Ex Parte GuoDownload PDFPatent Trial and Appeal BoardJan 28, 201512121807 (P.T.A.B. Jan. 28, 2015) Copy Citation 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 Copy with citationCopy as parenthetical citation