CN101442554A - 实现内容分发业务互动的方法、服务器及系统 - Google Patents
实现内容分发业务互动的方法、服务器及系统 Download PDFInfo
- Publication number
- CN101442554A CN101442554A CNA2008102185539A CN200810218553A CN101442554A CN 101442554 A CN101442554 A CN 101442554A CN A2008102185539 A CNA2008102185539 A CN A2008102185539A CN 200810218553 A CN200810218553 A CN 200810218553A CN 101442554 A CN101442554 A CN 101442554A
- Authority
- CN
- China
- Prior art keywords
- content
- interaction
- client
- server
- server end
- 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.)
- Pending
Links
Images
Landscapes
- Information Transfer Between Computers (AREA)
Abstract
本发明实施例提供一种实现内容分发业务互动的方法,包括:服务器端接收客户端发送的互动请求消息,所述互动请求消息携带互动内容信息;服务器端解析得到所述互动内容信息,根据所述互动内容信息进行互动。本发明实施例还提供一种服务器及实现内容分发业务互动的系统。本发明实施例中,内容分发业务的互动内容信息携带在客户端发送给服务器端的互动请求消息里,通过服务器端解析获取互动内容信息,使得服务器端与客户端之间的互动得以实现,从而大大丰富了内容分发业务的互动方式。
Description
技术领域
本发明涉及通信领域,尤其是涉及一种实现内容分发业务互动的方法、服务器及系统。
背景技术
随着宽带网络和宽带流媒体应用的兴起,内容分发CD(Content Delivery)作为一种提高网络内容,特别是提高流媒体内容传输的服务质量、节省骨干网络带宽的技术,在国内外得到越来越广泛的应用。
动态内容分发DCD(Dynamic Content Delivery)即是一种常见的内容分发技术,其是为了增强客户端用户的信息浏览体验,通过周期下载或者推送的方式,把用户需要的个性化和定制的内容更新到用户的客户端中。DCD极大地简化了内容发现和内容获得的方式,降低了用户的使用难度,方便用户获得最想要的内容。这些内容通过生动的展现,增加用户的交互性,吸引用户主动浏览更多的相关的内容。
移动广告(MobAd)也是目前应用越来越广的一种内容分发技术,其通过移动媒体传播商业信息,旨在通过这些商业信息影响受传者的态度、意图和行为。与传统广告相比,MobAd具有针对性强、情境性等优势。
发明人在实施本发明的过程中,发现现有的技术方案中,CD服务器端(CDServer)与CD客户端(CD Client)的互动至少存在如下问题:
(1)DCD场景下,现有的DCD内容获取都是基于DCD服务器提供频道列表,并通过订阅频道而获取的;无法对DCD服务器或CP(Content Provider,内容提供商)上可提供的内容进行检索,无法快速的查找到所需要的内容在哪个频道中。
(2)DCD场景下,对于内容而言,DCD客户端只能够接收和订阅CP所提供的内容,而无法对接收的内容进行反馈。DCD CP与DCD服务器并没有为发布的内容提供反馈的机制。
(3)MobAd场景下,客户端通常只能被动接收服务器端发送的广告内容,无法特定需求自定义请求服务器端发送广告内容。
发明人在实现本发明过程中发现,目前的内容分发业务中并没有很好的利用互动这个有利的工具,反应在业务上就是该业务的“订阅-下载/推送”的流程过于简单,并没有体现出该业务在内容上丰富,订阅与获取内容手段丰富的特点。
发明内容
本发明实施例要解决的技术问题在于,提供一种实现内容分发业务互动的方法、服务器及系统,以丰富和扩展内容分发业务的互动方式。
为解决上述技术问题,本发明实施例提供一种实现内容分发业务互动的方法,包括:
服务器端接收客户端发送的互动请求消息,所述互动请求消息携带互动内容信息;
服务器端解析得到所述互动内容信息,根据所述互动内容信息进行互动。
本发明实施例还提供一种服务器,包括:
接收模块,用于接收客户端发送的互动请求消息,所述互动请求消息携带互动内容信息;
解析模块,用于解析得到所述互动内容信息;
互动模块,用于根据所述互动内容信息进行互动。
本发明实施例还提供一种实现内容分发业务互动的系统,包括服务器,所述服务器包括:
接收模块,用于接收客户端发送的互动请求消息,所述互动请求消息携带互动内容信息;
解析模块,用于解析得到所述互动内容信息;
互动模块,用于根据所述互动内容信息进行互动。
本发明实施例具有以下有益的效果:内容分发业务的互动内容信息携带在客户端发送给服务器端的互动请求消息里,通过服务器端解析获取互动内容信息,使得服务器端与客户端之间的互动得以实现,从而大大丰富了内容分发业务的互动方式。
附图说明
图1是本发明实施例实现内容分发业务互动的方法的流程示意图。
图2是本发明实施例一的流程示意图。
图3是本发明实施例二的流程示意图。
图4是本发明实施例三的流程示意图。
图5是本发明实施例四的流程示意图。
图6是本发明实施例五的流程示意图。
图7是本发明实施例六的流程示意图。
图8是本发明实施例七服务器的结构示意图。
图9是本发明实施例八实现内容分发业务互动的系统的结构示意图。
具体实施方式
以下结合附图对本发明实施例进行详细描述。
本发明实施例中,客户端将欲与服务器端之间的互动内容信息,携带在消息(可以是自定义的消息,也可以是现有的消息)中发送给服务器端,服务器端接收该消息后对该消息进行解析,从而获取互动内容信息,再根据互动内容信息里对互动内容的描述,实现业务互动。
请参照图1所示,本发明实施例提供一种实现动态内容分发业务互动的方法,包括:
步骤101,内容分发业务服务器端接收客户端发送的互动请求消息,所述互动请求消息携带互动内容信息;
步骤102,服务器端解析得到所述互动内容信息,根据所述互动内容信息进行互动。
本实施例中,互动请求消息可以是如下形式:
消息 | 执行 | 流向 |
互动请求消息 InteractMessageRequest | 强制 | 客户端→服务器端 |
互动请求消息可以定义如下内容属性:
信息要素 | 实现 | 类型 | 描述 |
Message-Type | 强制 | 字符串 | “互动请求信息”或“InteractMessageRequest” |
Session-ID | 强制 | 字符串 | 会话标识。如果服务器与客户端建立会话,必须要有会话标识。 |
Message-ID | 强制 | 字符串 | 用来区别本消息与其他消息的标识(Interaction)。 |
Content | 强制 | 结构化 | 内容,用来说明本互动内容信息是做什么用的,可以是“互动内容信息”或“InteractionInfo”。例如,如果是“SearchInfo”,则表示该互动内容信息是请求查询的;如果是“AudienceInfo”则表示该互动内容信息是请求反馈用户信息的;如果是“Collection”则表示该互动内容信息是请求添加收藏标识。 |
应当理解,互动请求消息中携带的互动内容信息,体现在上述“Content”部分。作为例举,如果是“SearchInfo”,则表示该互动内容信息是请求查询频道或内容;如果是“AudienceInfo”则表示该互动内容信息是请求反馈用户信息的;如果是“Collection”则表示该互动内容信息是请求添加收藏标识。
上述互动请求消息中所包含的内容属性仅是举例说明,如果包含了消息中的互动内容相关属性,其原理也是相同的。并且互动请求消息可以复用现有DCD消息,复用时可以将相应的互动内容属性添加即可。
以下结合具体实施例进行详细描述。
本发明实施例一:
本实施例提供了一种在DCD环境下,DCD客户端上设置查询关键字,发送到DCD服务器端,由服务器完成相关内容检索与获取的方案。通过该方案,DCD客户端可以完成对所需内容的检索与获取,DCD服务器端可以完成对注册频道内容的检索,也可以完成保存内容的检索。通过这样的查询方式可以让客户端用户方便的检索到所需相关内容,同时也是提供了一种频道的检索方式。
本实施例中,DCD客户端可以在客户端设置查询关键字,通过互动请求消息(查询请求消息),将该关键字发送到DCD服务器端,在服务器上通过对所需要检索的内容进行检索。例如,如果用户需要检索包含“奥运”关键字的频道,那么就在互动请求消息(查询请求消息)中描述所需查询的关键字是“奥运”,查询内容是“频道”。服务器接收到这样的消息后,会在频道列表上查找包含“奥运”关键字的频道,并将结果通过查询响应消息发送给客户端。
在本实施例的场景下,DCD服务器端上已经具有CP注册的频道,并且DCD客户端已经激活注册。DCD客户端可以是已经订阅了一些内容,也可以是已经从DCD服务器端获得一些DCD内容。在这种情况下,DCD客户端需要进行查询频道或内容。
应当理解,本实施例虽以DCD业务为例,但同样适用于MobAd业务,且原理与处理流程均相同。
请参照图2所示,本实施例的具体流程如下:
步骤201,DCD客户端向DCD服务器端发送查询请求消息SerarchMessageRequest;
DCD客户端可以通过客户端应用程序输入查询关键字。该应用程序可以生成查询请求消息,并且客户端保存DCD服务器端的地址信息。客户端生成查询请求消息后,发送到DCD服务器端。该查询请求消息可以是通过SMS短消息或彩信消息发送到DCD服务器端;或者通过HTTP的GET,包裹在信令中,携带到DCD服务器端;也可以是通过DCD的订阅Subscribe方式发送到DCD服务器端。
DCD客户端通过服务器端查询的内容可以是:包含关键字的注册频道有哪些?包含具有关键字的内容有哪些?它们的地址信息等。
本实施例中,查询请求消息(SearchMessageRequest)即前述互动请求消息的具体表现,其内容属性可以是如下形式:
信息要素 | 实现 | 类型 | 描述 |
Message-Type | 强制的 | 字符串 | “查询请求信息”或“SearchMessageRequest” |
Session-ID | 强制的 | 字符串 | 会话标识。如果服务器与客户端建立会话,必须要有会话标识。 |
Message-ID | 强制的 | 字符串 | 用来区别本消息与其他消息的标识(Interaction)。 |
Content(SearchInfo) | 强制的 | 结构化 | 表示该互动内容信息是请求查询的,此处可以添加查询的关键字,并可说明查询的是内容还是频道,例如如果是“Channel”则表示用户请求查询频道。 |
查询请求消息还可以是互动信道上的消息,或者是DCD-3接口上对频道发现(Channel Discovery)消息的扩展,例如,复用频道发现请求ChannelDiscoveryRequest消息,在该消息中携带查询相关互动内容信息。
步骤202,DCD服务器端接收查询请求消息后,解析得到携带在查询请求消息中的互动内容信息。
例如,针对自定义的查询请求消息,DCD服务器端首先解析获知该查询请求消息属于互动请求消息,具体地,可以是解析Message-ID获知标识是互动(Interaction);然后进一步解析该消息的内容Content,获知具体的互动内容信息是请求查询频道或内容,例如,如果同时解析到“Channel”则表示请求查询频道。然后DCD服务器端还会解析出查询关键字。
步骤203,DCD服务器端根据解析的结果,即互动内容信息,进行频道或内容的查询。
例如,根据解析的结果,如果请求查询某频道,则服务器会在频道列表中查询具有关键字描述的频道;如果请求查询某个具体内容,则服务器会在本地查询,也可以在专门保存内容的服务器上进行查询。
步骤204,DCD服务器端将查询的结果发送给DCD客户端。
DCD服务器端将对频道的查询结果或对内容的查询结果通过查询请求响应SearchMessageResponse消息发送给DCD客户端。例如,如果客户端请求查询的是频道,则在SearchMessageResponse消息中会携带该频道的Channel-ID、Channel-name及描述等信息;如果用户查询的是内容,则SearchMessageResponse消息中会携带查询到的内容的描述信息,URL等Content-metadata属性。
SearchMessageResponse消息可以如下定义内容属性:
信息要素 | 实现 | 类型 | 描述 |
Message-Type | 强制的 | 字符串 | 消息类型定义为“SerarchMessageRequest” |
Session-ID | 强制的 | 字符串 | 会话标识。如果服务器与客户端建立会话,必须要有会话标识。 |
Message-ID | 强制的 | 字符串 | 用来区别本消息与其它消息的标识。 |
Channel-Metadata | 条件的 | 字符串 | 此处用来显示查询的结果。如果有查询的频道,则此处显示频道的Channel-ID |
Status | 强制的 | 布尔 | 布尔值,{True|False}。用来显示查询是否有结果。 |
Content-Address | 条件的 | 字符串 | 用来显示内容的保存地址信息。例如URL |
查询请求响应消息还可以是互动信道上的消息,也可以是DCD-3接口上对频道发现响应消息的扩展。查询请求响应消息可以通过短信、彩信、语音、邮件等承载方式发送到DCD服务器。查询请求响应消息中必须包含对查询结果的描述。查询请求查询消息在客户端与服务器之间通过DCD-3接口传递。
以上的消息中所包含的内容属性仅是举例说明,如果包含了消息中的查询相关属性,其原理也是相同的。并且上面的消息可以复用现有DCD消息,复用时可以将相应的查询属性添加即可。
通过本实施例,DCD客户端可以方便的查询DCD服务器端上的频道,或者查询所需内容,丰富了DCD业务的互动方式。
应当理解,本实施例虽以DCD业务为例,但同样适用于MobAd业务,且原理与处理流程均相同。
本发明实施例二:
本实施例提供了一种在DCD环境下,DCD服务器端根据客户端的请求,向客户端发送收视统计消息,获取客户端对某频道或内容的满意度,播放质量,以及用户对内容的评述的方法。通过服务器端与客户端的互动调查,使内容提供商CP能够更好的了解内容的播放效果和用户的收视情况,并且根据获取的收视信息调整内容。
本实施例中,DCD内容提供商可以在DCD服务器上设置满意度和收视情况的调查表,并随同节目内容一起发送到用户,以获取对当前某频道节目的收视情况和用户接收满意度。该调查表可以包括用户的收看内容的起始时间和终止时间,观看的频道ID,观看的效果,用户喜好,评论等收视信息。DCD服务器端可以将调查表以XML的形式,打包到DCD消息中下发给客户端,或者将调查表在内容下发的时候以短消息、彩信、语音、邮件等发送到客户端。客户端接收到包括调查表的消息后会解析,并呈现出来。调查表可以引导用户进入调查表填写界面,类似于短信书写界面。客户端用户通过填写消息,或者进行选择等操作,完成对调查表的填写。然后再将该消息反馈回服务器端。
请参照图3所示,本实施例的具体流程如下:
步骤301,DCD客户端向DCD服务器端发起收视调查请求消息AudienceInfoRequest;
本实施例中,收视调查请求消息AudienceInfoRequest即前述互动请求消息的具体表现,其内容属性可以是如下形式:
信息要素 | 实现 | 类型 | 描述 |
Message-Type | 强制的 | 字符串 | “收视调查请求信息”或“AudienceInfoRequest” |
Session-ID | 强制的 | 字符串 | 会话标识。如果服务器与客户端建立会话,必须要有会话标识。 |
Message-ID | 强制的 | 字符串 | 用来区别本消息与其他消息的标识(Interaction)。 |
Content(AudienceInfo) | 强制的 | 结构化 | 表示该互动内容信息是请求收视调查的。 |
步骤302,DCD服务器端接收收视调查请求消息后,解析得到携带在收视调查请求消息中的互动内容信息;
例如,针对自定义的收视调查请求消息,DCD服务器端首先解析获知该查询请求消息属于互动请求消息,具体地,可以是解析Message-ID获知标识是互动(Interaction);然后进一步解析该消息的内容Content,获知具体的互动内容信息是请求调查收视情况(AudienceInfo),例如,观看内容的起始、终止时间,播放质量等。
步骤303,DCD服务器端根据解析的结果,即互动内容信息,生成收视调查表;
DCD服务器端可以生成用于获得用户信息和收视信息的收视调查表。调查表可以包括用户的收看内容的起始时间和终止时间,观看的频道ID,观看的效果,评论等收视信息,也可以包括某些用户客户端能力、节目喜好等用户信息。
步骤304,DCD服务器端发送调查表到DCD客户端;
调查表可以是以XML的方式通过DCD-3接口上的消息发送给客户端的,也可以是通过短消息、彩信、邮件等发送给客户端的。发送的消息也可以是自定义的消息。
自定义的消息例如收视调查通知消息AudienceInfoNotification:
消息 | 执行 | 流向 |
AudienceInfoNotification | 强制的 | 客户端←服务器端 |
AudienceInfoNotification消息可以如下定义内容属性:
信息要素 | 实现 | 类型 | 描述 |
Message-Type | 强制的 | 字符串 | 消息类型定义为“AudienceInfoNotification” |
Session-ID | 强制的 | 字符串 | 会话标识。如果服务器与客户端建立会话,必须要有会话标识。 |
Message-ID | 强制的 | 字符串 | 用来区别本消息与其它消息的标识。 |
AudienceInfo | 强制的 | 结构化 | 用户信息。此处为多个属性的集合,例如观看内容的起始、终止时间,用户评价、播放质量等 |
AudienceInfo的内容属性可以是以下形式:
信息要素名称 | 描述 | 数据类型 | 在DCD-3消息中使用 | 在其他消息中使用 |
AudienceInfo | 收视调查 | 结构化 | 强制的 | 可选的 |
Start-timeEnd-timeSubscription-timeContent-qualityContent-typeApprove-values:0-yes1-NO用户信息Validity-periodDevice-capabilityUser-typeUser-suggest |
本实施例中,DCD服务器端通过AudienceInfoNotification消息下发调查表到DCD客户端。该调查表包括了多个属性。其中AudienceInfo属性又包括了用户收视调查和用户信息两部分。收视调查包括开始与结束时间(Start-time、End-time)、订阅时长(Subscription-time)、内容质量(Content-quality)、内容类型(Content-type)、满意度(Approve-values)等;用户信息部分包括:订阅有效期(Validity-period)、设备能力信息(Device-capability)、用户类型(User-type)和用户建议(User-suggest)等。
以上均为举例说明,如有类似属性包含在消息中原理也是一致的。
步骤305,客户端处理服务器发送来的调查表;
客户端接收到调查表后,根据调查表的内容进行填写。客户端可以将用户引导到填写界面,类似短消息界面。填写的内容一部分需要用户填写,一部分需要客户端自动输入。例如观看内容的起始与结束时间由客户端填入,客户端设备能力也由客户端填入;而内容质量与用户建议可以由用户填写。
步骤306,客户端发送填写后的调查表;
客户端用户填写完毕调查表后可以用AudienceInfoReport消息携带发送到服务器,也可以复用其它消息,上传到DCD服务器,或通过短消息、彩信等发送到服务器。
AudienceInfoReport消息可以如下定义内容属性:
信息要素 | 实现 | 类型 | 描述 |
Message-Type | 强制的 | 字符串 | 消息类型定义为“AudienceInfoReport” |
Session-ID | 强制的 | 字符串 | 会话标识。如果服务器与客户端建立会话,必须要有会话标识。 |
Message-ID | 强制的 | 字符串 | 用来区别本消息与其它消息的标识。 |
AudienceInfo | 强制的 | 结构化 | 经过终端填写后的用户信息。此处为多个属性的集合,例如观看内容的起始、终止时间,用户评价、播放质量等 |
步骤307,DCD服务器将调查结果发送到CP或其它服务器;
DCD服务器再次利用AudienceInfoReport消息发送到CP或需要统计数据的服务器上去。
通过本实施例,客户端与服务器端能够针对收视情况进行互动调查,服务器与CP可以得到客户端对内容的反馈评价与该内容的收视率情况、用户接收方式等用户收视信息。这些信息可以实时的反应出当前网内用户的内容接收情况,为服务器或CP的内容发送提供好的指导作用。因此本实施例丰富了DCD业务的互动方式。
应当理解,本实施例虽以DCD业务为例,但同样适用于MobAd业务,且原理与处理流程均相同。
本发明实施例三:
本实施例提供了一种在DCD环境下,DCD服务器端根据客户端的请求,向客户端发送调查信息表,获取客户端收视信息于用户信息的方法。通过服务器与客户端用户的互动调查,使内容提供商CP能够更好的了解内容的播放效果和用户的收视情况,并且根据获取的用户信息为用户提供符合用户个性化的内容订阅。
本实施例中,DCD内容提供商在将频道注册到DCD服务器上时,针对每个频道提供一份收视信息调查表。该调查表可以包括用户的收看内容的起始时间和终止时间,观看的频道ID,观看的效果,用户喜好,评论等收视信息。当客户端发送收视调查请求消息时,服务器可以将调查表发送到客户端。这样的好处是更灵活的掌握用户的信息和收视信息。
同时,DCD内容提供商也可以只提供一份收视信息调查表给DCD服务器。当客户端发送收视调查请求消息时,服务器就将收视信息调查表关联到需要调查的频道上,发送给客户端。
内容提供商发送调查表到服务器的消息可以是通过XML的形式,或自定义的消息格式下发。下发的消息也可以是复用DCD消息,将调查的内容包括在DCD消息中。
请参照图4所示,本实施例的具体流程如下:
步骤401,DCD客户端向DCD服务器端发起收视调查请求消息AudienceInfoRequest;
本实施例中,收视调查请求消息AudienceInfoRequest即前述互动请求消息的具体表现。
本实施例中所采用的消息还可以复用现有DCD消息。自定义消息AudienceInfoRequest形式及内容属性与实施例二中类似,此处不再赘述。
步骤402,DCD服务器端接收收视调查请求消息后,解析得到携带在收视调查请求消息中的互动内容信息;
例如,针对自定义的收视调查请求消息,DCD服务器端首先解析获知该查询请求消息属于互动请求消息,具体地,可以是解析Message-ID获知标识是互动(Interaction);然后进一步解析该消息的内容Content,获知具体的互动内容信息是请求调查收视情况(AudienceInfo),例如,观看内容的起始、终止时间,播放质量等。
步骤403,DCD服务器端将互动内容信息发送给DCD内容提供商或其他服务器(例如用于统计的服务器)。
DCD服务器端可以通过AudienceInfoRequest消息将互动内容信息发送给DCD内容提供商或其他服务器。
步骤404,DCD内容提供商或其他服务器根据接收的互动内容信息生成收视调查表;
DCD内容提供商或其他服务器可以生成用于获得用户信息和收视信息的收视调查表。调查表可以包括用户的收看内容的起始时间和终止时间,观看的频道ID,观看的效果,评论等收视信息,也可以包括某些用户客户端能力、节目喜好等用户信息。DCD内容提供商或其他服务器可以根据不同的频道生成不同的调查表,也可以只生成一份调查表。
步骤405,DCD内容提供商或其他服务器将调查表发送到DCD服务器端上;
步骤406,DCD服务器端将调查表与频道、内容等进行匹配;
调查表可以与频道进行匹配,以便连同内容一并发出;调查表也可以单独发送,不与内容一起发送。
步骤407~410与实施例二中步骤304~307类似,此处不再赘述。
通过本实施例,客户端与服务器端能够针对收视情况进行互动调查,服务器与CP可以得到客户端对内容的反馈评价与该内容的收视率情况、用户接收方式等用户收视信息。这些信息可以实时的反应出当前网内用户的内容接收情况,为服务器或CP的内容发送提供好的指导作用。因此本实施例丰富了DCD业务的互动方式。
应当理解,本实施例虽以DCD业务为例,但同样适用于MobAd业务,且原理与处理流程均相同。
本发明实施例四:
本实施例通过客户端对服务器端上的内容增加索引标识来记录的方式,使得客户端可以收藏某些内容和频道,并且可以通过设置的标识方便的查找到收藏的内容。
本实施例中,客户端订阅的频道中的某些内容希望能够保留或做出标记进行收藏时,可以在内容上增加一个收藏的标识,并在服务器上建立一个“收藏”的文件夹,里面放置用户收藏过的内容标识。通过在内容上增加收藏标识,服务器自动将该内容与用户的收藏夹做关联,使得用户在下次观看该内容的时候可以方便的查找收藏的内容。
在本实施例涉及的场景下,DCD客户端收藏服务器上的内容,首先需要订阅该频道。在此基础之上,可以收藏频道中的内容。
请参照图5所示,本实施例的具体流程如下:
步骤501,DCD客户端向DCD服务器端发送收藏请求消息FavoriteRequest;
发送收藏请求消息可以是DCD已有消息,也可以是自定义的消息类型。自定义的消息如:
消息 | 执行 | 流向 |
FavoriteRequest | 强制的 | 客户端→服务器端 |
FavoriteRequest消息可以如下定义内容属性:
信息要素 | 实现 | 类型 | 描述 |
Message-Type | 强制的 | 字符串 | 消息类型定义为“FavoriteRequest” |
Session-ID | 强制的 | 字符串 | 会话标识。如果服务器与客户端建立会话,必须要有会话标识。 |
Message-ID | 强制的 | 字符串 | 用来区别本消息与其它消息的标识。 |
Content-Id | 强制的 | 字符串 | 区别内容的标识。 |
Favorite-tag | 强制的 | 布尔 | 用来标识收藏内容的标识。取值:{True|False},取值为True时,将内容添加收藏标识,取值为False时,取消原有收藏内容。 |
本实施例中,收藏请求消息FavoriteRequest即前述互动请求消息的具体表现。
步骤502,DCD服务器端接收收藏请求消息后,解析得到携带在收藏请求消息中的互动内容信息。
例如,针对自定义的收藏请求消息,DCD服务器端首先解析获知该收藏请求消息属于互动请求消息,具体地,可以是解析Message-ID获知标识是互动(Interaction);然后进一步解析该消息的内容Content,获知具体的互动内容信息是请求收藏内容。
步骤503,DCD服务器端根据解析的结果,即互动内容信息,为某内容添加收藏标识。
服务器在收到DCD Client发来的带有收藏标识的消息后,根据消息中的Content-id将内容的Favorite-tag标识修改为True。作为内容元数据的Favorite-tag在初始的时候值为False。例如,DCD服务器收到DCD客户端的FavoriteRequest消息后,并且发现Favortie-tag值为True,则根据消息中的Content-id,将该内容的Favorite-tag修改为True。这样该内容就被标记为收藏了。
服务器可以同时建立一个属于该用户的“收藏文件夹”,并将该用户标记了收藏标识的内容信息保存在该“收藏文件夹”中,例如保存该内容连接。
步骤504,DCD服务器向DCD Client发送收藏请求应答消息;
DCD服务器向DCD客户端发送收藏请求应答消息。例如FavoriteReport消息,FavoriteReport消息可以如下定义内容属性:
信息要素 | 实现 | 类型 | 描述 |
Message-Type | 强制的 | 字符串 | 消息类型定义为“FavoriteReport” |
Session-ID | 强制的 | 字符串 | 会话标识。如果服务器与客户端建立会话,必须要有会话标识。 |
Message-ID | 强制的 | 字符串 | 用来区别本消息与其它消息的标识。 |
Status | 强制的 | 布尔 | 取值:{True|False} |
Reason | 可选的 | 字符串 | 如果返回的状态值为False,则说明原因。可以是任意形式的文档描述。 |
FavoriteReport消息中包含Status属性和Reason属性。Status属性表示收藏标识添加的成功与否;Reason属性用来在添加收藏标识为False的时候进行说明。
上面的两条消息只是一个举例说明,也可以复用DCD的其它消息来用于收藏的请求与应答,但是必须包括收藏标识“Favorite-tag”。这里的“Favorite-tag”也是一个举例,如果其它的属性同样可以标识收藏,则也属于本发明的保护范围。
通过本实施例,服务器端可以根据客户端的请求,为频道中某些内容添加收藏标记,便于下次访问。由此给DCD业务增加了新的互动方式。
应当理解,本实施例虽以DCD业务为例,但同样适用于MobAd业务,且原理与处理流程均相同。
本发明实施例五:
本实施例通过客户端对服务器端上的内容增加索引标识来记录的方式,使得客户端可以收藏某些内容和频道,并且可以通过设置的标识方便的查找到收藏的内容。
本实施例中,客户端订阅的频道中的某些内容希望能够保留或做出标记进行收藏时,可以在内容上增加一个收藏的标识,并在服务器上建立一个“收藏”的文件夹,里面放置用户收藏过的内容标识。通过在内容上增加收藏标识,服务器自动将该内容与用户的收藏夹做关联,使得用户在下次观看该内容的时候可以方便的查找收藏的内容。
在本实施例涉及的场景下,DCD客户端收藏服务器上的内容,首先需要订阅该频道。在此基础之上,可以收藏频道中的内容。
请参照图6所示,本实施例的具体流程如下:
步骤601,DCD客户端向DCD服务器端发送收藏请求消息FavoriteRequest;
发送收藏请求消息可以是DCD已有消息,也可以是自定义的消息类型,例如FavoriteRequest。收藏请求消息FavoriteRequest即前述互动请求消息的具体表现。自定义消息形式及内容属性与实施例四中类似,此处不再赘述。
步骤602,DCD服务器端接收收藏请求消息后,解析得到携带在收藏请求消息中的互动内容信息。
例如,针对自定义的收藏请求消息,DCD服务器端首先解析获知该收藏请求消息属于互动请求消息,具体地,可以是解析Message-ID获知标识是互动(Interaction);然后进一步解析该消息的内容Content,获知具体的互动内容信息是请求收藏内容。
步骤603,DCD服务器端根据解析的结果,即互动内容信息,为某内容添加收藏标识。
服务器在收到DCD Client发来的带有收藏标识的消息后,根据消息中的Content-id将内容的Favorite-tag标识修改为True。作为内容元数据的Favorite-tag在初始的时候值为False。例如,DCD服务器收到DCD客户端的FavoriteRequest消息后,并且发现Favortie-tag值为True,则根据消息中的Content-id,将该内容的Favorite-tag修改为True。这样该内容就被标记为收藏了。
步骤604,DCD服务器向DCD Client发送收藏请求应答消息;
DCD服务器向DCD客户端发送收藏请求应答消息。
与实施例四不同,本实施例中,将“收藏文件夹”建立在客户端上。服务器在客户端建立收藏文件夹,并将收藏请求应答消息中携带的URL和内容信息保存在收藏文件夹中。
应当理解,本实施例虽以DCD业务为例,但同样适用于MobAd业务,且原理与处理流程均相同。
本发明实施例六:
本实施例提供在移动广告业务(MobAd)下实现内容分发的互动方法,使服务器端可向不同能力客户端发送广告内容。
客户端能力是指,客户端能够正常接收和使用多媒体业务的一种属性,例如是否能够接收和使用文本、图片、或视频等。
在移动广告业务场景下,客户端为移动广告业务使能装置MobAd deviceenabler,服务器端为移动广告业务使能网MobAd enabler network。
请参照图7所示,本实施例的具体流程如下:
步骤701,客户端向服务器端发送广告内容请求消息AdContentRequest;
发送广告内容请求消息可以是已有消息,也可以是自定义的消息类型。自定义的消息如:
消息 | 执行 | 流向 |
AdContentRequest | 强制的 | 客户端→服务器端 |
AdContentRequest消息可以如下定义内容属性:
信息要素 | 实现 | 类型 | 描述 |
Message-Type | 强制的 | 字符串 | 消息类型定义为“AdContentRequest” |
Session-ID | 强制的 | 字符串 | 会话标识。如果服务器与客户端建立会话,必须要有会话标识。 |
Message-ID | 强制的 | 字符串 | 用来区别本消息与其它消息的标识。 |
AdContentInfo | 强制的 | 结构化 | 表示该互动内容信息是请求发送广告内容,此处可以添加客户端能力信息,表示客户端具备接收和使用哪种广告内容,例如“image”表示客户端可以接收和使用图片形式的广告内容 |
本实施例中,广告内容请求消息AdContentRequest即前述互动请求消息的具体表现。
步骤702,服务器端接收广告内容请求消息后,解析得到携带在广告内容请求消息中的互动内容信息。
例如,针对自定义的广告内容请求消息,服务器端首先解析获知该收藏请求消息属于互动请求消息,具体地,可以是解析Message-ID获知标识是互动(Interaction);然后进一步解析该消息的内容Content,获知具体的互动内容信息是请求发送广告内容。服务器还会解析出客户端的能力。
步骤703,服务器端根据解析的结果,即互动内容信息,进行广告内容的查询。
例如,根据解析的结果,如果请求发送餐饮类广告,则服务器会查找餐饮类广告内容;服务器会在本地查询,也可以在专门保存内容的服务器上进行查询。
如果互动内容信息中包含客户端能力,服务器解析出来后,在查询相关广告内容时,会根据客户端的能力查找与之匹配的广告内容。例如,客户端请求发送餐饮类广告内容,自身的能力是可以支持文本和图片,则服务器将在所有餐饮类广告内容查找出文本和图片格式的广告内容。
步骤704,服务器端将广告内容发送给客户端。
服务器端将广告内容通过广告内容请求响应AdContentResponse消息发送给客户端。如果在广告内容请求消息中还包含了客户端能力,则此处的广告内容是服务器查找出的与客户端能力相匹配的广告内容。
应当理解,本实施例虽以MobAd业务为例,但同样适用于DCD业务,且原理与处理流程均相同。
本发明实施例七:
请参照图8所示,本实施例提供一种服务器,包括:
接收模块81,用于接收客户端发送的互动请求消息,所述互动请求消息携带互动内容信息;
解析模块82,用于解析得到所述互动内容信息;
互动模块83,用于根据所述互动内容信息进行互动。
进一步的,所述互动模块83是查询模块,用于在频道列表中查询具有关键字描述的频道,或者在本地查询查询内容,或者在保存内容的服务器上查询内容。
进一步的,所述互动模块83是收视调查模块,所述收视调查模块进一步包括:
生成模块,用于生成收视调查表;
收发模块,用于将所述收视调查表发送到客户端,并在客户端处理完毕后接收所述收视调查表。
所述收视调查模块还包括:
频道匹配模块,用于在所述收发模块将所述收视调查表发送到客户端之前,将所述收视调查表与频道进行匹配。
进一步的,所述互动模块83是收藏模块,所述收藏模块进一步包括:
添加模块,用于给内容添加收藏标识;
存储模块,用于将添加了收藏标识的内容或者所述内容的连接进行存储。
进一步的,所述互动模块83是广告发送模块,用于查找所需的广告内容,并将所述广告内容发送到客户端。
所述广告发送模块还包括:
能力匹配模块,用于将查找的广告内容与客户端能力进行匹配。
本发明实施例八:
请参照图9所示,本实施例提供一种实现内容分发业务互动的系统,包括服务器92,所述服务器92包括:
接收模块,用于接收客户端91发送的互动请求消息,所述互动请求消息携带互动内容信息;
解析模块,用于解析得到所述互动内容信息;
互动模块,用于根据所述互动内容信息进行互动。
本发明实施例中,内容分发业务的互动内容信息携带在客户端发送给服务器的互动请求消息里,通过服务器解析获取互动内容信息,使得服务器与客户端之间的互动得以实现,从而大大丰富了内容分发业务的互动方式。
应当理解的是,以上实施例中,虽然是在DCD业务或移动广告MobAd业务场景下,但这并不是对本发明做出的限制。任何以内容分发业务为内容的领域或场合,本发明的原理、方式均可适用。
Claims (18)
1、一种实现内容分发业务互动的方法,包括:
服务器端接收客户端发送的互动请求消息,所述互动请求消息携带互动内容信息;
服务器端解析得到所述互动内容信息,根据所述互动内容信息进行互动。
2、根据权利要求1所述的方法,其特征在于:当所述互动内容信息是查询频道或查询内容时,服务器端根据所述互动内容信息进行互动具体包括:
如果所述互动内容信息是查询某频道并包含关键字,则服务器端在频道列表中查询具有关键字描述的频道;
如果所述互动内容信息是查询内容,则服务器端在本地查询,或在保存内容的服务器上进行查询。
3、根据权利要求2所述的方法,其特征在于:还包括:
服务器端将查询结果发送给客户端。
4、根据权利要求1所述的方法,其特征在于:当所述互动内容信息是收视调查时,服务器端根据所述互动内容信息进行互动具体包括:
服务器端根据解析的结果,生成收视调查表;
服务器端将所述收视调查表发送到客户端;
服务器端在客户端处理完毕后接收所述收视调查表。
5、根据权利要求4所述的方法,其特征在于:还包括:
服务器端发送所述客户端处理完毕的收视调查表到内容提供商或用于统计的服务器。
6、根据权利要求1所述的方法,其特征在于:当所述互动内容信息是收视调查时,服务器端根据所述互动内容信息进行互动具体包括:
服务器端将所述互动内容信息发送给内容提供商或用于统计的服务器;
服务器端接收内容提供商或统计服务器生成并反馈的收视调查表;
服务器端将所述收视调查表发送到客户端;
服务器端在客户端处理完毕后接收所述收视调查表。
7、根据权利要求6所述的方法,其特征在于:所述服务器端将所述收视调查表发送到客户端之前,还包括:
服务器端将所述收视调查表与频道进行匹配。
8、根据权利要求1所述的方法,其特征在于:当所述互动内容信息是收藏内容时,服务器端根据所述互动内容信息进行互动具体包括:
服务器端根据解析的结果,为内容添加收藏标识;
服务器端将添加了收藏标识的内容或者所述内容的连接进行存储。
9、根据权利要求1所述的方法,其特征在于:当所述互动内容信息是发送广告内容时,服务器端根据所述互动内容信息进行互动具体包括:
服务器端根据解析的结果,查找所需的广告内容;
服务器端将所述广告内容发送到客户端。
10、根据权利要求9所述的方法,其特征在于:如果所述互动内容信息中还包括客户端能力,则服务器端在查找的所需的广告内容中进一步确定与客户端能力相匹配的广告内容。
11、一种服务器,其特征在于:包括:
接收模块,用于接收客户端发送的互动请求消息,所述互动请求消息携带互动内容信息;
解析模块,用于解析得到所述互动内容信息;
互动模块,用于根据所述互动内容信息进行互动。
12、根据权利要求11所述的服务器,其特征在于:所述互动模块是查询模块,用于在频道列表中查询具有关键字描述的频道,或者在本地查询查询内容,或者在保存内容的服务器上查询内容。
13、根据权利要求11所述的服务器,其特征在于:所述互动模块是收视调查模块,所述收视调查模块进一步包括:
生成模块,用于生成收视调查表;
收发模块,用于将所述收视调查表发送到客户端,并在客户端处理完毕后接收所述收视调查表。
14、根据权利要求13所述的服务器,其特征在于:所述收视调查模块还包括:
频道匹配模块,用于在所述收发模块将所述收视调查表发送到客户端之前,将所述收视调查表与频道进行匹配。
15、根据权利要求11所述的服务器,其特征在于:所述互动模块是收藏模块,所述收藏模块进一步包括:
添加模块,用于给内容添加收藏标识;
存储模块,用于将添加了收藏标识的内容或者所述内容的连接进行存储。
16、根据权利要求11所述的服务器,其特征在于:所述互动模块是广告发送模块,用于查找所需的广告内容,并将所述广告内容发送到客户端。
17、根据权利要求16所述的服务器,其特征在于:所述广告发送模块还包括:
能力匹配模块,用于将查找的广告内容与客户端能力进行匹配。
18、一种实现内容分发业务互动的系统,其特征在于:包括服务器,所述服务器包括:
接收模块,用于接收客户端发送的互动请求消息,所述互动请求消息携带互动内容信息;
解析模块,用于解析得到所述互动内容信息;
互动模块,用于根据所述互动内容信息进行互动。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNA2008102185539A CN101442554A (zh) | 2008-10-17 | 2008-10-17 | 实现内容分发业务互动的方法、服务器及系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNA2008102185539A CN101442554A (zh) | 2008-10-17 | 2008-10-17 | 实现内容分发业务互动的方法、服务器及系统 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN101442554A true CN101442554A (zh) | 2009-05-27 |
Family
ID=40726791
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNA2008102185539A Pending CN101442554A (zh) | 2008-10-17 | 2008-10-17 | 实现内容分发业务互动的方法、服务器及系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101442554A (zh) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102970358A (zh) * | 2012-11-08 | 2013-03-13 | 百度在线网络技术(北京)有限公司 | 网盘中移动客户端的本地缓存的控制方法和装置 |
WO2013034012A1 (zh) * | 2011-09-05 | 2013-03-14 | 腾讯科技(深圳)有限公司 | 实现微博消息收藏的方法、系统、微博客户端和存储介质 |
CN103581148A (zh) * | 2012-08-07 | 2014-02-12 | 腾讯科技(深圳)有限公司 | 收藏网站资源的方法、装置及终端 |
WO2015027838A1 (en) * | 2013-08-28 | 2015-03-05 | Tencent Technology (Shenzhen) Company Limited | Method and systems for providing media content |
US9262041B2 (en) | 2010-03-16 | 2016-02-16 | Nokia Technologies Oy | Methods and apparatus for determining a selection region |
-
2008
- 2008-10-17 CN CNA2008102185539A patent/CN101442554A/zh active Pending
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9262041B2 (en) | 2010-03-16 | 2016-02-16 | Nokia Technologies Oy | Methods and apparatus for determining a selection region |
WO2013034012A1 (zh) * | 2011-09-05 | 2013-03-14 | 腾讯科技(深圳)有限公司 | 实现微博消息收藏的方法、系统、微博客户端和存储介质 |
CN102984187A (zh) * | 2011-09-05 | 2013-03-20 | 腾讯科技(深圳)有限公司 | 实现微博消息收藏的方法和系统 |
US20130346529A1 (en) * | 2011-09-05 | 2013-12-26 | Tencent Technology (Shenzhen) Company Limited | Method, device and system for adding micro-blog message as favorite |
CN103581148A (zh) * | 2012-08-07 | 2014-02-12 | 腾讯科技(深圳)有限公司 | 收藏网站资源的方法、装置及终端 |
CN103581148B (zh) * | 2012-08-07 | 2018-09-04 | 腾讯科技(深圳)有限公司 | 收藏网站资源的方法、装置及终端 |
CN102970358A (zh) * | 2012-11-08 | 2013-03-13 | 百度在线网络技术(北京)有限公司 | 网盘中移动客户端的本地缓存的控制方法和装置 |
CN102970358B (zh) * | 2012-11-08 | 2016-06-15 | 百度在线网络技术(北京)有限公司 | 网盘中移动客户端的本地缓存的控制方法和装置 |
WO2015027838A1 (en) * | 2013-08-28 | 2015-03-05 | Tencent Technology (Shenzhen) Company Limited | Method and systems for providing media content |
US9716750B2 (en) | 2013-08-28 | 2017-07-25 | Tencent Technology (Shenzhen) Company Limited | System for providing content from servers based on user responses to content inquiries |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP1536352B1 (en) | System for accessing content items over a network | |
US11812075B2 (en) | Enhanced service compatibility with clients | |
CN102724327B (zh) | 用于浏览器的实时网页浏览服务提供系统和方法 | |
CN102137291B (zh) | 一种广告选择方法及一种互联网协议电视iptv平台 | |
CN101267589B (zh) | 实现互动业务的系统及方法 | |
US20210133825A1 (en) | Secondary content delivery system | |
CN101576930A (zh) | 把由第一用户观看的视频内容项的关键帧发布到第二用户 | |
CN101969546A (zh) | 提供电子节目单、广告发布以及广告呈现的方法和装置 | |
US9208517B1 (en) | System for and method of generating advertising inventory by marketers sharing content with others | |
CN101217642A (zh) | 发送预览内容的方法和接收预览内容的方法与装置 | |
US11178433B2 (en) | Methods and systems for dynamic routing of content using a static playlist manifest | |
KR100367714B1 (ko) | 멀티미디어 컨텐츠와 타겟 광고의 동적 결합 기법을사용한 인터넷 방송 시스템 및 방법 | |
CN102117458A (zh) | 广告服务实现方法、装置和系统 | |
CN103081461A (zh) | 用于提供流媒体节目和目标广告的方法和装置 | |
CN101656688B (zh) | 一种即时消息的展示方法、系统和装置 | |
CN101442554A (zh) | 实现内容分发业务互动的方法、服务器及系统 | |
WO2002032025A1 (en) | Internet broadcast system | |
CN114631324B (zh) | 在流内容中实时递送目标内容的系统和方法 | |
KR101310900B1 (ko) | 서비스 정보 제공 방법, 서비스 정보 제공 시스템 및 서비스 정보 수신 방법 | |
US20240056627A1 (en) | Content delivery network utilizing dynamically assembled adaptive bitrates segments | |
WO2012131708A2 (en) | Video messaging and mailing service | |
CN102508893A (zh) | 一种视频多媒体搜索服务应用系统和检索方法 | |
WO2009073715A2 (en) | Method and system for distributing media | |
CN112243102A (zh) | 公告通知方法、装置、终端设备和存储介质 | |
KR20090039041A (ko) | Rss를 이용한 iptv 보드캐스팅 서비스 시스템 및방법 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C12 | Rejection of a patent application after its publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20090527 |