InvestCloud Inc

Patent Trials and Appeals Board

May 8, 2020

2019001501 (P.T.A.B. May. 8, 2020)

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/630,577 02/24/2015 Vicent Sos-Munoz INVESTCLOUD-0120-US 1807
65449 7590 05/08/2020
PATENT INGENUITY, P.C.
9701 Wilshire Boulevard
Suite 1000
Beverly Hills, CA 90212
EXAMINER
CHOUAT, ABDERRAHMEN
ART UNIT PAPER NUMBER
2451
NOTIFICATION DATE DELIVERY MODE
05/08/2020 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):
patents@patentingenuity.com
ssimpson@patentingenuity.com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
BEFORE THE PATENT TRIAL AND APPEAL BOARD
Ex parte VICENT SOS-MUNOZ, JOHN W. WISE, and
JULIAN BOWDEN
Appeal 2019-001501
Application 14/630,577
Technology Center 2400
Before MICHAEL J. ENGLE, PHILLIP A. BENNETT, and
SCOTT RAEVSKY, Administrative Patent Judges.
RAEVSKY, Administrative Patent Judge.
DECISION ON APPEAL
Pursuant to 35 U.S.C. § 134(a), Appellant1 appeals from the
Examiner’s decision to reject claims 1 and 11, all the pending claims in this
application. We have jurisdiction under 35 U.S.C. § 6(b).
We AFFIRM.

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
InvestCloud Inc. Appeal Br. 2.
Appeal 2019-001501
Application 14/630,577

2
CLAIMED SUBJECT MATTER
The claims relate to messaging protocols for communication between
computing devices. Spec. ¶ 2. Claim 1, reproduced below, is illustrative of
the claimed subject matter:
1. A method comprising:
composing, at a first computing device via first
application code, a plurality of messages according to a
messaging protocol that has a single predetermined immutable
message structure for communicating with a second computing
device independent of an update to contents of a function at the
second computing device, the single predetermined immutable
message structure identifying a message structure for contents
of a function call sent from the first computing device to the
second computing device to perform the function via a web
service, the single predetermined immutable message structure
being stored by the first computing device and the second
computing device prior to transmission of a subset of the
plurality of messages from the first computing device to the
second computing device such that the second computing
device understands a format of the subset of the plurality of
messages prior to the transmission; and
sending, from the first computing device to the second
computing device via the single predetermined immutable
message structure, the subset of the plurality of messages
having the function call to the second computing device
subsequent to the update of the function at the second
computing device, without the first application code being
recompiled by the first computing device based on the update to
the contents of the function at the second computing device,
such that the second computing device partially performs the
function with data from the function call, as understood by the
second computing device according to the single predetermined
immutable message structure, upon the second computing
device being unable to fully perform the function after the
function is updated.

Appeal 2019-001501
Application 14/630,577

3
REJECTION
Claims 1 and 11 stand rejected under 35 U.S.C. § 103 as being
unpatentable over Lehman (US 2002/0056047 A1, May 9, 2002) and Stack
Overflow (“Adding methods to the webservice: do old clients need to update
web references,” 2010). Final Act. 5.
ANALYSIS
Appellant contends that the Examiner fails to establish that the
combination of Lehman and Stack Overflow renders claim 1 obvious,
arguing three separate limitations of claim 1. Appeal Br. 7–12; Reply Br. 2–
7. We address each in turn.
I.
Appellant first addresses the following limitation of claim 1: “such
that the second computing device partially performs the function with data
from the function call . . . upon the second computing device being unable to
fully perform the function after the function is updated.” Appeal Br. 7–9;
Reply Br. 2–4. Specifically, Appellant contends, combining Stack Overflow
with Lehman for this limitation would “render[] Lehman unsatisfactory for
its intended purpose.” Appeal Br. 8.
Appellant contends, “the whole point of Lehman is to be able to use a
development device (e.g., PC) to fully perform the functionality of an
embedded device (e.g., mobile device) during debugging so that the hard-to-
find errors may be detected.” Id. Appellant further contends that “only
partially perform[ing] a function that has been updated on the embedded
device, because the development device does not have that update, would
prevent a thorough debugging of the updated function.” Id. To illustrate its
point, Appellant describes the following scenario: “if the application device
Appeal 2019-001501
Application 14/630,577

