WO2011113247A1 - 业务发起方法及终端 - Google Patents

Description

业务; 方法及终端 技术领域 本发明涉及通信领域， 尤其涉及一种业务发起方法及终端。 背景技术 随着移动通信技术的快速发展， 终端提供了丰富而又人性化的功能， 其 中， 短信、 彩信、 语音通话等是人们日常生活中最为常用的功能。 然而， 在现有的终端中， 在发送某些类型较特殊的信息， 例如， 增强型 短信 （Enhanced Message, 简称为 EMS ) 或日程短信时， 如果接收方终端不 支持该信息类型， 则接收不到该信息， 且双方都不会有任何提示； 另外， 当 终端发起对方终端不支持的业务， 例如， 可视电话、 无线一键通（ Push to talk Over Cellular, 简称为 PoC )、 视频共享等功能时， 接收方终端同样不能接收 该业务。 这会浪费用户编辑信息的时间和通信费用， 还会造成用户信息的丢 失， 降低了用户的体验。 发明内容 本发明的主要目的在于提供一种业务发起方法及终端， 以至少解决上述 问题。 才艮据本发明的一个方面， 提供了一种业务发起方法， 包括以下步骤： 第 一终端获取第二终端所支持的业务类型； 以及， 第一终端向第二终端发起获 取到的业务类型的业务。 进一步地， 第一终端获取第二终端所支持的业务类型包括： 第一终端接 收来自第二终端的短信， 其中， 短信的协议数据单元的特定位置的字段中携 带有第二终端所支持的业务类型的信息； 第一终端从字段中获取第二终端所 支持的业务类型。 进一步地， 字段中的比特通过比特图的方式指示第二终端所支持的业务 类型， 字段占用的比特数 B=nA, 其中， A 为第一终端的编码位数， n 为使 C<nA的最小值， C为第二终端支持的业务类型的数量。 进一步地， 第一终端获取第二终端所支持的业务类型包括： 第一终端接 受用户将第二终端加入组的操作； 第一终端根据组的属性确定第二终端所支 持的业务类型。 进一步地，在第一终端向第二终端发起其类型属于业务类型的业务之前， 还包括： 第一终端判断业务的类型是否与业务类型相一致， 若是， 第一终端 执行发起业务的操作， 否则， 第一终端提醒用户第二终端不支持业务。 进一步地，第二终端所支持的业务类型包括第二终端所支持的信息类型， 第一终端向第二终端发起其类型属于业务类型的业务包括： 第一终端向第二 终端发送其类型属于信息类型的信息。 才艮据本发明的另一个方面， 提供了一种终端， 包括： 获取模块， 用于获 取其它终端所支持的业务类型； 以及， 业务发起模块， 用于向其它终端发起 其类型属于获取到的业务类型的业务。 进一步地， 获取模块包括： 接收子模块， 用于接收来自其它终端的短信， 其中， 短信的协议数据单元的特定位置的字段中携带其它终端所支持的业务 类型的信息； 获取子模块， 用于从字段中获取其它终端所支持的业务类型。 进一步地， 获取模块包括： 配置子模块， 用于接受用户将其它终端加入 组的操作； 确定子模块， 用于根据组的属性确定其它终端所支持的业务类型。 进一步地， 该终端还包括： 判断模块， 用于判断业务的类型是否与业务 类型相一致； 调度模块， 用于在判断模块的判断结果为是的情况下， 调度业 务发起模块， 在判断模块的判断结果为否的情况下， 调度提醒模块； 提醒模 块， 用于提醒用户第二终端不支持业务。 通过本发明， 釆用终端获取其它终端支持的业务类型， 并 居其它终端 支持的业务类型来发起业务的方法， 解决了相关技术中由于目的终端不支持 发起的业务的类型导致业务信息丢失及用户体验降低的问题， 防止了编辑时 间及通信费用的浪费和业务信息的丢失， 提高了用户的体 -险。 附图说明 此处所说明的附图用来提供对本发明的进一步理解， 构成本申请的一部 分， 本发明的示意性实施例及其说明用于解释本发明， 并不构成对本发明的 不当限定。 在附图中： 图 1是 居本发明实施例的终端的结构框图； 图 2是 居本发明实施例的终端的优选结构框图一； 图 3是 居本发明实施例的终端的优选结构框图二； 图 4是 居本发明实施例的终端的优选结构框图三； 图 5是 居本发明实施例的业务发起方法的流程图； 图 6是根据本发明实施例的业务发起方法的优选流程图； 图 7是根据本发明优选实例的示例性短信格式示意图； 图 8是根据本发明优选实例的移动终端上号码及信息类型字段的存储格 式示意图； 图 9是根据本发明优选实例的移动终端上提示信息的示意图； 以及， 图 10是才艮据本发明优选实例的信息发送过程的详细流程图。 具体实施方式 下文中将参考附图并结合实施例来详细说明本发明。 需要说明的是， 在 不冲突的情况下， 本申请中的实施例及实施例中的特征可以相互组合。 图 1是 居本发明实施例的终端的结构框图， 该终端包括： 获取模块 12 , 用于获取其它终端所支持的业务类型； 以及， 业务发起模块 14 , 连接于获取模块 12 , 用于向其它终端发起其类型属 于获取到的业务类型的业务。 相关技术中， 终端发起业务 （包括信息） 时没有业务类型的限制 （只要 发起业务的终端支持该业务类型即可），业务的接收终端可能不支持该类型的 业务， 导致业务信息丢失， 同时浪费了用户的业务编辑时间和通信费用。 本 发明实施例提供的终端中， 业务发起模块 14 能够向其它终端发起属于获取 模块 12 获取的业务类型的业务， 从而能够从业务类型的角度， 保证接收终 端的支持， 不会由于类型不支持导致业务信息丢失， 提高了用户体验。 图 2是根据本发明实施例的终端的优选结构框图一， 获取模块 12 可以 包括： 接收子模块 22 , 用于接收来自其它终端的短信， 其中， 短信的协议数据 单元 （ Protocol Data Unit, 简称为 PDU ) 的特定位置的字段中携带有其它终 端所支持的业务类型的信息； 获取子模块 24 , 连接于接收子模块 22和业务发起模块 14 , 用于从上述 字段中获取其它终端所支持的业务类型。 由于短信类型是大多数终端支持的信息类型， 因此， 可以釆用短信携带 业务类型的信息， 且在短信 PDU 中仅借用一个字段来携带其它终端支持的 业务类型的信息， 对信息格式和终端处理的改动较小， ？丈造成本低， 易于实 现。 图 3是根据本发明实施例的终端的优选结构框图二， 获取模块 12 可以 包括： 配置子模块 32 , 用于接受用户将其它终端加入组的操作； 确定子模块 34 , 连接于配置模块 32和业务发起模块 14 , 用于根据组的 属性确定其它终端所支持的业务类型。 该终端中， 配置子模块 32 接受用户将其它终端加入组的操作， 再由确 定子模块 34 从所加的组的属性中， 判断出其它终端的业务支持信息， 提供 了用户手动添加的接口， 使用户能够灵活对业务支持信息进行添加或修改， 提高了用户的体验。 图 4是才艮据本发明实施例的终端的优选结构框图三，该终端还可以包括： 判断模块 42 , 连接于获取模块 12 , 用于判断业务的类型是否与业务类 型相一致； 调度模块 44 , 连接于判断模块 42、 业务发起模块 14、 和提醒模块 46 , 用于在判断模块 42的判断结果为是的情况下， 调度业务发起模块 14 , 在判 断模块 42的判断结果为否的情况下， 调度提醒模块 46； 提醒模块 46, 连接于调度模块 44 , 用于提醒用户第二终端不支持该业 务。 在该终端中设置提醒模块 46 可以在其它终端不支持待发起的业务的情 况下， 将不支持的信息通知给用户， 以便用户决定后续的处理， 例如， 决定 是否仍然发起该业务等。 同时， 不立即发起该业务， 还可以降低用户的通信 费用。 图 5是才艮据本发明实施例的业务发起方法的流程图， 该方法包括以下步 骤： 步骤 S502 , 第一终端获取第二终端所支持的业务类型； 以及， 步 4聚 S504 , 第一终端向第二终端发起业务类型的业务。 相关技术中， 终端发起业务时没有业务类型的限制 （只要发起业务的终 端支持该业务类型即可）， 业务的接收终端可能不支持该类型的业务，导致业 务信息丢失， 同时浪费了用户的业务信息编辑时间和通信费用。 本发明实施 例提供的方法中， 向其它终端发起其类型属于第二终端支持的业务类型的业 务， 从而能够从业务类型的角度， 保证接收终端对业务的支持， 不会由于类 型不支持导致业务信息丢失， 提高了用户体验。 作为一个可选的实施方式， 步骤 S502 可以具体包括： 第一终端接收来 自第二终端的短信， 其中， 短信的协议数据单元的特定位置的字段中携带有 第二终端所支持的业务类型的信息； 第一终端从字段中获取第二终端所支持 的业务类型。 由于短信类型是大多数终端支持的信息类型， 因此， 可以釆用短信携带 业务支持信息， 且在短信 PDU 中仅借用一个字段来携带该业务类型信息， 对信息格式和终端处理的改动较小， ？丈造成本氏， 易于实现。 当然， 在双方 终端均支持的情况下， 还可以釆用其它类型的信息， 例如， 彩信、 网络短信、 飞信、 PTT等， 还可以釆用为携带该业务类型信息新增的信息类型来携带， 为了更加智能地实现支持信息的更新， 减少用户的操作， 该新增的信息类型 的信息的属性可以设置为： 到达终端后， 无需通知用户， 而是由终端在后台 进行业务类型信息的解析和保存， 以进一步提高用户的体验。 对于以上的利用短信或是彩信、 网络短信、 飞信等方式来携带业务类型 信息的实施方式， 第一终端无需每次都进行信息的解析以获取第二终端所支 持的业务类型的信息， 可以在信息中设一标识位， 用于指示该信息中是否包 含支持的业务类型的信息， 第一终端在该标识指示信息中携带支持的业务类 型的信息的情况下， 进行解析操作， 以获得业务类型的信息； 或者， 还可以 判断 PDU 中用户数据长度和短信实际长度是否相等， 若相等， 则无需进行 解析操作， 否则， 解析并获得业务类型的信息。 作为另外一种可选的实施方式， 步骤 S502 还可以包括： 第一终端接受 用户将第二终端加入组的操作； 第一终端根据组的属性确定第二终端所支持 的业务类型。该实施方式中， 第一终端接受用户将其它终端加入组的操作后， 从所加的组的属性中， 判断出其它终端所支持的业务类型， 提供了用户手动 添加的接口， 使用户能够灵活对业务类型的信息进行添加或修改， 提高了用 户的体 -险。 该实施方式借助了用户手动添加的方式实现了第一终端对第二终 端的业务类型信息的获取， 但在实际应用中， 还可以釆用其它的方式， 例如， 红外、 蓝牙传送支持的业务类型的信息文件等方式来实现。 优选地， 第一终端也可以主动获取第二终端所支持的业务类型， 此时， 第一终端只需向第二终端发起支持业务类型的获取请求， 第二终端响应该请 求向第一终端发送自身支持的业务类型的信息， 例如， 在一键通 （如 PTT ) 时， 用户 A如果向用户 B发起支持业务类型的获取请求， 用户 B相应地可 以直接将自己支持的业务类型信息发送给用户 A。 优选地， 字段中的比特可以通过比特图的方式指示第二终端支持的业务 类型， 但不限于此。 比特图的方式配置简单， 解析方便， 易于实现。 优选地， 字段占用的比特数 B=nA, 其中， A为第一终端的编码位数， n 为使 C<nA的最小值， C为第二终端支持的业务类型的数量。 通过以上的方 式进行比特格式对齐， 方便了信息格式的扩展， 且便于管理。 图 6是根据本发明实施例的业务发起方法的优选流程图， 如图 6所示， 步骤 S504之前， 还可以包括： 步骤 S603 ,第一终端判断业务的类型是否与上述业务类型相一致，若是， 执行上述步骤 S504, 否则， 执行步骤 S605; 步骤 S605 , 第一终端提醒用户第二终端不支持该业务。 上述方法可以在第二终端不支持待发起的业务类型的情况下， 将第二终 端不支持该业务的信息通知给用户， 以便用户决定后续的处理， 例如， 决定 是否仍然发起该业务等。 第二终端所支持的业务类型可以包括第二终端所支持的信息类型， 第一 终端向第二终端发起其类型属于业务类型的业务可以包括： 第一终端向第二 终端发送其类型属于信息类型的信息。 优选实例 1 图 7 是根据本发明优选实例 1 的示例性短信格式示意图。 在短信原有 PDU串末尾， 新增一个字段， 用于表示本终端可支持的信息类型， 例如， 普 通短信、 EMS、 日程短信、 彩信、 推送 （push ) 消息等， 需要说明的是， 该 实例以第二终端支持的业务类型为第二终端所支持的信息类型为例进行说 明， 但不限于此。 为使得短信编码方式现有的普通短信格式对齐， 也为了今 后短信格式扩展方便， 这里使用 lbyte ( 8bit ) 的字段用于表示终端可支持信 息类型。 该字段可以用二进制的 bit位表示， bit位与支持的信息类型相对应， 置 1表示支持， 置 0表示不支持。 表 1示出了各信息类型及 bit位的对应关系，其中，前三个 bit用于扩展， 可以全部置 0。 表 1 信息类型与 bit位的对应关系表

