Ex Parte Fiallos

Patent Trial and Appeal Board

Sep 26, 2012

09948976 (P.T.A.B. Sep. 26, 2012)

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.
09/948,976 09/07/2001 Rosario Fiallos PD-201016A 8353
20991 7590 09/27/2012
THE DIRECTV GROUP, INC.
PATENT DOCKET ADMINISTRATION
CA / LA1 / A109
2230 E. IMPERIAL HIGHWAY
EL SEGUNDO, CA 90245
EXAMINER
HOSSAIN, FARZANA E
ART UNIT PAPER NUMBER
2424
MAIL DATE DELIVERY MODE
09/27/2012 PAPER
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.
PTOL-90A (Rev. 04/07)

UNITED STATES PATENT AND TRADEMARK OFFICE
____________

BEFORE THE PATENT TRIAL AND APPEAL BOARD
____________

Ex parte ROSARIO FIALLOS
____________

Appeal 2011-009526
Application 09/948,976
Technology Center 2400
____________

Before THOMAS S. HAHN, CARL W. WHITEHEAD, JR., and
ANDREW J. DILLON, Administrative Patent Judges.

WHITEHEAD, JR., Administrative Patent Judge.

DECISION ON APPEAL
Appeal 2011-009526
Application 09/948,976

2
STATEMENT OF THE CASE
Appellant is appealing claims 31-48. Appeal Brief 2-3. We have
jurisdiction under 35 U.S.C. § 6(b) (2002).
We affirm.

Introduction
The invention is directed to “a method for automatically generating a
software download command for upgrading integrated receiver/decoders
(IRDs) in a communication network.” Appeal Brief 3 (element numbers
omitted).

Illustrative Claim
31. A method for automatically generating a software
download command for upgrading integrated receiver/decoders
(IRDs) in a communication network, comprising:

providing a plurality of input files created on a plurality
of different software operating system platforms, the plurality
of input files comprising IRD software upgrade data, IRD
private manufacturer data, and IRD public upgrade parameters
for a target IRD;

creating a unique script from the plurality of input files
created on the plurality of different software operating system
platforms using a single software operating system platform,
wherein at least one of the plurality of different software
operating system platforms is different than the single software
operating system platform;

executing the unique script at a broadcast center by
automatically reading the IRD private manufacturer data and
the IRD public upgrade parameters from the input files to
Appeal 2011-009526
Application 09/948,976

3
generate a unique software download command for the target
IRD;

broadcasting at least one data packet containing the
software download command from the broadcast center over
the communication network to a plurality of IRDs as an
upgrade announcement; and

broadcasting data packets containing the IRD software
upgrade data from the broadcast center over the
communications network to the plurality of IRDs, wherein the
plurality of IRDs includes the target IRD.

Rejections on Appeal
Claims 31-34 and 39 stand rejected under 35 U.S.C. § 103(a) as being
unpatentable over Prus (U.S. Patent Application Publication Number
2005/0144651 A1; published June 30, 2005) and Eatough (U.S. Patent
Application Publication Number 2004/0139430 A1; published July 15,
2004). Answer 3-8.
Claim 35 stands rejected under 35 U.S.C. § 103(a) as being
unpatentable over Prus, Eatough, and Nelson (U.S. Patent Number
5,778,390; issued July 7, 1998). Answer 8-9.
Claim 36 stands rejected under 35 U.S.C. § 103(a) as being
unpatentable over Prus, Eatough, and Kato (U.S. Patent Number 6,470,496
B1; issued October 22, 2002). Answer 10.
Claim 37 stands rejected under 35 U.S.C. § 103(a) as being
unpatentable over Prus, Eatough, Kato, Ono (U.S. Patent Application
Publication Number 2003/0110483 A1; published June 12, 2003), and
Chaney (U.S. Patent Application Publication Number 2006/0075434 A1;
published April 6, 2006). Answer 10-12.
Appeal 2011-009526
Application 09/948,976

