Ex Parte Guo

Patent Trial and Appeal Board

Jan 28, 2015

12121807 (P.T.A.B. Jan. 28, 2015)

UNITED STATES PATENT AND TRADEMARK OFFICE
____________

BEFORE THE PATENT TRIAL AND APPEAL BOARD
____________

Ex parte YU-HSUAN GUO
____________

Appeal 2012-010939
Application 12/121,807
Technology Center 2400
____________

Before ROBERT E. NAPPI, JASON V. MORGAN, and ADAM J.
PYONIN, Administrative Patent Judges.

PYONIN, Administrative Patent Judge.

DECISION ON APPEAL
Appellant appeals under 35 U.S.C. § 134(a) from the final rejection of
claims 1–9. We have jurisdiction under 35 U.S.C. § 6(b).
We AFFIRM.

STATEMENT OF THE CASE
Introduction
The invention relates to “a method and apparatus for setting packet
headers in a wireless communications system, and more particularly, to a
method and apparatus for reducing overhead, and preventing a receiver from
wrongly reassembling Service Data Units . . . .” Spec. ¶ 3. Claim 1 is
Appeal 2012-010939
Application 12/121,807

2
representative, reproduced below from the Claims Appendix of the Appeal
Brief:
1. A method for setting a header, having a header extension
type field, of a protocol data unit in a radio link control layer of
a wireless communications system, the header extension type
field originally utilized for indicating if a next octet is data or a
combination of a length indicator and an extension bit, the
method comprising:
configuring a “use of the special value of the header
extension type field” mode; and
setting bits of the header extension type field to indicate
that a last octet of the protocol data unit is a last octet of a
service data unit when the last octet of the protocol data unit is
the last octet of the service data unit and there is no
concatenation of service data units inside the protocol data unit.

The Examiner’s Rejection
The Examiner rejects claims 1–9 under 35 U.S.C. § 102(e) as being
anticipated by Malkamaki (U.S. Patent 7,894,443 B2, Feb. 22, 2011). Ans.
4–6.

ISSUE
Did the Examiner err in rejecting independent claims 1, 4, and 7,
because the claimed “Header Extension Type field is different from [the]
Extension bit” of the prior art? App. Br. 6. We have considered in this
Decision only those arguments Appellant properly raised in the Briefs. Any
arguments that Appellant did not properly make in the Briefs have not been
considered and are deemed to be waived. See 37 C.F.R. § 41.37(c)(1)(vii)
(2011).

Appeal 2012-010939
Application 12/121,807

3
ANALYSIS
We adopt the Examiner’s findings and conclusions as our own, and
we add the following primarily for emphasis. The independent claims
require setting a “header extension type field” to indicate that a last octet of
a Protocol Data Unit (PDU) is a last octet of a Service Data Unit (SDU) and
there is no concatenation of SDUs inside the PDU. See claims 1, 4, and 7.
Appellant argues that Malkamaki does not anticipate the independent claims,
because it “is well known to those of ordinary skill in the art, [that]
Extension bit and Header Extension Type represent two different header
parameters or fields . . . .” App. Br. 6. For support, Appellant quotes the 3G
TS 25.322 V3.1.2 (2000-01) protocol specification, which states, inter alia,
that the “Extension bit (E)” has a length of 1 bit, and the “Header Extension
Type (HE)” has a length of 2 bits. App. Br. 5–6. Based upon this
specification, Appellant argues that “the claim term ‘header extension type
field’ imparts a specific feature in the header, which is the indicating
format of the extended header. An Extension bit, however, indicates if the
next octet will be a length indicator and E bit . . . .” App. Br. 6.
We are not persuaded the Examiner erred in citing the “extension bit
of Malkamaki” (Ans. 5, 7) as anticipating the “header extension type field”
recited in claims 1, 4, and 7. We agree with the Examiner that “the core of
Appellant[’s] argument hinges on how the phrase ‘header extension type
field’ should be interpreted. On page 5 of the brief, Appellant provides a
narrow interpretation of the phrase that is not congruent with the scope of
the claims.” Ans. 7. In particular, Appellant argues that the 3G protocol
specification should be read into the claims, but this protocol specification is
neither claimed nor mentioned explicitly in the application.
Appeal 2012-010939
Application 12/121,807

4
Appellant quotes MPEP 2111.01(III) regarding “the ordinary and
customary meaning” given to claim terms. As further elucidated in the
MPEP, however,
“[w]here no explicit definition for the term “electronic multi-
function card” was given in the specification, this term should
be given its ordinary meaning and broadest reasonable
interpretation; the term should not be limited to the industry
standard definition of credit card where there is no suggestion
that this definition applies to the electronic multi-function card
as claimed.
MPEP 2111.01(III), citing E-Pass Technologies, Inc. v. 3Com Corporation,
343 F.3d 1364. Here, the term “header extension type field” is given no
explicit definition in the specification, and nothing in the specification or the
claims themselves indicates that a person of ordinary skill in the art would
understand the term to be limited by the 3G protocol specification definition.
We do not find error in the Examiner applying a broad but reasonable
definition to the claim terms, which may differ from the 3G protocol
specification provided by Appellant. Ans. 5. “There is no guarantee that a
term is used in the same way in a treatise as it would be by the patentee. In
fact, discrepancies between the patent and treatises are apt to be common
because the patent by its nature describes something novel.” Phillips v.
AWH Corp. 415 F.3d 1303. The Examiner has found that one skilled in the
art would not limit the claim terms to the protocol specification, because
“there is no protocol claimed, no format claimed . . . .” App. Br. 5. Instead,
we agree with the Examiner in giving “the phrase header extension type field
its broadest reasonable interpretation and interpret[ing] it to simply mean an
extension field that has the functionality specified in the claims . . . .” Ans.
7. The Examiner finds that the “Extension bit of Malkamaki is a one-bit
Appeal 2012-010939
Application 12/121,807

5
field in the PDU that has uncontestably the same functionality specified in
the claims . . . .” Ans. 7. We do not find error in the Examiner’s finding,
because Claims 1, 4, and 7 recite “header extension type field,” but do not
differentiate this field from Malkamaki’s disclosed “extension bit,” which
“indicates that the UMD [(unacknowledged mode data)] PDU includes a
complete SDU which is not segmented, concatenated, or padded.” See
Malkamaki col. 4, ll. 35–42.
Thus, we are not persuaded that it “is well known to those of ordinary
skill in the art based on 3GPP protocol specification” (Reply 2) that
Malkamaki does not anticipate independent claims 1, 4, and 7. Applying the
broadest reasonable interpretation of the term, the Examiner interpreted
correctly “header extension type field” to encompass “[t]he Extension bit of
Malkamaki” that has the functionality specified by the claims. Ans. 7.
Accordingly, we sustain the Examiner’s rejection of independent claims 1, 4,
and 7, and dependent claims 2, 3, 5, 6, 8, and 9, which Appellant does not
argue separately. App. Br. 7.

CONCLUSION
For the foregoing reasons, we conclude that the Examiner did not err
in rejecting claims 1–9 under 35 U.S.C. § 102(e).

Appeal 2012-010939
Application 12/121,807

6
DECISION
We affirm the Examiner’s decision to reject claims 1–9.
No time period for taking any subsequent action in connection with
this appeal may be extended under 37 C.F.R. § 1.136(a)(1)(iv).

AFFIRMED

lv