Ex Parte Even et al

Patent Trial and Appeal Board

May 15, 2014

11612182 (P.T.A.B. May. 15, 2014)

UNITED STATES PATENT AND TRADEMARK OFFICE 1
___________ 2
3
BEFORE THE PATENT TRIAL AND APPEAL BOARD 4
___________ 5
6
Ex parte RONI EVEN, 7
SIGMUND GAVISH, 8
and ITAY YAD-SHALOM 9
___________ 10
11
Appeal 2011-009469 12
Application 11/612,182 13
Technology Center 2400 14
___________ 15
16
17
Before MURRIEL E. CRAWFORD, ANTON W. FETTING, and 18
THOMAS F. SMEGAL, Administrative Patent Judges. 19
FETTING, Administrative Patent Judge. 20
DECISION ON APPEAL 21
Appeal 2011-009469
Application 11/612,182

2
STATEMENT OF THE CASE1 1

1 Our decision will make reference to the Appellants’ Appeal Brief (“Br.,”
filed November 11, 2010) and the Examiner’s Answer (“Ans.,” mailed
January 26, 2011).
Roni Even, Sigmund Gavish, and Itay Yad-Shalom (Appellants) seek 2
review under 35 U.S.C. § 134 of a final rejection of claims 1-24, 26 and 27, 3
the only claims pending in the application on appeal. We have jurisdiction 4
over the appeal pursuant to 35 U.S.C. § 6(b). 5
The Appellants invented a way of multimedia communication by 6
controlling multiple multimedia communication systems from a single 7
control point. (Specification para 0002). 8
An understanding of the invention can be derived from a reading of 9
exemplary claim 1, which is reproduced below [bracketed matter and some 10
paragraphing added]. 11
1. A controller 12
for controlling two or more multipoint control units 13
(MCUs), 14
the MCUs operable to provide conferencing for a 15
plurality of terminals, 16
the controller comprising: 17
[1] an interface adapted for allocating resources 18
of the two or more MCUs; 19
and 20
[2] a database for storing 21
conference reservations 22
Appeal 2011-009469
Application 11/612,182

3
and 1
capability factors 2
for the two or more MCUs and the plurality of 3
terminals; 4
[3] wherein each of the terminals can be served by each of the 5
two or more MCUs, 6
[4] wherein the controller can initiate a conference by allocating 7
resources of at least one of the MCUs for handling the 8
conference, 9
and 10
[5] wherein the controller 11
logically combines capability factors of the two or more 12
MCUs 13
and 14
treats the combination of capability factors as a single 15
unit 16
for allocating resources 17
of the at least one of the MCUs 18
for handling the conference. 19
The Examiner relies upon the following prior art: 20
Rottoo US 5,933,417 Aug. 3, 1999
Malik US 5,938,735 Aug. 17, 1999
Claims 1-24, 26, and 27 stand rejected under 35 U.S.C. § 103(a) as 21
unpatentable over Rottoo and Malik. 22
ISSUES 23
The issues of obviousness turn primarily on whether allocating resources 24
required for performance is part of performance initiation, and whether 25
Appeal 2011-009469
Application 11/612,182

4
Rottoo’s device master-slave relationship is within the scope of treating two 1
devices as one device pair. 2
FACTS PERTINENT TO THE ISSUES 3
The following enumerated Findings of Fact (FF) are believed to be 4
supported by a preponderance of the evidence. 5
Facts Related to the Prior Art 6
Rottoo 7
01. Rottoo is directed to multipoint multimedia telecommunications 8
systems, and to reservation systems for the use of multimedia 9
multipoint servers which are used in the establishment and 10
conduct of multipoint multimedia conferences. Most particularly, 11
Rottoo is directed to an acceptance system which manages the 12
allocation of Multipoint Multimedia Server (MMS) resources to 13
specific conferences. Rottoo 1:14-22. 14
02. In multimedia conferencing, the audio and video data is handled 15
such that each party can see and hear one, several, or all of the 16
other parties. In fact, various telecommunications 17
recommendations and standards are presently being adopted by 18
the ITU-T, ISO, and Bellcore which govern the protocols of 19
multimedia conferencing (see, e.g., ITU-T T.120, H.323, H.320, 20
etc.). In the multimedia conferencing systems of the art, the audio, 21
video, and other data streams generated by a user's system are 22
multiplexed together directly in the encoder section of a 23
multimedia encoder/decoder (codec) located at the 24
Appeal 2011-009469
Application 11/612,182

