Method and apparatus for distributed arbitration of a right to speak among a plurality of devices participating in a real-time voice conference
Claim Score by NHIP
Abstract
An agent (100) is associated with each of a plurality of devices (201-204) for arbitrating between a talk stream generated by the device and a listen stream intended for the device and generated by another device on a network (210). In the agent a "Talk Mode" (300) is defined in which the agent passes the talk stream from the device to other devices participating in the conference while blocking all listen streams intended for the device, and a "Listen Mode" (400) is defined in which the agent blocks the talk stream of the device from the network and passes a single listen stream from the network to the device. The agent makes a decision to enter one of the Talk Mode and the Listen Mode, wherein the decision is based upon a presence of at least one of the talk stream and the listen stream, and wherein the decision is further based upon a comparison of source identifiers of the talk and listen streams when required to resolve a conflict.

Term
Term ended
Projected expiry passed 14 June 2022, 4.3 years ago.
- Priority and filed
- Published
- Projected expiry
- Today
25 claims: 3 independent, 22 dependent
- 1A method for distributed arbitration of a right to speak among a plurality of devices participating in a real-time voice conference through a network via multimedia data packets having source identifiers, the method comprising the steps of:associating an agent with each of the plurality of devices for arbitrating between a talk stream generated by the device and a listen stream intended for the device and generated by another device on the network;defining in the agent a “Talk Mode” in which the agent passes the talk stream from the device to other devices participating in the conference while blocking all listen streams intended for the device, and a “Listen Mode” in which the agent blocks the talk stream of the device from the network and passes a single listen stream from the network to the device;and making a decision, by the agent, to enter one of the Talk Mode and the Listen Mode, wherein the decision is based upon a presence of at least one of the talk stream and the listen stream, and wherein the decision is further based upon a comparison of the source identifiers of the talk and listen streams when required to resolve a conflict.
- 11An apparatus in a network for distributed arbitration of a right to speak among a plurality of devices participating in a real-time voice conference through the network via multimedia data packets having source identifiers, the apparatus comprising:a device interface for communicating with a device of the plurality of devices;a network interface for communicating with other devices through the network;and a processor coupled to the device interface and coupled to the network interface for controlling communications through the device interface and the network interface, wherein the processor is programmed to: act as an agent associated with the device for arbitrating between a talk stream generated by the device and a listen stream intended for the device and generated by another device on the network;define in the agent a “Talk Mode” in which the agent passes the talk stream from the device to the other devices participating in the conference while blocking all listen streams intended for the device, and a “Listen Mode” in which the agent blocks the talk stream of the device from the network and passes a single listen stream from the network to the device;and make a decision to enter one of the Talk Mode and the Listen Mode, wherein the decision is based upon a presence of at least one of the talk stream and the listen stream, and wherein the decision is further based upon a comparison of the source identifiers of the talk and listen streams when required to resolve a conflict.
- 21Broadest claimClaim Score 50, average(NHIP)A method for distributed arbitration of a right to speak among a plurality of devices participating in a real-time voice conference through a network via multimedia data packets having source identifiers, the method comprising the steps of:associating an agent with each of the plurality of devices for arbitrating between a talk stream generated by the device and a listen stream intended for the device and generated by another device on the network;defining in the agent a “Converge-Talk Mode” in which the agent provisionally passes the talk stream from the device to other devices participating in the conference while blocking all listen streams intended for the device, and a “Converge-Listen Mode” in which the agent blocks the talk stream of the device from the network and passes a single listen stream from the network to the device;and making a decision, by the agent, to enter one of the Converge-Talk Mode and the Converge-Listen Mode, wherein the decision is based upon a presence of at least one of the talk stream and the listen stream, and wherein the decision is further based upon a comparison of the source identifiers of the talk and listen streams when required to resolve a conflict.
Independent claims3
44 paragraphs in 4 sections, as filed
FIELD OF THE INVENTION
[0001] This invention relates in general to wireless communication systems, and more specifically to a method and apparatus for distributed arbitration of a right to speak among a plurality of devices participating in a real-time voice conference through a network via multimedia data packets having source identifiers.
BACKGROUND OF THE INVENTION
[0002] Voice “chat” and voice conferencing can put high traffic loads on an internet protocol (IP) network. Voice over IP uses the well-known Real Time Protocol (RTP) to send voice data packets between participants. Most of the time only one person is speaking and the RTP traffic is reasonable. However, when multiple participants speak at the same time, the network traffic increases tremendously. This can saturate the network and result in unintelligible speech. The unintelligible speech then further adds to the confusion.
[0003] A prior art solution has been the use of a centralized entity such as a conference bridge. The conference bridge hears all participants, but transmits only one selected participant. This solution complicates call setup and is expensive. It also does not reduce the load of the voice data from all participants coming into the conference bridge. The problem becomes even more serious in a wireless system. When several participants speak at the same time the amount of traffic for a single participant easily surpasses the capacity of the wireless channel to the participant. Several prior-art solutions are available. One is the insertion of a mixer in the wireless infrastructure. Another is the construction of a centralized dedicated controller, such as the Dispatch Application Processor (DAP) in the well-known iDEN dispatch system. The iDEN DAPs make sure that at any time only one participant can speak.
[0004] Because centralized solutions are expensive and do not scale well, what is needed is a distributed solution to limit the amount of voice conference data that is allowed to enter the network. Preferably, the solution will allow only one speaker at a time to have the right to speak.
BRIEF DESCRIPTION OF THE DRAWINGS
[0005]FIG. 1 is an exemplary electrical block diagram of an apparatus in accordance with the present invention.
[0006]FIG. 2 is an exemplary diagram depicting voice data flow through a network in accordance with the present invention.
[0007]FIG. 3 is an exemplary diagram depicting voice data flow through an agent in Talk Mode in accordance with the present invention.
[0008]FIG. 4 is an exemplary diagram depicting voice data flow through the agent in Listen Mode in accordance with the present invention.
[0009]FIG. 5 is an exemplary diagram depicting voice data flow and operation of the agent in accordance with the present invention.
[0010]FIG. 6 is an exemplary diagram depicting operation of the agent as it transitions from Talk Mode to Idle Mode in accordance with the present invention.
[0011]FIG. 7 is an exemplary diagram depicting operation of the agent as it transitions from Listen Mode to Idle Mode in accordance with the present invention.
[0012]FIG. 8 is an exemplary diagram depicting voice data flow through the network in accordance with the present invention.
[0013]FIG. 9 is an exemplary diagram depicting operation of the agent as it transitions from Idle Mode to Converge-Talk Mode in accordance with the present invention.
[0014]FIG. 10 is an exemplary diagram depicting operation of the agent as it transitions from Idle Mode to Converge-Listen Mode in accordance with the present invention.
[0015] FIGS. <b>11</b>-<b>13</b> are exemplary diagrams depicting operation of a four-way conference in accordance with the present invention, when two participants start to speak at about the same time.
[0016]FIG. 14 is an exemplary diagram depicting operation of the four-way conference in accordance with the present invention, when the network becomes separated into two networks.
DETAILED DESCRIPTION OF THE DRAWINGS
[0017] Referring to FIG. 1, an exemplary electrical block diagram depicts an apparatus <b>100</b> in accordance with the present invention. The apparatus <b>100</b> comprises a device interface <b>102</b> for communicating with a device, such as a mobile station (MS) <b>201</b> (FIG. 2). The apparatus <b>100</b> further comprises a network interface <b>106</b> for communicating with other devices <b>202</b>-<b>204</b> (FIG. 2) through a network <b>210</b> (FIG. 2). In addition, the apparatus <b>100</b> includes a processor <b>104</b> coupled to the device interface <b>102</b> and coupled to the network interface <b>106</b> for controlling communications through the device interface and the network interface. The apparatus <b>100</b> also includes a memory <b>108</b> coupled to the processor <b>104</b> for storing software for programming the processor <b>104</b> in accordance with the present invention. It will be appreciated that, alternatively, the processor <b>104</b> and the memory <b>108</b> can be manufactured as a single integrated component, as well. Indeed, the entire apparatus <b>100</b> alternatively can be manufactured as a single integrated component, if desired.
[0018] The memory <b>108</b> comprises an agent-device association program <b>110</b> for programming the processor <b>104</b> to act as an agent associated with the device <b>201</b> for arbitrating between a talk stream generated by the device and a listen stream intended for the device and generated by another device <b>202</b>-<b>204</b> on the network. The memory <b>108</b> further comprises a mode select program <b>112</b> for programming the processor <b>104</b> to define in the agent a “Talk Mode” in which the agent passes the talk stream from the device to the other devices participating in the conference while blocking all listen streams intended for the device, and a “Listen Mode” in which the agent blocks the talk stream of the device from the network and passes a single listen stream from the network to the device. The mode select program <b>112</b> also programs the processor <b>104</b> to make a decision to enter one of the Talk Mode and the Listen Mode, wherein the decision is based upon a presence of at least one of the talk stream and the listen stream, and wherein the decision is further based upon a comparison of source identifiers of the talk and listen streams when required to resolve a conflict. Streams will be used to carry the voice data of each participant. A stream that carries voice information is called a non-silent stream. Depending on the vocoder being used, when the participant stops speaking, the stream is either interrupted, or the vocoder produces “silent” packets that can represent background noise.
[0019] The memory <b>108</b> further comprises a stream detect program <b>114</b> for programming the processor <b>104</b> to detect the presence of a non-silent talk stream from the device <b>201</b> as well as a non-silent listen stream intended for the device. The memory <b>108</b> also includes a stream select program <b>116</b> for programming the processor <b>104</b> to select either the talk stream or one of the listen streams as the stream to pass, while blocking all others, in accordance with the present invention. In addition, the memory <b>108</b> includes a source identifier compare program <b>118</b> for programming the processor <b>104</b> to compare the source identifiers of the talk and listen streams to determine the highest priority stream. The memory <b>108</b> further comprises a plurality of timer programs <b>120</b> for programming the processor <b>104</b> to keep track of timing functions utilized in accordance with the present invention. The memory <b>108</b> also includes a priority mapping program <b>122</b> for programming the processor <b>104</b> to map the source identifiers into priority levels, according to predetermined rules. Because the apparatus <b>100</b> is arranged and programmed to act as an agent on behalf of its associated device, the apparatus <b>100</b> will also be referred to herein as the agent <b>100</b>. Operation of the agent <b>100</b> will now be described in further detail.
[0020] Referring to FIG. 2, an exemplary diagram <b>200</b> depicts voice data flow through a network in accordance with the present invention. The diagram <b>200</b> comprises devices <b>201</b>-<b>204</b>, preferably mobile stations, e.g., cellular telephones. The wireless link of each device <b>201</b>-<b>204</b> is coupled through an associated agent <b>100</b> to a packet data network <b>210</b>, e.g., a cellular infrastructure having packet data capability. All agents <b>100</b> use substantially the same algorithm. The algorithm is constructed such that the agents <b>100</b> do not need to exchange explicit information related to floor control. Each agent <b>100</b> limits the number of voice streams allowed into the network. It will be appreciated that, alternatively, the devices <b>201</b>-<b>204</b> can comprise wired devices. For a wired device, such as a PC, IP telephone, etc., the agent <b>100</b> preferably resides inside the device <b>201</b>-<b>204</b> itself. With wireless devices the agent <b>100</b> can reside in the MS, but preferably resides in the infrastructure. This advantageously limits the over-the-air (OTA) traffic. It will be appreciated that in one embodiment the device <b>201</b>-<b>204</b>, alternatively, can be a device, e.g., a conference bridge, which itself performs an arbitration of a right to speak for a plurality of separate devices, e.g., telephone sets. In that embodiment, the device <b>201</b>-<b>204</b> preferably provides a single talk stream into the agent <b>100</b>, and receives a single listen stream from the agent <b>100</b>. During operation, the agent <b>100</b> preferably runs in one of five Modes: Talk, Listen, Idle, Converge-Talk, and Converge-Listen. The need for, and operation of each of the five Modes will now be described.
[0021]FIG. 3 is an exemplary diagram <b>300</b> depicting voice data flow through the agent <b>100</b> in Talk Mode in accordance with the present invention. In Talk Mode the agent <b>100</b> receives, for example, an RTP stream from the associated device <b>201</b> (the ‘talk’ stream <b>202</b>) and sends the RTP stream to the other participants in the conference. The agent <b>100</b> blocks all listen streams <b>204</b> to the device <b>201</b>. The agent <b>100</b> preferably identifies selected streams through a well-known synchronization source identifier (SSRC) in the RTP header. The agent <b>100</b> can do the replication of the voice packets <b>206</b> for multiple participants, which reduces OTA load, or use IP multicast, to also reduce network load.
[0022]FIG. 4 is an exemplary diagram <b>400</b> depicting voice data flow through the agent <b>100</b> in Listen Mode in accordance with the present invention. In Listen Mode the agent <b>100</b> blocks the talk stream of the associated device <b>201</b> and passes exactly one <b>402</b> of the incoming ‘listen’ streams to the device <b>201</b>.
[0023]FIG. 5 is an exemplary diagram <b>500</b> depicting voice data flow and operation of the agent <b>100</b> in accordance with the present invention. The algorithm of the agent <b>100</b> is arranged such that normally there is only one agent <b>100</b> in Talk Mode at a given time, while the other agents <b>100</b> participating in the conference are in Listen Mode.
[0024]FIGS. 6 and 7 are exemplary diagrams <b>600</b>, <b>700</b> depicting operation of the agent <b>100</b> as it transitions from Talk Mode and Listen Mode, respectively, to Idle Mode in accordance with the present invention. The agent <b>100</b> uses a timer to define when a selected stream stops sending voice: when for a duration of t_idle, an agent <b>100</b> does not receive packets of the selected stream or receives only packets that encode silence, the agent <b>100</b> transitions to Idle Mode. All agents <b>100</b> preferably use the same value for t_idle. Note that with this mechanism one can not interrupt a speaker that does not pause for t_idle. In a conference the selected speaker will sooner or later stop speaking. All agents <b>100</b> will then go to Idle Mode and another participant may take a turn speaking. In a crude solution to the problem, each Idle Mode agent <b>100</b> could give the floor to the first speaker from which it receives a RTP stream.
[0025] It is easy to imagine that this leads to problems when two participants speak up at the same time (due to differential delays through the packet data network). For this reason the agents <b>100</b> preferably do not go directly from Idle Mode to Talk Mode or Listen Mode. When an agent <b>100</b> becomes Idle, it listens to all possible streams to detect a non-silent one. When a non-silent stream is detected, the agent <b>100</b> preferably goes through a convergence period of duration t_converge. All agents <b>100</b> preferably use the same value for t_converge. When the first detected stream comes from the agent's associated device <b>201</b>, the agent <b>100</b> transitions to Converge-Talk Mode; when the first detected stream is directed to the device <b>202</b>-<b>204</b>, the agent <b>100</b> transitions to Converge-Listen Mode, as depicted in FIGS. <b>8</b> to <b>10</b>. During a Converge Mode, the agent <b>100</b> looks for additional non-silent streams.
[0026] One or more non-silent streams may already be present when the agent <b>100</b> transitions to Idle Mode. If there is only one such stream, the agent <b>100</b> directly transitions to Converge-Talk or Converge-Listen Mode, as appropriate. However, when more than one non-silent stream is present, the agent <b>100</b> preferably is able to predictably pick one. Preferably all agents will pick the same stream. Therefore all agents use a common prioritization method:
[0027] A listen stream towards the device <b>201</b>-<b>204</b> associated with the agent <b>100</b> always has priority over a talk stream from the associated device <b>201</b>-<b>204</b>.
[0028] Prioritization among multiple listen streams is based on the source identifier of the stream, e.g., the SSRC in the header of the stream. A primitive—but quite acceptable—version of prioritization simply picks the stream with the highest SSRC.
[0029] During the Converge Modes, the agents <b>100</b> look for a more appropriate stream and, upon finding one, switch to it. To limit network traffic the selection algorithm preferably is biased against talkers.
[0030] In Converge-Listen Mode (FIG. 10) the agent <b>100</b> blocks the talk stream from the associated device <b>201</b>-<b>204</b> as long as a listen stream towards the associated device <b>201</b>-<b>204</b> is present. However, the agent <b>100</b> also continuously looks for new listen streams. It will select the listen stream with the highest priority (based on the source identifier) and switch to it as soon as it has been observed. When the t_converge timer runs out while the agent is in Converge-Listen Mode, the agent goes to Listen Mode. If t_idle is shorter than t_converge, the agent <b>100</b> can also transition to Idle Mode. If the listen stream stops for t_presence and no other listen stream is present, a talk stream can take over. The use of t_presence is explained further below. The agent <b>100</b> would then transition to the Converge-Talk Mode.
[0031] In Converge-Talk Mode (FIG. 9) the agent continuously looks for new listen streams. If the agent <b>100</b> detects a listen stream towards the associated device <b>201</b>-<b>204</b> with a priority that is higher than that of the talk stream, the agent <b>100</b> immediately switches to the listen stream and transitions to the Converge-Listen Mode. Preferably, the t_converge timer is not reset. When the t_converge timer runs out while the agent is in the Converge-Talk Mode, the agent <b>100</b> transitions to the Talk Mode. It will be appreciated that, because a stream consists of discrete data packets, the presence or absence of a stream needs to be defined. A reasonable definition is that a stream preferably is considered present as long as a non-silent packet belonging to the stream (based on the source identifier) has been received during the preceding period of length t_presence. All agents <b>100</b> preferably use the same value for t_presence. Preferably, t_presence is selected to be equal to or greater than three times the normal packet inter-arrival time for a non-silent stream. This will prevent a small number of missed or delayed packets for misleading the agent <b>100</b>. It will be appreciated that, alternatively, other values can be selected for t_presence as well, depending on the network <b>210</b>.
[0032] FIGS. <b>11</b>-<b>13</b> are exemplary diagrams <b>1100</b>-<b>1300</b> depicting operation of a four-way conference in accordance with the present invention, when two participants start to speak at about the same time. It is assumed that the priority of device <b>203</b> is higher than that of device <b>201</b>.
[0033] At the start of the example, all agents are in the Idle Mode. The participants using devices <b>201</b> and <b>203</b> start to talk at the same time. As depicted in the diagram <b>1100</b>, the agents <b>100</b> associated with the devices <b>201</b> and <b>203</b> will transition to the Converge-Talk Mode and will copy their talk streams onto the network <b>210</b>. The agent <b>100</b> associated with the device <b>202</b> receives the stream from the device <b>201</b> first, transitions to the Converge-Listen Mode, and passes the stream from the device <b>201</b> to the device <b>202</b>. Similarly the agent <b>100</b> associated with the device <b>204</b> passes the stream from the device <b>203</b>.
[0034] Referring to the diagram <b>1200</b>, the stream from <b>203</b> now reaches the agents for <b>201</b> and <b>202</b>, and the stream from <b>201</b> reaches the agents for <b>203</b> and <b>204</b>. Agents <b>100</b> for <b>202</b> and <b>204</b> are in the Converge-Listen Mode. They receive streams from <b>201</b> and <b>203</b>. Both will select the stream from <b>203</b> because it has higher priority. Agents <b>100</b> associated with <b>201</b> and <b>203</b> are in Converge-Talk Mode and compare the newly received stream from <b>203</b> with their currently selected (talk) streams.
[0035] The agent <b>100</b> associated with <b>201</b> finds that the new stream from <b>203</b> has higher priority, blocks its talk-stream, switches to the stream from <b>203</b>, and transitions to the Converge-Listen Mode. The agent <b>100</b> associated with <b>203</b> finds that the new stream from <b>201</b> has lower priority and will block it. The agent <b>100</b> will stay in Converge-Talk Mode.
[0036] Referring to the diagram <b>1300</b>, agents associated with <b>201</b>, <b>202</b> and <b>204</b> are now in Converge-Listen mode. Soon there will be no more data from <b>201</b> on the network. Agents of <b>202</b> and <b>204</b> will also block any talk streams from their devices, even if their devices have a higher priority than the device <b>203</b>. Note that this method advantageously is very robust. Even if for some reason the agent <b>100</b> of <b>202</b> would not have selected the stream from <b>203</b>, the stream from <b>201</b> would soon have dried out. That would the force the agent <b>100</b> of <b>202</b> to switch to the stream from <b>203</b> anyway.
[0037]FIG. 14 is an exemplary diagram <b>1400</b> depicting operation of the four-way conference in accordance with the present invention, when the network <b>210</b> becomes separated into two networks <b>1402</b>, <b>1404</b>. Another sign of robustness is that the conference is self-organizing. If, for example, the network <b>210</b> gets cut into two separate areas, each area will be able to continue its conference with a limited set of participants. When the network connection is restored later on, the conference will reconnect automatically after one area has an idle period.
[0038] One of ordinary skill in the art will recognize that there can be many variations on the prioritization algorithm. As a first alternative example, during call setup the participants can agree on the relative priorities of the devices participating in the conference. The participants can then either assign SSRC values accordingly, or inform the agents <b>100</b> of the SSRC priority scheme.
[0039] As a second alternative example, to avoid that some users always have higher priorities, one can change the prioritization algorithm such that user prioritization rotates. For example, if all agents are time-synchronized, one can make them add, modulo 2^ 32, different numbers from a suitable range of pseudorandom offset numbers to each SSRC (assuming a 32-bit SSRC). Each agent can then derive its offset each minute. Alternatively one can make each agent use a one-way hash function that inputs the time value and the SSRC of a stream to derive a new, scrambled identifier for the stream. The agent would then prioritize competing streams using the scrambled identifiers.
[0040] As a third alternative example, to provide the equivalent of a dispatcher that can always barge in, one can instruct all agents <b>100</b> to always give priority to a stream with the SSRC of the dispatcher. When the dispatcher then starts to talk, its agent <b>100</b> would go into Talk Mode and transmit the stream on the network <b>210</b>. Other agents <b>100</b> would then go to Listen Mode and switch to the dispatcher's stream as soon as they observe its SSRC.
[0041] As a fourth alternative embodiment, the present invention can be used in a multimedia (voice and video) conference. In such a multimedia conference it will be appreciated that it will be advantageous for the agent <b>100</b> to switch the video along with the voice, such that the speaker who currently has the right to speak also can be seen on video by the other participants.
[0042] It will be appreciated that there can be simpler alternative embodiments which use fewer Modes. For example, in one alternative embodiment the agents <b>100</b> can use the t_presence and t_idle timers and only the Converge-Talk, Converge-Listen, and Idle Modes. When no non-silent streams are present, the agent <b>100</b> simply waits in the Idle Mode for a stream to show up. The disadvantage of this embodiment is that it provides a less stable floor control. The use of the additional Talk and Listen Modes makes it more difficult to interrupt a speaker who has the floor.
[0043] It should be clear from the preceding disclosure that the present invention provides a method and apparatus which provides a distributed solution to limit the amount of voice conference data that is allowed to enter a network. Advantageously, the method and apparatus allow only one speaker at a time to have the right to speak. A further advantage is that the distributed architecture of the present invention is economical for small networks, and it scales well for large networks.
[0044] Many modifications and variations of the present invention are possible in light of the above teachings. Thus, it is to be understood that, within the scope of the appended claims, the invention can be practiced other than as specifically described herein above.
Contents4
7 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7
Every citation, both ways
| Document | Relation | Office | Cited during |
|---|---|---|---|
| US9025497B2 | Cited by | United States of America | Search report |
| WO2009073362A3 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| US2011141929A1 | Cited by | United States of America | Pre-grant |
| CN1317862C | Cited by | China | Search report |
| US2011167104A1 | Cited by | United States of America | Pre-grant |
| US2006050658A1 | Cited by | United States of America | Pre-grant |
| US2006140137A1 | Cited by | United States of America | Pre-grant |
| US8687613B2 | Cited by | United States of America | Applicant |
| WO2009073362A2 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| US2009144441A1 | Cited by | United States of America | Pre-grant |
| US7940705B2 | Cited by | United States of America | Search report |
| US10057426B2 | Cited by | United States of America | Search report |
| US7085263B1 | Cited by | United States of America | Search report |
| US7813327B2 | Cited by | United States of America | Applicant |
| US2010322137A1 | Cited by | United States of America | Pre-grant |
| GB2467675A | Cited by | United Kingdom | Search report |
| US9088630B2 | Cited by | United States of America | Applicant |
| WO2009073362A3 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| US5859663A | Cites | United States of America | Pre-grant |
| US6418125B1 | Cites | United States of America | Pre-grant |
| US6477150B1 | Cites | United States of America | Pre-grant |
| US6564261B1 | Cites | United States of America | Pre-grant |
| US6574469B1 | Cites | United States of America | Pre-grant |
2 members in 1 office
Priority claims2
| Document | Office | Kind | Date |
|---|---|---|---|
| 79690001 | United States of America | A | |
| US20010796900 | – | – | – |
Members2
| Document | Office | Kind | |
|---|---|---|---|
| US2002119795A1 | United States of America | A1 | |
| US6697614B2 | United States of America | B2 |
29 transactions on the USPTO file
Allowed without a rejection on record.
- Non-final rejections
- 0
- Final rejections
- 0
- RCEs
- 0
- Appeals
- 0
Over time
Point at a mark for the transactionTransactions
| Event | |
|---|---|
| Email Notification | |
| Change in Power of Attorney (May Include Associate POA) | |
| Correspondence Address Change | |
| Recordation of Patent Grant Mailed | |
| Patent Issue Date Used in PTA CalculationAllowed | |
| Issue Notification MailedAllowed | |
| Receipt into Pubs | |
| Application Is Considered Ready for Issue | |
| Receipt into Pubs | |
| Workflow - File Sent to Contractor | |
| Receipt into Pubs | |
| Mail Miscellaneous Communication to Applicant | |
| Miscellaneous Communication to Applicant - No Action Count | |
| Issue Fee Payment Verified | |
| Issue Fee Payment Received | |
| Mail Notice of AllowanceAllowed | |
| Notice of Allowance Data Verification CompletedAllowed | |
| Case Docketed to Examiner in GAU | |
| Case Docketed to Examiner in GAU | |
| Case Docketed to Examiner in GAU | |
| Case Docketed to Examiner in GAU | |
| Application Dispatched from OIPE | |
| Correspondence Address Change | |
| IFW Scan & PACR Auto Security Review | |
| Workflow - Drawings Finished | |
| Workflow - Drawings Matched with File at Contractor | |
| Information Disclosure Statement (IDS) Filed | |
| Information Disclosure Statement (IDS) Filed | |
| Initial Exam Team nn |
6 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Fee paymentFPAY | FPAY | |
| Fee paymentFPAY | FPAY | |
| AssignmentAS | AS | |
| Fee paymentFPAY | FPAY | |
| Information on status: patent grantGrantedPATENTED CASESTCF | STCF | |
| AssignmentAS | AS |
Numbers
- Publication, DOCDB
- 2002119795
- Publication, EPODOC
- US2002119795
- Application
- 9796900
- Application, DOCDB
- 79690001
- Application, EPODOC
- US20010796900
Titles
- English
- Method and apparatus for distributed arbitration of a right to speak among a plurality of devices participating in a real-time voice conference
Patent term adjustment
- A delay
- +472 daysthe office missed an examination deadline
- Net adjustment
- 472 days
Classification
- CPC, 4
- H04M3/56
- H04M3/566
- H04M3/569
- H04M7/006
- IPC, 2
- H04M3 56
- H04M7 00
- USPC, 2
- 455509000
- 455518000