Antonius Driaan Maria. Staring et al.

Patent Trials and Appeals Board

Nov 27, 2019

13379437 - (D) (P.T.A.B. Nov. 27, 2019)

UNITED STATES PATENT AND TRADEMARK OFFICE
UNITED STATES DEPARTMENT OF COMMERCE
United States Patent and Trademark Office
Address: COMMISSIONER FOR PATENTS
P.O. Box 1450
Alexandria, Virginia 22313-1450
www.uspto.gov
APPLICATION NO. FILING DATE FIRST NAMED INVENTOR ATTORNEY DOCKET NO. CONFIRMATION NO.
13/379,437 12/20/2011 Antonius driaan Maria Staring 2009P01228WOUS 2525
24737 7590 11/27/2019
PHILIPS INTELLECTUAL PROPERTY & STANDARDS
465 Columbus Avenue
Suite 340
Valhalla, NY 10595
EXAMINER
OHRI, ROMANI
ART UNIT PAPER NUMBER
2413
NOTIFICATION DATE DELIVERY MODE
11/27/2019 ELECTRONIC
Please find below and/or attached an Office communication concerning this application or proceeding.
The time period for reply, if any, is set in the attached communication.
Notice of the Office communication was sent electronically on above-indicated "Notification Date" to the
following e-mail address(es):
katelyn.mulroy@philips.com
marianne.fox@philips.com
patti.demichele@Philips.com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
BEFORE THE PATENT TRIAL AND APPEAL BOARD
Ex parte ANTONIUS DRIAAN MARIA STARING and
ANDRIES VAN WAGENINGEN
Appeal 2018-007394
Application 13/379,437
Technology Center 2400
Before MAHSHID D. SAADAT, ALLEN R. MacDONALD, and
NABEEL U. KHAN, Administrative Patent Judges.
MacDONALD, Administrative Patent Judge.
DECISION ON APPEAL

STATEMENT OF THE CASE
Pursuant to 35 U.S.C. § 134(a), Appellant1 appeals from the
Examiner’s decision to reject claims 1, 3–8, and 10–12. Claims 2, 9, and
13–17 have been cancelled. We have jurisdiction under 35 U.S.C. § 6(b).
We AFFIRM.

1 We use the word Appellant to refer to “applicant” as defined in 37 C.F.R.
§ 1.42(a). Appellant identifies the real party in interest as Koninklijke
Philips N.V. Appeal Br. 3.
Appeal 2018-007394
Application 13/379,437

2
CLAIMED SUBJECT MATTER
Claim 1 is illustrative of the claimed subject matter (emphasis,
formatting, and bracketed material added):
1. A method of processing a data packet comprising a header part and
a message part in a wireless communication system, said
method comprising:
[A.] receiving, by a receiver from a transmitter, the data packet,
wherein the header part stores a value that indicates
whether a type of the data packet is known or unknown
to the receiver; and
[B.] determining a size of the message part regardless of
whether the type of the data packet is known or unknown
to the receiver, wherein the value stored in the header
part is associated with the size of the message part
according to a look-up table or a formula stored in a
memory of the receiver.
REFERENCES
The prior art relied upon by the Examiner is:
Name Reference Date
Krumel US 2002/0080771 A1 June 27, 2002
Calhoon US 2005/0127868 A1 June 16, 2005
Yagyu US 2005/0243757 A1 Nov. 3, 2005
Yonemoto US 2007/0195767 A1 Aug. 23, 2007
Rajakarunanayake US 2008/0285476 A1 Nov. 20, 2008
Kasralikar US 2009/0003317 A1 Jan. 1, 2009

REJECTION
A.
The Examiner rejects claims 1 and 8 under 35 U.S.C. § 103(a) as
being unpatentable over the combination of Kasralikar and Yagyu. Final
Act. 2–7.
Appeal 2018-007394
Application 13/379,437

3
Appellant separately argues claim 1. Appellant does not present
separate arguments for claim 8. Thus, the rejection of this claim turns on
our decisions as to claim 1. Except for our ultimate decision, we do not
discuss the § 103(a) rejection of claim 8 further herein.
B.
The Examiner rejects claims 3–7 and 10–12 under 35 U.S.C. § 103(a)
as being unpatentable over the combination of Kasralikar and Yagyu in
various combinations with other references. Final Act. 7–15.
Appellant does not present arguments for claims 3–7 and 10–12.
Thus, the rejections of these claims turn on our decision as to claim 1.
Except for our ultimate decision, we do not discuss the § 103(a) rejections of
claims 3–7 and 10–12 further herein.

