Day 3 Of The Juniper Vs. Palo Alto Patent Trial

Feb.27.14 | About: Palo Alto (PANW)

Wednesday was the third day of trial in the patent infringement suit filed by Juniper Networks (NYSE:JNPR) against Palo Alto Networks (NYSE:PANW) in December 2011. For some background on the case, see my previous article discussing the judge's claim construction and summary judgment decision earlier this month and my reviews of days one and two of the trial. I attended the trial Wednesday and provide my observations and thoughts here.

Preliminary Matters

Before the jury was brought in to the courtroom for the trial to continue, Palo Alto told the judge that it objected to some of the testimony given on Tuesday by Juniper's expert witness, Avi Rubin, Professor of Computer Science at John's Hopkins University. Specifically, Palo Alto said that Rubin mislead the jury regarding the meaning of the terms "lookup tables" and "processors." On the latter, which only applies to one of the three patent-in-suit, the '723 patent, Palo Alto objected to Rubin's statement that a "processor" can be hardware, or software, or a combination thereof, because the court's claim construction had rejected Juniper's proposed definition of the term "processor" to include only software. Juniper responded that the court's claim construction decision did not exclude software alone from being a processor. The judge decided to postpone ruling on the issue because Rubin's testimony, including specifically about the '723 patent, was not yet completed.

I believe Palo Alto has a very strong argument on this point as a matter of pure science. In my rudimentary computer science opinion (I began programming in elementary school and continued through college and have litigated over a dozen software intellectual property cases), neither hardware alone, nor software alone, can be a "processor," because, standing alone, neither one can do anything at all. Well, I guess hardware alone can be used as a brick, doorstop or paperweight, but that's about it. Hardware alone surely can't "process" anything. Software alone is completely incapable of doing anything at all, as it is merely an abstract set of ideas that can be expressed in a language either humans or hardware can interpret. A print out of source code is not software, it's a visualization of software, much like a picture of a something is not the thing represented in the picture.

This is, by the way, why I've argued countless times over more than a decade that software is not patent eligible subject matter, because it is only a compilation of abstract ideas, which the Supreme Court has said time and time again are not patentable. And, not to veer too far off topic, in a huge coincidence, the Court of Appeals on Wednesday just happened to affirm a decision by the judge overseeing the Juniper vs. Palo Alto case in which she invalidated a software patent in another case for being ineligible subject matter. Palo Alto could have perhaps challenged the validity of some or all of Juniper's patents in this case on those grounds had the judge not estopped them from doing so. I think those arguments could have had some success, so it's unfortunate for Palo Alto that their hands are tied.

Back to Palo Alto's objection, I personally think it has merit, because Rubin's suggestion that hardware alone or software alone can be a "processor" is just flat wrong. Only a combination of hardware and software can process anything, and thus be a "processor." I suspect the judge may very well come to this same conclusion and instruct the jury at the end of the case that only a combination of hardware and software can be a "processor" not either hardware or software alone. Whether that will materially affect the outcome or not is yet to be seen.

Avi Rubin, Juniper's Technical Expert

After the jury was brought into the courtroom, Juniper continued its direct examination of Rubin by Lisa Glasser. On Tuesday, Rubin had discussed the '612 and '347 patents and how Palo Alto's accused products, in his opinion, infringe Juniper's asserted patent claims, but he had not yet begun to specifically perform an infringement analysis for the '723 patent. Before picking up there, Glasser asked Rubin to circle back to a few issues from Tuesday. For one, she asked Rubin whether an ASIC must be present for an accused device to infringe the '612 patent. He showed the jury how the term ASIC is not mentioned anywhere in the claim language or the court's claim construction decision, and is therefore not required for infringement. Glasser then asked Rubin if he could more specifically describe the difference of opinion between him and Palo Alto's expert, Michael Mitzenmacher, Professor of Computer Science at Harvard, with respect to the '347 patent. Rubin responded by saying it was merely a difference of naming, not substance, because he believes the application of the default deny rule to packets means they are initially denied, whereas Mitzenmacher believes that only a packet that has had an action variable set to deny can be considered "initially denied." Ultimately, the result is that a packet is not allowed through initially unless it matches a rule, said Rubin, and it is instead passed on to a second review in Palo Alto's system.

Returning to the '723 patent, Rubin described how Palo Alto's products contain a particular chip, made by a third party called Cavium, that has various components, including an "SSO" and multiple "cores," which are pieces of hardware that execute software. Rubin continued that the SSO contains a scheduler that keeps track of what packets need actions performed on them and which cores can perform those actions. The SSO routes the packets to the cores when they are available to do work on the packets, Rubin told the jury. He then continued to say that an example of a processor in Palo Alto's products is the function called "slowpath," which creates session table entries for new sessions and also does an initial part of NAT processing and captive portal lookup. Rubin said another processor in Palo Alto's system is called "fastpath," which does a second portion of the NAT processing and captive portal lookup. Each core in Palo Alto's system can only do one function at a time, Rubin said, and therefore slowpath and fastpath have to run on different cores. Rubin then turned to discussing "tag association" and said that step was accomplished by a "Tag_Value" function within slowpath and that the tag would include session information. He described fastpath as using the NAT and captive portal information from the tag.

