Ex Parte Essary et al

Patent Trial and Appeal Board

Feb 26, 2018

13716887 (P.T.A.B. Feb. 26, 2018)

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.
13/716,887 12/17/2012 Bill Essary 337394.01 7987
69316 7590 02/28/2018
MICROSOFT CORPORATION
ONE MICROSOFT WAY
REDMOND, WA 98052
EXAMINER
PARSONS, THEODORE C
ART UNIT PAPER NUMBER
2494
NOTIFICATION DATE DELIVERY MODE
02/28/2018 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):
u sdocket @ micro soft .com
chriochs @microsoft.com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
BEFORE THE PATENT TRIAL AND APPEAL BOARD
Ex parte BILL ESSARY and STEPHEN H. TOUB
Appeal 2016-002539
Application 13/716,887
Technology Center 2400
Before JOHN A. JEFFERY, KAMRAN JIVANI, and
SCOTT B. HOWARD, Administrative Patent Judges.
JEFFERY, Administrative Patent Judge.
DECISION ON APPEAL
Appellants1 appeal under 35 U.S.C. § 134(a) from the Examiner’s
decision to reject claims 1-20. We have jurisdiction under 35 U.S.C. § 6(b).
We affirm.
STATEMENT OF THE CASE
Appellants’ invention controls access to source code by enabling
access to encrypted source code according to configured access rights. See
generally Abstract. Claim 1 is illustrative:
1. A method in a server for managing access rights to computer
program source code, comprising:
1 Appellants name Microsoft Corporation as the real party in interest. App.
Br. 1.
Appeal 2016-002539
Application 13/716,887
encrypting the source code;
configuring access rights to the encrypted source code;
hosting the encrypted source code at a network-
accessible location;
receiving an access attempt for the encrypted source code
by a digital rights management (DRM) enabled software
development tool; and
enabling access to the encrypted source code by the
DRM enabled software development tool according to the
configured access rights.
THE REJECTIONS
The Examiner rejected claims 1, 4, 6-8, 11, 12, 14, 15, 18, and 20
under 35 U.S.C. § 102(b)2 as anticipated by Ting (US 2006/0212714 Al;
Sept. 21, 2006). Final Act. 9-12.3
The Examiner rejected claims 2, 9, and 16 under 35 U.S.C. § 103 as
unpatentable over Ting and Seeman (US 2003/0200459 Al; Oct. 23, 2003).
Final Act. 13-16.
2 Although the Examiner omits the particular subsection of pre-AIA § 102
on which the anticipation rejection is based, subsection (b) nonetheless
applies here since the cited Ting reference published more than a year before
Appellants’ filing date. Therefore, we presume that the Examiner intended
to reject the claims on this basis, and treat any error associated with this
omission as harmless.
3 Throughout this opinion, we refer to (1) the Final Rejection mailed
Dec. 31, 2014 (“Final Act.”); (2) the Appeal Brief filed June 11, 2015
(“App. Br.”); (3) the Examiner’s Answer mailed November 17, 2015
(“Ans.”); and (4) the Reply Brief filed December 21, 2015 (“Reply Br.”).
Although the Reply Brief is not paginated (unlike the Appeal Brief), we
nonetheless refer to the Reply Briefs pages in the order that they appear in
the record.
2
Appeal 2016-002539
Application 13/716,887
The Examiner rejected claims 3,10, and 17 under 35 U.S.C. § 103 as
unpatentable over Ting and Nagpal (US 2011/0276805 Al; Nov. 10, 2011).
Final Act. 16-18.
The Examiner rejected claims 5, 13, and 19 under 35 U.S.C. § 103 as
unpatentable over Ting and Thomsen (2008/0270462 Al; Oct. 30, 2008).
Final Act. 18-20.
THE ANTICIPATION REJECTION
The Examiner finds that Ting discloses every recited element of claim
1 including receiving an access attempt for encrypted source code by a
digital rights management (DRM) enabled software development tool,
namely Ting’s application 40 and interceptor 60 collectively. Final Act. 9-
10; Ans. 4-5.
Appellants argue that Ting does not teach a DRM enabled software
development tool as claimed. App. Br. 7-9; Reply Br. 2—4. According to
Appellants, Ting’s applications and tools do not perform security functions,
and Ting’s supervisor and associated interceptor is not a software
development tool. Id. Appellants add that the Examiner’s interpreting
independent claims 8 and 15 under pre-AIA 35 U.S.C. § 112, sixth
paragraph is improper. App. Br. 11-12; Reply Br. 5-6.
ISSUES
Under § 102, has the Examiner erred in rejecting claims 1, 8, and 15
by (1) finding that Ting discloses a DRM enabled software development
tool, and (2) interpreting certain limitations in claims 8 and 15 under § 112,
sixth paragraph?
3
Appeal 2016-002539
Application 13/716,887
ANALYSIS
Claims 1, 4, 6, and 7
We begin by construing the key disputed limitation of claim 1 which
recites, in pertinent part, a DRM enabled software development tool. The
Specification does not define this term, unlike other terms whose concrete
definitions leave no doubt as to their meaning. See, e.g., Spec. ^ 90
(defining, among other terms, “computer program medium” and “modulated
data signal”).
Appellants’ Specification does, however, indicate that DRM is a class
of access control technologies used by hardware manufacturers, publishers,
copyright holders, and individuals to limit the use of digital content and
devices after sale. Spec. ^ 3. Notably, DRM enabled software development
tools can decrypt and interact with source code, as enabled by the particular
access rights assigned to the code. Spec. 5, 26-27.
To this end, the Specification describes an exemplary embodiment in
Figure 1 where computing devices 102a and 102b communicate with server
104 containing encrypted source code 118. See Spec. 28-31. Notably,
both computing devices include respective software development tools 108a
and 108b, that each include respective DRM modules 112a and 112b that
enable the tools to interact with the encrypted source code according to
access rights information. See Spec. 31-32.
Our emphasis underscores that this embodiment is merely exemplary,
for the Specification is replete with exemplary and non-limiting language in
this regard. See, e.g., Spec. 20-22, 28, 34, 39. Nevertheless, this
description informs our understanding of the recited DRM enabled software
development tool, at least with respect to an exemplary implementation.
4
Appeal 2016-002539
Application 13/716,887
Figure 3 of the present application shows a software development
environment 300 including a DRM module 302 and plural software
development tools, including code editor 304, static analysis tool 310,
compiler 306, profiler 312, debugger 308, and deployment tool 314. Spec.
40. Although this embodiment uses a single DRM module to provide
DRM functionality for multiple software development tools, one or more of
these software development tools may include its own DRM module in
another embodiment. Spec. ^ 80.
Therefore, a software development tool can be DRM-enabled not only
by including its own DRM module as in Figure 1 of the present application,
but also via DRM functionality provided by an external module, such as the
DRM module 302 that services multiple software development tools 304-
314 in Figure 3. Accord Ans. 5 (noting this latter alternative).
In light of these alternatives, we see no error in the Examiner’s
reliance on Ting’s application 42 and the supervisor’s interceptor module 60
for teaching the recited DRM enabled software development tool. Ans. 5.
Not only is this software application a development tool as noted in Ting’s
paragraph 26, it is effectively DRM-enabled via the functionality provided
by the supervisor’s interceptor module—functionality that protects source
code by enforcing associated access rights as the Examiner indicates. See
Ans. 4-5; see also Ting ^ 26, 30, 32.
Although Ting’s application 42 itself is not DRM-enabled as
Appellant indicates (App. Br. 7-9; Reply Br. 3 4), it is nevertheless DRM-
enabled via its interaction with the supervisor’s interceptor module as noted
previously. On this record, then, we see no error in the Examiner’s finding
that the application and interceptor together constitute a DRM enabled
5
Appeal 2016-002539
Application 13/716,887
software development tool. Ans. 5. This interpretation reasonably comports
with the embodiment in Figure 3 of the present application that uses an
external DRM module to provide DRM functionality for multiple software
development tools—functionality that effectively renders those tools DRM-
enabled. Appellants’ arguments 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 4, 6, and 7 not argued separately with particularity.
Claims 8, 11, 12, 14, 15, 18, and 20
We also sustain the Examiner’s rejection of independent claims 8 and
15 reciting limitations commensurate with those in independent claim 1.
Final Act. 10-12. As noted previously, we see no error in the Examiner’s
finding that Ting’s application and interceptor together constitute a DRM
enabled software development tool. Ans. 5.
Nor are we persuaded that the Examiner’s interpreting independent
claims 8 and 15 under pre-AIA 35 U.S.C. § 112, sixth paragraph is improper
despite Appellants’ contentions to the contrary. App. Br. 11-12; Reply
Br. 5-6.
First, Appellants’ arguments in the Briefs improperly incorporate
arguments made during prosecution. See Manual of Patent Examining
Procedure (MPEP) § 1205.02 (9th ed. Rev. 08.2017, Jan. 2018) (“It is
essential that the Board be provided with a brief fully stating the position of
the appellant with respect to each ground of rejection presented for review in
the appeal so that no search of the Record is required in order to determine
6
Appeal 2016-002539
Application 13/716,887
that position. Thus, the brief should not incorporate or reference previous
responses.”).
Nevertheless, even if Appellants’ arguments were properly presented
(which they are not), we still find them unpersuasive. Claim 8 recites, in
pertinent part, a source code access manager comprising an encryption
module configured to encrypt the source code. But apart from reciting that
this element is configured to perform this function, the claim recites no
particular structure to achieve that end apart from the access manager’s
implementation in a server.
Although omitting the term “means” in a claim element creates a
rebuttable presumption that § 112, sixth paragraph does not apply, such an
omission does not automatically prevent that element from being construed
as a means-plus-function element. Williamson v. Citrix Online, LLC, 792
F.3d 1339, 1348 (Fed. Cir. 2015) (en banc). In such a case, § 112, sixth
paragraph will apply if the claim term fails to recite sufficiently definite
structure, or else recites function without reciting sufficient structure for
performing that function. Id. at 1349.
That is the case here. First, the term “module” is merely a generic
description for software or hardware that performs the specified functions.
That is, this term is merely a nonce word or “non-structural generic
placeholder” that is tantamount to the term “means” because it fails to
connote sufficiently definite structure and, in the context of claim 8, invokes
§112, sixth paragraph. Cf. id. at 1350 (discussing similar nonce words).
That MPEP § 2181 (I)(A) includes “module for ” as one of several exemplary
non-structural generic placeholders only bolsters this conclusion. Although
the claim 8’s “module” is modified by the word “encryption,” this modifier
7
Appeal 2016-002539
Application 13/716,887
does not add sufficient structure to the recited element to preclude § 112,
sixth paragraph construction, for it merely identifies the element’s recited
function. Cf. Ex parte Lakkala, No. 2011-001526 (PTAB Mar. 13, 2013)
(expanded panel) (informative); Ex parte Erol, No. 2011-001143 (PTAB
Mar. 13, 2013) (expanded panel) (informative); Ex parte Smith, No. 2012-
007631 (PTAB Mar. 14, 2013) (expanded panel) (informative)).4
We reach a similar conclusion regarding the three recited modules in
independent claim 15. Here again, these terms are merely nonce words or
“non-structural generic placeholders” that are tantamount to the term
“means” because they fail to connote sufficiently definite structure. Nor do
their respective modifying terms add sufficient structure to the recited
elements to preclude § 112, sixth paragraph construction, for they merely
identify the elements’ recited functions.
Therefore, we are not persuaded that the Examiner erred in rejecting
independent claims 8 and 15 and claims 11, 12, 14, 18, and 20 not argued
separately with particularity.
THE OBVIOUSNESS REJECTIONS
We also sustain the Examiner’s obviousness rejections of claims 2, 3,
5, 9, 10, 13, 16, 17, and 19. Final Act. 13-20. Despite nominally arguing
these claims separately, Appellants reiterate similar arguments made in
connection with claims 1, 8, and 15, and allege that the additional cited
4 These three informative Opinions are available from the Board’s web page
entitled “Key Decisions Involving Functional Claiming” at
http://www.uspto.gov/patents-application-process/appealing-patent-
decisions/decisions-and-opinions/key-decisions
8
Appeal 2016-002539
Application 13/716,887
references fail to cure those purported deficiencies. See App. Br. 10-11;
Reply Br. 4-5. We are not persuaded by these arguments for the reasons
previously discussed.
CONCLUSION
The Examiner did not err in rejecting (1) claims 1, 4, 6-8, 11, 12, 14,
15, 18, and 20 under § 102, and (2) claims 2, 3, 5, 9, 10, 13, 16, 17, and 19
under § 103.
DECISION
We affirm the Examiner’s decision to reject claims 1-20.
No time period for taking any subsequent action in connection with
this appeal may be extended under 37 C.F.R. § 1.136(a)(l)(iv).
AFFIRMED
9