Thursday was the fourth 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, two and three of the trial. I attended the trial Thursday and provide my observations and thoughts here.
Before the jury was brought in to the courtroom for the trial to resume, Juniper told the judge that it was concerned Palo Alto's expert witness may testify in a way that contradicts the judge's claim construction order. Particularly, Juniper was concerned that Palo Alto was trying to convince the jury certain things are required for infringement that the judge had said were not required. For example, Juniper expected Palo Alto to suggest that use of an ASIC (application specific integrated circuit), a firewall and an IDS (intrusion detection system) were all required, when that is not what the judge found in her Markman ruling earlier this month.
Palo Alto tried to respond to Juniper's concerns, but was immediately cut off by the judge, who said she had already decided there would need to be a specific instruction given at the end of the trial telling the jury that use of the specification and its examples was only relevant to the issue of infringement under the doctrine of equivalents. She felt strongly about this because Palo Alto has been, in her opinion, trying to use the specification and its examples to impact the jury's direct infringement analysis, which is improper.
I agree with the judge's ruling on the issue, and I am also confident Juniper's attorney will, on cross examination and during closing arguments, make sure to tell the jury at least seventeen times that direct infringement requires an analysis of the full scope of the claims as construed by the court and is not to be limited to anything written or described in the body of the patent, including its examples.
Avi Rubin, Juniper's Technical Expert
After the jury was brought in to the courtroom, Lisa Glasser continued her redirect examination of Juniper's expert witness, Avi Rubin, Professor of Computer Science at John's Hopkins University. On Tuesday and Wednesday, Rubin had been questioned at length by both parties regarding his opinions that Palo Alto infringes each of the three patent-in-suit, the '723, '612 and '347 patents. Glasser took the opportunity to ask Rubin questions Thursday morning just to briefly have him reiterate for the jury that his opinions had not changed from how he explained them the previous days. Her redirect ended in less than five minutes, but it was extremely worthwhile to start the day this way because the rest would be spent with Palo Alto getting to tell its story.
Interrogatories, Stipulated Facts, and Admissions
Juniper wrapped up its case-in-chief by reading to the jury selected answers provided by Palo Alto to questions Juniper posed during discovery as well as certain facts to which Palo Alto stipulated and responses Palo Alto made to Juniper's requests for admission. This material all dealt with factual issues relating to the way in which Palo Alto's products operate and are not significant areas of contention. With that, Juniper rested its case for this first portion of the trial dealing only with direct infringement.
Mark McLaughlin, Palo Alto Chairman, President and CEO
The first witness called by Palo Alto was Mark McLaughlin, Palo Alto's Chairman, President and CEO. Direct examination of McLaughlin for Palo Alto was performed by Harold McElhinny, who began by asking him about his background and work experience. McLaughlin described how he had been an attorney at first, then became a business executive, and eventually landed the job as CEO at Verisign before taking on the CEO position at Palo Alto in August 2011, just a few months before this suit was filed. He noted he had previously been offered the Palo Alto CEO position, but declined for family reasons, to stay in the Washington, D.C., area, rather than move to California.
McLaughlin told the jury that Palo Alto's biggest competitors are Cisco, Juniper and Check Point, but that Palo Alto has distinguished itself from its competitors by changing the definition of security. Specifically, he said, Palo Alto's products allow the safe use of applications, whereas previously available products only offered customers the ability to do wholesale allowing or blocking of certain network traffic. McLaughlin elaborate on that point by saying Palo Alto offers "Next Generation" internet security products and that the company is regarded as the "pioneer" in the industry. To match the patriotic name dropping of Juniper's Chairman from earlier in the week, McLaughlin noted for the jury that the Department of Defense was its second largest customer. He mentioned Palo Alto has its own patents and acknowledged having stock in the company worth about $100M.
Glasser then cross examined McLaughlin for Juniper. First, she had him admit that he has no technical background or expertise, that he only joined Palo Alto in mid 2011, so was not at the firm when the first infringing products were developed, and has had only minimal involvement with technical issues since arriving at the company. Perhaps Glasser's biggest achievement, especially for a potential motion by Juniper for an injunction against Palo Alto if they are found to infringe any of Juniper's patents, Glasser was able to get McLaughlin to concede that Juniper's SRX650 product, which was shown to the jury on Day 2, competes head-to-head with Palo Alto's "Next Generation" products. Glasser was also able to get McLaughlin to agree to an important legal point, that the presence of any distinguishing factors between Palo Alto's products and Juniper's products has nothing to do with the patent infringement analysis at issue in the case.
McElhinny briefly redirected McLaughlin, but not on anything material. With that, McLaughlin was excused. I thought he did just fine in front of the jury. He did not come off arrogant or as though the process was beneath him. He was quite adversarial with Glasser, which isn't surprising since he was a successful attorney himself, but he wasn't so aggressive that he was offensive or belligerent. It was easy to tell he's a tough business man and hard negotiator. Ultimately, he did what he was supposed to do, which is put a face on the company and say, "Hey, we're good Americans, too."
Michael Mitzenmacher, Palo Alto's Technical Expert
Palo Alto then called its expert, Michael Mitzenmacher, Professor of Computer Science at Harvard, to the stand. Palo Alto's direct examination of Mitzenmacher was performed by Michael Jacobs, the same attorney who cross examined Juniper's expert, Rubin. Jacobs began by walking Mitzenmacher through his educational and professional background. He explained how his PhD thesis focused on lookup tables and hash tables, because he found them particularly interesting. He also said he had experience with resource load management.
When asked to consent to Mitzenmacher's qualifications as an expert, Juniper's attorney, Morgan Chu, reserved the right to object later. I found this quite ridiculous. Is Juniper really going to argue a Harvard computer science professor is not qualified to analyze network security software? I mean, if the guy doesn't know what he's talking about, you can easily prove that with your questioning on cross examination. There is absolutely no chance the judge will strike him as an expert, so raising the prospect of such a request is a complete waste of time.
Regardless, with the qualification of Mitzenmacher as an expert out of the way, Jacobs then proceeded to have him give an overview of the basic technology involved with network security. Mitzenmacher explained how traditional firewalls only look at packet headers and then, as a consequence, reject all related packets with similar headers in the same session. He told the jury that intrusion detection systems (IDS) would often be the next layer of security, inspecting packets with greater granularity. He then transitioned to discuss how he performed certain tests and experiments on Palo Alto's software even though, like Rubin, he was not able to compile source into machine code. He said he tested the operation of the accused software by adding print statements to create log files that would then allow him to see what actions the system was performing.
As the last bit of general background, Mitzenmacher discussed the chips contained in Palo Alto's accused devices, which are provided to Palo Alto from a third party, Cavium. The chips, called Octeon, have multiple cores, Mitzenmacher said, so they can perform several functions at the same time. He said his analysis also relied on a Cavium document showing how the Octeon chips operate, including, for example, that a Work Queue Entry (WQE) is created in memory for a packet as an initial matter before the packet is processed by the SSO (scheduler) that then in turns sends a pointer to the WQE of a packet needing an action to be performed to a core that is available and appropriate to perform that action on it. With that foundation, Mitzenmacher proceeded to discuss each of the patent-in-suit and his opinions that none of them are infringed by the accused Palo Alto devices.
The '723 Patent
Unlike Juniper, who ended with the '723 patent, Jacobs chose to start with it, perhaps because it was the most complicated, and thus perhaps easiest to avoid infringing, of the three patents. I remarked in my comments on day three of the trial that Rubin was most unpersuasive on this patent, due in large part to its complexity and numerous parts. Mitzenmacher first went through portions of the patent's specification and drawings. This is consistent with Palo Alto's strategy to have the jury thinking about what the patent's say in their description and show as their examples when they are rendering their verdict. Juniper, if you haven't already noticed, wants to avoid that as much as possible, and have the jury only focus on the claims and the court's claim construction. Mitzenmacher introduced his opinion on the '723 patent to the jury by saying there were three reasons why Palo Alto's products do not infringe it. First, there is no "second engine" that is different from the "third engine." Second, there is no "tag" associated with a packet by the "second engine." Third, there is no "routing".
On the first issue, Mitzenmacher explained that there is no "second engine" that is different from the "third engine" because the "slowpath" and "fastpath" software functionalities identified by Rubin as the "second engine" and "third engine"are actually one in the same engine. Rubin had said that separate functionalities contained within a single piece of software, the "slowpath" and "fastpath", were separate processors, but it is undisputed that they get compiled in to one machine code file that is then loaded on the Cavium chip contained in the Palo Alto devices. Thus, there is only one software executable, and all packets go through both slowpath and fastpath in one continuous flow. The fact that they may be run on different cores, as Rubin argues, is of no consequence, because they are still contained in a single file and run on a single chip. Thus, they cannot be considered separate processors, which is the definition the judge gave to the term "engines" in her claim construction ruling. Regardless, Mitzenmacher performed an experiment that showed slowpath and fastpath can, and indeed do, run on the same core. Jacobs had Mitzenmacher tell the jury that Rubin had previously conceded, at this deposition, that slowpath and fastpath ran on the same core, although at the time he said it was irrelevant. That deposition was before the court's claim construction, which said that separate cores is indeed relevant, Mitzenmacher concluded. In short, Palo Alto's products have one processor (thus one "engine") and one chip (the Cavium Octeon chip), so there is no "second engine" and '"third engine" as required by the patent.
On the second issue, Mitzenmacher explained there is no "tag" associated with a packet by the "second engine" because even if slowpath is, for the sake of argument, considered to be a "second engine", it does not associate a tag with packets. Instead, Mitzenmacher continued, slowpath merely points to the WQE previously associated with the packet, which is the tag. Thus, the tag was already associated with the packet before slowpath got involved, Mitzenmacher concluded. Further, Rubin said the session ID was the tag, but the court's claim construction requires tags to be data structures, and a session ID is a value that gets contained in a data structure. Thus, to Mitzenmacher, the session ID can not be a "tag" as required by the patent anyways. Lastly, the session ID is associated with a packet through the WQE, and not slowpath.
On the third issue, Mitzenmacher explained that there is no "routing" because the SSO (scheduler) does not route packets, as Rubin had opined. Instead, Mitzenmacher explained, the SSO merely sends to a core that will perform an action on a packet a pointer to the WQE for the packet, not the packet itself. Thus, there is no "routing" of the packet by the SSO. At most, all it "routes" is a pointer to the WQE that is associated with a packet. Further, under the doctrine of equivalents, Mitzenmacher concludes that the sending of a pointer by the SSO to a core by the Palo Alto system performs a different function than the patented invention, in a different way, to achieve a different result. As an aside, for the rap fans out there, I tell my students that whenever they are responding to a doctrine of equivalents argument, they should simply emulate 2 Chainz (warning: link NSFW). Having finished analyzing the first patent, court broke for lunch.
The '347 Patent
After lunch, Jacobs turned Mitzenmacher's attention to the '347 patent, which he opined was not infringed because the default rule in Palo Alto's system does not "initially deny" packets as required by the patent. Instead, all packets are marked as allowed (with an action value of 0) and left that way unless and until they are switched to deny (with an action value of 1). Mitzenmacher told the jury that to determine if a packet has been initially denied you need to focus on the action value setting given to the packet by the system. In Palo Alto's system, no action value is ever switched from deny (1) to allow (0), therefore there is never any packet that is "initially denied." With respect to the fact that the claim language does not expressly require an action value be set to deny, Mitzenmacher said that there has to be some action that takes place to a packet with a deny action value for it to have been "initially denied." To "initially' deny something means that you've later changed its from deny to allow, Mitzenmacher quipped, and since Palo Alto's products do not do that (they only initially allow and then change that to deny), they don't infringe.
I noted at this point that the jurors were sitting back in their chairs, some with arms crossed. I wasn't exactly sure why that was, or what it meant, but it was a stark contrast to the way they had appeared during Rubin's direct on Tuesday afternoon when they denied the opportunity to take a break. I felt Mitzenmacher generally presented very well, and although he has a tendency to speak in sentences of no less than a hundred words and ten commas, he kept eye contact with the jury, maintained an excellent tone of voice, and continuously used simple understandable examples to aid in explaining his points. (And I think that last sentence has a hundred words and ten commas, so who am I to throw stones.)
Maybe it was just an after lunch crash hitting the jurors, although, I will say that at some points Mitzenmacher even lost me as he was getting deep in to the weeds of his analysis, and particularly his description of line by line of code. If I was lost, as a patent attorney having some familiarity with and interest in software, then I'm sure there is a risk he may have lost some of the jury at points as well. That's what is so interesting about juries sitting in patent trials, where you have an assembly of random Americans presiding over such deeply technical subject matter with which they likely have absolutely no experience or interest. It really is fascinating how our American legal system works.
As for the doctrine of equivalents for the '347 patent, Mitzenmacher again channeled his inner 2 Chainz and explained how Palo Alto's system performs a different function because it never performs a second analysis of whether to deny a packet, which is what the '347 patent is all about. He also said Palo Alto's system performed the different function in a different way, because it did not use an ASIC, which is the structure shown being used in the patent. Finally, he said Palo Alto's system achieves a different result, because the patent causes packets to be changed from deny to allow, while Palo Alto's system never does that. It only switches from allow to deny, not vice versa. The '347 patent, on the other hand, never switches a packet from allow to deny. It only switches from deny to allow. Whether those are substantial differences or not will be for the jury to decide.
The '612 Patent
On the '612 patent, Jacobs first had Mitzenmacher discuss what it means to be a "rule", and he used the example of persons who have served jury duty being exempt from being called for jury duty again for at least two years. By adding names of jurors to the list of those to not be asked again for two years, Mitzenmacher said you are not creating a new rule for each name. Rather, he opined, you are merely adding entries to a list. The rule, in his example, is that jurors are exempt for two years, and that rule is preexisting, not created on the fly as jurors complete their service. Applying the analogy to the facts in this case, Mitzenmacher said that the addition of IP addresses to the Block IP functionality in Palo Alto's system is not adding rules, but instead adding entries to a lookup table.
Mitzenmacher than went through a list of user defined rules in Palo Alto's system, and he noted that the Block IP function does not add any to the list even as IP address entries are added to the Block IP table. Indeed, Mitzenmacher said nothing in Palo Alto's system at all adds rules while it is running. All rules have to be created by users and implemented before the system operates. Thus, none of the "rules" are dynamic, as required by the patent. Mitzenmacher then explained an experiment he ran where he timed how long it took for the Block IP function to add a new IP address to its table and how long it took for each of the rules he identified to run. He determined that the rules took, on average, ten times longer to run than it took to add IP addresses to the Block IP table. In his opinion, that striking result supported his conclusion that the Block IP table is more properly considered a lookup table, not a "rule", as required by the patent. As such, Palo Alto's system does not create dynamic rules, and does not infringe the '612 patent.
At that point, court broke for the day. The direct examination of Mitzenmacher will continue Friday morning. So far, I thought Mitzenmacher was doing exactly what he needed to do, which is provide the jury an alternative opinion regarding infringement for each of the three patents-in-suit. But, being subject to direct examination is fairly easy and straight forward, as it has been practiced and rehearsed many times. The figurative fireworks will take place when Juniper's counsel cross examines Mitzenmacher, something I expect will begin on Friday as well.
Once the cross and then redirect of Mitzenmacher is completed, I expect Palo Alto to read in some of Juniper's answers to interrogatories and responses to requests for admissions as well as some more stipulated facts favorable to it. Once that is done, the parties will move on to make their closing statements and the judge will read to the jury her final instructions, at which point they will retire to the jury room to begin deliberations. I expect that to occur Monday afternoon or Tuesday morning.
Like on Monday, Tuesday and Wednesday, I began Thursday 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 Thursday to change my opinion, mostly because there was no cross examination on any issues of importance that occurred on Thursday. McLaughlin's testimony is substantively meaningless, and he did not do anything to offend the jury in a way that could alter their decision. The redirect of Rubin and direct of Mitzenmacher are largely scripted, so they went exactly as planned, with the experts telling the jury what their respective attorneys needed. I plan to attend the trial Friday and continue providing updates and thoughts through my Seeking Alpha column and my Twitter feed.
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.