信息传递设备、信息传递方法和信息传递系统

摘要

本发明揭示了一种信息传递设备，它向终端传递由该终端指定的关于具体资源的更新信息，该信息传递设备包括：传递部分，配置来用于从终端接收要求传递关于资源的更新信息的请求，并将更新信息传递给终端；更新信息产生部分，配置来用于在向传递部分输出所产生的更新信息之前，在检测到资源的更新时，产生关于资源的更新信息；其中，在从更新信息产生部分获取更新信息时，传递部分向终端传递所获取的更新信息。

说明书

技术领域

本发明通常涉及信息传递设备、信息传递方法和信息传递系统。更具体地说，本发明涉及用于传递关于由终端指定的具体资源的更新信息的信息传递设备、信息传递方法和信息传递系统。

背景技术

现在，在藉以从Web站点发布和传递更新信息的各种装置中，RSS(ReallySimple Syndication/RDF(Resource Description Framework)Site Summary)和Atom已是众所周知的了。RSS或Atom(以下称为RSS/Atom)是一种格式，在此格式中，可以使用XML(可扩展标记语言)结构上表达张贴在Web页面上的数据的属性信息。以RSS/Atom格式书写的数据称为馈给(feed)。RSS/Atom馈给可以包括Web站点的名称、概况和更新日期的信息。

最近几年，RSS/Atom馈给不仅用于传递更新信息，而且用于发布新闻报道、新产品信息和支持信息。RSS/Atom馈给也用于发布音频数据文件。用户可以利用与RSS/Atom兼容的浏览器、称为RSS/Atom阅读器的专用软件或装有阅读器的Web浏览器来获得RSS/Atom馈给。这样，用户就能得到更新信息而不用实际存取如像Web页面之类的信息资源。已公开的日本专利申请No.2005-284334揭示了一种使用RSS从Web站点传递更新信息的技术。

发明内容

说明性地，在Web站点上更新信息时，自动产生RSS/Atom馈给。将这样产生的馈给存储在Web服务器中。在从客户机(即与RSS/Atom兼容的浏览器或RSS/Atom阅读器)上接收到馈给获取请求时，就将所请求的RSS/Atom馈给传递给客户机。

这就是所谓的客户机拉取技术，该技术可让客户机定期地存取并获得RSS/Atom馈给。可用这种所谓的接收(get)方法和邮递(post)方法来获取RSS/Atom馈给。一般按照用户事先确定的固定的间隔，从客户机向RSS/Atom服务器发送请求获取RSS/Atom馈给的GET/POST(接收/邮递)命令。在每次收到GET/POST(接收/邮递)命令时，服务器就将RSS/Atom馈给发送给提出请求的客户机。

不管是否更新了RSS/Atom馈给，都由客户机提出馈给获取请求。这就是说，即使没有更新相应的馈给，也要发送RSS/Atom馈给。这就导致了客户机对服务器的不必要的存取，并造成在服务器和相关线路上的过度负担。

利用这样的客户机拉取传递技术，由服务器实际更新信息的日期几乎总是不同于客户机向服务器发送RSS/Atom馈给获取请求的日期。这样，就有一个问题，这就是用户不能从Web站点上实时得到更新信息和其它信息。

鉴于上述的情况提出了本发明，并提供了配置，以使得在更新目标数据(资源)时，将更新信息实时传递给用户。

在根据本发明的一个实施例执行本发明时，提供了信息传递设备(即服务器)，用于向终端传递由该终端(即客户机)指定的具体资源的更新信息，该信息传递设备包括：传递部分，配置来用于从终端接收要求传递关于资源的更新信息的请求，并将更新信息传递给该终端；更新信息产生部分，配置来用于在向传递部分输出所产生的更新信息之前，在检测到资源更新时、产生资源的更新信息；其中，在从更新信息产生部分获得更新信息时，传递部分将所获得的更新信息传递给该终端。

上述结构的信息传递设备进行从检测资源更新到通知资源更新信息的一整套的步骤。在更新所关注的资源时，就由此设备将相关的资源更新信息传递给发出请求的客户机。

根据上面概述的本发明，一旦检测到资源更新，就产生资源的更新信息。并立即将所产生的更新信息传递给相关的客户机。这就是说，客户机的用户能够实时获得资源的更新信息。

由于从检测资源更新到通知资源更新信息的一整套的步骤都是由信息传递设备进行的，因此，客户机不必向信息传递设备询问关于资源更新的情况。这个特性就减轻了在信息传递设备和通信线路上的负担。

附图说明

图1是示意图，该图说明了作为本发明的第一实施例的系统是如何配置的。

图2是方块图，该图作为第一实施例的一部分，示出了SIP(sessioninitiation protocol，会话开始协议)的典型的内部结构。

图3是方块图，该图作为第一实施例的一部分，示出了客户机的典型的内部结构。

图4是顺序图，该图示出了由第一实施例执行的典型步骤，这些步骤包括请求订阅馈给和资源获取。

图5A和5B是示意图，该图说明性地描述了SIP消息(message)，图5A给出了订阅消息的典型描述，图5B给出了通知消息的典型描述。

图6是示意图，该图示出了由第一实施例提供的典型的馈给描述。

图7是示意图，该图示出了由第一实施例提供的另一个典型的馈给描述。

图8是示意图，该图示出了由第一实施例提供的资源更新信息的典型显示。

图9是示意图，该图示出了由第一实施例的变体提供的另一个典型的馈给描述。

图10是示意图，该图说明了作为本发明的第二实施例的系统是如何配置的。

图11是顺序图，该图示出了由第二实施例执行的典型步骤，这些步骤包括请求订阅馈给和资源获取。

图12是示意图，该图示出了由第二实施例提供的典型的馈给描述。

图13是顺序图，该图示出了由第二实施例执行的其它的典型步骤，这些步骤包括请求订阅馈给和资源获取。

图14A和14B是示意图，该图示出了由第二实施例提供的其它的典型的馈给描述。

图15是示意图，该图说明了作为本发明的第三实施例的系统是如何配置的。

图16是顺序图，该图示出了由第三实施例执行的其它的典型步骤，这些步骤包括请求订阅馈给和资源获取。

图17是示意图，该图示出了由第三实施例提供的其它的典型的馈给描述。

具体实施方式

[第一具体实施例]

下面将结合附图来说明本发明的推荐的具体实施例。首先，将参照图1到图8来说明本发明的第一具体实施例，该实施例是以信息传递系统的形式实施的。该信息传递系统构成了IPTV装置，它在IP(互联网协议)网络上传递TV节目和电影。使用称为IMS(IP多媒体子系统)的技术来实现此IPTV装置，以便通过分组网络提供多媒体服务。在这方面，在推荐的实施例中所用的“资源”一词是指如像在IPTV上传递的视频信号之类的内容。

图1示意性地示出了如何配置作为本发明的第一实施例的系统。在图1中，通过网络5将SIP服务器100与客户机1-1和2-1互连起来。客户机1-1的用户是资源持有者，由他们来产生或更新IPTV的视频内容。客户机2-1的用户接收并观看由资源持有者产生或更新的内容。

SIP服务器100是由作为更新信息产生部分的馈给产生部分101、馈给传递部分102和位置管理部分103构成的。在从资源持有者1-1接收到更新通知时，馈给产生部分101产生包括内容更新信息的馈给，并将所产生的馈给转发给馈给传递部分102。一旦从客户机2-1上接收到了馈给订阅请求，馈给传递部分102就向位置管理部分103发送要求订阅的馈给类型以及关于要求订阅的客户机的信息。馈给传递部分102进而将来自馈给产生部分101的馈给传递给请求订阅馈给的客户机2-1。

位置管理部分103接收在以下两方面之间对应性的注册，一方面是以SIPURI(统一资源指示符)书写的客户机的ID，另一方面是客户机的传输地址(即IP地址和端口号)，位置管理部分103还接收关于由资源持有者持有的内容被存储的位置的信息的注册。位置管理部分103也允许在以下两方面之间的对应性的注册，一方面是要求订阅的每个资源的类型，另一方面是要求订阅的客户机。

尽管在图1中未示出，SIP服务器100也起着代理服务器的作用，它在客户机1-1和客户机2-1之间中介传递SIP消息。

在图1中虽然只示出了客户机1-1和客户机2-1，但是，这并不是说可以配置的客户机的数目只限于两个。在图1中，为了简单和便于说明起见，示出了资源持有者的角色和用户的角色固定到特定客户机。实际上，这些角色可以根据用户的操作来切换。例如，如果客户机通过网络5向SIP服务器100发送要求传递资源更新信息(即要求馈给订阅)的请求或者已经获得了某内容，那么，该客户机就变成了用户。该客户机可以在观看所获得的内容的同时进而产生或更新资源。在此情况下，就可以把一个客户机既当作是资源持有者又当作是用户。

下面将参照图2来说明如何构建SIP服务器100。SIP服务器100是由以下部分构成的：控制部分110、ROM(只读存储器)111、RAM(随机存取存储器)112、通常由硬盘驱动器构成的存储部分113、通常由键盘和鼠标构成的操作部分115，以及通信部分117。

控制部分110根据存储在ROM111中的计算机程序或者是那些装载到RAM112中的程序来进行各种处理。在控制部分110进行各种不同的处理时，RAM112也容纳控制部分110所需要的数据。上面参照图1说明的馈给产生部分101和馈给传递部分102在控制部分110的控制下进行操作。在上面参照图1讨论过的位置管理部分103可以在存储部分112的内部实现。由馈给传递部分102输出的馈给通过通信部分117和网络5发送给客户机2-1。

通过总线120将上述的组成部分互连起来。通过接口(I/F)114和116分别将存储部分113和操作部分115连接到总线120上。

下面将参照图3来说明客户机1-1和2-1的典型结构。在第一实施例中，假设客户机1-1和1-2具有相同的结构。客户机1-1(或2-1)是由以下部分构成的：控制部分12、ROM 13、RAM 14、存储部分15、操作部分17、扩音器19、音频处理部分20、音频输出部分21、音频处理部分22、显示部分23、显示控制部分24和通信部分25。通过总线11将这些部分互连起来。通过接口16和18分别将存储部分15及操作部分17与总线11连接起来。

在结构上，控制部分12、ROM 13、RAM 14、存储部分15、操作部分17、显示部分23、显示控制部分24以及通信部分25分别和SIP服务器100中的它们的对应部分等同，因此不再进行讨论。音频处理部分20将来自扩音器19的模拟音频信号转变为数字音频数据，并根据需要压缩转化了的数据。音频处理部分22将放在总线11上的压缩了的数字音频数据扩展为模拟音频信号。由话筒和/或耳机来构成音频输出部分21。

上述结构的客户机2-1通过通信部分25从SIP服务器100上接收馈给。通过总线11将接收到的馈给转发给控制部分12。控制部分12将馈给送去进行句法分析或类似的检查。控制部分12将分析过的馈给转换成通常为HTML(超文本标记语言)格式的数据。将转换了的数据作为更新信息输出到显示控制部分24，在显示部分23上显示更新信息。虽然在上面的例子中示出了将馈给转换成了HTML文件格式，但是这并不是对本发明的限制。可以另外将馈给转换成与显示部分23的显示格式相兼容的任何其它的数据格式。

