on this appeal we're talking about really what's a push in body image where the servers and control of what's being sent to the clients and now the server has to control the process of sending to the client  at an at a great enough speed to be able to maintain the playback without without dropping so you need to do two things you need to get a fast start up so it claims describe an initial trend the claim one or the overflowing or under flowing having the current client run dry of material to play back and whereas in the in the in the pattern we discussed in the prior appeal the client said client was in charge of telling the server when it needed more information might offer is getting low send me another piece on this side it's up to the server to figure that out so that's that's that's the difference a server model moderated and the other the other patent the other environment was was was client moderated so the issue on this appeal concerns motivation to combine there are two obviousness combinations  erratic delivery of data packets over a network such as the internet chris your the whole premise of these of these patents and is that you've got a transmission channel that's faulty and they have to find some way to get a smooth transmission over a faulty channel because if you didn't have a faulty channel you wouldn't need either of these inventions you would just take the data as it comes in and send it send it by pipe down the title and everybody would be happy there would be no problems the reason for chen and the present invention is it doesn't work that way you've got to do something to overcome the vagaries of the transmission channel that's that's the setting here and that's that's really the only motivation is going to look back to what it is they're trying to do with these with these with this technology only chen chen only deals here secures a key point shane only deals with streaming pre recorded program which differs from a live claims the claims are the claims involved in this appeal involve transmission from a live feed and chat and you're streaming a pretty recorded program and in these claims you have a live feed the difference is that when you have a pre of program the server can reach back into the program get anything it wants out of that data to send it down line in a little live feed all you get is what's arrived already you can't you can't look forward in time you can't say what's going to come you know three seconds from now because we're we're not there yet and that's a fundamental difference between live and prerecorded so what happened in this case is that they use  medium that was native to chen the problem here is that chen was never designed to handle a life feed to begin with and it corporates many operations that presume possession of the entire recorded program uncontroverted and i did not get that from well this is turning argument but there's no there's no competent evidence there's no no there's no expert that said otherwise our experts said that would happen there's nobody who came in and said otherwise there's a lot of attorney argument there's a lot of concludes conclusions by the board to this fact but there's no there's no evidence some of the things the board suggests is that it's ok there might be some disruption there might be some lank it might not be perfect broadcast but also have live broadcast sorry what was what why use chance why what if you don't have to worry about interruptions on your channel why bother with chen you don't need  that's that you know all you need to do is plug your microphone into the into the into the into your computer and have it send it by by by through port eighty and you're done you don't need these inventions if you have the whole motivation for these inventions is that your channel is not going to let you do that you're going to have a question though is is not the motivation for your patented invention right and the question is whether there is substantial evidence to support the board's conclusion that now when you come along and have to live feed on to that like they have done here that not mechanism no longer works you break chen because you don't have the data to rush once the initial buffer is depleted and you send a rush command there is nothing to rush so it can't it can't be so the problem with motivation here is this is one of those cases where the combination undoes the ability of the of the base reference to solve the problem that's that's fundamentally what you know what the problem is the board work is done address that board came up with these explanations about how the user could push the pause button which is really like that's not a solution to the problem that's getting up and saying oh well it's going to be interruptions on the china's largest what is it pausing wait till everything straightens out and then listen again that doesn't address the motivation issue wise why would a person of skill in the art be motivated to make a combination that predictably is going to undermine the ability of the prior art to do what it was intended to do that the resulting compensation differ from the claimed invention that it appears that the claim one claimed invention is in the same situation as the combination of shannon will be right but why argue is that somebody is not really motivated somebody is motivated to solve a real world problem not to reproduce claim one and i agree with you with play one says what it says but the question still is obvious is it obvious where to go you know but back to the table it sounds like your argument is basically that ransmission and playback is say with downloading something or know a preexisting stored file but it would still be good enough and it would still be attractive that people would want to be able to which is which is sending smoothly over over the internet and it is not a sufficient motivation we are yours not a sufficient motivation for somebody to put together something that can't even do what that what when what the what the prior that is that is to impair the part to make a modification that impairs the ability of the prior art to meet its intended purpose is you know that's what that is cited as a situation that that counters that counters motivation so to say that somebody would be motivated to make something that doesn't even solve the problem that the that the that the prior art solves is is not that's not a room in the real world nobody would do that a negative to motivation is there a modification that impairs the ability of the prior art to function to perform its intend may please the core there is substantial evidence to support the board's finding that there would be a motivation to combine these references chen describes a system for pacing delivery of multimedia content that's packetized it describes using a store priest or video but it does state that it can perform its necessary calculations for the pacing on the fly or during transmission the will of the reference then states it motivation it says more recently streamed audio and video have become  available from both stored and live sources on the web will be disclosed as a priest or system but then it also in another section discloses a way to provide live video to this type of priest or system are still there they're both in willoughby which itself provides market need for the ability to provide both life and priest or video and then according to the basic teachings as cats are  owner raises seems to be the fact that they don't think it's going to be reliable enough delivery that given enough time we're going to run out of the buffer so we'll be describes a buffer that several seconds and  the combined system will be going to rush a portion of the buffer over to chance find buffer and then chen continues to operate as it always would jan has ace the remainder of the server buffer and the client buffer and it  es transmission between those two buffers now it is true if you have enough interruptions you'll always run out of buffer space that that would always happen and has ownership say well few seconds that's not enough there's there's no evidence of why that would not be enough of a buffer this video would continue to play shen would continue to do with high level low level pacing until you experience more than that amount of interruptions more than a few seconds of interruptions for many videos that might be completely adequate there's no evidence that that's somehow inadequate but there is evidence in the record that a few seconds at the time was considered enough of a buffer will be itself is a live system at this time and will be chose a few seconds a buffer for its life and body so that's evidence that the time will be believed a few seconds was the proper amount of buffer size and that's substantial evidence in the record support that this idea that it's somehow too little is which has no evidence is unsupported i guess would be doesn't have to rush right will be doesn't have a rushed mode to do the initial fast startup server so if you have three seconds buffer that's three seconds of the way you can account for in chen even if that split between the two buffers and you've done the fast start up the amount of buffer that you have is still the amount of interruptions you can infer that you can account for and the same would be true of the inventive system whatever size that buffer is that's how how many seconds you have to buffer before you're going to start experiencing some kind of interruption that's just a fact of video we can generate new video faster than it's being made there's also a discussion that chen that we're throwing out the teachings of jack and in this combination the teachings the chant are not thrown out and the expert says it's going to continue to operate according to its known teachings so gender scribe that you have a low water mark and a high water mark on the fine buffer you always try to keep the buffer in the middle that well with will be excessive a buffer you have a few seconds a buffer rush a portion of it until you're above the high water the low water mark you may still have a portion of the server and then chance going to do its facing if you run low in the client buffer you're going to rush more because you're below the low water mark and so you'll rush more to the extent you can and if you go to the high water mark of chan if you're sending more packets that are being sued well then it will back up at the server buffering that would still happen so everything would continue to operate as it doesn't chat now chen doesn't say what are the exact situations where the client buffer fills to the high watermark because it is kind of a funny thing in chen when you're in between these two watermarks you're sending out the playback rate and so you're sending items out the playback rate at the same rate they're being watched you should never go above the high water mark you should be watching at exactly the same time so it's not entirely disclosure and so at the appendix on page nine thirty eight we said in chad what would cause the system to go impossible what would cause it to go above the water mark the high water mark and he said well would cause more incoming packets to the buffer zone and he said for example if the client gets a pause button then at that time you're not using the find buffer you're still sending data that data at the normal rate although it should be noted even if there were some aspects of chance that didn't function in the life watermark it wouldn't matter there can be tradeoffs when you make combinations and here it's und chen would now be able to serve life video the fact that all of chance schedule would be used when it serving a live video it's still an improvement to the system that previously could only do priest or video and finally it's also  noted that this is not a claim requirement some of these requirements are in other plans and there's no need for this combined system to meet every requirement of other homes and it by the system also doesn't need to recruit meet the objectives of the touches a claim limitation isn't that a different question whether chad and humility teaches a claim limitation in can we really apply a stock one situation so it could be it could be a different question if that if somehow in these cases so i think the particular argument made here it is proper to find that it was a stop so what was being argued was that this lost packet mechanism that had already been found buffer if we say that's the limit of the buffer schenn chance and still be requesting the packets as long as they're sort of within that buffer channel so has a timeout mechanism for once it's been too long and you know we've got to move and stop looking for the last pass it would do function the same here as a few seconds to try to grab that last pass it before it's going to play for them so i think the a stoppel goes to the fact that disclose the reloading limitations the frenzy fifty and that it goes on to explain how the compliance system would operate the same way ok thank you thank you reconstituted server buffer and i think i thought i made that clear in my in my argument that the the disclose embodiment certainly has it does it it does have the capability to reconstitute its server buffer so when the client buffer runs low librium and the thing about the thing about the cut the combinations here is that russia boating send doesn't work anymore because because of that because of this combination and all that this the server mr fauntleroy addressed that it was going to operate on the fly and do things during transmission and that's fine but one thing you can't do during transmission is send a to the server hasn't received yet that's the in that analysis and that's why it's going to run out of it's going to run out of data at the client and now it's getting back briefly to two motivation to combine you know the combination here is between chan and will it be can and carmel and the fundamental question is why why use chat if thrown out everything in chat and the thing that you absolutely need chen for here you have you know these claims are dependent from base claims and the base claims for sites very definite requirement that there has to be initial transfer of a buffer load of data from the server to the client its initial burst that gets that gets a fair start on the client that's key to yes now you can put together an arm and obviously a combination les you have a reference that does something like that that's why they need shen but when you look at this from an obvious