throbber

`
`IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`DOCKET NO: 0111168-00241
`
`
`PATENT:
`
`
`
`6,466,568
`
`Alex Krister Raith,
`INVENTOR:
`James Ragsdale and John Diachina
`FILED:
`
`September 21, 1999
`
`
`
`
`
`ISSUED: October 15, 2002
`
`MULTI-RATE RADIOCOMMUNICATION SYSTEMS AND
`TERMINALS
`
`TITLE:
`
`
`
`Mail Stop PATENT BOARD
`Patent Trial and Appeal Board
`U.S. Patent & Trademark Office
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`
`OPPOSITION DECLARATION OF HARRY BIMS, PH.D.
`
`
`
`I, Harry Bims, declare as follows:
`
`General Background
`
`1. My name is Harry Bims. I previously submitted a Declaration of
`
`Harry Bims, PhD, which I understand was filed with a Petition for Inter Parties
`
`Review of U.S. Patent No. 6,466,568 as Exhibit 1009. My background is
`
`described in that Declaration.
`
`2.
`
` I have been asked for my opinions on certain issues relating to a
`
`Patent Owner’s Motion to Amend U.S. Patent No. 6,466,568 Under 37 C.F.R. §
`
`42.121, which I have reviewed.
`
`
`
`1
`
`Broadcom v. Ericsson
`IPR2013-00602
`Broadcom 1026
`
`

`

`
`
`The ‘568 Patent
`
`3.
`
`Even if the ‘568 patent were to disclose a service type identifier that
`
`identifies more than just the “type of information” as alleged in Owner’s Motion to
`
`Amend, it only discloses identifying channel coding, not the broader “transmission
`
`characteristics of a service” as advocated by Owner. During prosecution, Owner
`
`cited to the following passage:
`
`[T]he FOC fields may also serve the purpose of service
`type identifier. In this embodiment, the FOC can provide
`information regarding the type of service which the
`associated payload is currently supporting, the channel
`coding and/or interleaving associated therewith. (’568 at
`9:27-32; Ex. 1001).
`Referring to this passage, Owner argued that “it is clear that the FOC field
`
`can provide information regarding three different aspects of the transmission,
`
`namely, 1) type of service, 2) channel coding, and 3) interleaving. These different
`
`aspects can be alternatives or they can all be indicated by the FOC field.” (Ex.
`
`1016 at 5). Interleaving is not a transmission characteristic, but just a way of
`
`rearranging data prior to transmission. Therefore the ‘568 patent only supports
`
`identifying channel coding in addition to the contents of the payload.
`
`
`
`
`
`
`
`
`
`2
`
`

`

`
`
`Morley Anticipates Amended Claims 8-13
`
`4.
`
`In my original Declaration I explained why Morley anticipated claims
`
`1-6 of the ‘568 patent. Below I provide an additional discussion of Morley in
`
`opposition to Patent Owner’s Amended Claims 8-13.
`
`5.
`
`Owner’s proposed claims 8-13 are invalid over Morley, which
`
`discloses an identifier that identifies a type of data in the payload and a
`
`transmission characteristic of the data. Morley discloses using a header to identify
`
`the type of information conveyed in the payload for the reasons set forth in my
`
`original Declaration. (Ex. 1009). In addition, Morley discloses identifying a
`
`transmission characteristic of the service because Morley discloses using the
`
`header to determine the rate – a transmission characteristic – at which to process
`
`the received data.
`
`Morley in view of Raith Renders Obvious Claims 8-13
`
`6. Morley discloses that the “format of the mux frame may need to
`
`change according to the particular characteristics of a call.” (Morley at 7:27-29;
`
`Ex. 1002). Morley discloses optimizing the structure of the multiplexer frames
`
`“according to ‘long term’ requirements of the application and protocol layers,”
`
`such as voice coder data rate and frame rate, and data bandwidth requirements.
`
`(Morley at 5:60-64; Ex. 1002). The ‘568 patent explains that bandwidth
`
`considerations are transmission characteristics. (‘568 patent at 2:41-42; Ex. 1001).
`
`
`
`3
`
`

