Facebook, Inc.Download PDFPatent Trials and Appeals BoardMay 12, 20212020001320 (P.T.A.B. May. 12, 2021) 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. 14/445,480 07/29/2014 Benjamin Maurer 007726.0275U1 5679 146113 7590 05/12/2021 FisherBroyles, LLP - Facebook, Inc. Facebook, Inc. 222 South Main Street, 5th Floor Salt Lake City, UT 84101 EXAMINER CONYERS, DAWAUNE A ART UNIT PAPER NUMBER 2152 NOTIFICATION DATE DELIVERY MODE 05/12/2021 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): docketing@fisherbroyles.com fb-docketing@fisherbroyles.com PTOL-90A (Rev. 04/07) UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE PATENT TRIAL AND APPEAL BOARD Ex parte BENJAMIN MAURER and NOAM LERNER Appeal 2020-001320 Application 14/445,480 Technology Center 2100 Before DANIEL J. GALLIGAN, JESSICA C. KAISER, and KARA L. SZPONDOWSKI, Administrative Patent Judges. GALLIGAN, Administrative Patent Judge. DECISION ON APPEAL STATEMENT OF THE CASE Pursuant to 35 U.S.C. § 134(a), Appellant1 appeals from the Examiner’s decision to reject claims 1–3, 5, 8–10, 12, 15, and 17–22.2 Claims 7, 14, and 16 have been cancelled. We have jurisdiction under 35 U.S.C. § 6(b). We AFFIRM IN PART. 1 We use the word Appellant to refer to “applicant” as defined in 37 C.F.R. § 1.42(a). Appellant identifies the real party in interest as Facebook, Inc. Appeal Br. 3. 2 The Non-Final Rejection from which this Appeal is taken rejects claims 1–6, 8–13, 15, and 17–22. Non-Final Act. 3–23. In the Answer, the Examiner withdrew the rejection of claims 4, 6, 11, and 13. Ans. 3. Appeal 2020-001320 Application 14/445,480 2 CLAIMED SUBJECT MATTER Claims 1, 8, and 15 are independent claims. Claim 1 is reproduced below: 1. A computer-implemented method for channeling structured data, comprising: receiving structured data comprising key-value pairs; generating a plurality of channel elements from the key- value pairs of the received structured data, wherein the generating includes: generating multiple type channel elements each of which indicates a type of a corresponding value in the key- value pairs, generating multiple key channel elements corresponding to keys of the key-value pairs, and generating multiple data channel elements corresponding to values of the key-value pairs; creating a channeled representation by assembling the channel elements into a plurality of channels, wherein the creating includes: generating a type channel and storing the multiple type channel elements in the type channel, generating a key channel and storing the multiple key channel elements in the key channel, and generating a data channel and storing the multiple data channel elements in the data channel; generating a compressed data object by compressing the channeled representation, wherein the generating includes: Appeal 2020-001320 Application 14/445,480 3 identifying a pattern in at least one of the assembled channel elements, and substituting a memoization reference for the pattern; and transmitting the compressed data object across a network, wherein creating the channeled representation improves an efficiency of compressing the structured data for transmission across the network. REJECTION The Examiner rejects claims 1–3, 5, 8–10, 12, 15, and 17–22 under 35 U.S.C. § 103(a) as being unpatentable over Nieuwpoort (Rob V. van Nieuwpoort et al., Ibis: an Efficient Java-based Grid Programming Environment (2002)), Garakani (US 2005/0015514 A1, published Jan. 20, 2005), Pusher (The Pusher Protocol, https://archive.org/ (2011)), Goupil (US 2014/0281885 A1, published Sept. 18, 2014), and Baudia (US 2016/0154117 A1, published June 2, 2016). Non-Final Act. 3–23; see Ans. 3. Our review in this appeal is limited only to the above rejection and the issues raised by Appellant. Arguments not made are waived. See MPEP § 1205.02; 37 C.F.R. §§ 41.37(c)(1)(iv) and 41.39(a)(1). OPINION Claims 1, 2, 8, 9, 15, and 17–22 “a type channel . . . a key channel . . . a data channel” Appellant argues that Goupil does not teach “generating a type channel and storing the multiple type channel elements in the type channel, generating a key channel and storing the multiple key channel elements in Appeal 2020-001320 Application 14/445,480 4 the key channel, and generating a data channel and storing the multiple data channel elements in the data channel,” as recited in claim 1 and similarly recited in claims 8 and 15. Appeal Br. 11–16; Reply Br. 6–9. Specifically, Appellant argues that Goupil teaches “a single ‘channel,’ which is inter- frame communication channel 203,” rather than teaching “three separate channels.” Appeal Br. 11, 13, 15–16; Reply Br. 7–8. We are not persuaded of Examiner error. The Examiner finds, and we agree, that Goupil teaches a “type channel” because Goupil’s “transportation type” — or “transport type” — is a data object in a particular format which stores a “string which is capable of storing multiple string elements.” Ans. 5 (citing Goupil ¶¶ 34, 83, Fig. 2); see Goupil ¶¶ 29, 35. For example, the transport type is a data object “represented as a JSON string.” Goupil ¶ 54; see id. ¶¶ 88–89. The Examiner further finds, and we agree, that Goupil’s transport type also stores “key channel elements of object data,” and, so, teaches a “key channel.” Ans. 5–6 (citing Goupil ¶¶ 34, 58, 86–87, Fig. 2). Still further, the Examiner finds, and we agree, that Goupil’s transport type additionally stores “a date string” and, so, teaches “a data channel.” Ans. 6 (citing Goupil ¶¶ 34, 58). Appellant’s arguments are not persuasive because those arguments are not commensurate with the scope of the claim. Appellant asserts that the claimed “type channel,” “key channel,” and “data channel” are “separate and isolated” (Reply Br. 7–8; Appeal Br. 11, 13, 15), but the claims do not recite that those channels are separate and isolated from one another. Further, the Specification does not define the terms “type channel,” “key channel,” and “data channel”— or even the term “channel”— much less define those channels as necessarily separate or isolated. The portions of the Specification Appellant relies on to support Appellant’s assertion that the Appeal 2020-001320 Application 14/445,480 5 claimed channels are separate and isolated (Appeal Br. 13–14 (citing Spec. ¶¶ 14, 24–29, Fig. 4); Reply Br. 7–8) do not provide definitions of the disputed terms. Instead, those portions describe non-limiting examples of a data structure having channels that store channel elements, e.g., a “Channeling Example” and “FIG. 4 is a block diagram illustrating the channeling of an example JSON data structure as may be implemented in some embodiments” Spec. ¶ 24 (emphasis added). In fact, the two instances in the Specification discussing “separate” channels state that separate channels are an option, not a requirement. Specifically, the Specification states channel elements, e.g., “lengths[,] may be incorporated into separate key length and string length channels” (id. ¶ 25 (emphasis added)) and the “original location of each string may be encoded in a separate channel” (id. ¶ 42 (emphasis added)). As such, the Specification supports the Examiner’s interpretation that a channel encompasses multiple different channels. For example, when a single channel stores string channel elements and corresponding string length channel elements, that channel encompasses both a string channel and a length channel. See id. ¶ 25. Accordingly, we are not persuaded the Examiner erred in finding Goupil’s transport type, which is a data structure storing type channel elements, key channel elements, and data channel elements, teaches “a type channel,” “a key channel,” and “a data channel” within the scope of the claims. Additionally, although not necessary to reach our decision, even if the claims did require that the “type channel,” “key channel,” and “data channel” were separate channels, Goupil’s data structure appears to teach elements stored in separate “channels.” As discussed above, the claimed “type channel,” “key channel,” and “data channel” are structures storing respective data. See Spec. ¶¶ 24–26, Fig. 4. Goupil describes a data object Appeal 2020-001320 Application 14/445,480 6 with separately identified structures storing respective data. As the Examiner points out (see Ans. 4–7; see also Non-Final Act. 8–9), Goupil describes a data object having a first identified structure storing “the name ‘method’ and the corresponding value includes the name of the method being called (in this case ‘someMethod’),” a second identified structure separately storing “the name ‘args’ and the corresponding value includes an array listing all of the input arguments in order (e.g., in the case of 123 and ‘hello’ being input arguments, the value would be [123, ‘hello’],” and a third identified structure separately storing “the name ‘handle’ and the corresponding value includes the unique identifier of the function call (in this case ‘flb78c53-e4e4-432b-a2cd-89532187d497’)” (Goupil ¶¶ 88–89). Accordingly, as neither the claims nor the Specification limits the meaning of a “channel” beyond some structure storing data, Goupil’s structures in its data object which separately store respective data teach separate channels. We also note that Appellant asserts that the alleged “improvements in memoization and compression” described in the Specification “only occur if the recited ‘plurality of channels’ is actually a ‘plurality’ of separate channels” because the generated channels “show[] a high level of repetition, thereby enabling a high level of compression through memoization.” Appeal Br. 14 (citations omitted); Reply Br. 8 (citations omitted). We acknowledge that the Specification describes alleged compression improvements by reorganizing data from an original data structure into a data structure with channels separated in a particular manner, having respective common elements in a particular arrangement and then memoizing those separate channels. Spec. ¶¶ 19, 24–27, Fig. 4. However, the claims do not reflect all the features required to achieve the alleged improvements Appellant highlights. As discussed above, the claims do not Appeal 2020-001320 Application 14/445,480 7 require separate channels, let alone separate channels defined in any particular manner. Nor do the claims recite reorganizing the data in an original data structure into a different arrangement more amenable to memoization. That is, the features Appellant argues are not required by the claims. Accordingly, we are not persuaded the Examiner erred in finding Goupil teaches “generating a type channel and storing the multiple type channel elements in the type channel, generating a key channel and storing the multiple key channel elements in the key channel, and generating a data channel and storing the multiple data channel elements in the data channel,” as recited in claim 1 and similarly recited in claims 8 and 15. Improper Combination Appellant argues the Examiner improperly combined Nieuwpoort and Goupil and Nieuwpoort, Goupil, and Garakani. Appeal Br. 16–20. Specifically, Appellant argues “the primary reference,” i.e., Nieuwpoort, “language of Ibis is based on Java, whereas the tertiary reference,” i.e., Goupil, “language of JSON is based on ‘JavaScript,” are “not closely related” and “[t]here is simply no ‘obvious’ way to interconnect and combine these two completely different programming protocols.” Appeal Br. 17–18. In a similar vein, Appellant argues Garakani “does not reference Ibis, Java, Javascript, or JSON, or otherwise suggest that its flag-based compression technique would have any obvious application to such different and foreign programming protocols.” Id. at 19. Additionally, Appellant argues Nieuwpoort “has no applicability to compression” (id. at 16), Nieuwpoort “does not fairly suggest two separate channels” (id. at 16–17), Appeal 2020-001320 Application 14/445,480 8 and the Examiner “has apparently engaged in hindsight reasoning” to combine the references (id. at 18–19). We are not persuaded the Examiner improperly combined the references. The Examiner determines that the “skilled artisan would have been motivated to improve the teachings of Nieuwpoort with the teachings of Pusher and Goupil to create object elements for communication channels.” Non-Final Act. 8–9. The Examiner further determines that the “skilled artisan would have been motivated to improve the teachings of Nieuwpoort with the teachings of Pusher, Goupil, and Garakani . . . to allow lossless compression for many types of serial protocols used over a clear channel.” Id. at 10 (citing Garakani ¶ 5). Appellant’s argument that the Examiner’s combination of Nieuwpoort, Goupil, and Garakani is improper because the references are based on different “programming language[s]” or “programming protocols” (Appeal Br. 17–19) is not persuasive. Appellant’s argument is based on its assertion that the various programming languages and protocols used by the references are so dissimilar that the references have “no obvious applicability to, or interconnectivity” to one another. Id. However, that assertion is supported only by attorney argument, which “cannot take the place of evidence.” In re Pearson, 494 F.2d 1399, 1405 (CCPA 1974). As such, Appellant’s argument is not adequately supported by evidence and is, correspondingly, unpersuasive. Moreover, Appellant incorrectly relies on exemplary computing environments to unnecessarily limit the teachings of the references to only those exemplary computing environments. In fact, the references contradict Appellant’s assertion and state that their features are applicable to a wider variety of computing environments. For example, Goupil states that “the Appeal 2020-001320 Application 14/445,480 9 principles described herein may operate for any data serialization format used between frames of a browser window, whether such data serialization formats now exist, or whether they are yet to be developed.” Goupil ¶ 29 (emphasis added); see id. ¶ 3 (“The subject matter claimed herein is not limited to embodiments that solve any disadvantages or that operate only in environments such as those described above.”) (emphasis added). Similarly, Garakani also states that its features are not limited to a particular programming environment. Garakani states that “application of embodiments of the invention is not limited to HDLC or similar protocols. HDLC does serve as an example of flagging protocols to which this may be applied.” Garakani ¶ 17 (emphasis added). As such, contrary to Appellant’s argument, the references support the combination of their features. Appellant’s remaining arguments that the combination is improper are also unavailing. Appellant’s argument that Nieuwpoort “has no applicability to compression and, therefore, does not even hint at the inventive solution of this application” (Appeal Br. 16) does not address the Examiner’s reliance on Garakani to provide compression improvements and does not address the Examiner’s motivation to improve Nieuwpoort with Garakani’s compression features (Non-Final Act. 9–10 (citing Garakani ¶¶ 5, 19–24)). Further, Appellant’s argument that Nieuwpoort does not teach “two separate channels, a type channel and a key channel” (Appeal Br. 16–17) does not address why the combination of references is improper and, instead, addresses limitations the Examiner relies on Goupil to teach, as discussed above. Still further, Appellant’s argument generally asserting that the Examiner “has apparently engaged in hindsight reasoning” to combine the references (Appeal Br. 18–19) does not persuasively address the Examiner’s stated motivation for the combination. Rather than using hindsight to Appeal 2020-001320 Application 14/445,480 10 combine the references, the Examiner articulates reasons to combine the references supported by rational underpinning. KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 418 (2007). Appellant does not address (see Appeal Br. 18–19) the Examiner’s articulated reasons to combine the references, namely, to improve data communication and data compression (Non-Final Act. 8–10; Ans. 13–14). Accordingly, we are not persuaded the Examiner erred in combining Nieuwpoort, Goupil, and Garakani. Appellant does not argue separate patentability for dependent claims 2, 9, and 17–22. See Appeal Br. 11. Accordingly, for the reasons set forth above, we sustain the Examiner’s decision to reject claims 1, 2, 8, 9, 15, and 17–22. Claims 3, 5, 10, 12 Appellant argues Pusher does not teach “length channel elements” as recited in claim 3 and similarly recited in claims 5, 10, and 12. Appeal Br. 20–23. Specifically, Appellant argues “the [E]xaminer does not provide a specific and meaningful citation to the ‘Pusher’ reference that would satisfy the language of the claims” and Appellant “did not identify, during this review, any disclosure that would satisfy the quoted claim language.” Appeal Br. 20, 22–23. We are persuaded the Examiner erred. The Examiner finds that Pusher’s disclosure of “data hash elements” teaches “length channel elements.” Ans. 16 (citing Pusher 5–8). However, the Examiner has not explained how or why a data hash teaches “length channel elements.” Nor is it readily apparent to us that the Specification describes that the scope of length channel elements encompasses data hashes. Accordingly, on the record before us, without further explanation from the Examiner, we are Appeal 2020-001320 Application 14/445,480 11 persuaded the Examiner erred in finding Pusher teaches “length channel elements.” As such, we reverse the Examiner’s rejection of claims 3, 5, 10, and 12. CONCLUSION In summary: Claims Rejected 35 U.S.C. § Reference(s)/Basis Affirmed Reversed 1–3, 5, 8– 10, 12, 15, 17–22 103 Nieuwpoort, Garakani, Pusher, Goupil, Baudia 1, 2, 8, 9, 15, 17–22 3, 5, 10, 12 TIME PERIOD FOR RESPONSE No time period for taking any subsequent action in connection with this appeal may be extended under 37 C.F.R. § 1.136(a). See 37 C.F.R. § 1.136(a)(1)(iv). AFFIRMED-IN-PART Copy with citationCopy as parenthetical citation