CHARTIQ, INC. et al.

Patent Trials and Appeals Board

Nov 30, 2021

2021005311 (P.T.A.B. Nov. 30, 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,377 09/19/2019 10180862 11821/008163-US0 1010
111420 7590 11/30/2021
Woods Rogers PLC
901 East Byrd Street
Suite 1550
Richmond, VA 23219
EXAMINER
FERRIS III, FRED O
ART UNIT PAPER NUMBER
3992
MAIL DATE DELIVERY MODE
11/30/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)

UNITED STATES PATENT AND TRADEMARK OFFICE
____________

BEFORE THE PATENT TRIAL AND APPEAL BOARD
____________

Ex parte CHARTIQ, INC.
Patent Owner and Appellant
____________

Appeal 2021-005311
Reexamination Control 90/014,377
Patent 10,180,862 B1
Technology Center 3900
____________

Before ALLEN R. MacDONALD, JOHN A. JEFFERY, and
MICHAEL J. ENGLE, Administrative Patent Judges.

JEFFERY, Administrative Patent Judge.

DECISION ON APPEAL
Appellant1 appeals under 35 U.S.C. §§ 134 and 306 the Examiner’s
decision to reject claims 1–18. We have jurisdiction under 35 U.S.C. §§ 134
and 306.
We AFFIRM.

1 Appellant identifies the real party in interest as ChartIQ, Inc. Appeal Br. 2.
Appeal 2021-005311
Reexamination Control 90/014,377
Patent US 10,180,862 B1

2
STATEMENT OF THE CASE
This proceeding arose from a request for ex parte reexamination filed
on September 19, 2019 of United States Patent 10,180,862 (“the ’862
patent”), issued to Schleifer et al. on January 15, 2019.
The ’862 patent’s invention orchestrates interoperability between
mark-up language applications executable within a browser container
executing on a processing device. To this end, a desktop services module
(1) communicates with the applications; (2) determines an interaction in a
first application, and (3) generates an action command for the second
application based on an interoperability function. See Abstract. Claim 1 is
illustrative of the invention and is reproduced below:
1. A method for interoperability between a first
application and a second application, where both the first
application and the second application are mark-up language
applications executable within a browser container executing on
a processing device, the method comprising:

accessing a first exchange script in the first application
and a second exchange script in the second application;

executing the first application and the second application
on the processing device;

executing a desktop services module in communication
with the first application and the second application, the
desktop services module disposed between the first application
and the browser container and between the second application
and the browser container;

communicating between the first application and the
desktop services module using the first exchange script and
Appeal 2021-005311
Reexamination Control 90/014,377
Patent US 10,180,862 B1

3
communicating between the second application and the desktop
services module using the second exchange script;

orchestrating interoperability between the first
application and the second application by the desktop services
module determining an interaction in the first application via
the desktop services module and generating an action command
for the second application based on at least one interoperability
function;

performing a processing operation in the second
application based on the action command.

THE REJECTIONS
The Examiner rejected claims 1–5, 7, 10–14, and 16 under 35 U.S.C.
§ 102 as anticipated by Holmes (US 7,805,730 B2; issued Sept. 28, 2010).
Final Act. 15–38.2
The Examiner rejected claims 6, 9, 15, and 18 under 35 U.S.C. § 103
as unpatentable over Holmes and Keith W. Horwood, In-browser
Multithreading Made Easy, www.keithwhor.github.io/multithread.js (Mar.
5, 2015) (“Horwood”). Final Act. 39–40.
The Examiner rejected claims 8 and 17 under 35 U.S.C. § 103 as
unpatentable over Holmes and React – A Javascript Library for Building
User Interfaces, www.facebook.github.io/react (Nov. 19, 2013) (“React”).
Final Act. 40–41.

2 Throughout this opinion, we refer to (1) the Final Rejection mailed July 29,
2020 (“Final Act.”); (2) the Appeal Brief filed January 27, 2021 (“Appeal
Br.”); (3) the Examiner’s Answer mailed July 13, 2021 (“Ans.”); and (4) the
Reply Brief filed September 10, 2021 (“Reply Br.”).
Appeal 2021-005311
Reexamination Control 90/014,377
Patent US 10,180,862 B1