显示在显示部分23上的更新信息包括指示存储所关注的内容的位置的链接形式的存储位置信息。在由用户操作操作部分17来选择链接的时候，通过通信部分25将连接请求发送到作为所述内容的持有者的客户机1-1上。在客户机1-1收到连接请求并与客户机1-1建立了连接(即媒体会话)的情况下，就将用户早先选择的内容从客户机1-1发送到客户机2-1。

如果来自客户机1-1的内容包括视频数据，那么，就通过总线11将视频数据发送到显示控制部分24上。在由显示控制部分24进行了解密或其它处理后，将视频数据输出到显示部分23并作为图像显示于其上。如果内容包括音频数据，那么，就通过总线11将音频数据发送到音频处理部分22。由音频处理部分22进行随后的数据扩展和其它处理，从音频输出部分21上输出音频数据。

下面将参照图4来说明按下述方式进行的常规步骤：客户机2-1向SIP服务器100发送馈给订阅请求，SIP服务器100将作为内容更新信息的馈给传递给客户机2-1，客户机2-1根据所传递的内容更新信息来获取所关注的内容。在图4中，假设客户机2-1希望被告知的内容更新信息是关于要在IPTV上广播的电视节目的电子节目指南(EPG)的更新信息。

在步骤S1中，作为用户的客户机2-1在发送SUBSCRIBE(订阅)请求之前，在SUBSCRIBE(订阅)请求的请求行(line)中，向SIP服务器100的馈给传递部分102说明希望传递其更新信息的内容的类型作为馈给订阅请求。在图5A中示出了在此点上要发送的SUBSCRIBE(订阅)请求的典型描述。在图5A中，第一行”Ln1”是请求行。在请求行的“Request-URI”部分中，指定了“sip:media-epg-pl@sip.media.server.example”。这就意味着客户机2-1的用户请求订阅用URI“sip:media-epg-pl@sip.media.server.example”来管理的资源的更新信息。

在行“Ln2”的“Event(事件)”头标中，指定了事件名“feed(馈给)”。行“Ln2”规定用户想要被告知的事件的类型是“feed(馈给)”。在行“Ln3”的“Accept(接受)”头标中，指定了“application/atom+xml”。行“Ln3”规定客户机2-1可接收的格式是“Atom”。被指定为可接受的格式是放在NOTIFY(通知)消息的正文格式中的内容类型，NOTIFY(通知)消息是作为对订阅(SUBSCRIBE)请求的响应而发送的。

第一实施例利用SIP URI(统一资源标识符)作为关于馈给的链接目标信息。由于这个缘故，采用Atom来包含除了URL(统一资源位置符)以外的信息。如果以后RSS被布置来包含链接的URI而不是链接的URL作为链接目标，那么，就可以采用RSS。另外，也可用其它适合的数据格式。

回到图4中的步骤S2上，馈给传递部分102如果接受来自客户机2-1的请求，则用响应代码200进行响应。虽然在图4的顺序图中没有示出，也要在SIP服务器100的位置管理部分103(见图1)中，与请求订阅的客户机2-1相关联地注册内容的类型，其中，所述内容的馈给是客户机2-1想要订阅的。

在步骤S3中，在馈给传递部分102将NOTIFY(通知)请求传递给客户机2-1之前，将携带在此时间点上的最新更新信息的馈给F1放在NOTIFY(通知)请求的正文中。图5B示出了要传递的NOTIFY(通知)请求的典型描述。在图5B所示的请求中，将“feed(馈给)”指定在行Ln4的事件(event)头标中；将“application/atom+xml”指定在行Ln5的“Content-Type(内容类型)”头标中。这就表明在此点上要报告的事件的类型是“馈给(feed)”，并且含于正文中的数据格式(即正文格式)的内容类型是“Atom”。行Ln6的正文含有此时要传递的馈给F1。如果使用的是RSS而不是Atom，那么，就在Content-Type(内容类型)的头标中指定“MIME”类型。

在此所传递的馈给D1已经发送给了订阅EPG更新信息的馈给的用户。对于想要续订的客户机2-1而言，馈给F1是最新的更新信息，并且在此点上将其传递给客户机2-1。一旦在步骤S4上接收了馈给F1，客户机2-1就通过使用响应代码200来进行响应。将由馈给产生部分101产生的馈给存储在存储器或图中未示出的类似器件中。馈给传递部分102根据需要从存储器中检索馈给以备传递。

图6示出了馈给F1的典型描述。在图6中指定为要素E1的区域中，夹在<title>标记之间的行示出了馈给的标题“SIP EPG”；夹在<id>标记之间的行示出了分配给馈给的ID(标识符)；夹在<updated>标记之间的行示出了馈给的更新日期，“2007年，6月，10日，星期日，11:23:45”；夹在<subtitle>标记之间的行示出了馈给的子标题，“媒体内容信息表”。关于单个电视节目的信息示于<entry>区域中，例如，要素E2和E3。

关于“节目02”的更新信息写在要素E2中，关于“节目01”的信息写在要素E3中。在要素E2和E3中，夹在<pubDate>标记之间的行表示最后更新各个节目的日期。更具体地说，“节目02”的更新日期是“2007，6月，10日，星期日，11:00:00”，“节目03”的更新日期是“2007年，6月，10日，星期日，10:00:00”。这就是说，是按照时间顺序从下向上将节目排列在馈给F1中。夹在<link>标记之间的行表明关于实际存储节目的位置的信息，即在SIP URI中描述的信息，这如像“sip:media-epg-pl@sip.media.server.example.”。夹在<auther(作者)>标记之间的行表明更新资源(即节目)的人的名字，例如更新“节目03”的人是“Carol”和更新“节目02”的人是“Bob”。

