使用多媒体服务的通信装置、方法和系统与流程

本申请为申请日为2015年1月20日、申请号为201580005088.9、发明名称为“使用多媒体服务的通信装置、方法和系统”的发明专利申请的分案申请。

本公开一般涉及使用多媒体服务的通信。

背景技术：

近来，除了面向语音的通信，使用各种多媒体服务的通信在考虑中。例如，诸如全球移动通信系统协会(gsma)的富通信套件(richcommunicationsuite，rcs)以及万维网联盟(worldwidewebconsortium，w3c)的web实时通信(webrtc)之类的技术在呼叫中利用比利用传统语音通信基础设施的以前和收敛web技术丰富的服务。

技术实现要素：

技术方案

为了解决现有技术的以上论述的缺陷，本公开主要方面提供一种用于支持使用各种多媒体服务的可视和可听通信的装置和方法。

本公开另一方面提供一种提供用于使用各种多媒体服务的通信的基本框架和优化的用户界面的装置和方法。

本公开又一方面提供一种用于在呼叫尝试或呼叫期间交换简档并且在呼叫方和被叫方之间共享数据服务的装置和方法。

在第一示例中，提供一种在通信系统的服务器中使用多媒体服务提供通信的方法。该方法包括：从第一设备接收对第二设备的语音呼叫连接请求。该方法还包括：通过web网络，给第一设备提供预先生成的与第二设备相关的视觉多媒体信息。该方法进一步包括：连接在第一设备和第二设备之间的语音呼叫。

在第二示例中，提供一种在通信系统中的呼叫方设备的通信方法。该方法包括：请求来自被叫方设备的语音呼叫连接。该方法还包括：通过web网络，从服务器接收预先生成的与被叫方设备相关的视觉多媒体信息。该方法进一步包括：与被叫方设备通信。

在第三示例中，提供一种在通信系统中的呼叫方设备的通信方法。该方法包括：执行与被叫方设备的语音通信。该方法还包括：在呼叫期间执行应用和web浏览器中的至少一个。该方法进一步包括：与被叫方设备共享应用和由web浏览器执行的网页内容中的至少一个。

在第四示例中，提供一种在通信系统中用于使用多媒体服务提供通信的服务器的装置。该装置包括呼叫处理控制块。该装置还包括与web网络交互工作(interworkwith)的服务器。呼叫处理控制块被配置成：从第一设备接收对第二设备的语音呼叫连接请求。呼叫处理控制块还被配置成：连接第一设备和第二设备之间的语音呼叫。响应于接收的语音呼叫连接请求，服务器被配置成：通过web网络，给第一设备提供预先生成的与第二设备相关的视觉多媒体信息。

在第五示例中，提供一种在通信系统中的呼叫方设备的装置。该装置包括用于语音通信的第一客户端。该装置还包括处理数据的第二客户端。第一客户端被配置成请求来自被叫方设备的语音呼叫连接，并且与被叫方设备通信。第二客户端被配置成：通过web网络，从服务器接收预先生成的与被叫方设备相关的视觉多媒体信息。

在第六示例中，提供一种在通信系统中的呼叫方设备的装置。该装置包括用于语音通信的第一客户端。该装置还包括处理数据的第二客户端。第一客户端被配置成执行与被叫方设备的语音通信。第二客户端被配置成：在呼叫期间执行应用和web浏览器中的至少一个，并且与被叫方设备共享由应用和由web浏览器执行的网页内容中的至少一个。

从下面结合附图进行的公开了本公开示范性实施例的详细描述中，该公开的其它方面、优点和显著特征对于本领域技术人员将变得清楚。

在进行下面的详细描述之前，阐述贯穿本专利文档中使用的某些词语和短语的定义可能是有利的：术语“包括”和“包含”以及其派生词意为包括而没有限制；术语“或”是包含的，意为和/或；短语“与……相关联”、“与其相关联”以及其派生词可意为包括、被包括在……内、与……互联、包含、被包含在……内、连接到……或与……连接、耦合到……或与……耦合、可与……通信、与……合作、交织、并列、接近……、被绑定到……或用……绑定、具有、具有……的属性等等；而术语“控制器”意为控制至少一个操作的任何设备、系统或其部件，这样的设备可以硬件、固件或软件、或者它们中的至少两个相同的一些组合来实现。应当注意：与任何特定控制器相关联的功能性可以是集中式或分布式的，无论是本地还是远程。贯穿本专利文档提供对某些词语和短语的定义，本领域普通技术人员应当理解：如果不是大多数情况下，也是在许多情况下，这样的定义适用于现有的以及这样定义的词语和短语的未来使用。

附图说明

为了更全面地理解本公开及其优点，现在参考下面结合附图进行的描述，其中相同的附图标记表示相同的部件：

图1图示根据本公开的使用dialweb(拨号网站)服务的通信的示例；

图2图示根据本公开的示例性dialweb网络架构；

图3图示根据本公开的示例性dialweb客户端；

