Microsoft Technology Licensing, LLC

Patent Trials and Appeals Board

Oct 20, 2020

2019002039 (P.T.A.B. Oct. 20, 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.
15/152,509 05/11/2016 Mathew I. Charles 338748-US-CNT 7465
69316 7590 10/20/2020
MICROSOFT CORPORATION
ONE MICROSOFT WAY
REDMOND, WA 98052
EXAMINER
WOOD, WILLIAM C
ART UNIT PAPER NUMBER
2193
NOTIFICATION DATE DELIVERY MODE
10/20/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):
chriochs@microsoft.com
usdocket@microsoft.com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
BEFORE THE PATENT TRIAL AND APPEAL BOARD
Ex parte MATHEW I. CHARLES
Appeal 2019-002039
Application 15/152,509
Technology Center 2100

Before JEFFREY S. SMITH, MICHAEL J. STRAUSS, and
DAVID J. CUTITTA II, Administrative Patent Judges.

CUTITTA, 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–20, all the claims under
consideration. 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 Microsoft
Technology Licensing. Appeal Br. 1.
Appeal 2019-002039
Application 15/152,509

2
CLAIMED SUBJECT MATTER
Invention
Appellant’s claimed subject matter relates to “providing backend
custom code extensibility” that “allows custom code to be automatically
loaded dynamically in a runtime that is hosted by a BaaS [(backend-as-a-
service)] module while the runtime is running to provide custom backend
features that are defined by the custom code.” Spec. ¶ 4.2
Exemplary Claim
Claims 1, 9, and 17 are independent. Claim 1, reproduced below,
exemplifies the claimed subject matter:
1. A method of providing backend custom code
extensibility, the method comprising:
receiving custom code that defines custom backend
features from a user for incorporation into a backend-as-a-
service module that is configured to provide a backend service
to a corresponding application; and
in response to receipt of a request from the corresponding
application, automatically loading the custom code dynamically
in a runtime hosted by the backend-as-a-service module while
the runtime is running, using at least one element that includes
at least one of (a) one or more processors, (b) physical
hardware, or (c) electrical circuitry, to provide the custom
backend features that are defined by the custom code to the
corresponding application.
Appeal Br. A1 (Claims Appendix).

2 We refer to: (1) the originally filed Specification filed May 11, 2016
(“Spec.”); (2) the Final Office Action mailed February 22, 2018 (“Final
Act.”); (3) the Appeal Brief filed September 22, 2018 (“Appeal Br.”); (4) the
Examiner’s Answer mailed November 14, 2018 (“Ans.”); and (5) the Reply
Brief filed January 14, 2019 (“Reply Br.”).
Appeal 2019-002039
Application 15/152,509

3
REFERENCES
The Examiner relies on the following prior art references.3
Name Reference Date
Igotti US 2003/0033443 A1 Feb. 13, 2003
Bhaskaran US 6,732,364 B1 May 4, 2004
O’Brien US 2007/0074187 A1 Mar. 29, 2007
Harvey US 2008/0005729 A1 Jan. 3, 2008
Williams US 2010/0180270 A1 July 15, 2010
Yu US 7,774,428 B2 Aug. 10, 2010
REJECTIONS
The Examiner makes the following rejections:
Claims 35 U.S.C. Basis
Final
Act.
1, 9, 17 § 103 Harvey, Bhaskaran 2
2, 10, 18 § 103 Harvey, Bhaskaran, Igotti 9
3–6, 11, 12, 14, 15, 19,
20
§ 103 Harvey, Bhaskaran, Yu 11
7, 13 § 103 Harvey, Bhaskaran, O’Brien 19
8, 16 § 103 Harvey, Bhaskaran, Williams, Yu 20
OPINION
We review the appealed rejections for error based upon the issues
identified by Appellant and in light of Appellant’s arguments and evidence.
Ex parte Frye, 94 USPQ2d 1072, 1075 (BPAI 2010) (precedential).
Arguments not made are waived. See 37 C.F.R. § 41.37(c)(1)(iv) (2017).
We disagree with Appellant that the Examiner erred and adopt as our own
the findings and reasons set forth by the Examiner to the extent consistent
with our analysis herein. Final Act. 2–22; Ans. 3–8. We add the following
primarily for emphasis.

3 All citations to the references use the first-named inventor or author only.
Appeal 2019-002039
Application 15/152,509