换句话说，在图6所示的馈给F1中，夹在<entry>标记之间的正文区描述了由“Carol”在2007年6月10日星期日10:00更新的关于“节目03”的信息，以及由“Bob”在2007年6月10日星期日11:00更新的关于“节目02”的信息。

回到图4中的步骤S5，由客户机1-1，即资源持有者来更新节目(资源)。在步骤S6中，客户机1-1使用PUBLISH(发布)请求，向在SIP服务器100中的馈给产生部分101通知关于资源更新的信息。在步骤S7中，在SIP服务器100中的馈给产生部分101向客户机发出响应“200 OK”。在步骤S8中，馈给产生部分101更新馈给F1，以便根据从客户机1-1上接收到的PUBLISH(发布)请求中的描述来产生馈给F2。在步骤S9中，将所产生的馈给F2发送给馈给传递部分102。

在步骤S10中，一旦接收到了馈给F2，馈给传递部分102就在向客户机2-1发送NOTIFY(通知)请求之前，将接收到的馈给放到NOTIFY(通知)请求的正文中。在步骤S11中，在接到NOTIFY(通知)请求之后，客户机2-1就将响应“200 OK”发回给馈给传递部分102。

图7示出了馈给F2的典型描述，在馈给F2中，要素E6和E7分别相应于在馈给F1中的要素E2和E3。这就是说，在前面传递的馈给中所描述的关于单个节目的更新信息没有改变。在此描述中，放在要素E6上面的要素E5包含最近的更新信息。

要素E5包含了关于由“Alice”在2007年6月10日星期日12:00:00更新的“节目01”的信息。图4的顺序图示出在步骤S8上更新了馈给F2。馈给产生部分101根据在图4的步骤S7上从客户机1-1上发送的资源更新信息来产生馈给F2。由于这个缘故，客户机101(的用户)原来是“Alice”。

馈给F2也示出在要素E4中的、夹在<updated>标记之间的行中的日期(即产生此馈给的日期)是“2007年6月10日星期日12:00:00”，与在要素E5中的、夹在<pubDate>标记之间的行中的日期相同。这就是说，更新要素E5中所描述的消息的时间与产生包含资源更新信息的馈给的时间是相同的。这是因为从更新资源的步骤S5到将馈给传递给客户机2-1的步骤S10的处理工序是连续进行的。这样，就将资源更新信息实时传递给了用户。

为了简单和便于说明起见，在上面示出的例子中，更新资源、产生馈给和传递馈给是同时进行的。实际上，从更新资源开始到传递馈给为止经过了有限的一段时期；在步骤S8中要花费时间来更新馈给，并且要花费时间来将馈给从馈给产生部分101发送到馈给传递部分102。这些时间段在资源更新日期和馈给传递时间之间累积。

图4中的步骤S12和其后的步骤构成了如下过程，在此过程中，客户机2-1实际上根据在步骤S10上由馈给传递部分102传递的馈给中的信息获取所关注的内容。如上面参照图3所讨论的那样，将传递给客户机2-1的馈给转换成HTML或类似的格式，并将其显示在显示部分23(见图3)上。显示部分23以链接的形式显示资源存储位置信息。

图8示意性地示出了在显示部分23上的资源更新信息的典型显示。图8中指示为A1的区域描述了写在馈给F2的要素E5中的内容(见图7)。这就是说，区域A1描述了已由“Alice”更新的关于“节目03”的信息。链接示出为“节目03”的行，并且，在馈给F2的要素E5中，将行“sip:media-epg-pl@sip.media.server.example.”嵌入在<link>标记之间。在图8中由A2指定的区域相应于馈给F2中的要素E6，由A3指定的区域相应于馈给F2中的要素E7。

可以由客户机2-1的用户来选择这些链接中的任何一个或全部。在选择链接时，在图4的步骤S12中，客户机2-1以INVITE(邀请)请求的形式向客户机1-1(资源持有者)发送会话建立请求。

在步骤S12中发送的INVITE(邀请)请求配备有SDP(会话描述协议)部分，它包括客户机2-1所想要的带宽(即服务质量(QoS))以及编解码器信息。如果已经接收到INVITE(邀请)请求的客户机1-1接受该信息，在步骤S13中，客户机1-1就把响应“200 OK”发回给客户机2-1。在步骤S14中，在客户机1-1和客户机2-1之间建立媒体会话。在建立媒体会话之后，客户机2-1通过实时通信获取所关注的内容。示例性在RTSP(实时流式传输协议)下进行实时通信。

根据其结构和处理程序已在上面说明了的第一实施例，在更新资源时，产生包括关于该更新的信息的馈给。将这样产生的馈给立即发送给想要订阅该馈给的客户机(即用户)。照此方式，用户就能实时获得资源更新信息。

而且根据其结构和处理程序已在上面说明了的第一实施例，由SIP服务器100来进行从检测资源更新到传递有关更新的馈给的步骤。这样，就不需要客户机一方轮询服务器了。由于中断了对服务器的不必要的存取(访问)，就减轻了加在服务器和相关线路上的负担。

通过使用其结构和处理程序已在上面说明了的第一实施例，用于传递资源更新信息的馈给也可以包括元数据(metadata)的描述，这如像关于资源的作者及其副标题的描述。这就允许用户同时校验资源更新信息和资源属性信息。也可能在单个的馈给中传递多个电视广播频道的信息。

通过使用其结构和处理程序已在上面说明了的第一实施例，也安排了馈给来携带资源存储位置信息。在显示部分或类似的器件上，以链接的形式来显示该信息，并让用户点击一个或多个适当的链接，以便轻易地获取所想要的资源。

