TIVO vs E*

[Greg Bimson]

That is not what the problem is, the problem is when the court decides to accept only one side of the story, ignore the story from the other side.

Isn't that what a court does?

The problem is that one story contradicts much of the law of the case.

Meanwhile, TiVo simply compared that which was found infringing to the modifications, and found that against the claims the elements are still there and being met.

Dish's argument is that I-frame analysis must also be applied in claims 31 and 61 where it says parse. This was never stated as a requirement at trial or appeal.

This was never stated as unnecessary at trial or appeal either, now E* says based on the patent specification, the prosecution history, in the context of the entire patent, it is necessary.

But you must understand that during the specification and the prosecution history of the patent, the limitation of the parse element was met by PID filtering.

What is being asked of the court by DISH/SATS is to evaluate this new definition when the old one still stands, because it was not challenged.

[jacmyoung]

Isn't that what a court does?

No it should not be, the court should not ignore any stories, no matter if it agrees with them or not.

What is being asked of the court by DISH/SATS is to evaluate this new definition when the old one still stands, because it was not challenged.

It was not asked on appeal because E* could not, they still did I-frame and start codes, asking the appeal court to limit the court constructions to them would be useless. Therefore the court simply did not address this issue.

Now E* asked the court to address such issue, based on the interpretation of the whole patent...

I just want to point out two things, Thomas22 just did me a favor by pointing out yes the judge actually did read E*'s contentions, he did not ignore them, somehow I missed the two quotes.

If one reads the judge's above counter arguments, it is clear the judge himself did not read the patent claims well himself.

For one thing, he said the "physical data source" needs only parse, which is absolutely not true, just read the first step of the software claims, it needs to do three things.

Secondly he said the "parse" did not have to be performed on the "payload," which was accepting E*'s contention that the PID filter did not parse the "payload," but then he argued parsing the "header" is just good enough, except he forgot the "header" contained no "audio and video data."

He did not try to say but the header also contained audio and video data, because TiVo did not try to prove such.

The judge's conclusions point out the fact he simply did not realize the term "audio and video data" was one of the limitations in the software claims step too, along with "parse" and "temporarily stores."

BTW Curiousmark, if TiVo had argued "temporarily stores" limitation could you quote it for us? Based on what the judge said, no "temporarily stores" was explained by TiVo.

It is true E* experts argued the PID filter met "parse" limitation back then, and now E* explained why they were wrong before, but the point is, no one argued back then the PID filter was that "physical data source." TiVo only argued the "media switch" was the "physical data source." Now TiVo is saying the PID filter can be that "physical data source." But both TiVo and the judge simply said to be that "physical data source" it only needs to "parse."

Please read the first step of the software claims again, it needs to meet three limitations, not just "parse."

[Greg Bimson]

If one reads the judge's above counter arguments, it is clear the judge himself did not read the patent claims well himself.

For one thing, he said the "physical data source" needs only parse, which is absolutely not true, just read the first step of the software claims, it needs to do three things.

But DISH/SATS contention was they no longer "parsed", not that they no longer did three things.

Secondly he said the "parse" did not have to be performed on the "payload," which was accepting E*'s contention that the PID filter did not parse the "payload," but then he argued parsing the "header" is just good enough, except he forgot the "header" contained no "audio and video data."

Except during trial all five experts stated PID filtering met the parse element limitation. Very difficult to get around that.

It is true E* experts argued the PID filter met "parse" limitation back then, and now E* explained why they were wrong before, but the point is, no one argued back then the PID filter was that "physical data source." TiVo only argued the "media switch" was the "physical data source."

No, TiVo did argue that the PID filiter was part of the physical data source and that it met the limitation on the parse element. That is how five of five experts agreed that PID filtering met the limitation.

[CuriousMark]

Secondly he said the "parse" did not have to be performed on the "payload," which was accepting E*'s contention that the PID filter did not parse the "payload," but then he argued parsing the "header" is just good enough, except he forgot the "header" contained no "audio and video data."

I will explain again. A packet is a block of data that contains a header and a payload. The header is short and sits at the front or top of the packet, among other things, it includes a PID and a length that tells how long the packet is, including the payload data.

A PID filter examines the PID in the header of each packet from the transponder stream. If the PID matches its selection list, the WHOLE PACKET is placed in temporary storage. The PACKET, which is parsed out of the transponder stream and into temporary storage does indeed contain audio and video data. The whole packet is parsed, therefor the audio and video data within it is also parsed from the transponder stream. This is a physical data source.

BTW CuriousMark, if TiVo had argued "temporarily stores" limitation could you quote it for us? Based on what the judge said, no "temporarily stores" was explained by TiVo.

You, Curtis, Gregg and others have quoted it many times. If you choose to understand the words correctly, there is no confusion.