4
[in Lehman] is unaware of a function updated on an embedded device, the
application device will not even know how to debug that updated function.
As a result, the updated functionality would not get tested, thereby rendering
Lehman unsatisfactory for its intended purpose.” Id.
The Examiner finds, “Even though Lehman teaches additional
features and functionality[, that] does not preclude Lehman from being
combinable with StackOverflow.” Ans. 4. The Examiner further finds that
Lehman’s “system is nearly identical [to Stack Overflow] and includes
similarities in communication, as well as message structure, and further is
used for updating applications in a web based environment.” Id. In
addition, the Examiner finds, “StackOverflow teaches that non-breaking
changes on the server side [are] applicable and combinable to Lehman,” and
“it would be obvious to want to update a function, for testing reasons and
may not want [to] disable previous functionality.” Id.; see also Final Act. 8.
In Reply, Appellant contends, “Lehman is directed toward a debugging
environment, which would typically be understood by one of ordinary skill
in the art as working best with full performance of a function.” Reply Br. 2–
3.2
Appellant’s arguments are unpersuasive. We disagree with
Appellant’s fundamental premise that Lehman’s intended purpose “is to be
able to use a development device (e.g., PC) to fully perform the functionality
of an embedded device (e.g., mobile device) during debugging so that the

2 The Reply Brief responds to additional Examiner findings related to
“reduc[ing] the amount of times an update at the client must occur” (Ans. 4),
but as we do not rely on these additional Examiner findings, we need not
address Appellant’s additional arguments. See Reply Br. 3–4.
Appeal 2019-001501
Application 14/630,577

5
hard-to-find errors may be detected.” Appeal Br. 8. Appellant points to two
paragraphs in Lehman that purportedly establish this intended purpose, but
neither paragraph supports Appellant’s argument. Id. (citing Lehman ¶¶ 16,
4). For instance, Appellant points to Lehman’s teaching that “[d]uring the
development stage . . . the application software may be loaded from the
development device (the ‘host’) to the embedded device or an equivalent
hardware platform for software development (the ‘target’) for debugging and
testing purposes.” Id. (citing Lehman ¶ 16). But merely loading an
application for debugging and testing purposes does not require “fully
perform[ing] the functionality of an embedded device . . . during
debugging.” See id. Appellant then cites Lehman’s “numerous examples”
of finding errors, including “program errors may only become evident after
an extended period of operation,” “error may only become evident once the
application is run in conjunction with the actual hardware platform,”
“detecting such errors often requires the developer to communicate with a
running device and retrieve diagnostic information form the device,” and
“the need may still arise in the future to connect to the device for
maintenance purposes and patch or update the functionality of the
application program.” Id. (citing Lehman ¶ 4) (emphasis added and
omitted). None of these examples requires fully performing the functionality
of the embedded device during debugging.
To the contrary, while one of ordinary skill in the art would have
understood that one could use Lehman’s system to debug every line of code
in a function or application, Lehman actually suggests the opposite, i.e., that
one might not always debug every single line of a function or other code.
For example, Lehman states, “[d]ebugging programs may find the errors by
Appeal 2019-001501
Application 14/630,577

6
stepping through the application programs one operation at a time.” Lehman
¶ 3. One of ordinary skill in the art would have understood from this
teaching that once an error is found, which could occur before an entire
function or program is fully stepped through, debugging of that function
could be halted. This is particularly the case where “program errors may
only become evident after an extended period of operation” because after an
application has been released, a developer would not necessarily need to
debug an entire function or the entire application to find the errors. See
Lehman ¶ 4.
As we disagree with Appellant’s characterization of Lehman’s
intended purpose, Appellant’s arguments based on that characterization do
not persuade us that modifying Lehman with Stack Overflow would have
rendered Lehman unsatisfactory for its intended purpose.
II.
Appellant next addresses the following limitation of claim 1:
sending . . . the subset of the plurality of messages having
the function call to the second computing device subsequent to
the update of the function at the second computing device,
without the first application code being recompiled by the first
computing device based on the update to the contents of the
function at the second computing device.
Appeal Br. 9–10; Reply Br. 4–6.
Appellant initially contends that the combination of Lehman and
Stack Overflow “does not teach sending the subset subsequent to the update
of a function, without the first application code being recompiled.” Appeal
Br. 9. Specifically, Appellant contends that, in Stack Overflow,
“implementing a new function or a change to a type does not correspond to a
function update.” Id. Appellant asserts that a Web Services Description
Appeal 2019-001501
Application 14/630,577