4
The Examiner rejected claims 1–5, 7, 8, 10–14, 16, and 17 under 35
U.S.C. § 102 as anticipated by OpenF2.3 Final Act. 42–49.
The Examiner rejected claims 6, 9, 15, and 18 under 35 U.S.C. § 103
as unpatentable over OpenF2 and Horwood. Final Act. 49–50.

THE ANTICIPATION REJECTION OVER HOLMES
The Examiner finds that Holmes discloses every recited element of
claim 1 including executing a desktop services module in communication
with first and second mark-up language applications executable within a
browser container, where the desktop services module is disposed between
(1) the first application and browser container, and (2) the second
application and the browser container. Final Act. 15–24. According to the
Examiner, Holmes orchestrates interoperability between the applications by
the desktop services module (1) determining an interaction in the first
application via the module; and (2) generating an action command for the

3 The Examiner’s citation to “OpenF2” refers to five documents collectively,
namely (1) OpenF2 Code – release 1.4.3,
github.com/OpenF2/F2/releases/tag/1.4.3 (May 11, 2017); (2) OpenF2 –
About F2, github.com/OpenF2/blob/e0eb9a2491e233a0f930993bf90216d
18cb64e44/docs/src/about-f2.md (Feb. 26, 2015); (3) OpenF2 – Container
Development, github.com/OpenF2/blob/e0eb9a2491e233a0f
930993bf90216d18cb64e44/docs/src/containerdevelopment.
md (May 11, 2017); (4) OpenF2 – App Development,
github.com/OpenF2/blob/e0eb9a2491e233a0f930993bf90216dl8ch64e44/do
cs/src/app-development.md (Feb. 26, 2015); and (5) OpenF2 – appclass.js,
github.com/OpenF2/blob/e0eb9a249le233a0f930993bf90216d8cb64e44
(Apr. 28, 2016). We reproduce the Examiner’s “OpenF2” nomenclature
here, but for clarity, we refer to and identify particular documents of this
group in our discussion.
Appeal 2021-005311
Reexamination Control 90/014,377
Patent US 10,180,862 B1

5
second application based on at least one interoperability function. Final Act.
21–23.
Appellant argues that Holmes does not disclose a desktop services
module, much less one that determines an interaction in the first application
and generates an action command in the second application as claimed.
Appeal Br. 17–24, 27–30; Reply Br. 2–11. According to Appellant, the
Examiner’s findings in this regard are erroneous because, among other
things, the Examiner ignores the “between” limitation recited in connection
with the desktop services module, namely that the desktop services module
is disposed between (1) the first application and browser container, and (2)
the second application and the browser container. Reply Br. 8–10.4

ISSUE
Under § 102, has the Examiner erred in rejecting claim 1 by finding
that Holmes discloses a desktop services module disposed between (1) a first
mark-up language application and a browser container executing on a
processing device, and (2) a second mark-up language application and the
container, where the applications are executable within that container?

4 Although Appellant also contends that the Examiner’s analysis under
functional equivalency is improper (Appeal Br. 32–34), the Examiner
nonetheless clarifies on page 12 of the Answer that the relevant limitations
were not construed as functional under 35 U.S.C. § 112(f), but rather recite
sufficient structure to avoid such a construction. This issue is, therefore,
moot.
Appeal 2021-005311
Reexamination Control 90/014,377
Patent US 10,180,862 B1