图4图示根据本公开的示例性dialweb服务器；

图5图示根据本公开的用于dialweb服务的呼叫处理的示例；

图6a和6b图示根据本公开的基本呼叫应用的示例性用户界面；

图7a到7d图示根据本公开的示例性个人联系人搜索；

图8a和8b图示根据本公开的示例性相互联系人搜索；

图9a至9d图示根据本公开的各种简档交换的示例；

图10a至10f图示根据本公开的容易用户可访问性和共享屏幕转移的示例；

图11a和11b图示根据本公开的用于在呼叫期间的容易服务菜单访问的示例性屏幕；

图12a至12f图示根据本公开的用于在呼叫期间访问各种app的示例性屏幕扩展；

图13a至13d图示根据本公开的在呼叫期间的web内容合并的示例；

图14a至14d图示根据本公开的在呼叫期间的游戏程序合并的示例；

图15图示根据本公开的用于错过的呼叫的示例性拒绝消息传输；

图16图示根据本公开的示例性最佳web执行器；

图17图示根据本公开的事件决定因素和事件组的示例性定义；

图18图示根据本公开的用于在最佳app执行器的控制器中执行应用的示例性方法；和

图19图示根据本公开的用于执行壁纸模式事件的示例性方法。

贯穿整个附图，相同的附图标记将被理解成指代相同的部件、组件和结构。

具体实施方式

以下论述的图1至19以及用于在本专利文档中描述本公开的原理的各种实施例仅仅通过说明的方式，而不应当被以任何方式解释为限制本公开的范围。本领域技术人员将理解：可在任何适当布置的电子设备或通信系统中实现本公开的原理。提供参照附图的以下描述以帮助全面理解如由权利要求及其等同物限定的公开的示范性实施例。它包括各种具体细节以帮助该理解，但是这些将被视为仅仅是示范性的。相应地，本领域普通技术人员将认识到：可以进行对在此所述的实施例的各种变化和修改而不脱离公开的范围和精神。另外，为了清楚和简明，可以省略对公知功能和结构的描述。

在下面描述和权利要求中使用的术语和词语不限于字面含义，而是仅仅由发明人使用以使得能够清楚和一致地理解公开。相应地，应当对本领域技术人员清楚的是：出于说明目的而不是出于限制由所附权利要求及其等同限定的本公开的目的提供下面对本公开示范性实施例的描述。

将理解的是：单数形式“一”、“一个”和“该”包括复数指代，除非上下文另有清楚地规定。因此，例如，提及“一组件表面”包括提及一个或多个这样的表面。

术语“基本上”意为所述的特征、参数或值不需要被精确地实现，而是可能以不影响所述特征意欲提供的数量发生偏差或变化，例如包括公差、测量误差、测量精度限制和本领域技术人员已知的其它因素。

本公开示范性实施例提供用于使用各种多媒体服务支持可视和可听通信的装置和方法。即，本公开示范性实施例提供从基于听和说的通信到在看、听和说之间的通信的创新。首先解释常规的通信及其限制。

使用各种多媒体服务的常规通信包括全球移动通信系统协会(gsma)的富通信套件(rcs)标准以及色环服务(color-ringservice)。消息收发为中心的rcs不提供差异化服务对过顶(overthetop，ott)消息收发解决方案。随着基于长期演进的语音(voiceoverlongtermevolution，volte)的出现，由于诸如kakao、line、viber和whatsapp之类的基于ott的消息收发消息服务在常规短消息收发服务(sms)/多媒体消息收发服务(mms)市场中显著突出，通信运营商开始积极地开始rcs以提供演进通信。在国内市场上，它开始于智能手机普及和lte全国性网络建设的2012年初。即，丰富的消息收发比在rcs-e中标准化的呼叫富集和增强电话簿更集中，而该消息收发服务不提供比基于激活的ott消息收发服务更差异化的服务。

rcs技术无法构建国家之间以及运营商之间的生态系统。在欧洲，通信用户经常周游于各国之间和移动通信运营商之间，而rcs提供的漫游不被无缝地支持。在2013年2月，德国电信(dt)在德国宣布无限期推迟rcs服务。因此，rcs无法差异化服务并在其商业初期建立生态系统，并且因此已经录得比ott服务低得多的使用。

诸如rcs的呼叫富集和增强电话簿之类的用户体验(ux)无法差异化。当前的来自国内运营商的rcs服务丰富了各种通信，诸如在呼叫期间如由标准定义的文件、视频和位置共享。然而，这样的系统功能不传播服务，这是因为提供给用户的设备ux与呼叫并不密切相关。另外，虽然在消息收发功能中的电话簿提供比常规电话簿更改善的功能，诸如订户状态信息和单行消息，但它不与诸如kakao和line之类的ott服务的电话簿功能相区分。

