CN1228982C - 视频点播***的信道合并方法和装置 - Google Patents

视频点播***的信道合并方法和装置 Download PDF

Info

Publication number
CN1228982C
CN1228982C CNB021540063A CN02154006A CN1228982C CN 1228982 C CN1228982 C CN 1228982C CN B021540063 A CNB021540063 A CN B021540063A CN 02154006 A CN02154006 A CN 02154006A CN 1228982 C CN1228982 C CN 1228982C
Authority
CN
China
Prior art keywords
channel
client
subchannel
request
combining
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.)
Expired - Fee Related
Application number
CNB021540063A
Other languages
English (en)
Other versions
CN1505401A (zh
Inventor
裴云彰
邵凌
谢东
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.)
Google LLC
Original Assignee
International Business Machines Corp
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 International Business Machines Corp filed Critical International Business Machines Corp
Priority to CNB021540063A priority Critical patent/CN1228982C/zh
Priority to TW092131521A priority patent/TWI280801B/zh
Priority to JP2004556477A priority patent/JP4475521B2/ja
Priority to EP03812215A priority patent/EP1568228A2/en
Priority to CA2508074A priority patent/CA2508074C/en
Priority to BR0316388-1A priority patent/BR0316388A/pt
Priority to AU2003302537A priority patent/AU2003302537B2/en
Priority to PCT/GB2003/005123 priority patent/WO2004052008A2/en
Priority to KR1020057009168A priority patent/KR100745531B1/ko
Priority to US10/726,835 priority patent/US7373653B2/en
Publication of CN1505401A publication Critical patent/CN1505401A/zh
Application granted granted Critical
Publication of CN1228982C publication Critical patent/CN1228982C/zh
Priority to US11/924,324 priority patent/US7673318B2/en
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/26616—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel for merging a unicast channel into a multicast channel, e.g. in a VOD application, when a client served by unicast channel catches up a multicast channel to save bandwidth
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
    • H04N21/2408—Monitoring of the upstream path of the transmission network, e.g. client requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H04N21/47202—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for requesting content on demand, e.g. video on demand
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
    • H04N7/17309—Transmission or handling of upstream communications
    • H04N7/17336—Handling of requests in head-ends

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Human Computer Interaction (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Testing, Inspecting, Measuring Of Stereoscopic Televisions And Televisions (AREA)

Abstract

一种用于视频点播***的信道合并方法，其特征在于所述方法包括步骤：响应于多个客户端对某一视频节目的请求，建立一根信道(S1)和至少一子信道(S11)，所述根信道(S1)根据最早发出请求的客户端的请求而建立，所述多个子信道(S11)中的每一个对应于一较晚发出请求的客户端的请求而建立；和对于所建立的每一个信道，监测使用该信道的客户端的数目变化，如果使用被监测信道的客户端数目不为零，则维持该信道，如果使用被监测信道的客户端数目为零，则关闭该信道。

Description

视频点播***的信道合并方法和装置
技术领域
本发明一般地涉及信道合并方法和装置，更具体地涉及在通信网络中利用传送视频流的多个信道的合并向多个客户端进行优化的组播(multicast)传送。
背景技术
随着互联网使用的***性增长和计算机能力的不断增加，人们对所谓的视频点播(video-on-demand)的应用的兴趣也极大地增长了，其中客户可以在任意时间请求媒体文件(视频、音频、数据等)，用于即时观看或将来观看。但是，视频点播也提出了新的挑战，即服务器带宽和网络带宽的巨大消耗。一般地，每个请求都由一个专用的单播(unicast)流来支持，并且基于单播的视频点播***的开销非常庞大。信道合并技术的出现为视频点播服务创造了一个全新的模式，其目标就是通过使客户端同时接收两个或更多的视频流来减少满足请求特定视频对象的各客户端所需要的服务器带宽。当客户端为了立即观看的目的而接收数据并且同时进行存储时，服务器可以通过组播的方式使一个视频对象服务于多个用户，并因此既减少了网络带宽，又减少了服务器带宽。
现有的信道合并方法可以分为三类：静态广播方法、合并树结构方法、和事件驱动(event driven)方法。由摩天楼(Skyscraper)代表的静态广播方法用指定的时段和长度、在几个信道中广播多段被请求的对象。静态广播的优点是在非常繁忙的环境中具有其简易性和相对高的效率。但是，当***的负载不高，或由于其不灵活的资源分配而使不同视频节目的普及度较分散时，静态广播的性能很差。对于由Dyadic代表的合并树结构方法，当有新的用户加入时，该合并树结构用表示信道的树节点动态地构建合并树，在用户真正需要信道之前不实际分配信道。这种方法通过消除闲置信道资源的浪费而克服了静态广播的缺陷。但是，当合并树仅由新用户的加入时间来确定时，它就不直接支持诸如VCR(盒带录象机)功能，即任意停止、暂停、快进/倒退等。对于由SRMT(Simple Reachable Merge Target，简单可到达合并目标)和CT(Closest Target，最近目标)代表的事件驱动方法，当客户向服务器表示要进行播放、停止、跳转或合并操作时，该方法动态地确定一组该客户应该使用的信道。因为每个客户的合并路径根据用户的交互作用而得到动态地调整，所以该方法可以支持VCR功能。
下面将结合图1、图2和图3对两个信道进行合并的方法说明如下：
第一步，视频服务器1从客户端A接收播放视频的请求，并根据该请求，用信道S6向客户端4发送被请求的视频节目。
第二步，当在一段时间(T)后从客户端B接收与所述客户端A相同的视频点播请求时，该视频服务器1建立信道S11，并通知客户端B准备在信道S11和信道S6两个信道上从该视频服务器1接收该视频节目。
第三步，该视频服务器1利用信道S11从该视频节目的开始点(a)向客户端B发送该视频节目，并且客户端B进行接收，同时客户端B在信道S6上与客户端A同步接收并存储从该视频服务器1继续发送的随后所述视频节目。
第四步，视频服务器1将信道S6作为信道S11的父信道(即信道S11将要并入的信道)，当客户端B在信道S11上接收的视频节目达到其在信道S6上接收并存储的视频节目的起始点(b)时，即又经过了时间T时，将信道S11并入信道S6，并且该视频服务器1将关闭信道S11，并停止在信道S11上向客户端B发送该视频节目。此时，客户端B中已经存储了从点(b)到点(c)的视频节目。该信道S11(子视频流)与其父信道S6合并后，如果没有其它的客户端正在使用子信道S11(即正在使用信道S11的子信道)，那么这个子信道S11将被停止。
第五步，在将信道S11并入信道S6后，客户端B在用所述信道S6继续从点(c)接收并存储从视频服务器1发送的随后所述视频节目的同时，以先进先出的方式从点(b)读取并播放已经存储在其本地存储器中的该视频节目，使得该视频节目在客户端B上的播放能够连续进行。
尽管用于信道合并的事件驱动方法是控制组播信道的最灵活的方法，但是这种类型的现有方法却存在明显的缺点：如果在上述第四步，一个信道当与其父信道合并而被删除或由于停止或跳转事件而被取消，则那些正在使用这个被删除的信道的子信道的客户不得不改变它们正在使用的信道。例如，CT方案简单地选择仍在***中的较早视频流中的最近时间的视频流信道作为下一个合并目标，而即使没有新的子信道被建立，CT计算的该合并目标也不一定是可到达的，原因是该目标流信道本身在被其后续信道追上以前可能已经与该目标信道的目标信道进行了合并。当这种情况发生时，后续流信道必须再次使用CT算法选择一个新的合并目标。另外，目标流信道的任意停止、暂停、快进/后退等操作都可能使后续流信道的合并不能发生，并迫使它们重新选择新的父信道。
为了将合并树的改变通知给受到影响的客户，视频服务器必须主动地向这些客户中的每一个发送通知。这可能导致以下几种负面影象：
1.由于通知的数量与受到影响的客户端的数量和未预料到的信道停止事件的频率成正比，从视频服务器到客户端的反向通知大大地增加了视频服务器的负载。
2.客户必须准备接收来自于互联网的未知区域的进入连接，而这增加了客户端受其它意外影响的可能性。
3.该反向通知可能不能通过具有一定配置的防火墙。例如，如果防火墙内的客户试图观看存储于该防火墙外的视频服务器中的一段视频片段，则该服务器永远都不会向客户端传送通知。
发明内容
为了解决上述问题，通过使用响应于开始、跳转、合并和停止事件而决定合并路径的准则，本发明提供一种视频点播***中的信道合并方法，所述方法包括步骤：(1)响应于多个客户对某一视频节目的请求，建立一根信道(S1)和至少一个子信道(S11)，所述根信道(S1)根据最早发出请求的客户机的请求而建立，所述多个子信道(S11)中的每个对应于一较晚发出请求的客户机的请求而建立；以及(2)对于所建立的每一个信道，监测使用该信道的客户机的数目变化，如果使用被监测信道的客户机数目不为零，则维持该信道，如果使用被监测信道的客户机数目为零，则关闭该信道，其中所有信道合并事件都是从最次级子信道向根信道的方向进行的，并且所述根信道与多个子信道形成树结构。
本发明还提供一种用于视频点播***的信道合并装置，所述信道合并装置配置于所述视频点播***中的视频服务器中或与其可操作地连接，其中所述信道合并装置包括：信道选择单元，用于响应多个客户端对某一视频节目的请求，建立一根信道(S1)和至少一子信道(S11)，所述根信道(S1)根据最早发出请求的客户端的请求而建立，所述多个子信道(S11)中的每一个对应于一较晚发出请求的客户端的请求而建立；信道控制单元，用于对所建立的每一个信道，监测使用该信道的客户端的数目变化，如果使用被监测信道的客户端数目不为零，则维持该信道，如果使用被监测信道的客户端数目为零，则关闭该信道。
在本发明中，所有的信道“合并事件”都是从最次级子信道向根信道的方向进行的，因此不会发生客户端正在使用的信道被移除的情况。即使直接发生停止事件，在使用某个信道的所有客户端(以该信道的子信道的方式)明确地释放该信道之前，该信道也不会被移除。所以避免了反向通知，从而一个客户端的行为不会影响其它的客户端，并减小了视频服务器和网络的负载。同时，因为当客户端触发的事件发生时动态地构建和调整合并树，而每个客户端的合并路径是基于合并树而进行动态调整的，所以这种方法固有地支持诸如播放、停止、搜索(快进/后退)等的VCR功能。
本发明的另一个主要优点是控制视频服务器的方法与HTTP(超文本传输协议)的请求/响应模式兼容，因此可以容易地在HTTP上实现。HTTP是在互联网上交换应用数据的主流协议，并且网络服务的出现进一步强化了基于互联网的应用在数据传输方面应该尽可能依赖HTTP的趋势。另外，大多数防火墙在允许一般数据流量的通过方面是难于处理的，而不是HTTP。
附图说明
通过结合附图对本发明进行的详细描述，将使本发明的上述优点和其它特点变得更加清楚。
图1是示出具有视频服务器和多个客户端的组播网络。
图2是示出进行信道合并的视频节目流的示意图。
图3是示出信道合并树的示意图。
图4是在图1的视频服务器和客户端之间发生的请求/应答的时序图。
图5是根据本发明配置于视频服务器中的信道合并装置的结构图。
图6是根据本发明发生“开始事件”时视频服务器的处理的流程图。
图7是根据本发明发生“跳转事件”时视频服务器的处理的流程图。
图8是根据本发明发生“合并事件”时视频服务器的处理的流程图。
图9是根据本发明发生“停止事件”时视频服务器的处理的流程图。
具体实施方式
下面将结合附图对本发明进行详细地描述。
除非特别说明，在本说明书的下文中涉及到的开始、停止、跳转、和合并等操作均是对于播放相同视频节目(对象)的各个信道进行的。
图1是具有服务器1和多个客户端4的组播网络。该组播网络包括视频服务器1、互联网2、防火墙3和多个客户端4，其中视频服务器1与客户端4通过互联网2和防火墙3进行通信。在本发明中，客户端4通过防火墙3和互联网2向视频服务器1发出请求，请求对某段视频节目进行播放、停止、暂停、快进/后退等诸如VCR功能的操作。
下面参考图4说明图1中的视频服务器1和客户端4之间所发生的请求/应答操作。
图4是在视频服务器1和客户端4之间发生的请求/应答的时序图。
在图4中，每个消息都包含要执行的动作的消息类型，该消息类型由一列参数来指定。这里定义了五种消息类型：打开(OPEN)、播放(PLAY)、暂停(PAUSE)、合并(MERGE)、和关闭(CLOSE)。对于由客户端发送的每个消息，服务器都会发送回应答(RESPONSE)消息。
在步骤(1)中，通过发送OPEN消息给视频服务器1，客户端4与视频服务器1建立一个会话，该OPEN消息包含唯一识别视频服务器1上所请求的视频文件(视频节目)的视频标识(Video ID)。如果成功地建立了该会话，则视频服务器1将会发送回包含信道信息的RESPONSE给客户端4，该信道信息例如是组播地址和端口号，客户机4可以根据该信道信息接收所请求的视频节目。
在步骤(2)中，客户端4发送一个PLAY消息，以请求开始播放该视频节目，或从暂停状态进行恢复，在该PLAY消息中可以指定一个偏移参数，以搜索该视频节目的指定位置。在该RESPONSE消息中可以包含给客户端4的附加信息，如指示客户机4接收所请求的节目等的信息。
在步骤(3)中，当客户端4检测到发生了信道合并时，发送MERGE消息给视频服务器1(当然，视频服务器1也可以通过自己的诸如信道控制单元20的部件对信道进行计算而得出信道合并事件的发生)。该视频服务器1将关闭不再使用的信道，并发送回指示客户端4应加入的附加信道。
在步骤(4)中，客户端4可以发送PAUSE消息给视频服务器1，以在播放视频节目时暂时停止数据传输，并且视频服务器1进行相应的响应。
在步骤(5)中，客户端4可以发送CLOSE消息给视频服务器1，以关闭与视频服务器1的会话，并且视频服务器1进行相应的响应。
如果我们将上述所有的请求和通知消息都模型化为各个事件，则在视频服务器1中共有四种事件：即“开始事件”、“跳转事件”、“停止事件”、和“合并事件”。这些事件都可以通过上述五种消息类型，即打开(OPEN)、播放(PLAY)、暂停(PAUSE)、合并(MERGE)、和关闭(CLOSE)进行操作。
当客户端4发送关于对象(视频节目)的请求时发生“开始事件”，即客户端4在时刻t请求播放一段视频节目(用PLAY消息)；当客户端4发送关于对象的快进或后退请求时发生“跳转事件”，当发生“跳转事件”时，相当于客户端4向视频服务器1发送了从时刻t+s或t-s播放该视频节目的请求，其中s是跳转的对象(即所请求的视频节目其它部分)相对于在时刻t的偏移时间)，这时，视频服务器1建立一个新的信道以从时刻t-s播放该视频节目(用PLAY消息)，同时关闭从时刻t开始播放该视频节目的信道(用CLOSE消息，对此操作将在下文中进行详细的说明)；当客户端4不再需要一个对象时发生“停止事件”，即关闭发送该视频节目的信道(用CLOSE消息)；当客户端4到达该客户端4正在收看的最后信道对(channel pair)已经成功合并的合并点时，发生“合并事件”(用MERGE消息和CLOSE消息)，如在本发明背景技术中所述的合并方法中所述的情况，即图2中的启始点(b)为该合并点。
为了实现上述对某段视频节目进行播放、停止、暂停、快进/后退等诸如VCR功能的操作，本发明提供了信道合并装置40。
下面结合图5说明根据本发明的信道合并装置40的具体结构。
图5是根据本发明的信道合并装置40的结构图。
本发明的信道合并装置40配置于视频服务器1的内部，包括：信道选择单元10，用于接收多个客户端对某一视频节目的请求，并响应该请求建立一根信道(S1)和至少一子信道(S11)，所述根信道(S1)根据最早发出请求的客户端的请求而建立，所述多个子信道(S11)中的每一个对应于一较晚发出请求的客户端的请求而建立，并且该信道选择单元10还在信道合并过程中为一子信道寻找满足后面将描述的条件表达式(1)和(2)的父信道；和信道控制单元20，用于根据客户端4的请求和信道选择单元10的选择结果等执行信道的建立、合并和关闭等操作。
另外，上述信道合并装置40可以与视频服务器1可操作地连接在一起，而不必要配置在视频服务器1的内部。同时，信道选择单元10和信道控制单元20还可以是同一个单元，例如可以是计算机中的CPU(中央控制单元)，用于执行存储于该计算机中的ROM或RAM或其它存储介质(未示出)中的可执行程序，以实现与信道选择单元10和信道控制单元20相应的功能。
该信道控制单元20还包括一计数单元22，该计数单元22用一计数参数(ref_num)来标记使用每个信道的客户端4的数量，以实现信道控制单元20的控制功能。当所述每个信道及其子信道发生合并、跳转、或停止事件时，所述计数单元22减小计数参数的值，并且如果计数参数的值等于零，则在视频服务器1侧关闭其计数值等于零的信道。
如果该计数参数的值不等于零，则在服务器端1保持该信道，而执行了合并、跳转、或停止事件的所述客户端则不再接收该信道播放的节目。
在本发明中，视频服务器1中的信道选择单元10响应于多个客户机4对某一视频节目的请求，如图3所示，建立一根信道S1和至少一个子信道(S11)，该根信道(S1)是根据最早发出请求的客户机(例如A)的请求而建立的，而该多个子信道S11(如还有S5和S6等)中的每个是对应于一较晚发出请求的客户机的请求而建立的，该根信道S1与多个子信道S11(和S5和S6等)形成树结构。当然，上述请求都是满足视频点播条件的请求。
所有上述信道都传送基于客户端4的请求而来自视频服务器1的组播流，并且每个信道的组播流都可以由所有的客户端4接收到。每个客户端4最多可同时接收两个信道，其中一个信道是为该客户端4本身而发起的，而另一个信道则是为之前的客户端而发起的较早的信道，例如，请求对象(视频节目)的第一个客户端只从信道s1(如图3所示)接收视频流，而第二个客户端同时从信道s1和s2接收该视频流，其中s1被选择作为s2的父信道(如图3所示)。每个客户端都必须能够在本地存储器(未示出)上存储所接收的视频流。对于所建立的每一个信道，视频服务器1通过本发明的信道控制单元20监测使用该信道的客户机4的数目变化，如果使用被监测信道的客户机4数目不为零，则维持该信道，如果使用被监测信道的客户机4数目为零，即已经没有客户机4在使用该信道了，则视频服务器1通过本发明的信道控制单元20关闭该信道。
这里，视频服务器1中的信道控制单元20是通过自己的计算或通过接收来自发生信道合并的客户端4的消息来检测两个信道(视频流)的合并的。并且，该合并过程一直持续到所有的子信道都合并进根信道(对于同一视频节目所建立的第一个信道)为止。这里假设视频节目的长度是无限的。
下面参考附图详细说明根据本发明的信道合并的方法。
还参考图3，图3是示出信道合并树的示意图。其中的每个节点都表示一个信道，在这里将对某一视频节目第一个建立的信道定义为根信道，将较高一级的信道定义为较低一级的信道的父信道，相反，将较低一级的信道定义为较高一级的信道的子信道。如图3所示，S1是根信道，S6是S11的父信道，而S11是S6的子信道，同时，S6、S10、S11、和S12是S5的子孙信道的集合。
如果视频服务器1中的信道控制单元20在客户端4的请求(信道的开始、跳转)下建立了一个新的信道，我们假设它是信道S11，则信道选择单元10立即为该信道S11寻找其父信道S6。如果找到了父信道S6，则返回该父信道S6；否则，返回“找不到父信道”的消息。
上述操作执行的方法如下：
步骤1：通过下列表达式(1)，从信道S11可能并入的活动根信道的集合中找到一个最近的根信道，如S1，即：
min(S11.start_time-S1.start_time)<object_length/2       (1)
其中，min(S11.start_time-S1.start_time)表示信道S11的开始时间(S11.start_time)与根信道集合中的各个根信道的开始时间(S1.start_time)的差值中的最小值，object_length/2表示所播放的视频节目的总长度(总时间)的1/2。其中，开始时间(start_time)表示该信道开始的时刻。因此，上述表达式的含义是：信道S11的开始时刻与根信道集合中的某个根信道S1的开始时刻的差值中的最小值要小于所播放的视频节目的总长度(总时间)的1/2。在这种情况下，我们认为该根信道S1是可以被其子信道S11追上的，可以作为信道S11的根信道S1；否则，如果上述开始时刻的差值大于所播放的视频节目的总长度(总时间)的1/2，我们就认为这个根信道是不可以达到的，从而返回“不能找到根信道”的消息，并将该信道S11作为一个新的根信道。
如果用上述条件找到了有效的根信道S1，则前进到下面的步骤2。
步骤2：如果将根信道S1的子孙信道的集合定义为S，这里所述的子孙信道包括其直接父信道就是根信道S1的子信道S5和信道S5的子信道S6，这里定义信道S11是信道S6的子信道，同时可知信道S11也是信道S5的孙信道，依次类推。通过下述条件表达式(2)在集合S中找出信道S6(其中信道S6是信道S11的父信道，而信道S6和信道S11均在子孙信道集合S中，且为根信道S1的子孙信道)：
min(S11.start_time-S6.start_time)<S6.start_time-S5.start_time      (2)
上述表达式的含义为：为信道S11找一个其将要并入的父信道S6，而这个父信道S6要满足一个条件，该条件就是：该信道S11的开始时刻与待选父信道S6的开始时刻的差值中的最小值应该小于该父信道S6的开始时刻与该父信道S6的父信道S5的开始时刻的差值。
如果满足上述条件的信道S6存在，则将信道S6返回作为信道S11在下一轮合并中的父信道。否则，如果找不到满足上述条件的任何信道，则将根信道S1返回作为信道S11的父信道。
很明显，只要满足上述条件，也就保证了在信道S11并入其父信道S6之前，该父信道S6不会并入该父信道S6的父信道S5。
也就是说，在一个信道S6合并进其父信道S5的时刻，该信道S6的各个子信道，如S10和S11，均已经合并进其父信道S6。因此，从通过计算或通过接收来自客户端4的消息而得知该信道S6合并进其父信道S5的时刻起，视频服务器1关闭该信道S6，从而不会影响其它客户端的使用，因为该信道S6的选择如果满足上述条件，在这个时刻已经没有其它客户端在使用该信道S6了，即满足上述条件的信道S10和S11均已经合并进入信道S6了。这样就保证了所有的信道合并都从最次级子信道向根信道的方向进行的，即在使用某个信道的所有客户端4(以该信道的子信道的方式)明确地释放该信道之前不移除该信道。
下面结合图6、图7、图8、和图9说明响应于开始、跳转、合并、和停止这四种类型的事件，视频服务器1及其中的各单元的工作情况。
首先说明响应于开始事件，视频服务器1及其中的各单元的工作情况。
如图6所示，当客户端4在时刻t调用“开始事件”(即客户端选择播放某一段视频节目)时：
在步骤100，信道选择单元10创建一个新的信道S11播放该视频节目，并在该信道S11中设置start_time＝t，object-offset＝0(对象偏移时间：表示该信道开始时视频节目的偏移时间，即该信道的开始时间相对于在时刻t开始的信道的偏移时间)，ref_num＝1(参考数值：表示客户端的数量)；这里start_time＝t表示该信道是从时刻t开始的，object_offset＝0表示该信道没有偏移，ref_num＝1表示只有一个客户端正在使用该信道。
在步骤102，通过信道选择单元10查找该信道S11的父信道。
在步骤103，判断是否存在该父信道。
在步骤104，如果没有找到其父信道，则信道合并单元20将这个信道S11作为新的根信道(即设置root_flag＝1(根标志：表示该信道是否是根信道的标志))，并且这个信道S11是客户端4应该收看的唯一信道。
否则，在步骤105，如果找到了父信道S6，则该客户端4必须同时收看该信道S11和它的父信道S6。
在步骤106，向客户端4发送上述操作信息，以响应客户端4触发的开始请求。
下面说明响应于跳转事件，视频服务器1及其中的各单元的工作情况。
如图7所示，当客户端4在相对于时刻t的对象偏移时间s调用“跳转事件”(即客户端4在t-s的时刻进行了相当于VCR功能的快进或后退的操作)时：
在步骤200，信道选择单元10创建一个新的信道S11以播放在时刻t-s开始的该视频节目，并在该信道S11中设置start_time＝t-s，object_offset＝s，ref_num＝1；这里start_time＝t-s表示该信道是从时刻t-s开始的，object_offset＝s表示该信道的开始时间相对于在时刻t开始的信道的偏移时间为s，ref_num＝1表示只有一个客户端正在使用该信道。
在步骤202，假设在时刻t开始的信道为S4，则减少信道S4的计数参数的值，即由于客户端4刚才使用的信道S4已经被执行了停止操作，因此目前正在使用信道S4的客户端的数量减少了一个。这时，如果信道S4的计数参数为零，表示目前已经没有客户端在使用该信道S4了，则信道控制单元20关闭该信道S4；相反，如果这时信道S4的计数参数不为零，表示目前还有客户端4在使用该信道S4，则不能关闭该信道S4，以供正在使用该信道S4的其它客户端(如S8和S9)继续使用，但是调用“跳转事件”的该客户端4则不再使用该信道S4，而转向信道S11收看该视频节目了。
在步骤203，通过信道选择单元10查找该新的信道S11的父信道。
在步骤204，判断是否存在该父信道。
在步骤205，如果没有找到父信道，那么这个信道S11就作为新的根信道(即设置root_flag＝1)，并且这个信道S11是客户端4应该收看的唯一信道。
否则，在步骤206，如果找到了父信道S6，则该客户端4必须同时收看该信道S11和它的父信道S6；
在步骤208，向客户端4发送上述操作信息，以响应客户端4触发的跳转请求。
下面说明响应于合并事件，视频服务器1及其中的各单元的工作情况。
如图8所示，当客户端4触发了“合并事件”(即发生子信道S11到父信道S6的合并)时：
在步骤300，信道控制单元20减少子信道S11的计数参数的值，即由于客户端4正在使用的信道S11已经合并入其父信道S6，因此目前正在使用信道S11的客户端的数量减少了一个。这时，如果信道S11的计数参数为零，表示目前已经没有客户端在使用该信道S11了，则视频服务器1关闭该信道S11；相反，如果这时信道S11的计数参数不为零，表示目前还有客户端在使用该信道S11，则不能关闭该信道S11，以供正在使用该信道S11的其它客户端继续使用，但是调用“合并事件”的该客户端4则不再使用该信道S11，而是转向了信道S6收看该视频节目了。信道S11的计数参数的值就是正在使用该信道S11的客户端4的数目，例如，如果计数参数是1(即ref_num＝1)，表示有一个客户端4正在使用该信道S11，如果计数参数是5(即ref_num＝5)，则表示还有五个客户端4正在使用该信道，而这些信道均是信道S11的次级子信道。
在步骤302，通过信道选择单元10查找该信道S6的父信道。
在步骤303，判断是否存在该父信道。
在步骤304，如果没有找到该信道S6的父信道，那么这个信道S6就作为新的根信道(即设置root_flag＝1)，并且这个信道S6是客户端4应该收看的唯一信道。
否则，在步骤305，如果找到了信道S6的父信道S5，则该客户端4必须同时收看该信道S6和其新认定的父信道S5。
在步骤306，向客户端4发送上述操作信息，以响应客户端4触发的合并请求。
下面说明响应于停止事件，视频服务器1及其中的各单元的工作情况。
如图9所示，当客户端4调用“停止事件”(即客户端执行了相当于VCR功能的停止操作)或对象(视频节目)到达终点(即结束)时：
假设客户端正在使用信道S11观看一视频节目，则在步骤400，判断该视频节目是否已经到达终点，即是否已经结束。
如果对象(视频节目)已经到达终点，则信道控制单元20在步骤402关闭客户端4正在使用的信道S11，并直接释放该信道的所有资源。
如果该视频节目未到达终点，则在步骤404，则信道控制单元20如上所述减少信道S11的参考数值的值。如果信道S11的参考数值为零，则关闭该信道S11并释放该信道的所有资源；相反，如果信道S11的参考数值不为零，则信道控制单元20不关闭该信道S11，以供正在使用该信道S11的其它客户端继续使用，而调用“停止事件”的客户端则不再使用该信道S11。
本发明上述控制视频服务器的方法与HTTP(超文本传输协议)的请求/响应模式兼容，因此可以容易地在HTTP上实现。HTTP是在互联网上交换应用数据的主流协议，并且网络服务的出现进一步强化了基于互联网的应用在数据传输方面应该尽可能依赖HTTP的趋势。另外，大多数防火墙在允许一般数据流量的通过方面是难于处理的，但是对于HTTP来说，则不存在这个问题。
上面对本发明的实施例进行了详细地说明。本领域的普通技术人员应该明白，按照本发明的精神及指导思想对本发明做出的各种修改都在本发明后附的权利要求书所要求保护的范围内。