6
ANALYSIS
We begin by construing the key disputed limitation of claim 1 that
recites, in pertinent part, a “desktop services module.” Notably, the ’862
patent does not define the term “desktop services module,” unlike other
terms whose concrete definitions leave no doubt as to their meaning. See,
e.g., ’862 patent col. 2, ll. 17–20, 35–39; col. 5, ll. 25–29; col. 9, ll. 46–48,
57–60; col. 10, ll. 4–7 (defining the terms “browser container,”
“interoperability functions,” “browser executable,” “client API,” “processing
component,” “library,” and “router” explicitly). The ’862 patent does,
however, define the term “desktop service” in terms of a module, namely
“an active, independently-threaded JavaScript module providing centralized
functionality throughout a processing application.” ’862 patent col. 10, ll.
13–15 (emphasis added).
Although the ’862 patent does not define the term “module,” its
meaning is nonetheless established in the art. In computer programming, a
module is “a program unit or section that is set aside and differentiated from
other sections so that its procedural code can be made available to more than
one component of the program.” Bryan Pfaffenberger, WEBSTER’S NEW
WORLD COMPUTER DICTIONARY 241 (10th ed. 2003).
Therefore, under its broadest reasonable interpretation consistent with
these definitions, a “desktop services module” is an active, independently-
threaded module, namely a program unit or section that (1) is set aside and
differentiated from other sections so that its procedural code can be made
available to more than one program component, and (2) provides centralized
functionality throughout a processing application.
Appeal 2021-005311
Reexamination Control 90/014,377
Patent US 10,180,862 B1

7
Although the ’862 patent defines a “desktop service” in terms of a
JavaScript module in column 10, lines 13 to 15, the ’862 patent elsewhere
indicates that JavaScript is merely an exemplary form of a desktop services
module. See ’862 patent col. 5, ll. 36–37 (“For example, in one
embodiment[,] the desktop services module 152 is written in a JavaScript
language.”) (emphasis added). Given this exemplary and non-limiting
language, the recited “desktop services module” is not limited to JavaScript
consistent with the broadest reasonable interpretation of the term articulated
above.
The ’862 patent explains that although desktop services module 152
includes plural processing modules facilitating communication between
applications, the desktop services module is not exclusively connectivity, but
is also an “electronic brain” between the applications, and can use
interoperability functions to transform communications between
applications. ’862 patent col. 5, ll. 41–49. To this end, a desktop services
module can employ “conditional transformations” that allow a single action
in one application to mean different results or operations in other
applications. Id. at col. 5, ll. 49–53. In this way, intelligence within desktop
services modules orchestrate interoperability between applications. Id. at
col. 5, ll. 54–55.
The ’862 patent further explains that desktop services modules not
only deliver centralized functionality, they are also less likely to change than
processing components because, unlike components, desktop services
modules provide a basic building block functionality. ’862 patent col. 9, ll.
33–37.
Appeal 2021-005311
Reexamination Control 90/014,377
Patent US 10,180,862 B1

8
Given our interpretation of “desktop services module” in light of this
explanation in the ’862 patent, the Examiner’s finding that the ’862 patent
“does not appear to disclose an actual structure for the desktop services
module other than to vaguely state it acts as an undefined ‘electronic brain’”
(Ans. 10) is problematic, for it ignores the module’s key transformation
functionality that enables disparate applications to communicate with each
other, thus facilitating their interoperability as explained above.
Notably, the desktop services module’s disposition between (1) the
first application and browser container, and (2) the second application and
the browser container in claim 1 establishes the module’s relationship to the
two applications with respect to the browser container and, therefore, the
functional and logical relationship of the module’s transformation
functionality with respect to those elements.
Turning to the rejection, the Examiner does not say what particular
element in Holmes corresponds to the recited desktop services module. That
is, apart from merely quoting language from column 17, lines 31 to 34 and
column 4, lines 41 to 54 of Holmes, and reproducing Holmes’ Figure 2, the
Examiner does not articulate which particular element in that disclosure
corresponds to the recited desktop services module. See Final Act. 19–20.
Nor does the Examiner’s Answer articulate or clarify such a mapping. See
Ans. 3–12. These omissions and ambiguities in the Examiner’s findings
make our task of evaluating the merits of the Examiner’s anticipation
rejection all the more difficult.
Nevertheless, even assuming that the Examiner intends to map the
recited desktop services module to the container 220 or associated interface
Appeal 2021-005311
Reexamination Control 90/014,377
Patent US 10,180,862 B1