色环接收安装单独应用的设备中的输入呼叫事件，从外部服务器接收并在屏幕中显示呼叫方的社交简档信息，并且因此传递呼叫方的各种信息。相比于常规的语音/视频色环服务，色环使用社交联网服务(sns)有效地向被叫方发送呼叫方的标识信息。然而，这种方法不能克服与呼叫连接同时的色环的中断的数据通信信息，并且不能离开由服务提供商定义的应用框架的屏幕，并且因而未获得内容多样性。另外，色环仅仅向被叫方发送呼叫方简档信息，这不是可交换的服务。

因此，通过组合各种数据通信服务与除简单语音为中心的模式之外的呼叫，根据通信中的长期演进(lte)和智能手机的出现，本公开提供从可听通信到可视和可听通信的转换，像从可听无线电到可视tv的转换。特别地，基于rcs服务，本公开提供服务解决方案包，用于聚合存储在私人电话/个人计算机(pc)和云系统中的web服务和信息并支持基本拨号器(诸如智能手机中的基本呼叫应用(app))和设备的多媒体通信。

本公开为rcs改善用户界面(ui)。本公开提供基本框架，用于为rcs的富集呼叫和增强电话簿改善ui，在呼叫、呼叫接收、通信和呼叫终止之前通过考虑电话簿查询的四个通信步骤而为呼叫提供优化的ui，并在呼叫期间与呼叫方的意欲的视觉数据一起在呼叫方和被叫方之间传递语音为中心的信息。本公开允许在呼叫期间相互简档交换和当前数据服务直接分享。本公开使得智能手机的用户能够使用数据服务并且在呼叫期间同时向其他方发送数据服务信息而不中断当前数据服务并因而丰富了通信。本公开通过呼叫来链接分散的内容。本公开提供一种用于通过收集通过公有云、私有云、博客和sns分散的私人信息而在呼叫期间提供可更换的屏幕内容并且提供用于支持呼叫通信的屏幕信息以与其他方交流的系统。

图1图示根据本公开的使用dialweb服务的通信的示例。参照图1，除了首先选择诸如呼叫app或kakaoapp之类的服务并且然后选择被叫方的语音或数据通信，本通信在s110中选择被叫方，并且在s120相应的被叫方选择预设的屏幕或服务以在s130中在呼叫接收期间或在呼叫期间交换。因此，可能改变与使用呼叫的消息收发、使用呼叫的sns访问以及使用呼叫的网络游戏通信。

图2图示根据本公开的示例性dialweb网络架构。参照图2，dialweb网络包括用户设备(ue)10和20、接入网络、核心网络200和web网络400。ue10和20均包括用于语音呼叫(诸如基于lte的语音(volte))的互联网协议(ip)多媒体子系统(ims)客户端100b。ue10和20均包括dialweb客户端100a。例如，ue10和20采用智能手机。然而，类似于智能手机，ue10和20采用用于不仅提供语音呼叫服务而且提供多媒体服务的电子设备(诸如智能pad、平板电脑和膝上型电脑)。在下文中，假设ue是智能手机。

是lte接入网的接入网络包括演进节点b(enb)。核心网络200包括演进分组核心(epc)、归属订户服务器(hss)、策略和计费规则功能(pcrf)、呼叫状态控制功能(cscf)、计费网关功能(cgf)、电话应用服务器(tas)和服务能力交互管理器(scim)。核心网络200包括dialweb服务器300。

web网络400为各种多媒体服务提供web内容。例如，web内容包括私人博客和sns的内容以及存储在公共云或私有云中的内容。如图2中所示，核心网络200起用于提供使用多媒体服务的通信的服务器的作用，并且包括作为呼叫处理控制块的cscf以及与web网络交互工作的dialweb服务器300。呼叫处理控制块接收从第一ue到第二ue的语音呼叫连接请求，并且在第一ue和第二ue之间连接语音呼叫。响应于接收的语音呼叫连接请求，服务器300通过web网络向第一ue提供与第二ue相关的预设的视觉多媒体信息。

视觉多媒体信息包括web内容信息。web内容信息包括基于超文本标记语言(html)5的web内容或者网页链接信息。web内容信息包括存储在云、博客和sns的至少一个中的信息。响应于接收的语音呼叫连接请求，服务器300生成呼叫方屏幕，建立与第一ue的超文本传输协议(http)会话，处理呼叫方屏幕，并且建立与第二ue的http会话。呼叫方屏幕包括：用于显示用于语音呼叫的被叫方信息的屏幕，以及用于搜索涉及第二ue的视觉多媒体信息的屏幕。

服务器还生成被叫方屏幕，建立与第二ue的http会话，并且处理被叫方屏幕。是呼叫方设备的ue10包括：作为用于语音呼叫的第一客户端的ims客户端100b，以及作为用于数据处理的第二客户端的dialweb客户端100a。第一客户端100b请求语音呼叫连接，并且与被叫方设备通信。第二客户端100a通过web网络接收来自服务器的与被叫方设备相关的预设视觉多媒体信息。视觉多媒体信息包括web内容信息。web内容信息包括基于html5的web内容或者网页链接信息。web内容信息包括存储在云、博客和sns中的至少一个中的信息。