Claims (15)

1.一种用于视频点播***的信道合并方法，其特征在于所述方法包括步骤：
(1)响应于多个客户端对某一视频节目的请求，建立一根信道(S1)和至少一子信道(S11)，所述根信道(S1)根据最早发出请求的客户端的请求而建立，所述多个子信道(S11)中的每一个对应于一较晚发出请求的客户端的请求而建立；
(2)对于所建立的每一个信道，监测使用该信道的客户端的数目变化，如果使用被监测信道的客户端数目不为零，则维持该信道，如果使用被监测信道的客户端数目为零，则关闭该信道，
其中所有的信道合并事件都是从最次级子信道向根信道的方向进行的，并且所述根信道与多个子信道形成树结构。
2.如权利要求1所述的信道合并方法，其特征在于：所述根信道(S1)和每个子信道(S11)的建立是响应于客户端的播放开始请求或节目跳转请求。
3.如权利要求1所述的信道合并方法，其特征在于所述步骤(2)包括：
(2-1)用一计数参数标记使用每个信道的客户端的数量；
(2-2)响应于所述每个信道及其子信道的合并、跳转、或停止事件的发生，减小所述计数参数的值；
(2-3)如果所述计数参数的值等于零，则在服务器端关闭所述信道。
4.如权利要求3所述的信道合并方法，其特征在于：如果所述计数参数的值不等于零，则在服务器端保持所述信道，而执行了合并、跳转、或停止事件的所述客户端则不再接收所述信道播放的节目。
5.如权利要求1所述的信道合并方法，其特征在于步骤(1)包括步骤：
(1-1)从所述子信道(S11)可能并入的根信道(S1)的集合中搜索一根信道(S1)，所述根信道(S1)满足条件：min(S11.start_time-S1.start_time)＜object_length/2，其中，min(S11.start_time-S1.start_time)表示所述子信道(S11)的开始时刻(S11.start_time)与待选根信道集合中的各个根信道的开始时刻(S1.start_time)的差值中的最小值，object_length/2表示所播放的视频节目的总长度的1/2；
(1-2)如果所述根信道(S1)存在，则在所述根信道(S1)的子孙信道的集合中为所述子信道(S11)搜索一个其将要并入的父信道(S6)，所述父信道满足条件：min(S11.start_time-S6.start_time)＜S6.start_time-S5.start_time，其中，S6.start_time表示所述父信道(S6)的开始时刻，S5.start_time表示所述父信道(S6)的父信道(S5)的开始时刻。
6.如权利要求5所述的信道合并方法，其特征在于：如果在步骤(1-1)中未找到所述根信道(S1)，则将所述子信道(S11)设置为新的根信道，并将它的根信道参数设置为1，并且所述子信道(S11)是所述客户端收看的唯一信道。
7.如权利要求5所述的信道合并方法，其特征在于：如果在步骤(1-2)中找到了所述父信道，则所述客户端同时收看所述子信道(S11)及所述父信道的视频节目。
8.如权利要求5所述的信道合并方法，其特征在于：如果在步骤(1-2)中未找到所述父信道，则将所搜索到的根信道做为所述子信道(S11)的父信道，并且所述客户端同时收看所述子信道(S11)及所述根信道的视频节目。
9.如权利要求2所述的信道合并方法，其特征在于：如果所述客户端在时刻t的请求是开始请求，则在子信道(S11)中将一开始时间参数设置为t、将一对象偏移参数设置为零。
10.如权利要求2所述的信道合并方法，其特征在于：如果所述客户端在时刻t的请求是跳转请求，且所述跳转的对象偏移时间为s，则在所述子信道(S11)中将一开始时间参数设置为t、将一对象偏移参数设置为s，同时对所述客户端在之前时间接收的从时刻t开始播放的所述视频节目的信道执行停止操作。
11.如权利要求4所述的信道合并方法，其特征在于：如果所述停止操作是所述视频节目已经结束，则直接关闭所述子信道并释放所述子信道的全部资源。
12.如权利要求5所述的信道合并方法，其特征在于：在建立所述子信道(S11)的次级子信道时，重复步骤(1-1)和(1-2)以将所述子信道(S11)确定为该次级子信道的父信道，并将所述子信道(S11)的计数参数的值加1。
13.一种用于视频点播***的信道合并装置，所述信道合并装置配置于所述视频点播***中的视频服务器中或与其可操作地连接，其特征在于所述信道合并装置包括：
信道选择单元，用于响应多个客户端对某一视频节目的请求，建立一根信道(S1)和至少一子信道(S11)，所述根信道(S1)根据最早发出请求的客户端的请求而建立，所述多个子信道(S11)中的每一个对应于一较晚发出请求的客户端的请求而建立；
信道控制单元，用于对所建立的每一个信道，监测使用该信道的客户端的数目变化，如果使用被监测信道的客户端数目不为零，则维持该信道，如果使用被监测信道的客户端数目为零，则关闭该信道。
14.如权利要求13所述的信道合并装置，其特征在于所述信道控制单元还包括：
计数单元，用一计数参数标记使用每个信道的客户端的数量；
其中当所述每个信道及其子信道发生合并、跳转、或停止事件时，所述计数单元减小所述计数参数的值；并且如果所述计数参数的值等于零，则在服务器端关闭所述信道。
15.如权利要求14所述的信道合并装置，其特征在于：如果所述计数参数的值不等于零，则在服务器端保持所述信道，而执行了合并、跳转、或停止事件的所述客户端则不再接收所述信道播放的节目。
CNB021540063A 2002-12-05 2002-12-05 视频点播***的信道合并方法和装置 Expired - Fee Related CN1228982C (zh)

Priority Applications (11)

Application Number Priority Date Filing Date Title
CNB021540063A CN1228982C (zh) 2002-12-05 2002-12-05 视频点播***的信道合并方法和装置
TW092131521A TWI280801B (en) 2002-12-05 2003-11-11 Channel merging method for VOD system
PCT/GB2003/005123 WO2004052008A2 (en) 2002-12-05 2003-11-24 Stream merging for video on demand
CA2508074A CA2508074C (en) 2002-12-05 2003-11-24 Stream merging for video on demand
BR0316388-1A BR0316388A (pt) 2002-12-05 2003-11-24 Fusão de canal para vìdeo a pedido
AU2003302537A AU2003302537B2 (en) 2002-12-05 2003-11-24 Stream merging for video on demand
JP2004556477A JP4475521B2 (ja) 2002-12-05 2003-11-24 ビデオ・オンデマンド用のチャネル・マージ
KR1020057009168A KR100745531B1 (ko) 2002-12-05 2003-11-24 채널 병합 방법, 채널 스트리밍 장치 및 컴퓨터 판독가능 저장 매체
EP03812215A EP1568228A2 (en) 2002-12-05 2003-11-24 Channel merging for video on demand
US10/726,835 US7373653B2 (en) 2002-12-05 2003-12-03 Channel merging method for VOD system
US11/924,324 US7673318B2 (en) 2002-12-05 2007-10-25 Channel merging method for VOD system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CNB021540063A CN1228982C (zh) 2002-12-05 2002-12-05 视频点播***的信道合并方法和装置

Publications (2)

Publication Number Publication Date
CN1505401A CN1505401A (zh) 2004-06-16
CN1228982C true CN1228982C (zh) 2005-11-23

Family

ID=32400076

Family Applications (1)

Application Number Title Priority Date Filing Date
CNB021540063A Expired - Fee Related CN1228982C (zh) 2002-12-05 2002-12-05 视频点播***的信道合并方法和装置

Country Status (10)

Country Link
US (2) US7373653B2 (zh)
EP (1) EP1568228A2 (zh)
JP (1) JP4475521B2 (zh)
KR (1) KR100745531B1 (zh)
CN (1) CN1228982C (zh)
AU (1) AU2003302537B2 (zh)
BR (1) BR0316388A (zh)
CA (1) CA2508074C (zh)
TW (1) TWI280801B (zh)
WO (1) WO2004052008A2 (zh)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1359766A3 (en) * 1997-02-14 2005-02-16 AT&T Corp. A method of generating a dequantized dc luminance or dc chrominance coefficient
WO2005076549A1 (ja) * 2004-02-09 2005-08-18 Vodafone Kabushiki Kaisha 配信要求管理方法及び装置並びに配信要求管理方法のプログラム
US8707376B1 (en) * 2004-07-21 2014-04-22 Comcast Ip Holdings I, Llc Convenient video program start over system and method for a video entertainment distribution network
JP4222295B2 (ja) * 2004-11-19 2009-02-12 パナソニック株式会社 ビデオサーバおよびこれを用いた映像配信システム
US7664020B2 (en) * 2005-11-07 2010-02-16 Hanan Luss Bandwidth allocation for video-on-demand networks
CN1852421A (zh) * 2005-11-30 2006-10-25 华为技术有限公司 一种实现直播与时移播放之间切换的方法
CN100505867C (zh) * 2006-02-14 2009-06-24 腾讯科技（深圳）有限公司 点播服务***和方法
US8046810B2 (en) * 2006-04-07 2011-10-25 Alcatel Lucent Method and apparatus for delivering subscription service content to roaming users
KR20070112573A (ko) * 2006-05-22 2007-11-27 삼성전자주식회사 다중반송파 통신시스템에서 자원 할당 장치 및 방법
KR101416833B1 (ko) 2007-03-12 2014-07-09 삼성전자주식회사 스케쥴링에 의하여 개인 방송국 서비스를 제공하는 시스템,장치 및 방법
US8225354B2 (en) * 2008-04-11 2012-07-17 Microsoft Corporation Merging electronic program guide information
US20090307758A1 (en) * 2008-06-05 2009-12-10 Motorola, Inc. Method and apparatus to facilitate using a multicast stream to provide on-demand streaming content
KR101303549B1 (ko) * 2009-12-21 2013-09-03 한국전자통신연구원 사전 전송 방식을 이용한 주문형 비디오 서비스 시스템 및 그 방법
US8719876B2 (en) * 2011-05-06 2014-05-06 Verizon Patent And Licensing Inc. Video on demand architecture
US8443408B2 (en) * 2011-09-12 2013-05-14 Rogers Communications Inc. Method and system for managing bandwidth
JP2013232697A (ja) * 2012-04-27 2013-11-14 Sony Corp コンテンツ転送装置及びコンテンツ転送方法、コンテンツ再生装置及びコンテンツ再生方法、コンテンツ配信システム、並びにコンピューター・プログラム
CN106331769A (zh) * 2016-09-23 2017-01-11 北京赢点科技有限公司 直播检测服务端及优化直播资源利用方法
CN107493486B (zh) * 2017-08-11 2020-03-24 深圳英飞拓科技股份有限公司 一种视频播放终止的方法、***及终端设备

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB9508283D0 (en) * 1995-02-07 1995-06-14 British Telecomm Information services provision and management
JP3578898B2 (ja) * 1997-10-16 2004-10-20 富士通株式会社 Ｃａｔｖ伝送センタ装置、ｃａｔｖ配信システム及び番組配信方法
US6938268B1 (en) * 1998-01-08 2005-08-30 Winston W. Hodge Video stream sharing
US6665732B1 (en) * 1998-08-21 2003-12-16 Lucent Technologies Inc. Method and system for resource scheduling composite multimedia objects
US6377972B1 (en) * 1999-01-19 2002-04-23 Lucent Technologies Inc. High quality streaming multimedia
US6859839B1 (en) * 1999-08-06 2005-02-22 Wisconsin Alumni Research Foundation Bandwidth reduction of on-demand streaming data using flexible merger hierarchies
US7111316B1 (en) * 1999-08-06 2006-09-19 Wisconsin Alumni Research Foundation Method for efficient, on-demand data streaming
KR100322371B1 (ko) * 1999-11-08 2002-02-27 황영헌 방송 포털 서비스 시스템
US20020023166A1 (en) * 2000-04-11 2002-02-21 Amotz Bar-Noy Method for stream merging
WO2002049360A1 (en) * 2000-12-13 2002-06-20 THE CHINESE UNIVERSITY OF HONG KONG A body corporate of Hong Kong SAR Method and system for delivering media selections through a network
EP1433324A4 (en) * 2001-07-31 2007-04-18 Dinastech Ipr Ltd SYSTEM FOR DELIVERY OF DATA ON A NETWORK
US8713623B2 (en) * 2001-09-20 2014-04-29 Time Warner Cable Enterprises, LLC Technique for effectively providing program material in a cable television system

Also Published As

Publication number Publication date
CA2508074A1 (en) 2004-06-17
WO2004052008A2 (en) 2004-06-17
TWI280801B (en) 2007-05-01
JP4475521B2 (ja) 2010-06-09
TW200516987A (en) 2005-05-16
AU2003302537B2 (en) 2009-06-04
KR20050083937A (ko) 2005-08-26
US20080052748A1 (en) 2008-02-28
US7373653B2 (en) 2008-05-13
AU2003302537A1 (en) 2004-06-23
US7673318B2 (en) 2010-03-02
US20040172654A1 (en) 2004-09-02
EP1568228A2 (en) 2005-08-31
KR100745531B1 (ko) 2007-08-03
WO2004052008A3 (en) 2004-08-12
JP2006515966A (ja) 2006-06-08
CN1505401A (zh) 2004-06-16
CA2508074C (en) 2010-11-02
BR0316388A (pt) 2005-09-27

Similar Documents

Publication Publication Date Title
CN1228982C (zh) 视频点播***的信道合并方法和装置
CN1217543C (zh) 对等视频点播***中的设备和方法
CN1185069A (zh) 连接网络的方法和设备
CN104159127B (zh) 一种视频转码方法、装置及***
CN102036058B (zh) 视频监控***中视频切换的方法、服务器、终端及***
TW200904095A (en) Network communication control method and system
CN1894858A (zh) 接收装置和接收方法
CN101035076A (zh) 一种多级交换网的反压方法、***及交换节点
Gao et al. Proxy-assisted techniques for delivering continuous multimedia streams
CN101043618A (zh) 一种在多路视频通讯中控制帧率的装置和方法
WO2015101303A1 (zh) 频道处理方法和装置
JP2008277961A (ja) オンデマンドデータ配信システム
CN1497959A (zh) 接收装置和接收方法
CN105828109A (zh) 服务器、客户端及基于rtsp/rtp的播放***
CN1860469A (zh) 使用动态通道提供点播多媒体数据服务的方法及其装置
CN1751303A (zh) 用于有效分配可多播服务的***和方法
CN100370727C (zh) 一种在互联网络中发送并处理广告的方法及***
CN103702219A (zh) 一种视频播放的控制方法及设备
CN107135424B (zh) 对多个数字电视菜单导航页的管理方法和装置
CN102387138B (zh) 一种基于屏幕保护的数据传输方法和设备
CN102164272A (zh) 在网络视频监控平台中减少云台控制延时的方法
CN1165454A (zh) 电缆电视***和用于电缆电视***的终端装置
CN1703086A (zh) 数据分发装置及其控制方法
CN1867175A (zh) 无线资源的分配方法及装置
CN108259815B (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: GOOGLE INC.

Free format text: FORMER OWNER: INTERNATIONAL BUSINESS MACHINES CORP.

Effective date: 20110414

C41 Transfer of patent application or patent right or utility model
COR Change of bibliographic data

Free format text: CORRECT: ADDRESS; FROM: NEW YORK, THE USA TO: CALIFORNIA, THE USA

TR01 Transfer of patent right

Effective date of registration: 20110414

Address after: American California

Patentee after: Google Inc.

Address before: American New York

Patentee before: International Business Machines Corp.

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

Granted publication date: 20051123

Termination date: 20151205

EXPY Termination of patent right or utility model