`

`
`
`Therefore a person of ordinary skill in the art would understand that Morley
`
`contemplates changing the format of the mux frame based on transmission
`
`characteristics, such as the voice coder data rate and frame rate, and data
`
`bandwidth requirements.
`
`7.
`
`Raith discloses using a field to identify the type of channel coding to
`
`support a variable channel coding rate. (Raith at 12:15-20; Ex. 1024). Raith
`
`discloses that if errors are detected for a transmission rate and the detected errors
`
`exceed a predetermined threshold level, the degree of channel coding can be
`
`changed for the transmission rate to achieve optimal channel coding. (Raith at
`
`11:54-59; Ex. 1024). To synchronize the base station and mobile station to
`
`changes in the type of channel coding, Raith discloses providing an indication of
`
`the type of channel coding that is being used. (Raith at 12:6-16; Ex. 1024).
`
`8.
`
`Therefore, Morley discloses using the header to identify the contents
`
`of a frame (voice and/or different types of data), and using different types of error
`
`protection for voice and data channels, and in view of Raith’s disclosure of
`
`supporting variable channel coding for different transmission rates it would have
`
`been obvious to modify the header in Morley to indicate different types of channel
`
`coding for the different voice and data channels.
`
`9.
`
`Raith discloses using a variable channel coding rate (Raith at 12:15-
`
`20; Ex. 1024) to transmit different services, such as voice channels, traffic
`
`
`
`4
`
`

`

`
`
`channels, paging/access channels and control channels (Raith at 2:28-31; Ex.
`
`1024). Morley discloses using frame types to indicate whether the contents of a
`
`frame include data from voice and/or different data channels. Morley also
`
`discloses a “Not Defined” frame type 3 that is “reserved for future expansion
`
`where more frame types may be required” (Morley at 7:23-25), and discloses
`
`optimizing the structure of the multiplexer frames “according to ‘long term’
`
`requirements of the application and protocol layers” (Morley at 5:60-64).
`
`10.
`
`It would have therefore been obvious to a person of skill in the art to
`
`use the frame types in Morley to indicate different channel coding rates in addition
`
`to the contents of the frame. Morley discloses using error protection to “ensure
`
`error free data to the protocol and application layers.” (Morley at 8:34-36; Ex.
`
`1002). A person of ordinary skill in the art would have combined Morley with
`
`Raith to achieve the predictable result of improving error protection for Morley’s
`
`packet transmissions. Raith discloses that its variable channel coding technique “is
`
`useful in obtaining an optimal degree of channel coding by weighing the trade-offs
`
`between the amount of channel coding and the number of retransmissions to
`
`achieve the highest throughput.” (Raith at 11:60-65; Ex. 1024). Raith further
`
`discloses that “while the amount of information data is decreased, there is a higher
`
`probability that the information data is being correctly received.” (Raith at 12:1-5;
`
`
`
`5
`
`

`

`
`
`Ex. 1024). Therefore a person of skill in the art would have used Raith’s variable
`
`channel coding to improve error correction in Morley.
`
`11. Further, to the extent that the language “of a service” in claim 8 is
`
`interpreted to require identifying different transmission characteristics for different
`
`services, and Morley’s voice and data channels are not considered to be separate
`
`services, Raith discloses using a variable channel coding rate for different services.
`
`Raith discloses using a variable channel coding rate for services such as circuit-
`
`switched systems (e.g., TIA/EIA/IS-54-B and TIA/EIA/IS-136 systems),
`
`connection-oriented packet-switched systems (e.g., X.25 systems) and
`
`connectionless packet-switched systems (e.g., Internet Protocol systems). (Raith at
`
`6:44-45 and 55-58; Ex. 1024).. Raith further discloses using a variable channel
`
`coding rate for a number of different types of cellular systems such as TDMA
`
`cellular systems (e.g., GSM and Cellular Digital Packet Data (CDPD)), including
`
`those that route voice and/or data packets to a mobile station. (Raith 8:10-12; see
`
`also 7:55-58, 8:32-42 and 8:57-64; Ex. 1024). It would also have been obvious to
`
`a person of skill in the art to apply the known techniques in Morley to identify
`
`different types of known services.
`
`Tiernan Invalidates New Claims 8-13
`
`12. Tiernan discloses a packet-based communication system that includes
`
`an encoder (a processor) that generates an output stream and transmits it over the
`
`
`
`6
`
`

`

`
`
`transmission path to a decoder. (Id. at 5:58-59 and 5:62-64; Ex. 1025). Tiernan
`
`discloses that the syntax of messages in the stream can vary depending on the type
`
`of elementary stream (e.g., video, audio, or VBI elementary streams). (Tiernan at
`
`5:42-43; Ex. 1025).. Tiernan therefore discloses a Message Type that identifies the
`
`type of message, such as:
`
`
`
`(Tiernan at 13:39-58; Ex. 1025). Tiernan discloses that the Message Type “acts as
`
`a selector for the Presentation Layer Entity needed to process the message (e.g.
`
`video, audio, VBI).” (Tiernan at 5:45-47; see also 13:29-32; Ex. 1025).
`
`13. Tiernan discloses that in addition to indicating the contents of the
`
`message (e.g., video, audio), the Message Type indicates presentation layer
`
`processing required for the message, such as MPEG2, ATM, or other transport
`
`services:
`
`To the extent that a message type is present in a Message,
`the Message is self-descriptive regarding the presentation
`layer processing that is required. Since it is possible in
`the future that PESs may be processed by transport
`services having a non-MPEG2 structure, such as ATM,
`and may even be processed in isolation from other
`
`
`
`7
`
`

`