4
Claim 38 stands rejected under 35 U.S.C. § 103(a) as being
unpatentable over Prus, Eatough, and Saib (U.S. Patent Number 6,049,830;
issued April 11, 2000). Answer 12-13.
Claims 40-42 stand rejected under 35 U.S.C. § 103(a) as being
unpatentable over Prus, Eatough, and Ono. Answer 13-15.
Claims 43 and 44 stand rejected under 35 U.S.C. § 103(a) as being
unpatentable over Pros, Eatough, Ono, and Kato. Answer 15-18.
Claims 45 and 48 stand rejected under 35 U.S.C. § 103(a) as being
unpatentable over Prus, Eatough, Ono, and Chaney. Answer 18-25.
Claim 46 stands rejected under 35 U.S.C. § 103(a) as being
unpatentable over Kato, Ono, Chaney, Prus, Eatough, and Nelson. Answer
26-27.
Claim 47 stands rejected under 35 U.S.C. § 103(a) as being
unpatentable over Kato, Prus, Eatough, Ono, Chaney, and Saib. Answer 27.

Issue on Appeal
Do Prus and Eatough, either separately or in combination, teach or
suggest “a] method for automatically generating a software download
command for upgrading IRDs] in a communications network,” as recited in
claim 31.

ANALYSIS
Claims 31-37, 39-46, and 48
We disagree with Appellant’s assertions regarding the Examiner’s
rejection of the claims on appeal. We adopt as our own (1) the findings and
Appeal 2011-009526
Application 09/948,976

5
reasons set forth by the Examiner in the action from which this appeal is
taken and (2) the reasons set forth by the Examiner in the Examiner’s
Answer (Answer 3-27) in response to arguments made in Appellant’s
Appeal Brief. We concur with the conclusions reached by the Examiner.
We highlight and address certain findings and arguments below.
Appellant argues that Prus does not teach the claimed target IRD
“because Prus teaches a hardware ID range with a MAC address for a
specific manufacturer.” Appeal Brief 9. Appellant contends that:
“Nowhere does Prus make any attempt to show that the MAC address is
unique to a specific receiver; instead, the MAC address is unique to a
specific manufacturer.” Id. Subsequently, “every receiver made by a
given manufacturer has the same MAC address, or at best, has a range of
identities for specific models made by that manufacturer.” Id. Appellant
concludes:
Thus, any attempt to upgrade software in a Prus system
would upgrade software for a large plurality of receivers,
either every receiver made by a given manufacturer or a
specific model made by a given manufacturer, not a single,
target ID receiver as in the present invention. Prus does
not and cannot teach this limitation because Prus does not
teach or suggest the granularity required to perform such a
task.
Id.
The Examiner finds that
Prus discloses a target IRD as hardware ID range with a
MAC address for a specific manufacturer provides only
specific IRD to receive a specific download command
(Page 3, paragraph 0028, Pages 4-6, paragraphs 0039,
0040, Table 1 - see lines 10, 31-32 of Page 5). The claim
Appeal 2011-009526
Application 09/948,976

6
does not state that the there has to be a unique ID for a
target IRD. The claim recites a target IRD.
Answer 28-29.
Therefore we do not find Appellant’s arguments to be persuasive. We
agree with the Examiner’s findings. Appellant’s arguments are not
commensurate with the scope of the claims; the claims do not recite that
there is a unique ID for a target IRD. Therefore the claim limitation reads
upon Prus’ “target IRD.” See Answer, 29.
Appellant argues that all of the searching, identification of the
receiver in Prus is being done at the receiver and there are no automatic
readings of hardware ID numbers being done by the broadcast center in
Prus. Appeal Brief 10. However, Prus discloses that a message is broadcast
continually to ensure that all settop receivers in the system have the
appropriate operating system/control program version. Prus, paragraph
[0055]. Prus further discloses that, “[t]his broadcast message could also be
sent individually to any settop receiver in the system.” Id. Therefore we do
not find Appellant’s arguments to be persuasive because Prus discloses
“automatic readings” of hardware ID numbers.
Appellant also argues that “[t]here is nothing in Prus that teaches
headend 101 reading the MAC address or any other data.” Appeal Brief 11
(underline omitted).
However, the Examiner finds:
Prus discloses that the digital network control
system (DNCS) at the headend creates and maintains a
code version table, which is transmitted from the headend
or broadcast center, which uses the OEM sub tables or
IRD private manufacturer data and the IRD public upgrade
parameters to generate the software download command
Appeal 2011-009526
Application 09/948,976

7
for the target IRD (Page 9, paragraph 0055, Page 3,
paragraph 0028, Pages 4-6, paragraphs 0039, 0040, Table
1). Microsoft Press Computer Dictionary (3rd Edition)
defines script as a program consisting of a set of
instructions to an application or utility program. Merriam-
Webster’s 10th edition Collegiate Dictionary defines create
as to produce or bring about by course of action.
Therefore, it is necessarily included to use a software
platform to create and execute a script at a broadcast
center that automatically reads the IRD private
manufacturer data and the IRD public upgrade parameters
from the input files to generate a software download
command for the target IRD. It is inherent that the DNCS
uses a set of instructions to perform the creation of the
Code Version Table (CVT) and therefore the process
causes instructions to be or become for execution. Prus
discloses uses the OEM sub tables or IRD private
manufacturer data and the IRD public upgrade parameters
(upgrade data including versions of the CVT) to generate
the software download command for the target IRD (Page
9, paragraph 0055, Page 3, paragraph 0028, Pages 4-6,
paragraphs 0039, 0040, Table 1 ).

Answer 29.
We agree with the Examiner’s findings that Prus discloses reading the
IRD private manufacturer data and the IRD public upgrade parameters to
generate software download commands for a target IRD and therefore we
are not persuaded of Examiner’s error.
Appellant argues that Eatough does not address the deficiencies of
Prus. Appeal Brief 12-13. Specifically, Appellant argues that “nowhere
does Eatough teach combination of vendor-specific files into script or using
a single software operating platform to execute that script.” Appeal Brief
13.
Appeal 2011-009526
Application 09/948,976

8
The Examiner finds:
Eatough discloses a single software operating system
platform (Page 1, paragraph 0013) as the server is a
system that offers capability to support multiple operating
systems and X packages are designed to use a script that is
supported on multiple operating systems that can be
processed. Eatough discloses the files are created on
different software operating system platforms and using a
single software operating system platform to create and
execute a script or as vendors are packaging files in
different software platforms based on different operating
systems such as Linux (via LANDESK Management Suite
or Red Hat Package Manager) and Windows (Microsoft
Windows Installer) and that the multiple vendor package
management system provides management means to
managing different operating systems by importing the
software package to create a new package document for
upgrades (Page 1, paragraphs 0010-0016, specifically
0013, Page 2, paragraph 0026).
Answer 30-31.
We agree with the Examiner’s findings that Eatough discloses vendor
specific files and we are not persuaded by Appellant’s arguments that the
Examiner erred in combining Prus and Eatough to establish a prima facie
case of obviousness in regard to independent claim 31.
Therefore we sustain the Examiner’s rejection of independent claim
31 as well as independent claim 45 not argued separately. See Appeal Brief
9. We sustain the Examiner’s rejections of dependent claims 32-37, 39-44,
46 and 48 not argued separately. Id at 14.
Dependent Claims 38 and 47
Appellant argues that claims 38 and 47 are distinguishable over the
combination of Prus, Eatough, and Saib because:
Appeal 2011-009526
Application 09/948,976

9
Saib teaches that a receiver can be grouped by
geographic location. This characterization of Saib
suggests that there is a priori knowledge of the
geographical location of each and every receiver in a
system such that groups can be created. However, if a
receiver is moved from one location to another, which
action is often performed without reporting to the system
operator, such receivers would not be locatable in Saib or
in combination with Prus and Eatough which say nothing
about geographical location.
Appeal Brief 15.
Claim 38 is reproduced in its entirety:
38. The method of claim 31, wherein the IRD public
upgrade parameters further comprises a target geographical
location containing the target IRDs which are to receive the
IRD software upgrade data.

Appellant argues that Saib is not properly combinable with
Prus and Eatough because there is a suggestion of a priori
knowledge of the geographical location of each receiver. Appeal
Brief 15. We do not find Appellant’s arguments to be persuasive
because the scope of the claim does not eliminate a priori
knowledge of the location. Claim 37 only requires a location.
Further, Appellant argues that if Saib’s receiver is moved from its
original location that it would not be locatable. See Appeal Brief
15. Appellant’s arguments are not commensurate with the scope of
the claim because the claim does not recite a geographical locator
only a location. Therefore we are not persuaded of Examiner’s
error and we sustain the Examiner’s rejections of claims 38 and 47
argued together. See Appeal Brief 14-15.
Appeal 2011-009526
Application 09/948,976

10
DECISION
The rejections of claims 31-48 are affirmed.
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). See 37
C.F.R. § 41.50(f).

AFFIRMED

llw