[00:00:00] Speaker 04: Your argument is 23-2312 Finto v. PayPal. [00:00:06] Speaker 04: Ms. [00:00:06] Speaker 04: Addy, whenever you're ready. [00:00:09] Speaker 04: Good morning. [00:00:09] Speaker 04: Please proceed. [00:00:10] Speaker 05: Good morning, Your Honors. [00:00:13] Speaker 05: This claim construction case where the court improperly applied 112.6 to a limitation that does not include the term means is bound with structure and for which PayPal did not overcome the presumption requires reversal. [00:00:29] Speaker 05: However, even if 112.6 is applied, the court also ignored the structure found in the claims and the specification, and for that reason as well, the case should be reversed. [00:00:42] Speaker 04: So talk to us about, you start off by saying, well, we've established, and I don't think you dispute, that you don't need the word needs. [00:00:49] Speaker 04: There might be a presumption, but need, that doesn't get you to where you need to go. [00:00:54] Speaker 04: So your second point was it is bound by structure. [00:00:58] Speaker 04: Can you tell me what that means when you look at the words of the claim? [00:01:02] Speaker 04: Yes, Your Honor. [00:01:04] Speaker 05: The claim is a payment handler that exposes a common OPI for interacting with different payment processors. [00:01:13] Speaker 05: And even looking at this claim term through a lens of means plus function, [00:01:19] Speaker 05: the function would occur after the four, and that would be interacting with different payment processors. [00:01:26] Speaker 05: Hence, looking at the language before the four, as a whole, which you have to do, payment handler that exposes a common API. [00:01:36] Speaker 05: and that contains definite structure and cannot be substituted with the term means. [00:01:43] Speaker 05: Your Honor, 112.6 requires that the claim, if it's in means plus function form, has to be devoid of, quote, the recital of structure, material, or acts. [00:01:56] Speaker 04: And if it's in means plus structure. [00:01:58] Speaker 04: I mean, and I think this comes from the red brief, but in [00:02:03] Speaker 04: The 386 patent, the claim says the payment handler service operable to use APIs. [00:02:10] Speaker 04: And 413, it says payment handler configured to use APIs. [00:02:16] Speaker 04: And then the 196, which is the one I think you referred to, a payment handler that exposes. [00:02:23] Speaker 04: Aren't those phrases fairly construed as being entirely functional? [00:02:29] Speaker 05: You and I, I think that's incorrect for two reasons. [00:02:32] Speaker 05: I'll start with the 488 and the 196, which is the one I just quoted before, and then I'll go back to the other two. [00:02:40] Speaker 05: Yes, Your Honor. [00:02:41] Speaker 02: I don't remember, did you either in this court or below argue that there was a difference among these several claims with respect to what constitutes the function [00:02:55] Speaker 02: We argue that, because here I think you're putting the that-exposes APIs on the before-you-get-to-function side of the line. [00:03:03] Speaker 02: Some of the other language doesn't, isn't amenable quite to that point where the API reference is clearly on the for side. [00:03:14] Speaker 02: And I don't remember you're making a distinction among these claims. [00:03:18] Speaker 05: We didn't make a big distinction because we said that you could have interacting with different payment processors as a functional language, or you could have operable to use different payment processors. [00:03:32] Speaker 05: And the way we get to that is if you look at the 386 claim [00:03:37] Speaker 05: The limitation is payment handler service, operable to use, APIs of different payment processors including one or more APIs of banks, credit and debit card processors, and bill payment processors. [00:03:51] Speaker 05: That's a lot of structure. [00:03:52] Speaker 05: And so we were trying to make these claim limitations consistent, and we said, all right, operable to interact with different payment processors, at least that is what, in general terms, we're getting at. [00:04:06] Speaker 05: But when you're looking at this claim 386, claim 1, [00:04:10] Speaker 05: There's really no functional language there that would support means plus function because there's no four, number one. [00:04:18] Speaker 05: And number two, operable to use APIs of different payment processors includes all kinds of function. [00:04:24] Speaker 05: It describes that function as banks and credit cards and that structure, I'm sorry, Your Honor, as banks and credit cards and processors. [00:04:32] Speaker 05: Why isn't that functional? [00:04:34] Speaker 05: It is functional, but it's not functional in the way that the statute defines means plus function. [00:04:40] Speaker 05: And in fact, Your Honor, it's entirely appropriate for the structure that satisfies a means plus function to be functional. [00:04:48] Speaker 05: In fact, in the Apex Court, an Apex case, you said that the fact that the court, the fact that a particular claim term may be defined in functional terms is not sufficient to convert the term [00:05:00] Speaker 05: into a means for performing. [00:05:03] Speaker 05: And such is the case here where the parties don't dispute that API discloses structure. [00:05:11] Speaker 05: There's no dispute there on the parties. [00:05:13] Speaker 05: It was known and both experts agree. [00:05:16] Speaker 05: Also, there are several cases from this court that say that API discloses structure. [00:05:20] Speaker 05: So at least, going back to your first question, at least [00:05:26] Speaker 05: Under the payment handler that exposes a common API, all of that is structure, because the parties agree that a common API is structure. [00:05:36] Speaker 05: And once you get all that structure, you are forbidden to use means plus function. [00:05:40] Speaker 05: I'm sorry, you said the parties agree to what? [00:05:43] Speaker 05: They agree that an API connotes structure. [00:05:46] Speaker 05: An API is a known application interface. [00:05:49] Speaker 01: So agreeing that there's sufficient structure for API is not an agreement that there's structure for payment handler, correct? [00:05:56] Speaker 05: Correct. [00:05:57] Speaker 05: But you can't excise certain claim terms out of the claim limitation and look at them in a vacuum. [00:06:02] Speaker 01: But you acknowledge you also need structure for full payment handler, do you not? [00:06:08] Speaker 01: I believe we do have structure for payment handler. [00:06:11] Speaker 01: And you need to, correct? [00:06:14] Speaker 05: I don't know that I want to go as far and say as we need to, because I think once you have any structure in the language that would be substituted for means under a statute, I think that kicks you out of means. [00:06:24] Speaker 05: But we absolutely do have structure for handler, Your Honor, too. [00:06:29] Speaker 05: And the court, in order to reach this means plus function conclusion, it had to excise this term handler out of the claim as a whole and look at it as a vacuum, which is improper under Dyson. [00:06:42] Speaker 05: However, looking at Handler in a vacuum, it still discloses sufficient structure to overcome 112.6 because, for example, PayPal's own dictionaries [00:06:52] Speaker 05: show that the structure of handler alone was known to want a skill in the art. [00:06:58] Speaker 05: Those dictionaries are repeated in our blue brief at 22, but just looking at one of them, for example, they cite the dictionary of computing for handler. [00:07:07] Speaker 05: And in that dictionary, it says a handler is a part of an operating system software or special software routine which controls a device or function. [00:07:18] Speaker 05: The example they give is a scanner handler. [00:07:22] Speaker 05: So a scanner handler, or a handler, is something that, at least these dictionaries show, one of ordinary still in the art recognized as a term in the industry, and not something that's not functional at all. [00:07:36] Speaker 04: It's clear where accepting your statement is correct gets you to where you need to go. [00:07:41] Speaker 04: Is there any evidence in this record that any of the handlers in the prior art performed this claim function? [00:07:49] Speaker 04: Isn't that the right question we should ask? [00:07:52] Speaker 05: No, Your Honor, but I don't think that's quite the right question. [00:07:55] Speaker 05: I think you have to say, okay, is this payment handler something that was known in the art? [00:08:03] Speaker 05: But to answer your question, I think I can answer your question in the positive. [00:08:06] Speaker 05: Yes, Your Honor. [00:08:08] Speaker 05: PayPal also cited the IOTP standard. [00:08:11] Speaker 05: And the court strangely disregarded the IRTP standard, but that standard shows that one of scale would understand what a payment handler is. [00:08:22] Speaker 05: And the district court recognized that the IRTP standard referred to many different entities [00:08:32] Speaker 05: in the payment system with different structures. [00:08:35] Speaker 05: But he said that wasn't enough. [00:08:37] Speaker 05: But that's not the law. [00:08:38] Speaker 05: In Dyson, if you're referring to a class of structures, as the IOTP standard is here, that is enough to connote that one of Ornée's still in the art would understand what a payment handler is. [00:08:51] Speaker 01: Dyson, do you mean Dyson? [00:08:53] Speaker 01: I'm sorry, Dyson. [00:08:54] Speaker 01: Can I ask you, because the red brief suggests that you're trying to get us to expand Dyson [00:09:01] Speaker 01: so far that it would, in their words, eviscerate 112.6 by allowing any genetic reference to software code to supply sufficient structure for performing a function. [00:09:12] Speaker 01: Isn't that what you're inviting us to do here? [00:09:15] Speaker 05: No, Your Honor. [00:09:16] Speaker 05: No, Your Honor, because as the parties agree, both the API is known structure. [00:09:29] Speaker 05: So there's structure in the claim before the floor on the mean side. [00:09:32] Speaker 05: And because the handler, or the payment handler, is known structure, because even though they dispute it, they put in a dictionary and they put in a standard, both of these things show that one of skill and the art would know absolutely what a payment handler is. [00:09:48] Speaker 05: In fact, the standard references payment handler over 180 times. [00:09:54] Speaker 02: Can I just use the handler definition? [00:09:59] Speaker 02: Does it define handler as a software routine or a piece of hardware? [00:10:06] Speaker 02: Here, in this context, handler is a software routine, Your Honor. [00:10:12] Speaker 02: And have we said that, you know, [00:10:15] Speaker 02: some expression like a software routine is or is not 1.6 triggering? [00:10:25] Speaker 05: Yes, we have, Your Honor. [00:10:26] Speaker 05: I think in the APEX case that I need to take a quick look. [00:10:42] Speaker 05: Well, then, in DIFAN case, we also said that code, or configure to, does not automatically invoke 112.6 when there's a known class of structure. [00:10:52] Speaker 05: So I go back to DIFAN to say that here, as shown in the standard, there's a known class of structures, and those structures would satisfy this quick DIFAN. [00:11:04] Speaker 04: But in DIFAN, there was, as I recall, unrebutted expert testimony the person skilled in the art would have understood. [00:11:12] Speaker 04: the terms as a particular structure and the availability of off-the-shelf code to perform the recited functions. [00:11:22] Speaker 04: There is no such unrebutted testimony here, correct? [00:11:26] Speaker 05: Your Honor, that's right, Dr. Chatterjee did say that one would not, one of Spiel would not know what a payment handler was. [00:11:32] Speaker 05: However, there was the other evidence, and of course our experts said that one of Spiel and I would know, and you have to consider this claim term in the context of the rest of the claim. [00:11:43] Speaker 05: So, in the rest of the claim language. [00:11:46] Speaker 05: So, number one, [00:11:50] Speaker 02: Did you suggest in the district court or hear that what you just summarized, which might be characterized as a factual dispute, is not for the district judge to resolve? [00:12:05] Speaker 02: I'm sorry. [00:12:06] Speaker 02: You just said Dr. Chatterjee said one thing. [00:12:10] Speaker 02: Your expert said the other thing. [00:12:12] Speaker 02: So I think, oh, factual dispute. [00:12:15] Speaker 02: And now I want to know who is supposed to decide that. [00:12:18] Speaker 02: And what did you argue about who is supposed to decide that? [00:12:22] Speaker 05: To answer your second question first, we focused our arguments on the fact that this was not a 112-6. [00:12:29] Speaker 05: And I'm not sure that we reached the question of who would decide whether that's a fact. [00:12:36] Speaker 02: It feels like that portion of claim construction that is factual, nevertheless, not for the jury, but for the judge as fact-finder. [00:12:46] Speaker 05: So I thought that was an interesting question as well because when you get down to [00:12:56] Speaker 05: when you get down to written description rather than claim construction. [00:13:00] Speaker 05: So if you're in claim construction, I can see, yes, it's a legal question with underlying factual disputes. [00:13:06] Speaker 05: And when you get into written description, then we're dealing with a higher burden to prove invalidity. [00:13:13] Speaker 05: And it seems to me that it could also be a summary judgment decision. [00:13:18] Speaker 05: And if they're disputing experts at that point, I'm not sure that that is appropriate to resolve in summary judgment. [00:13:26] Speaker 05: in validity type of analysis, not a claim construction analysis. [00:13:31] Speaker 01: But here you've not argued that this question should have gone to a jury. [00:13:37] Speaker ?: No. [00:13:37] Speaker 01: Can I just follow up? [00:13:39] Speaker 01: Judge Shirano's, I think, very first question to you was essentially, as I understand it, [00:13:43] Speaker 01: Do we have one claim construction dispute in front of us, or do we have possibly two, three, or four? [00:13:48] Speaker 01: You can see it's just one dispute. [00:13:49] Speaker 01: All these claims rise and fall together on this record. [00:13:52] Speaker 05: I think they do rise and fall together, but I want to, and I don't, I feel like I didn't answer Judge Post's question on the facts, which is, yes, the DieFan had undisputed expert facts, but here we have our expert, their dictionary, the IOTP standard, and the only outlier is their expert. [00:14:12] Speaker 05: So to answer your question, I want to also just take a look real quickly, and I'm in my unknown in my rebuttal. [00:14:20] Speaker 05: So the 386, actually I think we covered this, so I'll reserve the rest of my time. [00:14:27] Speaker 05: And thank you. [00:14:29] Speaker 05: Thank you. [00:14:36] Speaker 04: Good morning. [00:14:37] Speaker 04: Good morning, Ashley. [00:14:39] Speaker 03: May I please the court? [00:14:41] Speaker 03: Now, before I get into the actual evidence that the district court relied on, the extrinsic evidence from PayPal's expert that's reviewed for clear error, I did want to take a step back and look at all of Fintiv's purported structure. [00:14:56] Speaker 03: You've heard Fintiv's counsel say that these terms are bound by structure. [00:15:00] Speaker ?: And there's simply a complete lack of evidence supporting any of Fintiv's attempts to articulate the structure. [00:15:07] Speaker ?: Now just in the briefing before this core, there are four different types of structures that Fintive argues. [00:15:15] Speaker 03: At the opening brief in page 24, they say it's part of an operating system or specialized software routines which controls the device or function. [00:15:24] Speaker 03: Then four pages later, they say it's a narrower construct based on specific structures such as API and code wrapping for such APIs. [00:15:33] Speaker 03: Then one page later in the opening brief at page 29, they say the IOTP protocols define the term payment handler as a physical entity, which obviously doesn't convey any specific structure. [00:15:46] Speaker 03: And then they qualify in their reply that the physical entity has certain structures, such as an HTTP server. [00:15:52] Speaker 03: And that's at their reply at page 17. [00:15:55] Speaker 02: I just want to interrupt. [00:15:56] Speaker 02: So I guess I'm a little bit sympathetic to the [00:16:01] Speaker 02: displayed effort to try to figure out how to think about this claim language or the various versions of the claim language at issue, where there is an assertion that not a single word, like device or module or is a nonce word, but a two-word phrase [00:16:29] Speaker 02: Which has a kind of functional term inside it, but your contention is not that this is Handler for payment your contention is that payment handler as a two-word expression is a 126 triggering word like means And I guess one of my questions is [00:16:55] Speaker 02: Can you point to precedent where we have applied 112.6, where it wasn't a single term but a two-word phrase that was being asserted to be the nonce expression? [00:17:12] Speaker 03: I believe the closest that comes to mind might be media rights with the copyright compliance mechanism, where they looked at, obviously they looked at mechanism as a non-sphrase, but then they looked at copyright compliance and if it added anything to that mechanism, and they said that this was purely a functional term, that it talked about what the mechanism does, but not how it does it, and that's the one that comes to mind to answer your question, Your Honor. [00:17:39] Speaker 02: I guess it seems like there's a potential here for significantly expanding the reach of 112.6 in the computer field by looking at a phrase that [00:18:00] Speaker 02: would not strike an ordinary reader as a pure placeholder word. [00:18:09] Speaker 02: And now, if not two words, maybe three, four, maybe a whole phrase is now going to be analyzed under 112.6. [00:18:19] Speaker 03: Your Honor, I don't think there's a risk of that. [00:18:21] Speaker 03: What Dr. Trotterjee looked at, PayPal's expert, was that whether the term payment handler connotes a structure to a person's ordinary skill. [00:18:28] Speaker 03: And to do that, he looked at definitions for the term handler. [00:18:32] Speaker 03: He found that it was just basically any kind of software. [00:18:35] Speaker 03: And then he looked at whether the term payment added anything to it. [00:18:38] Speaker 02: Well, not any kind of software. [00:18:40] Speaker 02: I mean, the definition is any kind of software that controls something else. [00:18:45] Speaker 03: Right, a device or a specific function, right? [00:18:48] Speaker 03: And so that really mirrors the language. [00:18:50] Speaker 02: Your argument has not been that handler is a nonce word, payment is a function. [00:18:56] Speaker 02: I assume your argument is not bad because you probably can't find specification structure for payment. [00:19:08] Speaker 03: In these patents, in particular, there are five lines of specification that talk about the payment handler and they mirror the claims. [00:19:16] Speaker 03: Respectively, I don't think there is anything in the specification that talks about the only different payment method. [00:19:23] Speaker 02: You have not made your 112-6 argument in the form. [00:19:28] Speaker 02: Handler is an ounce word. [00:19:30] Speaker 02: The function is payment. [00:19:33] Speaker 02: Maybe it's payment plus other things, but you haven't put payment as a function and then looked for specification structure to perform the payment. [00:19:41] Speaker 03: These functions that we looked at were the ones that were resided in the claim. [00:19:45] Speaker 03: And as Judge Prost mentioned, there were two separate sets of functions. [00:19:49] Speaker 03: There's the 386-413, which is to use APIs of different payment processors. [00:19:55] Speaker 03: And then the other, the other exposure. [00:19:58] Speaker 03: And so those are the functions that we looked at. [00:20:01] Speaker 03: to kind of change the function to kind of unify these two sets of claims. [00:20:06] Speaker 03: And again, that's specifically prohibited under Lockheed Martin versus Space Systems Laurel 324 F3D 1308 F1319. [00:20:17] Speaker 03: The means first function claim must be construed to include the limitations contained in the claim language. [00:20:22] Speaker 03: And so I'm not sure if that answers your question, but we were looking specifically [00:20:28] Speaker 03: Dr. Traveje looked at whether payment added anything to the term handler. [00:20:32] Speaker 03: Handler was just a generic kind of software that controls a device or function, very similar to the language in Williamson, where the module was a generic description of hardware or software that performs a specified function. [00:20:47] Speaker 03: And so Dr. Traveje's opinion was that payment doesn't add anything, and that there was no structure tied to the two claimed functions recited in the two sets of claims. [00:20:57] Speaker 01: Is that really the right way to go about this analysis? [00:21:00] Speaker 01: The challenge term as I understand it is payment handler. [00:21:04] Speaker 01: Correct. [00:21:05] Speaker 01: So I'm concerned about, and I think the district court did the same thing, looking at handler. [00:21:11] Speaker 01: Deciding is that simply just a nonce word essentially? [00:21:14] Speaker 01: And then asking separately does payment change things shouldn't the analysis be? [00:21:21] Speaker 01: Let's look at payment handler. [00:21:23] Speaker 01: What would want to skill in the art know about payment handler? [00:21:26] Speaker 01: Perhaps it's a term for a class of structures. [00:21:29] Speaker 01: Perhaps it isn't So shouldn't that have been the reason? [00:21:32] Speaker 01: right form of analysis. [00:21:34] Speaker 03: I believe both the experts did look at the term payment handler in totality, as well as in part of or into its constituent parts. [00:21:42] Speaker 03: Dr. Tralogy looked at the term payment handler, said that this does not connote structure to a person of ordinary skill. [00:21:48] Speaker 03: And he looked at the specification and gave concrete reasons why, specifically that he doesn't know from these two different sets of claims to which entity the common API is exposed. [00:22:00] Speaker 03: Then, Mr. Johnson, Fintech's expert, they looked for definitions for payment handler within the prior art and within the extrinsic evidence. [00:22:10] Speaker 03: And they came up with the single reference, the RFC, that was a supplement to the IOTP specification. [00:22:16] Speaker 03: And the only thing he could say is, circularly, this document uses the term payment handler, and they didn't define it. [00:22:23] Speaker 03: So it must be so well known that it has a definition. [00:22:27] Speaker 03: And that was the extent of his opinion. [00:22:28] Speaker 03: And so these parties did look at the term payment handler as a whole, and they came up with nothing. [00:22:33] Speaker 03: There was no evidence, either in the intrinsic record or the extrinsic record, that supports [00:22:39] Speaker 03: that there is any type of known structure. [00:22:42] Speaker 01: Is it your view then that the law allows either of those two analytical approaches, either look at payment handler as its own singular term, [00:22:51] Speaker 01: or alternatively break it down into payment and handle it. [00:22:55] Speaker 01: I'm hearing you say your expert did both. [00:22:58] Speaker 01: I suppose you'd say the district court did both. [00:23:01] Speaker 01: Are both proper analyses under the law? [00:23:05] Speaker 03: I believe they are. [00:23:06] Speaker 03: They're both. [00:23:08] Speaker 03: Each one of these cases, as [00:23:12] Speaker 03: As this court said in WSOU 1, the Westlaw 621607 at 5, all of these cases, or the determination on whether 112.6 applies is contextually dependent on the patents and claims at issue. [00:23:30] Speaker 03: And so you might have, I'm not sure that there's a case that on the way that places [00:23:35] Speaker 03: one test over the other, but both tests are accepted methods of determining whether 112.6 applies. [00:23:45] Speaker 02: Can you remind me, what is your position on the IOTP 1.0 definition of payment handler, appendix 2829? [00:23:56] Speaker 02: Payment handler, the entity that physically receives the payment from the consumer on behalf of the merchant. [00:24:03] Speaker 03: Right, and so the IOTP is an internet trading specification, and it defines different functional roles. [00:24:10] Speaker 03: And so these trading roles, that's at 28, I'm sorry, appendix 2828, you have the customer, merchant, payment handler, delivery handler, and customer care provider. [00:24:21] Speaker 03: And these are the functional roles that are in this protocol. [00:24:25] Speaker 03: And an individual can, or an individual organization can take on multiple different roles. [00:24:29] Speaker 03: So again, these are functional roles, they're not actual specific [00:24:33] Speaker 03: devices or structures. [00:24:36] Speaker 03: The IOTP does say that they can be represented by HTTP servers, which is [00:24:44] Speaker 03: completely untethered from the structure that FinCIF now advances with their quote-unquote API structure. [00:24:52] Speaker 03: And so when we looked at this, we also took a look at what the payment processor does or the payment handler does in the IOTP, and it's a payment processor. [00:25:01] Speaker 03: It's what handlers do you have, do you have Visa, do you have MasterCard? [00:25:04] Speaker 03: It's the entity that physically accepts payment from the consumer. [00:25:08] Speaker 03: And so this is supportive of the idea that payment handling doesn't have a well-accepted meaning. [00:25:13] Speaker 03: It's referring in the IOTP to a completely different entity in the fintive system. [00:25:25] Speaker 01: The district court didn't find any waiver of the positions that are being argued here, and you're not asking us to find that. [00:25:31] Speaker 01: Is that right? [00:25:32] Speaker 03: Well, there were positions that were raised for the first time on appeal, so the district court wasn't able to assess that at all. [00:25:38] Speaker 01: So, okay. [00:25:39] Speaker 01: Maybe I need to break it down. [00:25:40] Speaker 01: There were some positions that were raised only after claim construction and a motion for reconsideration. [00:25:45] Speaker 01: Is that right? [00:25:45] Speaker 01: Correct. [00:25:46] Speaker 01: Are you arguing that those are untimely and we shouldn't even reach them? [00:25:50] Speaker 03: I think the rate of issues on those is less important than those two-step algorithm that's raised in these briefs alone. [00:25:58] Speaker ?: And we do believe those are waived. [00:25:59] Speaker 03: If you look at vintage reply brief where they discuss waiving, they never actually address this two-step algorithm head-up. [00:26:07] Speaker 01: So the two-step algorithm, you say, is new to us. [00:26:10] Speaker 01: It wasn't presented at any point to the district court. [00:26:12] Speaker 01: Correct. [00:26:17] Speaker 03: And your honor, with my remaining time, I'd like to talk about the Die-Fan case that Fintech relies on so heavily now. [00:26:27] Speaker 03: As you pointed out, the difference in Die-Fan was the unrebutted expert testimony that [00:26:34] Speaker 03: the term application would be commonly understood to mean a computer program to provide some service to some user, and that developers at the relevant time could have selected off-the-shelf software to perform services and functions. [00:26:48] Speaker 03: And so there's no evidence like that in this record with respect to the payment handler term. [00:26:54] Speaker 03: There's no off-the-shelf or conventional software. [00:26:57] Speaker 03: And this court made sure to articulate the same two judges' lawyer install [00:27:02] Speaker 03: in WSOU2, that's 6-2023 Westlaw 653-1525 at 5, that this distinction is significant and, in fact, critical. [00:27:15] Speaker 03: There, they said, they were looking at the term processor, and they said that, I'm sorry, yes. [00:27:23] Speaker 03: They say, looking beyond processors, a baritone is precisely what the district clerk did here, but there was no conventional code, like in DIFAN and ZeroClick, that could be identified as constituting a collaborative application management processor, and no expert testimony, like in DIFAN, supporting a structural understanding of processor in the context of the claim. [00:27:46] Speaker 03: And so, really, there's nothing in this record that would [00:27:52] Speaker 03: allow you to invoke the DIFF and really compel the same result as in DIFF on the record is completely devoid of testimony that there is off-the-shelf or conventional payment handler software, much less any that uses APIs of different banks or payment processors or exposes a common API. [00:28:12] Speaker 01: Your expert gave certain opinions about figures 20 to 22, I forget which specific patent they were referring to, but providing evidence and structure. [00:28:22] Speaker 01: And they suggest your expert did not respond to that. [00:28:25] Speaker 01: If your expert didn't respond, could you tell me where I would find that? [00:28:29] Speaker 03: The Dr. Chatterjee did not address those figures. [00:28:35] Speaker 03: None of those figures, however, even mention an API at all. [00:28:39] Speaker 03: They show data flows between various components of the system. [00:28:44] Speaker 03: One component, the business process services, talks to the payment handler. [00:28:48] Speaker 03: But there is absolutely nothing about using APIs of different banks or exposing a common API. [00:28:54] Speaker 03: And under eGenera, the idea is not that, or the test is not that, [00:28:59] Speaker 03: some structure at all. [00:29:01] Speaker 03: The structure must be linked and sufficient to show the claimed function, and we don't believe that expert testimony was necessary to address those data flows. [00:29:10] Speaker 01: Is it your view that that structure in those figures goes to APIs but not to the use of APIs with a payment handler? [00:29:18] Speaker 03: There's nothing in those figures that mentions APIs at all, so I don't think [00:29:24] Speaker 04: And the figures just show, am I looking at the right figures? [00:29:27] Speaker 04: 84 and 85 of the appendix where it just shows where the payment handler is. [00:29:32] Speaker 04: Figures 21 and 22A, 21I and 22AA. [00:29:39] Speaker 04: These are data flow diagrams and so they're really just showing what is talking to the payment handler and, you know, [00:29:49] Speaker 03: That's about it. [00:29:49] Speaker 03: That business process and services sends commands to the payment handler without any discussion of how the payment handler works or APIs. [00:30:02] Speaker 04: Thank you. [00:30:04] Speaker 04: Thank you, Your Honor. [00:30:10] Speaker 04: We're restored two minutes. [00:30:16] Speaker 05: I think I have three rebuttal or four rebuttal points that will be quick. [00:30:20] Speaker 05: First of all, counsel started his argument by talking about the different structure that we provided in our brief and trying to say that that was somehow wrong. [00:30:31] Speaker 05: But there's a difference [00:30:33] Speaker 05: between providing evidence of structure that pulls the claim out of a means plus function term, because it's known in the art what it is, and that's what we're providing in our brief, and defining the structure under a means plus function rubric. [00:30:50] Speaker 05: So based on that, I believe you asked, Council said that we had waived our [00:31:01] Speaker 05: definition of structure using the algorithm, which is part of what we argue on appeal. [00:31:06] Speaker 05: And I just wanted to point out that we didn't waive that. [00:31:09] Speaker 05: In fact, we argued the algorithm previously in our claim construction brief at appendix 2483. [00:31:16] Speaker 05: While again, we focused that this is not means plus function, we said if it is means plus function, it could be an algorithm. [00:31:23] Speaker 05: And we also cited to the specific specification [00:31:27] Speaker 05: area that we cite to support the structure in our Means Plus Function Analysis here. [00:31:34] Speaker 05: Finally, you raised the question, Judge Stark, on the figures, and I would direct you to Figure 20C, for example, at Appendix 71. [00:31:45] Speaker 05: Figure 20C shows the process flows, for example, for deposit transaction. [00:31:50] Speaker 05: And because of the structure, if you define it structurally so that it's not in means, or if you define it in means so that you pull the structure from the spec, because the payment handler wraps, which translates APIs from various external payment processors, [00:32:09] Speaker 05: And because the payment handler exposes a common API to the monetary transaction system, those are the two-step algorithm. [00:32:17] Speaker 05: That allows the payment transaction system to do what's shown in Figure 20C, which is to hold funds from an agent balance and to load funds from a subscriber account. [00:32:28] Speaker 05: This case, Your Honor, is like Apple v. Motorola, where the claim language... Is there any reference to APIs in Figure 20C? [00:32:35] Speaker 05: Not a secret 20C, but the API would be software that is in the payment handler. [00:32:41] Speaker 05: So this is like Apple v. Motorola, where the claim language and the specification describes the handler's operations within the context of the invention, including inputs, outputs, and how certain outputs are achieved. [00:32:55] Speaker 05: This case should be reversed. [00:32:57] Speaker 05: It's not 112-6, and even if it is, there's sufficient structure in the spec such that it does not show a written description. [00:33:05] Speaker 05: Thank you, Your Honors. [00:33:06] Speaker 05: Thank you. [00:33:06] Speaker 05: We thank both sides, and the case is submitted.