It is true E* experts argued the PID filter met "parse" limitation back then,

Which by definition, means that it is a physical data source and that it temporarily stores. Nothing more need be said.

[jacmyoung]

I had trouble quoting posts so this is in response to Greg:

E* is talking about the "physical data source" now, because as E* said during the hearing, whatever was not mentioned in the software claims was irrelevant (according to TiVo) so let’s talk about that "physical data source." See how TiVo’s argument is now used against them? Because as E* said during the hearing, the term "PID filter" was not mentioned in the first step either.

E* argued that for that "physical data source" to exist in the new design, it had to do three things, according to the terms of the first step in the software claims.

There are several claim limitations disclosed in the first step, as I pointed out:

1) Obtain
2) Parse
3) Parse audio and video data from the broadcast data
4) Temporarily stores

There are other limitations but E* is now focused mainly on limitation number 3).

There seems to be the belief that there is only one limitation in the first step, called the "parse limitation." But this is not true because during the jury trial, at a minimum Judge Folsom constructed two limitations, specifically 2) and 3).

He construed number 2) "parse" as "analyze." He then construed number 3) "parse audio and video data from the broadcast data" as "analyze audio and video data from the broadcast data." Both 2) and 3) are claim limitations which were constructed by the court before. The problem is now Judge Folsom says only the 2) is needed to meet the definition of the "physical data source," 3) is not needed.

E* is saying the "physical data source" must also meet 3), as constructed by the court itself back during the jury trial. E* is not contesting the court constructions nor trying to change them, E* is simply saying we are following the court construction 3) to mean the "physical data source" must meet the "analyze audio and video data from the broadcast data" limitation, in addition to meeting the "parse" limitation.

Of course there are other limitations such as the "temporarily stores" which I do not think the court had offered any construction, in such case this limitation will just have to be interpreted as is.

So to Curiousmark, the "parse limitation" is just that, the meaning of the word "parse." There are other limitations too, specifically the "parse audio and video from the broadcast data" limitation. Each limitation stands on its own.

The question the appeals court must now answer is, can the court ignore some of the limitations, and only apply one limitation.

If only this one parse limitation is good enough, then why did TiVo use all the other limitations in the first step of the software claims to describe its invention? And more importantly, if only the parse limitation is good enough, why did the court try to construe the "parse audio and video data from the broadcast data" limitation? It must be important if the court spent time to try to provide its own construction for that limitation.

[CuriousMark]

So to Curiousmark, the "parse limitation" is just that, the meaning of the word "parse." There are other limitations too, specifically the "parse audio and video from the broadcast data" limitation. Each limitation stands on its own.

Different claims, different claim constructions. You are now pouring them all together into one. A PID filter parses, it parses packets containing audio and video data from the full transponder stream of broadcast data. It meets both items on your list.

[jacmyoung]

Different claims, different claim constructions. ...

We have been talking about the software claims and the software claim constructions I hope.

I will quote what the judge said again, which was quoted by Thomass22 already:

Finally, the claims do not require that parsing be completed on the payloads of the incoming data rather than their headers. EchoStar’s arguments to this effect are thus inapposite. Therefore, this Court finds that PID filtering satisfies the parsing limitation of the Software Claims, the PID filter is a physical data source that parses incoming data.

But what kind of data from the incoming broadcast data that "physical data source" must parse? Does such data have to be specifically audio and video data, or any data, for example that 13-bit code in the header? The judge never addressed that.

From the above quote, the judge had already accepted E*’s argument that the PID filter did not parse the payloads of the incoming data, rather just the headers. So your argument about the PID filter still parses the playloads is in contrast to what the judge had said. I only care about what the judge said.

Next the judge said but parsing header was enough to satisfy the term "parse," despite the fact he agreed the PID filter did not parse the payloads. What he ignored was the point E* made, the header contained no "audio and video data." Therefore if the judge agreed the PID filter parsed only the header, not the payloads, he had to agree that the PID filter did not parse "audio and video data", unless the judge could argue that the header also contained audio and video data.

The judge simply skipped the "audio and video data" part. If one simply does not think the term "audio and video data" is important, please read the last appeals court ruling again and find out how the appeals court scrutinized each and every word in the claims.

Not to mention the term "audio and video data" is probably one of the most important limitations in the software claims, because it is mentioned three and half times, that is correct:

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

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

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

If such data is just a 13-bit code which has no audio data nor video data, just a code, can the above steps of the invention take place?

[CuriousMark]

But what kind of data from the incoming broadcast data that "physical data source" must parse? Does such data have to be specifically audio and video data, or any data, for example that 13-bit code in the header? The judge never addressed that.