现有一个终端支持信息类型包括： 普通短信、 EMS、 日程短信， 表示为 字段 0000 0111 , 转化为 16进制为 07。 上述第二终端在发送信息时， 可以将这一特殊字段附加在信息中， 该字 段可以附加于短信的用户数据字段中。 收件人 （即， 第一终端）接收到信息 后， 读取这一附加字段， 将号码及这一字段， 存储在终端列表中； 或者， 用 户通过口头沟通等方式获知第二终端可支持的信息类型后， 可以手动将第二 终端加入信息类型对应的组中， 也可手动编辑、 删除、 4爹改号码及其对应关 系， 第一终端才艮据第二终端所在的组， 编辑终端列表。 例如， 当一个号码在 EMS组中时， 则终端列表中该号码的信息类型字段中， EMS对应的 bit位为 1„ 图 8给出了一种示例性的终端列表的存储格式， 该示例性格式将信息类 型字段、 号码和一些个人信息 （例如， 姓名， 地址等） 组合在一起， 在实际 应用中， 终端列表也可以仅包括信息类型字段和号码的对应关系。 为避免联 系人更换手机后， 原有列表不能及时得到更新， 对于同一个联系人， 当新获 取的所支持的信息类型与现有列表不一致， 将使用新获取的信息覆盖原有的 信息。 在发送信息时， 第一终端可以判断信息类型，检索号码对应的信息字段， 并查询该类型对应的 bit位， 若为 1 , 表明对方支持， 直接发送； 若为 0, 将 提示用户对方不支持该信息类型， 是否编辑后再进行发送， 图 9给出了一种 示例性的移动终端进行不支持信息类型的提示的格式。 优选实例 2 以下以第二终端支持的业务类型为第二终端所支持的信息类型， 且第一 终端根据第二终端所支持的信息类型来发送信息的过程为例来说明本发明实 施例提供的业务发起方法。 第二终端在编辑时， 提前为信息类型字段预留一个或两个字符的存储位 置， 为了使得字符对齐， 若使用 7bit编码， 需预留两个字符 （ 14bit ), 即普 通短信最多可输入 158个字符，长短信的每一个分段最多可输入 150个字符； 若使用 8bit编码， 需预留一个字符 （8bit ), 即普通短信最多可输入 139个字 符， 长短信的每一个分段最多可输入 133个字符； 若使用 UCS 16编码， 需预 留一个字符 （ 16bit ), 则普通短信最多可输入 69个字符， 长短信的每一个分 段最多可输入 66个字符。 以 8bit编码为例， 如图 7所示， 在进行编码时， 用户数据位长度为实际长度 -1 , 即为 L-1个字符。 如图 10所示， 信息发送的过程包括如下步骤： 步骤 1001 , 终端收到短信后， 读取发件人号码。 为了减少手机的判断次 数， 也可仅对现有通讯录中的联系人进行判断。 步骤 1002 , 根据短信的头部信息， 判断接收到的信息类型是否是普通短 信。 步骤 1003 , 如果 1002的判断结果为是， 将比较用户数据长度和短信实 际长度是否相等， 以判断短信中是否携带了类型信息， 若相等， 进入步骤 1004, 否则， 进入步 4聚 1009。 步骤 1004, 此时， 短信未携带类型信息字段， L个字符均为真正的用户 数据， 按照一般的短信解码方式进行处理。 步骤 1005 , 此时， 短信携带有类型信息字段， 在本实例中， 数据长度比 实际长度少 1位， 这 1位用于携带信息类型， 因此 L-1个字符为用户数据内 容， 解码并显示， 最后一个字符为信息类型字段， 读取最后一个字段。 步骤 1006, 判断本终端列表中是否已经存在该号码， 如果已经存在， 执 行步骤 1007, 否则， 执行步骤 1008。 步骤 1007, 直接覆盖终端列表中该号码对应的类型信息字段。 步 4聚 1008, 对方不在通讯录中， 放弃保存。 步骤 1009, 收到的短信类型为长短信， 选择长短信中任一条短信进行处 理， 判断任一条短信的数据长度是否等于实际长度， 若是， 执行步骤 1004, 否则， 执行步 4聚 1005。 £设一个终端 A支持信息类型包括： 普通短信、 彩信、 EMS、 日程短信； 终端 B支持信息类型包括： 普通短信、 彩信、 日程短信、 push消息。 终端 A 收到 B发送的短信， 短信中包含 B可支持的信息类型字段。 按照以上的对应 关系， 该字段使用二进制表示为 0001 1011 , 转化为 16进制为 1 B。 终端 A 接收到短信后， 查看 B是否已经存在于 A的终端列表中， 如果已经存在， 覆 盖原有信息； 如果不存在，在列表中添加该联系人及其对应的信息类型字段， 一种示例性的列表形式如图 8所示。 优选实例 3 £设一个终端 A支持信息类型包括： 普通短信、 彩信、 EMS、 日程短信； 终端 B支持信息类型包括： 普通短信、 彩信、 日程短信、 push消息。 终端 A 上有群组普通短信群组、 彩信群组、 EMS群组、 日程短信群组。 当使用终端 A的用户得知终端 B支持信息类型后，可以手动将 B的手机号码添加到普通 短信、彩信和日程短信群组中。此时，终端 B对应的手机号码信息字段为 0000 1011。 终端 A向终端 B发送消息时， 首先检查终端 B的号码是否在待发送信 息对应的类型列表中。 如当前发送信息为彩信， 终端 A检查到 B支持彩信， 直接发送。 如当前发送信息为 EMS , 终端 A检查到 B不在 EMS群组中， 提 示用户： "对方不支持 EMS , 是否编辑后发送？ ，，。 如用户选择是， 进入短信 编辑界面； 选择否， 则取消编辑， 直接发送。 一种示例性的提示界面如图 9 所示。 综上所述， 上述业务发起方案能够从业务类型的角度， 保证接收终端对 业务的支持， 不会由于类型不支持导致业务信息丢失， 提高了用户体验， 且 该方案无需对移动终端软件进行大规模的改动， 易于实现。 显然， 本领域的技术人员应该明白， 上述的本发明的各模块或各步骤可 以用通用的计算装置来实现， 它们可以集中在单个的计算装置上， 或者分布 在多个计算装置所组成的网络上， 可选地， 它们可以用计算装置可执行的程 序代码来实现， 从而， 可以将它们存储在存储装置中由计算装置来执行， 并 且在某些情况下， 可以以不同于此处的顺序执行所示出或描述的步骤， 或者 将它们分别制作成各个集成电路模块， 或者将它们中的多个模块或步骤制作 成单个集成电路模块来实现。 这样， 本发明不限制于任何特定的硬件和软件 结合。 以上所述仅为本发明的优选实施例而已， 并不用于限制本发明， 对于本 领域的技术人员来说， 本发明可以有各种更改和变化。 凡在本发明的 ^"神和 原则之内， 所作的任何修改、 等同替换、 改进等， 均应包含在本发明的保护 范围之内。