OPINION
We have reviewed the Examiner’s rejections in light of Appellant’s
arguments that the Examiner has erred.
A.
Appellant raises the following arguments in contending that the
Examiner erred in rejecting claim 1 under 35 U.S.C. § 103(a).
Kasralikar and Yagyu, either alone or in combination, fail to
teach, show or suggest Appellants’ feature of “receiving, by a
receiver from a transmitter, the data packet, wherein the header
part stores a value that indicates whether a type of the data packet
is known or unknown to the receiver,” as recited in claim 1
(emphasis added). More specifically, Kasralikar only describes
MAC header 310 and IP header 320 having prescribed fields
conforming to the IEEE 802.3 standard. . . . None of the fields
in FIG. 3 of Kasralikar are analogous to Appellants’ recited
header part.
Appeal 2018-007394
Application 13/379,437

4
The Examiner, however, maintains his rejection. Allegedly,
fields 311, 312, 314 in FIG. 3, and switch 201 in paragraphs
[0039] and [0055] of Kasralikar disclose the above limitation.
However, none of those fields or the switch store a value that
indicates whether a type of the data packet is known or
unknown to the receiver, as required by Appellants’ claim 1.
In the “Response to Arguments” section of the Final Office
Action, the Examiner refers to Appellants’ disclosure in
paragraph [0018] of the US published application. It is
respectfully submitted that the Examiner is expressly prohibited
from importing limitations from the specification into the
claims and arguing those limitations. Appellants’ claim
language is clear and unambiguous on its face, and there is no
need to refer to the specification to interpret claim terms: it is
believed that the Examiner uses Appellants’ specification for the
sole purpose of reading the claims onto the prior art in this Final
Office Action. Even under the concept of broadest reasonable
interpretation as alleged by the Examiner, Kasralikar is deficient
in teaching, showing or suggesting Appellants’ feature of
“receiving, by a receiver from a transmitter, the data packet,
wherein the header part stores a value that indicates whether a
type of the data packet is known or unknown to the receiver”.
Appeal Br. 8–9 (emphasis added); see also Reply Br. 3.
The Examiner argues that Kasralikar discloses a stored indication
of where the data packet is to be sent such as getting the
information from the header where the packet needs to be sent.
The Examiner then maps this onto “whether a type of the data
packet is known or unknown to the receiver,” as recited in claim
1. An indicator of where the packet needs to be sent, under
Kasralikar, has nothing to do with whether the data packet is
known or unknown to the receiver. Kasralikar merely indicates
where the data packet is to be sent. But under Kasralikar,
although a data packet may be sent, the receiver still has no
indication of whether “a type of the data packet is known or
unknown to the receiver,” as recited in claim 1. An indication of
where to send a packet does not convey any information as to
whether the data packet is known or unknown to the receiver.
Under Kasralikar, a data packet can be sent to a receiver that still
Appeal 2018-007394
Application 13/379,437

5
has no indication of whether the data packet is known or
unknown. In communication systems, data packets are sent and
received by various transmitters and receivers, respectively. The
sending and receiving of data packets has absolutely nothing
to do with whether the type of data packet is known or unknown
to the receiver. Perhaps in some cases the data packet type does
not need to be known by a receiver because it is going to be
forwarded to another node. So it is not true that just because the
data packet is sent to a receiver that the receiver automatically
knows whether the data type is known or unknown. Thus,
Kasralikar fails to disclose that “the header part stores a value
that indicates whether a type of the data packet is known or
unknown to the receiver,” as recited in claim 1.
Appeal Br. 11–12 (emphasis added); see also Reply Br. 2–3.
We are unpersuaded by Appellant’s argument. Kasralikar discloses a
data packet 300 which is received by a switching device for redirection to a
port. See Kasralikar ¶¶ 14, 19, 20, 40. Kasralikar further discloses that the
data packet 300 includes a media access control (MAC) header 310, an
Internet Protocol (IP) header 320, and a payload 340 of data. See id. ¶ 40.
Kasralikar additionally discloses the various fields in MAC header 310 and
IP header 320 are examples of a traffic type of data packet 300 which
determines whether data packet 300 is to be redirected to a redirect port. See
id. ¶ 41. Such fields include, inter alia, a Length/Type field 314 indicating
at least one of a length or a protocol type of payload 340, and an IP
destination address 312 indicating at least one destination to which the data
packet is to be sent. See id. ¶ 40. The structure of data packet 300 is
illustrated in Figure 3 of Kasralikar, reproduced below.
Appeal 2018-007394
Application 13/379,437