第二客户端100a通过服务器300建立http会话，并且在呼叫方屏幕中显示来自服务器300的视觉多媒体信息。呼叫方屏幕包括：用于显示用于语音呼叫的被叫方信息的屏幕，以及允许视觉多媒体信息搜索的屏幕。

是呼叫方设备的ue10包括：作为用于语音呼叫的第一客户端的ims客户端100b，以及作为用于数据处理的第二客户端的dialweb客户端100a。第一客户端100b向被叫方设备进行语音呼叫。第二客户端100a在呼叫期间执行应用和web浏览器中的至少一个，并且与被叫方设备共享应用与web浏览器的网页内容中的至少一个。第二客户端100a进一步包括用于显示用户屏幕的显示器，该用户屏幕包括：语音呼叫屏幕，以及用于显示应用与web浏览器的网页内容中的至少一个的屏幕。第二客户端100a进一步包括：用于在呼叫期间检测用户的预设动作的运动检测器，以及用于在检测预设动作时执行应用和web浏览器中的至少一个的控制器。

图3图示根据本公开的示例性dialweb客户端。例如，dialweb客户端采用图2的ue10的dialweb客户端100a。参照图3，dialweb客户端包括基本呼叫app110、通信处理块120和最佳app执行器130。基本呼叫app110包括电话簿处理器112、呼叫处理器114和html浏览器116。通信处理块120包括会话发起协议(sip)处理器122、服务质量(qos)处理器124、http处理器126和rcs处理器128。最佳app执行器130包括控制器132和存储器134。

用作ue的智能手机中的基本呼叫app的客户端设备功能被设计成为dialweb服务提供所有ue功能，并且提高常规rcsui的用户便利性。本公开集成常规rcs客户端的丰富的呼叫ui与智能手机的基本呼叫app，并且因此用ott解决方案解决它们的分离和差异化中的不便。此外，本公开将rcs客户端的增强的电话簿嵌入到基本呼叫拨号器电话簿中，并有效地显示每个用户的基于html5的用户简档信息。

基本呼叫app被称为vtalkapp，含义在于它允许volte呼叫。vtalkapp集成用于volte呼叫的ims客户端功能、支持rcs标准的rcs客户端以及目前的dialweb客户端功能。该功能被合并到基本呼叫app110以用作设备应用中的基本呼叫app。基本呼叫app110包括用于处理基于html5web的多媒体通信(即web实时通信(webrtc))的演进的html浏览器116。通信处理块120管理通信运营商的服务的通信和qos。最佳app执行器130执行ue中的最佳应用。

图4图示根据本公开的示例性dialweb服务器。参照图4，dialweb服务器300包括：支持全球移动通信系统协会(gsma)rcs5.0标准或更高标准的rcs服务器310、webrtc网关320、ars服务器330、服务平台服务器340、媒体服务器350、ip多媒体服务交换功能(im-ssf)360和简档数据库(db)370。如标准中所定义，rcs服务器310包括：用于支持聊天的即时消息收发(im)312，用于提供当前用户状态信息、在呼叫期间共享视频、文件和图像的共享、共享位置的位置共享的存在服务器(ps)313，用于共享基于网络的地址簿和简档的聚合的地址簿(cab)311，用于管理用户信息的xml文档管理系统(xdms)314，以及用于提供各种内容的内容服务器(cs)315。ars服务器330提供通信运营商的ars，并且在个人通信中提供用于与rcs服务器相关联的可视呼叫的核心功能。媒体服务器350在呼叫期间提供多方通信功能。

当w3c的webrtc服务器对ims网络进行呼叫时，webrtc网关320转换webrtc和ims之间的信号和承载。im-ssf360与通信运营商的智能网络(in)交互工作。服务平台340向开放应用编程接口(api)380提供通过呼叫连接分布式web内容的web服务器，在呼叫期间提供屏幕信息，并且提供用于实现/加载通信运营商的各种服务请求的基本平台。

独立于经标准化以在基于ims的volte服务中提供丰富的通信的rcs服务，dialweb服务器300的dialweb服务通过给其他方提供用于语音呼叫和屏幕显示的基于各种html5的web内容而丰富通信，其中所述web内容是由个人创建的。在这样做时，显示的web内容提供允许个人容易地写内容的单独的书写工具。web内容几乎包括使用www可连接的任何内容，诸如用于使用电话号码连接呼叫对方的私人博客410和sns420的内容，存储在公共云430或私有云440中的内容以及合法的web内容450，并且在每个ue上用分离的书写工具来自动地优化。除了rcs服务块，dialweb服务器300还提供web高速缓存功能，其中所述web高速缓存功能读取、存储和提供在链接内容之中的由许多用户参考的内容以及在互联网上经由开放api380分散和管理的一般内容，其中该链接内容在由个人通过连接私有内容所创建的网页中被参考。