此外，根据其结构和处理程序已在上面说明了的第一实施例，用户使用SUBSCRIBE(订阅)请求来发送馈给订阅请求。响应于该请求，将用户想要得到通知的资源更新信息以NOTIFY(通知)请求的形式传递给用户。这就是说，在用户需要时，仅将用户想要的信息传递给用户。

尽管上述的第一实施例被示出为让作为资源持有者的客户机1-1在SIP之下使用所谓的PUBLISH(发布)方法来通知SIP服务器关于资源更新的信息，但是，本发明并非仅限于此。另外的办法是，可以通过使用“SUBSCRIBE(订阅)”请求和“NOTIFY(通知)”请求在资源持有者和SIP服务器100之间交换资源更新信息。

在前面的选用方案中，SIP服务器100使用“SUBSCRIBE(订阅)”请求事先向作为资源持有者的客户机1-1提出事件状态(即资源更新)通知请求。这个安排促使更新资源的人在每次更新资源时向SIP服务器100发出“NOTIFY(通知)”消息。作为另一个选用方案，资源持有者可以使用另外一些合适的协议(例如HTTP)来通知SIP服务器100进行了资源更新。

根据上述的第一实施例，示出了馈给产生部分101将馈给发送给馈给传递部分102。另外，也可以不处理馈给本身；可以仅发送馈给更新信息以及关于馈给存储位置的信息。在此情况下，可以单独提供用以管理馈给文件的文件系统，以便容纳由馈给产生部分101产生的馈给。每当把馈给存储到文件系统中，就可以从馈给产生部分101向馈给传递部分102发送包括馈给存储位置信息例如，“/xm/feed/new.xml”的更新通知。

根据上述的第一实施例，将要在IPTV上提供的节目的EPG作为馈给来传递。另外，也可以用馈给的形式来传递其它的信息，只要该信息是用SIP URI来管理的资源。图9示意性地示出了关于覆盖在包括IP电话终端的电话目录中的更新的信息的典型的馈给描述。

标明为要素E8的区域包括馈给标题、馈给标识符信息以及馈给更新日期信息。那些标明为要素E9和E10的正文区域包括用SIP URI表示的电话号码。示出了要素E9包括Bob的电话号码“sip:bob@sip.example”以及夹在<pubDate>标记之间的电话号码的更新日期“2007年6月10日星期日12:00:00”。示出了要素E10包括Carol的电话号码的更新信息。照此方式，可以使用馈给连同元数据来传递关于电话簿的更新信息。

[第二实施例]

现在将参照图10到图14B来说明本发明的第二实施例。第二实施例涉及作为馈给传递关于新闻的更新信息，这些新闻是由文本数据和视频数据构成的。在此假设文本数据和视频数据包括两类数据：用SIP URI管理的数据和用Web服务器管理的数据。在随后的说明中，把用SIP URI管理的资源称为SIP资源，把用Web服务器管理的资源称为Web资源。

图10是一个示意图，该图说明了作为本发明的第二实施例的系统是怎样构成的。在图10中，在网络5上将客户机1-1到1-3以及客户机2-1和2-2与应用服务器200相连。图10中的客户机1-1的用户是资源持有者，他产生并更新用SIP URI管理的资源。客户机1-2的用户是资源持有者，他产生并更新用Web服务器管理的资源。客户机1-3的用户是资源持有者，他产生并更新用SIP URI管理的资源和用Web服务器管理的资源。客户机2-1和2-2的用户利用这些资源。构造应用服务器200，以使其具有SIP服务器和Web服务器的能力。

应用服务器200是由以下部分构成的：HTTP(超文本传输协议)处理部分201、数据库(DB)202、馈给产生部分203、馈给传递部分204和位置管理部分205。HTTP处理部分201分析并响应从客户机上发送的HTTP请求。例如，如果借助于所谓的POST方法或PUT方法从客户机1-2或1-3上发送资源，那么，HTTP处理部分201就把接收到的资源放到数据库202中存储起来。如果从客户机1-2或1-3上发送GET命令，HTTP处理部分201就从数据库202中读取命令中指定的资源并将检索到的资源发送给提出请求的客户机。

在检测到资源更新的时候，即一旦HTTP处理部分201从客户机1-2或1-3上收到POST命令或PUT命令，馈给产生部分203就产生包括内容更新信息的馈给，并将所产生的馈给转发给馈给传递部分204。馈给传递部分204和位置管理部分205按照与图1中的馈给传递部分102和位置管理部分103相同的方式操作，因此不再加以说明。应用服务器200的内部结构与图2所示的结构相同，与此同时，客户机1-2或1-3的结构与图3中所描述的结构相同，因此不再对这些结构加以说明。

下面将参照图11来说明按这样的方式进行的步骤：客户机2-1首先发出馈给订阅请求给应用服务器200，然后，将包含资源更新信息的馈给发送给客户机2-1，客户机2-1根据资源更新信息获取所关注的资源。

在图11的步骤S21中，客户机2-1以“SUBSCRIBE(订阅)”请求的形式向应用服务器200的馈给传递部分204发送馈给订阅请求。在步骤S22中，馈给传递部分204将响应“200 OK”发回给客户机2-1。在此，假设关于客户机2-1想要订阅的资源的馈给还待产生(即没有馈给存储在存储器中)。在步骤S23中，馈给传递部分204向客户机2-1发送没有正文(body)的NOTIFY(通知)请求。在步骤S24中，客户机2-1基于接到NOTIFY(通知)请求，将响应“200 OK”发回给馈给传递部分204。

