DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 103
2. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1 - 19, are rejected under 35 U.S.C. 103 as being unpatentable over Grevers, Jr. (Pub. No.: US 2015/0139043 A1; hereinafter Grevers) in view of Mazzarella et al (Pub. No.: US 2019/0281096 A1; hereinafter Mazzarella)
Consider claims 1, 11, and 12, Grevers clearly shows and discloses a non-transitory computer-readable storage medium, a device for lifting a speaking ban at a video conference, and a method for lifting a speaking ban at a video conference, applied to a multi-point control end, the multi-point control end being in communication with a chairman end and a plurality of clients (users may participate in a meeting session that utilizes both a web browser session and a telephone session, via multiple types of IP (Internet Protocol) connected endpoint devices, he devices in the network may be call managers, communications managers, service points, endpoints, media sources, media receivers, media processing units, media experience engines, multimedia transformation units, multipoint conferencing units) (paragraphs: 0011, 0014-0015 and fig. 1), the method comprising: receiving a speaking ban request from the chairman end, wherein the speaking ban request carries permission information which allows the clients to lift a speaking ban (a user, host, or moderator of the session may have the ability to mute a participant or all non-speaking participants) (paragraphs: 0011 ); sending, according to the speaking ban request, a speaking ban notification to the clients, so as to impose a speaking ban on the clients (provide notification between dissimilar endpoint devices (platforms) to bring awareness to a user of the mute state of an audio connection; input received at the meeting server via a web browser at user device 14 (e.g., computer used for web session) or input received via user device 15 (e.g., phone used for audio session). The meeting server 16 generates an indication of the mute state change (e.g., `mute off` changed to `mute on` or `mute on` changed to `mute off`) (step 32) and transmits the mute state change for display at a second user device (step 34)) (paragraphs: 0013, 0019, 0020, 0029); and sending, in response to receiving a speaking ban lifting request from a target client, a speaking notification to the target client according to the speaking ban lifting request and the permission information, wherein the target client is one or more of the clients (the user's line remains muted until the user deselects the mute icon adjacent to the their user ID in the meeting application at their computer 46 or turns off the mute (e.g., presses mute button) on their IP phone 50, which initiates a signal back to the communications manager 52, which then communicates the mute state change to the meeting server 16 that the user wants to unmute their audio connection) (paragraphs: 0035 and fig. 2, labels: 20 and 18); however, Grevers does not teach wherein the speaking ban request carries permission information which allows the clients to lift a speaking ban.
In the same field of endeavor, Mazzarella clearly teaches wherein the speaking ban request carries permission information which allows the clients to lift a speaking ban (floor control parameters/ permission information can provide a framework for determining whether to grant transmission capabilities to a requesting endpoint. The floor control parameters can include rules or specifications for determining priorities between two or more endpoints in the conferencing session. More particularly, the floor control parameters can resolve the priorities based at least in part on floor control parameter data, such as the current floor allocation (e.g. whether an endpoint currently has transmission capabilities), the order and/or timing of requests, and/or other suitable floor control parameters. The floor control parameter data can further include contextual floor control parameter data, such as the identities the endpoints (or endpoint users) in the conferencing session, attributes or characteristics associated with the endpoints (or endpoint users) in the conferencing session, the relative ranks associated with the endpoints (or endpoint users) in the conferencing session, contextual information asserted by the endpoints (or endpoint users) in the conferencing session, relative importance of the endpoints (or endpoint users) in the conferencing session, the endpoint types of the endpoints; the floor control parameters can be set by a user to reflect the particular circumstances or contexts surrounding the conferencing session. ) (paragraphs: 0021-0025, 0035, 0038 and fig. 3).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to incorporate the teaching of Mazzarella into teaching of Grevers for the purpose of using permission information/ floor control parameters which allows the users to speak or unmute themselves.
Consider claims 8, 13, and 15, Grevers clearly shows and discloses a non-transitory computer-readable storage medium, a device for lifting a speaking ban at a video conference, and a method for lifting a speaking ban at a video conference, applied to clients, the clients being in communication with a chairman end by a multi- point control end, the method comprising: receiving a speaking ban notification sent by the multi-point control end, and imposing a speaking ban according to the speaking ban notification, wherein the speaking ban notification is generated by the multi-point control end according to a speaking ban request (a user, host, or moderator of the session may have the ability to mute a participant or all non-speaking participants; provide notification between dissimilar endpoint devices (platforms) to bring awareness to a user of the mute state of an audio connection; input received at the meeting server via a web browser at user device 14 (e.g., computer used for web session) or input received via user device 15 (e.g., phone used for audio session). The meeting server 16 generates an indication of the mute state change (e.g., `mute off` changed to `mute on` or `mute on` changed to `mute off`) (step 32) and transmits the mute state change for display at a second user device (step 34)) (paragraphs: 0011, 0013, 0019, 0020, 0029); sending, according to the speaking ban request, a speaking ban notification to the clients, so as to impose a speaking ban on the clients (provide notification between dissimilar endpoint devices (platforms) to bring awareness to a user of the mute state of an audio connection; input received at the meeting server via a web browser at user device 14 (e.g., computer used for web session) or input received via user device 15 (e.g., phone used for audio session). The meeting server 16 generates an indication of the mute state change (e.g., `mute off` changed to `mute on` or `mute on` changed to `mute off`) (step 32) and transmits the mute state change for display at a second user device (step 34)) (paragraphs: 0013, 0019, 0020, 0029); and receiving a speaking notification which is generated by the multi-point control end according to the speaking ban lifting request and the permission information, and lifting the speaking ban according to the speaking notification (the user's line remains muted until the user deselects the mute icon adjacent to the their user ID in the meeting application at their computer 46 or turns off the mute (e.g., presses mute button) on their IP phone 50, which initiates a signal back to the communications manager 52, which then communicates the mute state change to the meeting server 16 that the user wants to unmute their audio connection) (paragraphs: 0035 and fig. 2, labels: 20 and 18); however, Grevers does not teach wherein the speaking ban request carries permission information which allows the clients to lift a speaking ban.
In the same field of endeavor, Mazzarella clearly teaches and the speaking ban request is sent by the chairman end and carries permission information which allows the clients to lift a speaking ban; sending, upon the condition that the clients are in a speaking state, a speaking ban lifting request to the multi-point control end (floor control parameters/ permission information can provide a framework for determining whether to grant transmission capabilities to a requesting endpoint. The floor control parameters can include rules or specifications for determining priorities between two or more endpoints in the conferencing session. More particularly, the floor control parameters can resolve the priorities based at least in part on floor control parameter data, such as the current floor allocation (e.g. whether an endpoint currently has transmission capabilities), the order and/or timing of requests, and/or other suitable floor control parameters. The floor control parameter data can further include contextual floor control parameter data, such as the identities the endpoints (or endpoint users) in the conferencing session, attributes or characteristics associated with the endpoints (or endpoint users) in the conferencing session, the relative ranks associated with the endpoints (or endpoint users) in the conferencing session, contextual information asserted by the endpoints (or endpoint users) in the conferencing session, relative importance of the endpoints (or endpoint users) in the conferencing session, the endpoint types of the endpoints; the floor control parameters can be set by a user to reflect the particular circumstances or contexts surrounding the conferencing session. ) (paragraphs: 0020-0025, 0035, 0038 and fig. 3).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to incorporate the teaching of Mazzarella into teaching of Grevers for the purpose of using permission information/ floor control parameters which allows the users to speak or unmute themselves.
Consider claims 9, 14, and 16, Grevers clearly shows and discloses a non-transitory computer-readable storage medium, a device for lifting a speaking ban at a video conference, and a method for lifting a speaking ban at a video conference, applied to clients, the clients being in communication with a chairman end by a multi- point control end, the method comprising: receiving a speaking ban notification sent by the multi-point control end, and imposing a speaking ban according to the speaking ban notification, wherein the speaking ban notification is generated by the multi-point control end according to a speaking ban request (a user, host, or moderator of the session may have the ability to mute a participant or all non-speaking participants; provide notification between dissimilar endpoint devices (platforms) to bring awareness to a user of the mute state of an audio connection; input received at the meeting server via a web browser at user device 14 (e.g., computer used for web session) or input received via user device 15 (e.g., phone used for audio session). The meeting server 16 generates an indication of the mute state change (e.g., `mute off` changed to `mute on` or `mute on` changed to `mute off`) (step 32) and transmits the mute state change for display at a second user device (step 34)) (paragraphs: 0011, 0013, 0019, 0020, 0029); sending, according to the speaking ban request, a speaking ban notification to the clients, so as to impose a speaking ban on the clients (provide notification between dissimilar endpoint devices (platforms) to bring awareness to a user of the mute state of an audio connection; input received at the meeting server via a web browser at user device 14 (e.g., computer used for web session) or input received via user device 15 (e.g., phone used for audio session). The meeting server 16 generates an indication of the mute state change (e.g., `mute off` changed to `mute on` or `mute on` changed to `mute off`) (step 32) and transmits the mute state change for display at a second user device (step 34)) (paragraphs: 0013, 0019, 0020, 0029); and receiving a speaking notification which is generated by the multi-point control end according to the speaking ban lifting request, and lifting the speaking ban according to the speaking notification (the user's line remains muted until the user deselects the mute icon adjacent to the their user ID in the meeting application at their computer 46 or turns off the mute (e.g., presses mute button) on their IP phone 50, which initiates a signal back to the communications manager 52, which then communicates the mute state change to the meeting server 16 that the user wants to unmute their audio connection; allows for in-meeting controls such as the ability to mute attendees or see active speakers. The same link may be used to communicate mute state data from the cloud to the communications manager) (paragraphs: 0035, 0041 and fig. 2, labels: 20 and 18); however, Grevers does not teach wherein the speaking ban request carries permission information which allows the clients to lift a speaking ban.
In the same field of endeavor, Mazzarella clearly teaches the speaking ban request is sent by the chairman end and carries permission information which allows the clients to lift a speaking ban; sending, upon the condition that the clients are in a speaking state, a speaking ban lifting request to the multi-point control end; sending, upon the condition that the clients are in a speaking state, a speaking ban lifting request to the multi-point control end (paragraph 0002, and 0015-0016); and the permission information, and lifting the speaking ban according to the speaking notification (floor control parameters/ permission information can provide a framework for determining whether to grant transmission capabilities to a requesting endpoint. The floor control parameters can include rules or specifications for determining priorities between two or more endpoints in the conferencing session. activates a command control state whereby the two-way radio communications device or PTT application may transmit voice commands to the agent to perform conference endpoint functions in the conference, an agent may be invited to join or joins as a identified conference endpoint, or is otherwise announced or displayed as being present to other conference endpoints) (paragraphs: 0020-0025, 0035, 0038, 0086, 0088 and fig. 3).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to incorporate the teaching of Mazzarella into teaching of Grevers for the purpose of using permission information/ floor control parameters which allows the users to speak or unmute themselves.
Consider claims 2 and 18, Grevers and Mazzarella clearly show the non-transitory computer-readable storage medium, the device and the method, wherein prior to receiving the speaking ban request from the chairman end, the method further comprises: enabling a pre-configured function that allows lifting a speaking ban; wherein enabling the pre-configured function that allows lifting a speaking ban comprises: acquiring a configuration instruction, so as to configure a function that allows the chairman end and the clients to lift a speaking ban; and acquiring an enabling instruction, so as to enable the function that allows the chairman end and the clients to lift a speaking ban (Mazzarella: fig. 3).
Consider claim 3, Grevers and Mazzarella clearly show the non-transitory computer-readable storage medium, the device and the method, wherein after receiving the speaking ban request from the chairman end, the method further comprises: recording the permission information which allows the clients to lift a speaking ban (the floor control parameters can be set by a user) (Mazzarella: paragraphs: 0020-0025, 0035, 0038 and fig. 3 ).
Consider claim 4, Grevers and Mazzarella clearly show the method, wherein receiving the speaking ban lifting request from the target client comprises: receiving a request for turning on a corresponding microphone from the target client (Mazzarella: paragraphs: 0011, 0013, 0019, 0020, and 0029).
Consider claim 5, Grevers and Mazzarella clearly show the method, wherein sending the speaking notification to the target client comprises: sending the speaking notification to the target client corresponding to the microphone (Grevers: paragraphs: 0035, 0041 and fig. 2, labels: 20 and 18).
Consider claim 6, Grevers and Mazzarella clearly show the method, further comprising: receiving state information of the target client, wherein the state information represents that a microphone of the target client is in an ON state; and sending, upon the condition that the multi-point control end is in a state that allows lifting a speaking ban, a conference-participation instruction to the target client according to the state information, such that the target client joins a sound- mixing conference (Grevers: paragraphs: 0011, 0013, 0019, 0020, 0029).
Consider claim 7, Grevers and Mazzarella clearly show the method, further comprising: receiving change information of the chairman end, and disabling the function that allows lifting a speaking ban according to the change information, wherein the change information represents that the chairman end lifts a speaking ban, is offline, or releases a token (Grevers: paragraphs: 0011, 0013, 0019, 0020, 0029).
Consider claim 8, Grevers and Mazzarella clearly show the method, wherein the transaction is in process on the first communication channel prior to the user device accessing the second communication channel (Grevers: 0011, 0013, 0019, 0020, 0029).
Consider claim 10, Grevers and Mazzarella clearly show the method, wherein lifting the speaking ban according to the speaking notification comprises: turning on a microphone according to the speaking notification (Grevers: paragraphs: 0013, 0019, 0020, 0029).
Consider claim 17, Grevers and Mazzarella clearly show the method, wherein the multi-point control end comprises a voice function unit and a conference control unit, receiving the request for turning on the corresponding microphone from the target client comprises: receiving and reporting, by the voice function unit, the request for turning on the corresponding microphone from the target client (Mazzarella: paragraphs: 0011, 0013, 0019, 0020, and 0029 and fig. 3).
Consider claim 18, Grevers and Mazzarella clearly show the method, wherein sending the speaking notification to the target client corresponding to the microphone comprises: determining, by the conference control unit, whether the target client is allowed to lift the speaking ban according to the permission information; in response to that the target client is allowed to lift the speaking ban according to the permission information, sending, by the conference control unit, the speaking notification to the target client corresponding to the microphone (Mazzarella: paragraphs: 0011, 0013, 0019, 0020, and 0029 and fig. 3).
Consider claim 19, Grevers and Mazzarella clearly show the method, wherein determining whether the target client is allowed to lift the speaking ban according to the permission information comprises: upon the condition that the speaking ban request carries permission information which allows the target client to lift a speaking ban, determining the target client is allowed to lift the speaking ban; or upon the condition that speaking ban request does not carry permission information which allows the target client to lift a speaking ban, determining the target client is not allowed to lift the speaking ban (Mazzarella: paragraphs: 0011, 0013, 0019, 0020, and 0029 and fig. 3).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Amal Zenati whose telephone number is 571-270-1947. The examiner can normally be reached on 8:00 -5:00 M-F.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ahmad Matar can be reached on 571- 272- 7488. The fax phone number for the organization where this application or proceeding is assigned is 571- 273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/AMAL S ZENATI/Primary Examiner, Art Unit 2693
Prosecution Insights