图5图示根据本公开的用于dialweb服务的呼叫处理的示例。参照图5，在s501中设备a10请求到设备b20的语音呼叫连接。在从设备a10接收到设备b20的连接请求时，呼叫处理控制块s-cscf基于在ifc中定义的服务简档识别设备a10的用户预订了dialweb服务，并且在s502中将呼叫建立请求转发到dialweb服务器300。

通过从ims的角度看用作imsas330，dialweb服务器300接受经由s-cscf接收的呼叫建立请求。dialweb服务器300准备并且在s511中生成是呼叫方的设备a10的用户屏幕，并且在s503中请求对是呼叫方的设备a10的http访问。使用sip消息收发来请求http访问。响应于来自dialweb服务器300的http访问请求，在s504中，当设备a10请求http访问时，dialweb服务器300批准设备a10的http访问请求。接下来，在s512中，在dialweb服务器300和设备a10之间建立http会话，并且处理呼叫方屏幕。在s513中dialweb服务器300准备并生成被叫方屏幕，并且在s505中请求来自是被叫方的设备b20的http访问。使用sip消息收发来请求http访问。响应于来自dialweb服务器300的http访问请求，在s506中，当设备b20请求http访问时，dialweb服务器300批准设备b20的http访问请求。接下来，在s514中，在dialweb服务器300和设备b20之间建立http会话，并且处理被叫方屏幕。

这样，dialweb服务器300在由设备b20的用户生成的屏幕信息中发现提供给设备a10的用户的内容，并且然后命令设备a10通过s503中的http访问下载屏幕信息。在这样做时，dialweb服务器300确定设备a10的用户是否被授权访问相应的web内容。如果未发现可访问的web内容，则dialweb服务器300跳过s510，包括s503-s506和s511-s514，并且仅仅在s507和s520中连接语音呼叫。相比之下，当发现可访问的web内容时，dialweb服务器300执行s510(包括s503-s506和s511-s514)，并且在s507和s520中连接语音呼叫。在s510中，dialweb服务器300建立设备a10和设备b20之间的数据路径，并且提供用户屏幕共享服务。以dialweb服务器300在s507中经由s0-cscf转发语音呼叫请求给设备b20并且设备b20响应接收的语音呼叫请求(ok)的方式，连接语音呼叫。因此，在呼叫方设备a10和被叫方设备b20之间连接语音呼叫。

在设备a10和dialweb服务器300之间以及在dialweb服务器300和设备b20之间建立用于多媒体服务的数据路径以及语音呼叫之后，按用户来控制每个用户在屏幕上的web内容。例如，当在设备a10和设备b20之间控制相同的屏幕时，通过在设备a10和dialweb服务器300之间以及在dialweb服务器300和设备b20之间的路径按照用户来进行控制。在这样做时，通过设备上的菜单来定义屏幕控制授权。

根据图5的流程，如下处理用于建立的数据路径的qos。从根本上说，使用ims的volte服务被分配用于呼叫的保证比特率(gbr)的单独的路径。然而，ue中的一般http访问被分配最佳努力(be)的路径。当与语音紧密耦合的数据服务被给予不同于数据路径中的语音的qos时，用户所经历的服务质量严重下降。虽然本公开提供基于web的通信服务，但是为了使用与ims服务相同的接入点名称(apn)，ue被分配等效于单独分配的imsapn的apn，并且epc执行用于单独的订户路径管理的分开的过滤。因此，dialweb服务的ims语音路径和http数据路径获得相同的imsapn的质量。

图5的流程对应于设备a10和设备b20的相同的运营商。即使当设备a10和设备b20不属于相同运营商时，如图5中所示地通过在运营商之间的网络交互工作实现服务。例如，在不同运营商之间的用户漫游和网络交互工作符合gsmair.65gsmaims漫游和交互工作指南以及ir.90rcs交互工作指南。现在解释用于可视通信的基本呼叫app(vtalkapp)。基本呼叫appvtalk基本上包括用于支持volte呼叫的ims客户端功能、用于支持rcs5.0的rcs客户端功能以及dialweb客户端功能的全部，并且作为ue(诸如智能手机)上的基本呼叫app操作。vtalkapp不仅支持图6a的基本活动模式，而且支持图6b的缩减方式(或最小化状态)。所以，在呼叫期间的任何时间访问安装在壁纸中的各种app。

图6a和6b图示根据本公开的基本呼叫应用的示例用户界面。图6a示出基本活动屏幕，而图6b示出最小化窗口。参照图6a和6b，屏幕显示呼叫、视频呼叫、消息收发/im、记录和联系人的菜单1001。屏幕1002显示具有按压的呼叫按钮的用户输入，根据用户的字符和数字输入显示搜索结果，并且同时基于搜索的用户信息提供用于访问各种服务的功能。屏幕显示用于调整基本呼叫app的屏幕大小的用户控件1003。通过上推或下推用户控件1003，用户定义ue的屏幕上的基本呼叫app的大小。用户控件1003提供允许屏幕控制的呼叫app，并且因此用户在呼叫期间访问ue的各种应用或网页，并且在使用vtalkapp呼叫期间共享应用或网页内容。本公开使得能够与诸如ims网络或3g之类的移动通信网络交互工作。

基本上使用ue的单独设置菜单控制用于进行用于volte呼叫的ims呼叫或常规3g语音呼叫的选择。然而，当用户按压呼叫按钮时，基本上发出用于volte呼叫的ims呼叫。根据基于被叫方设备状态的网络确定，到被叫方的呼叫传递ims呼叫或3g语音呼叫。当用户使用3g语音呼叫或设备无法使用dialweb服务时，在ims中根据用于交互工作的2g和3g移动通信网络的标准、经由信令网关和媒体网关连接一般呼叫。

本公开提供sms/mms合并rcs消息收发功能。参照图6a和6b，消息收发按钮(在菜单1001中左边的第三菜单)发出rcs基本即时消息收发。典型地，智能手机的消息收发按钮发送sms消息或mms消息。消息收发按钮选择由用户使用ue的单独设置菜单来控制。rcs服务器向未预订rcs服务的被叫方设备或者使用不支持rcs的ue的订户提供可替代的服务。

本公开提供一种设备和网络合并和sns合并电话簿。参照图6a和6b，当用户按压联系人按钮(在菜单1001中右边的第一菜单)时，默认一起显示存储在rcs服务器的cab中的设备电话簿和网络联系人信息。一起显示预订dialweb服务的ars服务的共同的客户端信息。当搜索到的被叫方被设置成读取和发送关于呼叫方的社会简档信息的消息时，在相应的屏幕上显示来自相应的sns服务的一定数量的最近消息，或者提供即时消息传输。联系人按钮同时探究基于html5的屏幕，其中基于html5的屏幕在呼叫期间由被叫方定义为相互的简档交换信息。在7a至图7d以及图8a和8b中描绘统一的联系人搜索。

图7a到7d图示根据本公开的示例性个人联系人搜索。在图7a至7d中，作为个人搜索，sns链接功能使用vtalkapp支持存储在设备或dialweb服务器中的个人联系人搜索。当在图7a中呼叫方选择被叫方'honggingdong'时，在图7b中显示被叫方的sns列表1004。当显示sns列表1004时，vtalkapp提供下述功能，该功能允许呼叫方读取被叫方的sns列表1004的sns(诸如twitter)的最近信息并留下简短的消息，如图7a和7b中所示。vtalkapp还提供下述功能，该功能用于查询关于由被叫方定义为简档信息的博客以在呼叫期间、在屏幕1006中使用简档查询按钮1005与其他方共享，如图7c和图7c中所示。屏幕1006是vtalkapp中的html5浏览器。

图8a和8b图示根据本公开的示例性相互联系人搜索。作为统一的搜索，图8a和8b描绘vtalkapp显示设备的联系人或由dialweb服务器注册的公司名称的搜索结果，并且集成相应的公司的附加信息(诸如位置、优惠券广告、活动和主菜单)与电话簿。由公司预注册到dialweb服务器的广告内容信息被集成到设备的联系人中，以便将它显示在图8b的html5浏览器1006中。

图9a至9d图示根据本公开的各种简档交换的示例。参照图9a至9d，在联系人搜索和呼叫连接阶段，在呼叫服务用户之间交换由用户设置的各种简档。不仅在联系人搜索中而且在到其他方的呼叫连接中提供简档查询。根据简档查询在屏幕上显示的内容被存储在dialweb服务器中，并且dialweb服务器通过开放api读取存储在外部互联网中的内容。

基于html5支持创建简档，并且简档信息包括内容(诸如每个内容或几乎所有内容)。例如，不仅包含存储在dialweb服务器中的诸如文本、照片、媒体和音乐之类的资源的html(诸如图9a和9b)而且存储在twitter、facebook和门户网站博客中的各种内容(图9c和9d)链接到简档html文件。本公开提供容易用户可访问性和聊天屏幕共享功能。根据智能手机的特性，用户任意地安装和卸载许多应用程序。当为了用户的便利单独安装呼叫app时，本公开提供一种用于通过摇动智能手机以进行大多数多线程呼叫而执行呼叫app的方法。

图10a至10f图示根据本公开的容易用户可访问性和共享屏幕转移的示例。参照图10a至10f，当用户在ue中使用互联网，发现互联网上的具体内容并选择和进行对任意被叫方的呼叫时，互联网的内容被立即传递，以便与被叫方聊相同的内容。通过用户的特定动作(诸如摇动手机两次)执行vtalkapp，如图10b中所示，并且因此用户容易共享屏幕。ue的执行的呼叫app被定位在正在进行的应用程序的顶部，如图10c中所示。