在步骤S25中，持有SIP资源和Web资源的客户机1-3更新覆盖这两种资源的消息。换句话说，同时更新了Web资源和SIP资源。在步骤S26中，客户机1-3使用在HTTP下的POST命令向HTTP处理部分201发送关于Web资源的更新信息，并使用PUBLISH(发布)请求向馈给产生部分203发送关于SIP资源的更新信息。虽然在图11中并未示出，但是由HTTP处理部分201将附在POST命令上的资源写到数据库202中的适当位置上。在步骤S27中，HTTP处理部分201和馈给产生部分203中的每一个都将响应“200 OK”发回给客户机1-3。在图11中，示出了客户机1-3使用在HTTP下的POST命令向应用服务器200发出Web更新通知。另外的办法是，还可以替代地使用一些其它的合适的命令，例如，PUT命令。

在步骤S28中，馈给产生部分203根据在步骤S25中从客户机1-3上发出的资源更新通知来产生馈给F3-1。在步骤S29中，馈给产生部分203将所产生的馈给F3-1发送给馈给传递部分204。

图12示意性地示出了馈给F3-1的典型描述。标明为要素E11的区域包括馈给标题(“最新的消息”)，馈给标识符(sip:news@spi.app.server.example)，馈给更新日期(2007年6月10日星期日12:10:00)，馈给副标题(“带有WebURL和SIP URI的新闻标题”)。在构成要素E12的正文中，夹在<entry>标记之间的区域包含资源(即新闻)的更新信息

在要素E12中，夹在<title>标记之间的行包括标题为“一条关于娱乐活动的消息”的新闻更新信息。在夹在<putDate>标记之间的行上示出了该信息的更新日期“2007年6月10日星期日12:10:00”。此更新日期与馈给产生日期(在要素E11中夹在<updated>标记之间)相同。可以看出在更新标题为“一条关于娱乐活动的消息”的新闻的同时产生馈给。

在要素E12中，有两个夹在<link>标记中的行，一行是与Web资源链接的“http://www.app.server.example/entertainment/20070610121000.html”，另一条是与SIP资源链接的“sip:news-entertainment-20070610121000

@sip.app.server.example”。由此可以看出，客户机1-2更新了存储在http://www.app.server.example/entertainment/20070610121000.html”上的Web资源以及存储在“sip:news-entertainment-20070610121000@sip.app.server.example”上的SIP资源。这两个资源构成了标题为“一条关于娱乐活动的消息”的新闻。

在步骤S30中，通过使用NOTIFY(通知)请求，将在图11的步骤S29从馈给产生部分203转发到馈给传递部分204上的馈给F3-1从馈给传递部分204发送到客户机2-1。在步骤S31中，接收到NOTIFY(通知)请求的客户机将响应“200 OK”发回给馈给传递部分204。

如果客户机2-1的用户选择了在馈给F3-1的要素E12中描述的Web资源(见图12)，客户机2-1就在步骤S32中向应用服务器200的HTTP处理部分201发送作为资源获取请求的HTTP请求。在此所用的HTTP请求通常是GET命令。在步骤S33中，一旦接收到HTTP请求，HTTP处理部分201就通过使用HTTP响应将所请求的资源发送给客户机2-1。

如果客户机的用户选择在馈给F3-1的要素E12中描述的SIP资源(见图12)，那么，在步骤S34中，客户机2-1就使用INVITE(邀请)请求将会话建立请求发送给持有所述的资源的客户机1-3。如果客户机1-3接收INVITE(邀请)请求，在步骤S35中，客户机1-3就将响应“200 OK”发回给客户机2-1。在步骤S36中，在客户机之间建立媒体会话。客户机2-1在建立媒体会话之后通过实时通信获取所关注的内容。

下面将要参照图13来说明按照这样的方式进行的典型步骤：由持有SIP资源的客户机1-1以及持有Web资源的客户机1-2来更新资源，将资源更新信息传递到客户机2-1，客户机2-1获取所想要的资源。图13的顺序图时间上从图11的顺序图继续而来。在此假设客户机2-1已经向应用服务器200的馈给传递部分204发送了馈给订阅请求。

在步骤S37中，作为Web资源的持有者的客户机1-2更新Web资源。在步骤S38中，客户机1-2使用在HTTP下的POST命令向应用服务器200的馈给传递部分204发送资源。在步骤S39中，一旦接收到POST命令，HTTP处理部分201就将含于POST命令中的资源存储到数据库202中，并将响应“200 OK”发回给客户机1-2。

在检测到HTTP处理部分201收到来自客户机1-2的POST命令时，应用服务器200的馈给产生部分203在步骤S40中根据在POST命令中发现的信息更新馈给F3-1(见图12)，以便产生馈给F3-2。在步骤S41中，馈给产生部分203将所产生的馈给F3-2发送给馈给传递部分204。

图14A示出了馈给F3-2的典型描述。在馈给F3-2中，标明为要素E15的底部区域所包含的信息与图12的要素E12中的信息相同。在要素E15之上的标明为要素E14的区域包含由客户机1-2通知的资源更新信息。在要素E14中，夹在<title>标记中的行示出了标题为“一条关于体育运动的消息”的新闻的更新信息。如在夹在<putDate>标记之间的行所标明的那样，该新闻的更新日期是“2007年6月10日星期日12:20:00”。此更新日期与馈给创建日期相同(在要素E13中夹在<updated>标记之间)。这就是说，在更新标题为“一条关于体育运动的消息”的新闻的同时产生馈给。

在要素E14中，夹在<link>标记之间的行含有地址“http://www.app.server.example/entertainment/20070610121000.html”。这个地址是存储构成所述新闻的数据的位置。