9
in connection with Holmes’ Common Component Framework (CCF), we
cannot say—nor has the Examiner shown—that these elements are
necessarily disposed between (1) a first application and browser container,
and (2) a second application and the browser container as claimed. To be
sure, Holmes’ CCF is an interface that can standardize communication
between plural web-based software components and a container associated
with those components. Holmes col. 4, ll. 24–26. In Figure 2, Holmes’
container 220 can be a client application object running within a container
application 210 that not only includes both CCF and non-CCF components,
but also implements the container side of the CCF interface. Holmes col. 4,
ll. 41–54. In a different configuration, multiple CCF components can run
within the same browser object 230, where objects and data passed between
the container and components may be native objects and data of a browser-
implemented JavaScript interpreter. Id. at col. 5, ll. 5–18.
Despite this interoperability functionality, we cannot say—nor has the
Examiner shown—that Holmes’s CCF interface or container 220 that
presumably corresponds to the recited desktop services module, is
necessarily disposed between (1) a first application and browser container,
and (2) a second application and the browser container as claimed—a crucial
requirement for inherent anticipation. See In re Robertson, 169 F.3d 743,
745 (Fed. Cir. 1999). As Appellant indicates, regardless of whether Holmes’
browser 230 or container includes a desktop services module, the Examiner
has still not shown that the desktop services module is necessarily disposed
between (1) a first application and browser container, and (2) a second
application and the browser container as claimed. See Reply Br. 10. To the
Appeal 2021-005311
Reexamination Control 90/014,377
Patent US 10,180,862 B1

10
extent Holmes’s column 14, lines 8 to 19 and column 10, lines 1 to 8 on
which the Examiner relies (Ans. 11–12) establish this necessary recited
disposition of the desktop services module, we cannot say on this record, nor
will we speculate in that regard here in the first instance on appeal. What we
can say, however, is that the Examiner’s findings in this regard fall short of
anticipating the recited desktop services module disposition.
Therefore, we are persuaded that the Examiner erred in rejecting (1)
independent claim 1; (2) independent claim 10 that recites commensurate
limitations; and (3) dependent claims 2–5, 7, 11–14, and 16 for similar
reasons. Because this issue is dispositive regarding our reversing the
Examiner’s rejection of these claims, we need not address Appellant’s other
associated arguments regarding Holmes.

THE OBVIOUSNESS REJECTIONS BASED ON HOLMES
Because the Examiner has not shown that Horwood or React cure the
foregoing deficiencies regarding the rejection of independent claims 1 and
10, we do not sustain the obviousness rejections of dependent claims 6, 8, 9,
15, 17, and 18 (Final Act. 39–41) for similar reasons.

THE ANTICIPATION REJECTION OVER OPENF2
Regarding claim 1, the Examiner finds that OpenF2 discloses every
recited element including executing a desktop services module in
communication with first and second mark-up language applications
executable within a browser container, where the desktop services module is
disposed between (1) the first application and browser container, and (2) the
Appeal 2021-005311
Reexamination Control 90/014,377
Patent US 10,180,862 B1

11
second application and the browser container. Final Act. 42–46. According
to the Examiner, OpenF2 orchestrates interoperability between the
applications by the desktop services module (1) determining an interaction
in the first application via the module; and (2) generating an action
command for the second application based on at least one interoperability
function. Final Act. 45–46.5
Appellant argues that OpenF2 does not disclose a desktop services
module, much less one that determines an interaction in the first application
and generates an action command in the second application as claimed.
Appeal Br. 24–28, 30–32; Reply Br. 11–12. According to Appellant,
OpenF2’s container, which is a web page, places the container between
applications (widgets) and browser unlike the claimed invention. Appeal Br.
31–32.

ISSUE
Under § 102, has the Examiner erred in rejecting claim 1 by finding
that OpenF2 discloses a desktop services module disposed between
(1) a first mark-up language application and a browser container executing
on a processing device, and (2) a second mark-up language application and
the container, where the applications are executable within that container,
where interoperability is orchestrated by the desktop services module

5 Although the Examiner cites page 31 of OpenF2’s “About F2” document
in connection with this finding (Final Act. 46), that document is only 10
pages. Nevertheless, the subject matter on which the Examiner relies in this
regard is disclosed on page 31 of OpenF2’s “Container Development”
document.
Appeal 2021-005311
Reexamination Control 90/014,377
Patent US 10,180,862 B1

12
(a) determining an interaction in the first application, and (b) generating an
action command for the second application based on an interoperability
function?