5
source/terminal, and transported together through the transport 1
network (now proposed in ATM format) to a similar "peer" codec 2
at a remote location. The peer codec is either another codec at the 3
remote user site for a point-to-point conference, and/or a 4
codec/switch at a multimedia bridge (also called a Multipoint 5
Multimedia Server or MMS) for a multipoint conference. The 6
MMS 26, which typically includes a codec/switch 24 and a 7
controller 28, provides conference control (e.g., it determines the 8
signal to be sent to each participant), audio mixing (bridging) and 9
multicasting, audio level detection for conference control, video 10
switching (e.g., voice activated video switching), video mixing or 11
mosaic (e.g., a quad split, or "continuous presence device" which 12
combines multiple images for display together) when available 13
and/or desirable, and video multicasting. The audio and video data 14
exiting the MMS is multiplexed, and continues through the 15
transport network 20 to the desired multimedia source terminals 16
12b, 12c.. Rottoo 2:35-47. 17
03. A hypothetical telecommunications system is shown in Fig. 2 18
and includes a plurality of users, a plurality of MMS units, and a 19
plurality of reservation controllers. Each reservation controller is 20
shown coupled to two MMS units, while each MMS is shown 21
servicing three users. It will be appreciated by those skilled in the 22
art that depending upon its configuration and the needs of the 23
users, each MMS can service many more than three users; and 24
depending upon similar parameters, each reservation controller 25
can service more than two MMS units. Rottoo 2:35-47. 26
Appeal 2011-009469
Application 11/612,182

6
04. Where the set of users who will be party to the multimedia 1
conference all are serviceable by a single MMS, then the 2
reservation controller for that single MMS will make a 3
determination as to whether the necessary MMS resources will be 4
available for the requested conference for the time requested. If 5
so, the reservation controller will confirm the reservation with the 6
conference-initiating user via the private channel of the user. 7
Where the set of users who will be party to the multimedia 8
conference are not all serviceable by a single MMS, but a single 9
reservation controller is involved, again, the reservation controller 10
can determine whether resources are available and can confirm the 11
reservation with the conference-initiating user via the private 12
channel of the user. However, where the set of users who will be 13
party to the multimedia conference are serviced by multiple MMS 14
units which are serviced by multiple reservation controllers, then 15
the reservation controller(s) for the MMS units involved will 16
make determinations as to whether the necessary resources of the 17
MMS units under their control will be available for the requested 18
conference for the time requested. Rottoo 3:47 – 4:5. 19
05. Resources are managed and allocated, and reservations are 20
accepted or denied on the basis of a group of requested resources. 21
Rottoo 4:11-14. 22
06. In response to a reservation query involving two MMS units, 23
the acceptance system accesses the database of reserved resources 24
for each MMS and builds a list for each MMS of the resources 25
requested in the query together with the times during which those 26
Appeal 2011-009469
Application 11/612,182

7
resources are already reserved. These two lists are expanded to 1
form two lists of resources where each record in the list includes a 2
resource identification, a time, and an indication of whether the 3
time is the start of a reserved period or the end of a reserved 4
period. These expanded lists are sorted by the time field and are 5
used to create two two-dimensional resource availability matrices, 6
one for each MMS. One of the MMS units is considered to be a 7
master and the other is considered to be a slave. The master and 8
the slave will be coupled to each other by N-number of network 9
ports where the number N is specified in the query. The type of 10
ports used to couple the master and slave will be chosen by the 11
acceptance system and is not specified in the query. Rottoo 5:59 12
– 6:9. 13
07. After the two matrices are generated, the time dimension of 14
each matrix is interleaved with the other so that each matrix now 15
includes time elements which indicate when resource availability 16
changes in the other. In other words the matrix for the master 17
MMS will include extra entries to indicate times where resource 18
availability changes in the slave matrix and vice versa. Rottoo 19
6:10-16. 20
08. 21
Malik 22
09. Malik is directed to communicating information over an 23
Integrated Services Digital Network (ISDN) network. In 24
particular, Malik is directed to establishing over an ISDN D 25
Appeal 2011-009469
Application 11/612,182

