TiVo vs EchoStar: Echostar found to be in Contempt

[jacmyoung]

Originally Posted by Greg Bimson

The element of the claim states:

parses audio and video data from said broadcast data

If DISH/SATS never parses audio and video data from said broadcast data, then DISH/SATS has no subscribers as there would be no way to parse audio and video data from the transport stream, i.e., you cannot view a transponder. Something parses the transponder/transport into a viewable picture.

The claim term is "parses audio and video data from said broadcast data" AND a PID filter does exactly that.

Please read the first step of the software claims below carefully:

[1] 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;

To prove the new design still meet the above step, TiVo needs to identify that so called “physical data source” that does all three things above, which they say they have found it, it is called the “PID filter”. Next TiVo says, look, the PID filter parses the broadcast data, bingo!

Now your job is to try to fit the above highlighted sentence into that above claim step, be my guest.

Judge Folsom might have been fooled by TiVo, but I doubt the three circuit judges will do too, else they would not have kept asking TiVo’s attorney that question.

Having said all the above, I truly believe both E* and TiVo should work together. The synergy between the two will make their DVRs the clear leader in this new Internet TV/DVR era, set them apart from all the rest of the competitors.

TiVo can sell anything, even to Charlie, if they make a deal even Charlie cannot refuse. It will be the tallest order to fill but anything is possible.

[jacmyoung]

Originally Posted by P Smith

"This 13-bit code is part of the 188-bite stream" - please correct yourself : it is 188 BYTES...

You should have lectured Mr. Waxman that, before he started lecturing Judge Rader.

[Curtis52]

Originally Posted by P Smith

"This 13-bit code is part of the 188-bite stream" - please correct yourself : it is 188 BYTES.

As to you can't analyze encrypted PIDs for obtain info about it content, well for separation and storing those PIDs (what constitue a channel) you need analyze PMT PIDs after PAT PID, to get the knowledge: which PID is carry video, which audio(s) for selected channel.

TiVo's Red Brief:

"Even if the claims did distinguish between headers and payloads, the PID filtering circuitry must initially analyze portions of the broadcast stream—not limited to the packet headers—to synchronize the incoming packets. See A8164- 8165."

[Greg Bimson]

Originally Posted by jacmyoung

To prove the new design still meet the above step, TiVo needs to identify that so called “physical data source” that does all three things above, which they say they have found it, it is called the “PID filter”. Next TiVo says, look, the PID filter parses the broadcast data, bingo!

TiVo has only ever argued that the PID filter meets the element limitation against a device and process which "parses video and audio data from said broadcast data". That doesn't mean there isn't another part of a "phyiscal data source" which fulfills the other element of that step.

[jacmyoung]

Originally Posted by Greg Bimson

...That doesn't mean there isn't another part of a "phyiscal data source" which fulfills the other element of that step.

You don't think it is important for TiVo to prove so especially considering in a contempt proceeding the burden of proof of infringement is much higher?

[jacmyoung]

Originally Posted by Curtis52

TiVo's Red Brief:

"Even if the claims did distinguish between headers and payloads, the PID filtering circuitry must initially analyze portions of the broadcast stream—not limited to the packet headers—to synchronize the incoming packets. See A8164- 8165."

Where in the above did TiVo prove the PID filter actually analyzes audio and video part of the payloads? Did TiVo then identify how such audio and video data are "temporarily stored"?

In fact the TiVo expert admitted that the new software no longer temporarily stored the data, the code in the old software that was identified to have served that "temprarily store" function, is now gone.

[Curtis52]

Originally Posted by Greg Bimson

TiVo has only ever argued that the PID filter meets the element limitation against a device and process which "parses video and audio data from said broadcast data". That doesn't mean there isn't another part of a "phyiscal data source" which fulfills the other element of that step.

Correct. The physical data source could consist of hundreds of components. The claim describes the collective function of the components. Whatever component provides the temporary storage is automatically included as per the definition of physical data source in the claims.

[P Smith]

Originally Posted by Curtis52

TiVo's Red Brief:

"Even if the claims did distinguish between headers and payloads, the PID filtering circuitry must initially analyze portions of the broadcast stream—not limited to the packet headers—to synchronize the incoming packets. See A8164- 8165."

While it is true in general , in a case of encrypted payload (video and/or audio ) the sync between video/audio is impossible, due a location of time stamps inside on encrypted part. Hope TiVo reserved somehow in general diagram such decrypting block.

[jacmyoung]

Originally Posted by Curtis52

... Whatever component provides the temporary storage is automatically included as per the definition of physical data source in the claims.

Nothing is “automatically included”, TiVo must prove it as they did last time with regard to the old software, only this time with much higher burden of proof.

One of the limitations of such temporary storage has to be, it only stores the “audio and video data” that have just been parsed out of the broadcast data earlier, not any kind of audio and video data. The other limitation is, such temporarily stored audio and video data must then be “extracted” by that so called “source object” in the second step of the claims.

When E* asked TiVo where in the new design is that so called “source object”, TiVo could not even respond, they only said it was in there in that chart, why didn’t you go look for it? Is that how you prove to the judges by clear and convincing evidence?

Of course if TiVo cannot identify that “source object” in the new design, they cannot possibly prove the second step is met:

[2] providing a source object, wherein said source object extracts video and audio data from said physical data source;

Of course if TiVo cannot identify that “source object” in the new design they cannot possibly prove steps 4 and 5 are met either:

[4] 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;

[5] wherein said source object is automatically flow controlled by said transform object;

Without the audio and video data being parsed out from the broadcast data, there is no temporarily storing such audio and video data, therefore there is no need for a “source object” because the purpose of the source object is to extract such audio and video data, then convert the video part of the data into data streams, then fill such data streams in a buffer. It is a chain reaction that must have a start and an end. When there is no start, the whole chain crumbles.

The mistake E* made was, they did not go to such distance during the contempt proceeding to make the above points, they only argued they no longer parsed start codes. Only in the latest appeal they had employed all the points above. I had always wondered why ever since they started the contempt proceeding over a year ago. Did Charlie do so intentionally to drag TiVo through the mud? Hard to imagine he would take such risk, but then it is Charlie we are dealing with.

If you look back at the history of the contempt proceeding, Charlie was fully prepared to lose at the Judge Folsom’s court. The same day the 5/31/08 status meeting was concluded by Judge Folsom, Charlie filed the declaratory judgment suit against TiVo in the Delaware court, meaning he had already anticipated he was going to lose in that meeting.

After the 09/08 hearing, before anyone knew what Judge Folsom was going to say, Charlie was working on how to invalidate TiVo’s software claims through the PTO, and started it right after Judge Folsom said he was going to hold another hearing in 02/09.

Not to mention almost at the same time Judge Folsom issued his contempt ruling and orders on 6/2/09, Charlie had his big response already prepared, addressing point by point the Judge Folsom’s ruling, and sent his motion to the appeals court, had the appeals court stayed Judge Folsom’s ruling in less than 24 hours. I have never ever seen rapid responses like those before.

It reads like a fiction novel, the only thing missing is a dead body somewhere.

[BobaBird]

Originally Posted by jacmyoung

Please read the first step of the software claims below carefully:

[1] 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;

To prove the new design still meet the above step, TiVo needs to identify that so called “physical data source” that does all three things above, which they say they have found it, it is called the “PID filter”. Next TiVo says, look, the PID filter parses the broadcast data, bingo!

The physical data source parses video and audio data from broadcast data (from the s/w claim).

A DBS satellite transponder carries multiple channels of broadcast data (fact), and the function of the satellite receiver is to display a selected channel by looking to the appropriate transponder stream and tuning that channel.

The PID filter only parses a 188-byte header to identify which packets of the transponder stream to keep together to form the requested broadcast data (as explained in this thread).

The physical data source in the s/w claim gets its broadcast data from an input device. There is no discrete broadcast data until the transponder stream is processed as directed by the PID filter.