6

Figure 3 of Kasralikar illustrates a structure of data packet 300 which is
redirected to a port associated with a network service.
Id., Fig. 3.
As Kasralikar specifically describes that the Length/Type field 314
indicates a known protocol type of data packet 300, and more generally
describes that the fields in MAC header 310 and IP header 320 identify a
known traffic type of data packet 300, Kasralikar teaches header fields that
indicate that the type of data packet 300 is known. Thus, we agree with the
Examiner’s finding that Kasralikar teaches or suggests “wherein the header
part stores a value that indicates whether a type of the data packet is known
or unknown to the receiver,” as recited in claim 1. See Final Act. 3–4; see
also Ans. 3–5.
Appellant’s argument that Kasralikar’s header fields are distinct from
the aforementioned feature of claim 1 is not persuasive, as Appellant’s
Appeal 2018-007394
Application 13/379,437

7
argument fails to persuasively distinguish Kasralikar’s header fields from the
claimed “value [stored in a header part] that indicates whether a type of the
data packet is known or unknown to the receiver.” Further, we do not agree
with Appellant that the Examiner improperly imported limitations from
Appellant’s Specification in rejecting claim 1. Instead, in citing Appellant’s
disclosure, the Examiner found that the disclosed value ranges for the
claimed “value [stored in a header part]” were not recited in claim 1. See
Final Act. 13; see also Ans. 4. Thus, rather than importing the disclosed
value ranges from Appellant’s Specification, the Examiner’s finding makes
clear the scope of the claimed “value [stored in a header part]” is not limited
to the disclosed value ranges. Appellant’s argument does not persuade us of
any error in this finding.
B.
Appellant also raises the following arguments in contending that the
Examiner erred in rejecting claim 1 under 35 U.S.C. § 103(a).
[N]owhere does Kasralikar or Yagyu disclose “wherein the value
stored in the header part is associated with the size of the message
part according to a look-up table or a formula stored in a memory
of the receiver” as recited in Appellants’ claim 1.
The Examiner concedes that “Kasralikar does not disclose the
mechanism of wherein the size of the message part is determined
via a look-up table or a formula stored in a memory of the
receiver.” The Examiner relies on Yagyu to supplement this
deficiency in Kasralikar. In contrast to the Examiner’s assertions,
it is respectfully submitted that Yagyu also fails to teach, show
or suggest Appellants’ feature. According to paragraph [0138]
and FIG. 15 of Yagyu, as relied upon in the Final Office Action,
the packet size is compared with a reference value to determine
the size or length of the payload. Yagyu’s packet size and its
reference value are not analogous to Appellants’ value in a
header part. Clearly, such alleged correspondence between
Appeal 2018-007394
Application 13/379,437

8
Yagyu’s packet tables 57, 58 and Appellants’ look-up table or
formula cannot be reasonably maintained. According to
Appellants’ claims, the same value is used for indicating the
type of a data packet and determining the data packet’s size.
Appeal Br. 9, 10 (emphasis added); see also Reply Br. 4.
According to claim 1, the same value that is used for indicating
the type of a data packet is also used for determining the size of
the data packet. Yagyu describes a packet size determination
unit, which is not revolutionary technology. Data packet sizes are
routinely ascertained in communication systems. In Yagyu and
Kasralikar, there is simply no individual or combined disclosure
of one singular value used for both indicating the type of a data
packet that is used and for determining the size of the data
packet.
Furthermore, Yagyu does not disclose that said value is stored in
a header. For example. Yagyu at paragraph [0047] merely
describes, “FIG. 9A and FIG. 9B illustrate examples of the
format of a packet header having an additional field for storing
the tree ID information or the root bridge address information in
order to identify the currently used transmission tree (emphasis
added).” Yagyu merely describes that a packet header can have
a field for storing tree ID information or root bridge address
information for the express purpose of identifying the currently
used transmission tree. Nowhere does Yagyu disclose a header
with a one value that is used for both determining the size of
the data packet and indicating whether the data type is known
or unknown. No header in Yagyu stores such a value.
Appeal Br. 12–13 (emphasis added); see also Reply Br. 4–5.
We are unpersuaded by Appellant’s argument. Yagyu discloses a
wireless base station 50. See Yagyu ¶ 138. Yagyu further discloses the
wireless base station 50 includes a transmitting and receiving unit 51, a
packet size determination unit 56, a short packet table 57, and a long packet
table 58. See id. The packet size determination unit 56 is configured to
determine the size or length of a packet or the payload of the packet based
Appeal 2018-007394
Application 13/379,437