`
`
`elementary streams, Messages should be self-descriptive
`With respect to presentation layer parameters, Where
`possible.
` (Tiernan at 5:48-55 (emphasis added); Ex. 1025).
`
`14. Tiernan therefore discloses an encoder (a processor) that generates
`
`and transmits messages that include a Message Type to identify the contents of the
`
`message (e.g., video, audio, or VBI) in addition to using such information to
`
`identify the transport service, such as MPEG2 or ATM, and/or other processing
`
`required for the message (i.e., “transmission characteristics”).
`
`15. Tiernan also discloses that different Message Types are used for
`
`different services. Generally, Tiernan defines “a universal messaging syntax
`
`applicable to all types of information, including Internet data streams, VBI data
`
`streams, other types of data streams, as well as MPEG2 video, audio, and control.”
`
`(Tiernan, Abstract; Ex. 1025). Tiernan discloses that the contents of a Message
`
`depend on the type of elementary stream, and that each message is therefore
`
`assigned a Message Type identifying the message syntax. (Tiernan at 5:42-45; Ex.
`
`).Ex. 1025). Tiernan discloses that each elementary stream can consist of “video
`
`and audio, as well as other data.” (Tiernan at 1:22-24; Ex. 1025). Tiernan
`
`discloses that each of the elementary streams may belong to “a single ‘Program’”
`
`or “many programs.” (Tiernan at 1:47-59; Ex. 1025). Tiernan further discloses
`
`
`
`8
`
`

`

`
`
`that each element stream is associated with a unique Data Channel that identifies
`
`an association between the source and a decoder. (Tiernan at 5:24-31; Ex. 1025).
`
`16. Dependent claim 12 recites that the communication station is a base
`
`station, and claim 13 recites that the communication station is a mobile station.
`
`(‘568 at 14:13-16; Ex. 1001). Tiernan discloses a packet-based communication
`
`system, and discloses that the transmission path between the encoder and decoder
`
`shown in FIG. 1 “can be any transmission facility, such as a fiber optic link or a
`
`satellite transmission uplink/downlink.” As set forth in my original declaration, it
`
`is well-known in the art that such satellite communications devices include base
`
`stations. (Bims Decl. at ¶ 76; Ex. 1009). It was known for computer systems to
`
`format, arrange, and send audio, video, and data, and known that such systems
`
`could be mobile, such as with laptop computers. (Bims Decl. at ¶ 77; Ex. 1009).
`
`17.
`
`It would have been obvious to provide a protocol for sending voice,
`
`video, and data to a mobile station, as a mobile station could create multiple types
`
`of content to be sent, and therefore it would have been obvious to provide the
`
`ability to identify what type of data was included in a packet to allow the packet to
`
`be processed appropriately. As I explained in my original declaration, this would
`
`be the use of a known technique (of providing payloads and identifiers) applied to
`
`a known type of device (mobile) to yield the predictable result of allowing the
`
`
`
`9
`
`

`

`
`
`mobile to send content and identify the packets that make up the content. (Bims
`
`Decl. at ¶ 77; Ex. 1009).
`
`Availability for Cross-Examination
`
`18.
`
`In signing this declaration, I recognize that the declaration will be
`
`filed as evidence in a contested case before the Patent Trial and Appeal Board of
`
`the United States Patent and Trademark Office. I also recognize that I may be
`
`subject to cross examination in the case and that cross examination will take place
`
`within the United States. If cross examination is required of me, I will appear for
`
`cross examination within the United States during the time allotted for cross
`
`examination.
`
`Right to Supplement
`
`19.
`
`I reserve the right to supplement my opinions in the future to respond
`
`to any arguments that Patentee raises and to take into account new information as it
`
`becomes available to me.
`
`
`
`10
`
`

`

`
`
`Jurat
`
`20.
`
`I declare that all statements made herein of my own knowledge are
`
`true and that all statements made on information and belief are believed to be true;
`
`and further that these statements were made with the knowledge that willful false
`
`statements and the like so made are punishable by fine or imprisonment, or both,
`
`under Section 1001 of Title 18 of the United States Code.
`
`
`
`Dated: October 1, 2014
`
`_________________________________
`Harry Bims
`
`
`
`11
`
`

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket