CN103563314A - 用于被动通信服务的系统和方法 - Google Patents

Abstract

通过分析用户活动日志，获得用于诸如交谈服务等服务的第一用户的被动存在信息。这在收到对第二用户的请求时执行。因此，能够获得轻量级存在信息而不要求在常规因特网协议多媒体服务(IMS)环境中要求的更高开销。此类轻量级存在特征能够允许实现诸如允许用户更新交谈对象的交谈服务等其它服务。用户能够侦听特定交谈对象的更新，由此提供模拟实时推送体验。

Description

用于被动通信服务的系统和方法

技术领域

本公开内容一般涉及在通信网络上的用户之间提供被动存在和交谈服务的系统和方法。

背景技术

存在和交谈是在公共因特网和电信网络两者中的两个重要通信服务。通过使用IP多媒体子系统(IMS)、会话启动协议(SIP)或其它基于会话的协议，大部分现有存在和交谈服务在网络中产生相当大的业务流。处理这些开销网络业务要求额外的系统容量，这增大了在运营商网络中部署基于IMS的存在或交谈服务的总成本。

代表性状态传送(REST)是由启动到服务器的请求的客户端、处理请求并返回适当响应的服务器组成的软件体系结构的样式。请求和响应围绕资源的表示的传送构建。资源的表示一般情况下是表现资源的当前状态的消息或文档。在任何特定时间，客户端能够等待未决请求的响应或者“静止”。静止状态的客户端能够与其用户交互，但在服务器上或者在网络上不产生负载，也不消耗每客户端存储空间。在请求之间在服务器上不存储会话状态或客户端上下文。符合REST约束的体系结构称为具REST性。

目前，通信网络空间中不存在开放标准组织支持的提供用于轻量型、无状态存在和交谈服务的机制。

相应，应容易领会的是，具有用于通过使用被动方案，降低存在和交谈服务生成的网络业务流和利用的网络资源的解决方案将是有利的。

发明内容

本发明的目的是消除或减轻现有技术的至少一个缺点。

本文中公开的是使用具REST性方案构建，要求最小量的网络业务和资源的存在和交谈服务。

在本发明的第一方面，提供了一种用于初始化通信网络中用户之间交谈服务的方法，包括以下步骤：接收来自第一用户装置的启动与第二用户装置的交谈的请求；识别与收到的请求相关联的交谈对象；将包括与交谈对象相关联的标识符的邀请发送到第二用户装置；以及接收来自第一用户装置对交谈对象的更新通知的侦听请求。识别交谈对象的步骤包括确定是否存在与第一用户和第二用户相关联的交谈对象。响应交谈对象不存在，能够创建与第一用户和第二用户相关联的交谈对象。能够将与交谈对象相关联的标识符发送到第一用户装置。邀请能够是SMS-0消息。方法还能够包括将与交谈对象相关联的交谈历史发送到第一用户装置或第二用户装置至少之一的步骤。方法还能够包括响应来自第二用户装置的交谈更新的接收，将收到的侦听请求的回复传送到第一用户装置的步骤。

在本发明的第二方面，提供了一种用于更新通信网络中用户之间交谈的方法，包括以下步骤：接收来自第一用户装置对交谈对象的更新通知的侦听请求；接收来自第二用户的与交谈对象相关联的消息；根据收到的消息，更新交谈对象；以及响应更新交谈对象，将收到的侦听请求的回复传送到第一用户。收到的侦听请求的回复能够包括从第二用户收到的消息。方法还能够包括接收来自第二用户装置的对交谈对象的更新通知的侦听请求的步骤。能够传送从第二用户装置收到的侦听请求的回复，确认根据收到的消息对交谈对象的更新。更新交谈对象的步骤能够包括在与交谈对象相关联的交谈历史中存储收到的消息。方法还能够包括响应传送回复，接收来自第一用户装置对交谈对象的更新通知的更新的侦听请求的步骤。收到的侦听请求能够是长轮询请求消息。

在本发明的另一方面，提供了一种交谈系统，包括：存储器，用于存储与第一用户和第二用户相关联的交谈对象；通信接口，用于接收来自第一用户的启动与第二用户的交谈的请求和用于接收来自第一用户的对交谈对象的更新通知的侦听请求；以及处理器，用于识别与收到的请求相关联的交谈对象，用于指示通信接口传送邀请，向第二用户指示识别的交谈对象，以及用于响应来自第二用户的交谈更新的接收，传送收到的侦听请求的回复。处理器能够确定与第一用户和第二用户相关联的交谈对象是否存在存储器中。处理器能够响应与第一用户和第二用户相关联的交谈对象不存在，在存储器中创建交谈对象。通信接口能够接收来自第二用户的消息，并且响应接收消息，处理器能够更新交谈对象。收到的侦听请求的回复能够包括交谈更新。收到的侦听请求能够是长轮询请求消息。

在结合附图查看以下本发明特定实施例的说明中，本领域的技术人员将明白本发明的其它方面和特性。

附图说明

现在将通过仅限于示例的方式，参照附图描述本发明的实施例，其中：

图1是示出基于REST的存在和交谈服务的体系结构视图；

图2是示出示例存在服务的调用流程；

图3是在移动装置上显示的存在状态的示例；

图4是示出示例交谈服务的调用流程；

图5是示出用于初始化交谈服务的方法的流程图；

图6是示出用于更新交谈服务的方法的流程图；以及

图7是示出本发明的示例节点的框图。

具体实施方式

参照图1，提议的服务包含三个主要功能：通用Web服务功能(UWF) 102、存在功能(PF) 104和交谈功能(CF) 106。UWF 102、PF 104和CF 106能够驻留在通信网络100中诸如基于REST的存在和交谈服务(RPCS) 108等单个节点上，或者能够分布在网络中的多个节点。每个功能能够是由硬件执行的一个或多个软件模块或应用代码组成的框架。

UWF 102是绑定到诸如服务注册、简档(profile)管理等更低级电信功能的API容器。UWF 102向web门户110和客户端应用112提供REST API。它也能够为通过访问鉴权和授权应用服务器(AUTH AS) 114提出服务请求的客户端提供鉴权和授权。

PF 104执行代理职责，在每订户基础上在文件系统(FS) 116中更新和记录客户端应用112执行的活动。它也能够允许客户端检索过去活动的历史。PF 104具有基于其活动历史确定用户的存在状态的逻辑和如操作员或客户端设置的规则或策略集。

CF 106为参与用户提供与交谈相关联的信息。它在交谈中涉及的所有参与者/用户/用户装置之间交换信息。它也能够在文件系统116中为交谈期间交换的消息编排索引和存储消息。它提供了允许用户检索和查看交谈历史的方式。

基于REST的存在和交谈服务提供了允许经3PP鉴权应用服务器进行鉴权和授权的机制。短消息服务中心(SMS-C) 118能够用于发送用于交谈邀请的SMS通知。FS 116能够用于网络的中央数据存储库，用于为向网络预订的每个用户存储与交谈和存在有关的信息。

本领域技术人员将领会，为清晰和可读性起见，本公开内容涉及可交换的用户和参与者。将领会的是，消息由与用户相关联的用户装置发送和接收。

图2示出用于本发明的存在服务的调用流程的一示例实施例。本领域技术人员将领会，此示例涉及RPCS 108的UWF 102和PF 104，然而，为简明起见，将忽略在UWF 102与PF 104之间通信和交互有关的具体细节。用户A 202经UWF 102在网络上的其移动装置上执行动作220（例如，登录，发布消息，侦听等）。在接收来自用户A的请求220后，UWF 102识别动作的类型并且指示PF 104记录用于订户用户A的此动作。PF 104通过沿诸如/MSISDN_A/Presence/Activity_Log等路径发送指示，更新在FS 116中存储的用于用户A的日志文件208中的活动。日志文件能够包含带有相关联日期、时间和任何其它适当数据字段的动作类型列表。网络上的每个订户能够具有其自己相关联的活动日志文件。操作员能够配置在日志文件中记录和存储的活动的类型。在步骤223中，FS 116在用户A的活动日志208中存储更新。FS 116通过确认消息ACK 224响应RPCS 108，RPCS 108又将ACK 226发送到用户A。ACK 226能够是超文本传送协议(HTTP) 200 OK消息或SIP消息或适合协议中的任何其它确认消息。HTTP消息将只用于示范目的。本领域技术人员将领会，视特定实现和协议细节而定，确认消息224和226能够是可选的。

类似地，用户B 204也经UWF 102在其移动装置上执行动作228（例如，登录，发布消息，侦听等）。在接收来自用户B的请求后，UWF 102识别动作类型并且指示PF 104记录用于订户用户B的此动作。PF 104通过沿示范路径/MSISDN_B/Presence/Activity_Log发送指示，以更新在FS 116中存储的用于用户B的日志文件210中的活动。在步骤231中存储更新，并且能够返回类似于如上所述消息224和226的确认消息232和234。

用户B可能想查询或采用网络内用户A的存在信息。用户A能够是用户B的地址簿中的联系人。用户B的移动装置中的客户端应用能够向UWF 102发送检索用户A的存在状态的请求236。UWF 102将请求转发到PF 104以检索用户A的活动日志文件。PF 104从FS 116请求用户A的活动238，并且信息在消息240中返回。在检索用户A的活动日志文件后，PF 104基于操作员和/或最终用户定义的准则，得到用户A的存在状态。PF 104可使用动作的类型、动作的时间或任何其它准则从活动日志文件中存储的信息确定存在状态。网络中用户的存在状态可以是在线、离线、忙、可用等之一或如操作员或订户定义的任何其它状态。存在状态能够基于只理解最近记录的动作或任何数量的记录的动作来确定。例如，PF 104能够读取用户A的活动日志，并且确定用户A在最近预确定时间期内在活动状态，并且将用户A“在线”假设为其估计的状态。

随后，PF 104将用户A的存在状态返回到UWF 102。UWF 102又将用户A的存在信息242发送到用户B的装置。如图3所示，装置可向用户B显现244此信息。

本领域技术人员将领会，所述具REST性存在服务为用户提供无状态和被动存在状态。仅在另一用户请求信息时才确定用户的状态。此方法不要求用于建立、保持和最终中断会话的网络开销，也不要求为用户保持活动存在状态所需的持续网络业务。

图3示出显示如图2所确定的存在状态的用户移动装置300的示例显示。用于用户的各种存在状态的示例为“在线”302、“忙”304或“离线”306。

图4示出用于本发明的交谈服务的调用流程的一示例实施例。本领域技术人员将领会，此示例涉及RPCS 108的UWF 102和CF 106，然而，为简明起见，将忽略在UWF 102与CF 106之间通信和交互有关的具体细节。用户A 402能够从其移动装置上的联系人列表选择用户B 404，并且经UWF 102将交谈邀请消息406发送到用户B。邀请406能够是HTTP POST或任何其它适当的消息。在接收来自用户A的邀请406后，UWF 102指示CF 106识别交谈对象（或资源）。

交谈对象能够是FS 116或网络中中央数据存储库中存储的数据对象或条目。每个交谈对象能够具有独特的标识符(ID)、与交谈相关联的参与者列表（即，用户A和用户B）及交谈历史405。能够通过姓名、移动订户综合服务数字网络号码(MSISDN)或对订户独特的任何其它公共身份来识别参与者。交谈历史405能够是存储在与交谈对象相关联的参与者之间交换的所有以前消息的文件。交谈对象可包括交谈历史，或者它可以是到网络中其它处存储的交谈历史的指针。

在步骤408中，CF 106确定是否已经存在用于参与者之间以前交谈的交谈对象和交谈ID。如果交谈对象不存在，则CF 106将创建新交谈对象和相关联交谈ID。

UWF 102接收用于生成或现有交谈对象的交谈ID。随后，UWF 102在消息410中将交谈ID转发到用户A的装置。消息410能够包含触发用户A的装置中聊天客户端应用的应用标识符。随后，聊天客户端能够通过将消息412发送到RPCS 108，使用长轮询机制创建用于交谈对象的侦听信道。

长轮询是允许仿真从服务器到客户端的信息推送的轮询技术。使用长轮询时，客户端以类似于正常轮询的方式从服务器请求信息。然而，如果服务器没有可用于客户端的任何信息，则服务器不发送空响应，而是保留请求并且等待一些信息可用。一旦信息变得可用（或者在适合的超时后），完整的响应便被发送到客户端。随后，客户端一般将立即从服务器重新请求信息，因此，服务器将几乎始终具有能够用于响应事件而输送更新的数据的可用等待请求。

UWF 102也发送指示414，以便经短消息服务中心(SMS-C) 118将包括交谈ID的SMS-0消息发送到用户B的装置。SMS-C 118将SMS-0 416发送到用户B，确认418被返回到SMS-C 118，并且确认420被返回到UWF 102以证实S-0 416的输送。此SMS-0 416用作开始聊天客户端应用的触发和到要侦听的交谈对象的指针。将领会的是，SMS-0消息的使用是通知用户B的装置的一种示例方法。其它可能方法包括使用多媒体消息传递服务(MMS)消息、电子邮件或SIP消息。随后，用户B的装置中的聊天客户端应用将发送请求422到UWF 102和CF 106以检索由收到的交谈ID识别的交谈对象。RPCS 108能够通过请求424和返回426从FS 116检索可存在的与交谈对象有关的任何交谈历史。RPCS 108能够将交谈历史转发428到用户B。UWF 102能够经在侦听信道中发送的响应430向用户A指示用户B已加入交谈。用户A的装置通过长轮询或其它适合的机制更新432侦听信道。

用户B经UWF 102向用户A发布新消息434。UWF 102将消息传递到CF 106以便在FS 116中的交谈对象中存储。CF 106将更新436发送到FS 116并且接收返回的更新ACK 438。UWF 102在用于由用户B发布的消息的确认消息上进行分拆440。用户A接收用于交谈对象的其持续长轮询，由用户B作为返回442发布的消息（即，交谈对象的更新）。用户B接收用于发布消息434的确认444。

注意，在有多于两个参与者的群组交谈的情况下，分拆操作440能够执行以将用户B发布的消息发送到所有其它群组成员。例如，用户C（未示出）能够接收用于交谈对象的其持续长轮询，由用户B发布的类似于返回442的消息。

在接收消息442和444后，用户A和用户B均必须更新其长侦听信道。消息442的接收触发用户A的装置上的聊天客户端应用经长轮询446更新侦听信道。消息444的接收触发用户B的装置上的聊天客户端应用经长轮询448更新侦听信道。

用户A和用户B的装置只要其相应聊天客户端应用在运行，便能够继续长轮询交谈对象。无论何时添加新信息到交谈对象，便将它返回到用户。用户关闭其聊天客户端应用时，客户端装置将简单地停止侦听交谈对象。其它参与者能够接收用户已离开（即，已停止侦听）交谈的更新。

图5是示出根据本发明的一实施例，用于初始化交谈服务的方法的流程图。方法能够由通信网络中诸如图1的RPCS 108等节点实现，或者能够由网络中的多个节点或模块实现。在步骤502中，接收来自第一用户装置的聊天请求。聊天请求能够识别请求参与与第一用户的聊天/交谈的第二用户或多个用户。在步骤504中，根据收到的聊天请求识别交谈对象。能够通过聊天请求中第一用户和请求的参与者的身份来识别交谈对象。步骤504能够包括确定与聊天请求有关的交谈对象是否已经存在。如果交谈对象不存在，则能够创建新对象。在步骤506中，将交谈对象标识符传送到交谈参与者。交谈对象标识符能够包括在发送到第一用户装置的聊天请求的回复中。交谈对象标识符能够包括在发送到被请求参与者的聊天邀请消息中。邀请和聊天对象标识符能够通过SMS-0消息或者通过其它方式传送。在步骤508中，如果存在任何历史，则选择性地能够将交谈历史传送到每个用户装置。交谈历史能够包括在参与者之间以前交换的任何消息，并且选择性地包括用于每个参与者的存在状态。在步骤510中，从在交谈中处于活动状态的每个用户装置接收侦听交谈对象以用于更新的侦听请求。侦听请求能够是长轮询请求消息。侦听请求能够是接收交谈对象的更新通知的请求。

图6是示出根据本发明的一实施例，用于更新交谈服务的方法的流程图。在步骤602中，从与交谈对象相关联的至少一个参与者的装置接收创建侦听信道以用于交谈对象的更新的侦听请求。侦听请求能够是长轮询请求消息。在步骤604中，从第一参与装置接收更新交谈对象的消息。在步骤606中，根据收到的消息，更新交谈对象。更新交谈更新能够包括在交谈历史中保存或存储收到的消息。在步骤608中，作为在步骤602中收到的侦听请求的回复以及响应更新交谈对象606，将交谈更新通知传送到每个参与者。交谈更新通知能够是到第一参与者的确认，确认其消息604已发布到交谈对象。交谈更新通知能够是从第一参与者收到的消息到任何其它参与者的转发。交谈更新通知能够是链接，以检索自用于参与者的前一次更新以来向交谈对象发布的任何内容。在步骤610中，能够从交谈中的一些或所有参与装置选择性地接收新侦听请求。

图7是示出能够实现本公开内容的各种实施例的任何实施例的示例节点700的框图。节点700包括处理器702、通信接口704和存储器706。存储器706能够存储指令，指令在由处理器702执行时，允许节点700执行图1的RPCS 108的功能，包括通用web服务功能102、存在功能104和交谈功能106。存储器706也能够存储与在至少两个参与者之间的交谈相关联的交谈对象。通信接口704接收来自用户装置的启动与第二用户装置的交谈的请求。通信接口704也接收来自第一用户装置的侦听交谈对象以用于更新和在有更新时接收通知的侦听请求。

处理器702识别与收到的请求相关联的交谈对象。识别交谈对象能够包括确定是否已经存在在存储器706中存储，与第一和第二用户相关联的交谈对象。如果此类交谈对象不存在，则处理器702在存储器706中创建新交谈对象。处理器702指示通信接口704将交谈邀请传送到第二用户，邀请指示识别的交谈对象。邀请能够包括交谈ID。处理器702能够选择性地指示通信接口704将与交谈对象相关联的交谈历史传送到用户之一或两者。可从存储器706访问和检索交谈历史，或备选，可在位于通信网络中其它处的数据存储库存储它。

通信接口704接收来自第二用户装置的新消息。处理器702响应收到的新消息，更新交谈对象，并且响应来自第二用户装置的交谈更新的接收，指示通信接口704传送收到的侦听请求的回复。发送到第一用户装置的收到的侦听请求的回复能够包括从第二用户装置收到的新消息。通信接口704也能够将确认传送到第二用户装置以证实其消息已被收到，并且交谈对象已被更新。通信接口能够接收来自第一用户装置对交谈对象的更新通知的更新的侦听请求。

本公开内容的基于REST的存在和交谈服务不依赖任何重型基础设施、设置或网络开销。它不要求用户注册或预订交谈或存在信息。本公开内容基于记录的活动使用被动或假设的存在状态而不是绝对状态。本解决方案不要求使用SIP栈或任何IMS基础设施，只有基于REST的客户端实现基于HTTP的API。由于一旦交谈结束，便不存在活动会话，因此，解决方案是无状态的。在本公开内容中，用户装置上的聊天客户端应用负责交谈，并且邀请例如经SMS得到控制。不同于关闭活动会话，客户端能够简单地停止侦听交谈对象。

基于前面所述，本领域普通技术人员现在应明白，本公开内容提供了有利的解决方案。虽然本公开内容的系统和方法已专门参照某些类型的消息和节点进行描述，但基于至此为止的引用应认识到的是，本文中包含的创新教导不必限于此，并且可以各种方式有利地实现。相信从前面的描述中将明白本公开内容的操作和构造。

本发明的实施例可表示为在非暂时性机器可读媒体（也称为计算机可读媒体、处理器可读媒体或其中包含有计算机可读程序代码的计算机可用媒体）中存储的软件产品。机器可读媒体可以是任何适合的有形媒体，包括磁性、光学或电存储媒体，包括软盘、压缩磁盘只读存储器(CD-ROM)、数字多功能光盘只读存储器(DVD-ROM)存储器装置（易失性或非易失性）或类似的存储机制。机器可读媒体可包含各种指令集、代码序列、配置信息或其它数据，它们在执行时促使处理器执行根据本发明的一实施例的方法中的步骤。本领域普通技术人员将理解，实现所述发明所需的其它指令和操作也可存储在机器可读媒体上。从机器可读媒体运行的软件可与电路接口以执行所述任务。

