Ex Parte Even et alDownload PDFPatent Trial and Appeal BoardMay 15, 201411612182 (P.T.A.B. May. 15, 2014) Copy Citation 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 Copy with citationCopy as parenthetical citation