As he described each of these things, Rubin would cite the lines of code that performed the various functions and then also point out how they corresponded to particular portions of the '723 patent's claim (there is only one claim of the '723 patent being asserted). Rubin also said a couple times that he confirmed his conclusions by reviewing deposition transcripts of Mao and Zuk, two of the named inventors on the patents, and two of the designers of Palo Alto's system. With that, Juniper ended its direct examination of Rubin, and the court took its morning recess.

I found Rubin's analysis of the '723 patent to be much less crisp and clear than his analysis of the other two patents-in-suit. This is somewhat understandable, however, because the '723 patent's claim is much longer, and contains many more parts, than those other two patents. Still, I was not as convinced of his conclusions regarding the '723 patent as I was for the '612 and '347 patents. I expected Palo Alto's cross examination would likely exploit this weakness by highlighting the complicated, multifaceted nature of Rubin's analysis.

Cross Examination

The most dramatic parts of most trials are the cross examinations of witnesses, because they are hostile and the witness does not know what questions will be posed. In patent cases, the cross examination of experts is often the most important, because experts who concede critical points, or lose credibility with the jury, can ultimately lose the case for their client. Palo Alto's cross examination of Rubin was performed by Michael Jacobs. The first point he wanted to get across was that, for the '347 patent, the matching of a policy rule to a packet, which Palo Alto's software does, is not the same as initially denying the packet, which the '347 patent requires. Before getting to that issue specifically, Jacobs sought to impeach Rubin's technical bona fides by pointing out he had made a mistake in his expert report when he said packets matching default deny rules were assigned a security action of deny, because that is in fact not what Palo Alto's systems do. Rubin admitted he made that mistake, but said he did not rely on that conclusion in the infringement analysis he presented in court to the jury. Jacobs really drove the point home that Palo Alto's software does not set an action value of deny for packets that match the default deny rule, and I suspect that will be a significant basis of Mitzenmacher's non-infringement opinion when he testifies later in the trial.

Rubin tried to diminish the dent to his credibility by saying that the setting of an action value is a final decision, and therefore setting of an action value to deny would lead to dropping a packet. Thus, the '347 patent cannot require setting an action value of deny initially, because that would not comport with its invention, which is two-step processing. Therefore, Rubin said, it is indeed more in the spirit of the invention for a packet to not have an action value of deny set initially. Jacobs jumped on that argument by asking Rubin whether it was possible for a two-step system as claimed in the '347 patent to initially set an action variable to deny and then later change that to allow, and Rubin conceded it was indeed possible. Thus, Rubin's implication that the patented invention either required or preferred an action variable not be set to deny initially was pretty well refuted.

On the '612 patent, Jacobs asked Rubin whether the Block IP function impacted the flow of packets both to and from the network, something required by the claims. Jacobs posited that the examples given by Rubin in his direct testimony on this issue, e.g., a denial of service attack, would only result in the blocking of packets coming in to the system. Rubin responded that in thwarting DOS attacks, Palo Alto's system would also prevent certain packets from leaving the network. Jacobs then got Rubin to admit that the Block IP functionality is not itself dynamic, and therefore, it cannot satisfy the patent's requirement of a dynamic rule. Jacobs heatedly pushed Rubin on his opinion that the adding of new IP addresses to the Block IP file constituted new rules. "Would adding new names to a list of members of a hall be creating new rules that those added members can enter?" Jacobs asked. "Yes," Rubin replied, "in the context of the '612 patent, it would."

Jacobs then asked Rubin about the term "lookup table," which the judge's claim construction decision said was a "data structure that stores information." Jacobs specifically asked whether the table used by the Block IP function was a "lookup table," and Rubin denied it was. The issue was contentious, with both men firing back at each other vigorously. "Is not the Block IP table a data structure that stores information?" Jacobs jabbed. "You have to look at the context," Rubin hooked. Jacobs then pointed to examples of dynamic rules given in the patent specification and noted how none were lookup tables. Rubin conceded that was true.

This reference to the specification and its examples is a common tactic used by defendants in patent cases, because they want the jury to limit the asserted patent to only what is set forth therein. This is something the jury is not supposed to do, as they are supposed to instead abide by the breadth of the claim language provided to them through the court's claim construction. Judges can sometimes limit claim language to the examples given in the patent, but here the judge did not do that, which I believe was correct. Thus, if the jury follows its instructions, it should not conclude that the only types of dynamic rules that can infringe are those discussed in the specification, but that's a big "if." This is why defense counsel will frequently push the edge as far as they can get away with in discussing the examples contained in the specification of the patent, and the judge here seems to be extremely lenient, believing curative instructions can be given at the end of the trial to remind the jury that claims are to be interpreted according to her claim construction and not limited to the examples in the patent. We'll see if Juniper asks for any additional instructions along those same lines.

On the '723 patent, Jacobs pushed on the issue that was raised first thing in the morning, namely whether software alone can be an "engine," which is the word in the claim that the judge construed to mean "processor." "Yes, sometimes," said Rubin. "Really?!" exclaimed Jacobs, in clear disbelief that the witness was sticking with that definition, which, as I describe above, myself find tenuous at best (although I concede I have no PhD in computer science).

Jacobs did get Rubin to concede that the slowpath and fastpath functionality get compiled into one file before being loaded on the hardware and that the manufacturer of the chip in Palo Alto's devices describes it as a single processor. These points go to whether there are multiple "engines" as required by the claim, or only a single "engine," which would mean Palo Alto's products do not infringe the '723 patent.

Jacobs then pushed Rubin on the issue of whether a tag is "associated" with a packet before or after it reaches the scheduler, arguing that what happens is that a second tag is associated to the first tag (and not the packet directly) by the slowpath functionality, and thus the required tag association to the packet happens before the packet reaches the scheduler. Presumably this underlies an argument to be made by Mitzenmacher in his non-infringement testimony, that slowpath's pointing to a pointer is not "associating a tag" as required by the patent.

With that, Jacobs completed his cross of Rubin, which I think definitely scored some points, but did not land any knockout blows. Rubin stood up well and did not concede any major issues or lose credibility. Other than the single mistake he made in his expert report, Rubin was not impeached. Of course Palo Alto, and its expert Mitzenmacher, will disagree with Rubin's opinions, but that will merely leave it up to the jury to decide who they believe. Rubin did what he needed to do, which is satisfy Juniper's burden of proof on infringement for each of the three patents and, thus, shift the onus to Palo Alto to try to swing the pendulum back on each.


Glasser stood to ask a few follow-up questions of Rubin. She asked him (again) whether the '347 patent requires an ASIC or APL Engine, or the setting of an action variable or value, and he said the claims as interpreted by the court did not have any such requirements. On the '612 patent, she had Rubin point out how Palo Alto's Network Administrator's Guide describes the Block IP functionality as being able to restrict bidirectional traffic flow, both coming in and going out of the network, as required by the claims. On the '723 patent, Glasser had Rubin tell the jury that the manufacturer of the chip in Palo Alto's products had no role in designing slowpath or fastpath, thus that company's description of the chip being a single processor does not take them into account. At that point, court broke for the day. Thursday morning will begin with Glasser continuing her redirect of Rubin.

Evidentiary Ruling

After lunch, but before the jury returned to the courtroom, Palo Alto told the judge that once Juniper rested its case, it would call as its first witness, Palo Alto's Chairman, President and CEO, Mark McLaughlin. Palo Alto also said it wished to introduce during McLaughlin's testimony an analyst report that described the company as producing "Next Generation" technology. Juniper objected, arguing the document was hearsay, unreliable, and not subject to any verification by the witness, who could say Palo Alto was wonderful without any need to cite a third party report for the point. The judge took the report to review it and, at the end of the day, agreed with Juniper, telling Palo Alto it could not be used.


Like on Monday and Tuesday, I began Wednesday short PANW, as I still remained confident the market misinterpreted the judge's claim construction and summary judgment decision and, as a consequence, is underestimating the risk that Palo Alto faces from the suit. Nothing happened Wednesday to change my opinion. Indeed, due to the fact that Juniper's expert was able to successfully survive cross examination without conceding any devastating issues or losing credibility, I felt a significant amount of risk in my short position was eliminated. The worst thing that can happen now is the case goes to the jury. Had the expert failed miserably, the court could have granted a directed verdict to Palo Alto even before it begins its case in chief. I plan to attend the trial throughout the rest of the week and continue providing updates and thoughts through my Seeking Alpha column and my Twitter feed.

Disclosure: I am short PANW. I wrote this article myself, and it expresses my own opinions. I am not receiving compensation for it (other than from Seeking Alpha). I have no business relationship with any company whose stock is mentioned in this article.

Additional disclosure: My position as of submission of this article to the Seeking Alpha editors is disclosed. However, legal matters like the one discussed herein are highly dynamic as there can be, for example, new developments in the mentioned matter itself or in the law that applies to the matter at any moment without notice. Thus, the opinions I express herein are my opinions as of submission of this article to the Seeking Alpha editors and I may change my opinions or my position in any related security at any time for any reason. This article was originally available for my clients and to the public for a fee. It is now being made available here for free for the public.