Ex Parte Narayana Iyer et al

Patent Trial and Appeal Board

Sep 12, 2018

12474617 (P.T.A.B. Sep. 12, 2018)

UNITED STA TES p A TENT AND TRADEMARK OFFICE
APPLICATION NO. FILING DATE
12/474,617 05/29/2009
108982 7590 09/14/2018
Wolfe-SBMC
116 W. Pacific A venue
Suite 200
Spokane, WA 99201
FIRST NAMED INVENTOR
Anantharaman P. Narayana Iyer
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.
P922 1910
EXAMINER
BOURZIK, BRAHIM
ART UNIT PAPER NUMBER
2191
NOTIFICATION DATE DELIVERY MODE
09/14/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):
docket@sbmc-law.com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
BEFORE THE PATENT TRIAL AND APPEAL BOARD
Ex parte ANATHARAMAN P. NARA YANA IYER,
DANIEL DURA, and CHRISTIAN CANTRELL
Appeal2016-006387 1
Application 12/474,617
Technology Center 2100
Before JEREMY J. CURCURI, DANIEL N. FISHMAN, and
PHILLIP A. BENNETT, Administrative Patent Judges.
FISHMAN, Administrative Patent Judge.
DECISION ON APPEAL
This is an appeal under 35 U.S.C. § 134(a) of the final rejection of
claims 1-33, which constitute all the claims pending in this application. 2
We have jurisdiction under 35 U.S.C. § 6(b ).
We reverse.
1 Appellants asserts the real party in interest is Adobe Systems Incorporated.
Appeal Brief 3.
2 In this Opinion, we refer to the Appeal Brief ("App. Br.," filed July 15,
2015 (as supplemented by Appellants' Response to Notification ofNon-
Compliant Appeal Brief, October 9, 2015)), the Examiner's Answer ("Ans.,"
mailed April 7, 2016), the Final Office Action ("Final Act.," mailed January
29, 2015), and the original Specification ("Spec.," filed May 29, 2009).
Appeal 2016-006387
Application 12/474,617
STATEMENT OF THE CASE
THE INVENTION
Appellants' invention relates "compiling an input into a distributed
software application." Spec., 1 :3--4. Appellants' patent discloses that
currently known integrated development environments ("IDE") comprise a
number of tools for the software developer. Id. at 1 :4--12. Some software
applications, such as rich internet applications ("RIA") may include client
and server portions to be executed on respective computing devices. Id. at
1: 13-16. Software developers may use an IDE to develop an RIA and
manage the client and server portions thereof. Id. at 1:21-23.
The invention generally accepts a program as input, identifies a client
portion and a server portion therein including client symbols used in the
server portion and server symbols used in the client, and generates an
executable client application and an executable server application. Id. at
1 :25-2:7. Figure 3 is reproduced below.
2
Appeal 2016-006387
Application 12/474,617
Cornpiler
322 324
CJient Applicftt:on Comp,tier Serve,; Apptlca~fon Compiler
E.<.ec.1:..1t.::ible .App!~cution
3J2
·~~
Ext.:l•::uta:blc~ c11,mt
App!:cauan Portiori
FIG. 3
I
336
Ex~Gut~~li!e -S{jfV(::f
Apµli..:auon Pcrrion
330
Figure 3 is a schematic depiction of an exemplary embodiment of the
purported invention.
Referring to FIG. 3, a unified programming model 300 for
could computing allows a user to write and maintain an
application 310 in a single language ( although multiple
languages may be used in some implementations) that has both
client and server portions 312, 314. The application 310 can be
written in a single context ( e.g., shared symbol namespace ),
where client symbols such as variables, objects, methods,
functions of the client application portion 312 are available to the
server application portion 314 and vice versa. While writing the
application 310, the application developer may use server
symbols in the client application portion 312 and client symbols
in the server application portion and the compiler 320, upon
processing the application 310, provides the communication
between the two application portions 312, 314 and separates
them into respective client and server executable applications
332,334.
Spec., 9:15-25.
3
Appeal 2016-006387
Application 12/474,617
Independent method claim 1, reproduced below, is illustrative:
1. A computer implemented method comprising:
receiving a programming language input, having a client
input portion and a server input portion, written in a single
programming language that enables use of client symbols of the
client input portion in the server input portion and use of server
symbols of the server input portion in the client input portion;
parsing the programming language input to separate the
client input portion from the server input portion;
identifying usage of one or more client symbols in the
server input portion and usage of one or more server symbols in
the client input portion;
translating the client input portion into an executable client
application, and translating the server input portion into an
executable server application; and
producing a communication module to enable
communication of one or more client symbols and one or more
server symbols between the executable client application and the
executable server application, the communication module
providing for synchronous or asynchronous communication
based on metadata included in the programming language input.
Independent claim 12 recites a storage medium storing software
programmed to perform essentially the steps of method claim 1.
Independent claim 23 recites a system having a processor and a memory that
executes a program to perform essentially the steps of method claim 1.
THE REJECTION
Claims 1-3, 5, 10-14, 16, 21-25, 27, 32, and 33 are rejected under
35 U.S.C. § I03(a) as obvious over the combined teachings of Nagata et al.
(U.S. Patent Publication No. 2004/0181783 Al; Sept. 16, 2004) ("Nagata")
4
Appeal 2016-006387
Application 12/474,617
and Inohara et al. (U.S. Patent Publication No. 2005/0273792 Al; Dec. 8,
2005) ("Inohara"). Final Act. 6-11.
Claims 4, 15, and 26 are rejected under 35 U.S.C. § I03(a) as obvious
over Nagata, Inohara, and Ramani et al. (U.S. Patent No. 7,725,884 B2; May
25, 2010) ("Ramani"). Final Act. 11-12.
Claims 6, 7, 17, 18, 28, and 29 are rejected under 35 U.S.C. § I03(a)
as obvious over Nagata, Inohara, and Wei (U.S. Patent Publication No.
2004/0143823 Al; July 22, 2004). Final Act. 12-14.
Claims 8, 9, 19, 20, 30, and 31 are rejected under 35 U.S.C. § 103(a)
as obvious over Nagata, Inohara, and McCullough (U.S. Patent No.
7,272,786 Bl; Sept. 18, 2007). Final Act. 14--16.
ANALYSIS
"Identifying" Step
In rejecting independent claims 1, 12, and 23, the Examiner relies on
Inohara for disclosing "identifying usage of one or more client symbols in
the server input portion and any usage of one or more server symbols in the
client input portion." Final Act. 8 (bold emphasis omitted). Specifically,
after quoting the claimed step of identifying, the Examiner merely states,
"Inohara Fig. 8, 9 and 10. For example intf.h, funcl, funct2 [sic], funct3
[sic]." Id.
Appellants argue Figures 8-10 of Inohara are "examples of files
output by Inohara's compiler" and they are "tailored to include definitions
of procedure calls for either client or server side functionality." App.
Br. 17. Appellants further argue the functions (funcl, func2, func3) in
Inohara's Figure 8-10 are merely remote procedure calls defined in the input
5
Appeal 2016-006387
Application 12/474,617
file ("intf.idl" of Figure 7) for Inohara's compiler to generate corresponding
program code. Id. Appellants contend this generation process based on
"intf.idl" as input is not the same as the recited step of identifying server
symbols used in the client portion and client symbols used in the server
portion. Id. at 17-18.
Initially, the Examiner finds Appellants' Specification defines the
claimed usage of clients symbols in the server portion and server symbols in
the client portion in its disclosure that "[ t ]he application 310 can be written
in a single context (e.g., shared symbol namespace), where client symbols
such as variables, objects, methods, functions of the client application
portion 312 are available to the server application portion 314 and vice
versa." Ans. 19. 3 Thus, the Examiner seems to emphasize that a "shared
symbol namespace" defines in some manner what it means for the client
portion to use server symbols and the server portion to use client symbols. It
is unclear to the Board how the quoted paragraph, referring to a "shared
symbol namespace" defines this feature of the claims that requires
identifying the various shared symbols. Regardless, we find the claim
recitation "identifying usage of one or more client symbols in the server
input portion and usage of one or more server symbols in the client input
portion" is sufficiently clear.
The Examiner further finds "an IDL file [(e.g., intf.idl)] is a file that
includes object[ s] included in the server and client in order to communicate
3 The Examiner purports to quote this from paragraph 31 of Appellants'
Specification. The Specification as filed does not use paragraph numbering.
However, the quoted passage is found in the paragraph on page 9, lines 15-
25 of Appellants' Specification as filed.
6
Appeal 2016-006387
Application 12/474,617
and exchange data between those object[ s] through an object request
broker." Ans. 18. The Examiner further finds,
An IDL representation of the server interface include
object that is used in the server.
Referring to fig. 7, func 1 and func2 are object[ s] of the
server called from the client and the same namespace is used.
What func 1 and funt2 does with the argument passed to it is
defined in the server not the client. What is exposed to the client
is only the interface in the IDL.
So in Inohara, before compilation time the input to the
compiler are clientl.c and serverl.c, and in order to expose the
interface between client and server, IDL( an IDL source code 103
that describes in IDL an interface of a group of remote
procedures provided by the server.) is inputted also. And in
client side func 1 and func2 are not defined, but defined and
provided by the server and called by the client. During
compilation, compiler can add, delete and/ or optimize in order to
output an executable file, and RPC optimizer, compiler and
linker are included in the compilation time.
Ans. 19--20.
We agree with the Examiner that the "intf.idl" filing input to Inohara's
invention describes "an interface of a group of remote procedures provided
by the server." Such remote procedures would be "server symbols" used by
the client portion as claimed. Figure 7 of Inohara is reproduced below.
7
Appeal 2016-006387
Application 12/474,617
FIG. 7
intf.idl
701 interface MyServer {
702 int func1 (in int i);
703 void func2(inout long key, in String value);
704 };
client1 .c
751 #include "intLh"
752 main()
753 {
754
755
756
757
758
759
760
761
762 }
MyServer server "' lookupDirectory("MyServer•);
int count = O;
for (int i = O; i < 100; i++)
count += server.func1 (i);
}
printf("count=%d¥n". count);
server.func2(100, "hello world"};
serverJunc1 O);
u-- 700
)750
Figure 7 shows two exemplary input files provided to Inohara's
system-"intf.idl" 700 and "clientl.c" 750. In these exemplary input files,
"intf.idl" 700 indeed defines server symbols, namely procedures "func 1" and
"func2" in a server interface type called "MyServer." See Inohara ,r 117.
The "clientl.c" 750 file shows that a client portion of the input uses server
symbols "funcl" and "func2" (by invoking procedures "server.funcl" and
"server.func2"). See Inohara ,r 118. The fact that "funcl" and "func2"
appear in "intf.idl" teaches or at least suggests that Inohara has identified
these server symbols as used in the client portion (i.e., "client I .c").
However, the Examiner does not sufficiently explain where Inohara
teaches or suggests that it also identifies client symbols that are used in the
server portion. Claim 1 requires identifying "one or more" server symbols
used in the client portion and "one or more" client symbols used in the
server portion. The Examiner has not sufficiently shown that Inohara
8
Appeal 2016-006387
Application 12/474,617
teaches or suggests identifying one or more client symbols used in the server
portion.
We are persuaded the Examiner erred by failing to sufficiently
identify where Inohara teaches or suggests that it identifies client symbols
used in the server portion. Accordingly, we do not sustain the Examiner's
rejection of independent claim 1 and, for essentially the same reasons, we do
not sustain the Examiner's rejection of independent claims 12 and 23.
Because all dependent claims (2-11, 13-22, and 24--33) all depend, directly
or indirectly from one of claims 1, 12, and 23, we also do not sustain the
Examiner's rejections of dependent claims 2-11, 13-22, and 24--33.
DECISION
For the above reasons, the Examiner's decision rejecting claims 1-33
is reversed.
REVERSED
9