9
on a prescribed reference value, where the short packet table 57 is used
when the packet size is at or below the prescribed reference value, and the
long packet table is used when the packet size is above the prescribed
reference value. See id. A block diagram of the wireless base station 50 is
illustrated in Figure 15 of Yagyu, reproduced below.

Figure 15 illustrates a block diagram of wireless base station 50.
Id., Fig. 15.
Appeal 2018-007394
Application 13/379,437

10
Thus, Yagyu discloses associating a packet size value with either a
“short” size according to a short packet table or a “long” size according to a
long packet table. Further, as previously described, Kasralikar discloses a
header value associated with a size of a payload of a packet (i.e.,
Length/Type field 314). Because Kasralikar discloses a size value stored in
a header, and as Yagyu teaches associating a packet size value with a size
according to a packet table, we agree with the Examiner’s finding that the
combination of Kasralikar and Yagyu teaches or suggests “wherein the value
stored in the header part is associated with the size of the message part
according to a look-up table or a formula stored in a memory of the
receiver,” as recited in claim 1.
Appellant’s argument that Yagyu does not disclose that the size value
is stored in a header is not persuasive because Kasralikar discloses a size
value (i.e., Length/Type field 314) stored in a header. Further, Appellant’s
argument that Yagyu and Kasralikar, whether considered individually or in
combination, fail to disclose a single value used for both indicating a type of
data packet and determining the size of the data packet is also not persuasive
for at least two reasons. First, contrary to Appellant’s argument, Kasralikar
explicitly discloses that the Length/Type field 314 indicates at least one of a
length or a protocol type of payload 340, and thus, Kasralikar does disclose a
single value used for both indicating a type of data packet and determining a
size of the data packet. Second, notwithstanding the individual teachings of
Kasralikar, the combination of Kasralikar and Yagyu also teaches or
suggests a single value used for both indicating a type of data packet and
determining a size of the data packet. More specifically, as correctly found
by the Examiner, the proposed combination includes the size determination
Appeal 2018-007394
Application 13/379,437

11
technique disclosed in Yagyu within the switching device disclosed in
Kasralikar, so that Kasralikar’ header value, which indicates a type of data
packet, is also utilized to determine a size of the data packet according to a
look-up table as disclosed in Yagyu. See Final Act. 4–5.

CONCLUSION
The Examiner has not erred in rejecting claims 1, 3–8, and 10–12 as
being unpatentable under 35 U.S.C. § 103(a).
The Examiner’s rejection of claims 1, 3–8, and 10–12 and as being
unpatentable under 35 U.S.C. § 103(a) is affirmed.
DECISION SUMMARY
In summary:
Claims
Rejected
35 U.S.C.
§
Reference(s)/Basis Affirmed Reversed
1, 8 103(a) Kasralikar, Yagyu 1, 8
3, 5, 10, 11 103(a) Kasralikar, Yagyu,
Yonemoto
3, 5, 10, 11
4 103(a) Kasralikar, Yagyu,
Yonemoto,
Rajakarunanayake
4
6 103(a) Kasralikar, Yagyu,
Krumel
6
7, 12 103(a) Kasralikar, Yagyu,
Yonemoto, Calhoon
7, 12
Overall
Outcome
1, 3–8, 10–
12

Appeal 2018-007394
Application 13/379,437

12
TIME PERIOD FOR RESPONSE
No time period for taking any subsequent action in connection with
this appeal may be extended under 37 C.F.R. § 1.136(a). See 37 C.F.R.
§ 1.136(a)(1)(iv).
AFFIRMED