4
Claim 1 recites “receiving custom code that defines custom backend
features from a user for incorporation into a backend-as-a-service module
that is configured to provide a backend service to a corresponding
application.” Appeal Br. A1. The Examiner relies on Harvey to teach or
suggest this limitation. Final Act. 3–4; Ans. 3–7. In particular, the
Examiner relies on Harvey’s description of “generat[ing] system
specifications from user input.” Id. (citing Harvey ¶¶ 9, 10).
Appellant argues that “nothing in Harvey mentions anything about
‘receiving custom code that defines custom backend features from a user for
incorporation into a backend-as-a-service module that is configured to
provide a backend service to a corresponding application,’ as recited by
independent claim 1.” Appeal Br. 8.
The Examiner responds,
A review of the instant specification reveals no explicit definition
or limiting example of “custom code” thereby requiring a
broadest reasonable interpretation analysis. Appellant offers no
definition of the term or any reference in the instant specification
that would suggest specifics. The specification does provide a
nonlimiting example of custom code in ¶ 0019 as being
“business logic.” Custom code may be reasonably interpreted to
include system specifications as defined in Harvey.
Ans. 4.
Appellant’s argument that Harvey does not mention receiving custom
code is unpersuasive because Appellant fails to establish that the Examiner’s
interpretation of “custom code” as recited in claim 1, is not the broadest
reasonable interpretation consistent with Appellant’s Specification. In re
Am. Acad. of Sci. Tech Ctr., 367 F.3d 1359, 1364 (Fed. Cir. 2004). In
response to the Examiner’s interpretation, Appellant argues that the
Examiner must construe “custom code” to mean business logic. Reply Br. 2.
Appeal 2019-002039
Application 15/152,509

5
Appellant, providing several dictionary definitions of business logic, argues
“the Examiner has misinterpreted the term.” Id. at 2–3. Appellant, however,
does not address the Examiner’s determination that the Specification merely
provides business logic as a non-limiting example of custom code and
therefore “reveals no explicit definition or limiting example of ‘custom
code.’” Ans. 4.
Appellant further argues the Examiner’s interpretation of custom code
is unreasonable because “persons experienced in the field of application
development know that system specifications, as described by Harvey, do
not constitute custom code, as mentioned in Applicant's claim 1.” Appeal
Br. 10. We agree with the Examiner that “[n]o evidence is provided to
support such assertions.” Ans. 6. Mere attorney argument and conclusory
statements unsupported by factual evidence are entitled to little probative
value. In re Geisler, 116 F.3d 1465, 1470 (Fed. Cir. 1997); see also In re De
Blauwe, 736 F.2d 699, 705 (Fed. Cir. 1984). Nor can such argument take
the place of evidence lacking in the record.
Appellant, therefore, fails to demonstrate that the Examiner’s
interpretation of custom code as encompassing Harvey’s system
specifications is inconsistent with Appellant’s Specification or is otherwise
unreasonable. In re Smith Int’l, Inc., 871 F.3d 1375, 1382–83 (Fed. Cir.
2017).
Next, the Examiner finds that “[a]llowing users to define system
specifications is analogous to receiving system specifications from a user”
(Final Act. 25). According to Appellant, “the front-end application
generating the system specifications from user input, as described by
Harvey, is not the same as receiving the system specifications from the user”
Appeal 2019-002039
Application 15/152,509

6
because “allowing users to define system specifications is not analogous to
receiving system specifications from a user at all, much like allowing a user
to define specifications that are used by a tailor to construct a suit is not
analogous to receiving the suit from the user” (Appeal Br. 8–9).
The Examiner responds by (1) finding that “Ultimately, [Harvey’s]
system receives the system specifications from the user, regardless of where
they are built” and (2) determining that the “claim limitation in question
does not require that the system specifications (or custom code) be defined
in a particular location or by a particular entity.” Ans. 4.
Appellant’s argument is unpersuasive because, as the Examiner notes,
Appellant offers insufficient evidence that generating system specifications
from user input fails to teach receiving system specification from a user. Id.
at 5. Appellant’s analogy involving the creation of a garment is
unpersuasive because, as noted by the Examiner, any relevance to the issue
at hand is obscure at best.
Next, Appellant argues that “‘analogous’ is not the appropriate legal
standard for establishing a prima facie case of obviousness.” Appeal Br. 9.
The Examiner clarifies that “analogous,” as used in the rejection, is merely
synonymous with similarity or equivalence. Ans. 5. Appellant, in turn, fails
to persuasively establish why the Examiner’s finding, that Harvey’s user
defined system specifications is similar or equivalent to receiving system
specifications from a user, is insufficient to establish that Harvey teaches or
suggests the limitation at issue.
The Examiner finds that “Harvey discloses a backend module . . . that
maps to a backend-as-a-service module as recited in the claim” and that
receives system specifications. Final Act. 25. Appellant argues that “the
Appeal 2019-002039
Application 15/152,509