As I pointed out before, they are both in the same packet, they are ONE AND THE SAME. The distinction is meaningless. The 13 bit code in the header is the PID, it is what is used to decide which packets to parse. Think of it as the name of the stream that the packet is a part of. Instead of 13 bits it could be "Fox News Audio". Every packet that contains a tag that said Fox News Audio would be parsed out of the incoming stream and place in the temporary buffer.

You cannot parse the code without parsing the payload it identifies.

Let me put this another way. Imagine that the code is the street address sign on the side of a building you want to visit. When you visit you enter the building. If I apply your logic above to this scenario you would be saying that you wanted to visit and enter the street address sign itself and not the building to which it is attached. Of course that makes no sense whatsoever, you can't enter a painted sign. Similarly you cannot parse the code without getting the whole packet.

From the above quote, the judge had already accepted E*’s argument that the PID filter did not parse the payloads of the incoming data, rather just the headers. So your argument about the PID filter still parses the playloads is in contrast to what the judge had said. I only care about what the judge said.

No, the judge is agreeing with E*'s argument that PID filter does not open the payloads and parse out I-frame locations into an index table. That does not imply that the packets are not parsed, that would be non-sensical.

Next the judge said but parsing header was enough to satisfy the term "parse," despite the fact he agreed the PID filter did not parse the payloads. What he ignored was the point E* made, the header contained no "audio and video data." Therefore if the judge agreed the PID filter parsed only the header, not the payloads, he had to agree that the PID filter did not parse "audio and video data", unless the judge could argue that the header also contained audio and video data.

No, the judge did not ignore anything. He understands the audio and video data are in the packet that is parsed using the information in the header. What he agreed with is that the Audio and Video data are not additionally parsed in a second operation to extract I-frame locations and build an index. He agrees, this is not done, but that the initial parsing is adequate to meet the claim limitation.

The judge simply skipped the "audio and video data" part. If one simply does not think the term "audio and video data" is important, please read the last appeals court ruling again and find out how the appeals court scrutinized each and every word in the claims.

He skipped nothing, he understands how a PID filter works.

Nowhere is Echostar/Dish making this non-sensical argument. The argument they are making is that the claim limitation to parse in claims 31 and 61 must include parsing of I-frames and index table generation because that is what was described as the claim limitation in claims 1 and 32. They want to narrow claims 31 and 61. They could have done so at trial or at appeal, but chose not to. It's too late now.

The horse is dead. I will stop beating it now.

[jacmyoung]

To follow up on my previous post:

Also notice the "video data" in step 4, not "video and audio data." Even though the software claims do not disclose it, the "audio and video data" are separated, as disclosed in the hardware claims, that is why the "source object" only converts the "video data" into a "data stream," skipping the "audio data" part.

Most people probably think the software claims read like gibberish, so let me use the interpretation below to make sense of all the gibberish terms, if and only if you are willing to accept my interpretation, and look at the invention as a whole.

The "video and audio data" depict "start codes." The start codes are the I-frames of the MPEG streams, they have two parts, audio I-frames and video I-frames, hence called "video and audio data."

The physical data source parses out the audio I-frames and video I-frames from the MPEG broadcast data streams, then separates the two parts (this is omitted in the software claims but in the hardware claims) then temporarily stores them.

Only then can the "source object" "extract" such audio and video I-frame data from the physical data source. The source object then takes the video I-frame part (already separated out) and coverts the video I-frame part into a "data stream" (i.e. an index table) and fills such index table in a buffer it just obtained.

Why is only the video data (video I-frames) needed? Because during the DVR trickplays, only the video is present, not the audio. Anyone who is familiar with DVR trickplays knows when you do pause, skip forward or back, there is no audio, only video.

What I have just described above is the TiVo’s very own invention, as described by the software claims. The only way one can begin to make some sense out of the language of the software claims is if you are willing to accept the interpretation in the context of the entire patent and the patent specification. If one only reads the software claims themselves, one may never understand them.

That is why the appeals court said, when a person of ordinary skill in the field of the invention reads the patent, it must be assumed he/she reads the patent in the context of the entire patent, the prosecution history of the patent, and the patent specification.

The patent law requires the patent to be disclosed in such manner that a person of ordinary skill in the field of the invention must be able to duplicate the invention without undue experimentation, why? So he/she may learn from the invention and design around the patent, as long as the design around does not infringe.

If one only reads the software claims above, one will never be able to understand the invention, that is why interpreting the invention on the software claims alone is wrong, against the whole purpose of the patent law.

[Smith, P.]

Video and audio elementary streams coming from different PIDs; I-frame is applicable to video only; both streams [v/a] carry timestamps - you can not do any trick play without syncing the two (or more in case of multi language or/and AC-3 type ) timestamps. It is impossible to works with timestamps and I-frames if the payload is encrypted; decrypting should precede to that indexing process.