`
`
`IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`PATENT:
`
`
`
`6,772,215
`
`INVENTOR:
`FILED:
`
`
`Bela Rathonyi, et. al.
`March 29, 2000
`
`
`
`
`
`ISSUED: August 3, 2004
`
`METHOD OF MINIMIZING FEEDBACK RESPONSES
`IN ARQ PROTOCOLS
`
`TITLE:
`
`
`
`Mail Stop PATENT BOARD
`Patent Trial and Appeal Board
`U.S. Patent & Trademark Office
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`
`REPLY 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,772,215 as Exhibit 1004. My background is
`
`described in the prior Declaration.
`
`2.
`
` I have been asked for opinions on certain issues relating to a Patent
`
`Owner’s Response by Ericsson Under 37 C.F.R. § 42.120, which I have reviewed.
`
`
`
`
`
`- 1 -
`
`
`
`Seo Anticipates the Challenged Claims of the ’215 Patent
`
`1.
`
`In my original Declaration I explained why Seo anticipates claims 1,
`
`2, 4, 6, 8, 15, 22, 25, 26, 29, 32, 34, 45, 46, 49, 52, and 54 of the ’215 patent.
`
`Below I provide an additional discussion of Seo in reply to Patent Owner’s
`
`Response.
`
`2.
`
`The existence of padding in Seo does not mean messages have a fixed
`
`length. Messages could have one of a number of different possible lengths, but use
`
`padding to align frames so that they have an integer number of octets. For
`
`example, frames could have variable lengths of 8, 16, 32, or 64 octets, and yet bits
`
`of padding (e.g., 4 bits) could be used to align a message to one of these frame
`
`length boundaries. Although the different frame lengths are fixed, the messages
`
`within the frame (excluding the padding) are variable in length. Such a system
`
`would also not be considered fixed length. Seo does not indicate that the NAK
`
`message has a fixed length. The fact that Seo can include different numbers of
`
`bitmaps also indicates variable length.
`
`3.
`
`Even if all the NAK messages in Seo were the same fixed length, it
`
`would not mean that the NAK messages all have the same fields. For example, a
`
`message could use a number of bits to contain an alphanumeric string identifying a
`
`person’s eye color, while a different message could use the same number of bits to
`
`
`
`- 2 -
`
`
`
`contain an integer representing the balance in a person’s bank account. These two
`
`messages may be the same length, but they are unquestionably not the same type.
`
`4.
`
`Seo’s Figure 4 shows a set of possible fields that can be used in
`
`creating a NAK message, but there is no requirement in Seo that all of the fields in
`
`the figure must be used in all types of NAK messages. In fact, Seo’s Figure 4,
`
`columns 5-6, and claims 10-11 describe how different fields “exist” in different
`
`types of NAK messages, as indicated by the value of NAK_TYPE. Fields relating
`
`to NAK_MAP exist when the NAK message is a bitmap type (NAK_TYPE = 01),
`
`and different fields (e.g., FIRST, LAST) exist for the First/Last list type of NAK
`
`message (NAK_TYPE = 00). (Seo at claims 10-11; Ex. 1002).
`
`5.
`
`I read this to mean what is says. When a field exists, it is present in
`
`the NAK message; when a field does not exist, it is not present. This is a common
`
`sense reading of what “exist” means.
`
`6.
`
`I do not believe it would make sense to include unnecessary fields in a
`
`NAK message, such as FIRST and LAST fields in a NAK message of the bitmap
`
`NAK_TYPE, or bitmap fields in a First/Last type of NAK.
`
`7.
`
`I believe that the text of the IS-707 communication standard from
`
`April 1999 (Ex. 1010) provides further confirmation. A person reading the April
`
`1999 IS-707 standard would understand that bitmap fields exist when the NAK is a
`
`bitmap type, and not when the NAK is a list type; and that FIRST and LAST fields
`
`
`
`- 3 -
`
`
`
`exist with the list type of NAK, and not with the bitmap type of NAK. As shown
`
`at page 4-3 of Ex. 1010, when NAK_TYPE is “00”, the FIRST and LAST fields
`
`follow the L_SEQ_HI field, exactly as shown in Seo Figure 4, and when
`
`NAK_TYPE is “01”, the NAK_MAP_Count field follows the L_SEQ_HI field
`
`(and the FIRST and LAST fields do not exist), just as in Seo. Because the type-
`
`specific fields only exist for their particular type of NAK message, Seo discloses a
`
`type identifier field, even under Patent Owner’s unsupported claim construction.
`
`8.
`
`Even if the Board were to conclude (1) that padding means fixed
`
`length (even though I believe it does not), (2) that fixed length means that fields
`
`that “exist” and do “not exist” are both present (even though I do not believe this is
`
`logical), and (3) that Seo always uses the same fields even though there is no
`
`reason to (and which I do not believe is true), a person of ordinary skill would
`
`interpret Seo to disclose two types of NAK messages:
`
`
`
`a first type that has all zeroes in the bitmap-related fields
`
`and non-zero data in the list-related fields; and
`
`
`
`a second type that has all zeroes in the list-related fields
`
`and non-zero data in the bitmap-related fields.
`
`The ’215 patent does not support any special construction of the term “type.” Two
`
`messages would still be considered to be different “types” where the messages are
`
`constrained by a consistently applied set of rules, such that some fields are always
`
`
`
`- 4 -
`
`
`
`zeroes in some circumstances, and other fields are always zeroes in other
`
`circumstances.
`
`9.
`
`The alleged benefit of the ’215 patent is that one type of feedback
`
`response might use fewer bits in some cases, and another type of feedback
`
`response might use fewer bits in other cases. For example, Table 1 shows that a
`
`consecutive run of missing sequence numbers (example 1) is more efficient as a
`
`list; while a non-consecutive set of individual sequence numbers (example 4)
`
`would be more efficient as a bitmap. (’215 Patent at 4:19-29; Ex. 1001). I do not
`
`believe that the benefit of saving bits arises from any alleged distinction of whether
`
`information is in a payload or a header.
`
`10. The ’215 patent refers to its Figures 4-7 as “messages” without
`
`differentiating parts of those messages, such as those fields that include control
`
`information (type) and those fields that contain data content. I believe that the type
`
`field in Figures 4-7 of the ’215 patent contain bits that tell a receiver how to
`
`process the substance of the data that follows, and therefore would be considered
`
`part of a header as opposed to a “payload.”
`
`Availability for Cross-Examination
`
`11.
`
`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
`
`
`
`- 5 -
`
`
`
`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
`
`12.
`
`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.
`
`
`Jurat
`
`13.
`
`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
`
`