2021004036 (P.T.A.B. Sep. 15, 2021)

PERSONALWEB TECHNOLOGIES, LLC (ASSIGNEE) et al.

Patent Trials and Appeals BoardSep 15, 2021

2021004036 (P.T.A.B. Sep. 15, 2021)

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. 90/014,334 07/10/2019 7949662 337722-000153B 3133 23117 7590 09/15/2021 NIXON & VANDERHYE, PC 901 NORTH GLEBE ROAD, 11TH FLOOR ARLINGTON, VA 22203 EXAMINER WOOD, WILLIAM H ART UNIT PAPER NUMBER 3992 MAIL DATE DELIVERY MODE 09/15/2021 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) Appeal 2021-004036 Reexamination Control 90/014,334 Patent 7,949,662 B2 1 UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE PATENT TRIAL AND APPEAL BOARD Ex parte PERSONALWEB TECHNOLOGIES LLC Patent Owner and Appellant Appeal 2021-004036 Reexamination Control 90/014,334 Patent 7,949,662 B2 Technology Center 3900 Before KEVIN F. TURNER, BRADLEY W. BAUMEISTER, and MICHAEL J. ENGLE, Administrative Patent Judges. ENGLE, Administrative Patent Judge. DECISION ON APPEAL STATEMENT OF THE CASE Pursuant to 35 U.S.C. §§ 134(b) and 306, Appellant1 appeals from the Examiner’s rejection of claims 1–24, 26–29, and 31–35 of US 7,949,662 B2 (“the ’662 patent”). Claims 25 and 30 were previously cancelled. A hearing was held on August 11, 2021. We have jurisdiction under 35 U.S.C. § 6(b). We affirm in part. 1 Appellant identifies the real parties in interest as PersonalWeb Technologies, LLC and Level 3 Communications, LLC. Appeal Br. 1. Appeal 2021-004036 Reexamination Control 90/014,334 Patent 7,949,662 B2 2 TECHNOLOGY The application relates to “deleting a particular copy of a data item when at least one other copy of the data item is available.” ’662 Patent, Abstract. ILLUSTRATIVE CLAIM Claim 1 is illustrative and reproduced below with certain limitations at issue emphasized: 1. A computer-implemented method of eliminating a particular data item at a given storage location in a distributed file system when a copy of said particular data item can be obtained from at least one other storage location in the file system, wherein said file system comprises (i) a plurality of distinct storage locations, and (ii) at least one computer distinct from said plurality of storage locations, and (iii) at least one database, and wherein each data item in the file system is stored at multiple distinct storage locations in the file system, based, at least in part, on a predetermined degree of redundancy for said file system, and wherein said at least one database comprises mapping data that identifies where data items are stored in the file system, and wherein the file system further includes a table including a plurality of records indicating changes made to said file system, said table being accessible by said at least one computer, the method comprising the steps of: (A) obtaining, at said at least one computer, a request to delete a particular data item from said given storage location; and (B) based on the request, ascertaining a particular substantially unique data identifier for the particular data item, wherein said particular data item consists of a particular sequence of bits and wherein said particular data identifier is based, at least in part, on a given function of all of the bits in the particular sequence of bits of the particular data item; and Appeal 2021-004036 Reexamination Control 90/014,334 Patent 7,949,662 B2 3 (C) determining, using at least said particular substantially unique data identifier for the particular data item, whether deletion of said particular data item from said given storage location will leave a sufficient number of copies of said data item present at one or more other storage locations in the file system to satisfy said predetermined degree of redundancy for said file system with respect to that particular data item; and (D) based at least in part on said determining, if it is determined that deletion of the particular data item from the given storage location will leave at least a sufficient number of copies of said data item at one or more other storage locations in said file system to satisfy said predetermined degree of redundancy for said file system with respect to that particular data item, then (d1) adding an entry to said table to indicate deletion of said particular file from the given storage location in the file system, said entry including said particular substantially unique identifier for said particular data item. REFERENCES The Examiner relies on the following references, though as discussed below, Appellant challenges whether Kantor qualifies as prior art: Name Title Date Kantor FWKCS(TM) Contents_Signature System, Version 1.22 Aug. 10, 1993 Langer Re: dl/describe (File descriptions) posted to alt.sources Aug. 7, 1991 Satyanarayanan Coda: A Highly Available File System for a Distributed Workstation Environment, 39 IEEE Transactions on Computers 447 April 1990 Woodhill US 5,649,196 July 15, 1997 Kantor Kantor describes a software system to detect duplicate or near- duplicate files uploaded to an electronic bulletin board system (“BBS”). Appeal 2021-004036 Reexamination Control 90/014,334 Patent 7,949,662 B2 4 Kantor at Preface. A BBS in the 1980s might reward its users for uploading files by giving time credit, but this resulted in an “unanswered problem” of people cheating the system by uploading duplicate or near-duplicate files. Id. For example, people might “change the name of a file”; put existing files in a zipfile; “change the order in which the files appeared in a [zip] library”; or add “padding” to a file such as a spurious “tail.” Id. at Preface, 9. Kantor solves this problem by using a “contents signature” (“cs”) or “zipfile contents signature” (“zcs”) to identify files. Kantor 5–6. The contents signature consists of a 32-bit Cyclic Redundancy Check (“CRC”) together with the uncompressed file length. Id. at 8. The zipfile contents signature is based on a summation of the 32-bit CRC of each file within the zip library followed by a summation of the uncompressed file length of each file. Id. at 9. If certain options are enabled, the system can delete or ignore “tails” on GIF files before calculating the “cs” value. Id. Similarly, the “zcs” value “does not depend on the names of the files, the dates of the files, the order in which they appear in the zipfile, nor on the method nor amount of compression, nor does it depend on comments.” Id. Because of this, duplicate or near duplicate files may have the same contents signature. Thus, when a file is uploaded to a BBS, its “cs” or “zcs” value is compared to those of previous uploads, and any duplicate or undesired files can either be “deleted” or “set aside in a subdirectory.” Id. at 5. Woodhill “Woodhill discloses a distributed management system for backing up and restoring data files.” Pers. Web Techs., LLC v. Apple, Inc., 917 F.3d 1376, 1379 (Fed. Cir. 2019) (citing Woodhill 1:1–17). Appeal 2021-004036 Reexamination Control 90/014,334 Patent 7,949,662 B2 5 Satyanarayanan “Satyanarayanan discloses a network-based file replication system, where copies of files are stored at multiple servers.” EMC Corp. v. PersonalWeb Techs., LLC, IPR2013-00086, Paper 66, at 10 (May 15, 2014) (citing Satyanarayanan Abstract); see also Satyanarayanan 448. REJECTIONS The Examiner makes the following rejections under 35 U.S.C. § 103: Claims Basis Final Act. 1, 3–18, 20–24, 26–28, 31–35 Kantor, Satyanarayanan, Woodhill 4–39 2, 19, 29 Kantor, Satyanarayanan, Woodhill, Langer 39–40 PRIOR PROCEEDINGS This is an ex parte reexamination of the ’662 patent, which issued from U.S. Application No. 10/742,972 (“the ’972 application”). The ’972 application was filed on December 23, 2003, and through a series of continuation and divisional applications, it claims priority to April 11, 1995. Thus, the ’662 patent is now expired. The patent family has been involved in numerous proceedings before federal district courts, the Patent Trial and Appeal Board (“PTAB”), and the Court of Appeals for the Federal Circuit. Appeal Br. 2–14 (listing more than 160 cases in E.D. Tex., N.D. Cal., S.D.N.Y., and D. Del.). In district court, at least the Eastern District of Texas and the Northern District of California have issued claim construction orders. E.g., PersonalWeb Techs., LLC v. Microsoft Corp., No. 6:12-CV-663, 2013 WL 4035358 (E.D. Tex. Aug. 6, 2013); In re PersonalWeb Techs., LLC Patent Litig., No. 18-md-02834, 2019 WL 3859023 (N.D. Cal. Aug. 16, 2019). Appeal 2021-004036 Reexamination Control 90/014,334 Patent 7,949,662 B2 6 In 2020, a California court granted the defendants’ motion for judgment on the pleadings holding certain claims—including claim 33 of the ’662 patent—were directed to patent-ineligible subject matter under 35 U.S.C. § 101. PersonalWeb Techs. LLC v. Google LLC, No. 5:13-CV- 01317-EJD, 2020 WL 520618 (N.D. Cal. Jan. 31, 2020). The Federal Circuit affirmed that decision. PersonalWeb Techs. LLC v. Google LLC, No. 2020-1543, 2021 WL 3556889, __ F.4th __ (Fed. Cir. Aug. 12, 2021). Meanwhile, some defendants or other third parties filed requests for ex parte reexamination or petitions for inter partes review against the patent family. In addition to the art relied on in this case (Kantor, Satyanarayanan,2 Woodhill, and Langer), those proceedings relied on the following art: Name Number Issue Date Brunk US 7,289,643 B2 Oct. 30, 2007 Dan US 6,223,206 B1 Apr. 24, 2001 Farber3 WO 96/32685 Oct. 17, 1996 Fischer US 5,475,826 Dec. 12, 1995 Francisco US 4,845,715 July 4, 1989 Gramlich US 5,202,982 Apr. 13, 1993 Hellman US 4,658,093 Apr. 14, 1987 Kahn US 6,135,646 Oct. 24, 2000 Ross US 5,553,143 Sept. 3, 1996 Stefik US 7,359,881 B2 Apr. 15, 2008 Wyman US 5,204,897 Apr. 20, 1993 2 In some previous proceedings, Satyanarayanan is referred to as “Coda.” 3 Farber is referred to as “Kinetech” in IPR2014-00062. Appeal 2021-004036 Reexamination Control 90/014,334 Patent 7,949,662 B2 7 Name Title Date Browne Location-Independent Naming for Virtual Distributed Software Repositories, Univ. of Tenn. Tech. Report CS-95-278 Feb. 1995 Cheriton Decentralizing a Global Naming Service for Improved Performance & Fault Tolerance, ACM Trans. On Comp. Sys., Vol. 7, No. 2 1989 The chart below summarizes the results of the reexamination requests: Reexam No. (Appeal No.) Requester Patent Claims References Outcome 90/010,260 LimeWire 6,928,442 1–56 Hellman, Cheriton, Ross, Gramlich Confirmed 1–12, 14–21, 23–35, 37, 39, 42–55 Cancelled 13, 22, 36, 38, 40, 41, 56 90/012,931 (2015-004285) NetApp 5,978,791 35 Woodhill Cancelled 90/013,378 (2016-003387) Google 8,001,096 125 Kantor, Satyanarayanan Cancelled 90/013,379 (2016-001719) Google 7,949,662 25, 33 Kantor, Satyanarayanan Cancelled 25 Denied 33 (no SNQ) 90/013,487 (2016-006941) Google 6,415,280 10, 15, 16, 25 Woodhill, Browne Confirmed 15, 16 Cancelled 10, 25 90/013,764 (2020-000459) (2018-003936) GitHub 6,928,442 7 Woodhill, Kahn, Stefik Confirmed 90/014,368 Apple 7,802,310 70, 81, 82, 86 Browne, Langer Confirmed 90/014,376 Apple 6,415,280 15, 16 Woodhill, Dan Confirmed 90/020,091 IBM 8,099,420 166 Woodhill, Stefik, Francisco Confirmed 90/020,102 IBM 8,099,420 166 Woodhill, Stefik, Francisco Denied (no SNQ) The charts below summarize the outcomes of the petitions for inter partes review, organized by petitioner and outcome. As can be seen, some petitions were denied on procedural grounds (e.g., time bar or privy), while Appeal 2021-004036 Reexamination Control 90/014,334 Patent 7,949,662 B2 8 others reached the merits of the prior art (e.g., the petitions of EMC, Apple, and Rackspace). IPR: Denied Patent NetApp Unified Patents Google PayPal 5,978,791 IPR2013-00319 IPR2014-00702 IPR2014-00980 6,415,280 IPR2014-00977 6,928,442 IPR2014-00979 IPR2019-01092 7,802,310 IPR2014-00978 IPR2019-01111 7,945,544 IPR2019-01093 8,099,420 IPR2019-01089 IPR2019-01091 RESULT Joinder denied (new issues) Institution denied (§ 325(d)) Joinder denied (time bar) Institution denied (privy, § 314(a)) IPR: Instituted Patent EMC Apple Rackspace 5,978,791 IPR2013-00082 IPR2014-00057 6,415,280 IPR2013-00083 IPR2014-00059 6,928,442 IPR2014-00066 7,802,310 IPR2013-00596 IPR2014-00062 7,945,539 IPR2013-00085 7,945,544 IPR2013-00084 7,949,662 IPR2013-00086 8,001,096 IPR2013-00087 8,099,420 IPR2014-00058 RESULT Unpatentable CAFC affirmed Unpatentable CAFC reversed Instituted, Settled In two cases (IPR2019-01089 and IPR2019-01091), institution was denied because the petitions had only shown a reasonable likelihood of unpatentability in, “at best, four of the twelve claims at issue.” E.g., IPR2019-01089, Paper 28, at 2 (Nov. 21, 2019). However, the art at issue in those cases (Francisco and Wyman) is not at issue in the present case. The remaining cases that analyzed the merits of the prior art (i.e., the petitions filed by EMC, Apple, and Rackspace) all involved at least one prior art Appeal 2021-004036 Reexamination Control 90/014,334 Patent 7,949,662 B2 9 reference at issue in the present case. Those cases are summarized in the chart below: IPR No. Patent Claims References Outcome IPR2013- 00082 5,978,791 1–4, 29–33, 41 Woodhill PTAB: unpatentable CAFC: affirmed IPR2013- 00083 6,415,280 36, 38 Woodhill IPR2013- 00084 7,945,544 1 Woodhill, Kantor IPR2013- 00085 7,945,539 10, 21, 34 Woodhill, Langer, Kantor, Fischer IPR2013- 00086 7,949,662 30 Kantor, Satyanarayanan IPR2013- 00087 8,001,096 1, 2, 81, 83 Kantor, Satyanarayanan IPR2013- 00596 7,802,310 24, 32, 70, 81, 82, 86 Woodhill, Stefik, Browne, Langer, Farber (but instituted solely on Woodhill & Stefik) PTAB: unpatentable CAFC: reversed IPR2014- 00057 5,978,791 1–4, 29–33, 35, 41 Woodhill Instituted Settled IPR2014- 00058 8,099,420 166 Woodhill, Farber, Brunk, Francisco IPR2014- 00059 6,415,280 10, 15, 16, 18, 25, 31–33, 36, 38 Woodhill, Langer IPR2014- 00062 7,802,310 1, 2, 5–8, 10–12, 14, 16–19, 24, 29, 32, 70, 81, 82, 86 Woodhill, Francisco, Langer, Farber, Brunk IPR2014- 00066 6,928,442 1, 2, 4, 7, 23, 27, 28, 30 Woodhill, Francisco, Kahn, Langer As can be seen, the Federal Circuit affirmed the PTAB’s determinations for six patents in the EMC proceedings, including cancelling claim 30 of the ’662 patent. Pers. Web Techs., LLC v. EMC Corp., 612 F. App’x 611 (Fed. Cir. 2015) (affirming under Rule 36). Four of these involved Kantor, two of which also involved Satyanarayanan and two others with Woodhill. However, in the Apple proceeding on a different patent, the Appeal 2021-004036 Reexamination Control 90/014,334 Patent 7,949,662 B2 10 Federal Circuit affirmed the PTAB’s claim construction, but remanded on obviousness and later reversed the PTAB’s determination of obviousness because “the Board’s inherency finding derived from column 17 of Woodhill . . . lacks substantial evidence.” Pers. Web v. Apple, 917 F.3d at 1382; 848 F.3d 987 (Fed. Cir. 2017). For the ’662 patent, the net result of the prior proceedings was that (1) claim 25 was cancelled in IPR2013-00086 (based on Kantor and Satyanarayanan); (2) claim 30 was cancelled in Reexamination No. 90/013,379 (also based on Kantor and Satyanarayanan); and (3) claim 33 was held unpatentable under § 101 by the Federal Circuit. The present ex parte reexamination request was filed by Apple on July 10, 2019, and seeks to cancel all pending claims. However, some pending claims depend from canceled claims and include their limitations by dependency, so we still must analyze the limitations of the canceled claims. ISSUES 1. Did the Examiner err in finding Kantor teaches or suggests “a request to delete” (claims 1, 9, 20, 25, 27, 33, 34) or “an attempt to delete” (claim 33)? 2. Did the Examiner err in finding Kantor teaches or suggests ascertaining an identifier after obtaining a request to delete, as recited in claims 1, 9, 30, and 33? 3. Did the Examiner err in finding Kantor teaches or suggests the identifier is “based, at least in part, on [a] given function of all of the bits” of the file or data item, as recited in claims 1, 9, 17, 20, and 34? Appeal 2021-004036 Reexamination Control 90/014,334 Patent 7,949,662 B2 11 4. Did the Examiner err in finding the cited references teach or suggest “determining whether at least some of the chunks of at least some of the data files have a sufficient number of duplicates . . . based, at least in part, on a predetermined degree of redundancy,” as recited in claim 17? 5. Did the Examiner err in finding the cited references teach or suggest a “hash function,” as recited in claims 9, 25, 33, and 34? 6. Did the Examiner err by referring back to previous claims rather than separately addressing certain limitations in claims 17, 20, and 27? 7. Did the Examiner provide sufficient explanation for the combination of Kantor, Satyanarayanan, and Woodhill? 8. Did the Examiner err in concluding that Kantor qualified as a printed publication and hence prior art against the ’662 patent? STANDARD OF REVIEW “If, as is the case here, a reexamination involves claims of an expired patent, a patentee is unable to make claim amendments and the PTO applies the claim construction principles outlined by this court in Phillips v. AWH Corp., 415 F.3d 1303 (Fed.Cir.2005).” In re Rambus, Inc., 753 F.3d 1253, 1256 (Fed. Cir. 2014); see also Appeal Br. 45; Ans. 41. With this standard in mind, we address each of Appellant’s arguments below. Appeal 2021-004036 Reexamination Control 90/014,334 Patent 7,949,662 B2 12 ANALYSIS 1) Request to delete a particular data item Claim Limitation 1 “(A) obtaining . . . a request to delete a particular data item from said given storage location” 9 “(A) obtaining a request to delete said particular instance of said given file in the file system” 20 “(A) in response to a request to delete a particular file, . . . ” 25 “(A) receiving a request to delete a particular data item in the file system” 27 “obtaining . . . a request to delete a first data item” 30 “(A) . . . in response to an attempt to delete said particular data item in said file system” 33 “(A) to receive a request to delete a particular data item in the file system” 34 “(A) to receive . . . a request to delete a particular file in the file system” All of the independent claims except claim 17 recite either “a request to delete” certain data (claims 1, 9, 20, 25, 27, 33, and 34) or an “attempt to delete” such data (claim 30). Most claims (claims 20, 25, 27, 30, 33, and 34) merely require a request to delete a particular file or data item, but independent claims 1 and 9 require deleting a specific copy of the particular file or data item. Compare claim 34 (“delete a particular file”), with claim 9 (“delete said particular instance of said given file”). Claims 25 and 27 require that the request itself include an identifier for the data item (e.g., claim 25: “said request including [a] digital data item identifier corresponding to the particular data item”), whereas other claims require using the request to ascertain the identifier (e.g., claim 1: “based on the Appeal 2021-004036 Reexamination Control 90/014,334 Patent 7,949,662 B2 13 request, ascertaining a particular substantially unique data identifier for the particular data item”). The Examiner relies on Kantor for teaching or suggesting the claimed “request to delete.” Ans. 48–50; Final Act. 13–14. The Examiner finds, “The ‘request’ is the attempt by the Kantor system to determine if it should save/delete an uploaded file” and “the unique identifier (contents signature) is ‘ascertained’ based on the item indicated/requested for deletion (an upload for comparison with any duplicates).” Ans. 48, 50. According to the Examiner, “Kantor’s ‘contents signatures’ . . . includes at least both . . . ‘cs’ and ‘zcs.’” Id. at 51. The Examiner identifies three specific commands in Kantor as relating to the claimed “request to delete”: (1) FWKC17D.BAS, (2) the ‘w’ suboption of FWKCS, and (3) WIPE. Id. at 48–49; Final Act. 13–14. We address each of these commands below. a) FWKC17D.BAS Kantor’s FWKC17D.BAS is a BASIC program that can be used “to delete designated files.” Kantor 200. It is a “special-purpose program[] intended for use with a marked version of the special file produced by FWKCS/1s when that program finds redundant signature lines.” Id. (emphasis added). Specifically, the program “reads a special annotated file called MULTIS, looking for a lower_case ‘d’ in column 17” and “[i]f it finds the ‘d’, then it rearranges parts of the line to put together the drive\path\filename and then deletes that file at that location.” Id. An example of MULTIS showing three groups of duplicate files is reproduced below, with a header added to clarify what is in each column: Appeal 2021-004036 Reexamination Control 90/014,334 Patent 7,949,662 B2 14 <----cs/zcs----> <-CRC--><-SIZE->*<-FILENAME-> <---FILEPATH---> ---------------------------------------------------------------- 014FF56D 158AC LAWN2.ZIP z cs J:\RBBS 014FF56D 158ACdLAWN200.ZIP z cs M:\RBBS ---------------------------------------------------------------- 0249E9AB 486D EQIPVIEW.ZIP z cs H:\RBBS 0249E9AB 486DdVIS.ZIP z cs K:\RBBS ---------------------------------------------------------------- 02FF6937 522E7dCHEMIC20.ZIP z cs E:\RBBS 02FF6937 522E7 CHEMICAL.ZIP z cs E:\RBBS See Kantor 189; see also id. at 52–54 (explaining the columns). In the MULTIS file, the first 16 characters (or columns) are the contents signature value, of which the first 8 characters are the CRC value and the second 8 characters are the uncompressed file size. Each of these columns is in hexadecimal (0 to F). As can be seen, the files “LAWN2.ZIP” and “LAWN200.ZIP” are determined to be duplicates because they have the same zcs value, including the same CRC and the same file size. Column 17 (marked with an “*” in the header) is where a lowercase ‘d’ is used to indicate any files that should be deleted, such as marking the duplicate LAWN200.ZIP for deletion. Next comes the file name (e.g., “LAWN2.ZIP”) and at the far right is the file path (e.g., “J:\RBBS”). Kantor provides an example of the order of operations to make the FWKC17D program work: (1) “you could run” the FWKCS command with the “/1s” option “to put all the duplicate zipfiles together . . . in the file MULTIS”; (2) “Then, you could use a word processing program to look at the MULTIS file, and to put a lower case ‘d’ in column 17 on each line containing a file you wished to delete”; and (3) “Then, . . . you could run” FWKC17D in BASIC “to delete all of those marked files.” Kantor 189–90. Appeal 2021-004036 Reexamination Control 90/014,334 Patent 7,949,662 B2 15 Thus, the “FWKCS/1s” command is not a “request to delete” anything because it merely gathers a list of duplicates. We also agree with Appellant that the Examiner has not shown why the manual marking of the MULTIS file to add a lowercase ‘d’ to column 17 would, by itself, constitute an actual request to delete files. Appeal Br. 82. However, we disagree with Appellant’s argument that the third step— running FWKC17D.BAS—is not a request to delete files. Id.; Ans. 48–49. Appellant argues that “a request to execute FWKC17D.BAS is at the very best a request to delete all those files pre-marked for deletion,” yet Appellant fails to explain sufficiently how that request does not meet the claim language. Appeal Br. 82. For example, claim 1 recites “obtaining . . . a request to delete a particular data item from said given storage location.” The Federal Circuit “has repeatedly emphasized that an indefinite article ‘a’ or ‘an’ in patent parlance carries the meaning of ‘one or more’ in open-ended claims containing the transitional phrase ‘comprising.’” Convolve, Inc. v. Compaq Comput. Corp., 812 F.3d 1313, 1321 (Fed. Cir. 2016) (quotations omitted). Thus, the limitation “a particular data item” can be one or more particular data items. Appellant conceded this at the hearing. Hearing Tr. 14:1–7 (Aug. 11, 2021). The MULTIS file identifies the specific file name and file path for each particular file to delete, and the specific instances of files to delete are each indicated by a lowercase ‘d’ in column 17. Kantor 189, 200. According to Kantor, the “special-purpose” of FWKC17D.BAS is “to delete designated files,” specifically those files indicated in the “special annotated Appeal 2021-004036 Reexamination Control 90/014,334 Patent 7,949,662 B2 16 file called MULTIS.” Id. at 200. Thus, the user running FWKC17D.BAS teaches or suggests obtaining a request to delete a particular instance of a particular data item (or file) from a given storage location. b) WIPE and the ‘w’ suboption of FWKCS The WIPE command and the ‘w’ suboption of FWKCS work together to help delete (or “wipe”) all instances of certain files, such as ads from a competing BBS. Kantor explains that WIPE can be used “to remove specific file(s) from inside an uploaded zipfile,” such as when “another BBS may have been putting ads into other people’s zipfiles.” Kantor 206. However, “[a]fter you use WIPE on an example of that ad, the o and w options for processing uploads work together to automatically remove that ad from uploaded non_AV zipfiles received by your BBS.” Id. (emphasis added). Specifically, Kantor explains that “WIPE.BAT . . . can be used to mark material for Wipe” (i.e., the ‘w’ sub-option of FWKCS), whereas the “w – Wipe” sub-option is used to “[c]ollect for deletion all files found in non_AV file for which a matching contents_signature in CSLIST.SRT or CSLIST1.SRT was marked in decimal_column 17 with a lower case ‘w’.” Id. at 36. According to Kantor, “CSLIST.SRT is the main list of ‘contents_signature,’” whereas “CSLIST1.SRT is used for rapidly adding new material” before later being transferred to CSLIST.SRT. Id. at 18. Thus, based on the record before us, the WIPE command adds the contents signature (i.e., cs or zcs) of a file (e.g., an unwanted ad) to one or more lists of tracked files (i.e., CSLIST.SRT or CSLIST1.SRT) and flags that particular contents signature with a lowercase ‘w’, which indicates that Appeal 2021-004036 Reexamination Control 90/014,334 Patent 7,949,662 B2 17 if that particular contents signature is ever seen, it should be deleted. However, it is the ‘w’ sub-option of the FWKCS command that then searches for files matching those contents signatures marked with a ‘w’. We agree with Appellant that the Examiner has not shown that either WIPE or the ‘w’ sub-option teaches or suggests obtaining a request to delete “a particular data item from said given storage location” (claim 1) or a “particular instance of said given file in the file system” (claim 9). Appeal Br. 79–80; Ans. 48. Based on the limited record before us, WIPE is used to add a contents signature to the list and then the ‘w’ sub-option (which is a sub-option of the ‘f’ and ‘g’ options) is used to delete all instances of matches to that contents signature regardless of location. See Kantor 33–34 (“FWKCS Ver. 1.22 will accept as input, for /f, /g, and /u, a contents_signature”). Unlike the FWKC17D.BAS discussed above, the Examiner has not yet identified any way in which the ‘w’ sub-option of FWKCS is given a particular instance or location of a particular file to delete, whether via a command-line option or a pre-marked file (e.g., similar to the MULTIS file discussed above).4 However, independent claims 20, 25, 27, 30, 33, and 34 merely require obtaining a request to delete a particular file or data item. No particular location or instance must be identified. The ‘w’ sub-option of 4 In the event of further prosecution, the Examiner may wish to consider the ‘o’ sub-option, which is used to “[m]ake [a] list of names (with zipped path information, if any) as they appear inside the zipfile . . . to carry out the deletions” using the deletion command “PKZIP zipfile.zip -d @oust” (where “oust” is the list of files to delete). Kantor 35. Thus, the “oust” file created by the ‘o’ sub-option identifies the specific locations of files to delete. Appeal 2021-004036 Reexamination Control 90/014,334 Patent 7,949,662 B2 18 FWKCS is a request to delete one or more particular files, specifically the files (e.g., ads) whose contents signatures are stored in CSLIST.SRT or CSLIST1.SRT. Kantor 206, 36; see also id. at 33–34. As discussed above for FWKC17D.BAS, Appellant fails to explain why a command to delete a “pre-marked” list of files would not meet the claim language. See Appeal Br. 79. We also note that in the prior inter partes review and ex parte reexamination of the ’662 patent, the USPTO found that Kantor taught or suggested these limitations in claims 25 and 30. EMC Corp. v. PersonalWeb Techs., LLC, IPR2013-00086, Paper 66, Final Written Decision 11 (PTAB May 15, 2014); Ex parte PersonalWeb Techs., LLC, Reexam. Control No. 90/013,379, Final Act. 26–27 (Apr. 23, 2015). Those determinations were affirmed on appeal to the Federal Circuit and PTAB, respectively. Pers. Web v. EMC, 612 F. App’x 611; Ex parte PersonalWeb Techs., LLC, Reexam. Control No. 90/013,379, Decision 21–22 (PTAB Aug. 30, 2016) (“Execution of the ‘FWKC17D.BAS’ program deletes files previously marked for deletion in the MULTIS list. The MULTIS list includes data item identifiers. Patent Owners do not persuasively rebut this line of reasoning.” (citations omitted)). Neither Appellant nor the Examiner provide any detailed discussion whether issue preclusion prevents Appellant from re-litigating the same issue. Appeal 2021-004036 Reexamination Control 90/014,334 Patent 7,949,662 B2 19 2) Ascertaining Identifier After Request to Delete Claim Limitation 1 “(A) obtaining . . . a request to delete a particular data item from said given storage location” “(B) based on the request, ascertaining a particular substantially unique data identifier for the particular data item” 9 “(A) obtaining a request to delete said particular instance of said given file in the file system” “(B) based at least in part on said request, ascertaining a digital file identifier corresponding to the given file” Independent claims 1 and 9 recite obtaining a request to delete either a particular data item from a given storage location (claim 1) or a particular instance of a given file (claim 9). Both claims then recite obtaining an identifier for that file or data item based on that request. Appellant argues the Examiner fails to show how Kantor teaches the claimed order of steps. See Appeal Br. 88–90. Specifically, Appellant argues, “Kantor’s contents signatures are ascertained prior to any request in Kantor to mark files for deletion.” Id. at 89 (emphasis added). For example, “WIPE.BAT is merely marking items for possible subsequent deletion” and therefore “WIPE.BAT would be executed prior to [any] deletion request.” Appeal Br. 89. And “the ‘w – Wipe’ sub-option . . . assumes that entries in the CSLIST.SRT and CSLIST1.SRT housekeeping files are pre-marked with ‘w’ flags to indicate that they are to be deleted” and thus “there are no particular substantially unique data identifiers for any particular data items ascertained ‘based on’ the ‘w – Wipe’ sub-option.” Id. at 88. We agree with Appellant that the specific commands currently identified by the Examiner do not meet the order required in claims 1 and 9. Appeal 2021-004036 Reexamination Control 90/014,334 Patent 7,949,662 B2 20 As discussed above, the Examiner fails to explain how the WIPE command and ‘w’ sub-option teach a request to delete a particular instance or location of a file. Thus, for claims 1 and 9, we need only address the FWKC17D command. See Ans. 13–14, 48–51; Final Act. 14–15. If executing the FWKC17D command is the claimed “request to delete” (as discussed above), then the contents signatures are gathered in the MULTIS file before the request to delete, whereas claims 1 and 9 require ascertaining the identifier (here, Kantor’s cs or zcs values) after the request to delete. Appeal Br. 89–90. The Examiner asserts that Kantor teaches the claimed order but fails to provide any citation of where or explanation of how Kantor teaches this. See Ans. 50–51. Kantor discloses FWKC17D using the file name and file path stored in the MULTIS file as well as checking column 17 for a lowercase ‘d’, but it is not clear on this record whether FWKC17D ever “ascertains” or uses the contents signatures in the MULTIS file. See Kantor 200. Thus, Appellant persuades us that the Examiner has not shown how Kantor teaches or suggests the claimed order of steps (A) and (B) in independent claims 1 and 9 and their dependent claims 2–8 and 10–16.5 5 In the event of further prosecution, the Examiner may wish to consider the “/a5” option of FWKCS. Using the “/a5” option, the FWKCS program can take as input a “single variable, designating the file to process.” Kantor 74. For example, Kantor discusses an example using the command “FWKCS d:\path\filename.ext upload /a5” to determine whether the specified file at the specified location (“d:\path\filename.ext”) is a duplicate, in which case “[t]he redundant file is automatically deleted.” Id. at 191. Thus, the “/a5” option allows the user to use a single command line to request deletion of a particular instance of a particular file if that file is a duplicate. Appeal 2021-004036 Reexamination Control 90/014,334 Patent 7,949,662 B2 21 Claim Limitation 30 “(A) obtaining a particular digital data item identifier of a particular data item, said particular digital data item identifier of said particular data item being obtained in response to an attempt to delete said particular data item in said file system” 33 “(A) to receive a request to delete a particular data item in the file system” “(B) to ascertain, in response to said request, a digital data item identifier corresponding to said particular data item” Like claims 1 and 9, independent claims 30 and 33 also require an order of steps in ascertaining an identifier “in response to” receiving an attempt (claim 30) or request (claim 33) to delete. However, unlike claims 1 and 9, the deletion attempt or request in claims 30 and 33 need only be for a particular data item, not a given location or particular instance of that data item. In this case, the Examiner properly relies on the ‘w’ sub-option. See Ans. 48–51; Final Act. 13–15 (discussing claim 1), 39 (analogizing claims 30 and 33 to claim 1). As discussed above, the FWKCS command with the ‘w’ sub-option is a request to delete files matching any contents signature in the CSLIST.SRT or CSLIST1.SRT files marked with a ‘w’ (e.g., the cs values of ads from a competitor BBS). Kantor 36, 206. With this command, the contents signature of a newly uploaded file is ascertained and used for comparison in response to the FWKCS command being run with the ‘w’ sub-option. Thus, Kantor does teach or suggest the order of steps in claims 30 and 33. We note that in the prior inter partes review of the ’662 patent, the USPTO found Kantor teaches or suggests this limitation in claim 30. EMC Appeal 2021-004036 Reexamination Control 90/014,334 Patent 7,949,662 B2 22 Corp. v. PersonalWeb Techs., LLC, IPR2013-00086, Paper 66, Final Written Decision 10–12 (PTAB May 15, 2014). That determination was affirmed on appeal to the Federal Circuit. Pers. Web v. EMC, 612 F. App’x 611. Neither Appellant nor the Examiner provide any detailed discussion whether issue preclusion prevents Appellant from re-litigating the same issue. We also acknowledge that prior to the Federal Circuit decision, examiners in the prior ex parte reexamination determined that Kantor’s FWKC17D program and its use of the MULTIS list did not teach or suggest the “in response to” limitation of claim 33. Ex parte PersonalWeb Techs., LLC, Reexam. Control No. 90/013,379, Decision 24–25 (Dec. 2, 2014) (“the deletion process of Kantor fails to meet or disclose” the “in response to” limitation of claim 33 because “Kantor specifically discloses the digital data item identifier is ascertained before any MULTIS list is created and thus before any particular data item is identified and requested to be deleted”). This is consistent with our conclusion for FWKC17D discussed above for claims 1 and 9. However, that decision in the prior ex parte reexamination does not appear to have addressed Kantor’s WIPE command or ‘w’ sub- option and thus does not address the basis for our decision on independent claims 30 and 33 here. Appeal 2021-004036 Reexamination Control 90/014,334 Patent 7,949,662 B2 23 3) Identifier based on function of “all of the bits” Claim Limitation 1 “said particular data identifier is based, at least in part, on a given function of all of the bits in the particular sequence of bits of the particular data item” 9 “the corresponding digital file identifier for each file in the file system being based, at least in part, on given function of all of the bits of the file” 17 “the corresponding digital file identifier for each file in the file system being based, at least in part, on given function of all of the bits of the file” 20 “the corresponding digital file identifier for each file in the file system being based, at least in part, on given function of all of the bits of the corresponding file” “said particular digital file identifier for said particular file being based, at least in part, on said given function of all of the bits in said particular sequence of bits of the particular file” 34 “the corresponding digital file identifier for each file in the file system being based, at least in part, on given function of all of the bits of the file” As discussed above, the Examiner relies on Kantor’s contents signatures (cs and zcs values) for teaching or suggesting the claimed “identifier.” Ans. 51–52. Appellant argues, “Kantor’s function for generating contents signatures is able to ignore ‘padding bytes’ / ‘tails’” and, therefore, “information deemed erroneous may be disregarded when generating cs values.” Appeal Br. 94. According to Appellant, “Kantor’s cs values thus do not need to be based on a given function of all of the bits in the particular sequence of bits of a particular data item.” Id. Similarly, for zcs values, “Kantor does not consider header information from the zipfile, or other Appeal 2021-004036 Reexamination Control 90/014,334 Patent 7,949,662 B2 24 information indicative of paths, filenames, compression ratios, etc.” Id. at 96. Appellant’s argument is unpersuasive. First, all of the independent claims with this disputed term (claims 1, 9, 17, 20, and 34) recite that the identifier is based in part on a “given function of all of the bits” of the file or data item. Thus, the given function takes as input all of the bits, but what the function does internally with those bits is not specified by the claims. Ans. 51–52 (“The claim language does not indicate how the identifier is based on the bits” and thus does not preclude whether certain bits or bytes are ignored as “part of Kantor’s function to generate the contents signatures.”). Here, an entire file (i.e., all of the bits) is provided to Kantor’s cs or zcs functions, and Kantor therefore teaches or suggests that the cs or zcs value is based at least in part on a given function of all of the bits of the corresponding file, regardless of whether that function internally ignores some of those bits after receiving them. Second, we also agree with the Examiner that “any instance of Kantor not using all the bits, does not negate the fact that Kantor shows instances using all the bits.” Ans. 52. Although Appellant focuses on the few file types that get treated specially when calculating cs or zcs values (i.e., zip and GIF files), most file types will not get any such special treatment, including for example text files (.txt), documents (.doc), spreadsheets (.xls), scripts (.bat), programming code (.bas, .cpp, .c, .h), disc images (.iso), audio files (.wav), image files other than GIF (.bmp, .jpg, .tif), archive files other than zip (.tar, .rar), and executable files other than self-extracting zipfiles (.exe). See, e.g., Kantor 207–12 (showing sample duplicate CRC values Appeal 2021-004036 Reexamination Control 90/014,334 Patent 7,949,662 B2 25 with many of these file types). This further confirms that Kantor teaches or suggests this limitation, even under Appellant’s more narrow interpretation. Third, although Kantor is capable of treating zip and GIF files specially, that capability is optional. As the Examiner explains, “Kantor teaches both . . . finding exact duplicates . . . and . . . finding substantial duplicates” and “[w]hether the sensitivity of Kantor is configured to find exact duplicates, or substantially similar duplicates is a matter of design choice.” Ans. 59. In fact, Kantor teaches options to not treat zip and GIF files specially. For example, as Appellant correctly points out, the ‘j’ option allows the user to decide whether to “strip/ignore ‘GIF’ file’s tail before/when generating the file’s contents_signature.” Kantor 49, 59, 62, 98, 160; Appeal Br. 93 (citing Kantor 9, 49, 59, 62, 98). Thus, although Kantor provides the option to strip or ignore tails in GIF files, the default in Kantor is to include such tails in the calculation of the contents signature. Kantor therefore teaches or suggests calculating a contents signature from all bits of a GIF file. Similarly, Kantor lets the user choose between using the ‘z’ option to “make a ‘Zipfile contents signature’ for (each) Zipfile” or instead using the ‘y’ option to “make cs for zipfile as if plain file.” Kantor 55. Kantor explains that the ‘y’ option can be used for looking for exact duplicate (zip)files: unlike [the ‘z’ option], the contents_signature made using option y on a zipfile depends on compression, names, dates, and order of files in the zipfile, and on comment(s). In this case, FWKCS reads every byte in the zipfile and calculates its 32_bit CRC, rather than look up CRC value(s) in the zipfile. Appeal 2021-004036 Reexamination Control 90/014,334 Patent 7,949,662 B2 26 Kantor 55 (emphasis added). Kantor says this may be useful “in looking for change, e.g., in monitoring equipment performance, etc.” Id. Thus, the Examiner is correct that Kantor teaches letting the user choose to have the CRC of the contents signature calculated based on all bits for all files rather than treating some file types specially. As the Federal Circuit has said, “[a] reference must be considered for everything that it teaches, not simply the described invention or a preferred embodiment.” In re Applied Materials, Inc., 692 F.3d 1289, 1298 (Fed. Cir. 2012). Thus, “the fact that a specific embodiment is taught to be preferred is not controlling, since all disclosures of the prior art, including unpreferred embodiments, must be considered.” Merck & Co. v. Biocraft Labs., Inc., 874 F.2d 804, 807 (Fed. Cir. 1989) (quotation omitted). Thus, even if Kantor’s special treatment of GIF and zip files were a preferred embodiment (and it is not clear that they are because at least the ‘j’ option is not the default), we still must consider Kantor’s other teaching to treat all files as plain files to search for exact duplicates. Appellant also notes the claim constructions from previous proceedings, including that the term “data identifier” was “construed as ‘an identity for a data item generated by processing all of the data in the data item, and only the data in the data item, through an algorithm that makes the identifier substantially unique’.” Appeal Br. 96–97 & n.7 (citing PersonalWeb Techs., LLC v. NEC Corp. of Am., Inc., No. 6: l l-cv-00656- LED, Doc. 178 at 16 (E.D. Tex., Aug. 5, 2013) [Ex. 2009]). However, Appellant fails to provide any discussion or evidence of whether or how “processing all of the data” would change our analysis above. Appeal 2021-004036 Reexamination Control 90/014,334 Patent 7,949,662 B2 27 4) Checking for sufficient redundancy Claim Limitation 1 “(C) determining . . . whether deletion of said particular data item from said given storage location will leave a sufficient number of copies of said data item present at one or more other storage locations in the file system to satisfy said predetermined degree of redundancy for said file system with respect to that particular data item” “(D) based at least in part on said determining, if it is determined that deletion of the particular data item from the given storage location will leave at least a sufficient number of copies of said data item at one or more other storage locations in said file system to satisfy said predetermined degree of redundancy for said file system with respect to that particular data item, then” 9 “(C) determining whether deletion of said particular instance of said given file will violate said predetermined degree of redundancy for said file system” “(D) based at least in part on said determining in (C), when it is determined that deletion of said particular instance of said given file will not violate said predetermined degree of redundancy for said file system, then:” 17 “determining whether at least some of the chunks of at least some of the data files have a sufficient number of duplicates stored on said servers in the file system, said sufficient number of duplicates being based, at least in part, on a predetermined degree of redundancy for said file system” “based at least in part on said determining, updating a list to indicate the deletion of at least some of the chunks of data files that are determined to have more than said sufficient number of duplicates” With slight variation in wording, independent claims 1, 9, and 17 require determining whether a deletion will leave a sufficient number of copies given a predetermined degree of redundancy, then taking further steps based on that determination. Because we reverse the rejection of claims 1 and 9 on other limitations, we focus the discussion here on claim 17. Appeal 2021-004036 Reexamination Control 90/014,334 Patent 7,949,662 B2 28 Appellant argues that “Kantor affirmatively teaches away” from this limitation by “eliminating all duplicates.” Appeal Br. 101. This argument was rejected, however, in IPR2013-00087 on a related patent. EMC Corp. v. PersonalWeb Techs., LLC, IPR2013-00087, Paper 69, at 19 (PTAB May 15, 2014). In discussing Kantor’s FWKC17D command, the panel found that Kantor’s “MULTIS [file] is used to . . . list the files for which multiple copies exist” and “a word processor is used to add a ‘d’ to the line of . . . the files to be deleted.” Id. But “if the user does not place the ‘d’ on the line for the file, that duplicate file will remain on the system,” and therefore “Kantor does not require the elimination of all duplicates.” Id. at 19–20. We agree with the prior panel’s assessment. Although Kantor provides options to delete all matching files (e.g., WIPE) or all but one matching file (e.g., the sample MULTIS file shown on Kantor 189), the user is free to decide how many files to keep or delete. In fact, on pages cited multiple times in Appellant’s briefs, Kantor discloses an “mNNN” sub-option (where “NNN” is a number) to create a report of files for which “the number of matching contents_signatures . . . is greater than or equal to NNN.” Kantor 49–50; see also Appeal Br. 75 (citing Kantor 50), 58, 93, 111 (citing Kantor 49); Reply Br. 16 (citing Kantor 50). Example #2 on these pages discloses a command-line of “FWKCS /1sm16 CSLIST.SRT MULTIS SAMPLE” (where “m16” is the relevant sub-option) to create a file called SAMPLE containing the contents signature and total count of each file with “at least 16” matches and to “make a MULTIS file of matching contents_signatures.” Kantor 49–50; see also Kantor 196 (showing part of a sample report). Thus, Kantor discloses Appeal 2021-004036 Reexamination Control 90/014,334 Patent 7,949,662 B2 29 an example of creating the MULTIS file only for files with 16 or more duplicates. We also note that in the prior inter partes review and ex parte reexamination of the ’662 patent, the USPTO found that it would have been obvious to modify Kantor with the redundancy taught in Satyanarayanan. EMC Corp. v. PersonalWeb Techs., LLC, IPR2013-00086, Paper 66, Final Written Decision 10, 13 (PTAB May 15, 2014) (“Kantor fails to disclose the underlying storage system of the BBS, and, thus, does not disclose that files are replicated on multiple servers, per claim 30. Satyanarayanan discloses a network-based file replication system, where copies of files are stored at multiple servers. . . . [W]e concur with the analysis of [Petitioner’s expert], that it would have been obvious to combine Kantor and Satyanarayanan to provide more reliable storage systems for the BBS’s files.” (citations omitted)); Ex parte PersonalWeb Techs., LLC, Reexam. Control No. 90/013,379, Final Act. 9–13 (Apr. 23, 2015) (“the addition of [Satyanarayanan] in the rejection is applied to teach the notion of ‘replication mechanisms to store copies of files at multiple servers, while maintaining consistency and availability of files’”). Similarly, in an inter partes review of a related patent, the PTAB held that it would have been obvious to combine Satyanarayanan with Kantor in order to provide Kantor’s BBS with Satyanarayanan’s replication/mirroring. EMC Corp. v. PersonalWeb Techs., LLC, IPR2013-00087, Paper 69, at 20 (PTAB May 15, 2014) (“In view of the actual teachings of Satyanarayanan, namely that mirroring techniques can increase reliability and response times Appeal 2021-004036 Reexamination Control 90/014,334 Patent 7,949,662 B2 30 for requests for files, we agree with EMC that it would have been obvious to mirror duplicate files that were not deleted in Kantor.” (citation omitted)). Those determinations were affirmed on appeal to the Federal Circuit (for the inter partes reviews) and PTAB (for the ex parte reexamination). Pers. Web v. EMC, 612 F. App’x 611; Ex parte PersonalWeb Techs., LLC, Reexam. Control No. 90/013,379, Decision 22–23 (PTAB Aug. 30, 2016). Thus, the prior proceedings also determined that similar limitations would have been obvious over a combination of Kantor’s duplicate detection in a BBS with Satyanarayanan’s replication. 5) Hash function Claim Limitation 9 “said given function comprising a hash function or message digest function” 25 “said digital data item identifier being based at least in part on a hash function of the data comprising the particular data item” 33 “said given function comprising a hash function” 34 “said given function comprising a hash or message digest function” The claims recite that the identifier is based on a function, and four of the independent claims (9, 25, 33, and 34) further recite that the function is a hash function or message digest function. As an initial matter, we agree with Appellant that the terms “hash function” and “message digest function” are “used interchangeably in the ’662 patent.” Appeal Br. 54. For example, dependent claim 29 recites “the hash function is selected from the functions: MD4, MD5, and SHA,” whereas the body of the Specification explains, “A family of functions with the above properties are the so-called message digest functions,” which Appeal 2021-004036 Reexamination Control 90/014,334 Patent 7,949,662 B2 31 “include MD4, MD5, and SHA.” ’662 patent at 12:61–65 (emphasis added). Notably, the “MD” in MD4 and MD5 stands for “message digest,” and “SHA” stands for “Secure Hash Algorithm.” See, e.g., US 5,818,939 at 4:49–56 (issued Oct. 6, 1998) (emphasis added). For the meaning of this term, Appellant and the Examiner both look to column 12 of the Specification, which discusses its message digest function, as follows: A True Name is computed using a function, MD, which reduces a data block B of arbitrary length to a relatively small, fixed size identifier, the True Name of the data block, such that the True Name of the data block is virtually guaranteed to represent the data block B and only data block B. The function MD must have the following properties: 1. The domain of the function MD is the set of all data items. The range of the function MD is the set of True Names. 2. The function MD must take a data item of arbitrary length and reduce it to an integer value in the range 0 to N–1, where N is the cardinality of the set of True Names. That is, for an arbitrary length data block B, 0≦MD(B)