在步骤S42中，将在图13的步骤S41中从馈给产生部分203转发到馈给传递部分204上的馈给F3-2，以NOTIFY(通知)请求的形式，从馈给传递部分204发送到客户机2-1。在步骤S43中，接收到NOTIFY(通知)请求的客户机2-1将响应“200 OK”发回给馈给传递部分204。

如果客户机2-1的用户选择在馈给F3-2的要素E14中描述的Web资源(见图14A)，则在步骤S44中，客户机2-1向应用服务器200的HTTP处理部分201发送作为资源获取请求的HTTP请求。在步骤S45中，接收了HTTP请求的HTTP处理部分201使用HTTP响应将所请求的资源发送给客户机2-1。

在步骤S46中，作为SIP资源持有者的客户机1-2更新SIP资源。在步骤S47中，客户机1-1使用PUBLISH(发布)请求向应用服务器200中的馈给产生部分203通知资源更新。在步骤S48中，馈给产生部分203将响应“200OK”发回给客户机1-1。在步骤S49中，馈给产生部分203根据从客户机1-1上接收到的“PUBLISH(发布)”请求更新馈给F3-2，以便产生馈给F3-3。在步骤S50中，馈给产生部分203向馈给传递部分204发送所产生的馈给F3-3。

在步骤S51中，馈给传递部分204接收馈给F3-3，并在向客户机2-1发送NOTIFY(通知)请求之前，将馈给F3-3的内容放到“NOTIFY(通知)”请求的正文中。在步骤S52中，接收到NOTIFY(通知)请求的客户机2-1向馈给传递部分204发回响应“200 OK”。

图14B示出了馈给F3-3的典型描述，在馈给F3-3中标明为要素E18和E19的区域分别相应于在馈给F3-2中的要素E14和E15(见图14A)。这就是说，关于含于以前传递的馈给中的每条新闻的更新信息是保持不变的。最新近的更新信息含于标明为要素E17的区域中。

在要素E17中，夹在<title>标记之间的行包含关于标题为“一条关于商务活动的消息”的新闻的更新信息。这条新闻的更新日期是“2007年6月10日星期日12:30:00”，它夹在<putDate>标记之间。这个日期与馈给产生的日期(在要素E17中夹在<updated>标志之间)相同。由此可见，在更新标题为“一条关于商务活动的消息”的新闻的同时产生馈给。

在要素E17中，夹在<link>标记之间的区域包含关于存储SIP资源的位置的信息(在“sip:news-business-20070610123000@sip.app.server.example”上)。这就是说，由客户机1-1更新的是标题为“一条关于商务活动的消息”的新闻，并且是由存储在“sip:news-business-20070610123000@sip.app.server.example”上的SIP资源构成的。

如果已经接收到馈给的客户机2-1的用户选择了在馈给F3-3的要素E17中描述的SIP资源，那么，在图13的步骤S53中，客户机2-1就使用INVITE(邀请)请求向持有所讨论资源的客户机1-1发送会话建立请求。如果接收了INVITE(邀请)请求的客户机1-1接受此请求，那么，在步骤S54中，客户机1-1就向客户机2-1发回响应“200 OK”。在步骤S55中，在客户机1-1和客户机2-1之间建立媒体会话。在建立媒体会话之后，客户机2-1通过实时通信获取所关注的内容。

在步骤S56中，客户机2-2通过使用SUCRIBE(订阅)请求向应用服务器200发送关于新闻的馈给订阅请求。在步骤S57中，应用服务器200的馈给传递部分204向客户机2-2发回响应200OK。由于客户机2-2想要被传递的新闻的最新近的馈给是馈给F3-3，在步骤S58中，馈给传递部分204就使用NOTIFY(通知)请求将馈给F3-3传递给客户机2-2。在步骤S59中，已经接收到馈给F3-3的客户机2-2将响应“200 OK”发回给馈给传递部分204。

如果客户机2-2的用户选择在馈给F3-3的要素E17中描述的SIP资源(见图14B)，那么，在步骤S60中，在客户机2-2和持有所述的SIP资源的客户机1-1之间建立SIP会话。在会话期间，客户机2-2获取所关注的资源(在此情况下是新闻)。

如果客户机2-2的用户选择在馈给F3-3的要素E18中描述的Web资源(见图14B)，那么，在步骤S61中，在客户机2-2和应用服务器200的HTTP处理部分201之间建立HTTP(Web)会话。在会话进行期间，客户机2-2获取所关注的资源。

根据上面已说明了其结构和处理程序的第二实施例，新的配置的益处在于补充了第一实施例所提供的效果。例如，存在这样的情况，可由多个以不同的格式(例如，SIP URI和URL)管理的资源来构成单条新闻。将关于这些资源的更新信息的项目放在要传递给客户机的单个馈给之中。这样，客户机就能够获取所想要的资源而不用知道这些资源存储在什么位置上。

[第三实施例]

现在将参照图15到图17来说明本发明的第三实施例。如像第二实施例那样，按照这样的方式来执行第三实施例，这就是以馈给的形式来传递关于新闻的更新信息。第三实施例的特点在于构成新闻的文本数据和视频数据都是用Web服务器来管理的。

在图15中，将Web服务器300、SIP服务器100′、客户机1-1和2-1在网络5上互连起来。客户机1-1的用户是Web资源持有者。客户机2-1的用户订阅由资源持有者所产生或更新的新闻。

Web服务器300是由HTTP处理部分301、数据库302和馈给产生部分303构成的。SIP服务器100’是由馈给传递部分102′和位置管理部分103′构成的。第三实施例的系统配置的特点在于，由Web服务器300产生馈给，并由SIP服务器100′来传递所产生的馈给。由HTTP处理部分301、数据库302和馈给产生部分303进行的处理分别与上述的由图10中HTTP处理部分201、数据库202和馈给产生部分203进行的处理大致相同，在此不再加以讨论。馈给传递部分102′和位置管理部分103′所进行的处理与图1中馈给传递部分102和位置管理部分103所进行的处理基本相同，或者与图10中馈给传递部分204和位置管理部分205所进行的处理相同，在此不再加以讨论。Web服务器300和SIP服务器100’的内部结构基本上与图2所示的结构相同，客户机1-1和2-1的内部结构大致和图3所示的结构相同，因此，不再对这些结构加以说明。