当正好在ueapp下方的应用包括vtalkapp和内容共享应用(诸如一般的web浏览器)时，状态按钮1007指示内容共享app准备共享，如图10d中所示。当用户意欲通过点击状态按钮1007共享vtalkapp中的内容时，状态按钮1007的颜色变为成绿色并且第二层中的应用被显示在vtalkapp的html5浏览器1006中，如图10e中所示。当用户按压呼叫按钮时，呼叫被连接到被叫方并且两方在呼叫期间共享内容，如图10f中所示。

如图10a至10f中所示，增强用户体验使得用户随时随地访问ue中的呼叫功能。同时，为了通过呼叫与其他方共享ue的内容，当前的视觉主题与语音呼叫一起被共享。本公开有助于在呼叫期间访问rcs和附加服务菜单。本公开允许用户用视觉信息进行呼叫，因此提高用户体验并且丰富呼叫。为了这样做，本公开提供用于容易地访问rcs附加服务的屏幕ui，并且在呼叫期间交换关于聊天的视觉信息。

图11a和11b图示根据本公开的用于在呼叫期间容易服务菜单访问的示例性屏幕。参照图11a，控制执行器1008有助于访问dialweb服务菜单。ue提供一般呼叫服务的控制执行器1009。例如，控制执行器1009的控制支持诸如录音、扬声器、静音和蓝牙之类的功能。是html5浏览器的区域1010执行简单程序，即诸如游戏之类的应用程序，其中，所述简单程序需要与web内容或服务器的通信并且包括几个控制器。html浏览器的控制使得能够在呼叫期间进行相互简档交换、内容交换和游戏。

参照图11b，控制执行器1008执行各种功能。控制执行器1008的功能如下面的表1。

表1

本公开提供用于访问各种app的自由的屏幕扩展功能。

图12a至12f图示根据本公开的用于在呼叫期间访问各种app的示例性屏幕扩展。图12a示出全屏模式，图12b示出正常模式，图12c示出语音呼叫模式，图12d和12e示出语音呼叫最小化模式，而图12f示出状态条模式。

如图12a至12f中所示，几个屏幕模式用语音呼叫模式确保连续性，同时在呼叫期间访问ue的各种应用和内容，并通过dialweb服务、使用由vtalkapp提供ue中应用程序的开放api而与其他方共享内容。本公开在呼叫期间提供web浏览器搜索内容共享。

图13a至13d图示根据本公开的在呼叫期间的web内容合并的示例。图13a和13b示出呼叫方屏幕，而图13c和13d示出被叫方屏幕。参照图13a，为了在当前呼叫期间发送关于内容的视觉信息，呼叫方执行处于vtalkapp的语音呼叫模式的ue的web浏览器，使用网页搜索寻找特定信息，并且进入共享模式。在这样做时，vtalkapp从os读取正好在当前vtalkapp下方运行的应用信息。当应用是web浏览器时，vtalkapp取出对应于相应的web浏览器的当前屏幕的统一资源定位符(url)，并且仅仅将url发送给被叫方。在图13b中，在vtalkapp的html5浏览器中移动和合并对应于在web浏览器中搜索到的url的内容。

图13c示出被叫方屏幕并且图13d示出在vtalkapphtml5浏览器中合并和共享从呼叫方接收的url的内容。在此，仅仅传递url使得其它设备访问相同的网页并且屏幕被单独地控制。本公开使得呼叫方或被叫方完全控制当前网页以便实现与虚拟屏幕控制相同的效果。通过进入共享控制模式，任一个设备经由dialweb客户端向其它设备发送各种事件，诸如web浏览器的点击事件和滚动事件，并且其它设备的dialweb客户端将事件转发给其浏览器。本公开在呼叫期间提供基于html5的web游戏合并功能。

图14a至14d图示根据本公开的在呼叫期间的游戏程序合并的示例。例如，在呼叫期间合并go应用。这样的应用合并限于基于html5的创建，诸如go应用。图14a和14b示出呼叫方屏幕，而图14c和14d示出被叫方屏幕。参照图14a，在vtalkapp的语音呼叫模式中，执行安装到ue的基于html5的go应用，并且进入共享模式。在这样做时，vtalkapp从os读取正好在vtalkapp下方运行的应用信息。当应用是基于html5的app时，vtalkapp在当前html5浏览器中合并和执行它，并且仅仅向被叫方发送用于执行go应用的url。在图14b中，在被叫方的vtalkapp的web浏览器中合并和执行go程序。图14c示出被叫方屏幕而图14d示出：用于从呼叫方接收的url的基于html5的go应用与app一起被合并和执行。

本公开在呼叫期间提供一般app合并功能。为了执行不基于html5创建的程序(诸如从app商店下载的)，用户应用图14a至14d的游戏应用共享方法。在这种情况下，vtalkapp仅仅从os接收当前应用简档信息，并将它转发给被叫方。当被叫方根据接收的简档信息安装应用时，以与使用基于web的设备通信的go程序执行相同的方式执行相应的程序。vtalkapp以下述方式与os通信，该方式为：图3的最佳app执行器130从os读取信息，并且基本呼叫app110使用程序注册信息获得应用名称和版本信息，并且向被叫方发送获得的信息。被叫方使用由图3的最佳app执行器130定义的宏执行程序自动处理一系列应用安装和执行。本公开提供除了sms和mms之外的语音邮件系统(vms)和sns拒绝消息收发功能。