ANALYSIS
We begin by noting, as with the first anticipation rejection, the
Examiner does not articulate explicitly what particular element in OpenF2
corresponds to the recited desktop services module. Nevertheless, because
the associated subject matter on which the Examiner relies refers repeatedly
to the functionality of OpenF2’s F2 container in connection with the recited
desktop services module’s functionality (see Final Act. 44–46), we presume
the Examiner intends to map the recited desktop services module to
OpenF2’s F2 container.
A key aspect of OpenF2 is the ability of applications or “apps” to
share “context” with a container and other nearby apps, where the container
is a web page that (1) is aware of its contents, namely the apps, and
(2) manages context passing between the apps. OpenF2 “About F2” at 6–7.
In this sense, the container effectively functions as a “traffic cop” by
“managing which data goes where.” Id. at 7.
The F2 container is the layer between the browser and apps, and the
location where apps reside. OpenF2 “About F2” at 7. Notably, apps must
communicate via an F2 container to other apps. Id.
Given this functionality, the F2 container fully meets the recited
desktop services module under the term’s broadest reasonable interpretation.
That is, the F2 container is an active, independently-threaded module,
Appeal 2021-005311
Reexamination Control 90/014,377
Patent US 10,180,862 B1

13
namely a program unit or section that (1) is set aside and differentiated from
other sections so that its procedural code can be made available to more
than one program component, including other web pages and apps, and
(2) provides centralized functionality throughout a processing application, at
least with respect to the apps. In short, the F2 container is a “desktop
services module” consistent with our interpretation of the term articulated
previously.
Appellant’s contention, then, that OpenF2 ostensibly does not disclose
a desktop services module because it does not need or want one (Appeal Br.
32) is unavailing and not commensurate with the scope of the claim that
does not preclude the functionality of OpenF2’s F2 container noted above.
OpenF2’s F2 container is also effectively disposed between (1) a first
application and browser container, and (2) a second application and the
browser container as claimed despite Appellant’s contentions to the
contrary. See Appeal Br. 31–32.
In reaching this finding, we first note that the ’862 patent defines a
“browser container” as “a processing module including at least a portion of
browser software with additional processing code for engaging with the
operating system, e.g. hooks.” ’862 patent col. 2, ll. 17–20. OpenF2’s
browser on page 7 of the “About F2” document fully meets this definition
since the browser is a processing module that includes at least a portion of
browser software and has code for engaging with the operating system, at
least to the extent that the browser can be launched and terminated within
that operating system.
Appeal 2021-005311
Reexamination Control 90/014,377
Patent US 10,180,862 B1

14
Our emphasis on the term “browser” underscores that it is OpenF2’s
browser that corresponds to the recited “browser container”—not the F2
container that, despite its nomenclature, is a web page whose functionality
enables its constituent apps to communicate with each other, thus
corresponding to the recited desktop services module as noted previously.
For clarity, the disclosed relationships and functionalities of OpenF2’s
browser, F2 container, and apps are shown graphically below:

Graphical representation of functional and logical relationship between
OpenF2’s browser, F2 container, and apps

Appeal 2021-005311
Reexamination Control 90/014,377
Patent US 10,180,862 B1

15
As shown above, OpenF2’s desktop services module, namely the F2
container, is effectively between (1) a first application, namely “App 1,” and
a browser container, namely the browser, and (2) a second application,
namely “App 2,” and the browser container as claimed. Appellant’s
arguments to the contrary (Appeal Br. 31–32; Reply Br. 12) are, therefore,
unavailing.
In addition, OpenF2’s desktop services module, namely the F2
container, effectively (1) determines an interaction in a first application, and
(2) generates an action command for a second application based on an
interoperability function, namely “one or more rules or conditions that allow
for interoperability of applications, using system defines and/or user-defined
rules or conditions based on an event or occurrence in one application
[a]ffecting at least a second application.” See ’862 patent col. 2, ll. 34–40
(defining the term “interoperability functions”).
As OpenF2’s “Container Development” document explains on page
31, apps communicate with each other via the container. To this end, the
container (1) listens for events sent by apps, and (2) broadcasts or emits an
associated JavaScript event to a target app. OpenF2 “Container
Development” at 30–31; OpenF2 “About F2” at 6–7; OpenF2 “App
Development” at 22.
Given this functionality, OpenF2’s container effectively determines an
interaction in a first application by detecting an event sent by that
application. See OpenF2 “Container Development” at 30–31; OpenF2
“About F2” at 6–7; OpenF2 “App Development” at 22. We reach this
finding noting that not only does the ’862 patent use the term “interaction”
Appeal 2021-005311
Reexamination Control 90/014,377
Patent US 10,180,862 B1

