[00:00:00] Speaker 05: The next case for argument is 23-2155, eBuddy Technologies versus Stewart. [00:00:40] Speaker 05: Good morning. [00:00:41] Speaker 01: Good morning. [00:00:42] Speaker 01: May I please support Steve Slider for the appellant e-Buddy Technologies. [00:00:47] Speaker 01: The claims of the 395 and 453 patents require an aggregated contact list that is maintained, stored, and provided to a display device. [00:00:58] Speaker 05: Can I ask you a housekeeping question about this? [00:01:01] Speaker 05: There's so many issues that you've raised in this case. [00:01:03] Speaker 05: There are at least three claim constructions. [00:01:06] Speaker 05: issues that deal with different limitations, right? [00:01:10] Speaker 05: So is it your view that if you win on any one of these, it's a vacate? [00:01:19] Speaker 01: Well, yes, with regard to the construction of aggregated contact lists, that applies to both patents. [00:01:28] Speaker 01: High- and low-level networks also apply to both patents. [00:01:31] Speaker 01: With regard to the construction of a messaging service provider, that would only apply to the 395 patent. [00:01:37] Speaker 01: That term is only used in the one patent. [00:01:39] Speaker 01: Okay. [00:01:42] Speaker 05: Sorry, Doug. [00:01:44] Speaker 01: Here there's no substantial evidence that O'Dell discloses an aggregated contact list. [00:01:50] Speaker 01: The touchstone in the 395 and 453 patents is a single aggregated contact list. [00:01:58] Speaker 01: O'Dell discloses at most only multiple non-aggregated lists or arguably an aggregation of separate and distinct lists, but that's still not a single list. [00:02:12] Speaker 01: The board's findings and the director's arguments all require that an aggregated list comprise multiple different lists because that's all that ODEL discloses, multiple separate lists. [00:02:27] Speaker 01: ODEL specifically describes what it shows, which are separate buddy lists [00:02:32] Speaker 01: not a single aggregated contact list. [00:02:35] Speaker 01: For example, Odell says it displays buddy lists for all linked accounts. [00:02:40] Speaker 01: That's it. [00:02:41] Speaker 01: Column 833 through 34. [00:02:44] Speaker 01: regarding certain figures in ODEL. [00:02:47] Speaker 01: It describes interfaces for showing buddy lists for multiple linked accounts. [00:02:52] Speaker 05: And it describes an interface that's used to access... But before we get to ODEL, why don't we go to the claims themselves and the specification and where you get your claim construction based on those items. [00:03:09] Speaker 01: The 395 and 453 patents are directed to a technique for contact list aggregation across a plurality of different networks, and that's at column one, line 61 through 63. [00:03:24] Speaker 01: So there it talks about what these patents are directed to, is aggregating [00:03:29] Speaker 01: into a single list contacts from other sources, networks, or messaging services. [00:03:36] Speaker 02: Where in the reference, or where in the patent, does it talk about aggregating the contact lists into a single integrated list? [00:03:48] Speaker 02: So for example- As I understand it, that's your argument, that it should be interpreted [00:03:53] Speaker 02: to mean a single integrated contact list. [00:03:56] Speaker 02: That's correct, Your Honor. [00:03:58] Speaker 02: So where is there any suggestion that that's the proper interpretation? [00:04:06] Speaker 01: Yes, Your Honor. [00:04:06] Speaker 01: So for example, claim one requires an aggregated contact list that comprises of first contacts from a first contact list and a second contact list. [00:04:19] Speaker 01: How does that help answer? [00:04:22] Speaker 02: That doesn't mean it's a single integrated list, as long as it's aggregated. [00:04:28] Speaker 02: Aggregated means pulled together. [00:04:33] Speaker 01: Yes. [00:04:33] Speaker 01: And so that's what the patent is directed to, is pulling together these disparate or separate lists into a single list. [00:04:40] Speaker 01: And so that's shown, for example, at Figure 4A. [00:04:45] Speaker 01: And I'll reference the 395 patent. [00:04:46] Speaker 01: The specifications are the same for both. [00:04:51] Speaker 01: In Figure 4A, what you see is an aggregated list. [00:04:56] Speaker 01: And it shows, and we've colorized it in our briefing so it stands out. [00:05:01] Speaker 01: Contacts they're taken from three separate sources. [00:05:05] Speaker 01: They're put into a single aggregated list. [00:05:07] Speaker 05: But doesn't 4A, doesn't the specification refer to the figure as a multi-network IM display? [00:05:15] Speaker 05: Doesn't call it an aggregated contact list, does it? [00:05:18] Speaker 01: I don't, I think that is correct, but that is the aggregated contact list. [00:05:21] Speaker 01: That is a display of the aggregated contact list. [00:05:24] Speaker 05: And we're in the specification, how do we know that? [00:05:26] Speaker 01: Well, we also know that in Figure 5, it talks about... Well, let's stick with Figure 4a. [00:05:32] Speaker 05: Is that all? [00:05:33] Speaker 05: Is it just you're telling us that it means an aggregated contact list, or is there something in the specification that would give support to your conclusion? [00:05:42] Speaker 01: Well, the fact that it talks about taking these contacts from different sources and putting them into and displaying them as that single list that's shown in Figure 4A is the support for the aggregated contact list. [00:05:59] Speaker 04: But it never actually says, it never refers to that list as being an aggregated contact list. [00:06:05] Speaker 01: For figure 4A, it does not. [00:06:08] Speaker 01: But if you go to figure 5, the flow chart there talks about gathering these contact lists and then displaying an aggregated contact list. [00:06:18] Speaker 01: Okay, and how does that help you? [00:06:20] Speaker 01: Well, that goes to the point that the aggregated contact list is a collection, a gathered or collection of these contacts from different sources into the single integrated whole that we talk about. [00:06:37] Speaker 04: One of the problems is just the way the claim is written, where it says there's an aggregated contact list that comprises the first contact list and the second contact list. [00:06:50] Speaker 04: I mean, that's pretty broad, right? [00:06:54] Speaker 01: It could be, but in this context, I think what it's talking about is that it takes these contact lists from other networks or messaging services and it puts them together into the aggregated contact list that's claimed. [00:07:16] Speaker 01: So here, what Odell talks about [00:07:21] Speaker 01: is this concept of buddy lists. [00:07:24] Speaker 01: And there's no disclosure in ODEL that it ever aggregates those separate buddy lists into a single aggregated list. [00:07:38] Speaker 01: The board and the directors' arguments talk about [00:07:45] Speaker 01: Adel's figures for C, for A through C, but specifically looking at for C, where it shows a buddy list for two separate users here. [00:08:01] Speaker 01: But that's simply the display of two separate lists, not an aggregation into a single aggregated contact list. [00:08:12] Speaker 01: So displaying multiple separate lists does not disclose displaying a single aggregated list. [00:08:21] Speaker 01: Also relevant to O'Dell's lack of disclosure of any aggregated contact list is that the claims require that the aggregated contact list be stored and maintained. [00:08:32] Speaker 01: So even if the board was correct that this display, for instance in Figure 4C of O'Dell, somehow [00:08:41] Speaker 01: was an aggregated contact list, that there's still no disclosure in ODEL that an aggregated list is stored. [00:08:47] Speaker 05: But all of these arguments you're making are based on your claim construction and not the board's claim construction. [00:08:53] Speaker 05: In order to appreciate or to adopt or consider the arguments you just made in the past two minutes would require a reversal of the board's claim construction, right? [00:09:06] Speaker 01: I just want to understand what you're arguing. [00:09:10] Speaker 01: Yes. [00:09:12] Speaker 01: Yes and no. [00:09:13] Speaker 01: So let me address that. [00:09:14] Speaker 01: What the board said with regard to aggregated contact list is that it is a contact list resulting from gathering and collecting contacts from multiple contact lists. [00:09:26] Speaker 01: So there, the board recognized that the aggregated contact list has to be a single list. [00:09:34] Speaker 01: However, the board then goes on to say that the aggregated contact list need not be a single or integrated list. [00:09:44] Speaker 01: So that alone, I think, is a reversible error in that, on the one hand, the board says the aggregated contact list has to be a list. [00:09:54] Speaker 01: Then a page or two later says it need not be a single list. [00:10:00] Speaker 02: That's important here because if... Well, I think the distinction they were trying to make was between bringing together two lists and integrating them into one. [00:10:13] Speaker 02: There's no requirement that the lists be integrated as long as they are aggregated, meaning brought together from different sources into one. [00:10:26] Speaker 01: Important to that point, though, is that the claims require an aggregated contact list. [00:10:32] Speaker 01: So a collection of lists is still not an aggregated contact list. [00:10:37] Speaker 02: But as the patent describes, the list can be broken into different folders. [00:10:43] Speaker 02: Correct. [00:10:43] Speaker 02: And it's still an aggregated list. [00:10:47] Speaker 02: Yes. [00:10:47] Speaker 02: So why is it that the aggregated list, why are you arguing that the proper claim construction is that the list has to be not only aggregated but integrated as a single list when, in fact, there's discussion of different folders, which [00:11:07] Speaker 02: is the opposite of a single integrated list. [00:11:10] Speaker 01: Well, organization within a single list is still just a single list. [00:11:15] Speaker 01: So how you move with regard to folders, how you move the contacts around within the list still is only a single list. [00:11:24] Speaker 01: So I think there the board missed the point with regard to the discussion of folders in the patents. [00:11:30] Speaker 01: What in the patent they're talking about is being able to organize within the single list. [00:11:37] Speaker 01: That doesn't imply that you could have multiple lists and still have a single aggregated contact list. [00:11:42] Speaker 01: And I see I'm into my rebuttal time already, but just briefly, there's also the concept of a network contact database in the claims. [00:11:53] Speaker 01: What the board pointed to there was Odell's account linking database, and there's no substantial evidence that supports that finding. [00:12:02] Speaker 01: What the account linking database stores is information about a buddy list. [00:12:08] Speaker 01: There's no disclosure that [00:12:09] Speaker 01: account linking database stores the user's buddy lists and that's that's confirmed with by the Odell's disclosure that talks about information about the users buddy lists includes account linking information the alias screen names that are linked and other linking attributes but no mention that the buddy lists are stored at the account linking database [00:12:38] Speaker 01: Quickly with regard to messaging service provider, the experts for both sides agreed that a messaging service provider could be a business or entity that provides a service. [00:12:53] Speaker 01: Here, the board conflates networks, messaging services, and messaging service providers, but those terms have different meanings. [00:13:02] Speaker 01: in the claims and the board officiates the separation of those terms when it defines the messaging service provider as the computer system platform for providing a messaging service. [00:13:19] Speaker 01: With that, I'll stop here. [00:13:23] Speaker 01: Thank you. [00:13:35] Speaker 00: Good morning, Your Honors, and may it please the Court. [00:13:37] Speaker 00: Peter Herz, on behalf of the United States Patent and Trademark Office. [00:13:41] Speaker 00: There have been a lot of issues raised here today, as well as in the brief. [00:13:45] Speaker 00: I'll try to get through them as quickly as I can, because it seems as if- Well, East, your friend, spent the bulk of his time talking about this first issue of abrogated contactless. [00:13:55] Speaker 05: So why don't you go to that? [00:13:56] Speaker 00: Well, I will start with that, since that seems to be the main issue in the case. [00:14:02] Speaker 00: The board gave that term its plain and ordinary meaning, aggregated, meaning gathered or collected, as has been discussed. [00:14:13] Speaker 00: My friend does not dispute that that's the plain and ordinary meaning of aggregated. [00:14:17] Speaker 00: Then the only question is, where do these contexts come from? [00:14:21] Speaker 00: And to your point, Judge Stoll, the claim is quite clear that what gets aggregated are [00:14:31] Speaker 00: The contact list themselves and claim one it says it maintains an aggregated contact list that comprises a first contact list Associated with the contact information from the first message service provider and a second contact list from the second message service provider so the claim itself indicates that it doesn't have to lose sight or memory of the sources of [00:14:58] Speaker 00: the contacts themselves and we see that both in the 395 patent where it has that separate column on the right hand side which indicates the source of the associated contact. [00:15:13] Speaker 00: I would also point out that, as Judge Prost noted, that figure 4A, which my friend relies on almost exclusively of the 395 patent, does not refer to that display, figure 4A. [00:15:30] Speaker 00: as an integrated contact list. [00:15:33] Speaker 00: It's referred to as a multi-network IAM display. [00:15:37] Speaker 00: So very little intrinsic evidence to support their proposed claim construction. [00:15:43] Speaker 00: And unfortunately, there's just very little discussion in the patent itself about how these claims are aggregated. [00:15:52] Speaker 00: And I point the court to column 6, lines 39 through 42, where [00:15:59] Speaker 00: It just says that the databases are accessed in such a way that a list of contacts stored in the network context database 312 is aggregated. [00:16:13] Speaker 00: There's very little, there's no discussion about it has to be integrated, it has to be formed into a single integrated list. [00:16:21] Speaker 00: And then it also goes on to say, and then it's displayed on the display. [00:16:25] Speaker 00: I think that's another important point that claims [00:16:29] Speaker 00: distinguished between the aggregation step and the display and those two in the board recognize that. [00:16:40] Speaker 00: As far as ODEL teaching an aggregated contact list, I think that falls with the claim construction. [00:16:47] Speaker 00: I don't think there's really any separate arguments there. [00:16:51] Speaker 00: So under the board's claim construction, I think there's clearly substantial evidence. [00:16:57] Speaker 00: Also, there is substantial evidence to support the board's finding that ODEL's servers 372 [00:17:07] Speaker 00: 378 store and maintain the contacts that's at Odell a PPX 2764 Column 7 lines 20 through 40 and as well as Willis is supporting testimony and [00:17:24] Speaker 00: As far as the network contact base, that too there's substantial evidence to support the board's finding. [00:17:33] Speaker 00: There are points to that same passage where literally Odell [00:17:40] Speaker 00: teaches, quote, that account linking server interacts with the account linking database 380, which stores and maintains BuddyList. [00:17:51] Speaker 00: It literally says exactly the opposite of what eBuddy argues here on appeal. [00:17:59] Speaker 00: That's at APPX 2764. [00:18:05] Speaker 00: Finally, with respect to the messaging service provider, another claim construction dispute, the problem here is that there's just literally no intrinsic support for this. [00:18:16] Speaker 00: This provider distinction was added by amendment. [00:18:20] Speaker 00: That term does not appear in the original specification. [00:18:24] Speaker 00: The patent itself is focused almost exclusively on the network infrastructure, and it says that these are [00:18:33] Speaker 00: separate and distinct messaging services that are provided over those individual networks and that's essentially the construction that the board gave that term. [00:18:45] Speaker 00: And I think I've hit all of the issues that were covered here today and I'm happy to take any questions from the panel. [00:18:53] Speaker 00: Thank you. [00:18:53] Speaker 00: Okay. [00:19:05] Speaker 01: So I think key to the, again, to the aggregated contact list is that a list has to be a list. [00:19:12] Speaker 01: It can't be multiple lists. [00:19:13] Speaker 01: But that's exactly what the board has told us that it can be, is that a list can be multiple lists. [00:19:20] Speaker 01: And that's just not the case with regard to the term aggregated. [00:19:26] Speaker 01: That does require that contacts from separate lists, including related to a first network or a second network, are brought together, but they still have to be brought together into the single aggregated contact list. [00:19:42] Speaker 01: If we're talking about storing and maintaining the aggregated contact list, [00:19:49] Speaker 01: What you won't find in Odell is any mention that the buddy lists are stored in the account linking server. [00:19:57] Speaker 01: And I believe my friend referred to Odell's specific language of Odell at column 7. [00:20:09] Speaker 01: And what that says is that the account linking database stores and maintains user buddy lists and account linking information. [00:20:17] Speaker 01: So there it's not talking about storing buddy lists, it's talking about storing buddy list information. [00:20:21] Speaker 01: And as I mentioned before, it provides examples of what that information is. [00:20:26] Speaker 01: And none of that describes the buddy lists themselves. [00:20:34] Speaker 01: With regard to messaging service provider, what the board has done is construe that term to encompass or overlap at least the networks and messaging services that are separately claimed in the 395 and the 453 patents. [00:20:54] Speaker 01: Messaging service provider is a distinct term and it should have a separate meaning from the other terms that are used and again the [00:21:04] Speaker 01: The experts agreed that a messaging service provider could be a business or an entity. [00:21:10] Speaker 01: Here the board is simply incorrect in its construction.