By Bill Slawski, on November 20th, 2009In August, the Official Google Blog announced an upgrade to Google’s infrastructure code-named Caffeine, aimed at making the search engine faster, and Google opened the system up for testing to people who might want to provide feedback. An interview with one of the developers behind the upgrade described it as an upgrade to the Google File System.
While looking around the US Patent Office assignment database this morning, I noticed a number of new patents and patent applications assigned to Google on November 18, 2009, originally granted to startup MetaRAM.
If a search engine wanted to seriously upgrade its capabilities, it might do more than upgrade its software. It might also upgrade the hardware that it uses. The technology detailed in the MetaRAM patents could potentially transform Google’s computing capacity dramatically.
I have no idea if Google’s Caffeine upgrade also includes a memory upgrade at this point, but I suspect that the MetaRAM patent assignments may not be related.
A post at the Wall Street Journal’s blog from July told us about the demise of MetaRAM, a startup with some very high profile founders, board members, and exectives, including a CEO who was chief technology officer of Advanced Micro Devices Inc for ten years, and a Board of Directors’ member who was a former chief scientist of Sun Microsystems Inc. – Turning Out The Lights: Semiconductor Company MetaRAM
An interview with original and former CEO of MetaRAM from May of 2008, provides a lot of insight into the direction that the company was taking – Pioneering Change in the Memory Market: MetaRam Visionary Fred Weber.
Did Google acquire MetaRAM, or just the patent filings from the company? I’m not sure at this point. The WSJ blog post tells us that the company was shutting down without providing a date for its closing, but the LinkedIn profiles that I could find for people from MetaRAM still list their positions with the company as their present place of employment.
I haven’t been able to locate much in the way of recent news about MetaRam, nor much that associates them with Google.
Will Google keep this technology inhouse, and use it to reduce the costs of servers and workstations by a significant amount while increasing the amount of memory available to those systems, or will they license or sell the technology directly, or both? So little is known at this point, and there hasn’t been an announcement from Google or anyone from MetaRAM yet that I could find. I haven’t seen any rumors of the transaction behind the assignment of the patent filings anywhere on the Web either.
I’ve listed the granted patents and the patent applications separately below. There are 49 of them in total, though a number of them have been filed more than once for one reason or another.
Granted Patents:
Integrated memory core and memory interface circuit (7,515,453)
Abstract
A memory device comprises a first and second integrated circuit dies. The first integrated circuit die comprises a memory core as well as a first interface circuit. The first interface circuit permits full access to the memory cells (e.g., reading, writing, activating, pre-charging and refreshing operations to the memory cells). The second integrated circuit die comprises a second interface that interfaces the memory core, via the first interface circuit, an external bus, such as a synchronous interface to an external bus. A technique combines memory core integrated circuit dies with interface integrated circuit dies to configure a memory device. A speed test on the memory core integrated circuit dies is conducted, and the interface integrated circuit die is electrically coupled to the memory core integrated circuit die based on the speed of the memory core integrated circuit die.
Abstract
A memory circuit power management system and method are provided. In use, an interface circuit is in communication with a plurality of memory circuits and a system. The interface circuit is operable to interface the memory circuits and the system for autonomously performing a power management operation in association with at least a portion of the memory circuits.
Abstract
A memory circuit power management system and method are provided. An interface circuit is in communication with a plurality of memory circuits and a system. In use, the interface circuit is operable to perform a power management operation in association with only a portion of the memory circuits.
Interface circuit system and method for performing power saving operations during a command-related latency (7,581,127)
Abstract
A memory circuit power management system and method are provided. In use, an interface circuit is in communication with a plurality of memory circuits and a system. The interface circuit is operable to interface the memory circuits and the system for performing a power management operation in association with at least a portion of the memory circuits. Such power management operation is performed during a latency associated with one or more commands directed to at least a portion of the memory circuits.
Methods and apparatus of stacking DRAMs (7,379,316)
Methods and apparatus of stacking DRAMs (7,599,205)
Abstract
Large capacity memory systems are constructed using stacked memory integrated circuits or chips. The stacked memory chips are constructed in such a way that eliminates problems such as signal integrity while still meeting current and future memory standards.
Power saving system and method for use with a plurality of memory circuits (7,580,312)
Abstract
A power saving system and method are provided. In use, at least one of a plurality of memory circuits is identified that is not currently being accessed. In response to the identification of the at least one memory circuit, a power saving operation is initiated in association with the at least one memory circuit.
System and method for simulating an aspect of a memory circuit (7,609,567)
Abstract
A system and method are provided for simulating an aspect of a memory circuit. Included is an interface circuit that is in communication with a plurality of memory circuits and a system. Such interface circuit is operable to interface the memory circuits and the system for simulating at least one memory circuit with at least one aspect that is different from at least one aspect of at least one of the plurality of memory circuits. In accordance with various embodiments, such aspect may include a signal, a capacity, a timing, and/or a logical interface.
System and method for power management in memory systems (7,590,796)
Abstract
A memory circuit power management system and method are provided. In use, an interface circuit is in communication with a plurality of physical memory circuits and a system. The interface circuit is operable to interface the physical memory circuits and the system for simulating at least one virtual memory circuit with a first power behavior that is different from a second power behavior of the physical memory circuits.
Pending Patent Applications
Some of the patent applications below share names with granted patents above, and may contain the same or very similar content. There are also some pending patent applications with the same name and abstracts, and those have been grouped together below.
Apparatus and Method for Power Management of Memory Circuits by a System or Component Thereof (20080082763)
Abstract
An apparatus and method are provided for communicating with a plurality of physical memory circuits. In use, at least one virtual memory circuit is simulated where at least one aspect (e.g. power-related aspect, etc.) of such virtual memory circuit(s) is different from at least one aspect of at least one of the physical memory circuits. Further, in various embodiments, such simulation may be carried out by a system (or component thereof), an interface circuit, etc.
Combined Signal Delay and Power Saving System and Method for Use with a Plurality of Memory Circuits (20080123459)
Abstract
A system and method are provided. In use, at least one of a plurality of memory circuits is identified. In association with the at least one memory circuit, a power saving operation is performed and the communication of a signal thereto is delayed
Emulation of Abstracted DIMMs using Abstracted DRAMs (20090216939)
Abstract
One embodiment of the present invention sets forth an abstracted memory subsystem comprising abstracted memories, which each may be configured to present memory-related characteristics onto a memory system interface.
The characteristics can be presented on the memory system interface via logic signals or protocol exchanges, and the characteristics may include any one or more of, an address space, a protocol, a memory type, a power management rule, a number of pipeline stages, a number of banks, a mapping to physical banks, a number of ranks, a timing characteristic, an address decoding option, a bus turnaround time parameter, an additional signal assertion, a sub-rank, a number of planes, or other memory-related characteristics. Some embodiments include an intelligent register device and/or, an intelligent buffer device.
One advantage of the disclosed subsystem is that memory performance may be optimized regardless of the specific protocols used by the underlying memory hardware devices.
Abstract
A memory circuit power management system and method are provided. An interface circuit is in communication with a plurality of memory circuits and a system. In use, the interface circuit is operable to perform a power management operation in association with only a portion of the memory circuits
Abstract
A memory circuit power management system and method are provided. In use, an interface circuit is in communication with a plurality of memory circuits and a system. The interface circuit is operable to interface the memory circuits and the system for autonomously performing a power management operation in association with at least a portion of the memory circuits.
Memory Circuit Simulation System and Method with Power Saving Capabilities (20080027697)
Abstract
A system and method are provided including a component in communication with a plurality of memory circuits and a system. The component is operable to interface the memory circuits an the system for simulating at least one memory circuit with at least one aspect that is different from at least one aspect of at least one of the plurality of memory circuits. The component is further operable to perform a power saving operation.
Memory Circuit Simulation System and Method with Refresh Capabilities (20080027703)
Abstract
A system and method are provided including an interface circuit in communication with a plurality of memory circuits and a system. The interface circuit is operable to interface the plurality of memory circuits and the system for simulating at least one memory circuit with at least one aspect that is different from at least one aspect of at least one of the plurality of memory circuits. The interface circuit is further operable to control refreshing of the plurality of memory circuits.
Memory Circuit System and Method (20090024789)
Memory Circuit System and Method (20090024790)
Abstract
A memory circuit system and method are provided in the context of various embodiments. In one embodiment, an interface circuit remains in communication with a plurality of memory circuits and a system. The interface circuit is operable to interface the memory circuits and the system for performing various functionality (e.g. power management, simulation/emulation, etc.).
Memory Device with Emulated Characteristics (20080056014)
Memory Device with Emulated Characteristics (20080126687)
Memory Device with Emulated Characteristics (20080103753)
Memory Device with Emulated Characteristics (20080126692)
Memory Device with Emulated Characteristics (20080126689)
Memory Device with Emulated Characteristics (20080109206)
Memory Device with Emulated Characteristics (20080126688)
Memory Device with Emulated Characteristics (20080104314)
Abstract
A memory subsystem is provided including an interface circuit adapted for communication with a system and a majority of address or control signals of a first number of memory circuits. The interface circuit includes emulation logic for emulating at least one memory circuit of a second number.
Memory module with memory stack and interface with enhanced capabilities (20070195613)
Memory module with memory stack (20080126690)
Abstract
A memory module, which includes at least one memory stack, comprises a plurality of DRAM integrated circuits and an interface circuit. The interface circuit interfaces the memory stack to a host system so as to operate the memory stack as a single DRAM integrated circuit.
In other embodiments, a memory module includes at least one memory stack and a buffer integrated circuit. The buffer integrated circuit, coupled to a host system, interfaces the memory stack to the host system so to operate the memory stack as at least two DRAM integrated circuits. In yet other embodiments, an interface circuit maps virtual addresses from the host system to physical addresses of the DRAM integrated circuits in a linear manner.
In a further embodiment, the interface circuit maps one or more banks of virtual addresses from the host system to a single one of the DRAM integrated circuits. In yet other embodiments, the buffer circuit interfaces the memory stack to the host system for transforming one or more physical parameters between the DRAM integrated circuits and the host system.
In still other embodiments, the buffer circuit interfaces the memory stack to the host system for configuring one or more of the DRAM integrated circuits in the memory stack. Neither the patentee nor the USPTO intends for details set forth in the abstract to constitute limitations to claims not explicitly reciting those details.
Memory Refresh System and Method (20080025122)
Abstract
A system and method are provided. In response to the receipt of a refresh control signal, a plurality of refresh control signals is sent to the memory circuits at different times.
Memory Systems and Memory Modules (20080010435)
Abstract
One embodiment of the present invention sets forth a memory module that includes at least one memory chip, and an intelligent chip coupled to the at least one memory chip and a memory controller, where the intelligent chip is configured to implement at least a part of a RAS feature. The disclosed architecture allows one or more RAS features to be implemented locally to the memory module using one or more intelligent register chips, one or more intelligent buffer chips, or some combination thereof. Such an approach not only increases the effectiveness of certain RAS features that were available in prior art systems, but also enables the implementation of certain RAS features that were not available in prior art systems.
Method and Apparatus for Refresh Management of Memory Modules (20080028136)
Method and apparatus for refresh management of memory modules (20080109598)
Method and Apparatus For Refresh Management of Memory Modules (20080028137)
Method and Apparatus For Refresh Management of Memory Modules (20080109597)
Abstract
One embodiment sets forth an interface circuit configured to manage refresh command sequences that includes a system interface adapted to receive a refresh command from a memory controller, clock frequency detection circuitry configured to determine the timing for issuing staggered refresh commands to two or more memory devices coupled to the interface circuit based on the refresh command received from the memory controller, and at least two refresh command sequence outputs configured to generate the staggered refresh commands for the two or more memory devices
Methods and apparatus of stacking DRAMs (20070058471)
Abstract
Large capacity memory systems are constructed using stacked memory integrated circuits or chips. The stacked memory chips are constructed in such a way that eliminates problems such as signal integrity while still meeting current and future memory standards.
Method and circuit for configuring memory core integrated circuit dies with memory interface integrated circuit dies (20070014168)
Abstract
A memory device comprises a first and second integrated circuit dies. The first integrated circuit die comprises a memory core as well as a first interface circuit. The first interface circuit permits full access to the memory cells (e.g., reading, writing, activating, pre-charging and refreshing operations to the memory cells). The second integrated circuit die comprises a second interface that interfaces the memory core, via the first interface circuit, an external bus, such as a synchronous interface to an external bus. A technique combines memory core integrated circuit dies with interface integrated circuit dies to configure a memory device. A speed test on the memory core integrated circuit dies is conducted, and the interface integrated circuit die is electrically coupled to the memory core integrated circuit die based on the speed of the memory core integrated circuit die.
Multiple-Component Memory Interface System and Method (20080028135)
Abstract
A system and method are provided, wherein a first component and a second component are operable to interface a plurality of memory circuits and a system.
System and Method for Adjusting the Timing of Signals Associated with a Memory System (20080115006)
Abstract
A system and method are provided for adjusting the timing of signals associated with a memory system. A memory controller is provided. Additionally, at least one memory module is provided. Further, at least one interface circuit is provided, the interface circuit capable of adjusting timing of signals associated with one or more of the memory controller and the at least one memory module.
System and Method for Delaying a Signal Communicated from a System to at Least One of a Plurality of Memory Circuits (20080025108)
Abstract
A system and method are provided for delaying a signal communicated from a system to a plurality of memory circuits. Included is a component in communication with a plurality of memory circuits and a system. Such component is operable to receive a signal from the system and communicate the signal to at least one of the memory circuits after a delay. In other embodiments, the component is operable to receive a signal from at least one of the memory circuits and communicate the signal to the system after a delay.
System and Method for Increasing Capacity, Performance, and Flexibility of Flash Storage (20080086588)
Abstract
In one embodiment, an interface circuit is configured to couple to one or more flash memory devices and is further configured to couple to a host system. The interface circuit is configured to present at least one virtual flash memory device to the host system, wherein the interface circuit is configured to implement the virtual flash memory device using the one or more flash memory devices to which the interface circuit is coupled.
System and Method for Reducing Command Scheduling Constraints of Memory Circuits (20080109595)
System and Method for Reducing Command Scheduling Constraints of Memory Circuits (20070204075)
System and Method for Reducing Command Scheduling Constraints of Memory Circuits (20080120443)
Abstract
A memory circuit system and method are provided. An interface circuit is capable of communication with a plurality of memory circuits and a system. In use, the interface circuit is operable to interface the memory circuits and the system for reducing command scheduling constraints of the memory circuits.
System and Method for Simulating a Different Number of Memory Circuits (20080027702)
Abstract
A system and method are provided for simulating a different number of memory circuits. Included is an interface circuit in communication with a first number of memory circuits and a system. Such interface circuit is operable to interface the memory circuits and the system for simulating at least one memory circuit of a second number. Further, the interface circuit interfaces a majority of address or control signals of the memory circuits.
System and Method for Simulating an Aspect of a Memory Circuit (20090285031)
Abstract
A system and method are provided for simulating an aspect of a memory circuit. Included is an interface circuit that is in communication with a plurality of memory circuits and a system. Such interface circuit is operable to interface the memory circuits and the system for simulating at least one memory circuit with at least one aspect that is different from at least one aspect of at least one of the plurality of memory circuits. In accordance with various embodiments, such aspect may include a signal, a capacity, a timing, and/or a logical interface.
System and Method for Simulating an Aspect of a Memory Circuit (20080062773)
System and Method for Simulating an Aspect of a Memory Circuit (20080133825)
Abstract
A memory subsystem is provided including an interface circuit adapted for coupling with a plurality of memory circuits and a system. The interface circuit is operable to interface the memory circuits and the system for emulating at least one memory circuit with at least one aspect that is different from at least one aspect of at least one of the plurality of memory circuits. Such aspect includes a signal, a capacity, a timing, and/or a logical interface.
Abstract
A system and method are provided for use in the context of a plurality of memory circuits. In use, first information is received in association with a first operation to be performed on at least one of the memory circuits. At least a portion of the first information is stored. Still yet, second information is received in association with a second operation to be performed on at least one of the plurality of memory circuits. To this end, the second operation may be performed utilizing the stored portion of the first information in addition to the second information.
System and Method for Translating an Address Associated with a Command Communicated between a System and Memory Circuits (20070192563)
Abstract
A memory circuit system and method are provided. An interface circuit is capable of communication with a plurality of memory circuits and a system. In use, the interface circuit is operable to translate an address associated with a command communicated between the system and the memory circuits.
It does logically follow that Google would be looking at hardware methods to increase performance as well. Particularly ways of saving resources (equipment using less power etc) to shave a bit off their operating costs.
Hi James,
It does make sense, doesn’t it. The acquisition of MetaRam’s patent filings is a pretty serious move, considering how many patent filings were involved, and the potential impact on Google’s computing power if they were to incorporate the memory boost that the technology can bring to them. I’m still wondering if the people associated with MetaRAM have moved to Google along with the technology.
Just question, frankly I didn’t read all the patent abstracts there is way too much, question is there has been reports saying that caffine is faster than older Google but the truth may be its just their upgrades on the hardwares what you think? Plus could it be that new search engine demands more resources from hardware point of view?
Thanks
Hi seoyourblog,
I was overwhelmed by the number of patent filings myself – it took a while to go through all of them, but I wanted to make sure that they were all assigned to Google, and on the same day, and that they all focused upon memory and hardware. I thought it was worth sharing links to all of the filings for anyone who might be interested in seeing more, but I’m not anticipating too many people going through all of those abstracts.
From what I’ve read, the upgrades related to Google’s Caffeine should reduce bottlenecks in the way that information is retrieved from Google’s databases by making changes to how information on different chunk servers are accessed. While there could possibly be some hardware changes involved, it sounds like the primary change involved is in how the Google File System works.
I don’t think that hardware changes are at the root of the Caffeine upgrade, but it does look like MetaRAM was actually producing chips that could be used with the kind of servers that Google may be using. Adding more hardware based memory may make a significant impact on Google’s servers
It seems odd to me that Google would buy a patent on faster RAM just to use it in their servers – that doesn’t make sense to me. If they wanted to improve the performance of their hardware, you would think that there would be countless ways for them to do that which don’t require a patent on new memory modules. I don’t know what they paid for this, but it seems to me that if they needed more “brute force” in their computing environment that they could easily just buy more servers and get the job done a lot cheaper. I have a very hard time believing that RAM was a significant enough bottleneck in their systems that they needed to go out and acquire a patent on new RAM technology — that just can’t be a cost effective way of increasing the power of your hardware.
I think this is more likely to be unrelated to Caffeine. I mean how much sense does it make for them to acquire a memory patent just to use it in house and keep somebody else from getting it? It just doesn’t give them a big enough competitive advantage in any of their core markets to warrant acquiring for those purposes, IMO.
Could this be part of Google’s rumored router? If Google is in fact making it’s own uber-powerful line of routers, owning the patent on state-of-the-art memory modules makes a lot of sense. Very busy routers have huge demands.
My understanding is that Netlist, Inc. has brought patent infringement against first to MetaRAm and then Google for ‘386 patent related to breakthrough memory module exhibited recently at SuperComputing 09. Netlist in 2006 or thereabouts approached Google to discuss under an MOU to provide Google with breakthrough memory modules. Google ultimately declined. Netlist brught patent infringement against MetaRAM, and was in settlement discussion with Google when Google brought a pre-emptive lawsuit for declaratory relief that it is not infringing on Netlist ‘386 patent; and even if it was infringing such patent, Google claims it is moot because such Netlist patent is invalid. See the Complaint and Answer and Counter-Complaint from Netlist which action is in central district court CA.
Netlist symbol is NLST. For transparency, I own less than 20k shares in NLST, but have no insider information or have any relation to either company. It is advisable to do your own research.
Hi Buzzlord,
It wasn’t just one patent – the USPTO assignment database shows 49 patent filings assigned from MetaRAM to Google. There’s a possibility that Google may already be using some of this memory technology, though I haven’t seen anything yet that says so explicitly. A Google router sounds interesting – more research for me to do. Thanks.
Thank you, Auditor.
I appreciate your providing some details about this controversy. I’ve started to do some research.
The patent from Netlist in question appears to be this one:
Memory module decoder
Abstract
InformationWeek wrote about Google’s response to a number of letters from NetList in an article titled Google Launches Pre-Emptive Lawsuit Against Memory Maker. It appears that Google received proposals in 2006 from NetList for server memory, but decided to use another supplier. In May of 2008, NetList’s CEO sent a letter to Google which claimed that the memory Google chose infringed NetList’s patent.
Google filed a Complaint for Declaratory Judgment against Netlist, Inc., on August 29, 2008, asking a Federal District Court in the Northern District of California, San Jose Division, for a judgment stating that “Google does not infringe any valid and enforceable claim of the ‘386 patent” or alternatively “That the ‘386 patent is invalid.”
According to a docket that I could find for the case, Netlist filed an answer and a counterclaim on November 18, 2008:
Google Inc. v. Netlist, Inc.
U.S. District Court
California Northern District (Oakland)
CIVIL DOCKET FOR CASE #: 4:08-cv-04144-SBA
Assigned to: Hon. Saundra Brown Armstrong
Referred to: Magistrate Judge Joseph C. Spero
Cause: 35:145 Patent Infringement
Date Filed: 08/29/2008
Jury Demand: Both
Nature of Suit: 830 Patent
Jurisdiction: Federal Question
In the Netlist Form 10-Q filing of November 3, 2009 are these statements about litigation between Google and Netlist, and Netlist and MetaRAM:
I did find some more information about the lawsuits between Netlist and MetaRAM, though I don’t know how up to date the following dockets are:
Netlist Inc. v. MetaRAM Inc.
U.S. District Court
District of Delaware (Wilmington)
CIVIL DOCKET FOR CASE #: 1:09-cv-00165-GMS
Assigned to: Judge Gregory M. Sleet
Cause: 35:271 Patent Infringement
Date Filed: 03/12/2009
Jury Demand: Both
Nature of Suit: 830 Patent
Jurisdiction: Federal Question
Metaram, Inc. v. Netlist, Inc.
U.S. District Court
California Northern District (San Francisco)
CIVIL DOCKET FOR CASE #: 3:09-cv-01309-VRW
Assigned to: Hon. Vaughn R. Walker
Demand: $0
Cause: 35:271 Patent Infringement
Date Filed: 03/25/2009
Jury Demand: Plaintiff
Nature of Suit: 830 Patent
Jurisdiction: Federal Question
All very intriguing Bill. I tend to agree with Buzzlord though. I don’t feel all this is Caffeine related. Hadn’t heard about this Google router before. Also intriguing.
I don’t mean to be throwing up old rumors, but the Google router rumor ran rampant last January. I haven’t heard much of anything about it since then though… The rumor was that Google was going to make routers to compete with the Juniper line of products. If Google is acquiring technology like this though – it could mean it is for real.
The thing that gets me is that when Google was making the Android OS, technology journalists kept asking if they would make a phone. Google’s response was always “We do not make hardware.” If you don’t make hardware at all… what would you need with patents for RAM?
All of you are missing the point. MetaRAM allows to “hang” a lot of GBs off each CPU. Server apps, which is what of interest to Google, need as much GBs as possible. When you run multiple OS’es on top of VMware, e.g., which is also a typical server configuration / application, you can easily gobble up TBs of RAM. Google has been designing its own server HW for at least 7 years. Rumor has it that its HW group is less than stellar. It is only logical that Google bought MetaRAM IP portfolio for dime a dozen. Netlist should shut up and pack up – not to pick a war with Google over this. They are trying to claim priority over what may be similar – if not identical – to JEDEC JC LR-DIMM work. Interestingly, Inphy has not been mention by anyone on this blog. That’s how clueless everyone is.
My guess is that former employees of MetaRAM have not changed their profiles because many have not landed new jobs yet.
I am agree with Bullaman, I thing it is all to increase the performance to face the upcoming challenges by bing and yahoo.
Netlist (NLST) has patent infringement cases against MetaRAM as well as Inphi.
Netlist has serious IP in “rank multiplication”, “embedded passives” (for freeing up space on memory modules for memory), heat dissipation that is even (so that there is more tolerance for using lower quality memory chips which are cheaper to use).
GOOG was using MetaRAM. Memory module makers were using MetaRAM, Intel was supporting it. It was the darling of the industry. Except that it was infringing on Netlist’s IP.
Then MetaRAM went out of business.
http://venturebeat.com/2008/08/19/idf-intel-gets-behind-start-up-metarams-server-memory-solution/
IDF: Intel gets behind start-up MetaRAM’s server memory solution
August 19, 2008
Google probably does not want to jeopardize it’s server operations to a “small” (compared to Google’s size) legal issue with Netlist.
Google and Netlist are in negotatiations to cobble together an agreement. That must have been hard while MetaRAM IP was not under Google’s belt (now that MetaRAM is gone).
This is probably why Google has had to buy MetaRAM IP, so it can get a better agreement with Netlist.
Inphi makes components – it makes an “iMB” buffer chip that it wants to sell to memory module makers. Inphi has no IP (intellectual property) in this area. It is probably hoping the memory module makers will deal with infringement issues. However Netlist has filed a suit against Inphi.
The memory module makers are waiting for JEDEC to put it’s foot down. Until that happens they probably have to wait.
Meanwhile Netlist is already manufacturing the 16GB HyperCloud memory.
From Google’s point of view, there is now no competitor to Netlist. Netlist’s IP is strong, and MetaRAM is not even a company anymore. Inphi is making components for memory module makers but holds no IP.
You can understand this probably makes Google jittery regarding the supply of these new memory modules, since Google is probably a big consumer of high-memory loaded computers. The availability of Netlist’s 16GB HyperCloud memory module allows it to double capacity without having to install additional servers (for memory-bound tasts, such as virtualization/cloud-computing).
As long as the legal issues do not get resolved, Inphi and memory module makers will be wary of who do partner with to build the memory needed by Google.
Meanwhile Netlist can provide that memory right now. Using it’s 16GB HyperCloud, Google can install 384GB of memory per server (doubling memory, with would otherwise require adding additional servers).
Netlist allows doubling of memory, reduction in power consumption (which can be a lot for a heavily memory-loaded machine) and speed improvements. By avoiding adding new servers, you cut power consumption (as well as UPS and generator power requirements for data centers).
What do you think Google will do ? It probably wants to resolve the memory use issue, so it can continue forward.
Hi Bullaman,
It does sound like Caffeine is independent, doesn’t it. Going to look for more on the router.
Hi Buzzlord,
I’m still puzzling out why Google decided to invest in 49 patent filings involving memory. Internal uses only? Maybe. Though the patent infringement lawsuits can make one wonder.
Hi InTheKnow,
Thanks for a very interesting comment.
It did seem that Google would be interested in using MetaRAM’s technology for their own hardware.
Interestingly, Inphy filed a patent infringement suite earlier today against Netlist. The press release they issued included some specifics:
I looked up the patents:
Programmable strength output buffer for RDIMM address register (7,307,863)
Abstract
Output buffer with switchable output impedance (7,479,799)
Abstract
Things seem to be heating up.
Hi humza,
It’s beginning to sound like a possibility that Google may have been using MetaRAM’s technology for a while. That would make some sense.
Hi netlist_follower,
Thank you for your insight on this topic – much appreciated. I didn’t check into the Netlist lawsuit against Inphy yet, but that sounds like a good next step.
Inphy does have a number of patents, and it seems that they are now claiming that the two I listed a couple of comments ago are being infringed upon by Netlist in their modules, including the 16 GB HyperCloud memory.
Interesting speculation as well on Google’s acquisition of MetaRAM’s intellectual property. I imagine that Google will be happy to resolve these issues. Now that they own all of those patent filings, I’m wondering what their next steps might be, other than pursuing their declaratory injunction and defending the suite brought by Netlist.
I have a very hard time believing that RAM was a significant enough bottleneck in their systems that they needed to go out and acquire a patent on new RAM technology — that just can’t be a cost effective way of increasing the power of your hardware.
I am going to go with the general opinion here that it does seem unlikely but we have confirmation that they are doing this and there will be a reason behind it.
I am far from an expert on patents and dont really know how the work and what level of protection they offer but surely there has to be some visibility on these things to challenge them prior to becoming law? I know from watching Dragons den that what offers protection in one country does not always work in another.
Googles veil of mist and secrecy is half the fascination, part of me (the cynic) always thinks PR….
Hi Bill,
Update on Netlist v Google litigation. After a hotly contested hearing on 11/12/09, the Hon. Armstrong issued an order dated 11/16/09 in favor of Netlist’s ‘386 patent claim construction. On 11/18/09 or so, Google changed the attorney.
On 11/24/09 in Netlist v MetaRAM joint case mgmt statement, MetaRAM disclosed additional comment that it “ceased operations, and prior to then sold only approximately $37,000 worth of DDR3 memory controllers subject to lawsuit. None of those memory controllers were used by MetaRAM’s customers in commercial sales, and instead all were destroyed.” In the following sentence, MetaRAM referenced Google v Netlist as related case. Actions speak louder than words. A reasonable inference is that MetaRAM has taken drastic action to reduce and limit any potential liability from alleged patent infringement. Can you guess the identity of the MetaRAM’s customer, and why $37,000 worth of non-commercial DDR3 memory controllers were destroyed?
In re Netlist v Inphi, my understanding is that Netlist’s IP portfolios are continuation of its earlier patents. In fact, Netlist received more patent(s) in November 2009.
IMHO, Netlist is a logical acquisition target for Google, CISCO, Intel or even Microsoft in 2Q/3Q of 2010. Then again, you never know about tech stocks.
I wonder if the Nov 12, 2009 court order has anything to do with NLST stock price rise starting Nov 11-12.
Evidently as you load memory, the allowable bandwidth tends to go downhill. NLST’s HyperCloud memory module (demoed at Supercomputer Expo 2009 on HP ProLiant servers) doubles max memory to 384GB, while retaining ability to operate at max speed.
http://www.prnewswire.com/news-releases/netlist-demonstrates-new-hypercloud-memory-modules-at-supercomputing-09-70174702.html
Netlist Demonstrates New HyperCloud Memory Modules at Supercomputing 09
Showcases interoperability between standard JEDEC server memory solutions and HyperCloud modules
NLST HyperCloud presentation:
http://www.scribd.com/doc/22814075/Hyper-Cloud-Press-Presentation-11-4-09
It is also lower power (for maxed memory could be significant), but more significantly in applications which were previously memory-bound (as GOOG’s might be or in virtualization where you need to keep “virtual images” in memory) it halves the need for servers (which means you halve the need for power and REDUNDANT power i.e. UPSs, and generators).
http://www.theregister.co.uk/2009/11/11/netlist_hypercloud_memory/
Netlist goes virtual and dense with server memory
So much for that Cisco UCS memory advantage
By Timothy Prickett Morgan
Posted in HPC, 11th November 2009 18:01 GMT
…
The one cost that Duran did not calculate was savings in power and cooling, but the HyperCloud memory burns under 10 watts for a 16GB module, and in general, for a given capacity, a HyperCloud module will burn 2 to 3 watts less than a standard DDR3 module. And because HyperCloud memory can run at the full 1.33GHz speed, regardless of the capacity in the box, there should be a sizeable performance boost on applications that are sensitive to memory bandwidth – maybe as high as 50 per cent, says Duran.
NLST had shown this technology to GOOG some time back. Later GOOG had chosen to go with what now seems like MetaRAM (though as poster above suggests MetaRAM – now GOOG – claims not much was used ?).
NLST sent notice to GOOG about use of infringing technology. GOOG in turn sued to be left alone.
GOOG’s acquisition of MetaRAM’s IP is thus in line with it consolidating it’s defence against NLST suit (wouldn’t want to have MetaRAM in bankruptcy slacking off in defence since it would impact GOOG as a user of MetaRAM).
With the demise of MetaRAM, the only infringers left are Inphi, a component manufacturer. It probably seeks to offload infringing issues to memory makers. However memory makers are waiting for JEDEC to decide what to do with NLST in control of much of the IP in “rank multiplication”.
Earlier the memory module makers were allying with MetaRAM to supply them the technology. With MetaRAM no more, they will be looking to Inphi to provide them the technology. However Inphi has no IP in this area (the retaliatory lawsuit brought against NLST mentions some unrelated patents that Inphi holds).
http://www.inphi.com/news-events/press-releases-and-media-alerts/inphi-announces-availability-of-industrys-first-memory-buffer-based-on-its-isolation-memory-buffer-technology.php
Inphi announces availability of industry’s first memory buffer based on its isolation memory buffer technology
Inphi component enables servers and workstations to handle greater volumes of data and support more memory modules
…
Since first unveiling details of its iMB technology in June 2009, Inphi has worked closely with the JEDEC standards body and with the entire server technology ecosystem to make the benefits of the iMB technology available in standardized form. Of the multiple approaches to memory buffer (MB) technology, JEDEC has chosen Inphi’s single-chip configuration as the basis for the standard, which is expected to be finalized in the first quarter of 2010. At that time, Inphi plans to have JEDEC-compliant iMB parts available.
http://www.inphi.com/news-events/inphi-in-the-news/2009/enterprise-memory-for-energystar-systems.php
Enterprise Memory for EnergyStar Systems
Thursday, 12 November 2009
…
With the release of the energy star rating for compute servers, there has been a number of approaches to meet the requirement and increase density & performance. Standards communities such as JEDEC, the 40G/100G networking associations are currently finalizing adoption of the the iMB (Isolation Memory Buffer) technology for new high performance memories. The use of this technology creates a new class of memory module called the LRDIMM (Load Reduced Dual Inline Memory Module). This technology was developed by Inphi, a ten year old high speed analog semiconductor company from Sunnyvale CA.
…
The LRDIMMs are being built by Hynix Samsung, Micron, Naya and others using the Inphi chips in Q1 ‘10. The products are currently only for the Enterprise class EnergyStar applications as the Inphi chip that is being used costs about $25US in 100k qty. The advantage of the technology is the power reduction and density/performance improvement while still maintaining the 10-12 BER and supporting a single chip/ single cycle load for both command and address signals.
By acquiring MetaRAM’s IP, GOOG along with NLST now hold the keys to the new JEDEC LRDIMM standard which is being hashed out.
http://www.simmtester.com/PAGE/news/showpubnews.asp?num=167
What is LR-DIMM , LRDIMM Memory ? ( Load-Reduce DIMM)
Tuesday, October 13, 2009
CSCO’s UCS strategy does the same thing, except it seeks to put an ASIC on the motherboard and sell it’s servers.
In contrast NLST’s solution is to put the ASIC on the memory module itself. Thereby allowing it to be used as a regular memory module.
Here is an article which explains the difference:
http://www.theregister.co.uk/2009/11/11/netlist_hypercloud_memory/
Netlist goes virtual and dense with server memory
So much for that Cisco UCS memory advantage
By Timothy Prickett Morgan
Posted in HPC, 11th November 2009 18:01 GMT
http://www.ideationcloud.com/2009/11/12/after-metaram-enter-netlist-hypercloud-and-more-memory-for-all-types-of-servers/
After MetaRAM, enter Netlist: HyperCloud and more memory for all types of servers
By Tarry Singh at 12 November, 2009, 2:03 am
I don’t know what MetaRAM was expecting to do earlier – either it was asserting IP like NLST is with JEDEC, or MetaRAM was acting as supplier of chips (like Inphi – though Inphi holds little IP in this area).
MetaRAM holds IP in the area, but on stuff like stacked DRAMs etc. which NLST has said is inefficient for even heat dissipation etc.
Here is some more info on the limits to memory capacity:
http://searchdatacenter.techtarget.com/news/article/0,289142,sid80_gci1358898,00.html
Cisco’s hopes its Extend Memory technology will boost UCS
By Bridget Botelho, News Writer
10 Jun 2009
…
Adding capacity
In traditional systems, the CPU memory controller can use only a certain number of DIMMs and, thus, seeks out that number. The latest Intel Xeon 5500, for instance, can address up to 12 or 18 DIMMs, though it poses a performance tradeoff for the latter, David Lawler, Cisco’s vice president of platform products, told SearchDataCenter.com.
Cisco’s Extend Memory technology makes a CPU see one DIMM as four separate DIMMs, giving a single 12-DIMM server the memory capacity of 48 DIMMs and up to 384 GB of memory.
To address this issue, Cisco engineers placed a high-performance chip on the memory bus between the processor and the DIMM that changes the way the CPU searches for DIMMs, Lawler explained. “So when the CPU searches for an 8 GB DIMM, we can represent that as four 2 GB DIMMs instead,” he said.
…
Whether a CPU accesses an 8 GB DIMM or four 2 GB DIMMs makes no difference from a capacity standpoint, but using more, smaller DIMMS versus fewer, larger DIMMs is cheaper. An 8 GB DIMM is significantly more expensive than buying four 2 GB DIMMs because the cost of memory increases exponentially with density. A 2 GB DIMM, for example, costs around $125, but an 8 GB DIMM can cost more than $1,000.
…
Servers hosting virtual machines with large databases can run out of memory far before they run out of CPU power, so having that extra memory capacity to work with could be a strong selling point for Cisco.
“On a normal host, memory usually is the first resource we’re short on. When the CPU of a fully loaded ESX box is still at 60%, we often run into memory shortage,” said virtualization expert Gabrie van Zanten.
On the Ars OpenForum IT community site, one Unix administrator and virtualization user listed the “huge memory density with full-size blades” on UCS as one reason he may switch from Dell blade servers to the UCS.
Google probably owns the fastest CPU’s and ram a server could hold but why upgrade? Maybe their trying to fix some server hardware errors, or they are up to something, since they started engineering a google phone why not try their hands on google routers, that would be cool!
Hypothetically speaking if Google is venturing out to manufacture servers to compete against Cisco, it would make sense for Cisco to acquire Netlist and Broadcom. That is assuming that either is up for sale. My understanding is that Netlist insiders hold 51% of its stock. They have the manufacturing plant in China to capitalize on this Hypercloud R&D investment. I will vote for the underdog to knock out the giant. Bigger they are, the harder they fall. I’ve got more DD to conduct to set entry level for Netlist and Broadcom.
Hi Bill,
Based on my reading of Inphi and Netlist patent history and portfolio, I agree with Netlist legal counsel’s opinon that Inphi’s retaliatory infringement claims have no merit. My research shows the following:
Netlist’ IP attorneys of record: Knobbe, Martin, Olson & Bear
7,289,386, patent date: October 30, 2007
Appl. No.: 11/173,175
Filed: July 1, 2005
Inphi’s IP attorneys of record: Koppel, Patrick, Heybl & Dawson
7,307,863, patent date: Dec. 11, 2007
Appl. No.: 11/195,910
Filed: Aug. 2, 2005
Inphi’s 2nd patent referenced in lawsuit
7,479,799, patent date: Jan 20, 2009
Appl. No.: 11/376,593
Filed: Mar. 14, 2006
Netlist’s ‘386 patent has also can claim benefit of its prior related patents.
7,289,386, patent date: October 30, 2007
Appl. No.: 11/173,175
Filed: July 1, 2005
CROSS-REFERENCE TO RELATED APPLICATIONS
The present application is a continuation-in-part of U.S. patent application Ser. No. 11/075,395, filed Mar. 7, 2005, which claims the benefit of U.S. Provisional Application No. 60/550,668, filed Mar. 5, 2004 and U.S. Provisional Application No. 60/575,595, filed May 28, 2004. The present application also claims the benefit of U.S. Provisional Application No. 60/588,244, filed Jul. 15, 2004, which is incorporated in its entirety by reference herein.
Slice of Netlist’s patent summary and description is:
DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS
Various types of memory modules 10 are compatible with embodiments described herein. For example, memory modules 10 having memory capacities of 512-MB, 1-GB, 2-GB, 4-GB, 8-GB, as well as other capacities, are compatible with embodiments described herein. In addition, memory modules 10 having widths of 4 bytes, 8 bytes, 16 bytes, 32 bytes, or 32 bits, 64 bits, 128 bits, 256 bits, as well as other widths (in bytes or in bits), are compatible with embodiments described herein. Furthermore, memory modules 10 compatible with embodiments described herein include, but are not limited to, single in-line memory modules (SIMMs), dual in-line memory modules (DIMMs), small-outline DIMMs (SO-DIMMs), unbuffered DIMMs (UDIMMs), registered DIMMs (RDIMMs), fully-buffered DIMM (FBDIMM), mini-DIMMs, and micro-DIMMs.
. . .
Memory Density Multiplication
In certain embodiments, two memory devices having a memory density are used to simulate a single memory device having twice the memory density, and an additional address signal bit is used to access the additional memory. Similarly, in certain embodiments, two ranks of memory devices having a memory density are used to simulate a single rank of memory devices having twice the memory density, and an additional address signal bit is used to access the additional memory. As used herein, such simulations of memory devices or ranks of memory devices are termed as “memory density multiplication,” and the term “density transition bit” is used to refer to the additional address signal bit which is used to access the additional memory.
In certain embodiments utilizing memory density multiplication embodiments, the memory module 10 can have various types of memory devices 30 (e.g., DDR1, DDR2, DDR3, and beyond). The logic element 40 of certain such embodiments utilizes implied translation logic equations having variations depending on whether the density transition bit is a row, column, or internal bank address bit. In addition, the translation logic equations of certain embodiments vary depending on the type of memory module 10 (e.g., UDIMM, RDIMM, FBDIMM, etc.). Furthermore, in certain embodiments, the translation logic equations vary depending on whether the implementation multiplies memory devices per rank or multiplies the number of ranks per memory module.
My understanding is that Google, MetaRAM and Inphi has weak argument why they should not have to pay for “alleged” patent infringement. Equity and corporate ethics favor Netlist.
Please do your own DD and come to your own conclusion. Happy holidays . . .
Hi Inspirational,
I’m not sure that Google acquired MetaRAM’s intellectual property solely to increase the power of there technology, but I would say that memory modules like this would be helpful in getting rid of some bottlenecks.
Hi Jimmy,
The patent process is pretty involved, and does amount in a fair amount of scrutiny. Some patents require a fair amount of knowledge to understanding what they cover – I’m not going to begin to claim that I have enough of that knowledge when it comes to these patents focusing upon memory.
Hi Auditor,
Thanks for the updates. At this point, I’m wondering what kind of memory Google is actually using in their servers.
Would they build servers in competition against companies like Cisco? Funnier things have happened when it comes to a business developing technology and processes in response to a need, and finding that they have the possibility of a whole new revenue stream. It’s a little tempting to think that if Google were to want to go in that direction that they might start considering Netlist as an acqusition target. I’m not sure if that’s a possibility, or if it is feasible. I still find myself questioning Google’s motivations in acquiring MetaRAM’s IP, especially knowing about ongoing litigation.
Hi netlist,
There was also a drop in Netlist’s stock when the Inphy countersuit was announced, regardless of Netlist’s statements that the countersuit had no merit. I appreciate your extensive updates. Thank you. I’m going to have to find some time to look through all the references that you pointed towards this weekend.
Hi Mal,
I’m not sure that it’s safe to presume what Google is running on their servers at this point. One thing is for certain – there are a lot of lawyers involved in the thick of things here. It’s going to be interesting seeing how all of this plays out.
There’s something interesting here.
1. Google, Netlist then Metaram and Inphi are tangled up in lawsuits
2. Netlist stock shoots up and folks make money
Connected? I think Metaram was selling a lot of DDR2 memory to Google and others (for AMD servers) and about to sell DDR3 for Intel servers. There was a lot of press on Metaram and DDR2 in Feb 2008. Netlist threatens Google. Metaram gets hit with a lawsuit by Netlist. Google buys Metaram. Someone believes Netlist will settle and get the Google and other business. Smacks of insider trading. Search for CEO and board members for these companies and you get to Fred Weber (Metaram CEO) and Atiq Raza (board member) who worked together at AMD. Search on Raza and insider trading and you find he settled an insider trading suit. Remember Hector Ruiz at AMD?
Insider trading!
Bill and Auditor: I took a look at your postings. It seems there are 5 lawsuits:
http://www.rfcexpress.com/lawsuit.asp?id=39876
http://www.rfcexpress.com/lawsuit.asp?id=44941
http://www.rfcexpress.com/lawsuit.asp?id=45344
http://www.rfcexpress.com/lawsuit.asp?id=50603
http://www.rfcexpress.com/lawsuit.asp?id=52389
You can see all the details via PACER of course, http://pacer.psc.uscourts.gov/
There’s a lot on Google v. Netlist. Not so much on the others. Your comments on the patent sale are interesting. The one MetaRam patent in the case against Netlist is 7,472,220. This patent is still assigned to MetaRam, but has a terminal disclaimer.
See the first page http://www.google.com/patents?vid=USPAT7472220
From http://www.freepatentsonline.com/help/item/Terminal-Disclaimer.html
“A binding statement made with the Patent Office in a case where more than one patent
has been obtained by the inventor on the same invention. The disclaimer will state
that the later patent will expire at the same time as the former patent and the later
patent will be enforceable only as long as both the patents are commonly owned.”
According to PAIR there are 3 patents that have to be commonly owned with 7,472,220:
http://portal.uspto.gov/external/portal/pair
11/461439 now US 7,580,312 (transferred according to your list)
11/524812 now US 7,386,656 (transferred according to your list)
11/584179 now US 7,581,127 (not on your list but assigned to Google according to the USPTO records)
There are currently 10 patents granted to MetaRam according to the USPTO, you listed 9, the last above is the extra one.
I will be interested to see how MetaRam and Google handle this with Netlist. If MetaRam doesn’t have rights to enforce this patent any more, they may have to drop their case against Netlist or perhaps Google has to take over. Then interesting things may happen.
Do either of you have any more information?
Hi IP Agent,
Thank you very much for your followup on this. When I originally checked at the USPTO assignment database. I did only see 49 granted patents and patent applications, but now I’m seeing 50. US 7,581,127 is on my list above (fourth one down), but I didn’t include 7,472,220, and I’m not sure why.
There’s a new patent application now listed in both lists as well, 20090290442, which wouldn’t have shown up in either search since it wasn’t published until November 26th, but it was assigned to Google on November 18th as well (Unpublished patent applications aren’t displayed in the assignment database at the USPTO). That explains why there are now 50 showing, instead of 49.
It’s possible that when I searched in the Assignment Database on MetaRAM, I looked in the “Assignor Name” field instead of the “Assignee Name:” field, which would have meant that I would miss 7,472,220, since it doesn’t appear to have been assigned to Google.
What’s odd is that the USPTO assignment database now lists 50 granted patents and patent applications as having been assigned to MetaRam, and 50 granted patents and pending patent applications as being assigned by MetaRam, and and they aren’t the same 50. I’m going to have to check on why there is a mismatch.
The granted patent you’ve pointed out is:
Interface circuit system and method for performing power management operations utilizing power management signals.
Interesting. Thank you.
IP Agent and Bill,
Above referenced MetaRAM patent application disloses Netlist patent work under Bakhta that was filed in 2005. Since Netlist claims Hypercloud is interoperable, can it work for Cisco legacy servers and routers without upgrading to new CPU? Has neutral or OEM eval/review been conducted on Hypercloud? Can Hypercloud be reconfigured for laptop or desktop use?
Interesting patent info.
auditor:
NLST claims HyperCloud will work like regular memory. So it should work on desktops. NLST probably isn’t making it for laptops because the form factor maybe different for laptop memory (which may or may not allow for extra circuitry). Also laptop may not be the ideal market for pushing this.
CSCO’s UCS strategy is essentially neutered by NLST HyperCloud – the difference is CSCO puts the ASIC on the motherboard while NLST puts it on the memory module itself. NLST also uses some other technologies like Planar-X and “embedded passives” to give it more space on the memory module (don’t know much about that).
NLST HyperCloud – as far as I have understood it – seems to allow greater memory density, greater memory speed and energy efficiency.
It seems as you load memory (electrical load issues ?) the achievable speed goes down. So on heavily memory-loaded systems you have the memory, but the achievable speed is not giving you the bang for the buck.
NLST HyperCloud makes the processor think less memory is on board and it runs it at full speed.
Repeating some references from above:
http://www.theregister.co.uk/2009/11/11/netlist_hypercloud_memory/
Netlist goes virtual and dense with server memory
So much for that Cisco UCS memory advantage
By Timothy Prickett Morgan
Posted in HPC, 11th November 2009 18:01 GMT
…
The one cost that Duran did not calculate was savings in power and cooling, but the HyperCloud memory burns under 10 watts for a 16GB module, and in general, for a given capacity, a HyperCloud module will burn 2 to 3 watts less than a standard DDR3 module. And because HyperCloud memory can run at the full 1.33GHz speed, regardless of the capacity in the box, there should be a sizeable performance boost on applications that are sensitive to memory bandwidth – maybe as high as 50 per cent, says Duran.
NLST HyperCloud presentation:
http://www.scribd.com/doc/22814075/Hyper-Cloud-Press-Presentation-11-4-09
Look at page 9 of the above Netlist HyperCloud presentation using Adobe viewer. Title is HyperCloud 2 vRank DDR3 RDIMMs. There is a picture of the Netlist memory module. Zoom in on the bottom of the memory module. Look near the notch in the connector at the bottom. Go to about 500% (times 5) magnification. The Netlist chips “Isolation devices” are different sizes, one is really squashed. The only explanation I can see is that the chip images have been pasted in using PhotoShop. Why would Netlist do that if they had real modules to demonstrate?
quote:
magnification. The Netlist chips “Isolation devices” are different sizes, one is really squashed. The only explanation I can see is that the chip images have been pasted in using PhotoShop. Why would Netlist do that if they had real modules to demonstrate?
NLST demonstrated at Supercomputer Expo 2009. Here is what HP VP had to say:
http://www.prnewswire.com/news-releases/netlist-demonstrates-new-hypercloud-memory-modules-at-supercomputing-09-70174702.html
Netlist Demonstrates New HyperCloud Memory Modules at Supercomputing 09
Showcases interoperability between standard JEDEC server memory solutions and HyperCloud modules
To showcase its 2-vRank HyperCloud modules, Netlist is using industry standard servers, such as the HP ProLiant DL380, demonstrated in the following configurations:
* 8GB and 16GB 2 vRank DDR3 RDIMM functionality
* Three 2 vRank modules per channel
* 1333 Mega Transfers per second (MT/s)
* Interoperability with standard JEDEC DDR3 modules
* Interoperability with different RDIMM capacities
“Customers running memory intensive computing environments, such as virtualization, cloud computing, and HPC applications, are often limited by memory bottlenecks in their servers,” said Mike Gill, vice president, Industry Standard Servers Platform Engineering at HP. “The Netlist technology on HP industry-standard servers increases server memory capacity and bandwidth to enhance application performance in converged infrastructures.”
Here is the JEDEC standard that Inphi wants to sell chips for, which JEDEC is mulling over, and whose final standard memory module makers are awaiting before they start using Inphi chips. However this is infringing NLST intellectual property. So until JEDEC resolves this, memory module makers and Inphi are stuck.
http://www.simmtester.com/PAGE/news/showpubnews.asp?num=167
What is LR-DIMM , LRDIMM Memory ? ( Load-Reduce DIMM)
Tuesday, October 13, 2009
Here is an example of MU waiting for buffers:
http://www.micron.com/products/modules/lrdimm/index
LRDIMM
quote:
But because end quality is dependent on more than just
reliability, we’re also working closely with buffer suppliers and server
OEMs to ensure that our LRDIMMs function well with multiple server
platforms.
HP has it’s own issues with CSCO’s UCS strategy (which NLST HyperCloud neuters).
http://www.cnbc.com/id/33865963
HP’s Shot Across Cisco’s Bow
Published: Wednesday, 11 Nov 2009 | 5:09 PM ET
By: Jim Goldman
CNBC Silicon Valley Bureau Chief
Earlier this year, Cisco [CSCO] opened a major front against one-time partners Hewlett-Packard [HPQ] and IBM [IBM] in the hotly competitive, and fast-growing server market with its blade, and so-called Unified Computing System initiative. The competition, and headlines it generated, become so intense so quickly that Cisco even posted a blog entitled “Is HP Now a Friend or Foe of Cisco?”
http://www.reuters.com/article/marketsNews/idCNN1228359720091113?rpc=44
HP still seen looking for deals after 3Com
Thu Nov 12, 2009 8:49pm EST
* Competitive pressures rising in tech with flurry of M&A
* Analyst say HP could pursue more networking deals
* Storage, software also seen as attractive to HP
* Brocade shares plunge 13 pct, unlikely target after 3Com
By Gabriel Madway
But why is Netlist “faking” pictures in a press presentation made so recently? Doesn’t seem right to me. End.
quote:
Look at page 9 of the above Netlist HyperCloud presentation using Adobe viewer. Title is HyperCloud 2 vRank DDR3 RDIMMs. There is a picture of the Netlist memory module. Zoom in on the bottom of the memory module. Look near the notch in the connector at the bottom. Go to about 500% (times 5) magnification. The Netlist chips “Isolation devices” are different sizes, one is really squashed. The only explanation I can see is that the chip images have been pasted in using PhotoShop. Why would Netlist do that if they had real modules to demonstrate?
Yes, you are right. The “buffer”-like chip to the left of the notch does look slightly smaller.
However note there are already 8 “buffer” chips there (which seems like a canonical figure if the “buffers” are for data lines). The smaller one to the left of the notch is the 9th. It might be an odd one out i.e. used for something else – maybe control signals or something like that.
After all there is no assertion that the chips are the same.
Hi Roomy Khan,
Interesting choice of names to use to post with here. I’m not sure who knows what about the inner workings of each of the companies involved, though it does appear to be a mess. I would guess that it would be unavoidable for some of the people involved in these companies not to know each other, or to have worked together, but there is the potential that something unusual might be going on. Just a quick disclaimer on my part – I own no stocks in any of the companies mentioned in this post, and in the comments to the post.
Hi auditor,
The engineering and interoperability of memory modules goes a bit outside the area of my expertise. Thankfully, netlist was able to answer your questions on that topic.
Hi netlist,
Thanks for answering auditor’s and engineer’s questions. I still have some catchup reading with the links that you’ve posted. (And I’m still wondering why Google purchased MetaRAM’s IP.)
On Dec 4, 09, Netlist brings separate suit against Google for infringing on Netlist USPTO patent 7,619,912, entitled “Memory Module Decoder” issued on Nov 17, 2009 based on patent application in mid-2005. In para 9, Netlist alleges that Google infringed on the ‘912 Patent including its use of the 4-Rank Fully Buffered Dual In-Line Memory Modules (4-Rank FBDIMMs) in its server computers.
This new Complaint significantly advances Netlist’s claims and rights against Google, because this suit comes after having examined Google’s server after winning discovery ruling from that (Google v Netlist) Court authorizing Netlist to inspect Google server despite Google’s strong objections.
Netlist Relief for Prayer includes temporary and permanent injunctive relief, and “treble damages” for unlawful practices of Google characterized as “willful and deliberate”.
This Complaint reads: “The ‘912 Patent is directed to memory modules with a logic element that overcomes computer system limitations that would otherwise constrain the memory module architectures with which the computer system can operate. As a result, the claimed memory modules effectively increase the memory capacity and improve the energy efficiency of the computers in which they reside. Netlist is the owner of the entire right, title, and interest in and to the ‘912 Patent. A true and correct copy of the ‘912 Patent is attached hereto as Exhibit 1.” Reference Case3:09-cv-05718-EMC Filed 12/04/09
Hi Auditor,
From what little I’ve seen online regarding the injunctive relief requested on that suit, in part it asks for Google to stop using servers that use memory that infringes upon the Netlist patent. I don’t know how many servers Google uses that might include the memory modules in question, but if that is granted, it could possibly be a harsh blow to Google. Have to see if I can find a copy of the complaint.
From NLST’s complaints, and GOOG’s testimony, it seems to suggest GOOG is not just an innocuous buyer of memory from MetaRAM or some such infringer.
But GOOG seems itself to be a major party involved in issues of memory design (something which other posts here seem to suggest as well – that they had a hardware design group for such things).
NLST’s complaint includes use by GOOG of 4-rank FBDIMMs and inducing others to sell such stuff (maybe MetaRAM ?).
Patent in question is:
http://www.freepatentsonline.com/7619912.pdf
Just some comments on looking through the court dockets in GOOG suit against NLST.
In the previous GOOG suit against NLST, GOOG and NLST have a settlement conference in August 2010. They will probably have to thrash out an agreement before then.
In looking through court documents one can see that NLST has got access to a GOOG server (after GOOG protestations).
The protocol to be followed by NLST is outlined in:
JOINT INSPECTION PROTOCOL AND [PROPOSED] ORDER
NLST gets to inspect FBDIMMs – AMB buffer manufacturer, use of “Mode C” and non-Mode C, power consumption, replace with standard FBDIMMs, monitor thermal stuff, take max of 20 photographs (”Attorney’s Eyes Only”). Inspected at GOOG lawyer’s offices (Fish and Richardson).
GOOG is saying it doesn’t contest that it is using FBDIMMS in Mode C.
It’s argument perhaps is that the NLST IP is faulty.
NLST removed Morrison and Foerster and replaced by Pruetz Law Group (which is a small outfit supposedly very good for IP).
From the docket item – “AMENDED JOINT CASE MANAGEMENT CONFERENCE STATEMENT AND [PROPOSED] ORDER”:
NLST inventors Jayesh Bhakta and Jeffrey Solomon have testified.
GOOG employees under spotlight:
Rick Roy – “involved in the development of the accused 4-rank FBDIMMs and who participated in meetings with Netlist concerning it’s patented technology”
Andrew Dorsey – same as above
Rob Sprinkle – same as above
GOOG’s main argument maybe presented in this docket item:
[REDACTED] GOOGLE INC.’s RESPONSIVE CLAIM CONSTRUCTION BRIEF
Earlier Judge Armstrong denied GOOG request to include NLST ‘386 patent “prosecution history” (at the Patent Office I presume):
As auditor reported above:
Update on Netlist v Google litigation. After a hotly contested hearing on 11/12/09, the Hon. Armstrong issued an order dated 11/16/09 in favor of Netlist’s ‘386 patent claim construction. On 11/18/09 or so, Google changed the attorney.
The Nov 12, 2009 order states:
THIS COURT HOLDS THAT pursuant to Markman v. Westview Instruments, Inc., 52 F.3d
967, 980 (Fed. Cir. 1995) aff’d, 517 U.S. 370 (1996) and this Court’s Standing Order at Paragraph
10, because the ‘386 Patent’s prosecution history is not in evidence and not addressed in either
parties’ claim construction papers, Netlist’s objection is sustained.
IT IS HEREBY ORDERED THAT Google and its counsel shall not present, refer to,
comment upon, introduce or use in any way, the ‘386 Patent’s prosecution history in its claim
construction presentation.
From docket item # 27:
GOOG does not dispute it is using “Mode C” in it’s FBDIMMs.
From docket #27:
NLST wants to see GOOG servers so it can verify they are using what JEDEC refers to as “Mode C” to make it seem like there are fewer ranks of memory than actually are on the memory module.
From GOOG’s account, they say in early 2006, GOOG was looking for manufacturers and tester of it’s FBDIMMs. It discussed with various companies (including NLST).
They signed NDAs to see GOOG’s FBDIMM design.
“GOOG does not dispute that it’s FBDIMMs operate in Mode C” ..
Earlier GOOG had said (docket #33 documents) that it may call Desi Rhoden (Exec. VP of Inphi) to explain rank etc.
That witness maybe less of an impartial “expert” after NLST vs. Inphi.
The impression one gets from the docket info in GOOG’s suit against NLST, is that GOOG was not just a customer of MetaRAM, but an active developer of memory, and that it was a user of privileged information that NLST gave to GOOG when NLST proposed new memory for GOOG.
Whether that info leakage had any link back to MetaRAM (through GOOG) is another story.
Another point of view of Netlist vs Google, notes the lobbying by Google asking that changes be made in current patent law. One would wonder if Google understands that it has a weak case against Netlist. Not to say that the efforts of Google to have laws changes are made wholely against Netlist, but companies like Netlist. I would hope for the sake of inovation that small companies like Netlist are not stripped of their ability to bring new ideas to market and be rewarded for their efforts.
The last post was a bit haphazard – just a quick run through the filings.
In answer to the potential question – “does NLST HyperCloud really work”, I guess we have confirmation from GOOG’s extensive use of “Mode C” in it’s servers.
This is something which has emerged from discovery in GOOG vs. NLST (the case which GOOG brought – no monetary damages, but to be left alone by NLST).
GOOG acknowledges use of “Mode C”. This means their thrust will primarily be on claiming non-validity of NLST IP. However NLST IP goes back to March 2004 (according to NLST filings) on the ‘386 patent. This predates MetaRAM IP (which GOOG has now bought in a panic to ensure that a MetaRAM loss while lax in bankruptcy does not wind up screwing GOOG in it’s own case).
I am not sure about the relationship between GOOG and MetaRAM – it is possible that the “other manufacturer” that GOOG used to manufacture was MetaRAM (?). There are few other players in this space – MetaRAM is dead, and Inphi is a generic component manufacturer and holds little IP – and they are awaiting JEDEC FBDIMM “Mode C” proposed standard results before module makers decide what to do.
In GOOG vs. NLST (the case which GOOG brought in order to get relief), GOOG has had to furnish it’s server – which has led to discovery has led to the recent NLST vs. GOOG lawsuit (which refers to another NLST patent as well). GOOG has lost claim that NLST patent history should be examined in the proceedings.
This seems to be the status thus far.
Dec 17, 2009 – the GOOG vs. NLST and more recent NLST vs. GOOG (concerning another patent infringement that NLST alleges following discovery in GOOG vs. NLST) have now been consolidated.
Evidently both NLST and GOOG wanted the two cases to be combined together. Accordingly new court dates have been set.
Hi spencity,
I have seen other places where Google had been asking for patent reform, before any hints of this litigation came out. The patent process itself does seem to be much more difficult for smaller businesses. I don’t know enough about the facts behind the Google/Netlist ligitation to decide the strength of their case, but more seems to be coming out.
Hi netlist,
I’m still not certain of the relationship between Google and MetaRAM at this point either. I did notice a few more patent filings assigned from MetaRAM to Google a week after the initial batch of assignments.
I do appreciate the updates. Consolidating the cases does make sense, just on the basis of cost and judicial economy themselves. This is getting pretty interesting.
Hi Bill Slawski,
It’s interesting that Netlist did not react with a knee jerk response to Google’s court filings earlier this year by immediately counter suing. Instead Netlist chose to first pursue legal action against Inphi. It makes since to attempt to prove the legitimacy of patents in question against the smaller company in order to arm itself with court tested evidence. It will much more difficult for Google to claim that the patents in question are invalid.
If “Mode C” usage shows up in a random GOOG server, what are we talking about here ? That nearly all GOOG servers use the infringing “Mode C” ?
Since “Mode C” is a smoking gun for use of 4-rank/virtual-rank – as it seems to have BIOS report (incorrect) info to the processor so it can be fooled.
This would mean a lot more servers than claimed – MetaRAM (or was it GOOG – anyone know who said that ?) said there were only a “few” such infringing products manufactured. Does not seem like a few if all GOOG servers are tainted as the server displayed in discovery phase (for GOOG vs. NLST) was ?
I am not totally clear on this, but it seems “Mode C” is related to having (patched) BIOS report the (incorrect) memory info to the processor.
Some info on JEDEC’s FBDIMM Mode C proposed standard
http://www.jedec.org/download/search/JESD82-20A.pdf
http://www.jedec.org/download/search/JESD82-28A.pdf
Of course, this seems not to be required by the newer NLST HyperCloud memory – which is supposed to work along with other memory in unaltered motherboards.
But “Mode C” usage is indicative of an attempt to do 4-rank and so is a “smoking gun”.
thank you for this page. Got good info. top question on my mind:
1. why did metaram shut down ? Couldnt find anything. (my conspiracy theory:
Did the VCs find out the company was based on a stolen IP ? (metaram established in mid 2006, nlst patent – 7289386 filed mid 2005)
2. Is Goog collecting metaram patents to have bargaining/negotiating power with nlst ? (way patents are written there is always
room to overclaim/underclaim patent coverage, althought attorneys try to make it as broad as possible).
Hi spencity,
While the timing of filing lawsuits may have a strategy to them, I’m not sure that we can read too much into that timing sometimes. With a certain amount of time to file some claims under statutes of limitations, and other times dictated by court rules, someone filing a claim or counterclaim may not always be free to file a case in court exactly when the idea time might be to do so.
It is interesting that Netlist did first file a suite against Inphi, though.
Hi netlist,
I’ve been wondering how many Google servers might be using “Mode C” as well, and if they might be affected by the outcome of a settlement or judgment.
Hi Mike,
You’re welcome. I’m wondering the same things myself. It really was a total surprise to see all of those patent filings assigned to Google. I didn’t realize at the time that there was a hornet’s nest of litigation to go with them.
We don’t know for certain what kinds of memory modules Google uses in its servers, but a recently published study from Google on DRAM errors doesn’t mention any modules of more than 4 GB. The paper does mention that data collected from the study “covers multiple vendors, DRAM capacities and technologies, and comprises many millions
of DIMM days.”
In that paper, we’re told this about Google’s systems:
The paper is:
DRAM Errors in the Wild: A Large-Scale Field Study (pdf)
It was written by Bianca Schroeder from the University of Toronto, and Google’s Eduardo Pinheiro and Wolf-Dietrich Weber. It was presented at SIGMETRICS/Performance’09, June 15–19, 2009, in Seattle, Washington.
quote:
I’ve been wondering how many Google servers might be using “Mode C” as well, and if they might be affected by the outcome of a settlement or judgment.
The court asked them to show a “GOOG server” and they show the one with “Mode C” in it. In court filings, GOOG has not mitigated impact by saying “only a few servers are implicated”. Instead they have said they are not denying use of “Mode C”, but the value of NLST’s IP.
However this is a risky tactic, as the cost of failure would be high (and possibly unacceptable) for GOOG. Which means settlement. The GOOG vs. NLST lawsuit GOOG filed in reply to NLST letter to GOOG may just have been that – to allow them time for a soft landing, esp. if they did not have good answer to NLST letters.
Does GOOG throw away old servers and continue replacing, or is the error rate such that they wind up replacing them anyway after some months ?
MetaRAM link with GOOG is unclear. My impression was it was MetaRAM which sold “infringing” modules to GOOG (NLST vs. MetaRAM).
Now it turns out GOOG was the sponsor with component specs and seeking someone to manufacture according to GOOG specs (GOOG vs. NLST court dockets).
Since MetaRAM (NLST vs. MetaRAM) claims a very small amount of sales, that would not account for the proliferation of “Mode C” in standard GOOG servers (the one GOOG showed when forced by discovery in GOOG vs. NLST). Also MetaRAM says they were not “sales” and were “destroyed”.
Question is – why would they “destroy” that hardware ?
From auditor post above:
On 11/24/09 in Netlist v MetaRAM joint case mgmt statement, MetaRAM disclosed additional comment that it “ceased operations, and prior to then sold only approximately $37,000 worth of DDR3 memory controllers subject to lawsuit. None of those memory controllers were used by MetaRAM’s customers in commercial sales, and instead all were destroyed.” In the following sentence, MetaRAM referenced Google v Netlist as related case. Actions speak louder than words. A reasonable inference is that MetaRAM has taken drastic action to reduce and limit any potential liability from alleged patent infringement. Can you guess the identity of the MetaRAM’s customer, and why $37,000 worth of non-commercial DDR3 memory controllers were destroyed?
quote:
1. why did metaram shut down ? Couldnt find anything. (my conspiracy theory:
Yes, not clear to me either (first article below). It could have been:
- the semiconductor slump (low memory prices) of that time
- serious issues with the technology not working well
- patent issues (or realization that NLST had the earlier IP, or a more comprehensive set of related IPs – for example in “embedded passives” – which would allow successful use
NLST has IP in “embedded passives” which frees up real-estate on the memory module. In addition MetaRAM has IP in “stacked modules” which NLST has criticized for it’s inability to deliver symmetric lines to memory chips:
http://www.netlist.com/technology/technology.html
While some packaging companies stack devices to double capacity, Netlist achieves the same result without stacking, resulting in superior signal integrity and thermal efficiency. Stacking components results in unequal cooling of devices, causing one device to run slower than the other in the stack. This often results in module failures in high-density applications.
The density limitation is solved by proprietary board designs that use embedded passives to free up board real estate, permitting the assembly of more memory components on the substrate. The performance of the memory module is enhanced by fine-tuning the board design to minimize signal reflections, noise, and clock skews.
This is a presentation by NLST’s Bill Gervasi on NLST’s “embedded passives” (who went on to SMOD and Chairman JEDEC DRAM Packaging Committee):
http://www.discobolusdesigns.com/personal/IMAPS_netlist_embedded_resistor_reliability_20050125.pdf
NLST’s new HyperCloud memory modules are pictured in this presentation (pg. 9):
http://www.scribd.com/doc/23156890/Hyper-Cloud-Press-Presentation-11-24-09New
Hyper Cloud Press Presentation 11-24-09New
Date Added 11/25/2009
Compare that to:
MetaRAM’s modules – they do seem a bit cluttered (with possibly asymmetrical chip layout ?):
http://www.ansoft.com/ie/Track2/DDR3%20Memory%20Module%20Design.pdf
Inphi’s “iMB” buffer and a possible memory module:
LR-DIMM with Inphi’s iMB™ Component
http://www.inphi.com/images/productImageLibrary/highRes/Inphi_LR-DIMM_with_iMB_Component_gold.jpg
The article below suggests volume, power and cost will be hard to reduce. However NLST claimed just that with HyperCloud at Supercomputer Expo – that is, memory density, speed increase (for heavily memory-loaded systems which otherwise have to run at slower speeds), power reduction (since 4-rank may allow you to reduce power for “inactive” memory modules), and ability to present more memory in total than otherwise would be handleable.
The article below suggests it is a complex thing to get right – it is possible that MetaRAM was not able to get enough space on memory module for enough “decoupling capacitors” etc.
http://lynnesblog.telemuse.net/292
Feb 25, 2008
MetaRAM Busts RAMBUS Stranglehold?
Snake oil or salvation from former AMD CTO,
By Lynne Jolitz
…
Is the technology innovative? Not likely — it sounds like a combination cache and bank decoder, which is not innovative in the least. In fact, you need 4x the number of components on the DIMM, which means 4x the number of current spikes and decoupling capacitors, even if you put the chips together in the same package. Because you have a fifth chip, you complicate things even more. There is no way you can approach the triple-zero (volume, power, cost) sacred to chip designers with such a design, because one single high-speed high-capacity chip will eventually win out given the proliferation of small expensive gadgets demanding the lowest of volume and power. In a world of gadgets like IPODs, cellphones, laptops, PDAs and the like, cost is very important but *not* the most important quantity. So RAMBUS doesn’t have a lot to worry about here.
…
So where does little MetaRAM come in. When technology fails, maybe a clever business model will do. MetaRAM’s big claim to fame is cost reduction — not for gadgets or laptops, but according to Fred Weber, CEO of MetaRAM, for “personal supercomputers” and “large databases”. And who is the big licensee for this so-called technology. Why, it’s Hynix of course, who announced they will make this lumbering memory module. They claim it will be lower power. I think I’d like an independent evaluation on this point, but it will probably be lower cost. Is it worth it? Given reliability considerations, that also remains to be seen. But the moral of this saga is simple — human memories are longer than memory architectures in this business, and the real puppet-master behind the throne (Kleiner-Perkins) is sure to walk away with the money. I wish I could say the same for the customers.
http://mobile.chipcrunch.com/Blogs/Startup.Blurbs/Semiconductor.startups.dropping.like.flies.html
Semiconductor startups dropping like flies
Written by Maciej Bajkowski
Tuesday, 14 July 2009
…
We profiled MetaRAM in March of last year, shortly after the company emerged from stealth mode. It was backed by several prominent venture capital firms including: Kleiner Perkins Caulfield & Byers, Khosla Ventures, Storm Ventures, and Intel Capital. This just shows you that having prominent VC backing is not a guaranteed indicator of success. Already back then we had a couple of concerns regarding the MetaRAM technology: First, with increasing DRAM frequency, how long would MetaRAM be able to hide the latency of their chipset via clever buffering of reads and writes? Second, it was inevitable that memory controllers would enable support for ever larger amounts of memory, possibly making MetaRAM technology irrelevant? Whether any of these was the actually reason for the company ceasing operations we might never know. The company’s website seems to be down, and as far as I’m aware nobody has been able to reach any of the company representatives for an official comment.
The article below suggests volume, power and cost will be hard to reduce. However NLST claimed just that with HyperCloud at Supercomputer Expo – that is, memory density, speed increase (for heavily memory-loaded systems which otherwise have to run at slower speeds), power reduction (since 4-rank may allow you to reduce power for “inactive” memory modules), and ability to present more memory in total than otherwise would be handleable.
The article below suggests it is a complex thing to get right – it is possible that MetaRAM was not able to get enough space on memory module for enough “decoupling capacitors” etc.
http://lynnesblog.telemuse.net/292
Feb 25, 2008
MetaRAM Busts RAMBUS Stranglehold?
Snake oil or salvation from former AMD CTO,
By Lynne Jolitz
…
Is the technology innovative? Not likely — it sounds like a combination cache and bank decoder, which is not innovative in the least. In fact, you need 4x the number of components on the DIMM, which means 4x the number of current spikes and decoupling capacitors, even if you put the chips together in the same package. Because you have a fifth chip, you complicate things even more. There is no way you can approach the triple-zero (volume, power, cost) sacred to chip designers with such a design, because one single high-speed high-capacity chip will eventually win out given the proliferation of small expensive gadgets demanding the lowest of volume and power. In a world of gadgets like IPODs, cellphones, laptops, PDAs and the like, cost is very important but *not* the most important quantity. So RAMBUS doesn’t have a lot to worry about here.
…
So where does little MetaRAM come in. When technology fails, maybe a clever business model will do. MetaRAM’s big claim to fame is cost reduction — not for gadgets or laptops, but according to Fred Weber, CEO of MetaRAM, for “personal supercomputers” and “large databases”. And who is the big licensee for this so-called technology. Why, it’s Hynix of course, who announced they will make this lumbering memory module. They claim it will be lower power. I think I’d like an independent evaluation on this point, but it will probably be lower cost. Is it worth it? Given reliability considerations, that also remains to be seen. But the moral of this saga is simple — human memories are longer than memory architectures in this business, and the real puppet-master behind the throne (Kleiner-Perkins) is sure to walk away with the money. I wish I could say the same for the customers.
http://mobile.chipcrunch.com/Blogs/Startup.Blurbs/Semiconductor.startups.dropping.like.flies.html
Semiconductor startups dropping like flies
Written by Maciej Bajkowski
Tuesday, 14 July 2009
…
We profiled MetaRAM in March of last year, shortly after the company emerged from stealth mode. It was backed by several prominent venture capital firms including: Kleiner Perkins Caulfield & Byers, Khosla Ventures, Storm Ventures, and Intel Capital. This just shows you that having prominent VC backing is not a guaranteed indicator of success. Already back then we had a couple of concerns regarding the MetaRAM technology: First, with increasing DRAM frequency, how long would MetaRAM be able to hide the latency of their chipset via clever buffering of reads and writes? Second, it was inevitable that memory controllers would enable support for ever larger amounts of memory, possibly making MetaRAM technology irrelevant? Whether any of these was the actually reason for the company ceasing operations we might never know. The company’s website seems to be down, and as far as I’m aware nobody has been able to reach any of the company representatives for an official comment.
Just as Inphi (with it’s “iMB” buffer) is now hoping for JEDEC approval and then use by memory module makers, similiarly MetaRAM was hoping to sell the chipset (and make the memory itself also it seems).
Inphi also had a press release about the “iMB” buffer for Supercomputer Expo. What is not clear is if they actually got it working – since Inphi just sells a buffer chip component.
Since NLST seems to be claiming 4-rank (and it IS the inventor of 4-rank) then why has it not gone against memory module makers of 4-rank modules before ?
http://www.cmtlabs.com/quadfbdimm.asp
The Memory Compatibility Experts
“Quad-Rank Fully Buffered DIMMs”
Or is it that NLST has targeted the buffer chip manufacturers (MetaRAM, and now Inphi) ?
Hynix and SMOD were banking on MetaRAM at that time:
http://www.digitimes.com/news/a20080820PR200.html
Hynix demonstrates DDR3 R-DIMM using MetaRAM technology at IDF
Press release, August 20; Esther Lam, DIGITIMES [Wednesday 20 August 2008]
…
Hynix using MetaRAM “chipset” – MetaRAM memory module has Hynix logo on it (page 10):
http://www.ansoft.com/ie/Track2/DDR3%20Memory%20Module%20Design.pdf
http://www.epn-online.com/page/new56803/smart-launches-8gb-dual-rank-ddr2-rdimms.html
SMART launches 8GB dual-rank DDR2 RDIMMs
04/03/2008
…
The new module combines SMART’s new DDR2 packaging technologies with the MetaRAM chipset architecture.
I am trying to understand how GOOG use of “Mode C” is an indicator of infringement. Is use of 4-rank infringement ?
NLST was the originator of 4-rank. Yet it was made into a JEDEC standard.
Anyone know the history of how that worked.
But 4-rank is a JEDEC standard – if NLST was the innovator of 4-rank, how did that become standard ?
Does this mean NLST disapproves of it – including all the other manufacturers who make it ?
But lacking legal resources it is only going after a few players first ?
Bill Gervasi (now at SimpleTech) was at NLST at the time of 4-rank development.
He was also Chairman of JEDEC committee on memory modules.
http://www.docmemory.com/page/news/showpubnews.asp?title=What+is+a+4-Rank+DIMM+Memory+%3F&num=128
For a successful implementation of 4 Rank DIMM memory, System designers need to be aware of which processors and memory controllers are
enabled to support four-rank modules. Finally, it is necessary to note that byte five of the serial presence detect (SPD) describes the number of ranks on
a module
Many system designers are now are rushing to find out what “4 rank memory” is all about ?. We have the pleasure to introduce Bill Gervasi, the
inventor/initiator of the “4 rank memory”, to furthur explain the details technical details regarding 4 Rank DIMMs.
4 rank modules, recently approved by JEDEC, address this gap by allowing up to 72 DRAMs per memory slot, enabling the 32GB per CPU
capacity goal using commodity 512Mb DRAMs. When the 1Gb DRAMs are finally in mass production, 4 rank modules double the reach again
to 64GB per CPU.
netlist, thank you for sharing all of your research and reasoning on this thread. your efforts and generosity are very much appreciated.
And Bill, thank you for starting this thread about Google, MetaRAM, the patents, and the lawsuits. This is the best thread of information about Netlist that I know of. Cheers.
Happy New Year to all, and may all Netlist investors prosper.
i just reread the entire thread. want to thank auditor too, and everyone else who contributed to this thread. didn’t mean to take anyone for granted. thanks all, very helpful info & discussion.
An update on the various court cases.
Looks like NLST vs. Inphi (and retaliatory Inphi vs. NLST) are on track.
GOOG vs. NLST and NLST vs. GOOG (inspired by discovery in GOOG vs. NLST) have been consolidated (request of both GOOG and NLST) – both to be heard by Judge Armstrong.
NLST extended time to GOOG to answer to complaint by Jan 29, 2009.
Meanwhile, NLST vs. MetaRAM (and retaliatory MetaRAM vs. NLST – although MetaRAM does hold some IP, unlike Inphi) have both been retracted by both parties.
Since MetaRAM is in bankruptcy, it would want to end the case – in any case MetaRAM vs. NLST wouldn’t have much meat if they no longer own the patent they are asserting (though perhaps they could still assert harm caused by NLST while MetaRAM owned those patents).
NLST probably can’t get much from a bankrupt MetaRAM – although they MAY have been able to block the transfer of IP from MetaRAM to GOOG (since NLST had potential recoveries to make from MetaRAM estate in case of win against them for infringement).
So is this related to a gradual “understanding” in the NLST vs. GOOG case – not necessarily for settlement, but for how the case should proceed (as usually happens between two opposing legal teams – i.e. they agree on what terms the fight will proceed).
Reasons why NLST would retract case against MetaRAM
- removed MetaRAM vs. NLST (minor inconvenience that it maybe)
- reduces court costs and whittles away nonessentials (since moral victory against MetaRAM less interesting than against still healthy GOOG or Inphi) – plus same boutique lawyer team handling all cases (with allied legal firm as well)
- having retraction by MetaRAM may help them slightly in fight against GOOG (to neutralize GOOG use of MetaRAM-like arguments – since GOOG now holds MetaRAM’s IP).
Reasons why MetaRAM (while privately held shares, still a limited company ?) would retract case
- is in bankruptcy – limited options
- no real case retaliatory case against NLST (esp. true if MetaRAM folded partially because of that understanding – that they had weak hold on IP)
Does anyone know the answers to any of these questions?
1)Why did Google originally decline to use Netlist’s product, and instead order products from MetaRAM?
2)Why did MetaRAM declare bankruptcy, and are they planning to emerge from bankruptcy and continue as a private, limited company? If so, what will their business be?
3)Google is claiming that Netlist’s patents are “invalid”. In what way? What evidence or reasoning supports this argument?
4)Reportedly, neither Google nor Inphi are seeking monetary damages from Netlist, but Netlist is seeking monetary damages from Google and Inphi. Does this fact suggest that Netlist has the stronger cases against Google and Inphi?
5)When is it likely that Netlist’s new product “Hypercloud” will complete trials by OEMs, be approved and certified, be ordered in great volumes, and start generating significant earnings for Netlist?
6)How might Netlist be negatively affected by adverse judgments in the two court cases, and by the JEDEC committee’s impending decision on memory product standards?
7)If Google loses or settles the case with Netlist, is Google likely to become a paying customer of Netlist?
My thanks to anyone for their thoughts on, or answers to, these and related matters.
Two more questions and thoughts:
8)If MetaRAM is planning to emerge from bankruptcy and continue as a private company, why would they sell their many patents to Google (and be left with no IP) unless their patents do in fact infringe on Netlist’s patents, and are more of a liability than an asset going forward?
9)If MetaRAM’s many patents do infringe on Netlist’s patents, why did Google quickly buy them all from a bankrupt MetaRAM? If MetaRAM’s patents infringe on Netlist’s patents, they should be useless to Google as a legal defense in the court case with Netlist, as bargaining leverage with Netlist, and as a basis for Google or its contractors to manufacture memory products as an alternative to, and competitor against, Netlist’s memory module solution for servers.
Since Netlist sued MetaRAM over MetaRAM’s patents allegedly infringing on Netlist’s patents, Google must know that Netlist will sue Google if Google ever tries to use MetaRAM’s patents to manufacture memory products.
1)Why did Google originally decline to use Netlist’s product, and instead order products from MetaRAM?
From what we know now from court dockets – GOOG has an internal hardware group which wanted to MANUFACTURE memory modules. They discussed with various people (including NLST) about manufacturing memory modules according to GOOG specs and components. At that time NLST may have revealed the stuff they were able to offer (or may have been in process of doing – since NLST had that lull while they transitioned to China factory). In either case GOOG may have felt NLST unable to deliver at that time – plus GOOG may have wanted to do it themselves (given they had their own team inside GOOG).
Eventually they wound up using other suppliers.
This by itself does not reflect badly on NLST. What it does reveal however is that GOOG was far more (complicit) than an innocuous buyer for memory from MetaRAM or other (as I was assuming earlier). Thus a direct infringer.
2)Why did MetaRAM declare bankruptcy, and are they planning to emerge from bankruptcy and continue as a private, limited company? If so, what will their business be?
They had the support of INTC and others (basically supplying the buffer chip – like Inphi is wanting to do now). Now MetaRAM claims (in court dockets) that they only sold like $37K worth of goods (?) and “destroyed” the rest – so they aren’t infringing NLST stuff (!).
Inphi is doing similar as MetaRAM (except they only make the buffer chip – while MetaRAM had buffer chip plus ability to create memory module). However as pointed out above, MetaRAM may have used “stacking” and such means which NLST looks askance on – because of it’s asymmetric heat dissipation and line lengths (asymmetric delay on lines).
3)Google is claiming that Netlist’s patents are “invalid”. In what way? What evidence or reasoning supports this argument?
This is standard boilerplate language for anyone first response to any patent claim – you can see it in all the patent cases.
You will note GOOG “rushed” to court on NLST “letter”. This is because GOOG probably saw no (simple) answer to NLST claims in that letter – it would inevitably lead to complex arguments. So GOOG chose to take it to court (in GOOG vs. NLST). That court case wound up costing GOOG – they had to turn over a GOOG server to NLST – which resulted in discovery of “Mode C” usage and data for NLST. NLST already had counterclaims in GOOG vs. NLST, but they probably were waiting for additional data from this discovery – which they used in NLST vs. GOOG (which is more recent).
Another advantage for GOOG in going to court is it establishes an orderly method to deal with this “threat”. Since it affects the health of GOOG’s entire server infrastructure (since a typical GOOG server is using “Mode C” which is a smoking gun for “4-rank” usage), it was an essential asset to protect. Now in court proceedings, GOOG has the luxury of doing things in an orderly manner – no tension – if they are weak they settle and pay in an orderly way without any threat to GOOG’s structure. Plus they have option to do a buy deal with NLST (if NLST HyperCloud is that superior).
Circumstantial evidence suggests, GOOG purchase of MetaRAM’s assets is a ploy to gain SOME leverage. However as you have seen the MetaRAM cases have been voluntarily retracted by both NLST/MetaRAM – so this may affect GOOG adversely in that those cases don’t help it much in discovery or issues against NLST.
MetaRAM has significant IP – however it is IP in “stacked” modules and stuff which may or may not overlap NLST. Plus NLST has earlier (March 2004 antecedents) in the relevant patents.
Note also NLST position is significantly different from a year ago – at that time, even if GOOG wanted they could not have done a deal with NLST (as NLST was still going through transition to chinese factory and move off commodity memory into these high margin products).
4)Reportedly, neither Google nor Inphi are seeking monetary damages from Netlist, but Netlist is seeking monetary damages from Google and Inphi. Does this fact suggest that Netlist has the stronger cases against Google and Inphi?
NLST IS seeking damages, treble damages (for wilful violation etc.). This by itself doesn’t mean they have a “stronger” case.
The reason GOOG hasn’t claimed damages is that the tone of GOOG vs. NLST is to “please protect us from NLST” – as stated above it is basically a structured arena where GOOG can safely deal with this problem in a controlled way – i.e. if it works out good if not pay.
The reason Inphi hasn’t claimed damages, is that they have a (some would say) frivolous suit (retaliatory). Secondly they have not been damaged by NLST yet. In any case Inphi is a component maker which is not exactly focused on this niche and it’s IP is weak in this area.
On a related note, John Smolka (former Inphi employee) joined NLST recently (from SEC filing on awarding of options).
5)When is it likely that Netlist’s new product “Hypercloud” will complete trials by OEMs, be approved and certified, be ordered in great volumes, and start generating significant earnings for Netlist?
Someone else may have better insight into this.
6)How might Netlist be negatively affected by adverse judgments in the two court cases, and by the JEDEC committee’s impending decision on memory product standards?
JEDEC committee is probably conflicted, because their standard conflicts with NLST. This means MU and others will not be using Inphi buffer chips. So basically alternative to Hypercloud is on ice until JEDEC decides how to proceed.
NLST will be negatively affected if it “loses” the court cases – which is unlikely given NLST’s strong position in this area – i.e. second to none. If there is overlapping IP – then there is a settlement. In any case, there are no real “competitors” left in this area. MetaRAM was the only one who was seriously specialized in this area (and a supplier of memory buffers), plus it has some IP. Inphi does not come close. GOOG is a serious player, but it too has weak IP in this area (only the MetaRAM IP they just bought). Plus specifically in “4-rank” (i.e. “fooling” the processor/memory controller into thinking there is less memory than really is – is specifically a NLST patent having antecedents to March 2004). Plus there is a history of leakage – from Texas Instruments leakage to JEDEC committee, to MetaRAM, to GOOG discussions with NLST prior to making their own memory that fits into a “story”. Bill Gervasi – inventor of 4-rank while at NLST was later head of JEDEC committee – so there is probably some promiscuous employment (given such a small niche area).
7)If Google loses or settles the case with Netlist, is Google likely to become a paying customer of Netlist?
It is unlikely GOOG will “lose” the case – that would mean shutting down the GOOG network. It’s not like GOOG can’t pay any price that is required – so more likely is GOOG will eventually settle – either for cash sum, but more likely (to escape black eye of “do no evil” motto violation) they would opt for some “neutral” thing like overpaying for NLST memory or something. Or if GOOG is confident in own manufacturing (some have suggested their inhouse hardware division is not exactly all that great) they may license then.
Of course such a decision would have devastating consequences on the JEDEC FBDIMM “Mode C” proposed standard.
GOOG would probably like there to be a standard – for better pricing (since it is a big consumer of memory).
So one option (best for GOOG) would be some arrangement where NLST IP is allowed by NLST to become JEDEC standard – in return for something or other (i.e. shades of RMBS).
netlist,
Thank you very much for your fast and detailed reply. I’m glad you’re on this thread. All the best.
8)If MetaRAM is planning to emerge from bankruptcy and continue as a private company, why would they sell their many patents to Google (and be left with no IP) unless their patents do in fact infringe on Netlist’s patents, and are more of a liability than an asset going forward?
Unlikely that MetaRAM would emerge from bankruptcy – usually companies go into bankruptcy to shed debt. In many cases the management can continue (if resurrected) under new owners. In MetaRAM’s case the management WERE the owners. So it is unlikely to emerge AS MetaRAM.
However it lives on as GOOG-owned MetaRAM IP. Which GOOG will probably use to bolster it’s position against NLST, and possibly for future dealings with companies (since patents tend to get used as currency as well – if sued, countersue with patents other may be infringing – given the state of excessive issuance of patents in overlapping areas).
After sale of IP to GOOG, MetaRAM assets are further reduced, so “MetaRAM” of old probably will not emerge.
Think now of GOOG as the new “MetaRAM”.
9)If MetaRAM’s many patents do infringe on Netlist’s patents, why did Google quickly buy them all from a bankrupt MetaRAM? If MetaRAM’s patents infringe on Netlist’s patents, they should be useless to Google as a legal defense in the court case with Netlist, as bargaining leverage with Netlist, and as a basis for Google or its contractors to manufacture memory products as an alternative to, and competitor against, Netlist’s memory module solution for servers.
Well having those MetaRAM patents (on the cheap) is probably better than appearing in court without pants on.
Since Netlist sued MetaRAM over MetaRAM’s patents allegedly infringing on Netlist’s patents, Google must know that Netlist will sue Google if Google ever tries to use MetaRAM’s patents to manufacture memory products.
GOOG is not trying to “win” the case with the MetaRAM patents – it is just slightly “better” to have them. That is, can perhaps get away with less violation issues, or pressurize NLST on other fronts as nuisance.
However, note that GOOG situation is not symmetric with NLST. GOOG is an existing violator – so is in for some “damages”. Also if there is threat of treble damages. Not that the money will be of great concern to GOOG with it’s billions – but still as lawyers, GOOG attorneys will seek to limit damage to GOOG and avoid jury trial at the last minute.
Language is typical for such cases:
..Google’s infringing activities in the United States and this District include it’s use of 4-Rank FBDIMMs in it’s server computers and contributing to and/or inducing others to make, use, sell, and/or offer for sale such 4-Rank FBDIMMs, and/or components thereof which lack any substantive non-infringing use.
..Google’s infringement of the ‘912 patent is wilful and deliberate ..
..Netlist be awarded damages adequate to compensate Netlist for ..
..That the court award treble damages to Netlist for the unlawful practices described in this Complaint.
..That the court render judgement declaring this to be an exceptional case.
netlist,
Thanks again for your most recent post. I learned a lot of good info from it.
Overall, it seems that Netlist is in the best position. In contrast, Google and Inphi (and MetaRAM and Texas Instruments) seem to have engaged in questionable conduct, but Netlist has not, apparently.
And the fact that Netlist has a brand-new, potentially “breakthrough” product in an important niche of the emerging cloud-computing, and at a time when there are no real or strong competitors, suggests that Netlist should prosper significantly in 2010 — after a few months of resolving the current conflicts.
And since Netlist required 1-2 years and tens of millions of dollars to develop Hypercloud, it is unlikely that any serious competition to Hypercloud will appear for at least a year.
Like you, I have been thinking about Google’s founding principle and solemn commitment to “do no evil”. They appear to have violated their own values in their dealings with Netlist, so it will be interesting to see if Google redeems itself by compensating Netlist properly — eventually.
netlist,
Thanks also for your fast and detailed reply to questions 8 and 9.
I got a good laugh from your witty line about Google buying MetaRAM’s patents to avoid “appearing in court without pants on.”
I agree with you that Google’s recent purchase of patents by MetaRAM may help Google a little, but most of Google’s alleged misconduct occurred while it did not own MetaRAM’s patents. As you know, Google’s current ownership of MetaRAM’s patents will not give Google “retroactive” protection against Google’s alleged misconduct when it did not own MetaRAM’s patents.
So I also agree with you that Google appears to have knowingly and willfully infringed against Netlist’s legal rights — and therefore will eventually have to compensate Netlist to some degree. The extent of damages to Netlist and of compensation by Google is what the court will determine.
Also, the court will realize that Google did not invent anything related to MetaRAM’s patents, was not the original filer or owner of the patents, and only recently rushed to purchase MetaRAM’s entire list of patents to try to protect itself from its prior misconduct and current legal liabilities.
Under these circumstances, I doubt that the court is going to look very favorably on Google’s belatedly acquired, “second-hand” patents.
By the way, I also agree with your earlier doubts about the suspicious claims by MetaRAM that it sold only $37K worth of product and destroyed the rest of production (why was that, hmm?), and therefore, committed little or no infringement against Netlist.
Aside from wanting justice for Netlist (in court and in the market), I will be interested to eventually learn convincing explanations for many of the “mysteries” in this story.
Two corrections to my recent remarks:
1)It’s my understanding that MetaRAM claimed that it destroyed all of the products worth $37,000 that it sold, but which were never used commercially by the buyer (thought to be Google).
2)There is at least one serious competitor to Netlist’s “Hypercloud” product: Cisco. But Netlist’s product attaches directly to the memory, while Cisco’s product attaches to the motherboard. Apparently this difference gives Netlist’s product an advantage over Cisco’s product in performance.
If NLST is going after GOOG for “4-rank” usage, this is a JEDEC standard and plenty of other memory makers make 4-rank memory modules.
Or is it in some specific way that those do not infringe – or is it that they ALL infringe, it’s just that NLST has chosen the fight with GOOG (being most prominent and best player to get early resolution out of in court).
If so, that could mean JEDEC usage of NLST IP, and other memory module makers would have to fall in line if GOOG concedes ?
netlist,
If and when you can, would you please explain what you think the positive and negative effects on NLST would be if JEDEC adopts Netlist’s IP and Hypercloud technology as the JEDEC standard?
Thanks.
If and when you can, would you please explain what you think the positive and negative effects on NLST would be if JEDEC adopts Netlist’s IP and Hypercloud technology as the JEDEC standard?
I don’t know how something being a “standard” relates to something being “proprietary”. On the face of it JEDEC being a standards body just specifies a common way of doing something – and is a middle player to do that for a disparate and competitive group of companies.
It may not have anything to do with whether it is proprietary or not. Generally JEDEC would want to standardize on something that does NOT do something proprietary (to minimize costs of going with that standard).
In fact RMBS (Rambus) was accused of being part of early negotiations in standards setting process for DRAM and using that prior knowledge to patent stuff ahead of the standard process – in effect STRENGTHENING it’s hold on what would eventually become the standard. Essentially a way of herding competing manufacturers into a corner (having committed to a certain way of manufacturing) so it could squeeze out royalty payments later. In effect harming the whole purpose of the standards setting body – to make things easier (and cheaper) for the industry.
http://en.wikipedia.org/wiki/Rambus
July 30, 2007, the European Commission launched antitrust investigations against Rambus, taking the view that Rambus engaged in intentional deceptive conduct in the context of the standard-setting process, for example by not disclosing the existence of the patents which it later claimed were relevant to the adopted standard. This type of behaviour is known as a “patent ambush”.
Given this context it seems reasonable that JEDEC would wait before it finalizes a proposed standard – unless of course it is assured that the license fees related to that standard are going to be “reasonable” (by NLST).
From above link:
February 5, 2007, U.S. Federal Trade Commission issued a ruling that limits maximum royalties that Rambus may demand from manufacturers of dynamic random access memory (DRAM), which was set to 0.5% for DDR SDRAM for 3 years from the date the Commission’s Order is issued and then going to 0; while SDRAM’s maximum royalty was set to 0.25%. The Commission claimed that halving the DDR SDRAM rate for SDRAM would reflect the fact that while DDR SDRAM utilizes four of the relevant Rambus technologies, SDRAM uses only two. In addition to collecting fees for DRAM chips, Rambus will also be able to receive 0.5% and 1.0% royalties for SDRAM and DDR SDRAM memory controllers or other non-memory chip components respectively.
This would suggest the JEDEC CAN wind up in a position where they are pushing a standard which is heavily tied to one company’s IP – resulting in allied royalty payments.
So on the face of it – no, it would not harm NLST if JEDEC adopts NLST-related technology as a standard. In fact it would HELP NLST – since it would herd more folks into doing things that infringe NLST IP – thereby increasing the potential royalty collection by NLST in the future (once IP issues are resolved in court).
JEDEC NOT adopting NLST-related stuff as standard doesn’t help NLST – since it means the industry is doing something that is unrelated (and thus un-royalty-collectable by NLST).
netlist,
Thank you for your thoughtful, thorough reply, as is your style.
netlist,
thank you for for clarifying this complex issue. you seem to have an excellent grasp of technology as well as legal issues. I have a question that you might be able to shed some light on. Since netlist has to buy RAM on open market, how can you be competitive compared to DRAM manufactureres such as Elpida and Micron ?
Since netlist has to buy RAM on open market, how can you be competitive compared to DRAM manufactureres such as Elpida and Micron ?
I don’t know enough about this to comment – but it seems NLST is in similar situation as other memory module makers. Which include those that do not make their own memory chips:
STEC – Simple Tech
SMOD – Smart Modular
Also it seems these memory makers themselves can be buyers of NLST-like tech. For example Hynix (one of major memory chip makers) had licensed MetaRAM:
http://lynnesblog.telemuse.net/292
Feb 25, 2008
MetaRAM Busts RAMBUS Stranglehold?
Snake oil or salvation from former AMD CTO,
By Lynne Jolitz
…
MetaRAM’s big claim to fame is cost reduction — not for gadgets or laptops, but according to Fred Weber, CEO of MetaRAM, for “personal supercomputers” and “large databases”. And who is the big licensee for this so-called technology. Why, it’s Hynix of course, who announced they will make this lumbering memory module. They claim it will be lower power. I think I’d like an independent evaluation on this point, but it will probably be lower cost. Is it worth it?
http://www.digitimes.com/news/a20080820PR200.html
Hynix demonstrates DDR3 R-DIMM using MetaRAM technology at IDF
Press release, August 20; Esther Lam,
DIGITIMES [Wednesday 20 August 2008]
…
Intel will demonstrate the world’s first 16GB 2-rank DIMM from Hynix, using the MetaRAM DDR3 chipset at IDF. Intel will also demonstrate a server with 160GB using Hynix DDR3 R-DIMMs and Meta SDRAM technology, Hynix said.
So memory chip makers also DO deals with companies like NLST – in order to build more complicated modules (that include more than just memory chips).
Here is a list of memory chip manufacturers:
http://www.interfacebus.com/memory.html
This article lists the dominant memory chip makers (not the same as memory module makers):
http://news.cnet.com/8301-13924_3-10057284-64.html
October 3, 2008 4:00 AM PDT
Memory chipmakers face survival test
by Brooke Crothers
Hynix – in financial trouble due to extended drought in memory during last 2 years (low prices, low margins). However it is linked to S.Korean government and can get bailout.
Samsung
Qimonda AG (Infineon) – “ailing”
MU – “largest U.S. maker of memory”
question:
Since netlist has to buy RAM on open market, how can you be competitive compared to DRAM manufactureres such as Elpida and Micron ?
So short answer is that companies like NLST have to buy memory chips from those companies, but if those companies want to make memory modules they have to license from companies like NLST – or buy buffer chips (like they were planning to do from Inphi, and earlier MetaRAM).
From the chart they show, you can see that the companies which license their technology (i.e. their IP – intellectual property) are the ones with greatest gross margins.
http://seekingalpha.com/article/16968-gross-margin-kings-memory-chip-manufacturers
Gross Margin Kings – Memory Chip Manufacturers
by: Robert Zenilman September 15, 2006 | about: CY / SNDK / MU / SFUN / RMBS / IDTI / ISSI / MOSY / RMTR / SSTI / STEC / STAK
Rob Zenilman submits: Within a specific sector, gross margins can differ dramatically, due to the different nature of their businesses. Among the memory chip manufacturers tracked here, gross margins ranged from 24.8% (STEC) up to 85.7% (RMBS). The companies that have drastically higher gross margin are what I like to call “gross margin kings”.
What separates out the companies with the four highest gross margin rates is that they earn money by licensing out their technology. 88% of Rambus’ revenue is from licensing, 100% for MoSys (MOSY), 56% for Saifun Semiconductors (SFUN), 100% for Virage Logic (VIRL) and 25% for Staktek Holdings (STAK).
…
However, having high gross margins is no guarantee of profitability. Of the four companies here with gross margins over 70% (and that derive most of their revenue from licensing) – only Rambus has a positive P/E of 62.84.
Can anyone here provide any details about the kind of information that NLST CEO Hong will probably discuss in his “investor presentation”? Thanks.
Netlist to Present at the Needham Growth Stock Conference in New York City
IRVINE, Calif., Jan. 6 /PRNewswire-FirstCall/ — Netlist, Inc. (Nasdaq: NLST) today announced that CEO C.K. Hong is scheduled to make an investor presentation at the Needham 12th Annual Growth Stock Conference on Thursday, January 14, at 2:30 pm Eastern Time. The conference is being held January 12-14, at The New York Palace in New York City.
The presentation will be accessible by live webcast in the Investors section of the Netlist website at http://www.netlist.com. A replay of the webcast will be available on the Netlist website for 30 days.
Another twist that makes things even more interesting here.
According to the USPTO Assignment database, MetaRAM has licensed the use of the method in patent 7,472,220 to Netlist, and Netlist has licensed the use of the method in patent 7,289,386 to MetaRAM.
Memory module decoder
Interface circuit system and method for performing power management operations utilizing power management signals
It appears that the execution date on the conveyances was December 21, 2009, and the recording of the assignments took place on January 4, 2009.
The ‘386 patent appears to be at the heart of some of the litigation between Google and Netlist, and between Netlist and MetaRAM. Part of a settlement between Netlist and MetaRAM? I don’t know for certain. Might be interesting to listen in to the live webcast that netlistfan mentioned in the comment above this one.
This is seriously interesting. Thanks !!
USPTO assignment search page – entering patent number to search:
http://assignments.uspto.gov/assignments/?db=pat
Reveals that:
7472220 – MetaRAM license to NLST ..
http://assignments.uspto.gov/assignments/q?db=pat&qt=&reel=&frame=&pat=7472220&pub=&asnr=&asnri=&asne=&asnei=&asns=
7289386 – NLST license to MetaRAM ..
http://assignments.uspto.gov/assignments/q?db=pat&qt=&reel=&frame=&pat=7289386&pub=&asnr=&asnri=&asne=&asnei=&asns=
So a cross licensing arrangment – and this fits in with recent withdrawal of cases by both parties in NLST vs. MetaRAM and MetaRAM vs. NLST (as reported above).
The USPTO assignment info for each patent shows:
Conveyance: LICENSE (SEE DOCUMENT FOR DETAILS).
Compare with the patents that were sold to GOOG (as reported above) – for example:
7580312 – Power saving system and method for use with a plurality of memory circuits (
http://assignments.uspto.gov/assignments/q?db=pat&qt=&reel=&frame=&pat=7580312&pub=&asnr=&asnri=&asne=&asnei=&asns=
These have:
Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS).
That is, the “ownership” (ASSIGNORS INTEREST) is transferred to GOOG.
In an earlier post I had wondered HOW NLST allowed MetaRAM to sell it’s IP – since NLST was potentially due money (in case of eventual win in court against MetaRAM).
Now it seems something similar to that DID happen – i.e. either:
- NLST signalled to MetaRAM to keep certain IP in hand (while it could sell other stuff it was not interested in – like the IP on “stacked memory” which NLST has claimed has serious asymmetry issues – search above for “stacked”).
- MetaRAM recognized which of it’s IP would be valuable in eventually getting NLST off it’s back, and retained THOSE patents.
The date of assignment for patents sold to GOOG are 09/11/2009:
Assignor: METARAM, INC. Exec Dt: 09/11/2009
While the ones licensed to NLST are dated 12/21/2009:
Assignor: METARAM, INC. Exec Dt: 12/21/2009
So MetaRAM KNEW as early as 09/11/2009 that it would not need THOSE patents – and which ones NOT to sell to GOOG (!).
The other two alternatives are left unanswered:
- why NLST did not insist that all of MetaRAM’s IP be given (or sold) to NLST – maybe NLST wasn’t interested in all of it ?
- why GOOG didn’t overpay to buy ALL of MetaRAM’s IP – including the patents that MetaRAM retained, or did MetaRAM decline since it needed those to fend off NLST for an eventual settlement, so it’s bankruptcy proceedings could proceed unhindered.
- what happens to the patents MetaRAM has retained (not sold to GOOG) – like the cross-licensing patents. Can NLST claim interest in who gets the patents in bankruptcy proceedings since it is (now) a licensee ?
As well as this question:
- does MetaRAM hold other patents that it has NOT sold to GOOG ? Would be hard to believe GOOG would not want the most NLST-specific ones but were there MetaRAM patents that GOOG did not buy – which MetaRAM is still holding on to ? Why – since there is little value in retaining those patents – as a company, those assets will have to be liquidated during bankruptcy.
As conjectured above – the NLST/MetaRAM mutually agreed dismissal of cases – NLST vs. MetaRAM and MetaRAM vs. NLST bode well for the strategy the NLST lawyers were adopting. One of conciliation with a defeated enemy in order to positiong better for the fight against the larger one:
- since not much extractable from a bankrupt company, NLST can at least make sure info from discovery etc. in these cases is not available to help GOOG in the NLST/GOOG cases.
Now it seems NLST DID get something from that settlement as well – broader coverage thanks to help from MetaRAM patents.
searching the USPTO assignment search page – entering METARAM as “Assignor”, then clicking the “METARAM, INC” name that appears:
http://assignments.uspto.gov/assignments/q?db=pat&asnrd=METARAM,%20INC.
shows the patents that MetaRAM has assigned to others.
http://assignments.uspto.gov/assignments/q?db=pat&asned=NETLIST,%20INC.
The patents that assigned to NLST. Only the 7472220 patent appears for Netlist.
MetaRAM patents being transferred to GOOG number around 50 + 7 (patents or filings).
http://assignments.uspto.gov/assignments/q?db=pat&asned=GOOGLE%20INC.&page=15
quote:
So MetaRAM KNEW as early as 09/11/2009 that it would not need THOSE patents – and which ones NOT to sell to GOOG (!).
Another possibility is that MetaRAM sold off it’s IP without too much thought – but because they were being sued by NLST, and they were in turn retaliatory-suing NLST based on 7472220 patent, they HAD to retain that. So everything else went on sale, but they had to keep that in hand in order to retain some standing in court case against NLST (which was their counterweight to NLST’s suit against them).
When MetaRAM/NLST settled, this patent was lying around, so it became part of the eventual settlement – i.e. cross-licensing between the two.
So maybe this is the (simpler) interpretation.
Question is, why did MetaRAM license the NLST patent then ? Or is it standard procedure to cross-license this way – or is this standard “closure” to the case by making each party “whole” by giving them the license to patent which nullifies the case (so for instance the same type of suit cannot be filed again – either by NLST against MetaRAM or by MetaRAM against NLST) – and has nothing to do with whether MetaRAM intends to use the NLST patent (probably not).
Bill,
Thanks for making and sharing your latest discovery. Very interesting indeed.
And netlist,
Thanks for building on Bill’s discovery by sharing your related discoveries and by thinking through the implications and possibilities.
Great detective work, you two. The mystery slowly unfolds…
Thanks, netlist and netlistfan,
I’m very thankful for the comments and questions and information being shared here by everyone.
I’m still wondering how the licensing of technology to MetaRAM might affect the litigation between Netlist and Google, if at all.
from Briefing.com this evening:
“4:49PM NetList files for $30 mln mixed securities shelf offering”
NLST closing price today was $5.21. Now it’s $4.82 after-hours. Ouch!
My guess is that NLST will trade in a range between $4.50 and $6.50 for 3 to 6 months, and won’t rise steadily or significantly until the lawsuits are settled, the OEMs test and approve HyperCloud, the latter gets certified, and JEDEC decides the standardization question.
Over the next 1 to 2 years, I think NLST and HyperCloud will prosper nicely. But tonight’s share-dilution (on top of the many other obstacles to NLST that I just mentioned) will probably suppress the share price for several months.
Other opinions?
http://www.netlist.com/investors/SEC_filings.htm
The above link will take you to netlist.com, where you can download NLST’s S-3 filing dated today, 1-11-2010, in the format that you prefer. It confirms that NLST has filed with the SEC it’s plan to sell $30 million in mixed securities in a “shelf offering,” which may be sold over an unspecified duration.
For an explanation of the “dilution”, please read the following on the NLST yahoo board (poison-pill provisions possibility), since with 10M shares, a possible hostile takeover by GOOG would not be out of the question:
http://messages.finance.yahoo.com/Stocks_%28A_to_Z%29/Stocks_N/threadview?m=te&bn=51443&tid=11805&mid=11887&tof=2&frt=2#11887
Re: OFFERING, SELL SELL SELL .. part1
http://messages.finance.yahoo.com/Stocks_%28A_to_Z%29/Stocks_N/threadview?m=te&bn=51443&tid=11805&mid=11888&tof=1&frt=2#11888
Re: OFFERING, SELL SELL SELL .. part1
netlist,
Your “poison pill” hypothesis seems very plausible to me too. Netlist is especially wary of Google right now, because of Netlist’s lawsuits with Google, but Netlist is also probably wary of being vulnerable to a “premature” buy-out or hostile take-over from HP, Dell, IBM, Cisco, or any number of bigger companies. And almost everyone is bigger and richer than Netlist.
Since Netlist’s new product, HyperCloud, has real potential to be a blockbuster that could take Netlist’s share price to fantastic heights (and since Netlist has worked hard and long to remake itself, and now hopes to finally achieve the potential that they never enjoyed since their IPO in 2006), I think that Hong and Netlist’s other big inside owners must really want Netlist to have a chance to succeed and grow on its own, and not have its independent life “taken away” prematurely in what is really its infancy. A premature buy-out or take-over would be emotionally painful to Netlist management and employees, I think.
In addition to the emotional aspect, there is the financial aspect: Hong et al obviously would prefer to sell their shares in a few years at $500, not now at $5!!!
So now seems like a perfect time to obtain the legal right to sell up to $30 million worth of securities, in the manner and timing of Netlist’s choosing. Why? First and most important, for self-defense against Google (and others), as you rightly point out. And second, because Netlist’s share price has been range-bound (and likely will continue to be) until the obstacles I mentioned a few comments above get resolved. This S-3 filing would cause a price drop at almost any time, so it’s best get it over now, when the price is likely to be trading sideways for another 3 to 6 months anyway. Then, when Netlist has removed the obstacles that are currently in its way, and the orders come in and the payments come in, Netlist will likely be clear for take off.
Lastly, I just want to highlight that Netlist’s S-3 filing is not an offer to sell shares, and it’s not an obligation to sell shares — it will be (once approved by the SEC) just an option to act that sits on the “shelf,” waiting for Netlist to use if and when Netlist needs or wants to use it.
Thanks again, netlist and netlistfan,
There does seem to be the potential for Netlist to grow into a remarkable company, but they also have to appear to be an attractive target at this point. If the filing can help them, then it sounds like a good move to take. I wasn’t sure what kind of reactions this post might have when I first posted it, but I didn’t expect the mystery to start unraveling the way that it has. Thanks again, for keeping this post up to date with the latest news.
Today’s call was very depressing. I have accumulated quite a bit and was hoping to hear about OEM
qualifications in today’s Needham talk. All I heard was 6 months to revenue and no concrete OEM
announcement nor any talk of lawsuit settlement.
Netlist and others – Can you help me understand why it takes so long for qualification ? Also are
the lawsuits preventing quick adoption of hypercloud ?
Seems to have become hype-o cloud from hypercloud !
joeq,
I share your discouraged feeling and your financial pain. I agree with you that the NLST Investor Presentation was very disappointing. So much so, that I sold all my shares of NLST, at a painful-but-bearable loss, so that I could “let go and move on.” I hope to make the loss back elsewhere.
Like many others, I jumped too soon and too much into NLST because of all the great descriptions of its new product, HyperCloud, in November. But after watching a lot of my money drop and drift for two long months (while other stocks are rising), the thought of having my money falling or flat for another 6 months (or more) prompted me to sell, and switch to other stocks.
I still think NLST and HyperCloud have great potential IF everything works out well. But will it? And when?
Here is a “top 10″ list of my concerns regarding NLST:
1) Is HyperCloud truly the huge technological advance that the “hype” has claimed it is?
2) Does HyperCloud work exactly as promised, or will tests by OEMs require adjustments and delays?
3) How long will it take for OEMs to finish testing HyperCloud, and will they approve it? (Netlist Investor Relations doesn’t know.)
4) How long will it take for HyperCloud to receive full certification? (IR doesn’t know.)
5) How long will it take for OEM’s to place big orders and for NLST to start mass production? (IR doesn’t know.)
6) How long will it take for NLST to start receiving big sales and big payments? (NLST “thinks” 6 months, but based on all of the unknowns, I think 6 months is just a guess, and it could take longer.)
7) How long will it take for the lawsuits between NLST and GOOG, and NLST and Inphi, to be resolved (and will NLST win, or benefit from, these lawsuits)? Nobody knows.
9) What are NLST’s plans for their recent $30 million S-3 “shelf” filing, and do these plans include protection against a possible hostile takeover (netlist’s “poison pill” idea) or premature takeover (my idea)? (IR doesn’t know.)
10) Will NLST be able to become a successful company on its own (after struggling for 3 years since its IPO), or will NLST get bought out and merge into a much larger corporation? No one knows.
I want to emphasize that these are my concerns and understandings regarding NLST. Anyone is free to call Netlist Investor Relations’ Ms. Jill Bertotti at (949)474-4300, or to email her at jill@allencaron.com, and ask her your own questions.
The are no doubt additional unknowns and concerns regarding NLST — but these 10 alone seem likely to make an investment in NLST take 6 months or longer to significantly pay off.
For example, if the economic recovery in the U.S. and the world is slower than expected, or suffers a serious setback, tech spending on products like HyperCloud will likely be lower and slower.
I still wish NLST (and NLST investors) all the best, and I will watch to see if it eventually takes off (in price and performance), but I won’t buy it again unless and until it proves itself to be growing quickly and steadily.
BILL, thanks for starting this very helpful thread, and for your great discoveries and comments.
netlist, thanks for your especially useful information, prompt replies and thorough comments, many links, and thinking through of implications.
And thanks to everyone who commented and contributed to this thread.
joeq, I hope my reply helps. Maybe others can also answer your questions. I wish you the best.
Best regards everyone! Maybe I’ll see you later. Hope you have a healthy, happy, and prosperous new year!
oops! On number 9 of the above list, I meant to type “premature buy-out” not “premature takeover”.
Thanks for the smile, Bill. :>)
Just 5 more (I promise) :>)
11) When will JEDEC decide whether or not to adopt NLST’s IP and HyperCloud as the industry standard — and how will NLST be affected either way?
12) How well will NLST compete against much bigger and richer competitors (like CSCO)?
13) Are tiny NLST’s production capacities too small to keep up with a potentially huge demand by giant companies like HP, DELL, and IBM?
14) Does HyperCloud truly have a competitive edge over other products, and if so, how long and how much will it be profitable for NLST?
15) How long will it take before technological innovations by other companies advance ahead of NLST’s HyperCloud?
OK, I’m done. Good luck all!
Thanks, joeq and netlistfan.
Great questions, and a lot to think about. The issues involving netlist, metaram, and Google here arethe type that affect many tech companies. Can the small startup survive to become a large one? How can innovation in technology, market pressures, standards bodies, and a need for that innovative technology influence potentially shape our futures?
I’m not sure in this particular instance, between these particular parties. I’m not sure that I’ve seen Google purchase patents from another company before in what might be characterized as a defensive maneuver, if that is what in fact took place. That’s why I wrote about it in the first place. The cross-licensing of patent processes between Netlist and MetaRAM was a surprise as well.
I don’t have any stocks from any of the companies involved, but I think there are some pretty large implications behind what happens between the companies involved for large scale data centers, and search providers like Google. I’ll be following along, and very thankful for all of the sharing of information within the comments on this thread.
I hope you all have a wonderful new year as well. Thanks, again.
Note GOOG does not have the patent that MetaRAM was suing NLST with.
So the MOST overlapping patent that MetaRAM could think of is now licensed by NLST.
Even if GOOG were to license NLST patents now, it would not undo years of infringement (and treble damages if wilful).
quote:
Today’s call was very depressing. I have accumulated quite a bit and was hoping to hear about OEM
qualifications in today’s Needham talk. All I heard was 6 months to revenue and no concrete OEM
announcement nor any talk of lawsuit settlement.
Netlist and others – Can you help me understand why it takes so long for qualification ? Also are
the lawsuits preventing quick adoption of hypercloud ?
Seems to have become hype-o cloud from hypercloud !
NLST yahoo board:
http://messages.yahoo.com/?action=q&board=nlst
Many people have said on that board that OEM qualification does take time – maybe others can shed light on whether 3-6 months is normal.
Here is an overview of Needham presentation:
http://messages.finance.yahoo.com/Stocks_%28A_to_Z%29/Stocks_N/threadview?m=te&bn=51443&tid=12087&mid=12087&tof=1&frt=2#12087
netlist provided lots of good info in the last link to the NLST Yahoo Board that he posted just above. Scrolling far down on that Yahoo Board thread, the following opinion by “herbieray20…” that NLST might hit $2 or $3 and take a full year to take off seemed worth posting here.
netlist rightly replied that NLST’s share price might jump earlier than that, and by a lot, if, for example, the lawsuits settle sooner and favorably.
Lots of scenarios are possible, but most current opinions state that it will most likely take 6 to 12 months for NLST to take off in a sustained way.
Here’s the quote to consider:
“This [Netlist's HyperCloud] will take at least a year to bear fruit, with lots of ups and downs in the stock price.
As a retired engineer in the server area, I have lots of experience with product development cycles, evaluation of chips sets, etc. I would be very surprised if this product has tangible effects on revenues/profits for at least 4 quarters, and then who knows what the competition will have done..?
My prediction for the next year is consolidation between $2 and $3 at best.
Just my opinion.”
[by herbieray20... on NLST Yahoo Board, 1-16-10]
NLST has answered Inphi’s complaint in Inphi vs. NLST.
Among the usual boilerplate, one comment sticks out. NLST claims that Inphi cannot claim “injunctive relief”, because Inphi is subject to a “compulsory reasonable and non-discriminatory (RAND) license requirement pursuant to Inphi’s membership in JEDEC and activities therein in connection with these patents”.
Netlist,
Based on your statement,
Among the usual boilerplate, one comment sticks out. NLST claims that Inphi cannot claim “injunctive relief”, because Inphi is subject to a “compulsory reasonable and non-discriminatory (RAND) license requirement pursuant to Inphi’s membership in JEDEC and activities therein in connection with these patents”.
Does this mean that Netlist is infringing Inphi patents in its product and trying to use JEDEC as shield ? Clever move by netlist. Wonder if they infringe other JEDEC patents.
NLST sued Inphi (NLST vs. Inphi) and later Inphi retaliated with Inphi vs. NLST.
Inphi is lacking any serious IP in the area. Their retaliatory suit has variously been reported as “frivolous”.
I posted that to support that general impression that Inphi’s suit is a kneejerk suit crafted without thought.
Netlist today announced that the United States Patent and Trademark Office issued to Netlist Patent No. 7,636,274 for its invention related to memory load isolation and memory rank multiplication, and Patent No. 7,619,912 for its invention related to memory rank multiplication.
Hi McDee,
Thanks for citing those. From what I understand, they were announced because they have something to do with Netlist’s HyperCloud memory modules.
I didn’t do a rundown of Netlist patents here, but I looked through a number of them. These weren’t patents that were just published, but they are fairly recent. The newest of the two was granted in December. The press release, from January 19th, tells us:
In GOOG vs. NLST (now consolidated with NLST vs. GOOG at request of both GOOG and NLST), GOOG sacks whole legal team of Fish and Richardson.
From filing dated Jan 21, 2010:
Please take notice that plaintiff GOOGLE INC., hereby substitutes Timothy T. Scott, Geoffrey M. Ezgar, and Leo Spooner III of the law firm of King & Spalding LLP as attorneys of record in the place and stead of David J. Miclean, Howard G. Pollack, Jason W. Wolff, Juanita
R. Brooks, Robert J. Kent, Jr. and Shelley K. Mack of the law firm of Fish & Richardson, located at 12390 El Camino Real, San Diego, CA 92130 and 500 Arguello Street, Suite 500,
Redwood City, CA 94063.
What is interesting is that the new law firm King & Spalding is NOT KNOWN for patent or intellectual property litigation.
That is, they are not known for being “trial lawyers” or “intellectual property” lawyers, but are considered #2 in country for arbitration (yes, ARBITRATION) !
If you look at their practices:
http://www.kslaw.com/portal/server.pt?space=KSPublicRedirect&control=KSPublicRedirect&CommunityId=227&ui_pa_sort=group&ui_pa_display=
They surely DO have practice (like all large firms) in:
- Licensing
- Patents
- Trade Secrets & Non-Compete Litigation
- Mergers & Acquisitions
HOWEVER, they are not a small tight outfit that just deals with “intellectual property” or patent defence.
If you have all the money in the world (GOOG) to protect yourself in an IP-related lawsuit, you would get the best lawyers for that (if you were intending to contest on IP grounds).
However if you were thinking of getting the best deal – you would get the best company in arbitration.
In terms of rankings they are ranked VERY HIGH in arbitration, but are not even MENTIONED in rankings for patent or intellectual property litigation:
http://www.kslaw.com/portal/server.pt?space=KSPublicRedirect&control=KSPublicRedirect&PressReleaseId=3375
King & Spalding Lawyers Earn 26 Rankings As Leaders In Their Fields and 18 Practice Areas Recognized In Chambers Global 2009
04 Mar 2009
Historically not exactly famous for patent litigation either:
http://en.wikipedia.org/wiki/King_&_Spalding
Notable Mandates
* Counseled Sprint Corp. in its sale of Sprint Publishing & Advertising, the directory publishing business to RH Donnelly Corp. for $2.23 billion. The transaction was announced in 2002 and closed in 2003.
* Represented JDN Realty Corp. in its $1.02 billion sale to Developers Diversified Realty Corp. for a combination of cash and stock. The deal closed in 2003.
* Advised Credit Suisse First Boston as financial adviser to Graphic Packaging in its $3 billion merger with fellow forestry and paper company Riverwood Holding in 2003.
* Represented Caremark Rx in its $6 billion merger with AdvancePCS in 2004.
* Counseled Lockheed Martin in its $2.4 billion acquisition of Titan Corp., in a mixed cash and stock offer which closed in 2004.
* Advised SunTrust Bank in its $6.98 billion purchase of National Commerce Financial Corporation in 2004.
* Legal counsel to Novelis, a Canadian-based aluminum company in its purchase by Hindalco Industries Ltd., an Indian steel company for total consideration of $6 billion. The transaction closed in 2007.
Link for #2 ranking for arbitration:
http://www.kslaw.com/portal/server.pt?space=KSPublicRedirect&control=KSPublicRedirect&PressReleaseId=3491
King & Spalding Earns No. 2 Spot in 2009 Arbitration Scorecard
26 Jun 2009
NEW YORK, June 26, 2009—King & Spalding, a leading international law firm, earned the No. 2 spot in Focus Europe’s 2009 Arbitration Scorecard, a worldwide ranking of law firms by number and size of arbitrations. The rankings were published in the summer 2009 issue of Focus Europe, an annual supplement to The American Lawyer.
Focus Europe noted that King & Spalding is among “the first tier of arbitration law firms.” The firm appeared as arbitration counsel in a total of 25 arbitrations included in the 2009 Arbitration Scorecard.
King & Spalding was also included in Focus Europe’s list of Twelve Big Awards for its representation of three of the listed awards: Azurix Corp. v. Argentine Republic ($165 million), Sempra Energy International Co. v. Argentine Republic ($128 million) and Enron Creditors Recovery Corp. and Ponderosa Assets, LP v. Argentine Republic ($106 million).
The 2009 Arbitration Scorecard covers international arbitrations (not limited to Europe) that were active in the years 2007 and 2008. It is based on nearly 250 cases—all either commercial disputes with stakes of at least $500 million or treaty disputes with stakes of at least $100 million.
Among the survey’s list of disputes, King & Spalding served as claimant’s counsel in one investment treaty arbitration and three contract arbitrations in which at least $1 billion was in controversy.
King & Spalding is ranked among the leading international arbitration practices in the world. Chambers USA 2009 says, “This powerhouse continues to impress with its international arbitration practice, attracting praise for its depth of knowledge and client service,” an accolade that echoes from the publication’s 2008 edition, which described the firm as “currently one of the arbitration arena’s biggest success stories.” King & Spalding was nominated for a Chambers USA Award for Excellence 2009 in international arbitration and was a finalist in 2008. It also features among the world’s leading international arbitration practices in Chambers Global 2009. And the 2009 edition of The Legal 500: US describes King & Spalding’s international arbitration team as “”simply terrific.”
About King & Spalding
King & Spalding is an international law firm with more than 880 lawyers in Abu Dhabi, Atlanta, Austin, Charlotte, Dubai, Frankfurt, Houston, London, New York, Riyadh (affiliated office), San Francisco, Silicon Valley and Washington, D.C. The firm represents half of the Fortune 100 and in Corporate Counsel surveys consistently has been among the top firms representing Fortune 250 companies. For additional information, visit http://www.kslaw.com/.
From an interview of GOOG’s NEW new lead lawyer (Timothy Scott):
http://apps.kslaw.com/Library/publication/Zimmer%20Scott%20Met%20Corp%20Counsel%20Jan%202010.%20pdf.pdf
Top Litigators Manage Firm’s California Of?ces
Page 32 The Metropolitan Corporate Counsel January 2010
The Editor interviews Timothy T. Scott
and Donald F. “Fritz” Zimmer, Jr.,
King & Spalding LLP.
…
Editor: To what extent has the cost of e-discovery contributed to the increase in litigation expense?
Scott: You can’t even litigate a simple thing without the discovery cost dwarf- ing everything else in the case. If a com- plaint in a securities class action case survives a motion to dismiss, the cost of collecting and reviewing all the elec- tronically stored data creates an impetus to settle the case before even getting to the merits in order to avoid the cost of e- discovery.
Zimmer: The invention of email has done more to bene?t plaintiffs’ counsel than any other development of the last 20 years. I have colleagues on the plain- tiffs’ side of the bar who tell me they thank their lucky stars that email was invented.
…
Not only has GOOG suffered from discovery (on hardware side) – by having to reveal it’s GOOG server to NLST (and thus proving use of “Mode C” in GOOG servers).
It will now have to contend with NLST riffling through GOOG e-mails as well – as the trail is examined of who said what at GOOG and when they knew it.
The trial will examine the role of GOOG employees (mentioned in earlier court dockets and posted some days back – see above):
Rick Roy – “involved in the development of the accused 4-rank FBDIMMs and who participated in meetings with Netlist concerning it’s patented technology”
Andrew Dorsey – same as above
Rob Sprinkle – same as above
And god knows what else THAT “discovery” of GOOG internal e-mails will reveal.
The situation is strongly in favor of GOOG settling the case.
- for reasons mentioned above i.e. legal issues and “discovery” problems for GOOG (a loss will also not help their “do no evil” image – and image is essential for GOOG i.e. consumer trust since that is part of the GOOG business model.
- for reasons that alternatives to NLST are at a standstill.
Alternatives to NLST – there are none so far.
MetaRAM is out of business (NLST now licensee of patent MetaRAM hoped to use against NLST).
Inphi which owns no IP in this area and was just hoping to sell a buffer chip is embroiled in legal dispute with NLST.
Meanwhile memory module makers like Micron are waiting for JEDEC to arrive at a standard so they can start moving forward. Inphi is also awaiting that, so memory module makers will use it’s buffer chip (now that MetaRAM – who was earlier partnered with many memory module makers – is gone).
But while NLST/GOOG dispute (being the most prominent) is not resolved, and the licensing status of the infringing of IP in JEDEC proposed standard (like JEDEC FBDIMM “Mode C” proposed standard) are not clear, JEDEC cannot move forward with standardizing (since that will benefit NLST as IT’S IP is made into standard so many people can start doing that – meaning more infringers and people to collect damages from by NLST).
In any case JEDEC procedure is to see that they not infringe proprietary stuff – and if it does to negotiate licenses itself (or by it’s members) to allow the standard to move forward. After all the creation of “the standard” is to encourage standardization – which will lead to lower overall costs to it’s members. JEDEC cannot blindly adopt something as standard that still has IP and licensing issues unresolved.
For this reason – we will see a DROUGHT of memory in this space. NLST being the only unencumbered player – both as creator of the memory, and the manufacturer will be in an unenviable position – as there is no other player who can deliver what NLST can deliver.
Plus it is not like NLST HyperCloud is a totally new form factor – it is plug and play and requires no modification to BIOS. This means it is a “no brainer” for an OEM server manufacturer to incorporate NLST HyperCloud since nothing else is available and there is no “cost” to doing this (i.e. “how can we lose”).
In addition, all this is timed to coincide with the much reported server upgrade cycle (since there is a lot of pent up demand as there were fewer upgrades/purchases in last 2 years due to economic uncertainty and the upgrade cycle is now beginning – memory price improvement etc.).
And you have OEMs in a crunch – they cannot avoid using NLST.
Meanwhile memory module makers will be getting impatient. As they will miss the upgrade cycle (at least in this area of data center upgrade/cloud computing expansion). They will be under pressure to negotiate some licensing deals with NLST.
Note that while many memory module makers have done deals with MetaRAM in the past, they have NOT been prosecuted by NLST (partly to limit it’s legal expenses perhaps – and partly because these people are all potential customers).
GOOG also will perhaps also be under the most pressure – with ever expanding hardware needs (GOOG being a big user of memory-loaded systems – for which the NLST HyperCloud solution is most appropriate) GOOG will be in a crunch as well, if it cannot upgrade it’s systems for lack of non-infringing solutions.
In addition, note that GOOG – for the possibility of wilful infringement (since GOOG had discussed with NLST – then went ahead and violated NLST IP), could face treble damages in court (if case goes through).
So pressure is on GOOG – to settle. But because memory/server expansion is such a big part of it’s business, GOOG loses every month that it delays – every month that standard/legal memory modules are NOT available to sate the growth nees of GOOG server expansion.
So the time clock is clicking for most of these players, and that makes the GOOG vs. NLST/NLST vs. GOOG cases unlike a traditional IP infringement suit – since there are time issues as well which are NOT in favour of GOOG.
Hi Netlist,
Thanks for the updates and observations on the legal representation in the Google vs. Netlist litigation. There do seem to be some factors involved that point more towards a settlement than prolonged litigation. I guess we wait and see.
Netlist,
Brilliant analysis. Maybe there will be some money after all. Any thoughts on Google settlement in terms of
dollars ? How much can we expect ? Do you think Inphy will also settle and any guess on how many dollars
can we expect out of them ?
I do not know what the difference is between GOOG using 4-rank (for which “Mode C” is a smoking gun) and the other memory module makers who are making 4-rank memory. Whether they are violating NLST IP as well.
It is possible that they are – except that NLST has chosen to not fight them right now – and has gone against GOOG first (low legal resources and also that the memory module makers could be allies later).
quote:
Maybe there will be some money after all. Any thoughts on Google settlement in terms of dollars ? How much can we expect ? Do you think Inphy will also settle and any guess on how many dollars
Trying to pin down the knowns – and keeping in mind the constraints i.e. like what we know of GOOG psychology, their business model and how they hope to behave to retain customer trust etc. ..
My guess is as part of settlement, GOOG will want no attribution of guilt for starters (to avoid pollution of “do no evil” motto). To achieve that they will be willing to concede in other areas i.e. monetarily.
GOOG can pay and walk away. But situation is not that simple – there is a reason it was infringing NLST IP – this is exactly what GOOG needs for it’s servers.
NLST HyperCloud is designed precisely for GOOG type situations (i.e. increases speed for memory-loaded servers – apart from the cost and power advantages).
So GOOG has to make sure that it can negotiate a path for itself as well (so GOOG servers are not shut down). So maybe the carrot will be a contract for use, or licensing terms to protect existing GOOG usage.
Because of the constraints above, there will have to be a transition from acrimonious to congenial. GOOG knows it can’t just walk away from NLST even after throwing money at it – it will have to buy memory or license from NLST in the future even if they were not personally in litigation.
Therefore I suspect a change in attitude at GOOG – the change in law firm already changes the faces that NLST lawyers meet – thereby allowing discussion in a different direction (as I posted above, the new GOOG law firm is #2 in country for ARBITRATION, and not particularly famous for IP litigation).
The effect of that will be multiplicative for NLST – concession from GOOG will be validating for NLST. And GOOG may understand that it has that value just by acknowledging validity of NLST IP – is a signal to other players to fall in line (if GOOG the gorilla is acknowleding NLST IP validity).
I would not expect GOOG to take a share in the company – since insiders maybe careful at this stage. Plus they may need to remain neutral in order to be a trusted supplier to whole range of consumers (which include many cloud computing competitors of GOOG).
Regarding Inphi – maybe they will settle for a small payment. They probably haven’t sold that many buffer chips (which would only have been used if JEDEC finaled the standard). So maybe there won’t be any great damages.
Don’t see any real synergies between Inphi/NLST, so maybe a simple cash payment or a slap on the wrist.
Inphi holds no IP in this area, yet was trying to step into MetaRAM’s shoes after that company went bankrupt. MetaRAM was the darling of Intel and other memory module makers – who were using their buffer chips. Now Inphi was hoping to do the same (except without any IP) – mainly banking on JEDEC/module-makers to deal with the IP issues. However NLST didn’t go after those, but went directly for Inphi for IP infringement.
Argument for early GOOG/NLST settlement:
GOOG also will understand certain inherent advantages with an early settlement.
However superficially one would not expect the settlement to occur much before the 3-6 months for OEM qualification (Needham conference audio) since GOOG knows NLST will not be manufacturing in volume until then – so no hurry.
On the other hand, there maybe a whole process for internal qualification at GOOG which does a lot of custom solutions within GOOG – and they may want to “join the program” earlier so they can also give feedback to NLST (along with the other OEMs like HP, DELL).
This type of thinking would suggest a much earlier settlement, where early resolution is beneficial to GOOG, rather than delaying settlement (achieves nothing – have to still pay, and are in worse negotiating position, and are behind in OEM qualification roadmap).
In any case, GOOG founders may be of the opinion that to “keep it simple” – i.e. if it IS decided that they have to settle eventually, then to settle EARLY (and remove the distraction), and instead use the time to forge new relationship with NLST and to get in early with qualification of the new memory.
If this reading is correct, we may see a settlement far earlier than the 3-6 OEM qualification period.
Some comments on eventual JEDEC/NLST negotiations:
JEDEC is waiting for legal clarification, since it’s proposed standard falls awry of NLST IP. Since JEDEC standard is meant to make things easier for manufacturers, they would require favorable licensing terms from NLST before they could finalize the standard (and advocate it to manufacturers).
Since GOOG is the bigger player (and the decision is influential for others), I doubt NLST would bother dealing with a JEDEC deal before the GOOG deal.
After GOOG/NLST resolution, we may see JEDEC negotiating for reasonable terms of licensing with NLST.
Since NLST memory is plug and play and requires no BIOS updates, there is LESS need by OEMs for JEDEC standardization for this. In fact GOOG and others will not need JEDEC approval to start using NLST memory. This would have been different if it required changes to BIOS, motherboard – in that case there would be a need to have some standardization about how those changes should be made.
But as a consumer of memory for memory-loaded servers (where NLST HyperCloud works best), GOOG would WANT NLST IP to be licensed by JEDEC/module-makers so there are many manufacturers and prices go down on this technology. Of course, this would be the (JEDEC/RMBS-like) “royalty-based” model that CEO Hong mentioned in the Needham conference audio:
quote:
we have strong IP which create competitive barriers as well as provide future avenues for a royalty based business model
Since all these matters ARE interrelated – for instance GOOG settlement with NLST suddenly puts NLST in a strong spot – knowing this, GOOG may try to combine the GOOG settlement with JEDEC-licensing negotiations. While radical, this would be the sort of thing GOOG could do. Gives it some street cred, plus it is beneficial to GOOG in long run which is an avid consumer of memory for servers.
Allied NLST IP like “embedded passives”:
GOOG/NLST settlement raises other questions – what will become of the 4-rank stuff that memory module makers have been making for some time. Is that all a violation of NLST IP as well ? Were a lot of those 4-rank modules sold before ? Settlement would involve forgiving or getting compensation for all the other NLST IP that has been used by others.
However, so far NLST has been careful to avoid litigating too many cases – the seem to have gone after MetaRAM, GOOG and Inphi – i.e. the core players making the memory, or influential in what happens.
If JEDEC were to license NLST IP to JEDEC/memory-module-makers, they would probably need to license more than just the core IP, since to do it as well as NLST they may require the allied IP like “embedded passives” (to free up space on memory modules).
Summary:
So in summary, given previous post comments about time-sensitive nature for GOOG, which has ever expading server/memory-use growth, we may see a settlement far earlier than the “one day before jury trial” scenario.
The trend by infringers to drag out cases to settle a day before jury trial (to deplete accuser’s resources) is thus not applicable here.
And the time-sensitive nature includes not just wanting to use the memory, but also to join early so it can participate in qualification and feedback for NLST HyperCloud i.e. be part of the process early on if they ARE going to be using that memory anyway.
And then possibly also to mobilize JEDEC/NLST licensing so future multiple sources of such memory are available for GOOG.
Regarding Inphi, I don’t think there will be any of the “complicated relationship” issues (as between NLST/GOOG) since NLST probably doesn’t expect to be manufacturing anything through Inphi.
Inphi is not just a buffer chip manufacturer – so the case won’t harm them too much.
However the actual damages retreivable from Inphi may not be huge since they haven’t really sold this buffer chip that much (i.e. still only at the announcement level). Although they WERE prepping to replace MetaRAM as buffer chip of choice for memory module makers (like Micron etc.).
Which I think is why Google started the litigation against Netlist with their declaratory relief action.
They do seem like ideal clients for Netlist, with Hypercloud memory. Even though they are adversaries in court at this point in time, there is the potential for them to do business together in the future.
Thanks for the detailed analysis, netlist.
I do still find myself puzzled by Google’s purchase of MetaRAM’s patents, and what they might do with them in the future.
quote:
I do still find myself puzzled by Google’s purchase of MetaRAM’s patents, and what they might do with them in the future.
As an NLST shareholder, I would be happy to see GOOG transfer that IP to NLST. Although much of it may not be valuable (like IP on stacked memory which NLST has criticized for asymmetrical data lines etc.).
A related question is what GOOG intends to do with the internal hardware division – or at least the sub-section that was involved with development of the “internal” (don’t know who actually manufactured that for GOOG) infringing memory modules that GOOG is using.
If GOOG intends to keep that division they may need some IP like MetaRAMs for the future (at least to mount “retaliatory lawsuits”).
Hi netlist,
I suspect that Google wants to maintain their own independent ability to develop and manufacture hardware for their own internal uses. It is possible that’s the reason why the acquisition of the patents, but it was still a surprise to see. I’m not sure that they would transfer the MetaRAM IP over to Netlist, but I’ll try to keep my eyes open in case it happens.
Yes, makes sense. Although GOOG’s efforts for hardware are hard to gauge. We don’t even know how GOOG made those memory modules, and in what number, or if MetaRAM was involved with that (can’t be if MetaRAM says only made $37,000 worth and destroyed them at that).
http://www.baselinemag.com/c/a/Infrastructure/How-Google-Works-1/
How Google Works
By David F. Carr
2006-07-06
quote:
Google runs on hundreds of thousands of servers—by one estimate, in excess of 450,000—racked up in thousands of clusters in dozens of data centers around the world.
And this is from 2006. But as the other paper you posted above:
DRAM Errors in the Wild: A Large-Scale Field Study (pdf)
http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf
suggests they may have variety of hardware perhaps.
http://en.wikipedia.org/wiki/Google_platform
Current hardware
Servers are commodity-class x86 PCs running customized versions of Linux. The goal is to purchase CPU generations that offer the best performance per dollar, not absolute performance.[7] Estimates of the power required for over 450,000 servers range upwards of 20 megawatts, which cost on the order of US$2 million per month in electricity charges. The combined processing power of these servers might reach from 20 to 100 petaflops.
Here’s an article on a GOOG server:
http://news.cnet.com/8301-1001_3-10209580-92.html
April 1, 2009 2:26 PM PDT
Google uncloaks once-secret server
by Stephen Shankland
This article suggests GOOG builds a battery into it’s server – and may thus avoid separate UPS costs (i.e. can tolerate interruption before a generator is started).
The idea of using a battery is what many may have thought of – except GOOG has done it (because there is a critical mass of such people there – as soon as someone proposed it, there would be many who would immediately warm up to the idea – as opposed to a more conventional company).
As the article states – the loss of efficiency in conversion is important – as it directly impacts the heating that has to be managed with air conditioning etc. then.
They have also simplified the have motherboard (or possibly the power supply as the comments suggest) to do the 12V to 5V conversion (also required by motherboards from power supplies usually) – and this simplifies the use of the single voltage i.e. 12V battery.
quote:
The Google server was 3.5 inches thick–2U, or 2 rack units, in data center parlance. It had two processors, two hard drives, and eight memory slots mounted on a motherboard built by Gigabyte. Google uses x86 processors from both AMD and Intel, Jai said, and Google uses the battery design on its network equipment, too.
The comments suggest the motherboard is:
http://www.gigabyte.com.tw/Products/Networking/Products_Spec.aspx?ProductID=1075&ProductName=GA-9IVDT
Which on the face of it would only support up to 12GB of DDR2 400MHz memory.
One thing to note though – they DO have all the memory slots in use – though that would make sense from an economic standpoint i.e. get least dense memory module (cheapest) and populate all the slots.
GOOG infrastructure is designed for fault tolerance and motherboard failure – it is possibly they are also designed for server variation. If so, there is no real indication that new servers being installed are not using more memory than this server that was revealed.
After all the server GOOG showed in discovery for GOOG vs. NLST WAS infringing NLST IP (using “Mode C” and by implication 4-rank memory). It could be since GOOG had chosen to not deny that they were using “Mode C”, they thus chose to reveal a server demonstrating that as well – to simplify the process of eventual settlement and arbitration.
One reason GOOG could use the 4-rank memory despite not having systems that are heavily memory loaded (if 8-12GB still runs at top speed) could be reduced power consumption and ability to use cheaper memory chips. However would the manufacturing of such custom memory not be expensive as well (compared to a mass producer of such memory ?).
The article is dated April 1, 2009 – the author confirms that it was not an April Fool’s article.
Hi netlist,
Informative articles, especially the CNET one from April 1st.
There is an Exaflop patent (Exaflop shares the same address as Google on its patent submissions), Data center uninterruptible power distribution architecture, which includes the use of a 12 Volt lead acid battery in the event of power failure.
The patent looks like it might describe an earlier generation of Google’s use of a 12 volt battery for each server. A number of the many granted patents and patent applications assigned to Exaflop mention the use of a 12 volt battery.
Google also has a few granted and pending patent filings on motherboard cooling systems, a modular data center, and other data center approaches (including a water-based data center).
But I haven’t seen any published patent filings from them (other than the MetaRAM assigned ones) that focus upon memory.
NLST officially recognizes settlement with MetaRAM.
I wonder why the delay – is it because they have to wait for the final approval by court to appear ?
The other alternative – that NLST is savvy about holding back on news and posting it (like the previous 2 patents) at a time when stock is being manipulated down by market markers etc. If so, that would be interesting – and the opposite of what some companies wind up doing – i.e. screwing shareholders. With insiders owning 50% plus of NLST, that is perhaps one of the advantages – that management is better aligned with shareholder interest.
Stock price movements may not harm stocks in the long run, but they scare out many shareholders – leading to shareholder churn and (at least on stock bulletin boards) an absence of long time holders. So in that sense at least it helps if a company’s stock price does not move up/down that much (or manipulated down by market makers during a lull period).
http://finance.yahoo.com/news/Netlist-Announces-Settlement-prnews-1484777084.html?x=0&.v=1
Netlist Announces Settlement of Patent Infringement Lawsuits With MetaRAM
Press Release Source: Netlist, Inc. On Thursday January 28, 2010, 1:25 pm EST
Hi Netlist,
It’s quite possible that they waited because they wanted to get legal filings out of the way, and a final settlement order from the two Courts involved. Making an announcement in a timely fashion after legal requirements were fulfilled would make it less likely to be perceived that they were announcing news in an effort to manipulate stock prices.
GOOG’s attorneys King & Spalding add some IP litigation attorneys to the team:
01/27/2010 90 MOTION for leave to appear in Pro Hac Vice Mark H. Francis ( Filing fee $ 210, receipt number 44611004730.) filed by Google Inc.. (Attachments: # 1 Proposed Order)(jlm, COURT STAFF) (Filed on 1/27/2010) (Entered: 01/28/2010)
01/27/2010 91 MOTION for leave to appear in Pro Hac Vice for Daniel Miller ( Filing fee $ 210, receipt number 44611004730.) filed by Google Inc.. (Attachments: # 1 Proposed Order)(jlm, COURT STAFF) (Filed on 1/27/2010) (Entered: 01/28/2010)
01/27/2010 92 MOTION for leave to appear in Pro Hac Vice for Scott T. Weingaertner ( Filing fee $ 210, receipt number 44611004730.) filed by Google Inc.. (Attachments: # 1 Proposed Order)(jlm, COURT STAFF) (Filed on 1/27/2010) (Entered: 01/28/2010)
01/27/2010 93 MOTION for leave to appear in Pro Hac Vice for Susan Kim ( Filing fee $ 210, receipt number 44611004730.) filed by Google Inc.. (Attachments: # 1 Proposed Order)(jlm, COURT STAFF) (Filed on 1/27/2010) (Entered: 01/28/2010)
01/27/2010 94 MOTION for leave to appear in Pro Hac Vice for Allison Altersohn ( Filing fee $ 210, receipt number 44611004730.) filed by Google Inc.. (Attachments: # 1 Proposed Order)(jlm, COURT STAFF) (Filed on 1/27/2010) (Entered: 01/28/2010)
It seems Scott Weingaertner is the significant attorney with expertise in “employee trade secret misappropriation”:
http://www.marketwire.com/press-release/King-Spaldings-Growth-Continues-in-New-York-760126.htm
SOURCE: King & Spalding
Aug 13, 2007 12:02 ET
King & Spalding’s Growth Continues in New York
Weingaertner focuses on intellectual property litigation and counseling with particular experience handling disputes regarding patent infringement, licenses and employee trade secret misappropriation, as well as patent interferences and ex parte procedures before the U.S. Patent and Trademark Office. He is well versed in the technology areas of semiconductors and other electronics, computer software, medical and other mechanical devices, and financial services. He earned S.B. and S.M. degrees from the Massachusetts Institute of Technology, and a J.D. from the University of Pennsylvania.
GOOG attorneys King & Spalding probably needed some IP attorneys – that is understandable.
The original reading still stands – that if King & Spalding is unranked for IP litigation, but #2 for arbitration – it seems likely that it was the #2 part which brought them to attention of GOOG.
This because Fish & Richardson (which they dumped) is already a respected law firm for IP litigation.
In any case, GOOG may not have liked the direction in which things were going – or the previous prosecution pattern of previous attorneys, possibly moving to a new tack (with new faces).
This article gives the general sense of the situation – Fish & Richardson was ideal for IP litigation, while King & Spalding for “general matters”.
Fish & Richardson (GOOG’s previous attorneys) is consistently rated among top 2 in overall as well as “patent prosecution”. While King & Spalding is #13 in “overall category”, and not even listed in top 30 for “patent prosecution”:
http://www.law.com/jsp/iplawandbusiness/PubArticleIPLB.jsp?id=1202437741766
or
http://www.slwip.com/about/whats_new/documents/2010Top10PatentProsecution.pdf
The Guardians
Which law firms do the country’s biggest corporations turn to when they need help obtaining, asserting, and defending their valuable intellectual property?
By Erik Sherman
IP Law & Business
December 01, 2009
…
The Big List
On the surface, there is a lot of consistency in how widely the top companies spread their work. Consider that the 36 firms included in the overall ranking that, along with our patent prosecution and IP litigation rankings, appears here were mentioned by companies at least five times for doing either prosecution or litigation work. But only five firms—Baker Botts, Fish & Richardson, Foley & Lardner, K&L Gates, and Greenberg Traurig—got enough mentions to also qualify for spots on our prosecution and litigation lists.
…
With two exceptions, no firm got more than three mentions from companies in a single industry. The exceptions: Baker Botts and Fish & Richardson (a finalist in this year’s IP Litigation Department of the Year contest; see “Perfecting the Art of War.” ). Both were named by multiple high-tech and/or telecommunications companies.
…
Fish did litigation and prosecution work for Apple Inc., H-P, and Intel Corporation, and litigation for Microsoft Corporation.
By contrast, the top firm with the most diverse docket was King & Spalding, whose seven mentions came from seven different clients, each of them in a different industry. For example, the firm did litigation work for The Coca-Cola Company (beverage), Chevron Corporation (energy), and International Business Machines Corporation (technology), and prosecution for General Electric Company (diversified financials), The Procter & Gamble Company (household and personal products), Citigroup Inc. (financial services), and Costco Wholesale Corporation (retail).
…
With eight and six mentions, respectively, two of the top litigation firms—Fish & Richardson and IP Litigation Department of the Year winner Quinn Emanuel Urquhart Oliver & Hedges (see “What Rhymes with Win?” ) had four clients between the tech and telecom sectors. Compare that to Wilmer and King & Spalding, with four mentions spread across four different industries. When it comes to litigation, high-tech companies and telecoms stand out, with top industry players using 15 out of the 18 firms to rack up at least four mentions. Given that, between them, these companies account for only 12 percent of the 100 biggest companies, the fact that they hired so many top litigation firms is certainly noteworthy. Is it any wonder that technology companies—frequent targets of so-called patent troll infringement claims—have been a driving force in the push to reform the nation’s patent system?
…
The Prosecution List
While it may not be as lucrative as litigation, patent prosecution work can be plentiful. Consider that in 2008, Fortune 100 corporations collectively received well over 21,000 patents, according to figures from the Intellectual Property Owners Association and the Patent and Trademark Office.
So who’s doing the bulk of that work? Thirty firms earned at least four mentions. At the top of the list, there is little overlap with the top litigation shops. Only three firms—Baker Botts, Fish & Richardson, and K&L Gates—climbed into the top four on both lists.
http://www.law.com/jsp/iplawandbusiness/PubArticleIPLB.jsp?id=1202437199242
The IP Litigation Department of the Year
IP Law & Business
December 01, 2009
Winner: Quinn Emanuel What Rhymes with Win?
Finalist: Fish & Richardson Perfecting the Art of War
Finalist: Weil, Gotshal & Manges Tried and True
Finalist: Winston & Strawn The Net Effect
http://www.fr.com/news/2010/january/americanlawyer.pdf
The Fish docket is mostly defense cases, but
the firm can flex its enforcement muscles. Case
in point: Fish helped Callaway Golf Company
win an injunction blocking the sale of Acushnet
Company’s Titleist Pro V1, which generated
$1.9 billion in sales in 2008. While that win
was sent back for a retrial due to a technical is-
sue, Callaway GC Michael rider says he has no
qualms about hiring Fish to handle all his pat-
ent litigation: “They know the patent law abso-
lutely cold, and know how to try patent cases.”
http://www.fr.com/news/2010/january/FishIPLaw360.pdf
Law360, New York (January 01, 2010)
Fish & Richardson PC
Fish & Richardson earned top spot in Law360’s IP firm rankings for its success in
reversing over $700 million in damages awards against Microsoft Corp. and in forging
new law concerning the fraud standard in trademark disputes.
http://www.fr.com/news/articles.cfm?topicid=13
Recent Wins
Anyone know where the Google Caffeine project page is now ?
Originally announced at:
http://www2.sandbox.google.com/
Or has it been integrated already (i.e. working in some random data center as originally anticipated).
Hi Netlist,
The search at that address was retired a few months ago, and Matt Cutts announced on his blog in early November to Expect Caffeine after the holidays. In that post, Matt mentioned that they would be showing Caffeine results at one data center so that they could continue to test it.
From what I have heard, Caffeine results were being shown for roughly half the visitors to the data center at IP address 209.85.225.103. It’s quite poassible that Google has rolled out Caffeine results to more data centers at this point, but we can’t be sure for certain.
In re: the above article that this thread is under – no one thinks it’s too much of a coincidence that GOOG announces this Caffine Project exactly one week after NLST announces their HyperCloud? NLST comes out with something seemingly revolutionary in memory and cloud computing, and a week later GOOG announces that they’re upgrading their infrastructure code and doing an overhaul of their browser to make it faster? Something that would require a memory upgrade?
And, as of this writing, the NASDAQ is up big, and NLST is down on very low volume. They driving it down with 100 share trades, and then buy 10 & 15K share blocks once they get it down.
NLST is being manipulated like there’s no tomorrow.
quote:
no one thinks it’s too much of a coincidence that GOOG announces this Caffine Project exactly one week after NLST announces their HyperCloud? NLST comes out with something seemingly revolutionary in memory and cloud computing, and a week later GOOG announces that they’re upgrading their infrastructure code and doing an overhaul of their browser to make it faster? Something that would require a memory upgrade?
Although having more memory in servers would allow GOOG to do things on a different scale, the suggestion in media or GOOG info seems to suggests an improvement in the algorithms and stuff like that. Any improvement in the hardware is not explicitly mentioned it seems.
GOOG was using the infringing memory prior to GOOG announcement. If anything Caffeine may have been based on that memory. Thus it would have little to do with NLST’s announcement schedule.
Recall that GOOG had gone to court to prevent NLST seeking to shut down GOOG servers – that case is GOOG vs. NLST.
During discovery for GOOG vs. NLST, GOOG was forced to show a GOOG server to NLST which had “Mode C” (smoking gun for “4-rank”). That led to NLST filing case NLST vs. GOOG.
As reported above, both GOOG and NLST asked court to consolidate the two cases because they are dealing with same memory.
Now it seems (Feb 3, 2010) Judge Armstrong has DENIED the consolidation. She is saying the GOOG vs. NLST case is well on it’s way (with discovery on track), so why delay that.
And to let the cases go ahead separately.
What does this mean.
It means the GOOG vs. NLST (which is at an advanced stage) will not be delayed.
Note that both parties were keen to consolidate the cases.
Here is what she says:
quote:
Based on that
commonality, the parties request that the Court: (1) consolidate the cases for trial under
Federal Rule of Civil Procedure 42(a); (2) vacate the pretrial schedule and trial date in the First
Case in order to coordinate both cases for trial; and (3) schedule a date for a Case Management
Conference to set a new pretrial schedule applicable to both cases.
The Court is not convinced that the parties’ requests to consolidate and vacate the
pretrial schedule and trial date in the First Action are either necessary or appropriate. The First
Case based on Netlist’s decision to file a
new action over a year after the First Case was filed, particularly given that the new action
purportedly involves the same memory modules at issue in the First Case.
The Court also has serious concerns regarding the potential for the instant litigation to
expand exponentially, thereby increasing the cost to the parties and consuming an inordinate
amount of judicial resources. Although a settlement conference has been scheduled in the First
Case for August 3, 2010, the Court believes that it is in the parties’ mutual interest to engage in
a settlement conference or mediation, sooner rather than later—before the parties have
expended what likely will be a considerable amount of time and resources litigating these two
cases.
I’m pretty confident NLST is going to make another run again soon. I’m not some delusional buy and hold long who tells himself whatever he needs to hear while he keeps losing money.
I bought the stock @ 2.46 on that 1st Friday during the run up. I could have bought much cheaper, but it wasn’t until I did the DD that I realized the implications of what they had come up with. I sold the following Monday a little under 6, and then bought back in @ the close on Tuesday @ 4.03. Sold it at the end of the week @ 6.76. Played it a few more times on momentum and spikes here and there. But when they got it down to 3.34 the other day, I had to buy back in. And I bought back in deep. Got me 30K shares @ 3.43/3.42/.
Watching it trade the last few days, it’s really obvious that the crooks are walking it down on super low volume.
In the meantime, I really wish NLST would offer a little forward guidance.
I love this page you guys are well informed and very knowledgeable…
Can you tell me where you review the court docs for these case’s?
Thank you much.
Never mind. I found it…
Cheers!
quote:
Can you tell me where you review the court docs for these case’s?
For completeness here is the link:
http://messages.finance.yahoo.com/Stocks_%28A_to_Z%29/Stocks_N/threadview?m=te&bn=51443&tid=11572&mid=13025&tof=1&frt=2#13025
Re: update on the various court cases
…
By the way, anyone wanting to look for court cases can do so at:
http://pacer.uspci.uscourts.gov/
You need to register, but only need to pay after dues reach a certain amount (can use credit card to pay).
Click on “Enter U.S. Party/Case Index”.
Click on “All Court Types”
search for netlist:
Party Name: netlist
The cases will be listed (though with cryptic ids) – here is a guide:
NLST vs. Inphi:
4 NETLIST INC. cacdce 2:2009cv06900 09/22/2009 830
GOOG vs. NLST:
10 NETLIST, INC. candce 4:2008cv04144 08/29/2008 830
NLST vs. GOOG:
13 NETLIST, INC. candce 4:2009cv05718 12/04/2009 830
Inphi vs. NLST:
14 NETLIST, INC. cacdce 2:2009cv08749 11/30/2009 830
Clicking on the ID will show a page – you can view in HTML (webpage) or as pdf. View in HTML for now.
Click on “Docket Report”.
This will show what’s going on – and will have links for the individual dockets (judge’s ruling, filings by NLST/GOOG etc.).
Another patent application assigned to Google was published at the end of January:
Methods and Apparatus of Stacking DRAMS
From the patent filing:
Netlist’s ‘386 patent looks like it was filed on July 1, 2005, which was a couple of months earlier than the provisional patent application.
Not sure if any of this has any impact or significance for any pending litigation, and there is the possibility that there might be additional unpublished patent filings as well, but thought it was worth mentioning.
Another patent application assigned to Google was published at the end of January:
Methods and Apparatus of Stacking DRAMS
Thanks.
Netlist’s ‘386 patent looks like it was filed on July 1, 2005, which was a couple of months earlier than the provisional patent application.
NLST claims their IP dates back to March 2004 (from court filings).
Yes, this seems to be a MetaRAM patent that may have been in process (continuation of earlier patent).
It says it is a continuation of this patent:
http://www.freepatentsonline.com/7599205.pdf
Which itself is a continuation of:
http://www.freepatentsonline.com/7379316.pdf
This is a long-standing patent thread at MetaRAM – for “stacking DRAMs”.
Since GOOG is now owner of original thread, and all derivative patents, we see GOOG as direct owner. Note that the lawyer is Fish & Richardson (GOOG’s lawyer). Don’t know if Suresh Rajan is now a GOOG employee – but would make sense if MetaRAM main inventors are brought into GOOG hardware division.
This is related to the “stacking DRAMs” stuff that MetaRAM was doing and which as I pointed out earlier NLST was critical of for it’s asymmetrical lines to memory chips (i.e. asymmetric delays along lines).
As posted above:
Compare NLST to MetaRAM (now bankrupt) design:
http://www.ansoft.com/ie/Track2/DDR3%20Memory%20Module%20Design.pdf
It shows MetaRAM was to deliver 16GB 2Rank R-DIMMs in Dec 2008 at slower 1066 MT/s speed than the 1333 MT/s for the 8GB (and slower than 1333 MT/s for the NLST 16GB HyperCloud).
You can also see the problems with MetaRAM design – layout of chips is asymmetrical, and height increases considerably for the 16GB. It has the Hynix label on it.
You can see the “discrete decoupling capacitor” (compare to “embedded passives” with NLST IP).
And compare with NLST comments (also from earlier post above):
http://www.netlist.com/technology/technology.html
While some packaging companies stack devices to double capacity, Netlist achieves the same result without stacking, resulting in superior signal integrity and thermal efficiency. Stacking components results in unequal cooling of devices, causing one device to run slower than the other in the stack. This often results in module failures in high-density applications.
The density limitation is solved by proprietary board designs that use embedded passives to free up board real estate, permitting the assembly of more memory components on the substrate. The performance of the memory module is enhanced by fine-tuning the board design to minimize signal reflections, noise, and clock skews.
Sorry for incorrect use of HTML tags. What tag do you use to indent ?
Hi netlist,
No apologies necessary. All your efforts towards making this thread become as informative as it is are truly appreciated.
The html element “blockquote” can be used to indent, like in my comment above.
Netlist,
I am confused. I see the following part on netlist website
NMD2G7G3510BH-D85 16GB 1066MHz 2Rx4 16GB x4 4Gb DDP Planar LP
Does DDP mean staked(?) devices ? Why is Netlist selling staked devices and not using
their own proprietary technology ?
Netlist,
BTW, if staked technology is being used by Netlist then the metaram
patent will apply ? any ideas on how metaram patent might limit netlist ?
quote:
I am confused. I see the following part on netlist website
NMD2G7G3510BH-D85 16GB 1066MHz 2Rx4 16GB x4 4Gb DDP Planar LP
Does DDP mean staked(?) devices ? Why is Netlist selling staked devices and not using
their own proprietary technology ?
How do you presume it is “stacked DRAM” ?
NLST explicitly disparages stacked DRAM use by “other companies”:
MetaRAM had other IP (including “stacked DRAMs”) which it DID NOT use against NLST. What does that suggest ?
Instead it was one patent 7472220 that was used in
retaliatory suit against NLST:
http://www.freepatentsonline.com/7472220.pdf
As posted above:
7472220 – MetaRAM license to NLST ..
http://assignments.uspto.gov/assignments/q?db=pat&qt=&reel=&frame=&pat=7472220&pub=&asnr=&asnri=&asne=&asnei=&asns=
That patent is now licensed to NLST as part of settlement (and any buyer – GOOG or other – of this IP from MetaRAM will not be able to use it against NLST).
From the PR at time of NLST/MetaRAM settlement:
http://finance.yahoo.com/news/Netlist-Announces-Settlement-prnews-1484777084.html?x=0&.v=1
Netlist Announces Settlement of Patent Infringement Lawsuits With MetaRAM
Press Release Source: Netlist, Inc. On Thursday January 28, 2010, 1:25 pm EST
…
A provision in the settlement protects Netlist if another company purchases MetaRAM’s patent and attempts to seek action against Netlist in the future.
quote:
I am confused. I see the following part on netlist website
NMD2G7G3510BH-D85 16GB 1066MHz 2Rx4 16GB x4 4Gb DDP Planar LP
Does DDP mean staked(?) devices ? Why is Netlist selling staked devices and not using
their own proprietary technology ?
“4Gb DDP” seems to be some type of memory as can also be seen here:
http://www.intel.com/technology/memory/ddr/valid/ddr2_800_sodimm_results.htm
M470T5267AZ3-CE7 Samsung K4T4G274QA-TCE7 4GB 4Gb(DDP) 8 5-5-5 0801 No
More specifically:
DDP = Dual Die Packaging
Where you have two dies in same packaging (as opposed to the traditional one die in one packaging).
That is, two memory chip wafer pieces inside one packaging.
This is not the same thing as “stacked DRAM” (MetaRAM) which relates more to how you organize memory chip packages on a memory module.
http://www.freshpatents.com/Memory-system-dt20080131ptan20080025128.php
might be the “NetVault” line of products which CEO Hong has mentioned in Needham conference audio (which include onboard flash memory to backup memory module contents in case of power failure).
Sorry cut the last para out about NetVault.
I was half thinking that until appropriate google searches revealed DDP means something else.
Netlist,
It is not clear that staked and DDP are different. From,
http://en.wikipedia.org/wiki/Dynamic_random_access_memory
Stacked RAM modules contain two or more RAM chips stacked on top of each other. This allows large modules (like 512mb or 1Gig SO-DIMM) to be manufactured using cheaper low density wafers. Stacked chip modules draw more power.
Does this not mean DDP = 2 dies in same package = staked ?
Totally confused now.
Another item from Netlist webpage
http://www.netlist.com/technology/technology.html
>>While some packaging companies stack devices to double capacity, Netlist achieves the same result without stacking, resulting in superior signal integrity and thermal efficiency.
appears that DDP is same as staked ? No ?
would be dangerous if hypercloud is using staked technology ?
quote:
Stacked RAM modules contain two or more RAM chips stacked on top of each other. This allows large modules (like 512mb or 1Gig SO-DIMM) to be manufactured using cheaper low density wafers. Stacked chip modules draw more power.
Does this not mean DDP = 2 dies in same package = staked ?
An attempt at explanation of the terminology:
“die” – small stamp-sized piece of the shiny silicon wafer
http://en.wikipedia.org/wiki/Die_preparation
“memory chip” – die embedded within that black-plastic type stuff that people usually call a “chip” – has metal conductive pins coming out of it (shorter in the case of surface-mount chips).
“memory module” – that stuff you put in the memory slot of your computer – comprising a circuit board (maybe sophisticated many layered or including resistor/capacitors within it – as with NLST’s “embedded passives”). Circuit board has many “memory chips” on it (see above).
NLST technology lies not in “die”, or in “memory chip”. They buy the memory chip from Hynix and others (first NLST HyperCloud slated to use Hynix “memory chips”.
So Hynix is a “memory chip” manufacturer.
NLST is a consumer of those “memory chips” and a manufacturer of “memory modules”.
NLST combines “memory chips” so they fit on a “memory module”. This they do by IP (intellectual property/patents) that includes “embedded passives”, plus IP on how to place “memory chips” for even heat dissipation. That is, there is IP related to how you structure a “memory module” i.e. how you use those “memory chips” to construct a “memory module”.
In addition NLST has IP in extra circuitry that goes on the “memory module”. These are chips that NLST makes on it’s own – the buffer chip is a specialized ASIC for doing stuff with control signals, address lines and data lines that goto “memory chips” on the “memory module”.
In addition NLST has some circuitry for “load isolation” so they only connect (perhaps imprecise here) some set of “memory chips” to be visible at a time etc.
This is NLST’s purpose. They do not indulge in “memory chips” design, nor in “die” or wafer. They basically make complete “memory modules” that people can buy and put in their computer motherboard directly.
So NLST is a “memory module” maker, and it has IP to back that up. That IP relates to how the “memory module” is made/structured as well as all the EXTRA circuitry that they have put on that memory module.
MetaRAM was similar – they ALSO do (or did – now that they are prevented from doing so after settlement, and well .. bankruptcy).
MetaRAM ALSO has IP in load isolation, and in “memory chip” placement on the memory module. Since “memory module” is usually a standard sized piece of circuit board (albeit advanced circuit board), they have to come up with ways to fit more memory chips on there. Their “stacked DRAM” IP relates to THAT aspect.
NLST does not use “stacked DRAMs” because as pointed out above they feel it is inferior way of doing it.
Coming back to MetaRAM – so MetaRAM ALSO makes “memory modules”. In addition they were willing to work with Hynix and others to either sell them the memory modules (i.e. completed memory modules) for resale, OR they were willing to share their IP with Hynix and others so OTHER companies could also do something similar. This is the “royalty-based” model (i.e. instead of just making all memory modules yourself). This model is exemplified by RMBS. NLST has referred to it in the Needham conference audio.
quote:
we have strong IP which create competitive barriers as well as provide future avenues for a royalty based business model
The problem with MetaRAM was they don’t have IP in “embedded passives” etc. which means they not able to create more space on the same small circuit board as NLST can do.
They try to fit more “memory chips” by stacking them i.e. “stacked DRAMs” or other stuff to fit in more chips on the same “memory module”.
As noted above, that is not how NLST does it.
A second problem with MetaRAM was their IP is from much later – and it could be said is “derivative” or inspired by NLST IP. You have to ask yourself why a high flier like MetaRAM (with support from INTC and others – with Hynix and STEC and others all planning to use their IP/buffer chips) – why MetaRAM suddenly closed shop ?. Was it related to the GOOG/NLST lawsuit and was there some realization within MetaRAM. Why did MetaRAM say they only sold $37,000 worth of stuff and “destroyed” it (from MetaRAM court filings) – what’s the hurry to “destroy” stuff ?. MetaRAM was trying to minimize the potential for infringement penalty.
So basically NLST make and MetaRAM made whole “memory modules” – they did not make “memory chips” or “dies”.
Inphi is similar – except they may not even make the “memory module”, but just the buffer chips and allied circuitry so others can make it. Difference is they hold even less IP than MetaRAM. Inphi is a component maker – they make lots of different components. They were hoping to step in after MetaRAM dropped out.
So in summary:
Stacked DRAM refers to stacking “memory chips” – and is a way of arranging the “memory chips” on the “memory module”.
DDP – dual die packaging. This is when “memory chip” manufacturers like Hynix make “memory chips” with TWO dies in them.
So the “memory module” that NLST/MetaRAM make can include a normal “memory module” or a DDP “memory module”. They thus label their memory module specs with “DDP” or no DDP.
Hope this resolves the confusion between:
DDP – this is done by “memory chip” manufacturers like Hynix etc.
stacked DRAMs – this was done by MetaRAM in how it places those “memory chips” on “memory module”
They are two different things – relating to things that go on at two different scales – one within the “memory chip” black plastic packaging, and one on the “memory module” circuit board.
Hope this helps.
Slight correction to sentence above ..
quote:
So the “memory module” that NLST/MetaRAM make can include a normal “memory module” or a DDP “memory module”. They thus label their memory module specs with “DDP” or no DDP.
Should read:
So the “memory module” that NLST/MetaRAM make can include a normal “memory chip” or a DDP “memory chip”. They thus label their memory module specs with “DDP” or no DDP.
Thank you netlist. I think I am beginning to understand
the difference.
In a recent interview, NLST CEO said they strategically dedicated and spent over $10 million for R&D costs for products such as Hypercloud and NetVault. Not surprising that they are vigorously protecting investment in IP portfolio through negotiation and litigation as last resort. They seem to have facts and law on their side.
First, MetaRAM settled ‘386 patent infringement in December 2009, and agreed to cooperate and stop its infringement. Will MetaRAM’s cooperation include full disclosure of relevant customer lists including in Google’s case?
Next, Inphi must Answer by Feb. 11, 2010 to NETLIST’s Amended Complaint that added ‘912 and ‘274 patents in addition to initial allegations of ‘386 patent infringement. USPTO issued Patent 7,619,912, entitled “Memory Module Decoder” on 11/17/2009, and Patent 7,636,274, entitled “Memory Module with a Circuit Providing Load Isolation and Memory Domain Translation” on 12/22/2009. It appears Inphi hired a former employee of MetaRAM.
On Google’s Declaratory Relief on Non-Infringement of ‘386 patent, and Netlist v Google case for ‘912 patent infringement, a case management conference is set for 3/4/2010.
Is Google running out of time? As in above post, that judge Hon. Armstrong denied request to consolidate, and in essence said either settle or try the case on its merits, but no delays. Interesting to note that the Order strongly suggested parties “to engage in a settlement conference or mediation, sooner rather than later”. The judge also mentioned one of the reasons for denial was that the Court already held claims construction hearing and construed disputed claim terms. It seems that the Court ruled largely in favor of NLST patent claims construction. Same Court granted Netlist Discovery request to examine Google server. Subsequently, NLST sued Google alleging ‘912 patent infringement.
Right.
Also earlier, Judge Armstrong had denied GOOG fishing expedition “use of ‘386 patent prosecution history”. Though I can’t find that at the moment – but recall reading that somewhere.
quote:
First, MetaRAM settled ‘386 patent infringement in December 2009, and agreed to cooperate and stop its infringement. Will MetaRAM’s cooperation include full disclosure of relevant customer lists including in Google’s case?
Yes, it would be interesting to note the exact settlement in NLST/MetaRAM.
Even the possibility that IP beyond the one used by MetaRAM in retaliatory lawsuit could be compromised. However my gut feeling is that if the case had gone to jury trial and MetaRAM convicted, THEN that could have rendered suspect much of MetaRAM IP (even if sold to GOOG previously).
However with a settlement, there is no legal bar on MetaRAM (or those who bought from MetaRAM) – i.e. there is no enforcement – except what MetaRAM owns now. So the IP most relevant to NLST (which MetaRAM still held for use in retaliatory lawsuit) was handed over to NLST (or licensed with bar on any future buyer to use it against NLST).
On NLST’s investor SEC filing page, it shows report date of Feb. 11, 2009 for Renaissance Technology LLC owning more than 1.4 million shares as of Dec. 15, 2009.
Updates on NLST vs. Inphi.
Updates on NLST vs. GOOG.
We have Inphi answer in NLST vs. Inphi. Standard boilerplate answer – we challenge patents etc.
We have GOOG answer in NLST vs. GOOG. Standard boilerplate answer.
However there is some interesting information in the GOOG answer about goings on at the JEDEC meetings (specifically “JEDEC JC-45″ committee meetings).
From GOOG answer we find that:
INTC presented their FB-DIMM quad-rank (4-rank) proposal in May, June, August and December 2007.
GOOG says that at June 2007 meeting, NLST representatives “withheld” information that they held patents in this area and or were in process for new patents.
At August 2007 meeting the same.
At December 2007 meeting GOOG says that NLST revealed that it held IP which may apply to the FB-DIMM and 4-rank/quad-rank designs.
However NLST was willing to provide access to that IP on RAND terms (as JEDEC members do as part of JEDEC).
http://en.wikipedia.org/wiki/Reasonable_and_Non_Discriminatory_Licensing
Reasonable and Non Discriminatory Licensing
On Jan 8, 2008, NLST inventor Bhakta sent letter to JEDEC offering RAND terms “but only identified the ‘386 patent” (which is normal).
This makes sense as the ‘912 patent is just a continuation of the ‘386. In superficial reading you cannot see any major difference between the two:
http://www.freepatentsonline.com/7289386.pdf
http://www.freepatentsonline.com/7619912.pdf
However, since NLST complaint has referred to ‘912 patent (representing the ‘386 patent thread), GOOG has chosen to just focus on the ‘912 while not addressing the ‘386 patent which NLST could add as easily to the complaint (or which implicitly is perhaps included since ‘912 is a superset of ‘386).
The answer by GOOG is reminiscent of some of the controversy in the RMBS/JEDEC tussle. There it was alleged that RMBS knew their designs were being standardized or in some cases they patented IP AHEAD of decisions by JEDEC (knowing that those areas will become valuable to JEDEC future direction).
The case of NLST/JEDEC is simpler – here NLST IP predates (March 2004) the JEDEC standardization. The ‘386 patent had been issued (and NLST had announced it to JEDEC) prior to the JEDEC members voting for the standard.
Also one of the inventors of 4-rank Bill Gervasi (while at NLST) later became JEDEC committee chair, as well as employee at SimpleTech.
http://www.discobolusdesigns.com/personal/gervasi_modules_overview.pps
Memory Modules Overview
Spring, 2004
Bill Gervasi
Senior Technologist, Netlist
Chairman, JEDEC Small Modules
& DRAM Packaging Committees
http://www.stec-inc.com/products/DRAM/4rank_DRAM.pdf
4 Rank DRAM Modules
Addressing Increased Capacity Demand Using Commodity Memories
Bill Gervasi, VP DRAM Technology, SimpleTech
Chairman, JEDEC JC-45.3
January 19, 2006
http://www.discobolusdesigns.com/personal/stec_atca_memory_20061017.pdf
Memory Modules for ATCA and AMC
Bill Gervasi
Vice President, DRAM Technology
Chairman, JEDEC JC-45.3
Note that NLST in it’s complaint also alleges leakage of it’s IP to JEDEC. Or by Texas Instruments ?.
I don’t know if Bill Gervasi is considered part of that leakage (that JEDEC benefitted from).
Some info on JEDEC’s JESD82-20A – FBDIMM Mode C proposed standard etc.:
http://www.jedec.org/download/search/JESD82-20A.pdf
http://www.jedec.org/download/search/JESD82-28A.pdf
JESD82-20A.pdf has the following disclaimer:
Special Disclaimer
JEDEC has received information that certain patents or patent applications
may be relevant to this standard, and, as of the publication date of this
standard, no statements regarding an assurance or refusal to license such
patents or patent applications have been provided.
http://www.jedec.org/download/search/FBDIMM/Patents.xls
JEDEC does not make any determination as to the validity or relevancy of
such patents or patent applications. Prospective users of the standard
should act accordingly.
The Patents.xls file is not available at that address now. However this demonstrates that there were IP infringement shadows cast on JESD82-20A standard.
So why did GOOG violate knowing those caveats existed ?
But for reference, here is the RMBS story:
http://en.wikipedia.org/wiki/Rambus
As can be seen their behavior was suspect in some cases – i.e. securing IP ahead of JEDEC decisions.
However they have prevailed in court despite those negatives:
http://www.mercurynews.com/business-headlines/ci_14224770
Rambus wins $900 million from Samsung
By Steve Johnson
sjohnson@mercurynews.com
Posted: 01/19/2010 05:22:07 PM PST
Updated: 01/20/2010 03:04:17 AM PST
It is now clear that NLST is claiming that FB-DIMM and 4-rank/quad-rank is infringing NLST IP.
FB-DIMM is a major part of memory design roadmap – which introduced serial signalling and the use of the AMB (buffer) on the memory module. The AMB buffer part is probably the infringing part of the JESD82-20A standard.
http://en.wikipedia.org/wiki/Fully_Buffered_DIMM
The JEDEC standard JESD206 defines the protocol, and JESD82-20 defines the AMB interface to DDR2 memory.
GOOG says there was no public info that ‘912 had also been filed (is this true – cannot search for in-process patent applications ?).
GOOG answer suggesting that JEDEC voted for standard finally despite knowing of NLST IP issues (with ‘386 patent if not ‘912 patent) – quote:
The Intel proposed changes to JESD82-20 were incorporated in JESD82-20A. The JEDEC members voted to issue the JESD82-20A standard, having all such JEDEC members, except for Netlist representatives, vote unaware of the patent application that led to the ‘912 patent.
GOOG claims that that approval (without NLST participation) went on while “unaware of” the ‘912 patent in process.
quote:
Netlist has affirmatively attempted to disclose the ‘386 patent as relevant to certain JEDEC standards, with knowledge that they had filed a continuation of that patent, which was to issue as the ‘912 patent.
GOOG says – quote:
Netlist’s silence as to the patent application that led to the ‘912 patent induced the other JEDEC members to rely upon that standard being free of intellectual property encumbrances. The JEDEC members, including Google, were without information regarding the pending patent application that was to issue as the ‘912 patent when JEDEC issued the JESD82- 20A standard.
What about the progenitor ‘386 patent ? That was already public information by that time. What “induced” JEDEC members (and GOOG being among them) to vote again for standard – knowing by then that it was conflicting with ‘386 patent (if not ‘912 patent).
Focusing on ‘912 patent is a bit of a red herring – because NLST has used ‘912 in the complaint (as the latest of the ‘386 patent thread).
What prevented JEDEC members from abandoning this standard (if they knew it was conflicted by then) ?
JEDEC approval of a standard does not reduce the burden of securing IP that supports that standard.
Why did GOOG go ahead with rampant use of NLST IP after that ? Ratification of standard at JEDEC does not automatically give people the right to use NLST IP – to do that you STILL have to negotiate for licensing terms (even if it is a JEDEC “standard” and even if they are expected to be on RAND terms).
Netlist,
Thank you for going through the goog response. However it does appear that
Joe Soleiman (sp ?) of netlist who is an inventor of 912 attended JEDEC meeting
and appeared to keep quiet about the 912 patent application. Hard for him to
claim that he did not know ? It would be useful for goog to get 912 thrown out
based on netlist cheating and focus only on 386. Don’t you agree with that strategy ?
Also any chance that Netlist gets thrown out of JEDEC (like Rambus) and loses the
opportunity to claim that their hypercloud modules are “JEDEC compatible” ?
quote:
However it does appear that
Joe Soleiman (sp ?) of netlist who is an inventor of 912 attended JEDEC meeting
and appeared to keep quiet about the 912 patent application. Hard for him to
claim that he did not know ? It would be useful for goog to get 912 thrown out
based on netlist cheating and focus only on 386. Don’t you agree with that strategy ?
In my cursory reading of the two patents i.e. ‘386 and ‘912 I couldn’t find any serious difference between them. I suspect the only reason NLST refers to the ‘912 patent is that it is the newest incarnation of the ‘386 patent thread.
Read through the two patents (links above) and see if there is any difference there.
I suspect GOOG was in a hurry to file an answer before the deadline. Lawyers are also new (with changing of law firms). It is possible they just put some boilerplate stuff and threw in the ‘912 specific comments fully knowing it doesn’t really save GOOG since they have not addressed the ‘386 patent (which is part of ‘912 patent thread – ‘912 being a continuation of ‘386).
‘386 patent was known to JEDEC. And disclosed by NLST in December 2007 (from GOOG timeline it seems after NLST did this, the JEDEC members STILL went ahead and finalized standard).
So why agree on standard despite finding out it infringes.
And why did GOOG initiate use of infringing IP without first securing licensing rights from NLST ?
There is something deliberate about this.
Plus we don’t have full information about the leakage at Texas Instruments (and possibly Bill Gervasi and others who had worked at NLST at time of invention and later worked at JEDEC or STEC).
In addition MetaRAM was patenting stuff throughout this period. Would have known about competitors’ IP.
INTC was doing FB-DIMM with 4-rank/quad-rank presentations at JEDEC – it is naive to think they didn’t do patent searches on this area ahead of time.
It is naive to think that just because NLST employees delayed “mentioning” patent continuation applications (’912 was a patent continuation of ‘386 patent) which maybe routine in the industry, that that somehow impacts ability to know that ‘386 patent exists already.
quote:
Also any chance that Netlist gets thrown out of JEDEC (like Rambus) and loses the
opportunity to claim that their hypercloud modules are “JEDEC compatible” ?
I am not sure if NLST is even in JEDEC anymore. Wouldn’t surprise me to know they are not part of the memory module committee.
There is a difference between RMBS and NLST – RMBS were radical designs which required major changes (and cooperation by motherboard makers and slot architecture etc. type of stuff). NLST is a plug and play (and requiring no BIOS update) solution that works with existing systems. So NLST has considerably fewer hurdles than RMBS – and RMBS has done well both in court and in licensing.
Netlist,
I think Netlist offered 386 patent to JEDEC (court filing says there was a letter from Jack Bhakka ?) so
maybe 386 was not issue for JEDEC approval ? Only licensing had to be negotiated with Netlist. However
looks like 912 does not have such letter so there is a difference in disclosures ?
Texas Instruments and Gervase is interesting. Do you have any thoughts on how netlist can use
that for more $$ ?
quote:
I think Netlist offered 386 patent to JEDEC (court filing says there was a letter from Jack Bhakka ?) so
maybe 386 was not issue for JEDEC approval ? Only licensing had to be negotiated with Netlist. However
looks like 912 does not have such letter so there is a difference in disclosures ?
Texas Instruments and Gervase is interesting. Do you have any thoughts on how netlist can use
that for more $$ ?
Basically JEDEC knows standard falls awry of NLST ‘386 patent.
Same for GOOG – which actually went ahead and used it – without paying a dime to NLST, or bothering to discuss it with NLST. GOOG may even have been the mover behind the other players to bypass NLST (if NLST claims are right – i.e. encouraging others to infring NLST IP i.e. companies it dealt with, encouraged to manufacture the memory and maybe even MetaRAM).
You realize GOOG complaining “we didn’t know of ‘912 patent application” has the response that NLST just reverts to ‘386 patent in it’s arguments.
This is what I was saying – that GOOG nitpicking on the “we didn’t know about ‘912″ is suggestive that they have no substantive argument against ‘386 patent and they make that case as a short-term strategy. That is, biding time till settlement or what ?
quote:
Texas Instruments and Gervase is interesting. Do you have any thoughts on how netlist can use
that for more $$ ?
I am not sure about Bill Gervasi – I dropped that name just to highlight that there is considerable promiscuity in this niche area with people moving from one company to another company and JEDEC etc.
So the argument that people are not aware of patents is misleading (esp. after what happened with JEDEC/RMBS). Although initial patent applications may not be visible to others.
Gervasi the “inventor” of “4-rank” (he is one of three patent authors) later went to work for STEC and chaired the JEDEC committee as well.
NLST vs. Texas Instruments is under the radar – perhaps because one needs to goto the court to get the documents (or have them mailed). Couldn’t find it on PACER.
http://www.faqs.org/sec-filings/091103/NETLIST-INC_10-Q/
NETLIST INC – FORM 10-Q – November 3, 2009
…
Trade Secret Claim
On November 18, 2008, the Company filed a claim for trade secret misappropriation against Texas Instruments (TI) in Santa Clara County Superior Court, based in TI’s disclosure of confidential Company materials to the JEDEC standard-setting body. On February 20, 2009, TI filed its answer. The parties are currently engaged in settlement discussions. If those discussions are unsuccessful, the Company expects to vigorously pursue its claims against TI.
Court website:
http://www.sccaseinfo.org/civil.htm
Search – enter “netlist” for business name.
Gives the result:
Netlist, Inc. 1-08-CV-127991 Netlist, Inc. Vs Texas Instruments, Incorporated Intellectual Property – Unlimited
Which leads to:
http://www.sccaseinfo.org/pa6.asp?full_case_number=1-08-CV-127991
However it doesn’t seem to be on PACER, and seems to require going to court to get documents copied (or via mail).
Maybe someone will be interested enough to get a copy of the documents (will shed light on the goings on at JEDEC/Texas Instruments).
This seems to be an example of TXN (Texas Instruments) doing something similar to what Inphi is doing. That is, a buffer chip for “quad-rank/4-rank”.
So does this make TXN similar to Inphi and others – i.e. if “4-rank/quad-rank” is what makes it infringing ?
http://news.thomasnet.com/fullstory/818452
DDR3 Register is designed for memory modules.
DALLAS (April 15, 2008) – Texas Instruments (TI) (NYSE: TXN) today announced the industry’s first full production release of a phase locked loop (PLL) integrated DDR3 register for registered dual in-line memory modules (RDIMMs). This device enables system stability through constant clock and output delay over voltage and temperature variation. The single-chip quad rank support saves overall board space and reduces power consumption in servers, work stations and storage equipment. (See http://www.ti.com/sn74ssqe32882-pr.)
…
TXN’s SN74SSQE32882 datasheet:
http://pdf1.alldatasheet.com/datasheet-pdf/view/250017/TI/SN74SSQE32882.html
http://focus.ti.com/docs/prod/folders/print/sn74ssqe32882.html
SN74SSQE32882 Status: ACTIVE
JEDEC SSTE32882 Compliant 28-Bit to 56-Bit Registered Buffer with Address-Parity Test
With Netlist announcing volume production and shipment of its leading productrs and generating cash flow, Netlist should continue extensive and vigorous discovery on Google to prosecute what NLST claims is willful patent infringement. If Netlist wins, this case would be a landmark case and Google’s stellar image and pocket book may be damaged. Such a win would promote smaller companies’ investment in R&D and innovation as proprietary technology for volume production and generate solid ROI like Netlist is attempting to do. Apple, HP and Dell appears to have recognized the value of Netlist as an innovative company in contrast to Google’s apparent assessment.
We should expect discovery dispute motions to reveal the extent of Google’s conduct. Google would undoubtedly file protective orders from having to turn over such documents. Since MetaRAM settled with Netlist, Google may be unable to deny meetings, collaborations, or claim non-existence of certain documents.
If there are settlement discussions, Netlist should consider that after a full disclosure from Google. It would be particularly interesting to know the extent of collaboration with MetaRAM, Intel, Inphi and others, if any.
If Netlist prevails after a jury trial, how much would the valuation expert articulate to the jury? If punitive or exemplary damages are awarded, will that have relevance to Apple’s litigation with HTC and implication to Google?
Both Hypercloud and NetVault product lines should generate substantial cash flow for several years to come as in below link. http://www.netlist.com/investors/investors.html
IRVINE, Calif., Feb. 17 /PRNewswire-FirstCall/ — Netlist, Inc. (Nasdaq: NLST), a designer and manufacturer of high-performance memory subsystems, today announces that a major OEM has commenced volume consumption of NetVault-NV™, a flash memory based non-volatile cache memory subsystem targeting RAID (redundant array of inexpensive disks) storage applications. NetVault-NV offers disaster recovery backup from system power failures and is optimized to ensure high system availability in RAID systems without using battery power for backup.
Simultaneously, within the same product family, Netlist also announces that it is also at mass production status with a major OEM with its NetVault-BB (DRAM memory) based product, Netlist’s third-generation RAID cache solution. NetVault-BB offers disaster recovery backup from system power failures and ensures high system availability.
NetVault-NV provides server and storage OEMs a solution for enhanced datacenter fault recovery, reduces system downtime and total cost of ownership. Unlike traditional fault tolerant cache subsystems, which rely solely on batteries to power the cache until the IT manager can recover business critical data and restore the system, NetVault-NV utilizes a combination of DRAM for high throughput performance and Flash for extended data retention. With NetVault-NV, data is retained for years following a disaster versus traditional subsystems, which often cannot preserve cache data for more than 24 to 72 hours.
“NetVault-NV delivers the reliability and performance demanded by end users while reducing the total cost of ownership for this high reliability disaster recovery solution by eliminating the need for battery backup power,” said C.K. Hong, President, and CEO of Netlist. “As the only available flash based merchant market solution, NetVault-NV is also now entering volume production with a tier one OEM. Joining our recently announced HyperCloud product line, the NetVault family further demonstrates Netlist’s leadership in solving critical problems for the datacenter through innovative value-added memory subsystems.”
This is LR-DIMM, move along, nothing to see here.
Will Google capitalize competitively by being the plaintiff and dragging this court case out as far as possible in order to freeze industry acceptance of Hypercloud technology or will it admit an error in assessment of Netlist’s intentions and settle so that Netlist can go
about its business of innovation. The latter would surely help other Google competitors become more efficient, cut cost and become more green. Maybe that’s Google’s strategy to stay ahead. Dragging this case out would be a cheap way to stay ahead of the competition. It could be a sign that Google is running out of original ideas and has no better business morals than any other big business. What ever it takes to stay ahead of the game.
Hi Auditor,
It would be interesting if this case went to a jury, but the vast majority of civil cases end with settlements.
At the heart of this dispute isn’t the quality or value of the products that Netlist has to offer, but rather whether Google has infringed upon their patented technology. I don’t know the answer to that, but then again, I’ve never claimed to have any particular expertise in memory modules. I also don’t know what impact a legal victory over Google would have to how potential customers might treat Netlist in the market, or the impact on Apple’s litigation with HTC.
Hi Billy,
I wrote this post about Google’s unusual acquisition of a large amount of memory module technology from Metaram. The purchase is still somewhat of a mystery.
I did take a look on the 25th last month in a Second Amended Joint Case Management Conference Statement (pdf) that I viewed, and it referred to “four-rank FBDIMMs” as being at the heart of the dispute. The conference was scheduled for March 4th, and I haven’t gone back yet to see what might have happened during that conference.
I am interested in why you state that this dispute involves LR-DIMM, and what the implications of that would be if it did. I’m also not sure what interest you have in telliing visitors to this blog “Nothing to see here. Move along.” If you’d like to share, I’d be happy to listen. Thanks.
Hi spencity.
Possibly, but if I were in Google’s shoes, I would hate having to rely upon attempting to delay pending litigation as a tactic for hindering competitors.
I do see a lot of the patents and whitepapers that Google publishes, and try to keep up with the technology that they hint at and release in other areas. It does seem like they still have more than a couple original ideas coming out of their Mountain View headquarters.
Minor update on court cases.
NLST vs. GOOG:
- NLST filed answer to GOOG counterclaims in NLST vs. GOOG – nothing special there, just that NLST saying GOOG can’t claim NLST did this or that, when GOOG CONTINUED to violate NLST IP even after knowing about it, when JEDEC was told the new JEDEC standard violated NLST IP.
NLST vs. TXN:
- NLST filed some papers in NLST vs. TXN (Texas Instruments) – can’t get to it via PACER. Would be interesting to the contextual information in that case.
http://www.sccaseinfo.org/pa6.asp?full_case_number=1-08-CV-127991
NLST vs. TXN
quote:
Will Google capitalize competitively by being the plaintiff and dragging this court case out as far as possible in order to freeze industry acceptance of Hypercloud technology or will it admit an error in assessment of Netlist’s intentions and settle so that Netlist can go
about its business of innovation.
quote:
It would be interesting if this case went to a jury, but the vast majority of civil cases end with settlements.
The case is unlikely to go before jury trial – and may end much earlier because discovery will start to tackle issues with GOOG e-mail and what employees knew and when knew. If GOOG is going to settle, there is no point waiting.
Meanwhile by “dragging it out”, it does no harm to NLST OR to the competition using NLST memory (I also doubt that is the way GOOG will go about it – since it is a negative way of doing things which does not fit GOOG culture and is a defensive measure rather than a proactive measure).
The reason is that NLST is not waiting for JEDEC approval, or some “industry approval for a certain format” to “gain acceptance” – NLST HyperCloud memory modules are “plug and play”, require no BIOS update, and require no changes to the motherboard (like CSCO’s UCS strategy has motherboard changes to accomplish something similar).
So GOOG delaying it’s approval just deprives NLST of business at GOOG. But it also delays GOOG ability to participate in NLST HyperCloud memory qualification and participation. With MetaRAM (the biggest player with industry support from Intel and others) gone, there are few options available in the market (apart from building their own memory as GOOG seems to have been doing ? or were they using MetaRAM ?). GOOG use of NLST HyperCloud is a natural fit, and GOOG would deprive ITSELF of opportunity to use it (while prolonging their infringing NLST IP), while all the competition could start using it right now.
In addition, in the event of a failure, GOOG loses face, loses the case, treble damages, humiliation among the “do no evil” crowd, evisceration of old infringing memory from GOOG servers, perhaps even court audit of GOOG servers to see which are infringing which are not (to calculate damages).
In fact GOOG gains FAR more by doing a nice deal with NLST. Probably will get excused for using infringing memory and can continue to use that – so no disruption to GOOG servers either.
To be noted is GOOG’s under the radar behavior in this matter as well – the matter of who made the memory for GOOG – NLST accuses GOOG of “rallying the troops” in infringing NLST IP – and GOOG MAY have played a part at JEDEC rallying memory module makers to ignore NLST IP violations.
It is intruiging how MetaRAM claimed they had “destroyed” the infringing memory products and it was worth only a small amount. This was very odd, given they were the darlings of the industry – INTC and other supporting, they were to supply major memory module makers with the buffer chips.
So the story is not as crystal clear regarding GOOG’s behavior – possibly due to the conflict created by a hardware division that thought it could do things inhouse without caring about NLST IP.
So in summary – in stark contrast to what USUALLY happens in such cases i.e. big company stringing small company along until they fail – THAT type of leverage is NOT available to GOOG in this case.
Time is not on GOOG’s side, both in terms of escalation of severity, but also in terms of loss of access to NLST HyperCloud (which is a match for high memory-loaded systems). Using HyperCloud allows this niche area (servers running virtualization needing lots of memory, search function as at GOOG and such applications) to reduce the hardware you need (i.e. cases where CPU is too powerful, but not enough memory – so new server farms cannot capitalize on new CPUs with multiple cores if are limited by the memory loading capability of current systems – can’t load memory without reducing achievable speed – HyperCloud allows to bypass that problem).
HyperCloud helps in:
- reducing power requirements (memory module turns off banks that are not in use on the memory module)
- greater memory-loading at same bandwidth (as you load memory, electrical issues limit the max speed achievable)
- costs less – NLST uses “lower dollar per bit” memory chips to emulate “higher dollar per bit” memory chips. That is, can make a 16GByte module using 2GBit memory chips. If you don’t use the NLST IP, you have to use 4GBit memory chips. Since memory pricing is not linear it is a major cost savings for NLST – 4Gbit memory chips cost MORE than 2x what a 2Gbit memory chip costs.
In TXN case, I noticed that the ex parte motion from Netlist was granted. Ex parte motion needs special urgent circumstances. That would be interesting to know what TXN is trying to compel NLST to produce.
Today’s volume peaked over 8 mil shares which is curious. There has been no substantiated rumors. It would help to know which major OEM is doing volume consumption or signed for volume production. Cisco or Google seems far fetched at this point. Any recent transactions with Intel, AMD, Apple, Hynix, Samsung?
quote:
Today’s volume peaked over 8 mil shares which is curious. There has been no substantiated rumors. It would help to know which major OEM is doing volume consumption or signed for volume production. Cisco or Google seems far fetched at this point. Any recent transactions with Intel, AMD, Apple, Hynix, Samsung?
There was a rumor today about CSCO/NLST linkup. The relations is more combatitive though since NLST solution-on-memory-module trumps CSCO’s UCS strategy (where they have to modify the motherboard to do the same thing – thus also rendering it non-standard).
Here’s a much-repeated article which compares the two:
http://www.theregister.co.uk/2009/11/11/netlist_hypercloud_memory/
Netlist goes virtual and dense with server memory
So much for that Cisco UCS memory advantage
By Timothy Prickett Morgan
Posted in Servers, 11th November 2009 18:01 GMT
It also doesn’t help that NLST has extremely small float – by calculation on yahoo board, it is like 4.79M to 7.13M that are unaccounted for if you exclude management and fund holdings. Total outstanding shares nearly 20M.
http://messages.finance.yahoo.com/Stocks_%28A_to_Z%29/Stocks_N/threadview?m=tm&bn=51443&tid=13357&mid=13357&tof=1&frt=2
analysis of NLST float (from recent filings)
Of those 4.79-7.13M shares, subtract the smaller shareholders and the ones who post on message boards and you have substantially fewer shares available.
Just more reiteration of background info.
http://www.wsw.com/webcast/needham35/nlst/
Needham Growth Stock Conference
January 14 at 2:30 pm ET (Jan 14, 2010)
Corporate Presentation
Needham Conference January 2010
http://www.b2i.cc/Document/1941/Netlist_Needham_Conf_Jan_2010.pdf
In this Needham presentation, CEO Hong outlines the factors at play:
Servers traditionally have 24 sockets, most with 18 sockets.
If populate half of those sockets i.e. 9 sockets, your achievable memory speed goes down from 1333 MHz to 1067 MHz. The more memory you add the LOWER the achievable speed.
So for modern CPUs with multiple cores, it is the MEMORY which is holding it back.
NLST HyperCloud allows to pack all the sockets and STILL run at 1333 MHz.
From presentation above – get “100% more capacity at 66% higher memory speed” (probably with all sockets full, competitors run at 800 MHz, so 1333/800 = 1.66 – so 66% higher memory speed).
HyperCloud also uses register and isolation devices to shut down power to certain DRAM devices when not in use, thus reducing power. For heavily memory-loaded servers, memory power consumption is significant.
HyperCloud “tricks” the system into thinking of two 1Gbit memory chips as a 2GBit memory chip. Thus using “lower dollar per bit” memory chips instead of higher ones. PLUS this advantage always remains with NLST – as new higher density memory chips arrive, NLST can use the second tier memory chips (which will always be cheaper) to achieve same performance.
HyperCloud is plug and play, requires no BIOS changes, and not changes to motherboard (which WOULD have required dealing with JEDEC and standardization and getting partners on board and such complications). HyperCloud requires no such thing – and can be used interoperably with regular memory.
CEO Hong says done studies with OEMs – double memory capacity which increases efficiency by 50% – fewer serers required to do the same job in data centers/cloud computing.
Heavy memory-loaded servers – memory cost is significant, so using cheaper memory is advantage.
Billy,
“3 Advantages of Designing with Micron LRDIMMs”. That statement was made on a Micron Technology promotional web page soliciting OEMs to use their new DOA LRDIMM memory module. That seems to imply that LRDIMMs are not plug n play with current jedec standards, but would complete in a market with Hyper Cloud which is plug n play. I say DOA, because Micron is asking OEMs to design their systems around the memory modules and set new standards that Mircron would need. HyperCloud is plug and play. OEMs can spend their development budget on increasing bus speeds rather than accommodating new standards. I wonder what HyperCloud’s max speed realy is since it can handle todays max bus speeds according to Netlist. Also, Mircon is using buffer chips from Inphi that Netlist has contested as infringing on their IP and is under litigation. The IP enabling speed and efficiency along with 4 rank memory addressing are all claimed by Netlist. The courts may have the final say, unless there is a settlement before hand. Micron seemed to be well into development late 2009 until the Netlist vs Inphi case was initiated. Where is Micron in development of their LRDIMM modules. Is that the “Nothing” to which you are eluding?
Current servers can enjoy significant upgrades in efficiency and power by simply switching to HyperCloud. Can LRMDIMMs claim that?
HyperCloud benefits usually if have heavily memory-loaded systems.
On home-built systems you can overclock the computer and use higher speed memory also I guess.
However the area HyperCloud is targeting is populated by speeds starting at 1333 MHz but decaying rapidly as you fill up memory slots.
As outlined in above March 9 post, for 18 memory slot motherboards at 1333 MHz speed, as you fill 9 slots you are forced to run at 1067 MHz. When you fill all 18 slots, you have to run at 800 MHz (which is the “66% higher memory speed” figure which NLST quotes).
So for high memory-loaded servers, the advantage of having a fast CPU is negated as you add more memory.
NLST allows you to run with all 18 slots at the full 1333 MHz.
The power efficiency and cost advantages are additional.
Routine settlement conference in GOOG vs. NLST set for April 30, 2010 at 9:30am in front of Magistrate Judge (Elizabeth D. Laporte). Laporte was the judge both GOOG/NLST agreed on after Judge Trumbull was not available.
quote:
It is not unusual for conferences to last two to three hours or more. No participant in the settlement conference will be permitted to leave the settlement conference before it is concluded without the permission of the settlement conference judge.
Parties are encouraged to participate and frankly discuss their case. Statements they make during the conference will not be admissible at trial to prove or disprove liability in the event the case does not settle. The parties should be prepared to discuss such items as their settlement objectives, any impediments to settlement that they perceive, whether they have enough information to discuss settlement and, if not, what additional information is needed and the possibility of a creative resolution of the dispute.
I keep on feeling like some kind of surprise is going to jump out of this litigation. Not sure exactly what, but that’s the feeling I have.
Did anyone here get a copy of the transcript from the Roth OC Growth conference yesterday? If so can you post it somewhere?
I tried listening to the audio but the quality was terrible.
Hi Fallguy,
I don’t know if anyone publishes transcripts from that particular conference, but for anyone interested in trying to listen, I’m guessing it might be possible to sign up and do so from the Roth web site:
http://www.roth.com/main/page.aspx?PageID=7228
It would be amazing if Netlist did not search for other partners after they were rebuffed by Google. They are a very ambitious company given the development of their recent products. They could be pursuing multiple paths to growth. Their HyperCloud module has widened data processing bottle neck. Its maximum speed may be greater than 1333MHz. Its possible that the same Netlist IP used to speed up a memory data bus could be used elsewhere in a digital circuit hereby increasing data processing/ routing speed. Mr. Chung Ki Hong was once president and CEO Infnilink that manufactured routers and other data equipment. I wonder if that was the bases of the rumor started earlier this week that Netlist collaborated with Cisco in the development of their new super router? Just food for thought. Facts are hard to come by until official news releases.
It is possible that CSCO is using NLST IP for loading lots of memory into the router they produce, however that would require conventional motherboards being used (don’t know if they are in that product), and a longer standing relationship between CSCO and NLST than we are aware of.
Secondly CSCO UCS strategy is neutered by NLST HyperCloud – CSCO UCS server have motherboards with the same type of circuitry except it is in the motherboard, thereby allowing greater loading of memory. NLST has all that on the memory module itself, thereby making them plug and play and not dependent on any widespread adoption of newer standard for motherboard etc.
So they are competitors in that aspect at least. Don’t know how that affects the rumored collaboration story.
My own feeling is that the rumor is misleading – i.e. someone expecting something from NLST and it got ascribed to CSCO radical new product announcement.
Or it could be that CSCO is using NLST’s NetVault product – since routers include battery-backed RAM to store configuration information, it could be that they have chosen NLST’s NetVault product to do that instead of the standard battery-backed RAM. NLST’s NetVault backs up the memory information in the volatile RAM to flash memory (located on the same memory module) – the power required to do this quickly after power failure is supplied by a “supercapacitor” instead of batteries (thus reducing periodic replacement of batteries by on-site personnel).
NLST NetVault could be very useful in products that are consumer-oriented – since while battery-backed stuff worked for data centers where they have personnel, there would be consumer applications which may open up once manufacturers know they CAN design products that don’t require battery maintenance to retain integrity of the device (i.e. manufacturer’s startup settings).
Bill
I got the transcript. Completely useless and unreadable. What I gathered was
pretty much no new news – no OEM orders or any other news on litigation (at
least in the transcript) !
quote:
I got the transcript. Completely useless and unreadable. What I gathered was
pretty much no new news – no OEM orders or any other news on litigation (at
least in the transcript) !
That must have been one piece of creative writing (given the audio was so hard to decipher).
Here is a bit of the transcript:
And also a proceeding of major – operation to our department on the resulting on – the post office and important to maintain that – and we feel also – and the worldwide combined the – by holding certain of that and many to both number of – dollar material future to the proliferation of our computing and revolving traffic. And we are going to be – the workforce advice business makes anything. Do you think to create a huge computing and message do well?
On Planet Earth,
What worries me is no news of successful evaluations or status at OEMs.
Netlist – is this delay with no news reasonable ? Or is there some problem with the hypercloud solution ?
netlist
Does Netlist have known relationships with any top tier OEMs?
In conference audio, CEO Hong has mentioned “customers historically been”:
IBM
DELL
HP
Their SEC filings have mention of these OEM relationships.
In addition NLST used to supply memory to AAPL – so was considered good quality producer of memory.
The Register has come out with a newer piece on NLST – this time calling the raising of $15M as indicative of Wall Street confidence in the company’s technology:
http://messages.finance.yahoo.com/Stocks_%28A_to_Z%29/Stocks_N/threadview?m=tm&bn=51443&tid=14629&mid=14629&tof=1&frt=2
Netlist’s HyperCloud memory gets Wall Street’s blessing
Raises $14.1m in stock sale
By Timothy Prickett Morgan
Posted in Financial News, 23rd March 2010 06:02 GMT
Sorry that was the yahoo board thread discussing that article.
Here’s the direct link:
http://www.theregister.co.uk/2010/03/23/netlist_public_float/
Netlist’s HyperCloud memory gets Wall Street’s blessing
Raises $14.1m in stock sale
By Timothy Prickett Morgan
Posted in Financial News, 23rd March 2010 06:02 GMT
You will recall the earlier piece by theregister which is probably the best explanation so far for NLST HyperCloud:
http://www.theregister.co.uk/2009/11/11/netlist_hypercloud_memory/
Netlist goes virtual and dense with server memory
So much for that Cisco UCS memory advantage
By Timothy Prickett Morgan
Posted in Servers, 11th November 2009 18:01 GMT
quote:
In addition NLST used to supply memory to AAPL – so was considered good quality producer of memory.
This was before NLST did the restructuring (i.e. deemphasizing conventional memory which was a lossmaking operation for most memory producers at that time) and went on that prolonged effort to create what we now know as HyperCloud and NetVault – and the move to Suzhou, China (which seems to be a memory producing hub).
NLST states that nearly 50% or so of their customers are in China – whether that is China-China or HP or other OEMs factories in Suzhou is unclear (since many U.S. companies operating in China). Reason for shift to Suzhou given was also that “we needed to be closer to our customers” or something like that.
quote:
Reason for shift to Suzhou given was also that “we needed to be closer to our customers” or something like that.
And reduction in production cost.
Probably easier to source memory chips also – since most of the memory producers are there as well – Hynix and others.
NLST HyperCloud will be using Hynix memory chips (in the first batch at least).
Updates on GOOG vs. NLST.
From the following thread on NLST yahoo board:
http://messages.finance.yahoo.com/Stocks_%28A_to_Z%29/Stocks_N/threadview?m=te&bn=51443&tid=14733&mid=14811&tof=1&frt=2#14811
Re: update on the various court cases 2 .. GOOG infringing memory
We now know what types of infringing memory GOOG was using and who their contract manufacturers were (from court filings in GOOG vs. NLST – dockets 113 and 114).
NLST has outlined the info collected from the depositions they have been taking from GOOG employees.
From docket 113 (113-1):
12. Through the 30(b)(6) testimony of Google, Netlist was able to learn several
key pieces of information that inform and serve as the basis for the proposed infringement
contention amendments. I took both depositions. Because Google designated the transcripts
as “Confidential- Attorney’s Eyes Only,” they are not being submitted herewith to avoid the
necessity to file them under seal. The corporate testimony that Netlist was finally able to
obtain from Google during February and March 2010 included the following:
• the identity of the different 4-Rank FBDIMMs supplied by Google and
their part numbers;
• the specific serial signal protocol used by Google’s “logic element”
component of the accused 4-Rank FBDIMMs (called an “Advanced Memory Buffer” or
“AMB”) and the manner in which the logic element is informed about the rank to which
command and address signals are to be directed;
• the maximum number of memory ranks to which control and command
signals received by Google’s 4-Rank FBDIMMs may correspond;
• Google’s use of infringing eight gigabyte (“8GB”) 4-Rank FBDIMMs
and 2GB 4-Rank FBDIMMs in addition to 4GB 4-Rank FBDIMMs;
• the manner in which Google’s AMBs generate output command signals
such as row address strobe (“RAS”) signals, column address strobe (“CAS”) signals, and
write enable (“WE”) signals to a selected rank of memory to execute DRAM commands such
as read, write, refresh, precharge, etc.;
• the specific AMB part numbers and suppliers used by Google;
• the identity of the contract manufacturers who have assembled 4-Rank
FBDIMMs for Google;
• Google’s receipt of a letter from Netlist to JEDEC in January 2008
which identified the ‘386 Patent and its relationship to the JEDEC AMB Quad Rank Support
Standard that Google admits to practicing and Google’s actions in response to the Netlist
letter;
• Google’s admission that the AMB is a form of an application specific
integrated circuit (ASIC);
• Google’s use of edge connectors on its 4-Rank FBDIMMs to connect
the modules to memory slots in its servers.
Regarding pg. 4 (see below) mention of “Ilium” and “Icarus” servers, don’t know if this is a class of server, or are the specific servers that GOOG was asked to turn over to NLST for examination (which led to discovery of “Mode C” usage – being smoking gun for “4-rank/quad-rank” use).
Searching google for those server names, turned up this:
http://ruscoe.net/google/google-subdomains-internal/
Google’s Internal Subdomains
…
icarus.corp.google.com (7 May 2007)
ilium.corp.google.com (7 May 2007)
…
Regarding pg. 7 (see below) we see some of the contract manufacturers:
Unigen
Southland Microsystems
Kingston
Qimonda
Entorian
The timeline while known before, is spelled out again below – it shows that GOOG was caught in the headlights when NLST addressed it, and rather than deal with it, went to court instead to create an orderly environment for settling this issue (which is behind the server technology GOOG is using).
From docket 114 (114-4) for case GOOG vs. NLST:
(pg. 4)
… Based on the information presently known to Netlist, the Accused Instrumentalities include memory modules bearing the following names and/or model numbers:
1) 4-Rank, 2GB FBDIMMs: iGooFMM2, 07000752, 07000753, 07000754, 07000755, 07001780, 07001853, 07001834, 07002739, K17000752-753, K107000752-754 K107000752-755, S107000752-780 G107000752-853, G107000752-854, S107000752-739 S107000752-854:
2) 4-Rank, 4GB FBDIMMs: iGooFMM44, 07000763, 07000764, 07000765, 07000766, 07001779, 07001852, 07002028, 07002028, 07002255, K107000763-764, K107000763-765, K107000763-766, S107000763-779, Q107000763-852, G107000763-028, Ql07000763-255, S107000763-028, iGooFMM4LP, 07005903, S107000763-xxxLP, and
3) 4-Rank, 8GB FBDIMMs: GooFMM8, GooFMM8Q, 07002964, 07002970, QZ07002964-970.
Google infringes the ‘386 Patent as follows:
1. By making, using and/or importing the Accused Instrumentalities, including by operating computer servers known as “Ilium” and “Icarus” in which the Accused Instrumentalities have been installed.
(pg. 5)
4. By supplying components of the Accused Instrumentalities–including DRAM chips, quad-rank supported advanced memory buffers, and printed circuit boads–to third party contract manufacturers who make 4-Rank FBDIMMs for Google’s use, at Google’s request, and as instructed by Google, Google is actively inducing infringement ..
(pg. 7)
… The contract manufacturers include Unigen, Southland Microsystems, Kingston, Qimonda and Entorian. Google has instructed the contract manufacturers in the assembly of the Accused Instrumentalities with knowledge of the ‘386 Patent and intent of causing the contract manufacturers to directly infringe the ‘386 Patent.
(pg.
(h) Basis for Assertion of Willful infringement (PLR 3-1(h))
The basis for Netlist’s assertion of willful infringement includes the following:
During 2007. Google had 4-Rank FBDlMMs assembled for it by its contract manufacturers and used the modules in its data center computer servers.
Google was aware that the FBDIMMs were quad-rank enabled and understood that the modules utilized a quad-rank enabling method set forth in an Intel proposal called “AMB Quad Rank Support.”
During late 2007, Google attended one or more JEDEC meetings at which Netlist announced that it may have intellectual property that might cover the Intel AMB Quad Rank Support proposal. Nevertheless. Google made no inquiry about the Netist IP and abstained from voting on the Intel proposal to conceal its use of quad-rank enabled AMBs from other JEDEC members.
In January 2008, Google received a letter from Netlist to JEVEC which identified the ‘386 Patent by number and which stated that the 386 Patent might be required to implement “Mode C” of the AMB Quad Rank Support standard. Google has admitted to using Mode C in its 4-Rank FBDIMMs.
In May 2008. Netlist wrote to Erick Schmidt, Chairman of the Board and Chief Executive Officer of Google, and informed Mr. Schmidt that Netlist had reason to believe that Coogle was using the technology claimed in the ‘386 Patent in its computer servers.
Along with the May 2008 letter, Netlist provided Mr. Schmidt with a copy of the ‘386 Patent. Google never responded to the May 2008 letter.
On June 4, 2008. Netlist’s counsel wrote to Mr. Schmidt again, stating that that Google had not responded to the May 2008 letter and again identifying the ‘386 Patent to Mr. Schmidt. A copy of the May 20 letter and its attachments accompanied the June 4. 2008 letter.
Google did not respond to the June 4. 2008 letter. Thus on June 19, 2008, counsel for Netlist again wrote Mr. Schmiot and again attached the May 2008 letter and a copy of the ‘386 Patent.
In July 2008, Netlist met with Google and made a presentation to Google’s counsel describing the ‘386 Patent and its relationship to the JEDEC AMB Quad Rank Support Standard. On August 28. 2008, Google filed this lawsuit.
Despite being put on repeated notice concerning the ‘386 Patent and the infringement of its 4-Rank FBDIMMs, Google continued to have infringing modules made for it and continues to use them even now. There is no evidence that Google has obtained an opinion of counsel of non-infringement or invalidity or that it has taken any step to avoid infringing the ‘386 Patent.
Netlist:
Great job as usual.
Given the delayed response by GOOG and the type of response they chose, I surmise that GOOG was using so many suppliers and the use of NLST IP was so extensive and that they not only needed time but that a stoppage of the use of the NLST IP would have been detrimental to the everyday operations of GOOG.
That said, Since GOOG would be one of, if not, the biggest customer’s of this NLST IP that a cash settlement and additional considerations could be realistic.
Do you see any chance of a settlement announcement prior to the hearing on the 30th?
quote:
Do you see any chance of a settlement announcement prior to the hearing on the 30th?
I suppose that is possible, but no way to know.
If I were GOOG I would settle early and get moving with NLST HyperCloud.
GOOG lawyers may have other ideas though.
Thank you for the updates, netlist.
It’s hard to tell where this might eventually end up going, even with the facts that have come out so far.
Not directly related to the NLST/GOOG legal thread here, but continuing earlier post above about GOOG data center construction:
http://www.seobythesea.com/?p=3097#comment-237024
here is a video presentation of GOOG data center:
http://www.greentechies.com/blog/2009/04/08/video-googles-energy-efficient-data-center/
Video: Google’s Energy Efficient Data Center
quote:
CNET’s Stephen Shankland collected a bunch of Google produced videos on YouTube that discuss Google’s energy efficient container data centers…
YouTube tour reveals Google data center designs
netlist,
The bullet points that you posted seem to strongly support Netlist’s arguement and gives Google little hope of winning a judgement. Are you aware of any testimony or evidence presented by Google that would give thim a credable chance of obtaining a judgement in their favor?
netlist
The bullet points I refered to in the previous message is from docket 114 (114-1)
Hmm .. the previous post is confusing, reposting it below with some separators
quote:
The bullet points that you posted seem to strongly support Netlist’s arguement and gives Google little hope of winning a judgement. Are you aware of any testimony or evidence presented by Google that would give thim a credable chance of obtaining a judgement in their favor?
Docket 113 is where NLST amendment to charges against GOOG (thanks to facts unearthed in discovery – part numbers, contractors GOOG was using etc.).
From docket 113:
—–
(pg. 8 )
Specifically, a significant part of the non-public material discovered by Netlist
was obtained from the Rule 30(b)(6) deposition of Google’s staff design engineer, Rob
Sprinkle, whom Google promised to produce at the beginning of January yet ultimately
refused to produce until February 18, 2010. Hansen Dec. at ¶ 11. As described above,
Google also was “unable” to provide key information in response to Netlist’s written
discovery concerning the structure and operation of the accused 4-Rank FBDIMMs, and
refused to provide any specifics in its non-infringement contentions.
—–
Circumstantially, GOOG behaviour has been one of evasion. For example they did not answer NLST challenge with even a counter claim, but instead went rapidly to court (GOOG vs. NLST). It is possible that GOOG thought the case was indefensible (cannot give any answer) and so they took it to the court forum immediately.
This excerpt gives some sense of recent happenings, and you can get a flavor for the types of defence GOOG is mounting from this:
From docket 113-1:
—–
(pg. 2 )
After assuming responsibility for this case, Netlist’s current counsel began
reviewing hundreds of thousands of pages of information produced by Google and serving
written discovery directed to the structure and operation of Google’s accused 4-Rank
FBDIMMs. On September 10, 2009, Netlist served its second set of interrogatories and first set of requests for admission on Google. The requests for admission were directed to several pieces of infringement information, including the nature of the specific electrical signals received by the logic element (called an “advanced memory buffer” or “AMB”) of Google’s accused 4-Rank FBDIMMs.
Attached as Exhibit B hereto is a true and correct copy of Plaintiff Google Inc.’s Responses to Netlist’s Request for Admissions Set No. One [Nos. 1-26],” dated October 27, 2009 (“Google Response to Netlist’s RFAs”). As set forth therein, Google stated that it could not respond to Requests Nos. 6, 11, 13, 14, 16, 17, 19, 21, 23, 24, 25, and 26 concerning its own 4-Rank FBDIMMs because it “lack[ed] sufficient information.” Id. at 8, 11-15 (Request Nos. 6, 11, 13, 14-17, 19, 21, 23-26)
6. Attached as Exhibit C hereto is a true and correct copy of “Plaintiff Google
Inc.’s Responses to Netlist’s Interrogatories, Set No. Two [Nos. 6-9],” dated October 27, 2009. As stated at page 5 therein, Google identified Robert Sprinkle as an employee who is knowledgeable about the structure and operation of the accused 4-Rank FBDIMMs and gave the following answer as to why it contends that its 4-Rank FBDIMMs are allegedly non-infringing:
Google does not infringe any claim of the ‘386 patent because one or more
elements required to be present by each claim is missing from Google’s accused
products, both literally and under the doctrine of equivalents. For example, the
accused products do not include a structure that meets the “logic element”
limitation because they nowhere include the functionality that is claimed in that
limitation.
7. On November 8, 2009, Netlist accepted Google’s offer to produce Mr.
Sprinkle for deposition on January 8, 2010. Google also insisted that Netlist simultaneously
depose Mr. Sprinkle in his individual capacity and under Rule 30(b)(6) concerning the
“structure, function and operation of the accused Google instrumentalities” on the agreed-upon date. Attached as Exhibit D is a true and correct copy of an e-mail from me to Shelly K. Mack of Fish & Richardson as well as Ms. Mack’s November 15, 2009 response thereto concerning the foregoing.
8. On December 4, 2009, Netlist filed a patent infringement lawsuit (Case No.
09-05718-SBA) against Google alleging infringement of U.S. Patent No. 7,619,912 (the
“’912 Patent”), which had just been issued by the United States Patent & Trademark Office on November 17, 2009. The ‘912 Patent is a continuation of the ‘386 Patent that is at issue in this case. In the present action, Netlist filed an Administrative Motion to Consider Whether Cases Should Be Related and Consolidated under Civil Local Rule 3-12 on December 17, 2009 (Document 83). Along with the motion, Netlist filed a joint stipulation signed by both parties requesting consolidation of this case and Case No. 09-05718-SBA. After the Court related but did not consolidate the cases, the parties filed a Joint Motion to Consolidate Cases, on January 6, 2010. Document 85. The Court denied the consolidation motion on February 3, 2010. Document 95.
9. On December 29, 2009, Netlist contacted Google and informed Google that in
the Court’s order relating this case and Case No. 09-05718-SBA the Court had not ordered
consolidation of the cases. Netlist also requested that Google identify the topics to which Google’s 30(b)(6) witnesses would testify, and in particular, those to which Mr. Sprinkle would testify on January 8, 2010. In response, Google informed Netlist that it would not produce any witnesses for deposition until the Court ruled on the parties’ request for consolidation. Attached as Exhibit E hereto is a true and correct copy of an e-mail from Google’s counsel, Shelly Mack, to me dated January 4, 2010 stating the foregoing.
10. In view of Google’s actions, Netlist re-served its Rule 30(b)(6) deposition
notice and Mr. Sprinkle’s deposition notice on January 6, 2010. The notices set the date for Mr. Sprinkle’s deposition on February 4, 2010 and for the corporation under Rule 30(b)(6) on February 5, 2010. Attached as Exhibit F hereto is a true and correct copy of a letter from Lauren Gibbs of Pruetz Law Group to Shelly Mack of Fish & Richardson, dated January 6, 2010, along with the deposition notices for Robert Sprinkle and for the corporation under Rule 30(b)(6) which accompanied Ms. Gibbs’ letter.
11. In late January, the King & Spalding firm replaced Fish & Richardson as
Google’s counsel of record in this lawsuit. Mr. Sprinkle was not produced for deposition on
the previously noticed date of February 4, 2010. Instead, he was produced on February 18, 2010. Mr. Sprinkle was designated to testify to topics 1(a-m), 2, 6, 8, 9, 10, 11, 13, 16, 17, and 18 of Netlist’s Rule 30(b)(6) Notice, a copy of which is attached as Exhibit G hereto. In addition, Google produced Andrew Dorsey to testify to topics 3, 4, and 12 and to a portion of topic 5 on March 11, 2010. Attached hereto as Exhibit H is an e-mail from Scott Weingaertner of King & Spalding, dated February 14, 2010 specifying Google’s designations of Rule 30(b)(6) witnesses. Although Norm Haus is identified on Exhibit H, Google ultimately produced Andrew Dorsey in his place on March 18, 2010.
12. Through the 30(b)(6) testimony of Google, Netlist was able to learn several
key pieces of information that inform and serve as the basis for the proposed infringement
contention amendments. I took both depositions. Because Google designated the transcripts
as “Confidential- Attorney’s Eyes Only,” they are not being submitted herewith to avoid the
necessity to file them under seal. The corporate testimony that Netlist was finally able to
obtain from Google during February and March 2010 included the following:
• the identity of the different 4-Rank FBDIMMs supplied by Google and
their part numbers;
• the specific serial signal protocol used by Google’s “logic element”
component of the accused 4-Rank FBDIMMs (called an “Advanced Memory Buffer” or
“AMB”) and the manner in which the logic element is informed about the rank to which
command and address signals are to be directed;
• the maximum number of memory ranks to which control and command
signals received by Google’s 4-Rank FBDIMMs may correspond;
• Google’s use of infringing eight gigabyte (“8GB”) 4-Rank FBDIMMs
and 2GB 4-Rank FBDIMMs in addition to 4GB 4-Rank FBDIMMs;
• the manner in which Google’s AMBs generate output command signals
such as row address strobe (“RAS”) signals, column address strobe (“CAS”) signals, and
write enable (“WE”) signals to a selected rank of memory to execute DRAM commands such
as read, write, refresh, precharge, etc.;
• the specific AMB part numbers and suppliers used by Google;
• the identity of the contract manufacturers who have assembled 4-Rank
FBDIMMs for Google;
• Google’s receipt of a letter from Netlist to JEDEC in January 2008
which identified the ‘386 Patent and its relationship to the JEDEC AMB Quad Rank Support
Standard that Google admits to practicing and Google’s actions in response to the Netlist
letter;
• Google’s admission that the AMB is a form of an application specific
integrated circuit (ASIC);
• Google’s use of edge connectors on its 4-Rank FBDIMMs to connect
the modules to memory slots in its servers.
—–
You get the general impression that GOOG is not too eager to present their own employees’ side of the case (generally indicative of a fear that early discovery will only harm GOOG case) – this is especially odd given this case was brought by GOOG to protect itself against injunction (if NLST went to court to stop GOOG servers):
From docket 113:
—–
(pg. 5 )
Netlist also sought to obtain deposition testimony from Google concerning the
structure and operation of its accused 4-Rank FBDIMMs. Google identified Robert Sprinkle as “a person employed by Google who is knowledgeable about the structure and operation of the accused products.” Id. at 5. Google offered Mr. Sprinkle for deposition on January 8, 2010, and Netlist accepted. Hansen Dec. at ¶ 7, Exh. D. Google also insisted that Netlist simultaneously depose Mr. Sprinkle in his capacity as a fact witness and a Rule 30(b)(6) witness. Id.
In early December, Netlist filed a related lawsuit against Google (Case No. 09-05718-
SBA) alleging infringement of U.S. Patent No. 7,619,912, which had just issued on
November 17, 2009. Hansen Dec. at ¶ 8. Following the filing of the lawsuit, the parties jointly requested consolidation of this lawsuit and the ‘912 Patent lawsuit, which the Court ultimately denied on February 3, 2009. Hansen Dec. at ¶ 8. During the pendency of the request for consolidation, Google refused to produce any witnesses for deposition, including Rob Sprinkle:
Because the Court has not yet ruled as to whether two suits between the parties
will be consolidated, Google will not be presenting Mr. Sprinkle for deposition
on January 8th, and will not be presenting any witnesses for deposition (whether
in individual or 30(b)(6) capacities) until the scope of the case is clarified and, if
the cases are consolidated, a new schedule is entered. Fact discovery remains
open until the end of March, and there is no looming deadline that makes it
important for Netlist to take Mr. Sprinkle’s deposition in early January.
Hansen Dec. at ¶ 9, Exh. E (emphasis added). On January 6, 2010, Netlist again noticed Mr. Sprinkle’s fact and Rule 30(b)(6) depositions, this time for February 4-5, 2010. Hansen Dec. at ¶ 10, Exh. F.
In late January, Google replaced its counsel in this lawsuit, and Mr. Sprinkle was not
produced for deposition on February 4 or 5. Hansen Dec. at ¶ 11. Instead, he was ultimately produced on February 18, 2010. Hansen Dec. at ¶ 11. On March 11, 2010, an additional Rule 30(b)(6) witness, Andrew Dorsey, provided testimony about the manner in which Google induces the infringement of the ‘386 Patent by supplying contract manufacturers with components and directions for assembling 4-Rank FBDIMMs. Hansen Dec. at ¶ 11, Exh. H. Google designated both Mr. Sprinkle and Mr. Dorsey’s depositions as “Confidential – Attorney’s Eyes Only” under the Court’s Protective Order, contending that the information provided by the witnesses was not publicly available. Hansen Dec. at ¶ 13.
—–
You can conclude how clueful GOOG’s defence is about their own actions within GOOG from the above statement:
—–
quote:
As set forth therein, Google stated that it could not respond to Requests Nos. 6, 11, 13, 14, 16, 17, 19, 21, 23, 24, 25, and 26 concerning its own 4-Rank FBDIMMs because it “lack[ed] sufficient information.” Id. at 8, 11-15 (Request Nos. 6, 11, 13, 14-17, 19, 21, 23-26)
—–
And this statement:
—–
quote:
As stated at page 5 therein, Google identified Robert Sprinkle as an employee who is knowledgeable about the structure and operation of the accused 4-Rank FBDIMMs and gave the following answer as to why it contends that its 4-Rank FBDIMMs are allegedly non-infringing:
Google does not infringe any claim of the ‘386 patent because one or more
elements required to be present by each claim is missing from Google’s accused
products, both literally and under the doctrine of equivalents. For example, the
accused products do not include a structure that meets the “logic element”
limitation because they nowhere include the functionality that is claimed in that
limitation.
—–
From above-mentioned Exhibit C (GOOG response to NLST questions or “requests”) you can see the aspects that GOOG is avoiding answering at this time – giving a few of the responses that NLST claims (see above) GOOG was unable to answer below. In most of them, GOOG says it “lacks sufficient information” to answer questions about it’s own product:
From docket 113-1:
—–
(pg. 26 )
Subject to, without waiving, and based upon the foregoing objections, Google responds as follows: Google admits that certain FBDIMMs used in certain of its servers follow the Mode C serial channel communication protocol set forth in the JEDEC standard for the respective DRAM used on the DIMM To the extent not admitted, Google lacks sufficient information to admit or deny this Request. Google reserve the right to supplement or amend its response at an appropriate time.
—–
(pg. 29 )
REQUEST FOR ADMISSION NO. 11:
In certain of Google’s serves, at least one Google AMB receives bits (”Google’s AMB Input Bits”) from the server’s memory controller.
RESPONSE TO REQUEST FOR ADMISSION NO. 11:
Google incorporates by reference each of the General Objections. Google further objects to this Request as vague and ambiguous as to at least the terms “Google AMB,” “receives” and “memory controller.” Google further specifically objects to this Request on the basis of General Objection No. 2, above, concerning the “bit” terms.
Subject to, without waiving, and based upon the foregoing objections, Google responds as follows: Google lacks sufficient knowledge or information to admit or deny this Request at this time. Google reserves the right to supplement its response at an appropriate time.
—–
(pg. 10 )
REQUEST FOR ADMISSION NO. 13:
In certain of Google’s servers, at least one Google AMB receives DRAM Address Bits from the server’s memory controller.
RESPONSE TO REQUEST FOR ADMISSION NO. 13:
Google incorporates by reference each of the General Objections. Google further objects to this Request as vague and ambiguous as to at least the terms “Google AMB,” “Address Bits” and “memory controller.” Google further specifically objects to this Request on the basis of General Objection No. 2, above, concerning the “bit” terms.
Subject to, without waiving, and based upon the foregoing objections, Google responds as follows: Google lacks sufficient knowledge and information to admit or deny this Request at this time. Google reserves the right to supplement its response at an appropriate time.
—–
In Exhibit C we have GOOG responding to second set of questions by NLST. Here NLST asks reasons for why GOOG did not admit certain things in first set of questions:
From docket 113-1:
—-
(pg. 46 ) – Exhibit C
INTERROGATORY NO. 9:
For each request for admission that Ooogle did not admit in Netlist’s First Set of Reques4 for Admission of Plaintiff Google, inc., served September 10, 2009, please explain why Google did not admit the request, and identify all documents that support the basis for Google’s response to the request and persons with knowledge of the basis for Google’s response to the request.
RESPONSE TO INTERROGATORY NO. 9:
Google incorporates each of the foregoing General Objections as if set forth fully in response to this interrogatory. Google further objects to this interrogatory to the extent it calls for information protected by the attorney-client privilege, the work product doctrine or any other applicable exemption from discovery. Google further objects to this interrogatory as over broad, unduly burdensome, and duplicative to the extent it requests Google to re-state information that it has previously provided, or is concurrently providing, elsew here.
Subject to and without waiving the foregoing objections, Google responds as follows: Google’s responses and objections to Netlist’s First Set of Requests for Admission are fully compliant with the requirements of Federal Rule 36, and as such, those responses and objections adequately disclose the reasons for Google’s denials and partial denials. Google incorporates those responses and objections here by reference.
—-
Recently NLST has expanded the scope of charges against GOOG. GOOG has not accepted this expansion (because only one week remains before close of fact discovery – from e-mail dated Mar 25, 2010 – pg. 99 of docket 113-1).
So if GOOG needs time, we may see court delay end of discovery (maybe). Or they may deny NLST expansion of charges because it is expanding the complexity of the case.
It is interesting how GOOG delayed Sprinkle testimony (awaiting consolidation which didn’t happen) and now is saying there is not enough time for discovery.
It seems NLST has been deposing (taking testimony from) GOOG AMB (buffer chip) suppliers – pg. 103 of docket 113-1 (Exhibit N) refers to IDT and NEC:
—-
quote:
Netlist also just deposed Google’s AMB supplies, IDT and NEC, this week, and will use
the information from those depositions to support its ‘912 Patent Infringement Contentions. Thus, any alleged
“delay” will ultimately inure to Google’s benefit in the form of more detailed and specific infringement
contentions.
—-
In addition GOOG was set to depose JEDEC on March 30.
Regarding JEDEC, we see that JEDEC did circulate a letter to members about NLST’s contention that the JEDEC “Mode C” standard was infringing NLST IP:
From docket 113-1
—-
pg. 44 (Exhibit C – pg. 6)
INTERROGATORY NO. 7:
State the date on which Google first became aware of the ‘386 patent, the patent application that issued as the ‘386 Patent, any patent application to which the ‘386 Patent claims
priority, and/or any Nelist patent application disclosing and/or claiming memory density multiplication, memory rank decoding, and/or memory rank multiplication; describe the circumstances leading to such first awareness, including the identity of the person(s) involved, the identity of all documents which refer or relate to such first awareness, and/or the circumstances leading to such first awareness.
RESPONSE TO INTERROGATORY NO. 7:
Google incorporates each of the foregoing General Objections as it set forth fully in response to this interrogatory. Google further objects to this Interrogatory to the extent it calls for information protected by the attorney-client privilege, the work product doctrine, or any other applicable exemption from discovery. Google objects to this Interrogatory as calling for the production of information that is neither relevant nor likely to lead to the discovery of admissible evidence to the extent it requests information cuncemir^lg patents other than the ‘386 patent in suit. Google will respond concerning the patent in suit only. Google further objects to this Interrogatory as vague and ambiguous as to at least the terms “memory density multiplication,” ‘memory rank decoding,” and “memory rank multbplicabon.” Google further objects to ibis Interrogatory as over broad and unduly burdensome to the extent it would require an investigation into the aforcmenboned irrelevant patents conceding vague and ambiguous subject matter, which have no bearing on this case.
Subject to and without waiving the foregoing objections, Google responds as follows: Google was first made aware oftbe ‘386 patent in suit by an e-mail from Mr. Phileasher Tanner of JEDEC to various JEDEC mailing list recipients, including Mr. Rob Sprinkle and Mr. Andrew Swing of Google on or about Jan. 10, 2008, forwarding a Nelist patent disclosure letter concerning the patent. This e-mail, and the attached letter, were produced by Google in this matter as GNET034096-97 and GNET269919-20.
—-
Hi netlist,
It’s interesting to see how the pre-courtroom drama is playing out amongst Google and Netlist. Thank you very much for the updates.
NLST yesterday got qualified by SuperMicro (SMCI).
So this is now the first third-party validation of NLST technology.
For a good overview of what this means, check out these threads:
http://messages.finance.yahoo.com/Business_%26_Finance/Investments/Stocks_%28A_to_Z%29/Stocks_N/threadview?bn=51443&tid=15147&mid=15147
Here’s why Supermicro deal is a BIG DEAL
http://messages.finance.yahoo.com/Business_%26_Finance/Investments/Stocks_%28A_to_Z%29/Stocks_N/threadview?bn=51443&tid=15172&mid=15172
Putting numbers on the Supermicro Deal
http://messages.finance.yahoo.com/Stocks_%28A_to_Z%29/Stocks_N/threadview?m=te&bn=51443&tid=12961&mid=15178&tof=10&frt=2#15178
Inphi seems to have had a delay
quote:
NLST yesterday got qualified by SuperMicro (SMCI).
So this is now the first third-party validation of NLST technology.
http://finance.yahoo.com/news/Supermicro-Qualifies-Netlists-prnews-2550444882.html?x=0&.v=1
Supermicro Qualifies Netlist’s HyperCloud Memory on High-Density Servers
Netlist’s HyperCloud and Supermicro Optimize Server Utilization
Press Release Source: Netlist, Inc. On Monday April 12, 2010, 6:00 am EDT
…
“With Netlist’s HyperCloud memory, our servers empower customers to improve their productivity and to support memory-intensive applications such as cloud computing and virtualization,” said Wally Liaw, vice president of sales at Supermicro. “HyperCloud helps us to uniquely position our high memory footprint servers with unprecedented levels of performance in these growth markets.”
By optimizing server utilization, HyperCloud improves datacenter economics associated with memory intensive, high performance computing applications and workloads, including virtualization, cloud computing, online transaction processing, video services and storage. Servers in these datacenters are typically underutilized due to memory bandwidth and capacity bottlenecks. Improving performance while lowering operating and capital expenses in datacenters, increases utility out of new and existing servers.
…
netlist
Thanks for the information. I am just becoming familiar with the legal side of the technical field, so it is taking me time to wrap my mind around the information that you supplied. Correct me if I’ve got it wrong.
I gather that Google is using 4 rank memory addressing in many of their servers but may have implemented it using their own ASIC and command codes, thus attempting to give Goggle protection against infringement claims. In my opinion, Mode C is Mode C no matter how it is implemented. Its almost certain that Google got the idea from Netlist and Netlist holds the patents protecting many elements to Mode C. The court will decide if that patent is broad enough to protect against superficial changes.
Netlist had a chance to completely optimized the codes claimed as its IP. Often there is only one optimized code for any CPU operation such as memory operations. Even if Google wins by using a different code, it may be second rate code (less efficient) to Netlist’s IP. That efficiency is hard to make up through ASIC design since the ASIC is subservient to the CPU. This could mean that Google looses memory access speed because of inferior code. Moving Tera byte upon Tera byte of data over time using less efficient code adds up to real money. Even if Netlist looses their claim because of a slightly different code, competitors may have to either use Netlist’s code as written and respect IP, or put out an inferior product using inferior code.
It looks like Google stands a chance of shooting itself in the foot twice, since its giving Netlist an opportunity to see exactly how it implemented its flavor of Mode C, and may be delaying or preventing the use of a more eloquent technology from Netlist.
GOOG was informed (via letter from JEDEC to it’s member companies – of which GOOG was one) of the conflict pointed out by NLST in the JEDEC “Mode C” proposed standard.
Yet GOOG continued to be blase about it and continue contracting NEC and IDT to make the AMB (buffer chips) for use on the memory modules and explictly going out and manufacturing or having these things manufactured and then going out and using them in it’s servers.
That is a high degree of complicity.
In recent filings (April 14, 2010), GOOG is claiming it answered “don’t know” to many questions about the buffer chips because they don’t know what they do – that is an odd assertion given that it is GOOG which is CONTRACTING with these subcontractors to deliver them these buffer chips and to manufacture the stuff.
From docket 117:
(pg 3. )
Google has been forthcoming about its limited knowledge and understanding of the accused 4-Rank FBDIMM products.
…
(pg. 5 )
Google had (and continues to have) insufficient knowledge because it neither designed nor manufactured the components at issue—the AMBs, which are being accused as the “logic element” of the asserted claims.
The hardware that GOOG had manufactured seems to have been following the JEDEC proposed standard or somewhat close to that. NLST has taken testimony from NEC and IDT (AMB buffer subcontractors for GOOG) regarding the design of the AMB and how it relates to JEDEC proposed standard.
As long as GOOG is using “Mode C”, it is a telling indicator that it was continuing to pursue a path (that JEDEC itself is wary of and had warned it’s members of) of violation of NLST IP.
quote:
In recent filings (April 14, 2010), GOOG is claiming it answered “don’t know” to many questions about the buffer chips because they don’t know what they do – that is an odd assertion given that it is GOOG which is CONTRACTING with these subcontractors to deliver them these buffer chips and to manufacture the stuff.
Also while GOOG maybe entitled to claim this WHILE claiming NLST IP is not related to GOOG, I would think it weakens GOOG’s argument attacking NLST IP if they are not clear about the technology that they ARE using.
If they don’t know what they are using, how can they claim non-relatedness to NLST IP ?
Since GOOG vs. NLST is GOOG attempt to deflect imminent injunction closing GOOG servers (if NLST requested it after complaining to GOOG sometime back), then there IS a burden on them to show evidence that distinguishes their technology from the IP claimant (NLST).
One could argue the burden of proof is on NLST – however we are talking about a hush hush internal manufacture of hardware by GOOG, and some degree of cooperation IS required by GOOG. What NLST can show is circumstantial evidence that on the face of it GOOG IS violating NLST IP – that has been shown in discovery where GOOG server turned out to be using “Mode C”, and GOOG has accepted that it DOES use “Mode C”.
The question naturally arises that even if GOOG doesn’t know WHAT it’s doing – it’s just following JEDEC proposed standard and telling subcontractors to “just use that”, where was the caution when JEDEC informed members that proposed standard was “iffy” because of potential violation of NLST IP.
Instead GOOG continued doing what it was doing, and it was not until NLST asked questions of GOOG directly that GOOG went directly to court (did not even know what to answer directly to NLST) in order to “manage” the process of (possibly) eventual concession to NLST (in an orderly court environment).
In any case, this undermines the thesis that GOOG has great IP in this area (like MetaRAM – even though MetaRAM also conceded to NLST).
Basically GOOG is relying on JEDEC proposed standard or such stuff – after all when it contracts with NEC and IDT to make buffer chips but leaves it up to them – they must be following some standard or method – likely the JEDEC proposed standard (of which GOOG was a part).
If so, it boils down to JEDEC proposed standard vs. NLST dictating GOOG fortune in this case.
“Don’t know”
Well that certainly is an interesting defense. GOOG must be squirming pretty bad to come up with that one. It may have worked for Ronald Reagan in the Iran Contra trial “I don’t recall” but ignorance is not an excuse for braking the law in the case Patent law.
It almost seems while claiming stupidity they are also try to blame the companies they contracted to manufacture for them. If I was the judge this kind of crap in the court room would piss me off.
Has this approach actually ever worked in a case like this that anyone is aware of?
Why is GOOG delaying a settlement?
They don’t really think “don’t know” carries merit?
Seems like the kind of defense the guy that has all the money and knows he is wrong uses in an attempt to bleed out the smaller guy.
quote:
Has this approach actually ever worked in a case like this that anyone is aware of?
Why is GOOG delaying a settlement?
They don’t really think “don’t know” carries merit?
Seems like the kind of defense the guy that has all the money and knows he is wrong uses in an attempt to bleed out the smaller guy.
Recently NLST expanded the charges against GOOG – as outlined in this post above:
http://www.seobythesea.com/?p=3097#comment-263652
Docket 117 is the GOOG argument for why new charges should not be admitted now.
As part of that argument, GOOG attempts to answer why their “don’t know” answers were not really a delaying tactic – so that explanation (i.e. the subcontractors did it) is part of that argument.
I was highlighting that because it reflects badly on GOOG’s overall case – it pisses off their subcontractors, it feigns ignorance of GOOG’s role in JEDEC proposed standard. And it undermines GOOG’s determination as a cognizant party – in effect it gives the impression they were juvenile in temperament (which undermines their credibility in fighting an IP case against NLST).
To be fair to GOOG, docket 117 is not really their “defence”, but are actually the arguments they are making to prevent NLST from expanding the charges against GOOG.
this isn’t actually their defence (i.e. “don’t know”).
Netlist – thank you as usual!
If GOOG and NLST are scheduled for a settlement conference on the 30th why is GOOG still submitting filings to the court. Is this normal? Are they still trying to argue the case?
Settlement conference is routine – doesn’t mean much.
Meanwhile GOOG has to fight whatever it can – notice that NLST is piling on charges on GOOG, so GOOG has to have rebuttals. So that is what we are seeing. That doesn’t mean that settlement cannot happen. Court business still has to be dealt with on a day to day basis.
The only way Google would have a chance of getting around Mode C is to custom build a non JEDEC server that would have different addressing protocols. That would add extra cost to servers and memory modules. If Google is not using the inexpensive 2 gig memory chips that Netlist’s IP enables it to use, Google would come up short . There would be obstacles concerning addressing, speed, power and thermal management. Google approach makes no since unless the new design delivers a quantum leap in over all performance per dollar spent. There is no substitute for “on board memory” when it comes to servers. I think the high price of custom built, non-JEDEC servers and memory modules would only make sense if Google is going into the server manufacturing business. Potential server purchasers would be leery of hitching their wagons to a competitor using non standard components, because Google would control much of the IP. I wonder what is Google’s end game?
I recall that Google prided itself on desinging its own specialized hardware when it was smaller, and more nimble. Focus can be easlily lost with hyper growth. An error only becomes a mistake if its not corrected. Netlist may prove that small, and nimlbe is still best for focused goals.
quote:
I recall that Google prided itself on desinging its own specialized hardware when it was smaller, and more nimble. Focus can be easlily lost with hyper growth. An error only becomes a mistake if its not corrected. Netlist may prove that small, and nimlbe is still best for focused goals.
Google’s “custom hardware” was essentially use of generic hardware in ways that could be scaled. The search problem was designed to be scalable, and they tried to make the hardware side scalable – based on many cheap servers which could be scaled as needed.
It is in GOOG’s interest if memory technology becomes standardized – memory costs go down.
In the absence of a good solution – and with JEDEC proposed standard – GOOG tried to make early what was coming down the road later. However they went failed to account for the legal ownership of the IP – their behavior was consistent with their beginnings as a academic type of organization. However it ignores their reality as a technology behemoth of a company.
Within GOOG, their hardware division got involved in the memory project – so a bit of internal engineering momentum (and because they are a consumer of their own hardware division) may have blindsided their legal department (?).
However, I am thinking that if there WAS internal momentum, it should have dissipated by now – and the move out of Fish & Richarson (#2 in IP litigation) to King & Spaulding (#2 in ARBITRATION, but not in top 30 in IP litigation) seems like a very deliberate move – and may have come from the very top of GOOG (after a meeting perhaps “ok, guys what do we do”).
So probably GOOG NOW knows what they have to do – it’s just that the legal team do what is best to achieve good balance if there ever are settlement discussions.
NLST had already offered RAND terms to JEDEC. It seems the clear way forward is to have GOOG pay some penatly (or some future business – SMCI qualification of NLST probably goes a long way towards strengthening NLST position as having something tangible to offer – a working replacement for the stuff GOOG is doing currently).
And to have JEDEC get good terms for it’s member memory module makers – for JEDEC proposed standard.
However it would seem that a mamory module maker would be more interested in getting the NLST HyperCloud IP license than the JEDEC proposed standard (which may require BIOS changes).
Or at least they would want NLST IP for the short-term, with JEDEC proposed standard for later (when BIOS updated boards become the norm) – maybe they have to pay less licensing fees with that.
Total speculation of course.
There may have been a misjudgement by the hardward division of Google. I have heard the term “patent troll” used by Google in th past. I don’t know if they used that term refering to Netlist directly. The fact that Netlist has a certified product using the contested IP blowns that notion clean out of the water. Given, that the company has a tendency to use such references gives insight to elements of Google’s enternal culture. I speculate that the only way that this gets t
I speculate that the only way this gets to court is that
Google’s councel thinks that it has a much better than an 50% chance of winning. A lost could be a public relations desaster. Meanwhile, discovery will buy time.
In my opion, it would be amazing if Google had no knowledge of infringing technology because they left it up to the individual suppliers to determine how to designed memory modules for Googles use. That could result in a hodge-podge of different specs, and performance charicteristics. Any company making that kind of investment would want to have tight control of what they are getting for their moneny.
Makes sense.
Recently NLST expanded the charges against GOOG – as outlined in this post above:
http://www.seobythesea.com/?p=3097#comment-263652
GOOG opposes claiming they “didn’t know” how their memory module components operate and were not delaying etc.
In response NLST files a pretty interesting read on events.
—-
Given the foregoing, Google seeks to confuse the Court by arguing that Netlist “has had detailed knowledge of AMBs for years” based upon its participation in the industry’s standard setting process and analyses of third-party products. Opposition p. 3:1-15. Google then contrasts Netlist’s expertise with its own professed ignorance as to the function of AMBs. Opposition p. 3:16-17 (“In contract to Netlist’s detailed knowledge of AMBs, Google, as an acquirer of 4-rank FBDIMMs and the AMBs they include, has only limited knowledge of the products”).
In doing so, Google argues that Netlist somehow lacked diligence in amending its infringement contentions because Netlist would be more knowledgeable than Google on the function of AMBs in the computer memory industry and could have sought the information from
other third parties earlier.
Google’s argument is a red-herring; Netlist’s knowledge of AMBs in the computer
memory industry in general is irrelevant. Indeed, if the information Netlist sought was generally
known in the industry, Google would presumably not have designated the deposition transcripts
of its Rule 30(b)(6) witnesses as “Confidential-Attorney’s Eyes Only.” Hansen Dec. ¶ 12.
Netlist needed and sought information on how Google used the third party AMBs it purchased
and whether and how its use of the AMBs conformed to JEDEC standards.
The proposed amended infringement contentions concern specific information regarding Google’s infringing use of AMBs with its 4-Rank FBDIMMs. This information includes details such as the number and type of “memory devices” (i.e., DRAM chips), the physical connection between the FBDIMMs and a computer server, the physical connections between the AMBs and the DRAM chips and the number of ranks in which the DRAMs are configured, the types of 4-Rank FBDIMMs used by Google (2GB, 4GB, 8GB), and the specific manner in which the AMBs operate when used by Google, including the types of commands they perform and how they perform them. Google delayed producing this information until the February and March 2010 depositions of its Rule 30(b)(6) witnesses. While some of the information may have been included in the hundreds of thousands of pages of documents that Google produced, the Rule 30(b)(6) witnesses were critical in navigating those documents and establishing their relationship to the structure and operation of the accused products.
For example, when the current infringement contentions were created, Netlist only knew that Google was using 4 Gigabyte 4-rank FBDIMMs using rank multiplication technology, infringing upon claims 1 and 11 of the patent-in-suit. However, upon taking the deposition of Mr. Sprinkle on February 18, 2009, Netlist learned that Google’s AMB is a form of an application specific integrated circuit (ASIC), as recited in claim 5 of the ‘386 Patent. At Mr. Sprinkle’s deposition, Netlist also learned that claim 9 of the ‘386 patent was implicated by the specific manner in which Google’s AMB is informed about the rank to which command and address signals are to be directed. Hansen Dec., ¶ 12.
—-
And some information on how the GOOG server was made available for inspection – and the flip-flopping by GOOG on “Mode C” being used:
From docket 133 (133-main):
—-
(pg. 5 )
For example, Google sought to block Netlist from inspecting a Google server to obtain information and photographs of the server and its 4-Rank FBDIMMs. The information and exhibits were eventually used to examine Google’s witnesses.
In an effort to convince the Magistrate Judge to deny Netlist’s inspection request, Google admitted that its 4-Rank FBDIMMs operated in accordance with “JEDEC Mode C,” an infringing mode of operation. Joint Letter of the Parties to Magistrate Judge Spero, dated May 19, 2009 at 5 (See Declaration of Steven R. Hansen in support of Netlist’s Reply Brief, dated April 20, 2010 (“Hansen Reply Dec.”) at ¶ 2, Exh. A).
Magistrate Judge Spero eventually ordered the inspection to go forward. See May 29, 2009 Order Granting Defendant’s Request For Production No. 12 For Inspection Of A Functioning Google Server [Docket No. 31]). Further, in October 2009, Google admitted in responses to Requests for Admission that it uses “Mode C.” Google’s Response to Netlist’s RFAs at 6-7 (Hansen Dec., ¶ 5, Exh. B). However, on the evening of the last day of discovery, Google “supplemented” its responses to deny using Mode C:
May 19, 2009 Letter to
Magistrate Judge Spero
(page 5) (Document 27;
Hansen Reply Dec., ¶ 2, Exh.
A) (original emphasis)
“Google does not dispute that
its FBDIMMs operate in
Mode C . . . .”
October 27, 2009 Response
to Netlist’s Request for
Admission No. 3 (Hansen
Dec., ¶ 5 Exh. B)
“Google admits that certain
FBDIMMs used in certain of
its servers follow the Mode C
serial channel
communication protocol set
forth in the JEDEC standard
for the respective DRAM
used on the DIMM.”
March 30, 2010
Supplemental Response to
Netlist’s Request for
Admission No. 3 (Hansen
Reply Dec. ¶ 3, Exh. B)
“Google lacks sufficient
knowledge and information
to admit or deny this Request
and therefore denies it.”
—-
And on GOOG’s “lack of knowledge”:
From docket 133 (133-main):
—-
(pg. 7 )
While Google protests that it “lacks knowledge” of how its own 4-Rank FBDIMMs are configured and operate, it is undisputed that when Google’s 30(b)(6) witnesses were finally deposed (the protracted history of Google’s failure and refusal to timely produce its witnesses its detailed in Netlist’s moving papers), Mssrs. Sprinkle and Dorsey had plenty of non-public knowledge regarding them. Hansen Dec., ¶ 12. Thus, Google’s suggestion that “Google’s lack of knowledge undermines rather than advances Netlist’s position” is false. Opposition p. 5.
Google’s effort to hide behind its purported “lack of knowledge” is nothing more than a tactic used to avoid meeting its discovery obligations.
As such, Google delayed in revealing highly-relevant information by obstructing inspection of its server, delaying the production of its 30(b)(6) witnesses, and denying requests for admission based upon lack of knowledge when in fact its witnesses had extensive knowledge of the subject. After going to such great lengths to delay disclosing relevant information, Google cannot now complain about the timeliness of Netlist’s request to amend its infringement contentions; Google itself is responsible for any delay in the production of the information necessitating the proposed amendments.
—-
It seems NLST is claiming GOOG manufactured “hundreds of thousands of computer memory modules”.
I am not sure if it is that much – but maybe NLST has information on how common these modules are in current GOOG setup.
Also contains an explanation of “Mode C” (and NLST IP).
From docket 133-2 (which outlines earlier arguments – which eventually led the court to refuse GOOG arguments and grant NLST request for examining GOOG server):
—-
(pg. 2 )
This is a patent infringement case. Netlist owns IP relating to computer memory modules, and it shared some of those inventions under NDA with Google while Netlist’s patents were pending. Google turned down a business relationship with Netlist. Netlist alleges that Google then went on to manufacture hundreds of thousands of computer memory modules using the Netlist technology, and that it now uses those memory modules in server computers at Google data centers.1
…
One of Netlist’s production requests was for an allegedly infringing Google server. Google has refused to produce one. In its Request for Production No. 12, Netlist requested that Google produce a server containing the Accused Devices, including all software, firmware, and/or “register-setting code” used in the operation of the Accused Devices. The purpose of this request is to allow Netlist to verify that the FBDIMMs used in Google servers function as described in the ‘386 patent.
In particular, for Google’s FBDIMMs to be infringing, they must be capable of being set to run in what the industry standard-setting body, JEDEC, refers to as “Mode C”. In general terms, Mode C fools the computer into thinking that it is accessing two sets of memory chips, when in fact its access requests are split among four less-expensive sets of memory chips. This yields tremendous cost and energy savings. When an infringing server is turned on, it sets the appropriate registers for Mode C, and it can then report that it has the amount of memory contained on the memory module in those four sets of chips (e.g., 4 gigabytes).
—-
And GOOG’s answer there includes acceptance of “Mode C”.
From docket 133-2:
—-
(pg. 6 )
Netlist can determine FBDIMM operation from the code Google has agreed to make available, including the code that controls Mode C operation, and FBDIMM configuration can be determined from the design files and the product itself. Google does not dispute that its FBDIMMs operate in Mode C and the code it has agreed to produce is the code relating to Mode C operation.
—-
From docket 133-2 (NLST letter to GOOG – more on “Mode C”):
—-
(pg. 16 )
Netlist Requested that Google produce a server so that it can test-among other things-Google’s FBDIMM functionality. The registers controlling the memory module running in what JEDEC refers to as “Mode C” are set by and on the CPU, not the FBDIMM. This is a central infringement issue, and theeefore simply producing a memory module and code is insufficient. Similarly, because Netlist argues that Google induces infringement by providing services using the infringing servers, Netlist needs an operational server rather than a memory module in order to prove up it’s case.
—-
GOOG fought production of server tooth and nail – all the while trying to placate with production of FBDIMMs, their circuit board plans and code, but to avoid embroiling the servers.
Eventually the court ordered GOOG to produce the server (which is what led to discovery against GOOG, and helped expand claims against GOOG).
Netlist,
I have to admit the “settlement conference” is a confusing subject to me. I was of the impression that if it were to be ordered by the court that, it was probably do to the fact that the Judge saw a definite violation by one side. Now if I understand it correctly what it is essentially doing is forcing the sides to declare what they are looking for in a post trial settlement? Am I correct?
Obviously I have not read all the documents (only what you have been kind enough to share), but this seem pretty one sided. What does GOOG hope to gain by continuing to delay or going to trial? Are they simply trying to bleed the cash out of NLST?
In most cases with jury trials, the court forces the parties to a “settlement conference” with some arbitrator/judge in order to give them the chance to settle early i.e. out of court settlement – thus saving the court the expense and bother of going to jury trial if the matter can be dismissed/resolved early.
However if the parties are not amenable to settling this early, the settlement conference usually produces no result.
That is why I have noted that the settlement conference date is interesting but not necessarily means anything.
http://en.wikipedia.org/wiki/Settlement_conference
quote:
Matters discussed in a settlement conference are confidential, and cannot be introduced as evidence in court. All such information would be considered privileged or hearsay. There is one exception to this rule: statements of fact made by criminal defendants in settlement discussions over disputed civil claims asserted by government agencies are admissible in the criminal case.
netlist,
Has Netlist given any indication of what they are looking for in the settlement? It seems that the assertion that Google has installed “hundreds of thousands” of mode C infringing modules signals that Netlist believes that Google has committed tremendous damage. How often are agreements reached during Settlement conferences in cases similar to this one?
I have not found indication of what NLST is looking in settlement.
Though CEO Hong has signalled that:
From Q4 2009 CC (Feb 18, 2010):
quote:
cannot disclose litigation .. vigorously protect
not in litigation business .. will seek reasonable settlements
Well based on this information. I can’t see why both sides shouldn’t be able to establish an understanding for settlement. As it stands now the only ones gaining are the lawyer’s (unless there is something we don’t know yet).
Either way – should be interesting.
Thanks for all the insight.. Great board!
Netlist,
It seems in charioteer with the leadership of Netlist to be looking forward, as evident by the development of their recent products. The protection of their IP could be worth more than a punitive sized settlement. Google would look hypocritical if they reject a reasonable settlement in which the ownership of IP is the major issue, when it complains about the lack of respect for its own IP in China. Thanks for all of the useful information that you have supplied.
My best guess is that Google assumed that because Mode C is an industry standard, they were free to use it without infringing any patents. Netlist had notified Google, as well as the concerned industry standard body that Mode C may infringe their intellectual property. Although they had a letter from NetList, they took the view that NetList is a patent troll.
Using other people’s patents even after you have been told about them seems evil to me.
I think this case will cause a lot of changes in the way Google looks at Patents. Recent news reports that they have patented various parts of their architecture are significant. Open source clones of their architecture may now be infringing their patents. Although Google as per its policy has no plans of suing others of infringement, except as a defense.
Could the lack of news out of the settlement conference indicate both parties are looking for a timely solution? The Supermicro computer server model SYS-6026T-NTR+-GS015 with 288 gig of HyperCloud memory demonstrated at Interop 2010 is good timing. Wonder how it stacks up against Google’s Icarus server?
Don’t know – settlement conference may not mean anything as is mandatory by the court. Their settlement dynamics maybe moving at their own pace, with settlement conference just an official date to be ignored or to go to with eyes rolling.
As expected, nothing happened on the April 30, 2010 “mandatory settlement conference” between GOOG and NLST in front of Judge Laporte for GOOG vs. NLST.
Outcome was “did not settle” (docket 136 in GOOG vs. NLST).
Parties are required to attend such settlement conferences in order to give every opportunity to avoid the time and resource expenditure by the court for jury trials.
However the parties may have their own timeline for when they want to settle – so these become a formality.
NLST had recently asked the court for permission to expand the claims against GOOG.
Judge Armstrong (Docket 134 in GOOG vs. NLST) denied permission to expand the case.
NLST claimed that since GOOG had delayed in discovery process, NLST got testimony from GOOG employees at a late stage and that helped them craft additional claims against GOOG.
Judge Armstrong has in the past denied things which might slow GOOG vs. NLST – the joint GOOG/NLST request to consolidate GOOG vs. NLST and NLST vs. GOOG was denied earlier for similar reasons. It would have slowed GOOG vs. NLST down which was in an advanced state.
Given that precedent, it was not surprising that Judge Armstrong denied expansion of claims as it would disrupt the existing GOOG vs. NLST case.
I assume this still leaves NLST vs. GOOG (which has a later timeline) open for addition of those claims by NLST.
However as indicated in the past, if GOOG/NLST settle early, it will include all cases (and may even include some JEDEC licensing of NLST IP for the JEDEC “Mode C” proposed standard). So the outcome of the NLST vs. GOOG maybe moot, as it will probably become part of whatever settlement in GOOG vs. NLST.
This outcome was suggested in an earlier post “it would keep things on track”:
http://messages.finance.yahoo.com/Stocks_%28A_to_Z%29/Stocks_N/threadview?m=te&bn=51443&tid=15757&mid=15843&tof=1&frt=2#15843
Re: vicl2010v scammed you all
quote:
—-
Other than that there is a May 4 (today) hearing on NLST’s extra claims against GOOG.
If approved they would add to the burden against GOOG. If Judge Armstrong disapproves the extra claims, it would keep things on track.
—-
Judge Armstrong has earlier also said the parties should try to settle the case “sooner rather than later” – when she earlier denied GOOG/NLST joint request to consolidate GOOG vs. NLST and NLST vs. GOOG.
http://messages.finance.yahoo.com/Stocks_%28A_to_Z%29/Stocks_N/threadview?m=te&bn=51443&tid=14993&mid=15027&tof=1&frt=2#15027
Re: A Lot Of 100 Lots Going Through
(Caveat: I have not read the original lawsuit or other papers. On the other hand, I have read this thread and the associated hyper linked material in detail. )
Extent of damages depends on extent of infringement, and willfulness of infringement.
Extent of infringement will depend on how many servers Mode C was used on.If it was in use in hundreds of thousands of server the damages will be more.
This case is unusual- Google apparently had an ASIC manufactured for memory expansion that is compliant with JEDEC Mode C. They had been told that Mode C was NetList IP. The JEDEC standards body had also been told about it. They continued to use Mode C- they decided that NetList was a patent “troll”. Google cannot say that the legal department knew about the NetList claim, but not the hardware engineering group. This defense if allowed would make mockery of the legal system. Any company would be free to argue that they are just a large company where the left hand does not know that the right hand is infringing.
Willful infringement penalty is 3 times the damages. The judge has discretion to increase or decrease the damages. Subsequent Google conduct such as refusing to admit or deny infringement, delaying the discovery process will not be looked at favorably. Even saying that NetList is a patent troll may not be looked at favorably at the stage of calculating damages. Would Google say the same about an established large company in high tech? As it happens, there is only one other company that can give the same amount of memory as the upstart Netlist.
I am hoping that Google is forced to settle for hundreds of millions of dollars, and then is forced to buy from NetList for 3 to 7 years. Many companies which pride themselves on being ethical have a policy when settling law suits. They will settle a lawsuit in which they are guilty of wrong doing. Instead of the boiler plate- “Without admitting wrongdoing, we pay millions of dollars”- they will say- we admit our actions were wrong, and are taking steps – such as better decision making processes and training – to make sure this wrong doing does not happen again. Stealing patented ideas, willfully is “evil”.
Do you think that this case will make it to court? Sames that the cost of bad pr from an unfavoraable court outcome would be enough to motivate an early settlement by Google, not to mention the delaying the adoption of Netlist prouducts.
quote:
Do you think that this case will make it to court? Sames that the cost of bad pr from an unfavoraable court outcome would be enough to motivate an early settlement by Google, not to mention the delaying the adoption of Netlist prouducts.
Delaying adoption – as in delaying adoption of HyperCloud within GOOG.
Yes. Adopting HyperCloud within Goog is a possibility, depending on how Hypercloud technology stacks up to Googles memory modules. Can you get the specs for Goog’s modules? That information seems to be confidential. If the difference is great enough in Netlist favor, Goog would be a shrewd to adopt HyperCloud or some other Netlist IP, and lower its overall settlement and memory cost going forward. Having Goog as a customer for years to come would be a substanial victory for Netlist. Goog could also turn an embarressing situation into an example of how to manage mis-steps, while maintaining it’s gleeming coorperate image.
I don’t think the issue of whether GOOG’s memory is better is an issue. It probably doubles memory, but probably does not allow full speed operation.
The issue is: It probably infringes NetList Patent, and the infringement is perhaps willful- considering NetList had notified them.
GOOG cannot possibly say: “We lack sufficient knowledge” about whether we infringe. This defense will not be accepted during trial. It seems laughable for a tech giant, to say they do not know if something which they designed and manufactured infringes someone’s patents. Normally companies say: We do not infringe, as we work around the claims- or they say the patent is invalid. I have not seen a defence like this.
Comments/analysis of Netlists first quarter 2010 results going forward?
http://www.netlist.com/investors/investors.html
http://www.bizjournals.com/sanfrancisco/prnewswire/press_releases/California/2010/05/11/LA03022
Anyone:
1. Have close by multiple industry source market past, current, future projections for DC server potential growth 1-10 yrs out (i.e., demand pool)? As well: top 5 server consumers, penetration, region.
2. Visit Netlist at Interop 2010 Vegas and see the “Data Cnter in a Box” with thoughts/impressions?
Joeq: did you see that news article of ‘papers flung from a red peugot’? started a big fire back in the day…
Question: with regard to bandwidth, how well does it scale? What is the bandwidth for each DIMM (4GB, 8GB, and 16GB) and then total for a server (i.e., Supermicro etc.) partially or fully loaded utilizing eighteen, 16GB 2vRank HyperCloud DIMMs (288GB DRAM)?
Does anyone here have access to the settlement information concerning the Texas Instruments case that was just announced?
Thanks
NLST vs. TXN settled.
Problem is can’t get access to the court records – although if it is a settlement, that may not be in the court records.
But if someone can get access (goto court basically, since that court is not on PACER), that would be nice as it would shed light on the goings on at JEDEC and how TXN (being fingered as the ORIGINAL leaker of info to JEDEC) may have been involved.
http://www.prnewswire.com/news-releases/netlist-settles-lawsuit-with-texas-instruments-93915489.html
Netlist Settles Lawsuit With Texas Instruments
IRVINE, Calif., May 17 /PRNewswire-FirstCall/ — Netlist, Inc. (Nasdaq: NLST) today announced that it has reached a settlement in the misappropriation of trade secrets and breach of contract lawsuit against Texas Instruments, Incorporated. The settlement resolves a dispute between the two companies concerning the use of proprietary memory modules and other related technology.
“We are pleased to have successfully resolved this case. Netlist remains committed to protecting its portfolio of intellectual property,” said C.K. Hong, President and CEO of Netlist.
Examining the language in the PR:
quote:
IRVINE, Calif., May 17 /PRNewswire-FirstCall/ — Netlist, Inc. (Nasdaq: NLST) today announced that it has reached a settlement in the misappropriation of trade secrets and breach of contract lawsuit against Texas Instruments, Incorporated. The settlement resolves a dispute between the two companies concerning the use of proprietary memory modules and other related technology.
quote:
“We are pleased to have successfully resolved this case. Netlist remains committed to protecting its portfolio of intellectual property,” said C.K. Hong, President and CEO of Netlist.
Here we have CEO Hong issue the PR – possibly suggesting that NLST is in the drivers seat regarding who would put out the PR.
It has NLST speaking, and it does not have TXN representative speaking (if there was a TXN concession there would be nothing to tout about).
Plus the reiteration of defence of NLST IP.
Language suggests that this is to the satisfaction of both parties – and esp. NLST.
From court docket info, the settlement happened 5/10/2010.
Court-mandated settlement conference was set for 09/29/2010.
And jury trial for 10/4/2010.
See docket info for NLST vs. TXN:
http://www.sccaseinfo.org/pa6.asp?full_case_number=1-08-CV-127991
10/4/2010 08:45AM 01 CV Jury Trial – Long Cause Vacated; dismissal filed C 05/10/10 None None None
9/29/2010 01:30PM 01 CV Settlement Conf – Jury Vacated; dismissal filed C 05/10/10 02/10/10 None None
…
0038-000 Cv Ntc:Settlement 05/10/2010 None 05/11/2010 For: Netlist, Inc. / PLT
0037-000 Cv Req:Dismissal, Entire W/Prej 05/10/2010 None 05/11/2010 For: Netlist, Inc. / PLT
Against: Texas Instruments, Incorporated / DEF
So this was an early settlement – if TXN is quiet, this would suggest they concded something which is nothing to crow about. And if this is so, then an early settlement suggests TXN realized that delaying would not help TXN.
Note that like MetaRAM (which was making buffer chips, plus had some IP), TXN is also making some buffer chips (see above). But TXN is also accused of leaking NLST info to JEDEC.
What would a concession look like ? Would TXN concede IP (MetaRAM conceded IP to NLST, and promised to not let it’s IP be used against NLST) ? Or would TXN concede they will abandon buffer chip manufacture within TXN ?
What would TXN concede regarding leakage to JEDEC ?
What would be interesting is if TXN starts licensing NLST IP. Would be an indicator of start of fall of dominoes. Since TXN is a part of JEDEC – alleged by NLST to have leaked NLST IP to JEDEC – which may later have been used by Intel in that demo at JEDEC, which prompted NLST to inform JEDEC that this technology falls awry of NLST IP. Which in turn prompted the letter from JEDEC to members – including GOOG. Which GOOG in turn chose to ignore and continued manufacture until warned by NLST – in response to which GOOG went to court to prevent stoppage of it’s servers.
If TXN stops making buffer chips – that would impact negatively on Inphi (in NLST vs. Inphi) litigation as well.
We may or may not hear full details on the settlement. Settlement with MetaRAM involved a company in bankruptcy, while TXN has it’s reputation to protect as well.
Question is, if NLST is going to look the other way on TXN leakage to JEDEC, what is TXN going to promise in return ?
Just for comparison, here is a recap of the NLST vs. MetaRAM litigation settlement PR at time of settlement:
http://www.prnewswire.com/news-releases/netlist-announces-settlement-of-patent-infringement-lawsuits-with-metaram-82948382.html
Netlist Announces Settlement of Patent Infringement Lawsuits With MetaRAM
Press Release Source: Netlist, Inc. On Thursday January 28, 2010, 1:25 pm EST
quote:
Under the terms of the settlement, filed in U.S. District Courts in Delaware and Northern California, MetaRAM will not sell, offer to sell, release, or commercialize the MetaRAM DDR3 controllers in the U.S. or outside the U.S. Netlist contended that MetaRAM’s DDR3 controllers and memory modules incorporating such controllers infringed its U.S. Patent No. 7,289,386, entitled “Memory Module Decoder.” A provision in the settlement protects Netlist if another company purchases MetaRAM’s patent and attempts to seek action against Netlist in the future.
“We are pleased to have successfully resolved this case,” said C.K. Hong, President and CEO of Netlist. “As the pioneer of this technology, the results of this settlement clearly underscore Netlist’s fundamental patent and product leadership. Netlist’s HyperCloud product-line embodies this foundational technology and Netlist remains committed to protecting its portfolio of intellectual property.”
Does this mean that TXN has licensed the technology to produce high memory chips?
In the upcoming generations of Intel processor the limitation on memory is reduced- a 4 socket Intel Xeon with 1024 GB of memory is in the labs of major server vendors.
This does not mean that there is no need for NetList or other memory expansion technology- it is just that the need for that technology is reduced.
quote:
Does this mean that TXN has licensed the technology to produce high memory chips?
In the upcoming generations of Intel processor the limitation on memory is reduced- a 4 socket Intel Xeon with 1024 GB of memory is in the labs of major server vendors.
Not clear WHAT TXN could offer to atone for leakage to JEDEC. It would seem like licensing would be one thing – would also be a signal to JEDEC.
Or maybe they agree to having leaked – which would be useful in NLST vs. JEDEC – which practically speaking impacts NLST vs. GOOG (since GOOG is using JEDEC “Mode C” proposed standard).
NLST has a first to market advantage which is available now – with buildout for cloud computing it is a good time to be offering this product.
However NLST HyperCloud has other advantages – notably being the advantage of using “lower dollar per bit” memory chips to emulate “higher dollar per bit” memory chips.
Eventually new technology will arrive – server motherboards will change – but there is an economic value to have memory solutions that work NOW – and with existing low-priced servers.
Mode C has a limited lifespan going forward. Netlist doesn’t look like a one trick pony. The fact that Netlist figured out how to increase the address range on current motherboards without bios changes is amazing, and Google and others thought it was useful. HyperCloud involves additional Netlist IP that should be very useful in designing memory modules for the next generation mother board. IP needed to manage cost, space, speed, energy, and thermal issues will out live the current Mode C requirement for expanded memory addressing. HyperCloud is a great prototype demonstrating how to engineer high capacity/performance modules even as the need for Mode C diminishes. Netlist is positioning itself to become a major industry player. They must be successful in protecting their IP and executing properly. It seems they were denied an opportunity to grow by Google’s rebuff. I would expect that the settlement would address that issue.
10-Q filed by NLST:
http://www.secinfo.com/d11MXs.rSe8.htm
On the NLST vs. TXN litigation settlement:
quote:
Trade Secret Claim
On November 18, 2008, the Company filed a claim for trade secret misappropriation against Texas Instruments (”TI”) in Santa Clara County Superior Court, based on TI’s disclosure of confidential Company materials to the JEDEC standard-setting body. On May 7, 2010, the parties entered into a settlement agreement. The court dismissed the case with prejudice.
As stated in previous post above:
quote:
From court docket info, the settlement happened 5/10/2010.
Court-mandated settlement conference was set for 09/29/2010.
And jury trial for 10/4/2010.
The 10-Q now reveals they had agreed to settle May 7, 2010.
Superficially, HyperCloud seems to offer the advantages of JEDEC “Mode C” proposed standard plus the plug and play and requiring no updates to BIOS.
In addition it brings with it the integrated advantages of the “embedded passives” and NLST’s thermal IP (even heating to reduce thermal disparity so memory modules perform within tighter tolerances).
From the recent 10-Q filed by NLST:
http://www.secinfo.com/d11MXs.rSe8.htm
A good explanation of HyperCloud – pointing out that the “no BIOS changes” results in having no impact on OEM’s product cycles:
quote:
Our HyperCloud™ products can be installed in servers without the need for a bios change. As such, their design and anticipated sales launch is not dependent on the design plans or product cycle of our OEM customers. Alternatively, when developing custom modules for an equipment product launch, we engage with our OEM customers from the earliest stages of new product definition, providing us unique insight into their full range of system architecture and performance requirements. This close collaboration has also allowed us to develop a significant level of systems expertise. We leverage a portfolio of proprietary technologies and design techniques, including efficient planar design, alternative packaging techniques and custom semiconductor logic, to deliver memory subsystems with high speed, capacity and signal integrity, small form factor, attractive thermal characteristics and low cost per bit.
“Superficially, HyperCloud seems to offer the advantages of JEDEC “Mode C” proposed standard plus the plug and play and requiring no updates to BIOS.”
Jedec Mode C is a Netlist invention. That is the crux of the lawsuit.
quote:
Jedec Mode C is a Netlist invention. That is the crux of the lawsuit.
Yes, basically that it violates NLST IP. However that does not mean that it is better than HyperCloud. In fact HyperCloud – as qualified by SuperMicro (SMCI) – is a finished product which includes the advantages of JEDEC “Mode C” proposed standard PLUS the advantage of plug and play and no BIOS updates required.
What will be the hint before there is a big settlement?
Will there be a big settlement?
http://www.google.com/ventures/images/imagestrip_locations.jpg
Before building an ASIC may be Google should see if they have the green light to do so.
Don’t know.
Hi MemoryGeek,
It’s hard to say if there will be a settlement, or if we’ll get some kind of hint beforehand if there is one.
Many lawsuits do settle, and many often on the courthouse steps in the moments before a trial.
NLST has asked court for “summary judgement” in GOOG vs. NLST (case GOOG brought to protect it’s servers from being shutdown etc.) on the basis of some exhibits, mainly testimony from JEDEC attorney and GOOG employee.
http://en.wikipedia.org/wiki/Summary_jud...
Summary judgment
Easy to understand explanation of “summary judgement”:
http://answers.yahoo.com/question/index?qid=20071028194145AAxtvtV
quote:
Best Answer – Chosen by Asker
A summary judgment is a decision by a judge that decides the case early because there are no facts in dispute. The judge’s decision means that the case never goes to trial.
To ask for a summary judgment from a judge, you must do the following:
1. File a Motion for Summary Judgment asking the judge to rule in your favor. It must be filed pretty soon after discovery is complete.
2. In the Motion for Summary Judgment, you must submit case law and facts that support your Motion for SUmmary Judgment.
3. Generally, you won’t win a summary judgment motion unless there are NO facts in dispute – meaning the only issue outstanding is an issue of law.
For example, let’s say you and I are neighbors. Your trees were blocking my view – so I cut them down. You sue me to get the trees replaced. Both of us agree that this is what happened (that the facts are not in dispute).
Since we agree on the facts, the only outstanding issue is what the law says.
Why have a jury trial when juries ONLY decide facts – not law. Judges decide the law; therefore, the above case is RIPE for a decision.
The law states that I don’t have the right to trespass on your property and damage your property; therefore, if you file a motion for summary judgment the judge will find in your favor.
http://en.wikipedia.org/wiki/Jury_trial
Jury trial
A jury trial (or trial by jury) is a legal proceeding in which a jury either makes a decision or makes findings of fact which are then applied by a judge. It is distinguished from a bench trial, in which a judge or panel of judges make all decisions.
…
Juries usually weigh the evidence and testimony to determine questions of fact, while judges usually rule on questions of law, …
Another explanation:
http://www.legalandlit.ca/summaries/first/civpro/civpro_farrow_w07.doc
14 Stages of a Lawsuit -CHECKLIST
quote:
7. Disposition Without Trial – most cases don’t get to trial (only 1-3 percent get to trial)
4 different possibilities:
1. negotiated settlement – the most common resolution
mediated settlement – mediation is assisted negotiation with the assistance of a third party – a mediator helps facilitate communicate b/w the parties – there is now a rule requiring mandatory mediation – reduces costs and helps achieve a resolution
2. motion for judgment – if a party has made admissions through the oral examination for discovery process which entitle the opponent to succeed, you can move for judgment b/c the evidence sworn under oath on discovery entitles a win w/o a trial
3. moving for summary judgment – when one party in an action can demonstrate to the court that there is no triable issue in the case – the difference w/ motion for judgment is that there is no possible evidence to defeat your claim
4. striking a pleading by using R 25.11
5. default judgment – the D has failed to deliver a statement of defence – if you don’t respond to a statement of claim you are deemed to admit the allegations in the statement of claim – difficult motion to win b/c the court is being asked to do something quite significant, which is an ex parte (one party) – elements of the action still need to be proven, ie. Serving affidavit, damages, et
WHEN IS R20 USED (anytime before trial)
o if after discovery, you look at their evidence and conclude that they cannot back up their pleading, so a Rule 20 motion allows for early adjudication to have matter resolved
o Efficient on party resources and time and judicial resources
o It avoids a trial or shortens the proceeding on satisfying a court that there is no need for a trial because there is no genuine issue of fact requiring one
Thanks, netlist.
Thanks a fairly thorough explanation of a summary judgment.
If I were to simplify it, I might say that a motion for summary judgment is a ruling on the law involved in a case when there aren’t any facts left to dispute and argue in front of a jury, and only a legal interpretation of the law involved is necessary for a decision on a case.
Yes, basically it seems a jury trial is to establish “the truth” (or facts).
While the judge usually rules on the facts – or in some cases the jury rules on the facts as well as the judgement to varying degrees.
The suggestion being that once the facts are clear, then the jury is no longer required, and one side may ask the judge that “discovery has unveiled facts which are not in dispute any longer”. NLST cites JEDEC lawyer testimony and GOOG’s employee Robert Sprinkle (although some of their testimony is blacked out because it is confidential – attorney’s eyes only).
Good points.
Many motions for summary judgment fail because there are still some facts in dispute that haven’t been uncovered in discovery to the satisfaction of the judge deciding the motion, but it’s often worth filing a motion for summary judgment to avoid the expense of a trial, and the time that it might take to have that trial.
Do you know if a summary judgement request usually leads to the judge giving time to the other party to settle ?
That is, if the judge sees things are “not looking good” they can say that in the conferences they have with the two sides’ lawyers, and urge them to settle.
In such a case, GOOG would be hard pressed to settle fast – since with that climate they would be willing to pay MORE than what a judge might order. Since with a judge’s order, GOOG not only has to pay, but also suffers:
- security of GOOG servers in question (could harm GOOG share price)
- GOOG may have to use NLST products ANYWAY if they are the only ones available in this area
- would not help “do no evil” mantra (and GOOG’s entire business model of intrusive “big brother-like” behavior is tempered by the perception that they “are good”)
- would provide ammunition to competitors to use GOOG prior history of subterfuge
So in fact settling is a significant advantage for GOOG – I don’t know if that means that there has to be a premium there for that therefore.
I am not a patent lawyer. But usually in patent law cases, the defendant claims that they have not infringed on the patents. This has not been done by Google. They seem to say that they do not know if they have infringed. This would be somewhat acceptable if they had done some lab experiments. But they have actually gone and hired vendors to construct the ASIC. Therefore, they have infringed- and since they had notice through various means, the infringement may be considered willful.
Hi Netlist,
Usually, an opposing party has time to file a response to a motion for summary judgment, and sometimes the possibility of asking for more time in some instances. Courts do tend to like the possibility that a case might settle before reaching a trial as long as it doesn’t appear that a party is attempting to delay only to make a case drag on.
Hello Netlist,
Is it probable that Google is having the “Mode C” memory modules manufactured and installed while litigation goes on?
quote:
Is it probable that Google is having the “Mode C” memory modules manufactured and installed while litigation goes on?
There has been no indication that GOOG has stopped what it was doing.
GOOG has indicated that the GOOG server they provided to NLST lawyers was representative of the infringing servers.
That does not indicate:
- if they are continuing to do so.
- if they are a minority or a significant portion (10% ?) of the current GOOG server set.
- if these servers are part of GOOG Caffeine project (GOOG’s effort at near real-time search which is probably even more reliant on in-memory techniques, thus requiring more memory than earlier servers). GOOG Caffeine has recently gone mainstream.
It seems NLST is claiming GOOG manufactured “hundreds of thousands of computer memory modules” – as earlier posted:
http://www.seobythesea.com/?p=3097#comment-267873
quote:
——–
From docket 133-2 (which outlines earlier arguments – which eventually led the court to refuse GOOG arguments and grant NLST request for examining GOOG server):
—-
(pg. 2 )
This is a patent infringement case. Netlist owns IP relating to computer memory modules, and it shared some of those inventions under NDA with Google while Netlist’s patents were pending. Google turned down a business relationship with Netlist. Netlist alleges that Google then went on to manufacture hundreds of thousands of computer memory modules using the Netlist technology, and that it now uses those memory modules in server computers at Google data centers.1
——–
While NLST says GOOG maybe using this memory in “hundreds of thousands of servers”, I wonder if GOOG actually uses so much memory.
Some articles have suggested GOOG used to buy bargain basement priced memory.
But maybe the move to Caffeine and scaling have pushed GOOG to use higher-memory computers.
After all, GOOG WAS interested enough to start it’s own memory module division.
But it still remains unclear if all GOOG servers run at max memory loading or just a few.
However, the effects of memory loading maybe apparent at reasonably sized memory levels as well (i.e. don’t have to load to 384GB but maybe apparent as low as 24GB or something ?) and if so availability of HyperCloud-like solutions impacts many more of GOOG servers.
Google Caffeine seems to include these things as well:
- a rewrite of the GFS (Google File System 2 or GFS2)
- doing more stuff “in-memory” (i.e. RAM) including databases all in memory etc. (what is not clear is what percentage of it’s servers would be involved with higher memory use applications – however GOOG interest in making and using it’s own memory may suggest some interest from GOOG in this direction)
NLST CEO Hong has mentioned all these uses for NLST HyperCloud:
- government labs with HPC (High Performance Computing) applications (like Viglen caters to which recently qualified HyperCloud though it may have been because of SuperMicro qualifying – since Viglen sells SuperMicro (SMCI) stuff).
- search applications needing to do things more in memory (RAM)
- database applications where the whole database is in memory (RAM)
- video delivery – supposedly huge user of memory
It is possible GFS2 itself shifts stuff to in-memory use:
http://www.channelregister.co.uk/2009/08/12/google_file_system_part_deux/
or
http://www.channelregister.co.uk/2009/08/12/google_file_system_part_deux/print.html
Google File System II: Dawn of the Multiplying Master Nodes
A sequel two years in the making
By Cade Metz in San Francisco
Posted in Enterprise, 12th August 2009 02:12 GMT
quote:
But GFS supports some applications better than others. Designed for batch-oriented applications such as web crawling and indexing, it’s all wrong for applications like Gmail or YouTube, meant to serve data to the world’s population in near real-time.
“High sustained bandwidth is more important than low latency,” read the original GPS research paper. “Most of our target applications place a premium on processing data in bulk at a high rate, while few have stringent response-time requirements for an individual read and write.” But this has changed over the past ten years – to say the least – and though Google has worked to build its public-facing apps so that they minimize the shortcomings of GFS, Quinlan and company are now building a new file system from scratch.
…
GFS dovetails well with MapReduce, Google’s distributed data-crunching platform. But it seems that Google has jumped through more than a few hoops to build BigTable, its (near) real-time distributed database. And nowadays, BigTable is taking more of the load.
“Our user base has definitely migrated from being a MapReduce-based world to more of an interactive world that relies on things such as BigTable. Gmail is an obvious example of that. Videos aren’t quite as bad where GFS is concerned because you get to stream data, meaning you can buffer. Still, trying to build an interactive database on top of a file system that was designed from the start to support more batch-oriented operations has certainly proved to be a pain point.”
From the comments section:
http://forums.channelregister.co.uk/forum/1/2009/08/12/google_file_system_part_deux/
As for “other tools”; Lustre was invented as a local network filesystem. GFS was invented to handle thousands of tasks all reading & writing as fast as they could all day every day. The indexing pipeline; download the internet, index it, run a few mapreduces over it to mark down spammy sites, crappy sites, duplicate sites, dead sites etc. and then compress it so it could be shipped all over the place. As Sean says in his interview, these days ‘routine use’ is dozens of petabytes of data that has to be randomly accessed – as in, the metadata has to stay in RAM.
“Still, trying to build an interactive database on top of a file system that was designed from the start to support more batch-oriented operations has certainly proved to be a pain point.”
Hi Netlist,
Google has had a long history of attempting to do as much with software as possible while using as many inexpensive computers as they can. The original Google File System focused upon that approach, and the GFS 2 system, which was supposedly developed in 2007-2009, worked hard to distribute the processes involved over more computers, as well as making more processes happen in memory rather than touching disks as much. So more memory on each machine might help.
Google is supposedly working on a GFS 3, but I haven’t heard too much in the way of details. I would suspect that it would still focus upon spreading out processes on as many inexpensive computers as possible, though.
The relevance for NLST investors however is to estimate the number of servers that maybe using high memory (sufficient that memory-loading causes slowdown – in which case the NLST HyperCloud or JEDEC “Mode C” proposed standard related memory modules that GOOG was manufacturing become useful).
If these are common needs for most of their servers (not just the main or central node ones) then there maybe “hundreds of thousands of servers” which are infringing NLST IP.
If they are only a few node servers, that number would be less.
However the fact that GOOG went to great lengths to manufacture the JEDEC “Mode C” proposed standard modules suggests they needed these crucially (and could not rely on JEDEC or the memory module makers to produce these on time). It also suggests that the need was not for a few servers alone.
I don’t know enough about GFS2 (or GFS3 as you suggest) – but the suggestion is that more is being done in-memory (either indexing or database type stuff is in-memory). The question (of interest to NLST investors) is however still how many servers have these high-memory requirements.
Thanks for your comments.
The problem complicating the above analysis is that as GOOG moves to GFS2, does that distributing out of the main nodes’ work to many servers entail using much more memory per server still ?
Or is the move part of a strategy that knows it CAN increase memory per server (earlier node servers may already have been running at high memory) – which is what allows some of the faster (in-memory type) methods to work.
Or are the servers still able to get by with measly amounts of memory – since the tasks they do do not require that much (per server) with the new GFS2 structure.
Hi Netlist,
Part of the change to GFS 2 involves smaller file sizes as well, which should help reduce the amount of memory required per server.
See: Google File System II: Dawn of the Multiplying Master Nodes
A snippet: