Ex Parte Fiallos

Patent Trial and Appeal BoardSep 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