There is now a usable signal from which the physical data source can parse video and audio data. The parsing of the header is different from the parsing of audio and video data from the broadcast stream. The PID filter is an essential element of the satellite receiver, whether or not it also has DVR functionality.

DVR functionality is made possible by the parsing and storing of A/V data which is done by a physical data source that requires an input.

Conclusion: The PID filter is the input device in the software claim.

[jacmyoung]

You are absolutely correct that the PID filter is part of the “input device”, right in front of TiVo’s “physical data source”. The “physical data source” “accepts” “broadcast data” from the “input device”. E* tried to explain to Judge Folsom this way during the 02/09 hearing, they even used TiVo’s own figures during the trial (with arrows going all over the places) to point it out to the judge, but it did not work. It was too complicated. Judge Folsom probably dozed off at that point.

I think E* decided to dumb it down for the judges and figured that since it is a fact when the PID filter receives the broadcast data, the audio and video data contained in it are scrambled, so the PID filter cannot possibly analyze such data even if it wants to.

It seems to have worked for the circuit judges. It even worked for the TiVo’s attorney since he pretty much admitted if the audio and video data are scrambled, the PID filter cannot analyze them.

[audiomaster]

Originally Posted by Greg Bimson

The element of the claim states:

parses audio and video data from said broadcast data

If DISH/SATS never parses audio and video data from said broadcast data, then DISH/SATS has no subscribers as there would be no way to parse audio and video data from the transport stream, i.e., you cannot view a transponder. Something parses the transponder/transport into a viewable picture.

The claim term is "parses audio and video data from said broadcast data" AND a PID filter does exactly that.

______________
Seems to me that if it separates (parses) the data for one channel from the total transponder stream, and if that data contains audio and video as part of the separated signal, then it is parsing audio and video data whether it is encrypted at that point or not, and whether there is other data with it. There is AV data in the part being separated, hence it is "parsed"

[Curtis52]

Originally Posted by P Smith

While it is true in general , in a case of encrypted payload (video and/or audio ) the sync between video/audio is impossible, due a location of time stamps inside on encrypted part. Hope TiVo reserved somehow in general diagram such decrypting block.

If some of the channels are scrambled, I wonder how Dish was (supposedly) able to get the start codes from the PID filter previously.

[scooper]

Originally Posted by audiomaster

______________
Seems to me that if it separates (parses) the data for one channel from the total transponder stream, and if that data contains audio and video as part of the separated signal, then it is parsing audio and video data whether it is encrypted at that point or not, and whether there is other data with it. There is AV data in the part being separated, hence it is "parsed"

How are you going to "parse" encrypted data (in this case audio / video data) without decrypting it ?

All you have at the PID filter level is the header and the encrypted payload. The "packets" of audio video data (with their header information) are encapsulated in the encrypted payload.

[Curtis52]

Exactly. Dish's excuse for the flip flop in whether the PID filter still analyzes audio and video data or not was that they used to get start codes from the PID filter. If that's true, how did they do that with scrambled data?

[scooper]

OK - throw this in the mix -

satellite data => PRIMARY PID filter =>decryption engine => SECONDARY PID filter

[Curtis52]

What purpose does the first filter accomplish that can't be done by the second filter? Why would Broadcom put in two filters?

Anyway, that would mean that the second filter certainly still analyzes audio and video.

[P Smith]

Originally Posted by scooper

OK - throw this in the mix -

satellite data => PRIMARY PID filter =>decryption engine => SECONDARY PID filter

You don't need "SECONDARY PID filter", from this point you could start parsing payload, extract headers/t_stamps/etc and making idx tables for later trick play and multiple access to same 'channel' ie stored on HDD A/V packets.
In reality, dish is using more complicated processes - for example VOD movies stored as encrypted stream.

[scooper]

Originally Posted by Curtis52

What purpose does the first filter accomplish that can't be done by the second filter? Why would Broadcom put in two filters?

Unless you're suggesting that they are looping the data out of the decryption engine back into the PID filter , how can you NOT do it that way ?

