More on Resonate v. Alteon
I got some emails asking to further clarify which claims were infringed etc. Here's a little more detail.
We believed the infringed claim was number #6.
Alteon argued that the entire patent was based on what we called the 'triangular data flow' where the return data bypassed the load balancer. However, the return path of the packets isn't introduced until claim #11 which adds:
Our lawyers told us that it's standard claims construction that each claim is examined separately. Yet, to our astonishment, the initial claims construction muddled claims #6 and #11. Where 'transferring the requested resources' from claim #6 was constructed to mean:
On appeal, we challenged this bypass language and made it the focus of our appeal. There were other aspects of the construction, but for whatever reason (I forget now), we didn't argue all issues with the construction because we first needed to get back in the game by overturning the 'bypass' language.
The other part of the construction that was problematic was 'transferring the connection' from claim #6. The district court ruled that:
At this point all Alteon had to do was agrue that there were lots of things that determined the connection (packet sequence numbers, for example), and since theirs were different from ours, they didn't infringe. We needed to agrue that the connection information was simply source and destination IP addresses. I felt the game was already lost because this is a purely subjective determination, and their arguement was a lot easier to make than ours.
In the end, this is what killed us. It didn't matter that a specific protocol was being used. Even though the claim covered any protocol, each protocol would be unique so any protocol other than TCP would not infringe.
I've lost track of the litigation and it might actually still be in the courts, but once the claims were constructed like this it didn't seem worth the effort. Any nitwit could implement something that didn't infringe.
We believed the infringed claim was number #6.
6. A computer-implemented method of servicing requests for resources from a client by nodes containing different resources, the computer-implemented method comprising the steps of:
making a connection and setting up a session between the client and a load balancer at a web site for servicing requests from clients;
waiting for a URL request from the client once the load balancer has made the connection with the client;
receiving the URL request from the client and decoding the URL request to determine a requested resource;
comparing an identifier for the requested resource to identifiers for resources located on a plurality of nodes and determining a first subset of the plurality of nodes which contain the requested resource and a second subset of the plurality of nodes which do not contain the requested resource;
assigning the URL request to an assigned node in the first subset of the nodes which contain the requested resource, by determining the assigned node to be a server in the first subset of the nodes which is least busy processing requests, wherein the assigned node is not in the second subset;
transferring the connection and the session setup to the assigned node containing the requested resource by storing packets received from the client when establishing the connection and by transmitting the packets to the assigned node after the URL request is received;
reading the requested resource on the assigned node and transmitting the requested resource to the client,
whereby the assigned node is selected based on a location of the requested resource determined from the URL request and load balancing is performed among nodes having the requested resource and the connection is transferred from the load balancer to the assigned node by re-transmitting the packets to the assigned node.
Alteon argued that the entire patent was based on what we called the 'triangular data flow' where the return data bypassed the load balancer. However, the return path of the packets isn't introduced until claim #11 which adds:
11. The computer-implemented method of claim 10 wherein the step of transmitting the requested resource to the client from the assigned node comprises
transmitting the requested resource in TCP/IP outgoing packets which contain the virtual IP address of the load balancer as a source IP address but an IP address for the client as the destination IP address, wherein the TCP/IP outgoing packets bypass a node with the load balancer,
whereby incoming packets are routed to the load balancer but the outgoing packets bypass the node with the load balancer.
Our lawyers told us that it's standard claims construction that each claim is examined separately. Yet, to our astonishment, the initial claims construction muddled claims #6 and #11. Where 'transferring the requested resources' from claim #6 was constructed to mean:
“transmitting outbound data packets from the server directly to the client using the connection with the client which was transferred to the server, causing the outbound data to bypass the load balancer.”We were dead. Utterly and completely dead.
On appeal, we challenged this bypass language and made it the focus of our appeal. There were other aspects of the construction, but for whatever reason (I forget now), we didn't argue all issues with the construction because we first needed to get back in the game by overturning the 'bypass' language.
The other part of the construction that was problematic was 'transferring the connection' from claim #6. The district court ruled that:
“transferring the connection” was interpreted to mean “replicating the unique connection information of the original connection between client and load balancer and transferring it to the assigned server so that the connection exists between client and assigned server.”'Unique connection information' was taken straight out of Alteon's brief. We knew it was bad if that remained since our implementation was different from others so of course no two implementations would result in identical 'connection information'.
At this point all Alteon had to do was agrue that there were lots of things that determined the connection (packet sequence numbers, for example), and since theirs were different from ours, they didn't infringe. We needed to agrue that the connection information was simply source and destination IP addresses. I felt the game was already lost because this is a purely subjective determination, and their arguement was a lot easier to make than ours.
In the end, this is what killed us. It didn't matter that a specific protocol was being used. Even though the claim covered any protocol, each protocol would be unique so any protocol other than TCP would not infringe.
I've lost track of the litigation and it might actually still be in the courts, but once the claims were constructed like this it didn't seem worth the effort. Any nitwit could implement something that didn't infringe.
4 Comments:
Great post.
Seems the basic fact is that you made two inventions, a)delayed binding b) bypass. But the patent isn't drafted properly (claim 6 is limited by 11) and you guys got bad legal advice (claim 6 can be construed independently).
Why didn't you guys sue people who uses bypass, instead of Alteon which didn't?
BTW, as the inventor, did you find the discovery process intrusive?
Cheers.
Anonymous said:
1. Seems the basic fact is that you made two inventions, a) delayed binding b) bypass. But the patent isn't drafted properly (claim 6 is limited by 11) and you guys got bad legal advice (claim 6 can be construed independently).
Yes indeed. There are two clearly identifiable inventions and we did consider filing two separate patents. We were advised that in order for a patent to be issued, there needed to sufficient substance and 'new invention' and at the time we weren't sure that delayed binding would do it. We were also comforted that there was sufficient precedent for 'claim independence' that as long as we drafted the claims to capture the separable nature of the two inventions we'd be OK.
As for being drafted improperly, I'm not exactly sure I know what you mean. Yes, Claim 11 is a dependant claim, but 6 is not. Claim 6 stands by itself and captures the entirety of the delayed binding features.
Claim 11 is a dependant claim and depends on 10, which depends on 9, 9 on 7, then 7 on 6. Yes, 11 is the 'bypass' claim, but in order for 'bypass' to be implemented as we intended (which is how the benefits are derived), you'd have to implement 7, 9, 10 and 11. So we didn't think there any problem with this. In fact there was no other way since 'bypass', all by itself, without the specific qualifiers of 6, 9 and 10 is not a new invention. You’d just have to set your default gateway to a different 'bypass' IP address, or change the MAC address (which is what some competitors did). Nothing new there.
This intertwining of multiple ideas is what allow Alteon to drive a wedge in our infringement prosecution. They argued that since the body of the patent discussed at length the benefits of 'bypass', it was an essential aspect of the invention and must be inferred in claim 6. Our legal counsel came back with the long standing principles of 'claim independence' and decoupling the body of the patent with the language of the claims.
This all seemed pretty solid to us. We even went to an arbitration hearing where the judge told Alteon that our case was pretty solid and they ought to settle. We had been open to a licensing arrangement from day one. Alteon was part of Nortel by then and their counsel had no incentive whatsoever to settle and continued the litigation. We were pretty confident until the District Court stunned us with their initial claims construction which spliced claims 6 with 11 to include the 'bypass' language.
Also part of the District Courts decision were some other things that worried us. I think the 'unique connection information' was there, but not 100% sure. One thing I do remember was that we were advised to 'choose our battle' and focus on the most important part of the decision and not blanket our appeal with a rehash of our initial arguments.
This lead us to focus on the 'bypass' language almost exclusively. I forget the exact advice we got, but it was essentially: "If you fight every point on appeal, you run risk of not getting anything. Focus on what you really need (i.e. the 'bypass' language) and live to fight another day, where you can make your case on the other points at trial".
In retrospect, this was a mistake. What we 'really needed' was both the 'bypass' and 'unique' language out of the claims. Our lawyers may not have fully understood the difficulty of arguing against the 'unique connection information' language. I certainly did, but I also knew that we at least needed to win on the 'bypass' language otherwise the 'unique' language was moot.
The reality was that the initial claims construction was a double whammy. We should have realized that even with favorable 'bypass' appeal, we were dead with the 'unique' language. We should have swung for the fences on appeal.
2. Why didn't you guys sue people who uses bypass, instead of Alteon which didn't?
It turned out that we were the only ones using the bypass features as they were described in the patent (at the IP layer, ISO layer 3). Some competitors had a bypass feature that avoided infringement entirely by altering the MAC address (ISO layer 2). At the time of the invention, we thought outbound packets bypassing the load balancer would provide the scalability that was necessary for high traffic sites. It turns out that the processing outbound packets at Layer 3 didn't degrade performance as much as we initially thought, so not bypassing wasn't much of a problem. Everyone did 'delayed URL binding' but no one did bypass.
3. BTW, as the inventor, did you find the discovery process intrusive?
No, not really. Me, along with the other three inventors were deposed and spent about 8 hrs. with them. There were several funny moments along the way with their lawyers trying to paint us into a corner, but not being network guys, they simply got confused and tied up in knots. They asked rhetorical questions fully expecting 'yes' answers, where we would confidently respond 'no'. As much as I wanted to help them resolve their confusion, I was strongly advised to remain silent.
In the end, though, they had the last laugh.
"There are two clearly identifiable inventions and we did consider filing two separate patents."
You don't have to file two. As long as you make independent claims of the inventions, you are ok.
"..at the time we weren't sure that delayed binding would do it.."
Aha, my feeling exactly. I don't know the prior art on that, i.e. whether URL-based content addressing is indeed a new invention. Unfortunately the litigation didn't even get to argue about the prior arts.
"We were also comforted that there was sufficient precedent for 'claim independence' that as long as we drafted the claims to capture the separable nature of the two inventions we'd be OK."
I'm confused. Claim 7-13 are drafted to be dependent on 6, therefore would read on 6 as further limitations of the subject matter. The district court interpreted the claims narrowly - but correctly. Instead of getting a patent on 2 inventions, you guys got a patent requiring a combination of the 2 inventions.
After reading Federal Circuit ruling, I find it funny that the district court based its ruling on execuses like the "level of detail" analysis. No wonder it got overturned on appeal. The court could have just said you guys failed to claim delayed binding as the invention.
"...The reality was that the initial claims construction was a double whammy. We should have realized that even with favorable 'bypass' appeal, we were dead with the 'unique' language..."
The appeal court handed you guys a big victory. Why didn't you guys immediately press the delayed binding argument and invoke doctrine of equivalents (provided your strategy is to focus on delayed binding instead of bypass)? There is no need to argue about specific tcp implemenations. If you do, Alteon could turn its weak position around.
"It turned out that we were the only ones using the bypass features as they were described in the patent.."
The claim's too narrow. It reads like a specific layer 3 implemenation. You can't even go after those who do bypass. Too bad.
"It turns out that the processing outbound packets at Layer 3 didn't degrade performance..."
Really?! That certainly takes the air of a lot of marketing brochures.
"As much as I wanted to help them resolve their confusion, I was strongly advised to remain silent..."
Did you counsuel have to tug your sleeve not talk too much during the deposition? Just kidding. :)
"...I'm confused. Claim 7-13 are drafted to be dependent on 6, therefore would read on 6 as further limitations of the subject matter. The district court interpreted the claims narrowly - but correctly. Instead of getting a patent on 2 inventions, you guys got a patent requiring a combination of the 2 inventions..."
We never believed that any of claims 7-13 were being infringed. Only claim 6, which is independent. So, yes, you are right. The 'Invention' of claim 11 is dependant (and quite narrow). Claim 6 ('delayed URL binding'), however, is where all the action was.
Yes, 7-13 are narrower, but all these were necessary to get to the 'bypass' feature to be allowed by the examiner. Alternatives that attempted broader interpretations were rejected.
"...No wonder it got overturned on appeal. The court could have just said you guys failed to claim delayed binding as the invention...."
We did have some confidence it would be overturned on appeal, but as for failing to claim delayed binding as the invention, I disagree! We did not fail to claim delayed binding as the invention. That's what claim 6 is!
Your perspective is what Alteon argued, which was that the invention was 'bypass' and this delayed binding claim 6 needed to infer that as well.
"...The appeal court handed you guys a big victory. Why didn't you guys immediately press the delayed binding argument and invoke doctrine of equivalents...."
This is exactly what we did. That's how we thought we'd be able to overcome the 'unique connection information', but it's much harder with that language in the claim construction. 'Unique' is a pretty strong condition.
I've actually lost track of the status of the entire process. I think it went to trial, but was dismissed on summary judgment, but even that might have been appealed. No one has asked me to get involved....
Post a Comment
Links to this post:
Create a Link
<< Home