8
channel a communication link between a source terminal and a 1
destination terminal via an ISDN switch, where the established 2
communications link has communications attributes that are 3
favorable to both the source terminal and the destination terminal. 4
Malik 1:20-28. 5
10. The system begins operation by the source terminal receiving 6
an indication from a user that the user wishes to optimize 7
communications between the source terminal and destination 8
terminal while establishing a B channel connection to the 9
destination terminal. Optionally, the user will not be asked 10
whether the user would like to optimize the communications to the 11
destination terminal, but rather, the optimization is performed 12
automatically, without further user input. In the present 13
embodiment, however, the user indicates the user wishes to 14
optimize communications by responding to a prompt on display of 15
the source terminal. In response, the processor-base resource 16
coordination mechanism, retrieves from memory the 17
communication attributes associated with the source terminal. The 18
source terminal after forming a setup message that includes the 19
communication attributes, sends the information in a setup 20
message through the terminal adapter. Optionally, the user or the 21
source terminal may provide only a subset of its available 22
communication attributes because the user or the source terminal 23
may have a preferred set of attributes that are desired to be used in 24
the communication with the destination terminal; in this way, the 25
user of the source terminal maintains control of the B channel 26
Appeal 2011-009469
Application 11/612,182

9
resource allocation based on attributes forwarded to the switch, 1
rather than the switch making the decision regarding the B 2
channel resource allocation based on all possible communication 3
attributes supported by the source terminal. Malik 7:11-46. 4
11. In response to receiving the setup message at the switch 5
module, the ISDN switch passes the message to the processor, 6
where the communication attributes included in the setup message 7
are extracted and analyzed by the central resource coordination 8
mechanism. The central resource coordination mechanism then 9
stores the communication attributes in RAM, and initiates an 10
initial communication query to the destination terminal, via the 11
switching module, ISDN line, NT1, and terminal adapter. Once 12
the destination terminal receives the communication query 13
message, the destination terminal retrieves from memory a listing 14
of communication attributes associated with the destination 15
terminal, and includes these attributes in a reply message to the 16
processor. As with the source terminal, the destination terminal 17
may also elect to only provide a subset of its communications 18
attributes offered by the destination terminal. This subset may be 19
performed automatically, or as a result of user-preferred options. 20
Malik 7:47-65. 21
ANALYSIS 22
As to claim 1, we are not persuaded by the Appellants’ argument that 23
Rottoo fails to teach or suggest initiating a conference by allocating 24
resources to one or more MCUs. Br. 7-11. Appellants acknowledge that 25
Appeal 2011-009469
Application 11/612,182

10
Rottoo allocates resources, but contend this is not an initiation. As the 1
Examiner found, claim 1 does not narrow or otherwise specify the manner or 2
nature of its recited “the controller can initiate a conference by allocating 3
resources.” This phrase does not narrow the initiation to being coextensive 4
with the allocating step, but only recites using such allocating as part of the 5
initiation. As allocation of required resources is by definition required, such 6
allocation necessarily forms part of the initiation process. Appellants further 7
contend that Rottoo’s allocation is for reserving resources rather than 8
initiating a conference. This contention is unpersuasive for the same reason, 9
as reserving resources is a predicate to Rottoo’s conference. 10
We are not persuaded by the Appellants’ argument that Malik fails to 11
teach or suggest a system in which each endpoint can be served by each of 12
the MCUs. Br. 11-12. As the Examiner found, the recitation that “wherein 13
each of the terminals can be served by each of the two or more MCUs” is 14
ambiguous, and may simply mean that each terminal can be served by each 15
of corresponding MCU’s, as contrasted with meaning an interchangeability 16
of MCU’s. 17
We are not persuaded by the Appellants’ argument that Rottoo and 18
Malik in combination fail to teach or suggest the use of capability factors. 19
Br. 12-13. 20
Appellants contend that: 21
[t]he "communication attributes" of Malik are solely attributes 22
of the source and destination terminals, and are not used for 23
allocating resources of the ISDN switch, selecting which ISDN 24
switch to use, or selecting which ports of the ISDN switch to 25
use. Instead, the "communication attributes" of Malik are solely 26
used for ensuring that the source terminal and the destination 27
Appeal 2011-009469
Application 11/612,182

11
terminal are capable of communicating with each other and 1
determining the "most efficient communication attributes." [] 2
The ports of an ISDN switch do not have such attributes, but 3
simply switch B and D channels. 4
Id. at 12(internal citation omitted). As the Examiner found, claim 1 does not 5
recite an ISDN switch, and Malik is only relied upon to teach a “capability 6
factor” and storing the capability factor. Appellants’ argument is not 7
commensurate with the scope of the claim and the Appellants respond to the 8
rejection by attacking the references with a theory different from that the 9
Examiner applied. 10
As to claim 6, reciting “combining resources of the plurality of MCUs 11
to provide a combined MCU; and allocating resources of the combined 12
MCU for handling a conference,” and its dependent claims 7 and 10, we are 13
not persuaded by the Appellants’ argument that: 14
Rottoo only reserves resources on an individual MMS basis. 15
There is no way for Rottoo to reserve or allocate a resource on 16
one MMS for a terminal that must use a second MMS. The 17
passage relied upon by the Examiner generates separate 18
matrices for each of the MMS units, each of which includes the 19
resources that are required from that MMS. . . . 20
Br. 13-14. As the Examiner found, claim 6 requires only some combining of 21
MCU resources, as this combination is the totality of what claim 6 recites of 22
the basis for providing a combined MCU. Rottoo combines the MCU’s into 23
a master-slave pair of resource lists. This pairing is within the scope of the 24
recited “combining.” 25
As to claim 18, reciting “selecting comprises maximizing a number of 26
participants assigned to a single selected MCU,” we are not persuaded by the 27
Appellants’ argument that: 28
Appeal 2011-009469
Application 11/612,182