7
system specifications in Harvey are not incorporated into the backend
application” because the Examiner’s interpretation of incorporated is
unreasonably broad in view of a dictionary definition of the term. Appeal
Br. 11 (emphasis added); Reply Br. 3–4.
Appellant’s argument is unpersuasive because, absent evidence that
the Examiner’s claim interpretation is inconsistent with the Specification,
even if Appellant can point to definitions or usages that conform to their
interpretation, this does not make the PTO’s interpretation unreasonable
when the PTO can point to other sources that support its interpretation. In re
Morris, 127 F.3d 1048, 1056 (Fed. Cir. 1997). Because Appellant provides
insufficient evidence that the Examiner’s claim interpretation is inconsistent
with the Specification or otherwise unreasonable, this argument is
unpersuasive. Accordingly, Appellant fails to demonstrate why Harvey’s
disclosure of a backend module that receives system specifications from a
user does not teach that the specifications are incorporated into the backend
module.
Claim 1 also recites “in response to receipt of a request from the
corresponding application, automatically loading the custom code
dynamically in a runtime hosted by the backend-as-a-service module while
the runtime is running.” Appeal Br. A1. The Examiner relies on Bhaskaran
to teach or suggest this limitation. Final Act. 4–5; Ans. 7–8. In particular,
the Examiner relies on Bhaskaran’s description of dynamically loading
Awarelets into a runtime instantiation. Id. (citing Bhaskaran 5:21–24, 7:7–
17, 8:65–9:4).
Appellant argues that “the Awarelets in Bhaskaran are not
automatically loaded dynamically in a runtime hosted by the Awarelet
Appeal 2019-002039
Application 15/152,509

8
backend services.” Appeal Br. 15. The Examiner responds by pointing out
Bhaskaran discloses that “The Awarelet Container 103 acts as a host for the
derived Awarelets 101” and that it “dynamically loads various derived
Awarelets based on the configuration information from an Awarelet
Repository 105.” Ans. 7 (citing Bhaskaran 5:21–24).
Appellant’s argument that Bhaskaran does not teach Awarelets being
loaded dynamically is unpersuasive because the Examiner-cited portion of
Bhaskaran specifically indicates that the Awarelets are dynamically loaded.
Next, Appellant argues that “Awarelets being loaded during runtime,
as described by Bhaskaran, is not the same as the Awarelets being
automatically loaded dynamically in a runtime while the runtime is running”
and that “deploying the Awarelets into a runtime instantiation of an
awareness engine (e.g., AOL instant messaging) does not constitute
dynamically deploying components into a runtime.” Appeal Br. 16–17.
In response, the Examiner points to Bhaskaran’s disclosure of
deploying components into a runtime:
“It is up to an Application Developer to determine the
configuration during build time, and also instruct the Awarelet
Container to load various Awarelets during runtime.” . . . “An
Awarelet Repository 105 provides storage for the derived
Awarelets 101 and dynamically loads the derived Awarelets 101
based on the Awarelet Configuration 113.”. . . “A developer will
design and implement Awarelets at build time, and then deploy
and configure the Awarelets into a runtime instantiation of one
of the prior art awareness engines.”
Ans. 7 (citing Bhaskaran 5:67–6:3, 6:6–8, 3:11–19).
Appellant’s arguments are unpersuasive because Appellant fails to
specifically address all the Examiner’s findings. For example, Appellant
Appeal 2019-002039
Application 15/152,509

9
provides insufficient evidence or persuasive reasoning to show why
Bhaskaran’s disclosure of dynamically loading Awarelets into a runtime
instantiation fails to teach or suggest the limitation at issue.
Applicant further argues “the Application Developer determining the
configuration during build time and instructing the Awarelet Container to
load various Awarelets during runtime” and “the developer designing and
implementing Awarelets at build time and then deploying and configuring
the Awarelets into a runtime instantiation of one of the prior art awareness
engines, as described by Bhaskaran, does not constitute . . . automatically
loading the custom code dynamically in a runtime hosted by the backend-as-
a-service module while the runtime is running,” as in claim 1. Reply Br. 5.
We are unpersuaded of Examiner error, because Appellant’s summary
of Bhaskaran, followed by a conclusion that Bhaskaran “does not constitute”
the recited claim language (in this instance with underlined claim language),
is not a substantive argument that persuasively and specifically addresses
why the Examiner erred. See In re Lovin, 652 F.3d 1349, 1357 (Fed. Cir.
2011) (“[W]e hold that the Board reasonably interpreted Rule 41.37 to
require more substantive arguments in an appeal brief than a mere recitation
of the claim elements and a naked assertion that the corresponding elements
were not found in the prior art.”).
For the reasons discussed, Appellant has not persuaded us of error in
the Examiner’s obviousness rejection of independent claim 1. Accordingly,
we sustain the Examiner’s rejection of that claim, as well as the rejection of
independent claims 9 and 17, and dependent claims 2–8, 10–16, and 18–20,
which Appellant does not argue separately with particularity. Appeal
Br. 18–46.
Appeal 2019-002039
Application 15/152,509

10
CONCLUSION
We affirm the Examiner’s decision to reject claims 1–20 under
35 U.S.C. § 103.

DECISION SUMMARY
In summary:
Claims
Rejected
35 U.S.C. § Reference(s)/Basis Affirmed Reversed
1, 9, 17 103 Harvey, Bhaskaran 1, 9, 17
2, 10, 18 103 Harvey, Bhaskaran,
Igotti
2, 10, 18
3–6, 11,
12, 14, 15,
19, 20
103 Harvey,
Bhaskaran, Yu
3–6, 11, 12,
14, 15, 19,
20

7, 13 103 Harvey, Bhaskaran,
O’Brien
7, 13
8, 16 103 Harvey, Bhaskaran,
Williams, Yu
8, 16
Overall
Outcome
1–20
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