Ex Parte Obstfeld et al

Patent Trial and Appeal Board

May 26, 2017

13533780 (P.T.A.B. May. 26, 2017)

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/533,780 06/26/2012 Joel Obstfeld 1014-569US01/JNP-1666 8073
72689 7590 05/31/2017
SHUMAKER & SIEFFERT, P.A
1625 RADIO DRIVE , SUITE 100
WOODBURY, MN 55125
EXAMINER
PATEL, RONAK
ART UNIT PAPER NUMBER
2458
NOTIFICATION DATE DELIVERY MODE
05/31/2017 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):
pairdocketing @ ssiplaw.com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
BEFORE THE PATENT TRIAL AND APPEAL BOARD
Ex parte JOEL OBSTFELD, DAVID WARD, COLBY BARTH,
and MU LIN
Appeal 2016-002102
Application 13/533,780
Technology Center 2400
Before CAROLYN D. THOMAS, ERIC B. CHEN, and
MICHAEL M. BARRY, Administrative Patent Judges.
THOMAS, Administrative Patent Judge.
DECISION ON APPEAL
Appellants seek our review under 35 U.S.C. § 134(a) of the
Examiner’s Final Rejection of claims 1—18, all the pending claims in the
present application. See Claims Appendix. We have jurisdiction over the
appeal under 35 U.S.C. § 6(b).
We AFFIRM-IN-PART.
The present invention relates generally to distributing network device
tasks across virtual machines executing in a computing cloud. See Abstract.
Appeal 2016-002102
Application 13/533,780
Claims 1 and 2 are illustrative:
Claim 1: A method comprising:
receiving, with a router, a plurality of link-state messages
from a plurality of network devices communicatively coupled to the
router;
sending, with a virtual machine agent executing at the
router and to a virtual machine manager executing at a computing
cloud, a request for available computing resources of the computing
cloud;
receiving, with the router and from the virtual machine
manager, a response that includes a network socket to at least one
virtual machine executing at the computing cloud;
sending, with the virtual machine agent and to the virtual
machine using the network socket, a request to determine shortest
paths between the router and each of the plurality of network devices,
wherein the request includes the plurality of link-state messages;
receiving, with the virtual machine agent and from the
virtual machine, a response message that includes an indication of a
respective shortest path between the router and each of the plurality of
network devices; and
updating, based on the response message, routing
information stored at the router.
Claim 2: A method comprising:
executing, by a router, a version of a network operating
system;
identifying, with a virtual machine agent executing at the
router, a virtual machine executing at a computing cloud
communicatively coupled to the router, wherein the identified virtual
machine executes an instance of the version of the network operating
system;
sending, with the virtual machine agent and to the virtual
machine, a request to perform a task;
receiving, with the virtual machine agent and from the
virtual machine, a task response that includes a result of performing
the task; and
updating, based on the result included in the task
response, the router.
2
Appeal 2016-002102
Application 13/533,780
Appellants appeal the following rejection:
Claims 1—18 are rejected under 35 U.S.C. § 103(a) as being
unpatentable over Kodialam (US 2002/0018264 Al, Feb. 14, 2002), Dunlap
(US 2013/0103827 Al, Apr. 25, 2013), and ChinaV: Building Virtualized
Computing System, Hai Jin et al. (2008) (“BVCS”).
We review the appealed rejections for error based upon the issues
identified by Appellants, and in light of the arguments and evidence
produced thereon. Ex parte Frye, 94 USPQ2d 1072, 1075 (BPAI 2010)
(precedential).
ANALYSIS
Claim 1
Issue 1: Did the Examiner err in finding that the cited art collectively
teaches or suggests a virtual machine agent executing at the router, a request
for available computing resources, and a response that includes a network
socket, as set forth in claim 1?
Appellants contend that “the cited portions of the applied references
are silent as to ‘a virtual machine agent executing at the router’ .... In
Figure 1 of Dunlap ... no virtual machine is shown executing anywhere in
the system, much less within [a] router” (App. Br. 10). Appellants further
contend that “the techniques described by BVCS do not support the Office’s
assertion that. . . ‘VM at the cloud for communicate [sic] the request data
between cloud and router’” (Reply Br. 7). In essence, Appellants are
arguing that neither Dunlap nor BVCS teaches a virtual machine agent
executing at a router.
3
Appeal 2016-002102
Application 13/533,780
the Examiner finds that “BVCS discloses generic cloud computing
technology including sending [a] request to the VMM to [] provision a VM
for a specific task” and a “VM at the cloud for communicat[ing] the request
data between cloud and router” (Ans. 4). For example, the portion of BVCS
cited by the Examiner discloses that “[l]ive virtual machine migration takes
a running VM and moves it from one physical machine to another” (p. 27,
section 4.3) and a “VMM daemon is . . . providing primitive functions
manipulating VMM and virtual machines on local physical machine . . .[,
which] carries out the tasks assigned and returns the results” (p. 30, section
5.2).
In other words, BVCS teaches relocating a running virtual machine
from one physical machine to another without interrupting its services,
whereby the VM continues to carry out the tasks. BVCS further discloses a
“multiple-host virtualization” whereby “many virtual machines [are] running
on connected physical hosts based on the current single-host virtualization
technology . . . [and] a host supports simultaneously multiple running VMs”
(p. 29, section 5)
Although BVCS does not expressly state implementing its method
with a “router,” as argued by Appellants (Reply Br. 6), we find that one of
ordinary skill in the art would recognize that BVCS’s physical machines
could be any network device, including routers and/or computing clouds.
Thus, we find unavailing Appellants’ contention that “BVCS do[es] not
support the Office’s assertion that. . . ‘VM at the cloud for communicate
[sic] the request data between cloud and router’” (Reply Br. 7).
Appellants further contend that “[i]t is unclear to Appellants] how
th[e] portions specifically identified by the Office are relevant to ... a
4
Appeal 2016-002102
Application 13/533,780
request for available computing resources of the computing cloud.
Paragraph [0014] of Dunlap does not describe any such request” (App. Br.
11). In response, the Examiner finds that “[b]ased on [the] combination^]
Kodialam discloses general router functions for routing LSP and link state
message[s] and Dun[lap] discloses the cloud services that can perform
processing for [a] router . . . [T]he router can also send network activity
reports to the cloud . . . and using cloud computing resources available”
(Ans. 5). We agree with the Examiner.
Specifically, Dunlap discloses “[t]he router 110 can also send network
activity reports to the cloud 150 to allow the cloud to perform network
analysis ... In addition ... the router 110 can utilize storage at the cloud
150” (114). In other words, Dunlap’s router sends activity messages to the
cloud triggering the computing resources at the cloud to perform analysis.
Thus, we find that the broadly claimed “request for available computing
resources of the computing cloud” reads on Dunlap’s cloud-related activity
reports sent to the cloud for network analysis. Therefore, we find unavailing
Appellants’ contention that Dunlap does not describe any such request for
available computing resources.
Appellants further contend that “the cited portions of Dunlap cannot
properly be considered to disclose or suggest... a response that includes a
network socket” (App. Br. 13). Here, we find that Appellants are ignoring
the Examiner’s reliance on the combined teachings of Dunlap and BVCS,
and specifically BVCS’s teachings of using a network socket (see Final Act.
5; and Ans. 6). Thus, Appellants’ argument against Dunlap separately from
BVCS does not persuasively rebut the combination made by the Examiner.
One cannot show non-obviousness by attacking references individually,
5
Appeal 2016-002102
Application 13/533,780
where the rejections are based on combinations of references. In re Merck
& Co., Inc., 800 F.2d 1091, 1097 (Fed. Cir. 1986); In re Keller, 642 F.2d
413, 425—26 (CCPA 1981). Therefore, we find unavailing Appellants’
contention that Dunlap does not disclose a network socket.
Appellants further contend that “BVCS is silent as to sending
anything using a network socket” (App. Br. 14). The Examiner finds that
Kodialam teaches shortest paths and “BVCS explains communicating
through network sockets” (Ans. 7; see also Final Act. 4—5). We agree with
the Examiner.
Specifically, Kodialam discloses guaranteed paths for network tunnel
paths, i.e., links between nodes (1 8), and BVCS discloses that a “VMM
daemon is the implementation of single-host service layer . . . [, which]
carries out the tasks assigned and returns the results” (p. 30, section 5.2).
Appellants fail to persuasively rebut why the aforementioned combined
teachings of Kodialam and BVCS, in addition to the teachings in Dunlap
noted supra, shows a network socket, as claimed. Appellants’ argument
against BVCS separately from Dunlap and Kodialam does not persuasively
rebut the combination made by the Examiner. Again, one cannot show non­
obviousness by attacking references individually, where the rejections are
based on combinations of references. Therefore, we find unavailing
Appellants’ contention that BVCS does not disclose a network socket.
Accordingly, we sustain the Examiner’s rejection of claim 1.
6
Appeal 2016-002102
Application 13/533,780
Claims 2, 7—10, and 15—18
Issue 2: Did the Examiner err in finding that the cited art collectively
teaches or suggests the identified virtual machine executes an instance of the
version of the network operating system, as set forth in claim 2?
Appellants contend that “Dunlap does not disclose any virtual
machine at all” (App. Br. 15) and Dunlap does not “suggest ‘identifying,
with a virtual machine agent executing at the router, a virtual machine
executing at a computing cloud . . as recited in claim 2” (App. Br. 16).
For at least the reasons noted supra regarding the claim 1 arguments, we
find Appellants’ similar contentions here relating to Dunlap unavailing given
that the Examiner relies upon BVCS to teach virtual machines in
routers/clouds.
Appellants further contend that “the virtual machine executing at the
computing cloud operates the same version of the network operation system
as is being executed by the router. ... the cited portions of Dunlap and
BVCS teach no such features” (App. Br. 16—17). In response, the Examiner
finds “BVCS describes [a] system administrator who prepares various
operating system version at cloud computing for VM repository” (Ans. 8).
We agree with the Examiner.
For example, BVCS discloses that the Template-based VM repository
(TVR) “contains all versions of various operating systems and software” (p.
33. section 6.3). It appears that the Examiner has concluded that because
BVCS teaches that all versions of the operating systems are available in the
repository, a virtual machine is able to execute the same version as the
router. Appellants fails to rebut this specific finding in the Reply Brief.
Arguments not made are waived. See 37 C.F.R. § 41.37(c)(l)(vii). Cf. In re
7
Appeal 2016-002102
Application 13/533,780
Baxter TravenolLabs., 952 F.2d 388, 391 (Fed. Cir. 1991) (“It is not the
function of this court to examine the claims in greater detail than argued by
an appellant, looking for nonobvious distinctions over the prior art.”)
Accordingly, we sustain the Examiner’s rejection of claim 2, and also
the rejection of claims 7—10 and 15—18, for which Appellants provide no
arguments separate from those for claim 2.
Claims 3, 4, 11, 12
Issue 3: Did the Examiner err in finding that the cited art collectively
teaches or suggests first/second tasks for first/second logical segments of a
network, as set forth in claim 3?
Appellants contend that “BVCS does not disclose or suggest, ‘wherein
the task is a first task for a first logical segment of a network, ’ as recited by
claim 3” (App. Br. 19); “wherein the first virtual machine and the second
virtual machines are different virtual machines” {id.y, and “BVCS is silent as
to at least ‘wherein the second task is for a second logical segment of the
network’” (id. at 20).
In response, the Examiner finds that BVCS discloses that “a host
supports simultaneously multiple running VMs ... by allocating (task[s])”
(Ans. 10). Although we agree that BVCS discloses a multiple-VM
management system that can manage a large number of virtual machines and
specifically notes “that different versions of VMMs may also have a wide
range of distinction^]” (p. 30, section 5.2), we find that the Examiner has
not clearly shown where any of these distinctions in BVCS discloses that the
second task is for a second logical segment of the network, as required by
claim 3. No logical segmentation of the network is shown. At best, BVCS
8
Appeal 2016-002102
Application 13/533,780
broadly discloses carrying out various tasks assigned and returning the
results, without distinguishing whether a task is for a particular logical
segment of the network.
Although claims 3,4, 11, and 12 are argued together, we note that
claims 11 and 12 do not require a second task for a second logical segment
of the network, but instead merely claims a second task (see claim 11).
Thus, the aforementioned argument is not applicable to claims 11 and 12.
Therefore, we are constrained by the record before us to find that the
Examiner erred in rejecting dependent claims 3 and 4. However, we affirm
the rejection of claims 11 and 12.
Claims 5, 6, 13, 14
Issue 4: Did the Examiner err in finding that the cited art collectively
teaches or suggests a request including an indication of the version of the
network operating system and an indication of a task to be perform, as set
forth in claim 5?
Appellants contend that “[t]he cited portion of BVCS is silent as to
‘sending ... a request for computing resources, wherein the request includes
an indication of the version of the network operating system and an
indication of a task to be performed” (App. Br. 21). We agree with
Appellants.
Although the Examiner directs our attention to BVCS for teaching the
aforementioned specifics of claim 5 (see Ans. 11—12), we find that such
cited portions of BVCS fail to describe a request that includes an indication
of the version of the network operating system and an indication of a task to
be performed, as required by claim 5. We also find that Dunlap’s alleged
9
Appeal 2016-002102
Application 13/533,780
request also fails to teach these specifics, i.e., in their activity reports (see
Dunlap (114)).
Therefore, we are constrained by the record before us to find that the
Examiner erred in rejecting dependent claim 5, and dependent claims 6, 13,
and 14 for similar reasons.
DECISION
We reverse the Examiner’s § 103(a) rejection of claims 3—6, 13, and
14.
We affirm the Examiner’s § 103(a) rejection of claims 1, 2, 7—12, and
15-18.
AFFIRMED-IN-PART
10