12
[b]ecause "local ports are specifically designated (i.e. directly 1
coupled to local conference sites)" (Rottoo, col. 7, lines 43-45) 2
there is no possibility of "maximizing a number of participants 3
assigned to a single selected MCU"; those participants are 4
always assigned to whichever MMS serves them. Maximizing 5
is only possible when terminals can be served by multiple 6
MCUs, as in Appellants' claimed subject matter, in which case 7
different assignments of terminals to MCUs are possible. The 8
passage relied upon by the Examiner merely states the truism 9
that a reservation is not possible at a time when a port needed 10
by a participant is not available. Unlike the system of 11
Appellants' claimed subject matter, which may use different 12
numbers of MCUs, depending on how terminals are allocated 13
one of to the various MCUs to which the terminals can be 14
served, the system of Rottoo does not have any choice of how 15
many MMS units are to be used, because those MMS units are 16
necessarily required based on the participants, who are only 17
served by one MMS. 18
Br. 16. As the Examiner found, claim 18 requires only maximizing a 19
number of participants assigned to a single selected MCU, without 20
narrowing the manner in which such maximizing occurs. As Rottoo allows 21
plural users me MCU, such maximization is simply a matter of assigning the 22
capacity limit of users. The claim does not recite maximizing the number of 23
terminals, as Appellants suggest. 24
As to claim 24, reciting “a first application program interface (API) for 25
allowing a user to communicate with the apparatus; and a second API for 26
allowing the apparatus to communicate with a plurality of MCUs,” we are 27
persuaded by the Appellants’ argument that: 28
Rottoo . . . nowhere, either in the relied upon passage or 29
elsewhere, recites either of the APIs in Appellants’ claimed 30
subject matter. Indeed, Rottoo nowhere mentions the use of an 31
API for any purpose. The recitation of a codec, as in the relied 32
upon passages, is not a teaching of an API, either “for allowing 33
Appeal 2011-009469
Application 11/612,182

13
a user to communicate with the apparatus” or “for allowing the 1
apparatus to communicate with a plurality of MCUs.” 2
Br. 17. As the Examiner found, claim 24 requires only an application 3
program interface (API). This is simply any interface for use in coding 4
access a program. The codec Examiner points to, however, being a 5
coder/decoder (codec) for compressing and decompressing data, is not a 6
programming interface. 7
As to claim 27, reciting “the capability factors of the ports comprise one 8
or more of types of terminals supported, speed of the port, number of free 9
audio bridges associated with the port, and a number of free video mixers 10
associated with the port.,” we are not persuaded by the Appellants’ argument 11
that Malik only describes capabilities as: 12
a type of communication the source terminal wishes to establish 13
(synchronous versus asynchronous), a protocol type such as 14
modified G3, VT, MIL-STD 161A, B, C, etc., speed of 15
communication . . . . 16
Br. 18. As the Examiner found, claim 27 requires only one such capability. 17
As Malik describes type of communication, which is an indicator of a type 18
of terminal supported, and speed of communication, which is an indicator of 19
speed of port, these are within the scope of claim 27. 20
CONCLUSIONS OF LAW 21
The rejection of claims 1-23, 26, and 27 under 35 U.S.C. § 103(a) as 22
unpatentable over Rottoo and Malik is proper. 23
The rejection of claim 24 under 35 U.S.C. § 103(a) as unpatentable over 24
Rottoo and Malik is improper. 25
Appeal 2011-009469
Application 11/612,182

14
DECISION 1
The rejection of claims 1-23, 26 and 27 is affirmed. 2
The rejection of claim 24 is reversed. 3
No time period for taking any subsequent action in connection with this 4
appeal may be extended under 37 C.F.R. § 1.136(a). See 37 C.F.R. 5
§ 1.136(a)(1)(iv) (2011). 6
AFFIRMED-IN-PART 7
llw 8
9