and and so the claim was being immediately compared to whatever was going on in the carmel disclosure without really defining with the right conception of the claim language was in so what i'm trying to figure  to what extent did you specify to the board you are operating under an assumption that the claim called for the new media data elements being sent to be a very requested media data elements that are specified by some kind of identifier i didn't quite see that kind of discussion come out in any of your papers you argue that very vigorously if you talk about i thought maybe maybe you'd be looking at six fifty or sixty one you might have other pages  the so the elements responsive to requests are the ones that are requested by serially then fire is that it is the elements that are requested by syria within a fire that all of them have to be sent faster and playback rate that was in the petition so our argument i'm sorry this was that was language for your claim construction position do i understand that correctly that we rely on the claim language yes we rely on the claim then which already obviously in light of the specification but we rely on the claim language for the construction that one says refers to said requests it is request for the elements by their serial by their serial are done fires those are the ones that have to be sat faster than the playback rate and that's and gist that's what they seek to blur on the other side that's what the board sought to blur the board did not focus as we we as we say that they had they had to according to the plain language on the elements that are requested by their the claim language could have written been written or even more clearly i mean it is a little squishy and the board is operating under the broadest resume or the interpretation of risk and so when it 's sending media data elements to the user response if you said the quest it it's a little on the vague side to understand what does that mean responsive to that request it could be as you say that it's precisely the very media data elements that were requested and specified by jennifer responsive to is also a little opaque and could be understood the clued in other data elements that come along with that precisely requested data elements and so i mean if the claimants caused the server to send the requested media data elements user system i mean that would be very clear but here we've got maybe a little bit of wiggle room and that's what i'm trying to understand well i would disagree i would say it's does say responsive to set requests which is referring to those specific of what's being sent what's being sent to the client the client is managing that process so that's the way that is poll so when you when you start to interpret claim ten were broadly than that then inscription yes we've not i guess wouldn't think that this claim would result in an operative device without it having talking about pulling each require each i'm sorry each data element as opposed to pulling multiple data elements at once for example well if the poll is going to work it's that if the client is now in charge of the client is now in charge of keeping its buffer at the proper level right then it has it's essential to that process that it knows that it's going to get the pieces of requests faster faster than the playback rate so this time this time between the pieces in order to in order to adjust otherwise otherwise it won't be able it just does no guarantee that is going to be able to keep up you know in order for this to work the pieces have to get there fast at the pieces that requests have to get there fast in the playback r client to be able to be in control that's the that's the assumption here and the spec is also clear about that that they're sent faster than the playback rate so you're really getting away from paul you're you're really inconsistent with poll when you start to read the claim that broadly and that's you know that's our that's our our it's our position on that and i think that in light of the spec it has to be understood that way because otherwise you're you're not you don't have a poll and body image that works is is the one that actually actually recites the negative limitation the server does not maintain a pointer into a buffer established within said server for each for each set user and to start streaming from that identifier if you're going to do that the server has to be able to keep track of the last element that is sent in order to know that in order to know the next element that is sent it has a pointer for that and that's what the expert testified and it's and it's unreal but it couldn't operate he said it couldn't operate without maintaining a pointer to the last element sent he stated that to support the function of the server would need to maintain a pointer substantial evidence standard review that we have here i understand you have you know a piece of evidence that for a declaration that you say suggests carmel has the server pointer but at the same time for found otherwise and then also found that there were carmella talks about all these client side controls and the board found and why wouldn't it be reasonable to find that there isn't a sort of a point that's needed and all the client side controls are taken care of this george chained to the board was that was an error in that finding completely in error in plain sight control that the board was referring to was the language in the specification about synchronization of playback yes the client needs to synchronize on its side after receives the elements needs to synchronize playback that has nothing to do with transmission from the server is misplaced it's misplaced reliance it's completely off completely off base and is not support the conclusion that th just simply an error on that this is not a pointer on the server side telling the server which element to send next this is on the client side telling telling the client playback device which piece to playback through the speaker was kind of to say the word in its decision and claim construction instead of talking about the claim language and the words used in the patent specification discussed the construction of the claim in the context of the prior art by using the terms links talking about singling symbol table links do you know why it is that the borg was talking about the prior to construe this claim normally he would look at the intrinsic evidence so i think it has to do with how the issue was presented to the board here we argued that multiple links it's the overall rate of item sent over multiple links that the claim element the had no to argue back could not meet the claim element and neither party had presented a claim construction so i think we're still does talk about it does provide a claim destruction right i mean it's in a section of the board's opinion titled claim construction correct and i think the board is certainly the prior art is is not how the claim should be interpreted does not teach on that that's correct but i think the what the border saying is that there is nothing in this claim language using the broadest reasonable interpretation standard that would preclude the multiple they could vote in and since that was the bot environment that they were trying to consider whether or not fell within the claim i think that they use that as context for discussing would you say that's kind of harmless error by the board because i mean the question really claim and then you were to look at does the prior it's a factual question right well and we would be looking at is there substantial evidence to support the conclusion that carmel teachers that claim limitation is properly interpreted well i think that i think ultimately the court construed the claims are correctly in that or by saying that it could be multiple links yes that it could be that rate is not limited to the rate over singl essentially the pad owner was asking the board to read in limitations and says that not the resolution of the factual issue of whether the prior teaches the claimed limitations so the board saw it as an implicit claim to destruction argument on the what the board set out to do the premise of the board's anticipation for me is that you look at you know all the data on this is sent over and carmel and and then figure out what the overall raised is rather than just looking at the rate of the actual requested data element and then transfer it over is that right i would say i would have a slight change that i think it was they said you looked at the rate of the overall data elements that's hard i agree with rather than look to only the data elements over a single way the board didn't have to address the entire issue of whether in addition to being elements sent over multiple lengths whether the claims further require that each of those also be requested by serial identif that's the issue that had never been raised below and so the board did not address that the one discussed during the argument before the board so it was discussed only after the board raised the issue itself so the entire argument before the board in the reply brief is this first argument of can be multiple links instead of one link and that argument really didn't depend on the serial identifier nor did it depend on the interpla address yes but no three yet and so this is the argument that had never come up this interplay between the two parts of the plane and this whole idea of whether each item is requested by serial identifier this came up for the first argument and it actually came up when the judge raised the issue and he asked the question the reason he asked the question is because there was a third disclosure we relied on that's not at issue here and that third disclosure involves resizing the media data elements to send them faster and the judge thought that resizing of those that might make them different media data elements so he raises this question about the interplay the last two was an argument that had never been raised and you agree though that at least what was earned in the pattern in your response was that the data rate refers to the rate for each slice in carmel correct they did argue the data rates each slice but now they're further  uing the data rate also has to be for each slice requested by serial identifier which is a further limitation on what they said before because the few to have already found you can have all these links  send a bunch of data elements over and that's sufficient to me that it doesn't matter that they're using multiple lanes now they're arguing it even if we accept what the few tab decided there that it can be the multiple lengths should then have to have an opportunity to argument this is not so one way or another well they've had the opportunity to argue against these disclosures of carmel from th and they've argued in the beginning that this disclosure is not met because it uses multiple links they could have at that time argue that each one also must be requested by serial identifiers so they've had agreed though that they didn't seek a construction that it was for us so in terms of the construction itself if we look at the last two clauses of the flames the second to last clause asked that we request one or more media data elements zero identifier that can be met by identifying one media data owned by serial identifier for example you request that send media data elements starting at eleven forty two you've met the first of those two request you've requested element forty two in following and then you now send element forty two forty three forty four and forty five those are responses to the requests they were not each separately requested by serial identifier but they do meet the  this is considered and the french narrow construction is determined to be the right one the limitation still met by the two disclosures we've relied upon in carmel and the board sort of implicitly notice when the board says it doesn't is the board the board has already decided that the rate could be the rate of achieved in the aggregate over multiple lists so then the question is if it's a bus also be each one requested by serial identifier does carmel in the multiple lin bottom and disclose requesting by ciro identifier are each one of those over the multiple length requested by zero identifier and here they are carmel uses the same t c p mechanism which will requests by zero identifier so set over that one is sent after playback but then we also starting on page twenty eight discussed this multiple ways and so we say it also describes faster in playback as a lag recovery mechanism and then on page twenty nine is where we set forth the substantial evidence to support the fact that each of these request is made by zero identifier i'm sorry were you on page twenty nine sure so  you and so this is so there is first the evidence is the fact that the clients are the ones initiating these requests just like in the patent system karmel at column ten very clearly describes a system where the client is monitoring the so what we have is clients making requests using t c p that's the exact same disclosure that's in the one for one path clients making requests using t c p we have x substantial evidence we have expert testimony that  two separate disclosures first carmel says that you should use a transmission rate that's generally equal to or faster than playback that's over all over all the disclosure is this general then on the for the multiple links embodiment that's used to recover from a live scenario so you've fallen behind real time in playback and you now have to recover and build up the buffer so to recover you have to send media data elements faster than the play requesting faster playback that said carmel discloses the same underlying system that their patent supposes so that any narrow reading of these plans is still going to be met by carmel because carmel is in column ten carmel describes a client side request and it says explicitly the time stamps are used to have it monitor the pace of information coming in and if necessary open more links so karmel is a system that uses pi inside requests just like the one for one patent it explicitly says it's going to send media faster than playback and disposes ways to do that the server so there's a server in between uploading computer and the downloading people in order to determine the amount of time required to convey place and a verify that the slices are conveyed at a sufficient rate when the data stream comprises multimedia data the data rate should be generally equal to or faster than the rate at which data is generated transmitted so and here it's discussing two sides of the system disk it's in figure two there's an upload in computer that's recording video and uploading it to the server and then there's a client computer thirty that's downloading from the server and throughout this patent it describes those two processes at the end and it says you can use that to change from one process to the other but what it's saying is it's those two machines on the two sides that are monitoring the the rate but generally the goal is to have a rate that is equal to or faster than the rate at which data are generated so that's i know that that data rate is the rate for each individual slice and how do i know that that's not referring to the bandwidth and having multiple slices of data center lines how do i know that i mean i think this is kind of a general description here and so i'm wondering exactly so there's not other than we know that carmel starts by opening away and only was open additional links should it fall behind in playback so the disclosure suggests that we have one length it should be generally equal to or faster if it's if it becomes slower we will then open multiple lines that's that's a secondary mechanism if the primary backers and is not doing the job  address first of all he's multiple links the petition didn't mention multiple links but it did not make any arguments about aggregating the rate the rate over multiple links an oral argument having to address i mean to address that aspect for the first time which then raises the issues about individual pieces it brings it brings out the brings out on that and has nothing in the petition about aggregating the ra over over multiple links there was also nothing in the petition trying to make an argument that that the limitation about requesting slices by their id was satisfied by t c p there's nothing in the station about that  completely off base t c p is a low level protocol that concerns requesting bytes not media data elements it's totally off base it wasn't just known just don't foundation for it in the record satisfying this limitation not the basis of the board's decision it's really a red herring the i also note that my you know my my adversary has didn't say anything to address claim fifteen where we say that our position is that the board was just off base in finding that there were client site control mechanisms that moderated that moderated the to the transmission make moderate opening opening opening individual links but either t c p has requests for bytes at a low level it's not needed it's not media data elements so there's really there's really nothing they have really nothing on claim fifteen word was wrong on it's on its characterization of client side process are internal to the client not not concerning communication concerning communication with the server so i think that's the i think that they're pretty much sums up unless