Ex Parte Kishan et al

Patent Trial and Appeal Board

May 17, 2018

12716381 (P.T.A.B. May. 17, 2018)

UNITED STA TES p A TENT AND TRADEMARK OFFICE
APPLICATION NO. FILING DATE
121716,381 03/03/2010
69316 7590 05/21/2018
MICROSOFT CORPORATION
ONE MICROSOFT WAY
REDMOND, WA 98052
FIRST NAMED INVENTOR
Arun Kishan
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
ATTORNEY DOCKET NO. CONFIRMATION NO.
328568.02 1640
EXAMINER
YUN, CARINA
ART UNIT PAPER NUMBER
2194
NOTIFICATION DATE DELIVERY MODE
05/21/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):
usdocket@microsoft.com
chriochs@microsoft.com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
BEFORE THE PATENT TRIAL AND APPEAL BOARD
Ex parte ARUN KISHAN, KARTHIK THIRUMALAI,
RICHARD A. PLETCHER, and BRYAN W. FAGAN
Appeal2017-009693
Application 12/716,3 81
Technology Center 2100
Before JOHN A. JEFFERY, LARRY J. HUME, and
NORMAN H. BEAMER, Administrative Patent Judges.
JEFFERY, Administrative Patent Judge.
DECISION ON APPEAL
Appellants 1 appeal under 35 U.S.C. § 134(a) from the Examiner's
decision to reject claims 1-3, 5-11, and 13-20. We have jurisdiction under
35 U.S.C. § 6(b). We reverse.
STATEMENT OF THE CASE
Appellants' invention uses a loader that can identify executable
components that collectively implement an application programming
interface (API) namespace representing a predefined collection of functions.
The API namespace may have an interface contract similar to an interface
1 Appellants identify the real party in interest as Microsoft Technology
Licensing, LLC. App. Br. 2.
Appeal2017-009693
Application 12/716,381
contract for a dynamically linked library. Therefore, applications and other
components can reference the API namespace in the same way that a
dynamically linked library is referenced. See generally Abstract; Spec. i-f 8.
Claim 1 is illustrative:
1. A method performed on a computing device that includes at
least one processor and memory, the method comprising:
receiving, by the computing device from a component that was coded
against an interface contract that corresponds to an application programming
interface ("API") namespace, a request to load the API namespace that
represents a predefined collection of functions that fulfill the interface
contract, where the received request includes parameters that identify: the
API namespace, a particular version of the API names pace required by the
component, and the component;
identifying, by the computing device based on the parameters and a
map, a set of components that implement the predefined collection of
functions represented by the particular version of the API namespace, where
the interface contract is decoupled from the set of components, where the
interface contract defines APis of the predefined collection of functions, and
where the map links the particular version of the API namespace to the set of
components that implements the predefined collection of functions that
fulfill the interface contract; and
loading the identified set of components.
THE REJECTIONS
The Examiner rejected claims 1, 5, 7, 9, 16, and 17 under 35 U.S.C.
§ 103 as unpatentable over Pasha (US 2007/0143501 Al; June 21, 2007) and
Gunduc (US 2003/0110312 Al; June 12, 2003). Ans. 3-7.2
2 Throughout this opinion, we refer to (1) the Appeal Brief filed February
23, 2017 ("App. Br."); (2) the Examiner's Answer mailed May 10, 2017
("Ans."); and (3) the Reply Brief filed July 6, 2017 ("Reply Br.").
2
Appeal2017-009693
Application 12/716,381
The Examiner rejected claims 2, 6, 8, 10, 18, and 19 under 35 U.S.C.
§ 103 as unpatentable over Pasha, Gunduc, and Marucheck (US
2006/0179146 Al; Aug. 10, 2006). Ans. 7-9.
The Examiner rejected claim 3 under 35 U.S.C. § 103 as unpatentable
over Pasha, Gunduc, Marucheck, and Gilboa (US 2004/0148586 Al; July 29,
2004). Ans. 9-10.
The Examiner rejected claims 13, 15, and 20 under 35 U.S.C. § 103 as
unpatentable over Pasha, Gunduc, and Gilboa. Ans. 10-11.
The Examiner rejected claims 11 and 14 under 35 U.S.C. § 103 as
unpatentable over Pasha, 3 Gunduc, and Banks (US 2005/0144591 Al; June
30, 2005). Ans. 11-13.
THE OBVIOUSNESS REJECTION OVER PASHA AND GUNDUC
Regarding independent claim 1, the Examiner finds that Pasha
discloses, among other things, a computing device that receives a request to
load an API namespace from a component that was coded against an
interface contract that corresponds to the API namespace that represents a
predefined collection of functions that fulfill the interface contract. Ans.
3--4. According to the Examiner, Pasha's conform module functionality that
receives a web service implementation is also said to receive an API
3 Although the Examiner's statement of the rejection cites Marucheck,
Gunduc, and Banks, the Examiner nonetheless refers to Pasha, Gunduc, and
Banks in the corresponding discussion-the latter combination consistent
with the rejection of claim 9 from which claims 11 and 14 depend. See Ans.
11-13. Accordingly, we presume that the Examiner intended to cite Pasha
instead of Marucheck in this rejection, and we treat the Examiner's error in
this regard as harmless.
3
Appeal2017-009693
Application 12/716,381
namespace loading request as claimed in view of user input that requests to
bind the namespace to the web service implementation during execution.
Ans. 13-20. Although the Examiner acknowledges that Pasha does not
decouple the interface contract from a component set, the Examiner cites
Gunduc for teaching this feature in concluding that the claim would have
been obvious. Ans. 5.
Appellants argue that the cited prior art does not teach or suggest a
device receiving a request to load an API namespace from a component
coded against an interface contract that corresponds to the API namespace as
claimed. App. Br. 6-13; Reply Br. 3---6. According to Appellants, Pasha
modifies a service implementation according to contract changes, but does
not receive a request to load an API namespace, let alone from a component
that was coded against an interface contract corresponding to that
namespace. App. Br. 6-9. Appellants add that Pasha's conform module
performs a function opposite to that of the recited component, namely by
receiving a contract and, therefore, Pasha does not teach or suggest a device
receiving a request from that component. App. Br. 12; Reply Br. 10-11.
ISSUE
Under§ 103, has the Examiner erred by finding that Pasha and
Gunduc collectively would have taught or suggested a computing device that
receives a request to load an API namespace from a component that was
coded against an interface contract that corresponds to the API namespace
that represents a predefined collection of functions that fulfill the interface
contract?
4
Appeal2017-009693
Application 12/716,381
ANALYSIS
As noted above, Appellants' claimed invention loads an identified set
of components on a computing device that implement predefined functions.
According to the Background section of Appellants' Specification, software
components are loaded dynamically by an operating system component, or
"loader," that performs operations needed to make a binary or executable
file ready for execution. Spec. i-fi-1 4--5. A binary may implement a library of
functions defined in an "interface contract" that defines APis that are used to
access those functions. Id. i16.
Appellants' invention improves computer operation with a loader that
can identify executable components that collectively implement an API
namespace representing a predefined collection of functions. Id. i1 8. The
API namespace may have an interface contract similar to an interface
contract for a dynamically linked library. Id. Therefore, applications and
other components can reference the API namespace in the same way that a
dynamically linked library is referenced. Id. Notably, this API namespace
implementation is not tied to a particular dynamically linked library, thus
allowing flexibility in implementing functions and maintaining these
libraries. Id.
As shown in Appellants' Figure 4 reproduced below, loader 410
receives, among other things, input parameters 412 indicating that an API
namespace is to be loaded. Spec. i150.
5
Appeal2017-009693
Application 12/716,381
., ...... ---·---·-r··~~~~~~-,-
,, ,/ 45y'
4:.1;2,
I
\_r-----.
FIG.4
Appellants' Figure 4 showing loader receiving input parameters
As the Specification explains, this API namespace loading indication
may be generated in any suitable way, such as (1) during computer system
initialization, (2) responsive to an indication that an application should be
launched, or (3) responsive to operations performed within a component that
is already loaded and executing. Spec. ii 50. The loader uses these received
parameters to access a map 450 to identify a set of components that
collectively implement the set of functions in the API namespace identified
by the parameters. Id. ii 55. As shown in Figure 4, each namespace in a
given row of map 450 is mapped to a set of components in that row (e.g.,
NAMESP ACE 1 is mapped to DLL A and DLL B, etc.).
6
Appeal2017-009693
Application 12/716,381
Turning to claim 1, the claim recites, in pertinent part, receiving, by
the computing device from a component that was coded against an interface
contract that corresponds to an API namespace, a request to load the
namespace (the "receiving limitation"). Our emphasis underscores that the
recited request is received from a component-a particular alternative that is
most consistent with the third disclosed alternative noted previously that
generates API namespace loading indications via these requests, namely
responsive to operations performed within a component that is already
loaded and executing. See Spec. i-f 50; see also id. i-f 86 (noting that a
component can indicate to the loader that a namespace is to be resolved by
collecting runtime parameters and passing them to the loader).
The Examiner, however, apparently construes the component in
claim 1 's receiving limitation as having been received by the computing
device. See Ans. 13, 20 ("The claims disclose receiving a component that
was coded against an interface contract.") (emphasis added). But as
Appellants indicate (Reply Br. 10), a component is not received in claim 1,
but rather a request from a component. Although the component is
identified in the parameters included in this received request under the terms
of claim 1, the component itself is not received.
The Examiner's mapping the recited elements to corresponding
elements in Pasha is not a model of clarity. In the rejection, the Examiner
does not clearly identify a "component" from which a computing device
receives a request, but rather cites Pasha's paragraphs 10, 28, 44, and 48 in
connection with the receiving limitation. See Ans. 3. The Examiner also
refers to Pasha's conform module 150 in connection with the recited
component. See Ans. 4.
7
Appeal2017-009693
Application 12/716,381
In the Answer's Response to Arguments section, however, the
Examiner finds that Pasha's conform module receives a web service
implementation that (1) acts as the component coded against an interface
contract, and (2) is received by the computer system (conform module).
Ans. 13-14, 16. Although this articulation is somewhat ambiguous, the
Examiner may intend to map the recited component to Pasha's web service
implementation rather than the conform module, despite Appellants'
contention to the contrary. See App. Br. 12.
Nevertheless, regardless of whether the Examiner intends to map the
recited component to Pasha's conform module under Appellants' theory (see
id.), web service implementation, or some other element in Pasha, we agree
with Appellants that Pasha falls well short of teaching or suggesting a device
receiving a request to load an API namespace from a component that was
coded against an interface contract that corresponds to the API namespace as
claimed.
Pasha's system automatically modifies a web service implementation
to conform to an updated web service contract. Pasha i-f 24. As shown in
Pasha's Figure IA, a first service contract 110---a document that describes
service behavior and that may be agreed upon and generated by a
developer-is used to generate a web service implementation 130. Pasha
i-fi-124--28. As shown in Pasha's Figure IB, web service implementation 130
includes, among other things, various web service class types and associated
attributes and methods. Pasha i-fi-128-32.
A developer may also produce a second service contract 140,
however, that updates, modifies, or replaces the first service contract. Pasha
i-f 33. In this situation, Pasha's conform module (1) receives the second
8
Appeal2017-009693
Application 12/716,381
contract document defining changes to the first contract document, and (2)
automatically modifies a portion of web service implementation 130 by,
among other things, updating the web service implementation binding name
or namespace detailed in steps 302 and 304 of Figure 3. Pasha i-fi-144--48,
72-74; Figs. lA-3. As part of this update, the system may accept additional
user input while the implementation is modified. Pasha i-fi-1 67---68.
According to the Examiner, this manual update during modification
teaches receiving a request to load an API namespace because the user input
requests to bind the namespace to the web service implementation that is4
coded against the contract during execution. Ans. 14--15, 17. But even
assuming, without deciding, that this manual update involves receiving a
request to load a namespace as the Examiner finds, we fail to see-nor has
the Examiner shown-that this received request involves loading an AP I
namespace as claimed. Not only is Pasha's binding name and namespace
inconsistent with the API namespace described in the Specification as
Appellants indicate (Reply Br. 4), it is also inconsistent with the ordinary
and customary meaning of "API" as the term is understood in the art.
One computing dictionary defines the term "application programming
interface" as "[a] set of routines used by an application program to direct the
performance of procedures by the computer's operating system."
MICROSOFT COMPUTER DICTIONARY 33 (5th ed. 2002). Another computing
dictionary defines API as "[a] standardized interface via which an
4 The Examiner finds that Pasha's web service implementation is coded
against a contract despite the claim's reciting this coding in the past tense,
namely that the component was coded against an interface contract.
Nevertheless, we are persuaded of error in the Examiner's rejection for other
reasons indicated in the opinion.
9
Appeal2017-009693
Application 12/716,381
application program can access services provided by the operating system or
other subsystems." Dick Pountain, THE PENGUIN CONCISE DICTIONARY OF
COMPUTING 15 (2003). According to that dictionary, "[a]n API is usually
defined by source code in a high-level programming language such as C or
C++, and consists of a set of functions each of which invokes a particular
service; programmers then call these functions from their own programs."
Id. Another dictionary defines API, in pertinent part, as "[a] set of
instructions that determine how a computer application interacts with the
operating system." Steven M. Kaplan, WILEY ELECTRICAL & ELECTRONICS
ENGINEERING DICTIONARY 34 (2004).
The clear import of these definitions is that an API involves the
interaction of an application with a computer's operating system. To the
extent that the Examiner finds that Pasha's binding name or namespace is
somehow equivalent to an API namespace (see Ans. 14--15, 19), there is no
evidence on this record to substantiate such a finding. Consequently, the
Examiner fails to show that Pasha's computing device receives a request to
load an API namespace, let alone that this request is received from a
component that was coded against an interface contract as claimed. Nor has
the Examiner shown that Gunduc cures those deficiencies. That Pasha's
service contract documents are entirely different from the recited interface
contract that defines APis that are used to access those functions as
described in paragraph 6 of the Specification only further undermines the
factual basis for the Examiner's rejection.
Therefore, we are persuaded that the Examiner erred in rejecting
(1) independent claim 1; (2) independent claims 9 and 16 that recite
commensurate limitations; and (3) the dependent claims for similar reasons.
10
Appeal2017-009693
Application 12/716,381
Because this issue is dispositive regarding our reversing the Examiner's
rejection of these claims, we need not address Appellants' other associated
arguments.
THE OTHER OBVIOUSNESS REJECTIONS
Because the Examiner has not shown that the cited prior art cures the
foregoing deficiencies regarding the rejection of the independent claims, we
will not sustain the obviousness rejections of dependent claims 2, 3, 6, 8, 10,
11, 13-15, and 18-20 (Ans. 7-13) for similar reasons.
CONCLUSION
The Examiner erred in rejecting claims 1-3, 5-11, and 13-20 under
§ 103.
DECISION
We reverse the Examiner's decision to reject claims 1-3, 5-11,
and 13-20.
REVERSED
11