图15图示根据本公开的用于错过的呼叫的示例性拒绝消息传输。参照图15，vtalkapp以各种方式、相对于错过的呼叫向其他方提供用于发送消息1100的可替代路径。例如，vtalkapp在基本呼叫app中发送文本消息1102，使用由被叫方为呼叫方的访问打开的sns服务发送消息1106，并发送语音和视觉信息1104。在这样做时，当相应的通信运营商不采用用于基于ims的语音消息的服务器和用于视觉消息的服务器时，呼叫方经由现有的语音或视觉消息处理服务器、通过用于由dialweb服务器提供的in相互作用的im-ssf而向被叫方发送消息。

图16图示根据本公开的示例性最佳web执行器。例如，最佳web执行器是图3的最佳web执行器130。参照图16，最佳web执行器130包括控制器132、存储器134、运动检测器1302、额外的输入检测器1304、用户位置检测器1306、屏幕显示器1308和os1310。运动检测器1302检测用户的ue摇动动作，并且控制器132根据运动检测器1302的检测执行vtalk呼叫app。另外，根据额外的输入检测器1304的检测，当用户在紧急情况下摇动ue时，控制器1302自动执行特定的app并且执行在执行相应的app之后输入的宏。控制器132在存储器134中存储由用户位置检测器1306按规律间隔检测的用户位置信息以便宏在事件的情况下使用用户位置信息。

图17图示根据本公开的事件决定因素和事件组的示例性定义。参照图17，为多个事件x、y和z定义多个事件组e1至en。图18图示根据本公开的用于在最佳app执行器的控制器中执行应用的示例性方法。该方法由图16的控制器132执行。参照图18，在s1801中，控制器132接收事件。在s1802中，控制器132确定接收的事件是否是紧迫的事件。当确定紧急事件时，控制器132转到s1803。否则，控制器132转到s1807。

在s1803中，控制器132确定设备是否是活动的。当设备不是活动的时，控制器132在s1804中请求紧急模式并且然后前进到s1805。当设备是活动的时，控制器132转到s1805。控制器132在s1805中提取事件注册app和宏并且在s1806中执行提取的app和宏。在s1807中，控制器132确定设备是否是活动的。当设备不是活动的时，控制器132完成该过程。当设备是活动的时，控制器132转到s1808。在s1808中，控制器132确定它是否是壁纸模式。在壁纸模式中，控制器132在s1809中执行壁纸模式。在壁纸模式外，控制器132在s1810中提取事件/app注册事件。在s1812中，控制器132确定提取的事件是否是多事件注册。当提取的事件不是多事件注册时，控制器132转到s1806。当提取的事件不是多事件注册时，控制器132在s1814中设置优先级，并且然后转到s1806。

图19图示根据本公开的用于执行壁纸模式事件的示例性方法。参照图19，壁纸模式事件执行s1900包括：基于系统设置的执行s1902，基于用户设置的执行s1904，和在有限时段内执行最佳apps1906，以及执行最近的apps1908。如上所阐述，语音呼叫服务用户(诸如volte服务用户)与除了常规语音为中心的通信之外的其他方聊天，与其他方容易地共享用于帮助聊天的视觉信息，并且通过给其他方提供各种私有web内容和其它web内容而丰富通信，其中各种私有web内容和其它web内容在呼叫之前或期间通过互联网、通过适当的安全过程而被分散和管理。虽然常规的呼叫仅仅为通信存在，但本dialweb服务使得能够使用电话号码访问各种基于html5的内容。vtalk客户端的基本呼叫app与一般应用的合并在呼叫期间使用各种应用，并且有助于在紧急情况下访问相应的应用和情况通知。

本操作由单个控制器实现。在这种情况下，由各种计算机实现的程序指令被记录在计算机可读介质中。计算机可读介质单独或组合地包括程序指令、数据文件、数据结构等等。程序指令被设计和构造成尤其用于本公开的实现方式，或者对本领域技术人员公知。计算机可读存储介质的示例包括磁介质，诸如硬盘、软盘和磁带；光学介质，诸如光盘(cd)只读存储器(rom)盘和数字多功能盘(dvd)；磁光介质，诸如光磁盘；以及专门配置成存储和执行程序指令的硬件设备，诸如rom、随机存取存储器(ram)、闪存等等。程序指令的示例包括由编译器生成的机器代码，以及由计算机使用解释器执行的高级语言代码。当基站或中继的全部或部分被实现为计算机程序时，本公开包括存储计算机程序的计算机可读记录介质。

虽然已经参照其某些示例性实施例示出和描述了本公开，但将由本领域技术人员理解的是：在此进行形式和细节上的各种变化而不会脱离如由所附权利要求及其等同限定的本公开的精神和范围。