CN1925410A - 表决消息创建、处理、及结果确定方法和控制协议、表决评估、会议服务器部件和通信终端 - Google Patents

表决消息创建、处理、及结果确定方法和控制协议、表决评估、会议服务器部件和通信终端 Download PDF

Info

Publication number
CN1925410A
CN1925410A CN200610121442.7A CN200610121442A CN1925410A CN 1925410 A CN1925410 A CN 1925410A CN 200610121442 A CN200610121442 A CN 200610121442A CN 1925410 A CN1925410 A CN 1925410A
Authority
CN
China
Prior art keywords
voting
host
protocol
control protocol
message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN200610121442.7A
Other languages
English (en)
Other versions
CN1925410B (zh
Inventor
A·施密特
N·施瓦格曼
H·施密特
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Infineon Technologies AG
Intel Deutschland GmbH
Original Assignee
Infineon Technologies AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Infineon Technologies AG filed Critical Infineon Technologies AG
Publication of CN1925410A publication Critical patent/CN1925410A/zh
Application granted granted Critical
Publication of CN1925410B publication Critical patent/CN1925410B/zh
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1813—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H04L65/403—Arrangements for multi-party communication, e.g. for conferences
    • H04L65/4038—Arrangements for multi-party communication, e.g. for conferences with floor control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Abstract

公开了一种利用计算机辅助创建表决消息的方法、利用计算机辅助确定至少一个表决结果的方法、利用计算机辅助处理表决消息的方法、传输协议的控制协议部件、会议表决评估部件、会议服务器部件和通信终端。包括表决询问的表决消息被依照例如实时传输控制协议之类的传输协议的控制协议来编码，并且在会议期间被发送以便发起表决。

Description

表决消息创建、处理、及结果确定方法 和控制协议、表决评估、会议服务器部件和通信终端
技术领域
本发明涉及一种利用计算机辅助创建表决消息的方法、一种确定至少一个表决的至少一个表决结果的方法、一种利用计算机辅助处理表决消息的方法、一种传输控制协议部件、一种会议表决评估部件、一种会议服务器部件以及一种通信终端。
背景技术
在现代通信***中，在通信***内常常希望在多个订户之间换句话说在多个通信终端之间进行会议。用于提供诸如此类会议***的通信***可以使用通信终端来在多个用户之间通信。想要一种使会议的参与者能够执行表决的会议***。
附图说明
图1依照本发明一个示例性实施例示出了按键通话(push-to-talk)通信***的体系结构；和
图2依照本发明一个示例性实施例示出了用于图示在表决过程期间的消息流的消息流程图。
具体实施方式
在下文中，举例来说，会议***被理解为基于因特网协议的会议***或所谓的按键通话***，或者通常的任何***，其中通信***内的通信终端可以在通信会议内彼此通信，就是说能够在所述通信终端之间发送数据。
按键通话通信***(PTT通信***)被理解为例如意指来自美国Nextel公司的“直接连接(Direct Connect)”通信***或来自开放移动同盟(Open Mobile Alliance OMA)的经由蜂窝的按键通话(Push-to-talk over Cellular PoC)的通信***，PTT通信***是用于移动无线电通信终端(例如移动无线电电话)的多订户通信***。讲话者通常依照与处理无线电话机(walky-talky)类似方式来在他的移动无线电通信终端上操作特定按钮，以便询问谈话权继而把谈话消息发送到PPT通信会话内的其它移动无线电通信终端。在此期间禁止传输来自其它移动无线电通信终端的其它用户的消息。因而PTT通信***通常是半双工通信***。
依照来自IETF(因特网工程任务组)或现代按键通话通信***中的一个建议，借助于所谓的实时传输协议(Real-Time TransportProtocol RTF)来发送将要在会议***中发送的媒体数据，例如音频数据和/或视频数据和/或静止图像数据和/或文本数据。借助于所谓的实时传输控制协议(Real-Time Transport Control Protocol RTCP)来监视媒体数据流。
会议***和按键通话通信***都具有集中式的体系结构。换句话说，这意味着诸如此类会议***的订户没有直接地彼此进行通信，而是借助于中央服务器部件来进行所述通信。也被称为会议服务器部件的中央服务器部件在移动无线电通信***中被布置在通信网络的非移动区域中，例如在UMTS(Universal Mobile Telecommunications System通用移动电信***)的情况下是布置在核心网络中。
在按键通话通信***中，订户通信终端上的请求按钮可以用于简单的(二值)表决。
依照本发明一个实施例，在会议***中可以依照简单的方式来进行计算机辅助表决。
在本发明的一个实施例中，提供了一种在多个通信终端之间的会议中利用计算机辅助创建表决消息的方法，其中所述表决消息依照例如实时传输协议的控制协议之类的传输协议的控制协议来编码，借助于传输协议的控制协议控制例如实时传输协议之类的传输协议，用于标识至少一个表决询问或至少一个表决响应的信息项被添加到所述表决消息。
在本发明的一个实施例中，提供了一种在多个通信终端之间的会议中确定至少一个表决的至少一个表决结果的方法，其中解码至少一个接收的表决响应消息，所述表决响应消息依照例如实时传输协议的控制协议之类的传输协议的控制协议编码，借助于传输协议的控制协议控制例如实时传输协议之类的传输协议，所述表决响应消息包括用于表决的至少一个表决询问的至少一个响应。根据所解码的表决响应消息来确定至少一个响应，并且使用至少一个确定的响应来确定至少一个表决结果。
在本发明的一个实施例中，提供了一种在多个通信终端之间的会议中处理表决消息的方法，其中接收表决消息，所述表决消息被依照例如实时传输协议的控制协议之类的传输协议的控制协议编码，借助于传输协议的控制协议控制例如实时传输协议之类的传输协议，并且根据所述表决消息来确定用于标识至少一个表决询问的信息项和/或用于标识至少一个表决响应并且包含在所述表决消息中的信息项。向参与表决的通信终端的用户显示至少一个表决询问和/或至少一个表决响应，并且用户输入对所述至少一个表决询问的至少一个响应，换句话说它依照表决询问来执行表决过程。此外，表决响应消息依照例如实时传输协议的控制协议之类的传输协议的控制协议编码，借助于传输协议的控制协议控制例如实时传输协议之类的传输协议，用于标识对至少一个表决询问的至少一个响应的信息项被添加到表决响应消息。
依照本发明另一实施例，提供了一种传输协议的控制协议部件，例如实时传输协议的控制协议部件，用于在多个通信终端之间的会议中创建表决消息，所述表决消息依照例如实时传输协议的控制协议之类的传输协议的控制协议编码，借助于传输协议的控制协议控制例如实时传输协议之类的传输协议，并且用于标识至少一个表决询问的信息项和/或用于标识至少一个表决响应的信息项被添加到所述表决消息。
依照本发明另一实施例，提供了一种会议表决评估部件，具有传输协议的控制协议部件，例如实时传输协议的控制协议部件，用于解码至少一个表决响应消息，所述至少一个表决响应消息依照例如实时传输协议的控制协议之类的传输协议的控制协议编码，借助于传输协议的控制协议控制例如实时传输协议之类的传输协议。此外，提供了确定部件，用于根据所解码的表决响应消息来确定对至少一个信息项的至少一个响应，所述信息项用于标识表决询问，以及提供了表决评估部件，用于使用所述至少一个信息项来确定表决结果，所述信息项标识了对至少一个表决询问的响应。
一种会议服务器部件具有如上所述的会议表决评估部件。
此外，提供了一种传输协议的控制协议部件，例如实时传输协议的控制协议部件，用于在多个通信终端之间的会议中创建表决响应消息，所述表决响应消息依照例如实时传输协议的控制协议之类的传输协议的控制协议编码，借助于传输协议的控制协议控制例如实时传输协议之类的传输协议，用于标识对至少一个表决询问的至少一个表决响应的信息项被添加到所述表决响应消息。
一种通信终端，具有会议部件，用于与至少一个其它通信终端参与会议或换句话说提供与至少一个其它通信终端之间的会议。此外，提供了第一传输协议的控制协议部件，例如实时传输协议的控制协议部件，用于解码至少一个表决消息，所述至少一个表决消息依照例如实时传输协议的控制协议之类的传输控制协议编码，借助于传输协议的控制协议控制例如实时传输协议之类的传输协议。此外，通信终端具有用于根据所解码的表决消息来确定至少一个信息项的确定部件，所述信息项用于标识表决询问和/或至少一个表决响应，以及具有显示部件，用于向用户显示所确定的信息或至少一个表决询问和/或从其所确定的至少一个表决响应。提供一输入部件，用于输入对至少一个表决询问的至少一个响应。此外，提供了第二传输协议的控制协议部件，例如第二实时传输协议的控制协议部件，用于在多个通信终端之间的会议中创建表决响应消息，所述表决响应消息依照例如实时传输协议的控制协议之类的传输协议的控制协议编码，借助于传输协议的控制协议控制例如实时传输协议之类的传输协议，用于标识至少一个表决询问的至少一个响应的信息项被添加到所述表决响应消息。
依照本发明一个实施例，在通信***中的多个通信终端之间的通信会议内提供作为通信业务的表决能力，使用例如实时传输协议的控制协议之类的传输协议的控制协议来发送信息，所述信息与表决目的相关，例如预先确定的或由参与的通信设备的用户所自由定义的表决询问和/或可能的一个或多个表决响应。
就整个数据交换性能而言，这样做就使利用传输协议的控制协议而不是专有协议产生相当大的改进成为可能。
换句话说，依照本发明一个实施例，一个或多个表决消息在通信***中被依照例如实时传输协议的控制协议之类的传输协议的控制协议而作为消息发送，所述通信***使用例如实时传输协议的控制协议之类的传输协议的控制协议。
一个表决消息可以包含一个或多个表决询问或者参与表决过程的用户可以选择的一个或多个表决响应。
表决响应消息可以包含对表决询问的一个或多个响应，例如可以由用户自由表述的响应，或者关于所选择响应的选择信息，为所述用户预先确定所述选择信息以供选择。
用于标识表决询问或表决响应的信息可以是对在另一服务器部件中所存储的表决询问或表决响应的交叉引用，在这种情况下例如通过使用唯一的资源标识符(Unique Resource Identifier URI)来向所述询问或响应提供明确的寻址，所述唯一资源标识符可以是信息或可以是表决询问或表决响应本身，其可以包括在各自的表决消息或表决响应消息中。
在从属权利要求中规定了本发明的示例性实施例。
实时传输控制协议(RTCP)可以被用作实时传输协议的控制协议。
实时传输协议(RTP)可以被用作实时传输协议。
表决可以在半双工会议期间例如在按键通话会议期间进行，在例如“直接连接”会议或经由蜂窝的按键通话的会议(PoC会议)期间进行。
作为选择，表决可以在基于因特网协议的会议期间或使用因特网会议架构来进行。
至少一个表决响应消息可以由会议服务器部件在利用计算机辅助确定至少一个表决结果期间接收，和/或至少一个表决结果可以由会议服务器部件确定。
在利用计算机辅助确定至少一个表决结果的方法的另一实施例中，规定：把所确定的至少一个表决结果发送到参与会议的至少一个通信终端(例如发起了至少一个表决的通信终端)。本发明的此实施例可以被认为是用于会议服务器部件或是用于确定表决结果以把此结果传递到一个或多个其它通信终端的其它部件，在这种情况下，可以规定：只有发起至少一个表决的通信终端有权接收所述表决结果。然而，作为选择，可以规定：向在表决过程中所涉及的所有通信终端发送表决结果。各自的权利可以由发起表决的通信终端来预先确定，或者作为选择，会议服务器部件或用于确定表决结果的部件可以预先确定这些权利。
依照用于利用计算机辅助确定至少一个表决结果的方法的另一实施例，至少一个表决响应消息由会议服务器部件接收，并且表决响应消息和/或包含至少一个表决响应消息的表决响应信息项被发送到参与会议的至少一个通信终端，例如发起了表决的通信终端。
依照用于处理表决消息的方法的一个实施例，规定：把表决响应消息发送到会议服务器部件。
实时传输协议的控制协议部件可以依照实时传输控制协议(RTCP)来设计。
在下文中将把经由蜂窝的按键通话的通信***(PoC通信***)100作为示例性实施例来描述，在这种情况下应当注意，在候选实施例中，也可以使用不同的按键通话通信***或不同的通信***，例如不同的半双工通信***，或依照IETF会议架构的通信会议***。
下文是基于以下假设：在由中央按键通话服务器部件101所生成的按键通话会议中，均包括经由蜂窝的按键通话的客户端的四个移动无线电通信终端彼此已经建立了按键通话会议。
措辞“半双工会议”意指这样的一个会议：在任一时刻至多有一个参与的通信终端而不是多个通信终端有权发言。因而，在任何给定时间只有一个通信终端例如有权发言，或一般地说有权向通信会议中引入数据并且向参与的其它通信终端发送数据。其它通信终端只可以接收所引入的数据，并且它们自己没有发言权利或通信权利，不能引入任何数据，并且特别地是也不能把任何语音消息引入到例如电信会议之类的通信会议中。
四个移动无线电通信终端102、103、104、105参与由经由蜂窝的按键通话的会议服务器部件101所提供的会议，特别地是，第一移动无线电通信设备102、第二移动无线电通信设备103、第三移动无线电通信设备104和第四移动无线电通信设备105。每个移动无线电通信终端102、103、104、105借助于各自的双向移动无线电通信链路106、107、108、109连接到会议服务器部件101，并且因而可以在会议期间从其它移动无线电通信终端接收数据，和/或当各自的移动无线电通信终端已经被分配通信权利时，它可以向其它移动无线电通信终端发送数据。
依照此本发明示例性实施例，在移动无线电通信终端102、103、104、105之间发送语音消息，或者换句话说音频消息，在这种情况下应当注意，在候选会议中也可以发送其它媒体数据，例如视频数据和/或静止图像数据和/或文本数据。
使用所谓的实时传输协议(RTP)作为实时传输协议来在移动无线电通信终端102、103、104、105之间传送音频数据。使用实时传输控制协议(RTCP)作为实时传输协议的控制协议来监视数据流，即依照此本发明示例性实施例的音频数据。
依照本发明此示例性实施例，第一订户T1即第一移动无线电通信终端102的用户，在按键通话通信会话(显然是按键通话会议)中通过发送表决询问来在订户之间发起表决(参见图2中的消息流程图200)。表决询问被***到表决消息201中，所述表决消息201由第一订户T1使用第一移动无线电通信终端102来生成。
表决消息201具有在下面表1中所图示的消息格式，并且依照RTCP编码。表决消息201包含作为文本的表决询问以及关于可能的表决响应的细节。此外，使用表决消息201来声明时间周期，在该时间周期中，将在已经开始的表决过程期间接收对表决询问的响应。
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V＝2|P|10100| PT＝APP＝204|          长度                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              表决发起者的SSRC                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                名称＝PoC1                                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   SDES CNAME项后面是SDES NAME项                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    表决询问长度   |    表决询问文本＝                       |
|      世界上最高山的名称是什么？；                           |
|          123456789；123458470；                             |
|选择类型；1；蒙大拿布朗峰；|珠穆朗玛峰；布罗肯峰填充         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
表1：用于发起表决的RTCP消息的格式
详细地，在表1中所图示的RTCP消息中的字段的意义如下：
·V＝2：
RTP版本号；
·P：
用于填充的指示符；
·10100：
消息的子类型10100意味着“Voting_Question(表决询问)”。所声明的值仅仅是示例性的值并且也可以选择不同的值；
·PT＝APP＝204：
用于应用定义的RTCP消息的指示符；
·长度：
在长度字段之后消息的长度，以字(32比特)计；
·SSRC
做出发起的PoC订户的同步源。SSCR明确地标识了媒体流的发送者，并且在与RTCP消息相关联的RTP分组中定义。
·名称＝PoC1
应用定义的消息名(PoC1＝经由蜂窝的PTT版本1)；
·SDES CNAME项后面是SDES NAME项：
发起表决的订户终端的CNAME和NAME。CNAME和NAME就是所谓的SDES项，其在SDES RTCP分组中被定义用来描述RTP订户；
CNAME是唯一订户名，其也仍然存在于特定RTP会话之外(例如包括用户名和主机IP地址)；
NAME是任何想要的订户名，典型情况下其由订户自己规定。
NAME不必唯一地标识订户；如在SDES RTCP分组的情况下，SDES项CNAME和NAME的列表由00000000类型的SDES项唯一地终止；然后所述列表用零填充直到为32比特的倍数；
·表决询问长度：
“表决询问文本”字段的长度，以字节计；“表决询问长度”字段包括16比特；
·表决询问文本：
用于规定表决发起的文本；
·填充：
零，用于把“表决询问长度和文本”字段填充到32比特的整数倍。
举例来说，表决消息201的“表决询问文本”字段具有以下内容：
世界上最高山的名称是什么？；123456789；123458470；
选择类型；1；蒙大拿布朗峰；珠穆朗玛峰；布罗肯峰
内容意指：
·表决询问＝世界上最高山的名称是什么？
·表决时间周期＝从123456789到123458470(时间细节(timedetail)是采用网络时间协议(network time protocol NTP)时间戳格式的绝对时间细节)，在这种情况下应当注意，在候选实施例中也可以使用相对时间细节，例如从发送表决消息或创建表决消息201的时间开始；
·对询问的响应类型＝选择类型(即应当选择多个可能的响应之一)；
·要选择的响应数目＝1
·可能的响应＝蒙大拿布朗峰；珠穆朗玛峰；布罗肯峰。
由第一移动无线电通信终端102依照RTCP格式借助于RTCP部件来编码表决消息201，所述RTCP部件提供在每个移动无线电通信终端102、103、104、105中。
此外，每个移动无线电通信终端102、103、104、105具有第二RTCP部件，用于解码所接收的消息，其中所述消息已经依照RTCP格式编码。可以把两个部件集成为一个RTCP部件提供。
表决消息201被发送到会议服务器部件101，所述会议服务器部件101当接收到表决消息201时，再次借助于在会议服务器部件101中提供的RTCP部件依照RTCP格式生成进一步的表决消息，并且把它们发送到参与会议的其它移动无线电通信终端103、104、105。
如图2中所图示，会议服务器部件101因而生成第二表决消息202并将其发送到第二移动无线电通信终端103，并因而发送到第二订户T2。此外，会议服务器部件101生成第三表决消息203并将其发送到第三通信终端104，即发送到第三订户T3。此外，会议服务器部件101生成第四表决消息204并将其发送到第四移动无线电通信终端105，即发送到第四订户T4。
依照本发明此示例性实施例，所生成的表决消息202、203和204与所接收的表决消息201相同。
在接收到各自的表决消息202、203或204之后，RTCP部件分别解码所接收的表决消息202、203、204，并且在每一情况下使用所解码的表决消息来确定表决询问并且借助于呈现部件向各自的订户T2、T3、T4呈现此表决询问，例如(对于视觉信息来说)借助于屏幕呈现或(对于音频信息来说)借助于扬声器呈现。
在最简单的情况下，在各自的移动无线电通信终端103、104、105的各自屏幕上以询问文本的形式向订户T2、T3、T4表明表决询问。也可以向订户T2、T3、T4展示可能的表决响应，所述表决响应同样被包括在表决消息202、203、204中并且由移动无线电通信终端103、104、105中的RTCP部件确定。依照本发明此示例性实施例，用文本来显示三个可能的响应(即“蒙大拿布朗峰”、“珠穆朗玛峰”、“布罗肯峰”)，使得能够使用所谓的“单选按钮”即借助于选择元素来选择其中一个文本，其中在每一情况下从所要选择的多个可能的元素中只可以选择唯一的一个元素。候选实施例还规定对多个可能的响应的选择，在这种情况下使用其它选择元素作选择，所述选择元素在订户各自的移动无线电通信终端103、104、105的各自屏幕上向各自的订户T2、T3、T4呈现。每个移动无线电通信终端103、104、105使用各自的表决消息202、203、204来确定仍然可以选择响应的时间，以及因而确定是否仍然可以选择任何响应。如果仍然可以选择响应，即响应时间尚未过去，那么移动无线电通信终端103、104、105在屏幕上借助于适当的图标向各自的订户T2、T3、T4表明这点，例如通过突出特定显示区域或通过突出向各自订户T2、T3、T4所显示的特定文字部分。例如，移动无线电通信终端103、104、105可以在呈现中借助于闪烁文本来向订户T2、T3、T4表明(仍然)可以对此文本作出响应。在响应阶段期间，即只要响应时间还在持续的时间内，举例来说如在上面表1的表决消息中所图示，可选地，可以向订户T2、T3、T4连续地显示仍然剩下的用于选择响应的时间。
此示例性实施例是基于这样的假设：第二订户T2借助于第二移动无线电通信终端103的适当输入来选择第二可能的响应。然后第二移动无线电通信终端103依照RTCP格式生成第一表决响应消息205并且将其发送到会议服务器部件101。
下面的表2图示了用于第一表决响应消息205的格式的一个例子：
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V＝2|P|10101|PT＝APP＝204|       长度                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              作响应的参与者的SSRC                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 名称＝PoC1                                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          SDES CNAME项后面是SDES NAME项                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    表决回答长度    |    表决回答文本＝                      |
|    选择类型；1；2  |        填充                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
表2：用于对表决询问作出响应的RTCP消息的格式
详细地，在表2中所图示的RTCP消息中的字段的意义如下：
·V＝2：
RTP版本号；
·P：
用于填充的指示符；
·10101：
消息的子类型10101意指“Voting_Answer(表决回答)”；所表明的值只是示例性的值，并且也可以选择不同的值；
·PT＝APP＝204：
用于应用定义的RTCP消息的指示符；
·长度：
在长度字段之后消息的的长度，以字(32比特)计；
·SSRC：
作响应的PoC订户的同步源；SSRC唯一地标识媒体流的发送者并且在与RTCP消息相关联的RTP分组中定义；
·名称＝PoC1：
应用定义的消息名(PoC1＝经由蜂窝的PTT版本1)；
·SDES CNAME项后面是SDES NAME项：
作响应的订户终端的CNAME和NAME；
CNAME和NAME就是所谓的SDES项，其在SDES RTCP分组中被定义用来描述RTP订户；
CNAME是唯一订户名，其也仍然存在于特定RTP会话之外(例如包括用户名和主机IP地址)；
NAME是任何想要的订户名，典型情况下其由订户自己规定。
NAME不必唯一地标识订户；如在SDES RTCP分组的情况下，SDES项CNAME和NAME的列表由00000000类型的SDES项唯一地终止；然后所述列表用零填充直到为32比特的倍数；
·表决回答长度：
“表决回答文本”字段的长度，以字节计。“表决回答长度”字段包括16比特；
·表决回答文本：
用于详细说明表决响应的文本；
·填充：
零，用于把“表决询问长度和文本”字段填充到32比特的整数倍。
依照本发明此示例性实施例，另外在不存在对一般性有任何约束的情况下假定：在短时间后，第二订户改变其对于响应选择选项并且由于他把他的响应改变为第三可能的响应，所以选择响应“布罗肯峰”。用于纠正响应的可选能力，换句话说重新选择不同的表决响应并且相应地把此信息发送到会议服务器部件101，在直到可能的响应时间过去之前都是可以的。
用于标识表决询问或表决响应的信息可以是对在另一服务器部件中所存储的表决询问或表决响应的交叉引用，在这种情况下举例来说通过使用唯一的资源标识符(Unique Resource Identifier URI)来向所述询问或响应提供明确的寻址，或者作为选择所述表决询问或表决响应自身可以包括在各自的表决消息或表决响应消息中。作为选择可以只使用表决响应消息中的唯一标识符来标识已经由订户所选择的各自的表决响应，其中在会议服务器部件中根据预先确定的分配已经知道所述唯一标识符。
在由第二订户T2选择新的响应之后，第二移动无线电通信终端102生成第二表决响应消息206并且同样把它发送到会议服务器部件101。
例如，第一表决响应消息205的“表决回答文本”字段具有以下内容：
选择类型；1；2
内容意指：
·响应类型＝选择类型(即选择已经从多个响应选项中做出了)；
·所选择响应的总数＝1；
·所选择响应的号码＝2(所述号码指的是在表决询问中即在表决消息中(即各自的表决消息201、202、203、204中的表决响应)所声明的可能响应的序列)，依照本发明此示例性实施例已经选择了表决响应“珠穆朗玛峰”。
此外，此示例性实施例是基于以下假设的，第三订户T3首先选择了第一可能的表决响应(即表决响应“蒙大拿布朗峰”)。响应于由第三订户T3所做出的选择，第三移动无线电通信终端104依照RTCP生成第三表决响应消息207，并且将此RTCP数据分组发送到会议服务器部件101。依照此示例性实施例，第三订户T3同样是不确定的，并且通过发起响应取消消息而取消了他的响应(即他先前所选的选择)，所述响应取消消息由第三移动无线电通信终端104生成以作为表决响应取消消息208，其被发送到会议服务器部件101。表决响应取消消息208同样依照RTCP来编码，并且被发送到会议服务器部件101。
下面的表3图示了表决响应取消消息208的格式布局的一个可能的例子。
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V＝2|P|10110|PT＝APP＝204|      长度                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 作响应的参与者的SSRC                        |
+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 名称＝PoC1                                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          SDES CNAME项后面是SDES NAME项                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
表3：用于取消表决响应的RTCP消息的格式
详细地，在表3中所图示的RTCP消息中的字段的意义如下：
·V＝2：
RTP版本号；
·P：
用于填充的指示符；
·10110：
消息的子类型10110意指“Voting_Answer_Delete(表决回答删除)”；所表明的值只是示例性实施例并且也可以选择不同的值；
·PT＝APP＝204：
用于应用定义的RTCP消息的指示符；
·长度：
在长度字段之后消息的长度，以字(32比特)计；
·SSRC：
正在取消其响应的PoC订户的同步源；SSRC唯一地标识媒体流的发送者并且在与RTCP消息相关联的RTP分组中定义；
·名称＝PoC1：
应用定义的消息名(PoC1＝经由蜂窝的PTT版本1)；
·SDES CNAME项后面是SDES NAME项：
正在取消其响应的订户终端的CNAME和NAME；CNAME和NAME就是所谓的SDES项，其在SDES RTCP分组中被定义用来描述RTP订户；
CNAME是唯一订户名，其也仍然存在于特定RTP会话之外(例如包括用户名和主机IP地址)；
NAME是任何想要的订户名，典型情况下其由订户自己规定。
NAME不必唯一地标识订户；如在SDES RTCP分组的情况下，SDES项CNAME和NAME的列表由00000000类型的SDES项唯一地终止；然后所述列表用零填充直到为32比特的倍数。
该示例性实施例也基于这样的假定：第三订户T3并不发送任何更进一步的表决响应消息。
也可以假定第四订户T4是不确定的，并且直到已经提供的响应周期之后才选择他的响应，继而只发起相应的第四表决响应消息209，所述第四表决响应消息209由第四移动无线电通信终端105在此时生成并且被发送到会议服务器部件101。由会议服务器部件101在所提供的响应时间内收集响应，即表决响应消息205、206、207、208、209。一旦所有响应消息已经到达会议服务器部件101，或者当响应时间周期已经过去时，会议服务器部件101组合在响应周期内已经到达的响应来形成表决消息(所述表决消息在下文中也被称作表决组合消息210)，并且然后依照RTCP将其编码并发送到发起表决的移动无线电通信终端，即发送到依照本发明的此实施例的第一移动无线电通信终端102，。
举例来说，下面的表4示出了表决组合消息210的格式的一个例子。
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V＝2|P|10101|    PT＝APP＝204|      长度                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  PTT服务器的SSRC                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   名称＝PoC1                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            SDES CNAME项后面是SDES NAME项                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          表决回答长度    |   表决回答文本＝                 |
|          选择类型；1；2  |        填充                      |
+-+-+-+.-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                                                             :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     SDES CNAME项后面是SDES NAME项                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      表决回答长度    |     表决回答文本＝                   |
|      选择类型；1；2  |     填充                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
表4：用于多个表决响应组合的RTCP消息的格式
详细地，在表4中所图示的RTCP消息中的字段的意义如下：
·V＝2：
RTP版本号；
·P：
用于填充的指示符；
·10101：
消息的子类型10101意指“Voting_Answer(表决回答)”；所表明的值只是示例性的值，并且也可以选择不同的值；
·PT＝APP＝204：
用于应用定义的RTCP消息的指示符；
·长度：
在长度字段之后消息的的长度，以字(32比特)计；
·SSRC：
发送组合消息的PTT服务器的同步源；SSRC唯一地标识媒体流的发送者并且在与RTCP消息相关联的RTP分组中定义；
·名称＝PoC1：
应用定义的消息名(PoC1＝经由蜂窝的PTT版本1)；
·SDES CNAME项后面是SDES NAME项：
作响应的订户终端的CNAME和NAME；
CNAME和NAME就是所谓的SDES项，其在SDES RTCP分组中被定义用来描述RTP订户；
CNAME是唯一订户名，其也仍然存在于特定RTP会话之外(例如包括用户名和主机IP地址)；
NAME是任何想要的订户名，典型情况下其由订户自己规定。
NAME不必唯一地标识订户；如在SDES RTCP分组的情况下，SDES项CNAME和NAME的列表由00000000类型的SDES项唯一地终止；然后所述列表用零填充直到为32比特的倍数；
·表决回答长度：
“表决回答文本”字段的长度，以字节计；“表决回答长度”字段包括16比特；
·表决回答文本：
用于详细说明表决响应的文本；
·填充：
零，用于把“表决询问长度和文本”字段填充到32比特的整数倍。
在每个订户响应中发送“SDES项”、“表决回答长度”、“表决回答文本”以及如果适当的话还有填充字段。
在表决组合消息210中忽略在所提供的响应时间周期以外到达会议服务器部件101的表决响应消息，诸如来自第四移动无线电通信终端105的第四表决响应消息209。
会议服务器部件101依照RTCP把表决组合消息210发送到第一移动无线电通信终端102并因而发送到第一订户T1，这是因为第一订户T1发起了表决。第一移动无线电通信终端102解码所接收的表决组合消息并且使用它来确定响应的组合，并因而自动评估所接收的响应并且例如使用短消息业务(Short Message Service SMS)把结果作为相应的SMS消息发送到在表决中所涉及的订户T2、T3、T4(未在图2中图示)。
在这里应当注意，表决消息还可以使用不同于在以上例子中所表明的“选择类型”的响应类型。可以提供的可能的响应类型包括：
·文本集(“选择类型”)
·从…到…的整数，
·从…到…的实数，
·任何想要的文本，
·…
表决消息总体上具有在上面表1中所图示的优选格式。在那里的例子中，“表决询问文本”字段包含文本形式的询问的细节。在下文中依照所谓的巴科斯-诺尔范式(Backus Naur Form BNF)来描述“表决询问文本”字段的一般语法。
借助于“＝”来定义元素；
“[”、“]”意指可选元素；
“*”定义重复；
“/”分隔候选元素。
表决询问＝询问文本“；”响应[“；”响应时间]
询问文本＝Text
文本＝*ALPHANUM
响应＝＝响应类型“；”响应的数目[“；”参数]
响应类型＝“选择类型”/“整数类型”/“实数类型”/“文本类型”
响应的数目＝正整数
参数＝＝(文本*(“；”文本))/限值
限值＝(整数整数)/(实数实数)
响应时间＝开始时间“；”结束时间
开始时间＝正整数
结束时间＝正整数
正整数＝1*NUM
整数＝[“+”/“-”]1*NUM
实数＝[“+”/“-”]1*NUM[“.”1*NUM]
在这种情况下“ALPHANUM”意指字母数字符号并且NUM意指数字。
在本发明的一个候选实施例中，并不声明响应时间。在这种情况下，从当前时间或按键通话通信会话的时间开始的不受限制的时间周期被假定为响应时间周期，即会议持续的时间。这在当评估要求来自所有订户的响应或者当评估时间相对于询问时间尚未固定的情况下尤为值得做。
如果不一致的时间周期被声明为响应时间周期，即例如如果开始时间出现在结束时间之后的某个时间(开始时间≥结束时间)，那么从当前时间或按键通话通信会话的时间开始的不受限制的时间周期同样被假定为响应时间周期。
在一个表决响应消息中还可以使用不同的响应类型，对应于表决询问消息中的可能响应类型。
上面表2依照本发明这些示例性实施例示出了表决响应消息的一般格式。由以下巴科斯-诺尔范式给出“表决回答”字段的一般语法：
响应＝响应类型“；”响应的数目“；”值
响应类型＝“选择类型”/“整数类型”/“实数类型”/“文本类型”
响应的数目＝正整数
值＝值*(“；”值)
值＝正整数/整数/实数/文本
正整数＝1*NUM
会议服务器部件(PTT服务器部件)101把多个订户响应组合在如表4所示的表决组合消息中。表决组合消息210被发送到表决管理者，即发送到生成了询问的订户。来自订户的响应依照它们到达会议服务器部件101的序列来在表决组合消息210中列出。这也使在响应评估中考虑所述响应的序列成为可能。例如这对于实现反应游戏来说是重要的。在本发明的一个候选实施例中，可以规定：各自的响应与时间细节相关联并且被连同表决组合消息一起发送，这表明了各自的表决响应消息到达会议服务器部件101的时间，或者由各自的移动无线电通信终端发送表决响应消息的时间。
询问也可以再次由表决管理者取消。为了做到这一点，表决管理者的移动无线电通信终端生成如下面表5中所示的消息并且将其发送到会议服务器部件101。然后会议服务器部件101把此消息分送到订户，确切地说分送到他们的移动无线电通信终端。取消表决结束了表决过程。
下面的表5依照本发明一个示例性实施例示出了表决取消消息的格式：
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V＝2|P|10111|PT＝APP＝204|          长度                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                表决发起者的SSRC                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   名称＝PoC1                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|          SDES CNAME项后面是SDES NAME项                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
表5：用于取消表决询问的RTCP消息的格式
详细地，在表5中所图示的RTCP消息中的字段的意义如下：
·V＝2：
RTP版本号；
·P：
用于填充的指示符；
·10111：
消息的子类型10111意指“Voting_Question_Delete(表决询问删除)”；所声明的值只是示例性的值并且也可以选择不同的值；
·PT＝APP＝204：
用于应用定义的RTCP消息的指示符；
·长度：
在长度字段之后消息的的长度，以字(32比特)计；
·SSRC：
取消其询问的PoC订户的同步源；SSRC唯一地标识媒体流的发送者并且在与RTCP消息相关联的RTP分组中定义；
·名称＝PoC1：
应用定义的消息名(PoC1＝经由蜂窝的PTT版本1)；
·SDES CNAME项后面是SDES NAME项：
取消其询问的订户终端的CNAME和NAME；CNAME和NAME就是所谓的SDES项，其在SDES RTCP分组中被定义用来描述RTP订户；
CNAME是唯一订户名，其也仍然存在于特定RTP会话之外(例如包括用户名和主机IP地址)；
NAME不必唯一地标识订户；如在SDES RTCP分组的情况下，SDES项CNAME和NAME的列表由00000000类型的SDES项唯一地终止；然后所述列表用零填充直到为32比特的倍数。
举例来说，当来自订户的足够大量的响应已经被传递到表决时，取消表决就可能是值得的，即便响应时间周期尚未过去并且所述订户尚未都作出响应也是如此。表决管理者可以使用如下面所进一步定义并详细描述的消息来检查中间结果以便确定已经接收了多少响应，即已经接收了多少表决响应消息。
也可以由于其它原因，例如由于询问似乎已不再是值得的或感兴趣的，而取消该询问。
可以依照两种不同的方式由发送响应的订户来再次取消已经发送的响应。首先，订户，即他的移动无线电通信终端可以再次发送表决响应消息。这使旧的响应不起作用。只有最近发送的表决响应消息一直是有效的。其次，订户，即他的移动无线电通信终端可以把在表3中所示出的消息发送到会议服务器部件101。依照这种方式，订户，即他的移动无线电通信终端取消他的响应而不必用另一响应来代替它。订户的响应状态对应于一直都没有生成任何响应的订户的响应状态。
为了获得表决结果，表决管理者-即他的移动无线电通信终端不必等到所有新的订户已经作出响应并且用于表决的响应阶段已经过去为止。实际上，表决管理者即便在表决响应期间，也可以通过把在表6中所示出的依照RTCP的消息发送到会议服务器部件101来询问与表决相关的中间结果。
下面的表6依照本发明一个示例性实施例示出了依照RTCP的中间结果询问消息的格式：
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V＝2|P|11100|PT＝APP＝204|           长度                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            请求的参与者的SSRC                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                名称＝PoC1                                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      SDES CNAME项后面是SDES NAME项                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
表6：用于取消表决询问的RTCP消息的格式
详细地，在表6中所图示的RTCP消息中的字段的意义如下：
·V＝2：
RTP版本号；
·P：
用于填充的指示符；
·11000：
消息的子类型11000意指“Voting_Answers_Question”(表决回答询问)；所表明的值只是示例性的值并且也可以选择不同的值；
·PT＝APP＝204：
用于应用定义的RTCP消息的指示符；
·长度：
在长度字段之后消息的的长度，以字(32比特)计；
·SSRC：
请求迄今被放弃的响应的PoC订户的同步源；SSRC唯一地标识媒体流的发送者并且在与RTCP消息相关联的RTP分组中定义；
·名称＝PoC1：
应用定义的消息名(PoC1＝经由蜂窝的PTT版本1)；
·SDES CNAME项后面是SDES NAME项：
请求迄今被放弃的响应的订户终端的CNAME和NAME；CNAME和NAME就是所谓的SDES项，其在SDES RTCP分组中被定义用来描述RTP订户；
CNAME是唯一订户名，其也仍然存在于特定RTP会话之外(例如包括用户名和主机IP地址)；
NAME是任何想要的订户名，典型情况下其由订户自己规定；
NAME不必唯一地标识订户；如在SDES RTCP分组的情况下，SDES项CNAME和NAME的列表由00000000类型的SDES项唯一地终止；然后所述列表用零填充直到为32比特的倍数。
当接收到中间结果询问消息时，会议服务器部件101首先检查询问订户是否被授权去询问表决的结果或中间结果。如果订户即他的移动无线电通信终端，因为例如假定在这种情况下，他是表决的发起者而被授权进行此操作，那么会议服务器部件101就用如上面在表4中所图示的表决组合消息作出响应，所述表决组合消息包含截止检查消息时为止所发出的所有响应。
对表决可能的响应的表示被留给通信终端。特别地是，除了借助于单选按钮之外，还可以借助于例如弹出菜单或借助于可自由选择的文本信息输入，来使上面例子中的选择类型响应为可选择的。
依照本发明另一实施例，在另一通信终端中而不是在订户通信终端中评估对表决的响应。作为选择，响应也可以在网络元件中评估。为此，网络元件被用作为按键通话通信会话的订户，并且网络元件向在所述按键通话通信会话中所涉及的订户发起表决并发送表决询问。
代替在上面例子中借助于表决管理者(即他的移动无线电通信终端)评估表决，借助于SMS把结果分送给订户，所述表决管理者可以把与表决相关的表决组合消息直接传递到所述订户。
作为选择，表决询问还可以作为音频数据流被呈现给订户。这可以依照下面不同的方式来执行：
1.第一，以文本形式所接收的询问可以由订户通信终端转换为音频数据，并且可以从中发出。
2.第二，音频数据流可以代替表决消息中的文本表决询问来发送，其内容表示表决询问。在这种情况下，表决消息的格式必须被适当地扩展，使得还可以发送其它数据格式，例如其它媒体数据流。表决询问还可以用其它媒体形式来呈现，例如作为图像或作为电影来呈现。
3.还可以借助于按键通话谈话串来发送表决询问。在这种情况下，如该例子所述的表决询问消息被发送，所述表决询问消息还包括以下信息：(仅仅或另外地)采用当前交谈串的形式发送表决询问。
作为选择，不仅可以规定：先前给出的响应被组合在按键通话会议服务器部件的表决组合消息中，而且还声明哪些通信会话订户至此尚未作出响应。同样可以使用上面表4中所示出的用于表决组合消息的格式来发送此消息。同样，为尚未作出响应的那些订户建立条目，确切到值：“表决回答长度”字段＝0并且“表决回答文本”字段＝空。
表决过程的管理者常常并不亲自参与表决或对其作出响应。然而，原则上，表决管理者也可以参与他自己的表决过程。在这种情况下，表决管理者的订户通信终端的表决应用在响应时间周期期间不应当产生与可用于表决管理者的先前表决响应相关的任何信息。
代替在表决询问消息中必须借助于绝对时间来指定表决过程的持续时间，还可以相对于当前时间来指定所述持续时间。作为选择，事件还可以被声明为表决的时间约束，并且例如可以通过发出来自至少n个订户的响应来定义表决过程的结束。还可以使用除NTP时间戳之外的格式来用于时间细节。
会议服务器部件101还可以在表决组合消息中发送单个订户响应的时间。为此目的，如下面表7中所示，可以扩展表决组合消息的格式：
0         1         2         3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V＝2|P|11001|PT＝APP＝204|        长度                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             作响应的参与者的SSRC                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   名称＝PoC1                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           SDES CNAME项后面是SDES NAME项                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   表决回答时间                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|表决回答长度            |      表决回答文本＝                |
|选择类型；1；2          |    填充                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
表7：用于对表决询问的响应的RTCP消息的格式，具有时间细节
详细地，在表7中所图示的RTCP消息中的字段的意义如下：
·V＝2
RTP版本号；
·P：
用于填充的指示符；
·11001：
消息的子类型11001意指：具有时间细节的“Voting_Answer(表决回答)”；所声明的值只是示例性的值并且也可以选择不同的值；
·PT＝APP＝204：
用于应用定义的RTCP消息的指示符；
·长度：
在长度字段之后消息的的长度，以字(32比特)计；
·SSRC：
作响应的PoC订户的同步源。SSCR唯一地标识了媒体流的发送者，并且在与RTCP消息相关联的RTP分组中定义；
·名称＝PoC1：
应用定义的消息名(PoC1＝经由蜂窝的PTT版本1)；
·SDES CNAME项后面是SDES NAME项：
作响应的订户终端的CNAME和NAME；
CNAME和NAME就是所谓的SDES项，其在SDES RTCP分组中被定义用来描述RTP订户；
CNAME是唯一订户名，其也仍然存在于特定RTP会话之外(例如包括用户名和主机IP地址)；
NAME是任何想要的订户名，典型情况下其由订户自己规定；
NAME不必唯一地标识订户；如在SDES RTCP分组的情况下，SDES项CNAME和NAME的列表由00000000类型的SDES项唯一地终止；然后所述列表用零填充直到为32比特的倍数；
·表决回答时间：
采用NTP时间戳格式的响应时间；
·表决回答长度：
“表决回答文本”字段的长度，以字节计；“表决回答长度”字段包括16比特；
·表决回答文本：
用于详细说明表决响应的文本；
·填充：
零，用于把“表决询问长度和文本”字段填充到32比特的整数倍。
响应时间的细节使得能够更准确地评估订户例如对于游戏的反应时间。
在按键通话通信会话内还可以同时进行多个表决过程。为了可以区分来自不同表决过程的RTCP消息，就给所述RTCP消息提供用于标识表决过程的附加字段。
下面的表8示出了表决消息格式的相应扩展：
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V＝2|P|xxxxx|PT＝APP＝204|             长度                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 SSRC                                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 名称＝PoC1                                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       SDES CNAME项后面是SDES NAME项                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              表决发起者的SSRC                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 表决ID                                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|                 附加数据                                    |
:                                                             :
|                                                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
表8：向表决消息添加表决标识符
详细地，在表8中所图示的RTCP消息中的字段的意义如下：
·V＝2：
RTP版本号；
·P：
用于填充的指示符；
·XXXXX：
消息的子类型，其值取决于表决消息；
·PT＝APP＝204：
用于应用定义的RTCP消息的指示符；
·长度：
在长度字段之后消息的的长度，以字(32比特)计；
·SSRC：
发送者(订户终端或PTT服务器)的同步源；SSRC唯一地标识媒体流的发送者并且在与RTCP消息相关联的RTP分组中定义；
·名称＝PoC1：
应用定义的消息名(PoC1＝经由蜂窝的PTT版本1)；
·SDES CNAME项后面是SDES NAME项：
发送者(订户终端或PTT服务器)的CNAME和NAME；CNAME和NAME就是所谓的SDES项，其在SDES RTCP分组中被定义用来描述RTP订户；
CNAME是唯一订户名，其也仍然存在于特定RTP会话之外(例如包括用户名和主机IP地址)；
NAME是任何想要的订户名，典型情况下其由订户自己规定；
NAME不必唯一地标识订户；如在SDES RTCP分组的情况下，SDES项CNAME和NAME的列表由00000000类型的SDES项唯一地终止；然后所述列表用零填充直到为32比特的倍数；
·表决发起者的SSRC：
发起了表决的订户的SSRC；
·表决ID：
在发起订户的表决过程中的表决的唯一标识的号码；
·附加数据：
·用于表决消息的进一步信息；所述信息取决于消息的子类型并且对应于在上面所定义的表决消息(没有表决标识符)中所声明的附加信息。
表决过程的标识包括各自的表决发起者的SSRC和附加表决号码。如果一个订户在表决询问中第二次使用已经进行的表决过程的表决号码，那么两个表决过程中的第一个结束，并且第二个开始进行。
作为选择，对选择询问的响应也可以采用文本形式。于是，对应于以上例子的“表决回答文本”字段读作：文本类型；1；珠穆朗玛峰。
除上述其它响应类型之外的进一步响应类型也可以被定义为可能的响应，例如对谈话消息的接收。
除文本之外，其他媒体也可以被用作可能的响应，例如图像或谈话消息。
RTCP表决询问消息或RTCP表决响应中的“表决询问文本”字段和“表决回答文本”字段还可以依照除上面例子所述之外的方式来格式化。
在本发明的一个候选实施例中，设想在按键通话通信***中不仅发送音频数据而且在按键通话通信***中发送其它数据，尤其是发送其它媒体数据。
此外，作为选择，例如会议***之类的通信***并未被设计为按键通话通信***，而是被设计为使用RTCP(通常是实时传输协议的控制协议)的、不同会议***，尤其被设计为具有依照IETF的会议***的通信***。
此外，可以使用借助于RTCP的表决过程来约定接下来应当向哪个订户给予谈话权利(底层控制)。为此目的，采用机器形式的订户，作为表决管理者，参与通信。此订户发起表决，该表决关于接下来应当向哪个订户分配谈话权利，继而此订户评估所给出的响应。机器订户应当被授权能够分配谈话权利，即换句话说，此订户具有所谓的“底层席位(floor chair)”功能。机器订户根据评估结果来分配谈话权利。
本发明的一个方面是在使用实时控制协议(RTCP)的通信***中把表决消息作为特定RTCP数据分组发送。
基于因特网协议的通信***(诸如按键通话通信***或基于网际协议(IP)的会议***)通常使用实时传输协议(RTP)来发送媒体数据。借助于RTCP来监视RTP通信链路。依照本发明的一个方面，RTCP通信链路用来发送用于表决功能的特定RTCP消息。
依照本发明的另一方面，定义特定RTCP消息以便发送表决询问、表决响应并且取消表决询问和表决响应。
定义特定表决消息的一个优点在于：可以由机器来评估表决。如果并未定义可以选择的可能响应，那么可以规定估算部件包含分析器部件，所述分析器部件自动分析采用明文形式给出的响应，并且从其确定表决结果。
表决消息具有简单的格式并且是基于文本的，其优点在于所述消息易读且短。
通信***中的中央会议服务器部件把表决响应组合在RTCP消息中。会议服务器部件通过发送表决组合消息来向表决管理者通知表决结果。此优点在于会议服务器部件只需要发送一个消息来向表决管理者通知表决结果。由于表决结果被集中收集并存储，所以有益地是，还可以由询问订户通信终端来检查表决(中间)结果。
表决结果可以由订户通信终端或由通信网络中的元件来评估。此优点在于表决通信***的体系结构可以被定义为灵活的。

Claims (34)

1.一种在多个通信终端之间的会议中利用计算机辅助创建表决消息的方法，包括：
依照传输协议的控制协议来编码所述表决消息，借助于传输协议的控制协议控制传输协议，用于标识至少一个表决询问的信息项或用于标识至少一个表决响应的信息项被添加到所述表决消息。
2.一种在多个通信终端之间的会议中利用计算机辅助确定至少一个表决的至少一个表决结果的方法，包括：
解码至少一个接收的表决响应消息，所述表决响应消息依照传输协议的控制协议编码，借助于传输协议的控制协议控制传输协议，所述表决响应消息包括用于表决的至少一个表决询问的至少一个响应，
根据所解码的表决响应消息来确定所述至少一个响应，并且
使用所述至少一个响应来确定至少一个表决结果。
3.如权利要求1所述的方法，包括：
使用实时传输协议的控制协议作为所述传输协议的控制协议，借助于实时传输协议的控制协议控制实时传输协议。
4.如权利要求3所述的方法，包括：
使用实时传输控制协议作为所述实时传输协议的控制协议。
5.如权利要求3所述的方法，包括：
使用实时传输协议作为所述实时传输协议。
6.如权利要求1所述的方法，包括：
在半双工会议中进行所述至少一个表决。
7.如权利要求6所述的方法，包括：
在按键通话会议中进行所述至少一个表决。
8.如权利要求7所述的方法，
在经由蜂窝的按键通话的会议中进行所述至少一个表决。
9.如权利要求1所述的方法，包括：
在基于因特网协议的会议中进行所述至少一个表决。
10.如权利要求2所述的方法，包括：
由会议服务器部件接收所述至少一个表决响应消息，或
由会议服务器部件确定所述至少一个表决结果。
11.如权利要求2所述的方法，包括：
把所确定的至少一个表决结果发送到参与所述会议的至少一个通信终端。
12.如权利要求11所述的方法，包括：
把所确定的至少一个表决结果发送到发起了所述至少一个表决的通信终端。
13.如权利要求2所述的方法，包括：
由会议服务器部件接收所述至少一个表决响应消息，并且
把所述表决响应消息或在所述表决响应消息中所包含的至少一个表决响应信息项发送到参与所述会议的至少一个通信终端。
14.如权利要求13所述的方法，包括：
把所确定的表决响应消息或在所述表决响应消息中所包含的至少一个表决响应信息项发送到发起了所述表决的通信终端。
15.一种用于在多个通信终端之间的会议中利用计算机辅助处理表决消息的方法，包括：
接收依照传输协议的控制协议编码的表决消息，借助于传输协议的控制协议控制传输协议，
根据所述表决消息来确定用于标识至少一个表决询问的信息项或用于标识在所述表决消息中所包含的至少一个表决响应的信息项，
向参与所述表决的通信终端的用户显示至少一个表决询问或至少一个表决响应，并且
用户输入对所述至少一个表决询问的至少一个响应，
依照传输协议的控制协议来编码表决响应消息，借助于传输协议的控制协议控制传输协议，用于标识对所述至少一个表决询问的至少一个响应的信息项被添加到所述表决响应消息。
16.如权利要求15所述的方法，包括：
使用实时传输协议的控制协议作为所述传输协议的控制协议，借助于实时传输协议的控制协议控制实时传输协议。
17.如权利要求15所述的方法，包括：
把所述表决响应消息发送到会议服务器部件。
18.如权利要求16所述的方法，包括：
使用实时传输控制协议作为所述实时传输协议的控制协议。
19.如权利要求16所述的方法，包括：
使用实时传输协议作为所述实时传输协议。
20.如权利要求15所述的方法，包括：
在半双工会议中进行所述至少一个表决。
21.如权利要求20所述的方法，包括：
在按键通话会议中进行所述至少一个表决。
22.如权利要求21所述的方法，包括：
在经由蜂窝的按键通话的会议中进行所述至少一个表决。
23.如权利要求15所述的方法，
在基于因特网协议的会议中进行所述至少一个表决。
24.一种在多个通信终端之间的会议中创建表决消息的传输协议的控制协议部件，所述表决消息被依照传输协议的控制协议来编码，借助于传输协议的控制协议控制传输协议，并且用于标识至少一个表决询问的信息项或用于标识至少一个表决响应的信息项被添加到所述表决消息。
25.如权利要求24所述的传输协议的控制协议部件，
是用于在多个通信终端之间的会议中创建表决消息的实时传输协议的控制协议部件，所述表决消息被依照实时传输协议的控制协议来编码，借助于实时传输协议的控制协议控制实时传输协议。
26.如权利要求25所述的传输协议的控制协议部件，
其被依照所述实时传输控制协议来设计。
27.一种会议表决评估部件，
具有传输协议的控制协议部件，用于解码依照传输协议的控制协议编码的至少一个表决响应消息，借助于传输协议的控制协议控制传输协议，
具有确定部件，用于根据所解码的表决响应消息来确定用于标识对至少一个表决询问的响应的至少一个信息项，
具有表决评估部件，使用用于标识对至少一个表决询问的响应的至少一个信息项确定表决结果。
28.如权利要求27所述的会议表决评估部件，
所述传输协议的控制协议部件是实时传输协议的控制协议部件。
29.如权利要求28所述的会议表决评估部件，
所述实时传输协议的控制协议部件被依照所述实时传输控制协议来设计。
30.一种具有如权利要求27所述的会议表决评估部件的会议服务器部件。
31.一种在多个通信终端之间的会议中创建表决响应消息的传输协议的控制协议部件，所述表决响应消息被依照传输协议的控制协议来编码，借助于传输协议的控制协议控制传输协议，用于标识对至少一个表决询问的至少一个表决响应的信息项被添加到所述表决响应消息。
32.如权利要求31所述的传输协议的控制协议部件，
是用于在多个通信终端之间的会议中创建表决响应消息的实时传输协议的控制协议部件，所述表决消息被依照实时传输协议的控制协议来编码，借助于实时传输协议的控制协议控制实时传输协议。
33.如权利要求31所述的传输协议的控制协议部件，
其被依照所述实时传输控制协议来设计。
34.一种通信终端，
具有用于与至少一个其它通信终端之间产生会议的会议部件，
具有第一传输协议的控制协议部件，用于解码依照传输协议的控制协议编码的至少一个表决消息，借助于传输协议的控制协议控制传输协议，
具有确定部件，用于根据所解码的表决消息来确定用于标识表决询问的至少一个信息项或用于标识表决响应的至少一个信息项，
具有显示部件，用于向用户显示所确定的信息项、或从其确定的至少一个表决询问、或至少一个表决响应，
具有输入部件，用于输入对所述至少一个表决询问的至少一个响应，
具有用于在多个通信终端之间的会议中创建表决响应消息的第二传输协议的控制协议部件，所述表决响应消息被依照传输协议的控制协议来编码，借助于传输协议的控制协议控制传输协议，并且用于标识对所述至少一个表决询问的至少一个响应的信息项被添加到所述表决响应消息。
CN200610121442.7A 2005-08-22 2006-08-22 表决消息创建、处理、及结果确定方法和控制协议、表决评估、会议服务器部件和通信终端 Expired - Fee Related CN1925410B (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102005039669A DE102005039669B3 (de) 2005-08-22 2005-08-22 Verfahren zum rechnergestützten Erstellen einer Abstimmungs-Nachricht, Verfahren zum rechnergestützten Ermitteln mindestens eines Abstimmungs-Ergebnisses, Verfahren zum rechnergestützten Bearbeiten einer Abstimmungs-Nachricht, Transportprotokoll-Steuerungsprotokoll-Einheit, Konferenz-Abstimmungs-Auswerte-Einheit, Konferenz-Servereinheit und Kommunikations-Endgerät
DE102005039669.0 2005-08-22

Publications (2)

Publication Number Publication Date
CN1925410A true CN1925410A (zh) 2007-03-07
CN1925410B CN1925410B (zh) 2010-08-18

Family

ID=37006430

Family Applications (1)

Application Number Title Priority Date Filing Date
CN200610121442.7A Expired - Fee Related CN1925410B (zh) 2005-08-22 2006-08-22 表决消息创建、处理、及结果确定方法和控制协议、表决评估、会议服务器部件和通信终端

Country Status (5)

Country Link
US (1) US20070058796A1 (zh)
CN (1) CN1925410B (zh)
DE (1) DE102005039669B3 (zh)
FR (1) FR2889900A1 (zh)
GB (1) GB2429614C (zh)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1959378B1 (en) * 2007-02-14 2014-08-27 Software AG Collaboration application and method
US8478819B1 (en) * 2007-09-25 2013-07-02 Avaya Inc. Automatically initiating a process by the outcome of a voting conference
US8038061B2 (en) * 2007-10-01 2011-10-18 Samsung Electronics Co., Ltd. Voting by peers with limited resources
US8155632B2 (en) * 2009-06-17 2012-04-10 At&T Mobility Ii Llc Systems and methods for voting in a teleconference using a mobile device
US10904732B1 (en) * 2020-01-29 2021-01-26 Motorola Solutions, Inc. Method for real-time voting within a push to talk for the Internet of Things system

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB9215662D0 (en) * 1992-07-23 1992-09-09 Workspace Technologies Limited Conference assisting apparatus
JPH08234976A (ja) * 1995-02-23 1996-09-13 Sony Corp プログラム機能拡張方法、およびデータ処理方法
GB2425692B (en) * 2002-08-15 2007-03-21 Iml Ltd A participant response system and method
CN1189052C (zh) * 2002-09-03 2005-02-09 广州市正创科技有限公司 基于移动通信网的调查***及方法
US7130403B2 (en) * 2002-12-11 2006-10-31 Siemens Communications, Inc. System and method for enhanced multimedia conference collaboration
US7586938B2 (en) * 2003-10-24 2009-09-08 Microsoft Corporation Methods and systems for self-describing multicasting of multimedia presentations
FI20041205A0 (fi) * 2004-09-16 2004-09-16 Nokia Corp Konferenssiviestinnän hallinta viestintäjärjestelmässä
DE102004049907A1 (de) * 2004-10-13 2006-04-20 Infineon Technologies Ag Verfahren zum Anfordern oder Zuteilen eines Push-to-talk-Sprachrechts und/oder zum Erfragen oder Mitteilen von Warteschlangeninformation, Push-to-talk-Client-Einheit, Push-to-talk-Steuerserverrechner und Entscheidungseinheit
US20060156330A1 (en) * 2005-01-07 2006-07-13 Fu-Sheng Chiu Intelligent interactive multimedia
KR101158573B1 (ko) * 2005-03-22 2012-06-22 삼성전자주식회사 푸쉬투토크 오버 셀룰러 망의 클라이언트 의견 수렴 방법및 그 시스템

Also Published As

Publication number Publication date
GB2429614C (en) 2008-07-02
US20070058796A1 (en) 2007-03-15
DE102005039669B3 (de) 2007-01-04
GB0615118D0 (en) 2006-09-06
GB2429614B (en) 2007-12-05
FR2889900A1 (fr) 2007-02-23
CN1925410B (zh) 2010-08-18
GB2429614A (en) 2007-02-28

Similar Documents

Publication Publication Date Title
CN1819671A (zh) 关于按键通话发言权和队列信息的方法及其相关装置
CN1801970A (zh) 自动产生和/或控制有多个参加者的电信会议的方法及设备
CN1794705A (zh) 即时消息用户使用其它即时消息***聊天室的方法及***
CN1220359C (zh) 通信终端、服务器、广播通信***及方法
CN1770805A (zh) 计算机辅助管理电话会议的方法以及电话会议服务器装置
CN1263302C (zh) 远程会议***和远程会议支持方法
CN1565105A (zh) 手持无线会议技术
CN1655553A (zh) 便于第三方呼叫和设备控制的***和方法
CN1934825A (zh) 通过通信协议传送广播/多播会话的参数
CN1507725A (zh) 因特网通信***、因特网通信方法、对话管理服务器、通信适配器、通信中继服务器及程序
CN1615646A (zh) 通信装置
CN1801814A (zh) 一种离线消息发送和接收方法
CN1193440A (zh) 图象数据发送方法和装置及图象数据再生装置
CN1656482A (zh) 在使用用户档案web门户的电信网中用于服务和应用个性化的方法和装置
CN1832414A (zh) 提供多个群组通信业务的方法、群组通信业务***及群组通信业务服务器单元
CN1914922A (zh) 内容的编码、分发及接收的方法、装置、***以及程序
CN1490733A (zh) 服务提供方法
CN1650561A (zh) 音频数据编码转换发送方法以及编码转换接收方法、设备、***和程序
CN1843050A (zh) 无线通信网络中资源预留的方法和***
CN1893352A (zh) 一种因特网协议多媒体子***的鉴权方法
CN1930838A (zh) 信息处理装置、服务器、通信***、地址决定方法、地址变更方法及程序
CN1925410A (zh) 表决消息创建、处理、及结果确定方法和控制协议、表决评估、会议服务器部件和通信终端
CN1507202A (zh) 设备管理***、设备管理终端、网络设备、终端程序、设备程序以及设备管理方法
CN1754385A (zh) 图像数据发布控制方法及装置、***以及程序
CN1848881A (zh) 通信过程中处理主叫号码显示的实现方法及装置

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant
ASS Succession or assignment of patent right

Owner name: INTEL MOBILE COMMUNICATIONS TECHNOLOGY LTD.

Free format text: FORMER OWNER: INFINEON TECHNOLOGIES AG

Effective date: 20120611

Owner name: INTEL MOBILE COMMUNICATIONS LTD.

Free format text: FORMER OWNER: INTEL MOBILE COMMUNICATIONS TECHNOLOGY LTD.

Effective date: 20120611

C41 Transfer of patent application or patent right or utility model
C56 Change in the name or address of the patentee
CP03 Change of name, title or address

Address after: Neubiberg, Germany

Patentee after: Infineon Technologies AG

Address before: Munich, Germany

Patentee before: Infineon Technologies AG

TR01 Transfer of patent right

Effective date of registration: 20120611

Address after: Neubiberg, Germany

Patentee after: Intel Mobile Communications GmbH

Address before: Neubiberg, Germany

Patentee before: Infineon Technologies AG

Effective date of registration: 20120611

Address after: Neubiberg, Germany

Patentee after: Intel Mobile Communications GmbH

Address before: Neubiberg, Germany

Patentee before: Intel Mobile Communications GmbH

C17 Cessation of patent right
CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20100818

Termination date: 20130822