7
Language (WSDL) file “uses the term ‘type’ quite specifically to refer to
‘[d]escrib[ing] the data’ via XML Schema Definition (‘XSD’).” Id. (citing
Wikipedia).
The Examiner finds, “[t]he claims and the specification do not limit
the types of updates of the function in any manner differentiating between a
breaking and non-breaking change, that is a change that requires a change in
signature.” Ans. 5. The Examiner also finds, “Appellant[’]s own
specification indicate[s] an update can be a function parameter [0041].
Parameter updates are taught by StackOverflow [bottom of page 1] . . . [:] if
the method has added fields and properties [to a type,] Product A can still be
used for old functionality without rebuilding.” Id. Appellant’s Reply Brief
does not address this finding.
Appellant’s argument is unpersuasive. Stack Overflow teaches that
“adding new fields/properties to a type[] are almost always non-breaking
changes.” Stack Overflow 1. As explained above, the Examiner finds that
Stack Overflow’s teaching regarding adding fields or properties to a type
describes a function update. Ans. 5. In the Appeal Brief, Appellant’s
argument that adding new fields/properties to a type is not a function update
relies on a Wikipedia definition of “type.” Due to the constantly changing
nature of Wikipedia, a citation to Wikipedia may be of limited value here.
Moreover, Wikipedia is not always considered to be a reliable source.3 In

3 See, e.g., Ex parte Three-Dimensional Media Grp., Ltd., 2010 WL
3017280, at *17 (BPAI 2010) (“Wikipedia is generally not considered to be
as trustworthy as traditional sources for several reasons, for example,
because (1) it is not peer reviewed; (2) the authors are unknown; and (3)
apparently anyone can contribute to the source definition”); see also Bing
Shun Li v. Holder, 400 F. App’x 854, 857 (5th Cir. 2010) (noting
Appeal 2019-001501
Application 14/630,577

8
any event, the Examiner’s phrase (“do not limit the types of updates of the
function in any manner”) does not refer to the same “type” Appellant points
to in the WSDL Wikipedia entry. For example, although Appellant argues
that changes to a function’s signature require recompilation on the client,
e.g., Reply Br. 5, the Examiner is correct that claim 1 is not limited to
updates of a signature but instead recites “update of the function” and
“update to contents of a function,” and Stack Overflow recognizes that
updates to things other than a signature can be “non-breaking” changes that
do not require recompilation.4 Ans. 5; Stack Overflow 1. Accordingly,
Appellant does not persuade us of Examiner error.
Appellant next contends that one of ordinary skill in the art would not
have combined Stack Overflow with Lehman because Stack Overflow
teaches away from avoiding recompilation when a function has been
updated. Appeal Br. 9–10; Reply Br. 4–6. Specifically, Appellant contends,
“the Final Office Action appears to contend that the combination of Lehman
and StackOverflow advocates for avoiding recompilation but also appears to
ignore the remainder of StackOverflow, which teaches away from avoiding
recompilation.” Appeal Br. 10. For example, Appellant cites Stack

Wikipedia's unreliability and citing Badasa v. Mukasey, 540 F.3d 909, 910–
11 (8th Cir. 2008)).

4 For example, one of ordinary skill in the art would have understood that
functionality could be added to a function’s internals (such as the creation of
a new variable or some new mathematical operation), which would not
change the signature of the function. In that instance, one of ordinary skill
in the art would have understood that the client-side code would not need to
be recompiled to continue to access the function, as it is only the internal
workings of the function (i.e., “the contents”) on the server that have been
updated.
Appeal 2019-001501
Application 14/630,577