Claims

权 利 要 求 书

1. 一种业务发起方法， 其特征在于， 包括以下步 4聚：

第一终端获取第二终端所支持的业务类型； 以及，

所述第一终端向所述第二终端发起所述业务类型的业务。

2. 根据权利要求 1所述的方法， 其特征在于， 所述第一终端获取所述第二 终端所支持的所述业务类型包括：

所述第一终端接收来自所述第二终端的短信， 其中， 所述短信的协 议数据单元的特定位置的字段中携带有所述第二终端所支持的业务类型 的信息；

所述第一终端从所述字段中获取所述第二终端所支持的所述业务类 型。

3. 根据权利要求 2所述的方法， 其特征在于， 所述字段中的比特通过比特 图的方式指示所述第二终端所支持的所述业务类型， 所述字段占用的比 特数 B=nA, 其中， A为所述第一终端的编码位数， n为使 C<nA的最小 值， C为所述第二终端所支持的所述业务类型的数量。

4. 根据权利要求 1所述的方法， 其特征在于， 所述第一终端获取所述第二 终端所支持的所述业务类型包括：

所述第一终端接受用户将所述第二终端加入组的操作； 所述第一终端 居所述组的属性确定所述第二终端所支持的所述业 务类型。

5. 根据权利要求 1所述的方法， 其特征在于， 在所述第一终端向所述第二 终端发起所述业务类型的所述业务之前， 还包括：