下面将参照图16来说明按照这样的方式来进行的典型步骤：客户机2-1向SIP服务器100’发送馈给订阅请求，然后将包括关于想要资源的更新信息的馈给发送给客户机2-1，客户机2-1实际上根据接收到的资源更新信息获得讨论中的资源。

在步骤S71中，客户机2-1使用SUBSCRIBE(订阅)请求向SIP服务器100′的馈给传递部分102′发送馈给订阅请求。在步骤S72中，馈给传递部分102′将响应“200 OK”发回给客户机2-1。在步骤S73中，馈给传递部分102′通过使用NOTIFY(通知)消息将含有在此时间点上的最新更新信息的馈给传递给客户机2-1。在步骤S74中，已经接收到NOTIFY(通知)请求的客户机2-1将响应“200 OK”发回给馈给传递部分102′。

在步骤S75中，持有Web资源的客户机1-1更新由这些资源构成的新闻。在步骤S76中，客户机1-1使用在HTTP下的POST命令将新闻发送给Web服务器300的HTTP处理部分301。尽管在图16中没有示出，由HTTP处理部分301将附在POST命令上的资源写到数据库302中的适当位置上。在步骤S77中，HTTP处理部分301将响应“200OK”发回给客户机1-1。

在步骤S78中，馈给产生部分303根据在步骤S76上由HTTP处理部分301接收到的POST命令中的描述更新馈给，以便产生馈给F4。将所产生的馈给F4写到数据库302中的适当位置上(见图15)。在步骤S79中，馈给产生部分303向SIP服务器100′的馈给传递部分102′发送包含馈给F4存储位置的信息的馈给更新信息。在步骤S80中，馈给传递部分102'根据接收到的馈给更新信息从数据库302中获取馈给F4。在步骤S81中，馈给传递部分102′在向客户机2-1发送NOTIFY(通知)请求之前，将获取的馈给F4放到NOTIFY(通知)请求的正文中。在步骤S82中，已经接收到NOTIFY(通知)请求的客户机2-1将响应“200OK”发回给馈给传递部分102'。

图17示出了馈给F4的典型描述。在标明为要素E20的区域中包含馈给标题(“The Lasted News”)，馈给标识符(http://www.news.com.example)，馈给更新日期(“2007年6月10日星期日12:30:30”)，馈给副标题(“NewsHeadlines”)，。在标明为要素E21到E23的区域中，夹在<entry>标记之间的正文部分包含关于各条新闻的更新信息。按照时间顺序从下到上示出了夹在<pubDate>标记之间的每条新闻的更新日期。这就是说，最下面的要素E23表示最老的更新日期，随后是位于上面的要素E22和E21，它们示出了较新的新闻的更新日期。

换句话说，在要素E21中的所述的新闻的更新日期是最新近的日期，“2007年6月10日星期日12:30:00”，它夹在<pubDate>标记之间。这个日期和馈给产生日期(在要素E20中它夹在<updated>标记之间)相同。由此可知，在产生馈给F4的同时，更新了含于要素E21中的、由客户机1-1更新的新闻。

要素E21到E23中的每一个都含有夹在<link>标记之间的资源存储位置信息。例如，要素E21具有嵌于其中的“http://www.news.com/business/20070610123000.html”。

如果客户机2-1的用户选择了在馈给F4的要素E21中描述的Web资源，则在图16的步骤S83中，客户机2-1向客户机2-1的HTTP处理部分301发送HTTP请求。一旦接收到HTTP请求，HTTP处理部分301在步骤S84中使用HTTP响应向客户机2-1发送资源。

根据其结构和处理程序已在上面讨论过了的第三实施例，也使用在SIP下的NOTIFY(通知)请求将由Web服务器管理的资源信息发送给客户机。这样，用户就能实时地获取资源更新信息和类似信息。

也根据其结构和处理程序已在上面讨论过了的第三实施例，馈给产生部分203将馈给更新信息通知给馈给传递部分102′。然而，这并非是对本发明的限制。另外的办法是，馈给传递部分102′可以连续监控馈给文件产生的时间，一旦检测到更新，就能从馈给产生部分203获取馈给文件。

根据本发明上述的第一到第三实施例，分别构造了馈给产生部分和馈给传递部分。另外的办法是，可以集成式地形成这两个部分。更具体地说，可以通过对相同的进程进行多线程化来生成馈给产生部分和馈给传递部分。另外的方案是，可以作为不同的进程来生成馈给产生部分和馈给传递部分。

在以相同进程的多线程结构的形式来实现馈给产生部分和馈给传递部分的情况下，这两个部分共用单个的存储器。在将馈给产生部分产生的馈给存储到存储器中时，不需要在馈给产生部分和馈给传递部分之间移动馈给(如在图4的骤S9中那样)。在作为不同的进程来实现馈给产生部分和馈给传递部分的时候，可将放到由馈给产生部分使用的存储器中的内容拷贝到由馈给传递部分使用的存储器之中。如像在多线程运行的情况中那样，这样就不需要在两个部分之间移动馈给了。

那些熟悉工艺技术的人应当了解的是，只要在本发明附后的权利要求或等效条款所规定的范围内，根据设计要求和其它的因素，可以进行各种修改、组合、次级组合和变换。