You can implement this one of 2 ways -
You have 2 (or more) PID filters
OR
you put a flag in the header that states this is encrypted / decrypted data so you can loop it back if encrypted.

Both are equally valid ways of handling it. It really depends on the design priorities - silicon is cheap and fast.

We all know that Dish stores data on the harddrive in encrypted form. We also know that in Dish's DVR designs - EVERYTHING is buffered through the harddrive.

[P Smith]

"We all know that Dish stores data on the harddrive in encrypted form." - telling that is like telling: you or we all know nothing.

That's simple not true: "Dish stores data on the harddrive in encrypted form" and such "we all know that".

It was true before - for 721 and 921 but those DVRs become to dead end recently.

[jacmyoung]

Originally Posted by Curtis52

If some of the channels are scrambled, I wonder how Dish was (supposedly) able to get the start codes from the PID filter previously.

E* admits their previous position with regard to the PID filter was wrong, because the jury said so by finding for the TiVo’s argument.

The question is then, which would our court prefer? That E* admits they were wrong and now changes its position to that of TiVo’s winning position at trial, or E* must stick to its losing position it took during the trial and allow TiVo to also adopt E*’s such losing position to punish E* for it?

In the name of justice, which of the above should the court prefer?

If I make a statement A about you, you correctly point out to the judge I am wrong, the correct statement about you should be B, the court agrees with you and I am ordered to pay you $100 for defamation.

Now I go around telling people you are in fact B. Should you be allowed to go to the judge and ask him to again fine me another $100 for saying your are B?

[scooper]

Originally Posted by P Smith

You don't need "SECONDARY PID filter", from this point you could start parsing payload, extract headers/t_stamps/etc and making idx tables for later trick play and multiple access to same 'channel' ie stored on HDD A/V packets.
In reality, dish is using more complicated processes - for example VOD movies stored as encrypted stream.

Certainly - you aren't expecting the PID filter to be doing that parsing payload, extract headers / T-stamps/etc. ? Especially if you had read Echostar's OWN Patent application where they AREN'T creating said idx tables, etc. for doing trick plays and multiple access.

[peak_reception]

Originally Posted by P Smith

"We all know that Dish stores data on the harddrive in encrypted form." - telling that like telling you or all know nothing.

intelligibility edit please.

[Greg Bimson]

Originally Posted by jacmyoung

E* admits their previous position with regard to the PID filter was wrong, because the jury said so by finding for the TiVo’s argument.

Funny. Let's get this straight:

All of DISH/SATS' experts state that PID filtering meets the element limitation. Because DISH/SATS lost, the argument cannot be used against DISH/SATS.

TiVo's experts state that PID filtering meets the element limitation. Because DISH/SATS lost, somehow TiVo's exact same expert testimony cannot be used against DISH/SATS because DISH/SATS' experts agreed with TiVo.

I seem to recall that if all experts on both sides agree, it becomes an irrefutable fact. Especially when one expert has to recant his testimony so that DISH/SATS can completely reverse positions as compared to trial.

[jacmyoung]

Originally Posted by Greg Bimson

...I seem to recall that if all experts on both sides agree, it becomes an irrefutable fact. Especially when one expert has to recant his testimony so that DISH/SATS can completely reverse positions as compared to trial.

The TiVo's expert also completely changed his position, if you had listened to the oral argument, the E* attorney quoted the TiVo's expert's testimony in order to make that point. BTW, all the judges agreed, even Judge Folsom, that both sides completely changed their positions.

Show me where it says if all experts on both sides agree, it becomes an irrefutable fact? Experts offer opinions based on facts, not facts based on facts. Experts' opinions cannot be facts.

Have you missed my citation from the appeals court, in which the court had said, expert opinions are "extrinsic evidence", if such "extrinsic evidence" is in conflict with the "intrinsic evidence" provided by the claims and the specification of the patent, the "intrinsic evidence" rules.

Even if all the experts had stated that the PID filter met the "parse" limitation, as long as it does not parse any audio and video data, and also does not temporarily store such audio and video data (both "intrinsic evidence" from the claims), the experts' opinion cannot overcome such claims requirement.