所述第一终端判断所述业务的类型是否与所述业务类型相一致， 若 是， 所述第一终端执行发起所述业务的操作， 否则， 所述第一终端提醒 用户所述第二终端不支持所述业务。

6. 根据权利要求 1所述的方法， 其特征在于， 所述第二终端所支持的所述 业务类型包括所述第二终端所支持的信息类型， 所述第一终端向所述第 二终端发起其类型属于所述业务类型的业务包括：

所述第一终端向所述第二终端发送所述信息类型的信息。

7. —种终端， 其特征在于， 包括：

获取模块， 用于获取其它终端所支持的业务类型； 以及， 业务发起模块， 用于向所述其它终端发起所述业务类型的业务。

8. 根据权利要求 7所述的终端， 其特征在于， 所述获取模块包括： 接收子模块， 用于接收来自所述其它终端的短信， 其中， 所述短信 的协议数据单元的特定位置的字段中携带所述其它终端所支持的业务类 型的信息；

获取子模块， 用于从所述字段中获取所述其它终端所支持的所述业 务类型。

9. 根据权利要求 7所述的终端， 其特征在于， 所述获取模块包括：

配置子模块， 用于接受用户将所述其它终端加入组的操作； 确定子模块， 用于根据所述组的属性确定所述其它终端所支持的所 述业务类型。

10. 根据权利要求 7所述的终端， 其特征在于， 还包括：

判断模块， 用于判断所述业务的类型是否与所述业务类型相一致； 调度模块， 用于在所述判断模块的判断结果为是的情况下， 调度所 述业务发起模块， 在所述判断模块的判断结果为否的情况下， 调度提醒 模块；

所述提醒模块， 用于提醒用户所述第二终端不支持所述业务。