16
quite broadly in connection with “a processing occurrence” in column 9,
lines 3 and 4, the ’862 patent merely provides non-limiting examples of
these interactions in the first application as a user entering text, selecting an
icon or hyperlink, etc. That the broad and open-ended term “etc.” is used in
column 11, line 4 of the ’862 patent underscores the scope and breadth of
these exemplary interactions. Given this breadth, nothing in the claim
precludes OpenF2’s F2 container determining the events sent by the first
application as effectively determining an interaction, namely a processing
occurrence, in that application. Appellant’s arguments to the contrary
(Appeal Br. 24–28) are unavailing and not commensurate with the scope of
the claim.
In addition, by broadcasting or emitting an associated JavaScript event
to a target app, OpenF2’s F2 container effectively generates an action
command for a second application based on an interoperability function as
claimed. See OpenF2 “Container Development” at 30–31; OpenF2 “About
F2” at 6–7; OpenF2 “App Development” at 22. We reach this finding
noting that the ’862 patent does not define the term “action command”
unlike other terms whose concrete definitions leave no doubt as to their
meaning. See, e.g., ’862 patent col. 2, ll. 17–20, 35–39; col. 5, ll. 25–29;
col. 9, ll. 46–48, 57–60; col. 10, ll. 4–7 (defining the terms “browser
container,” “interoperability functions,” “browser executable,” “client API,”
“processing component,” “library,” and “router” explicitly). That the ’862
patent notes that action commands are illustrated as event messages in
column 9, lines 6 to 8 underscores that these event messages are reasonably
consistent with the JavaScript events that OpenF2’s F2 container sends to
Appeal 2021-005311
Reexamination Control 90/014,377
Patent US 10,180,862 B1

17
target apps. See OpenF2 “Container Development” at 31. Appellant’s
arguments to the contrary (Appeal Br. 24–28) are, therefore, unavailing and
not commensurate with the scope of the claim.
Therefore, we are not persuaded that the Examiner erred in rejecting
claim 1, and claims 2–5, 7, 8, 10–14, 16, and 17 not argued separately with
particularity.

THE OBVIOUSNESS REJECTION OVER OPENF2 AND HORWOOD
We also sustain the Examiner’s obviousness rejection of claims 6, 9,
15, and 18. Final Act. 49–50. Because this rejection is not argued
separately with particularity, we are not persuaded of error in this rejection
for the reasons previously discussed.

CONCLUSION
The Examiner’s decision to reject claims 1–18 is affirmed.
DECISION SUMMARY
In summary:
Claim(s)
Rejected
35 U.S.C.
§
Reference(s)/Basis Affirmed Reversed
1–5, 7, 10–
14, 16
102 Holmes 1–5, 7, 10–
14, 16
6, 9, 15, 18 103 Holmes, Horwood 6, 9, 15, 18
8, 17 103 Holmes, React 8, 17
1–5, 7, 8,
10–14, 16,
17
102 OpenF2 1–5, 7, 8,
10–14, 16,
17

6, 9, 15, 18 103 OpenF2, Horwood 6, 9, 15, 18
Appeal 2021-005311
Reexamination Control 90/014,377
Patent US 10,180,862 B1

18
Overall
Outcome
1–18

REQUESTS FOR EXTENSIONS OF TIME
Requests for extensions of time in this ex parte reexamination
proceeding are governed by 37 C.F.R. § 1.550(c). See 37 C.F.R. § 41.50(f).

AFFIRMED

cc Third Party Requester:

LEASON ELLIS, LLP
ONE BARKER AVENUE, FIFTH FLOOR
WHITE PLAINS, NY 10601-1526