本发明的上述实施例仅旨在做为示例。在不脱离只由本文所附权利要求定义的本发明范围的情况下，本领域的技术人员可对特殊实施例实现变更、修改和改变。

Claims (20)

1. 一种用于初始化在通信网络中用户之间交谈服务的方法，包括：

-接收来自第一用户装置的启动与第二用户装置的交谈的请求；

-识别与所述收到的请求相关联的交谈对象；

-将包括与所述交谈对象相关联的标识符的邀请发送到所述第二用户装置；以及

-接收来自所述第一用户装置对所述交谈对象的更新通知的侦听请求。

2. 如权利要求1所述的方法，其中识别所述交谈对象的所述步骤包括确定是否存在与所述第一用户和所述第二用户相关联的交谈对象的步骤。

3. 如权利要求2所述的方法，还包括响应与所述第一用户和所述第二用户相关联的交谈对象不存在，创建所述交谈对象的步骤。

4. 如权利要求1所述的方法，还包括将与所述交谈对象相关联的所述标识符发送到所述第一用户装置的步骤。

5. 如权利要求1所述的方法，其中所述邀请是SMS-0消息。

6. 如权利要求1所述的方法，还包括将与所述交谈对象相关联的交谈历史发送到所述第一用户装置或所述第二用户装置至少之一的步骤。

7. 如权利要求1所述的方法，还包括以下步骤：

-响应接收来自所述第二用户的交谈更新，传送所述收到的侦听请求的回复。

8. 一种用于更新在通信网络中用户之间交谈的方法，包括：

-接收来自第一用户装置对交谈对象的更新通知的侦听请求；

-接收来自第二用户装置的与所述交谈对象相关联的消息；

-根据所述收到的消息，更新所述交谈对象；以及

-响应更新所述交谈对象，将所述收到的侦听请求的回复传送到所述第一用户装置。

9. 如权利要求8所述的方法，其中所述收到的侦听请求的所述回复包括从所述第二用户装置收到的所述消息。

10. 如权利要求8所述的方法，还包括接收来自所述第二用户装置的对所述交谈对象的更新通知的侦听请求的步骤。

11. 如权利要求10所述的方法，还包括根据所述收到的消息，传送从所述第二用户装置收到的所述侦听请求的回复，确认所述交谈对象的所述更新。

12. 如权利要求8所述的方法，其中更新所述交谈对象的所述步骤包括在与所述交谈对象相关联的交谈历史中存储所述收到的消息。

13. 如权利要求8所述的方法，还包括响应传送所述回复，接收来自所述第一用户装置对所述交谈对象的更新通知的更新的侦听请求的步骤。

14. 如权利要求8所述的方法，其中所述收到的侦听请求是长轮询请求消息。

15. 一种交谈系统，包括：

-存储器，用于存储与第一用户和第二用户相关联的交谈对象；

-通信接口，用于接收来自所述第一用户的启动与所述第二用户的交谈的请求和对所述交谈对象的更新通知的侦听请求；以及

-处理器，用于识别与所述收到的请求相关联的所述交谈对象；用于指示所述通信接口传送邀请，向所述第二用户指示所述识别的交谈对象；以及用于响应来自所述第二用户的交谈更新的接收，传送所述收到的侦听请求的回复。

16. 如权利要求15所述的交谈系统，其中所述处理器确定与所述第一用户和所述第二用户相关联的交谈对象是否存储在所述存储器中。

17. 如权利要求16所述的交谈系统，其中所述处理器响应与所述第一用户和所述第二用户相关联的交谈对象不存在，在所述存储器中创建所述交谈对象。

18. 如权利要求15所述的交谈系统，其中所述通信接口接收来自所述第二用户的消息，并且响应接收所述消息，所述处理器更新所述交谈对象。

19. 如权利要求15所述的交谈系统，其中所述收到的侦听请求的所述回复包括所述交谈更新。

20. 如权利要求15所述的交谈系统，其中收到的侦听请求是长轮询请求消息。

Images