9
Overflow’s teaching that the “[b]est practice” is to “[b]e sure to regenerate
your client side artifacts any time you receive an updated WSDL file.” Id.
(citing Stack Overflow 2) (emphasis added). Appellant continues,
While one portion of StackOverflow (referred to by the
Final Office Action) appears to allow for avoiding
recompilation in certain non-function update instances, another
portion of StackOverflow suggests that the best practice is to
recompile “any time” an updated WSDL file (e.g., new method
or new field/property of a type) is received because problems
have occurred as a result of not performing recompilation.
Id. (emphasis added).
In the Final Action, the Examiner finds Lehman teaches or suggests
claim 1’s “an update to contents of a function at the second computing
device.” Final Act. 5 (emphasis omitted). The Examiner finds Stack
Overflow teaches or suggests the claimed “sending, from the first computing
device to the second computing device . . . messages . . . subsequent to the
update of the function at the second computing device, without the first
application code being recompiled by the first computing device.” Id. at 7–8
(emphasis omitted).
Appellant’s argument is unpersuasive. While one of Stack
Overflow’s users opines that client side artifacts should be regenerated any
time an updated WSDL file is received, another user opines that many
changes are almost always non-breaking. Stack Overflow 1–2. These two
opinions merely represent alternatives, and disclosure of an alternative
method does not teach away from the use of a claimed method. In re Dunn,
349 F.2d 433, 438 (CCPA 1965); DePuy Spine, Inc. v. Medtronic Sofamor
Danek, Inc., 567 F.3d 1314, 1327 (Fed. Cir. 2009) (“A reference does not
teach away [. . .] if it merely expresses a general preference for an alternative
Appeal 2019-001501
Application 14/630,577

10
invention[.]”). Accordingly, Appellant does not persuade us of Examiner
error.
III.
Appellant’s final argument addresses the following limitation of claim
1: “composing, at a first computing device via first application code, a
plurality of messages according to a messaging protocol that has a single
predetermined immutable message structure for communicating with a
second computing device independent of an update to contents of a function
at the second computing device.” Appeal Br. 11–12; Reply Br. 6–7.
Appellant contends that the combination of Lehman and Stack
Overflow would “result[] in a data structure that is changed in certain
instances (i.e. a change to a method signature is a change to the data
structure . . . ) but possibly . . . not changed in other instances (changes other
than to existing functions).” Appeal Br. 11. Appellant contends,
Accordingly, even if the data structure of Lehman was
considered to be immutable by itself, it would not be considered
immutable in the combination with StackOverflow because
StackOverflow would modify the data structure of Lehman to
change in certain instances and possibly not change (although
not suggested as the best practice) in other instances.
Id. Appellant further contends, “Since the data structure in the combination
of Lehman and StackOverflow changes in at least certain instances, it simply
cannot be considered immutable after a function update, as recited by claims
1 and 11.” Id.
Appellant further contends, “StackOverflow is quite clear that if an
updated function is used by Product A, the signature for that function would
have to be changed as a requirement.” Id. at 12. Thus, Appellant contends,
“the resulting data structure in the combination of Lehman and
Appeal 2019-001501
Application 14/630,577

11
StackOverflow cannot be immutable: it changes in certain instances.” Id.
Appellant concludes that “one of ordinary skill in the art would [not] have
any reasonable expectation of success in ‘maintaining an immutable
message of structure’ of Lehman when StackOverflow clearly provides
instances when the immutable message structure should be changed.” Id.
The Examiner finds, and we agree, that Stack Overflow teaches that at
least in some instances “the client side does not have to be updated, that is
users can still use the function.” Ans. 6. As we noted above, Stack
Overflow teaches that many changes “are almost always non-breaking
changes.” Stack Overflow 1. Appellant’s arguments do not persuasively
rebut the Examiner’s findings in this regard. Accordingly, we find
Appellant’s arguments unpersuasive.
We, therefore, sustain the rejection of claim 1, along with the rejection
of independent claim 11 argued collectively with claim 1. See 37 C.F.R.
§ 41.37(c)(1)(iv).
CONCLUSION
In summary:
Claims
Rejected
35
U.S.C. § 
Reference(s)/Basis Affirmed Reversed
1, 11 103 Lehman, Stack
Overflow
1, 11
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