I thought it was a lot more than that, but I agree should have thought about buying ReplayTV then.
But buying ReplayTV in 2007 would not have changed the current situation, it could deter any future proceedings against E* maybe.
TIVO vs E*
- Thread starter Juan
- Start date
- Latest activity Latest activity:
- Replies 2K
- Views 169K
- Status
I thought it was a lot more than that, but I agree should have thought about buying ReplayTV then.
But buying ReplayTV in 2007 would not have changed the current situation, it could deter any future proceedings against E* maybe.
Nope. ReplayTV was being sued by the studios and was about to go bankrupt. Ti Vo knew they couldn't get blood out of a turnip. Both companies withdrew their suits without prejudice (meaning they could refile a lawsuit anytime they felt like it). ReplayTV/Sonicblue declared bankruptcy a couple of months later.
I think the point was, had Charlie bought ReplayTV, he could have countersued TiVo therefore deterred TiVo from further court proceedings against him.
Of course one can also argue that by 2007, E* was confident that they had a safe design around, there was no point paying for ReplayTV. Who knows, history may prove Charlie correct. Many seem too eager to write this thing off, too soon.
Some might find this amusing:
Davis Freeberg’s Digital Connection Blog Archive Dish Researching Hostile TiVo Takeover?
Davis Freeberg’s Digital Connection Blog Archive Dish Researching Hostile TiVo Takeover?
DISH/SATS only assertions regarding the modified software:jacmyoung said:
None of the eight named models of DVR found infringing parse .
The Broadcom-DVR's are no longer flow-controlled.
Those were DISH/SATS only assertions. And this is basically both claims 31 and 61 in a nutshell:
31. A process for the simultaneous storage and play back of multimedia data, comprising the steps of:
providing a physical data source, wherein said physical data source accepts broadcast data from an input device, parses video and audio data from said broadcast data, and temporarily stores said video and audio data;
providing a source object, wherein said source object extracts video and audio data from said physical data source;
providing a transform object, wherein said transform object stores and retrieves data streams onto a storage device;
wherein said source object obtains a buffer from said transform object, said source object converts video data into data streams and fills said buffer with said streams;
wherein said source object is automatically flow controlled by said transform object;
providing a sink object, wherein said sink object obtains data stream buffers from said transform object and outputs said streams to a video and audio decoder;
wherein said decoder converts said streams into display signals and sends said signals to a display;
wherein said sink object is automatically flow controlled by said transform object;
providing a control object, wherein said control object receives commands from a user, said commands control the flow of the broadcast data through the system; and
wherein said control object sends flow command events to said source, transform, and sink objects.
providing a physical data source, wherein said physical data source accepts broadcast data from an input device, parses video and audio data from said broadcast data, and temporarily stores said video and audio data;
providing a source object, wherein said source object extracts video and audio data from said physical data source;
providing a transform object, wherein said transform object stores and retrieves data streams onto a storage device;
wherein said source object obtains a buffer from said transform object, said source object converts video data into data streams and fills said buffer with said streams;
wherein said source object is automatically flow controlled by said transform object;
providing a sink object, wherein said sink object obtains data stream buffers from said transform object and outputs said streams to a video and audio decoder;
wherein said decoder converts said streams into display signals and sends said signals to a display;
wherein said sink object is automatically flow controlled by said transform object;
providing a control object, wherein said control object receives commands from a user, said commands control the flow of the broadcast data through the system; and
wherein said control object sends flow command events to said source, transform, and sink objects.
The bolded parts were DISH/SATS only assertions on how they no longer infringe. Which means the modified DVR's still do everything that is not bolded.
Keep in mind, after finding of guilt and the implementation of the workaround, the 622/722 received a software update, presumably the same workaround the eight named DVR's received.
If DISH/SATS felt the need to "upgrade" the 622/722, one can simply assume that DISH/SATS felt those receivers were in danger the way they were. Now that these modified DVR's have also been found infringing, it is possible the 622/722 would be in the same class.
Yes, I remember this from the last few times you've posted it. But lets not forget we are talking about DVRs here that use different technology all together than the ones named in the trial. The ViP series can handle both mpeg4 and mpeg2 datastreams, the DVRs in question, only one, mpeg2. This leaves two open issues, does the mpeg4 datastream alone, or the ability to handle two distinct A/V technologies alone separate the ViP from the previous DVRs enough to be considered new technology. I think it has.
I don't know how well you understand the technical elements of this trial, but when you look at your two highlighted points, the parsing of A/V data and the handling of the transform object, those are two elements that could directly apply to my two points mentioned about. Now if that the case, we would need to see the exact specification to know that. But is it a fair educated guess that may have some merit within this discussion? Certainly...
The only thing you can be certain of is that Tivo's lawyers will continue to 'dummy down' the expert witness testimony in an attempt to take advantage of the judges ignorance, and continue to expose the glaring problems with our legal system. I can see this whole thing coming down to the differences between mpeg2 and mpeg4 with regards to the synchronization of the audio and video layers during a trickplay, and the ViPs ability to presently work it, where Tivo is playing 'catch up' in that department and claiming to have invented it..
It is slightly over-reaching to worry about MPEG2 or MPEG4 technology when the court has agreed the "parsing" limitation applies to the decoding of a channel from a broadcast transponder. At that point, MPEG doesn't even matter, as the PID filter in either an MPEG2 or MPEG4 implementation simply "parses" one channel out of the numerous channels on broadcast on a single transponder.vampz26 said:
Not true, I don't known if you actually read the whole Feb hearing transcripts, in there E* spent a good deal of time explaining to the judge how the PID filter only parsed the channel ID packets in order to select which channel to tune to, and at that point the broadcast data are encrypted, and E* explained while the data were encrypted, there was no way to analyze "audio and video data" hidden in the stream. After the PID filter parsed the channel ID packets, which E* stressed such ID packets contained no "audio and video data," only channel IDs for channel selection, only then the TV program stream was sent to the next step to be decrypted, then to the next step to have the audio and video data analyzed, at that point the PID filter's job was already done. This explanation was not contested by TiVo at all.
Secondly E* also got the TiVo's expert to admit that the new software did not "temporarily store" anything at the PID level. Those are the two things I have mentioned before, but the judge never responded to them in his opinion piece, talk about being careful. On appeal, E* can raise these two issues, and TiVo will be left to argue on their own without the judge's opinion for support, because the judge never paid attention to these two points.
If E* updated 622s/722s with the new software after the new software had been found to continue to infringe by the judge, it only demonstrated that they were confident they could win on appeal, else why bother?
That doesn't make sense, Do you know anything about parsing mpeg2 and mpeg4 datastreams? Or even differentiating between the two? Or are you agreeing that the concept is intentionally dummied down to confuse the judges? Because quoting the courts like scripture to respond to a technical statement just isn't going to cut it...
The appeals court had already said MPEG2, ATSC, NTSC or Pal, did not matter, they are simply "broadcast data." Since MPEG4 falls into the same category, MPEG4 will be construed as "broadcast data" just like MPEG2.
But the "audio and video data" is another element which E* argued the PID filter did not parse, because it was impossible for it to even parse such data when the data was encrypted at that time. Only after the PID filter parsed the "broadcast data" and found the correct channel to tune, then the decryption took place and only after that the "audio and video data" contained in the "broadcast data" could be analyzed, by then the process had already passed beyond the PID filter stage.
What update was this ? Where was it documented what the changes entailed ? To assume that just because Dish pushed an update shortly after a court decision that the "change" was related is stretching.
I'm well aware of that, and that was exactly what I meant when I said.
"The only thing you can be certain of is that Tivo's lawyers will continue to 'dummy down' the expert witness testimony in an attempt to take advantage of the judges ignorance, and continue to expose the glaring problems with our legal system." which it has. That statement is very vague and not close to the truth regarding the details. Mpeg2 and PAL aren't even comparible enough to make the a statement like that stand up to technical scrutiny, much less 'assume' mpeg4 is included or not. We are comparing two distinct types of compression algorithms for digital media to analog...they just don't compare enough to give such a general statement any credibility a technical level.
But anyway, when the subject of the ViPs was brought up in this thread, you correctly stated that the ViPs weren't on the table because the ViPs did not exist during the initial trial sequence. Which means quite possibly a new trial...
And then I said, and have been saying, that I expect this whole parsing of the datastream to get paid much closer attention this time around because the the ViPs use different technology to parse both mpeg4 and mpeg2 datastreams than the previous DVR implementations, either Tivo or Dish, and such a difference could very well present colorable difference as they are build upon different technical foundations...
Without going into the semantics of what MPEG2 or MPEG4 do, "parses video and audio data from said broadcast data" has nothing to do with the format.
I want my receiver to show me ESPN.
A transponder contains 12 channels.
A PID filter can figure out which one of the 12 channels it wants, so it analyzes the broadcast data and parses out ESPN, in some format.
That is the step that is met. It doesn't matter if it is MPEG2 or MPEG4. Once that analysis occurs, then ESPN is "audio and video data" in MPEG2 or MPEG4 format. The analysis occurs before the "audio and video data" is simply an MPEG channel.
I want my receiver to show me ESPN.
A transponder contains 12 channels.
A PID filter can figure out which one of the 12 channels it wants, so it analyzes the broadcast data and parses out ESPN, in some format.
That is the step that is met. It doesn't matter if it is MPEG2 or MPEG4. Once that analysis occurs, then ESPN is "audio and video data" in MPEG2 or MPEG4 format. The analysis occurs before the "audio and video data" is simply an MPEG channel.
It is amusing. It's ludicrous to think That Dish hasn't known every detail about Tlvo's poison pill since day one and had to resort to searching blogs.
You do not know the fundamental differences between the mpeg2 or mpeg4 data to make that claim, and there is not enough physical evidence one way or another for you to prove it.
You're oversimplifying an otherwise complex technical issue.
You're confusing the issue with the MPEG2 vs MPEG4 details. They are irrelevant and if you notice, you're the only one who thinks it has anything to do with the patent/lawsuit.
No...let me clarify...
They had nothing to do with the previous lawsuit because the DVRs in question were only mpeg2. You are correct mpeg4 had NOTHING to do with the lawsuit. There weren't even any mpeg4 DVRs being questioned.
I'm saying that when and if the ViP get brought to trial. There is a very strong possibility that the whole issue could get revisited. Mpeg2 and mpeg4 are two different video compression technologys and could by default change part of the design. How much or how little is what waits to be seen.
The only thing confusing to some, is that my statement is a forward looking statement regarding the ViP series and the ongoing trials. Anything that happened in the past is irrelevant to my statement because the ViP series was never highly scrutinized and the technology within the ViP series wasn't present in the DVRs that were.
Thats all...
Not "in some format" because it only points to which channel to select, no "parsing out audio and video data" from the ESPN programming stream, also the PID filter does not "temporarily store" the "audio and video data."
TiVo spent a great deal of time during the trial to prove how the old software "parsed out the audio and video data" and then "temporarily stored" such data, now TiVo's burden of proof is much higher, yet it did not even try to prove what "audio and video data" did the PID filter "parse out" and also admitted the PID filter did not "temporarily store" the data.
Yet Judge Folsom still agreed that TiVo had proven by clear and convincing evidence that the first step of the software claims was met.
BTW, care to explain how Judge Folsom had concluded that even if the redesigned DVRs were non-infringing, E* would still be in violation?
Okay, I'll bite.vampz26 said:
The 622/722 variants can decode MPEG2, just like the 522/625 and the 50X series. Just because MPEG4 decoders were added to the mix does not change the fact the 622/722 pretty much behaves like the all other satellite receivers, which must analyze the transport stream from the transponder to create an MPEG2/4 channel stream.
It could be a trial, but it is more than likely a bench hearing if TiVo ever gets off their duff and files a motion for contempt regarding infringement.vampz26 said:
You are doing the exact same thing as vampz:jacmyoung said:
parses video and audio data from said broadcast data
is the same as
grab a transport stream and pluck out the data you want to store (in my example, it is simply how a satellite receiver analyzes the signal to put ESPN on your TV)
There doesn't need to be an analysis of the video and audio data, there needs to be an analysis of the broadcast data. In the case of SD DVR's, that is an analysis of the transport stream from satellite. In the case of HD DVR's, it is both the satellite transport stream and also the digital transport stream from terrestrial broadcasters.
Semantics and somewhat incorrect.jacmyoung said:
Every expert from the April 2006 trial (two from TiVo, three from DISH/SATS) testified that the PID filter met the limitation for parsing. The proof is in the parsing.
During the February 2009 bench hearing, TiVo caught the DISH/SATS expert recanting his testimony that the PID filtering meets the "parse" limitation. But I never saw where DISH/SATS ever tried to prove that they no longer meet the "temporarily store" limitation in the same step.
- Status
