Facebook, Inc.

Patent Trials and Appeals Board

May 12, 2021

2020001320 (P.T.A.B. May. 12, 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.
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