Ex Parte Evans et alDownload PDFPatent Trial and Appeal BoardDec 27, 201612841898 (P.T.A.B. Dec. 27, 2016) Copy Citation 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. 12/841,898 07/22/2010 Nigel Ronald Evans 82251221 2978 56436 7590 12/29/2016 Hewlett Packard Enterprise 3404 E. Harmony Road Mail Stop 79 Fort Collins, CO 80528 EXAMINER HWANG, JOON H ART UNIT PAPER NUMBER 2447 NOTIFICATION DATE DELIVERY MODE 12/29/2016 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): hpe.ip.mail@hpe.com chris. mania @ hpe. com PTOL-90A (Rev. 04/07) UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE PATENT TRIAL AND APPEAL BOARD Ex parte NIGEL RONALD EVANS, RUSSELL IAN MONK, and GARRY BRADY1 Appeal 2015-004731 Application 12/841,898 Technology Center 2400 Before CARL W. WHITEHEAD JR., HUNG H. BUI, and MICHAEL M. BARRY, Administrative Patent Judges. BARRY, Administrative Patent Judge. DECISION ON APPEAL Appellants appeal under 35 U.S.C. § 134(a) from a final rejection of claims 1—5, 7—11, and 13—20, which constitute all of the pending claims. We have jurisdiction under 35 U.S.C. § 6(b). We AFFIRM. 1 Appellants identify Hewlett-Packard Development Company, L.P. as the real party in interest, for which the general or managing partner is HPQ Holdings, LLC, and which is a wholly-owned affiliate of Hewlett-Packard Company. (App. Br. 2.) Appeal 2015-004731 Application 12/841,898 Introduction Appellants disclose a “method of storing data received in a data stream from a data source ... in which prior to performing deduplication on the data stream a processor decompresses selected compressed data entities in the data stream.” (Abstract.) Appellants explain a benefit is that “[bjecause the compressed entities are presented to the deduplication engine in decoded form, there can be a significantly increased probability of obtaining a larger number of matching data chunks during the matching process in many data storage situations . . . .” (Spec. 9 (reference numbers omitted).) Claim 1 is illustrative: 1. Data deduplication apparatus for storing data received in a data stream from a data source, the apparatus stored as machine readable instructions on a non-transient computer readable medium executable by a processor, the apparatus comprising: a command handler operable, in response to a write command, to remove command meta data from the data stream to provide a stripped data stream including both non-encoded data entities and encoded data entities; an encoded entity handler operable, in response to the write command, to: receive the stripped data stream from the command handler; identify, in the stripped data stream, encoded entity meta data associated with an encoded data entity, the encoded entity meta data relating to an encoding process that has been used to encode the encoded data entity; use the encoded entity meta data to decode the encoded data entity to provide a decoded form of the encoded data entity: and 2 Appeal 2015-004731 Application 12/841,898 substitute said decoded form of the encoded data entity for the encoded form of the encoded data entity in the stripped data stream; remove the encoded entity meta data from the stripped data stream; and a deduplication engine to: perform deduplication on the stripped data stream including at least one said decoded data entity to provide deduplicated data; and store the deduplicated data to a deduplicated data store; the encoded entity handler operable, in response to the a read request [sic2], to assemble the deduplicated data into compressed entities with associated encoded entity meta data to provide a processed data stream; and the command handler operable, in response to the read request, to reinsert command meta data into the processed data stream. (App. Br. 13 (Claims App’x).) Rejections3 Claims 1—5, 7—11, and 13—20 stand rejected under 35 U.S.C. § 103(a) as obvious over Stoakes et al. (US 2010/0077161 Al; Mar. 25, 2010) (“Stoakes”), Van Maren et al. (US 5,280,600; Jan. 18, 1994) (“Van Maren”), and Khu (US 7,071,848 Bl; July 4, 2006). (Final Act. 12-34.) 2 We note the Examiner objects to “the a read request” as an informality, which requires appropriate correction (Final Act. 10-11). 3 At the time of appeal, claims 13—17 were rejected under 35 U.S.C. § 101 as directed to non-statutory subject matter (Final Act. 12). The Examiner subsequently withdrew the § 101 rejection (Ans. 2). 3 Appeal 2015-004731 Application 12/841,898 ANALYSIS We have reviewed the Examiner’s rejections in light of Appellants’ contentions of reversible error. We disagree with Appellants’ conclusions. Unless noted otherwise below, we adopt the Examiner’s findings and reasons as set forth in the Final Rejection from which this appeal is taken and as set forth in the Answer. We highlight the following for emphasis. Claim 1 Appellants argue the Examiner errs in rejecting claim 1 because the combination of Van Maren and Stoakes does not “disclose the stripped data stream including both non-encoded data entities and encoded data entities.” (App. Br. 8.) The Examiner responds that in Stoakes, “the delimitated backup stream 125 ([0025]), teaches ‘a stripped data stream’” (Ans. 26), and that “Stoakes’ compressed data discloses .. . ‘encoded data entities’” {id. at 27), and “[t]hus, Stoakes’ user data (e.g., compressed, uncompressed, or other file type information) (12th-16th lines of 1 [0040]), teaches the ‘data stream including both non-encoded data entities and encoded data entities’” {id.). We agree with the Examiner that Stoakes’ “delimitated backup stream,” created by removing “application metadata” from a backup stream, which includes removing metadata of the backup application that corresponds to the recited “command meta data” {see ^fl[ 21—25), teaches the recited “stripped data stream.” {See Ans. 26.) We further agree that in Stoakes 140, the “user data” in the delimitated backup stream, which may be compressed or non-compressed, teaches that the stripped data stream includes the recited “non-encoded data entities and encoded data entities.” {See Ans. 27.) 4 Appeal 2015-004731 Application 12/841,898 We find unpersuasive Appellants’ argument in reply, that “the Answer is inconsistent with the rejection of the claim as a whole” because “Stoakes says nothing about the electronic mail ‘application metadata’ (i.e., the encoded entity meta data, as asserted by the Office Action) being related to a data compression process (i.e., the encoding process, as asserted by the Answer) that has been used to compress the compressed data (i.e., the encoded data entity, as asserted by the Answer).” (Reply Br. 3 (citing Final Act. 14 (citing Stoakes 22, 24)).) The Examiner identifies electronic mail metadata as an example of the claimed “encoded entity meta data” in backup stream 115 of Stoakes. (Final Act. 14.) The Examiner also identifies the metadata examples of information for “compressed, uncompressed, or other file type information,” which Stoakes explains provide information so that “user data are treated in a particular manner during data de-duplication of . . . backup stream 115.” (Stoakes 140.) We find these examples in Stoakes support the Examiner’s finding that its delimitated backup stream teaches the recited stripped data stream with both encoded and non-encoded entities. We also find that an ordinarily skilled artisan would have understood that electronic mail routinely includes data that is compressed or encoded, such as image or video file attachments. Appellants also argue the Examiner errs in finding Stoakes teaches “the claim recitation of the command handler operable, in response to the read request, to reinsert command meta data into the processed data stream.'1'’ (App. Br. 8.) The Examiner responds, and we agree, that “Stoakes’ reconstruction of a backup stream to re-incorporate removed application metadata (13th— 17th lines of 1 [0025]), teaches ‘to reinsert command meta data into the processed data stream’.” (Ans. 29.) 5 Appeal 2015-004731 Application 12/841,898 Appellants also contend in Reply that “the Examiner has apparently equated the same prior art element (i.e., the ‘application metadata’ of Stoakes) to two distinct elements of the claims (i.e., the command meta data and the encoded entity meta data), which is improper.” (Reply Br. 4.) Appellants further respond that “Stoakes describes something substantially different, namely that ‘[d]ata stream editor 234 automatically edits a data stream, such as backup stream 115, to remove any identified application metadata, such as backup application metadata and/or non-backup application metadata.’” {Id. at 5 (quoting Stoakes 142).) Certainly Stoakes (142) teaches removal of any or all application metadata, including removal of metadata from the backup application that corresponds to the recited “command meta data.” Appellants do not persuade us, however, that this negates Stoakes’ teaching of the “proper reconstruction of a backup stream to re-incorporate removed application metadata” (125). Accordingly, we agree with the Examiner’s finding that Stoakes teaches reinserting metadata of the backup application (“command meta data”) in response to a read request as recited. (See Ans. 28—30.) Accordingly, we sustain the Examiner’s rejection of claim 1, and its respective dependent claims 2—5, 7, 13—18, and 20, which Appellants do not argue separately. Claim 8 Appellants argue the Examiner errs in rejecting independent claim 8 because “Stoakes does not teach removing both command meta data and encoded entity meta data prior to performing deduplication” as recited. (App. Br. 10.) We find Appellants’argument unpersuasive. Stoakes’ “backup application metadata” (121) corresponds to the recited “command 6 Appeal 2015-004731 Application 12/841,898 meta data” and “other application metadata” (122) corresponds to the recited “encoded entity meta data.” We agree with the Examiner’s finding that Stoakes teaches removal of both types of metadata prior to de- duplication (| 25). (See Final Act. 21; see also discussion of claim 1 supra.) We accordingly sustain the rejection of claim 8, and along with it the rejection of claims 9 and 11, for which Appellants offer no separate substantive arguments. Claims 10 and 19 Claim 10 depends from claim 8, and further requires “removing both the command meta data and the encoded entity meta data from the data stream, and storing the command meta data and the encoded entity meta data store for access when required during a read operation.” Appellants contend claim 10’s requirement for removing metadata from the data stream “is even more explicit than claim 8 in this regard,” arguing the Examiner errs in rejecting claim 10 for the same reasons as for claim 8. (App. Br. 10.) We again agree with the Examiner. As discussed supra, Stoakes discloses (1) removing both the backup application metadata (“command meta data”) and other application metadata (including “encoded entity meta data”) (see, e.g., 142; see also 21—25), and (2) “re-incorporat[ing] removed application metadata” (125) (which necessarily entails storing the removed metadata prior to its reincorporation (i.e., for use in read operations)). We accordingly sustain the rejection of claim 10. Claim 19 depends from claim 1, and further recites “wherein the encoded entity handler is further operable to perform checks for expected 7 Appeal 2015-004731 Application 12/841,898 value ranges in other expected fields in a file header to prevent misdetection.” Appellants argue the Examiner errs in rejecting claim 19, contending Van Maren’s disclosure of “obtaining the number of compressed records from the header portion and a zero algorithm number in the header indicating the start of a new dictionary” fails to teach “check[ing] for expected value ranges in other expected fields in a file header to prevent misdetection” as recited. (App. Br. 9-10 (emphasis omitted); see also Final Act. 33 (citing Van Maren 21:11—21, 13:7—26).) The Examiner responds by finding “Van Maren’s disclosure that the number of compressed records in the entity is obtained from the header portion enabling a record count down to be performed” (col 21 11 18-20), teaches ‘to perform checks for expected value ranges in other expected fields in a file header to prevent misdetection’.” (Ans. 30.) We agree with the Examiner, noting Van Maren’s disclosure of “[t]he algorithm number in the header portion is checked for consistency with the algorithm used by the [data compression] processor” (21:15—17 (emphasis added)) teaches checking for a range of algorithm numbers that are compatible. We accordingly sustain the rejection of claim 19. DECISION For the above reasons, we affirm the rejection of claims 1—5, 7—11, and 13—20. No time period for taking any subsequent action in connection with this appeal may be extended under 37 C.F.R. § 1.136(a)(l)(iv). AFFIRMED 8 Copy with citationCopy as parenthetical citation