CN112787910A - 一种消息处理方法、装置、电子设备和存储介质 - Google Patents

一种消息处理方法、装置、电子设备和存储介质 Download PDF

Info

Publication number
CN112787910A
CN112787910A CN202110128398.7A CN202110128398A CN112787910A CN 112787910 A CN112787910 A CN 112787910A CN 202110128398 A CN202110128398 A CN 202110128398A CN 112787910 A CN112787910 A CN 112787910A
Authority
CN
China
Prior art keywords
message
dimension
category
user
historical
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
Application number
CN202110128398.7A
Other languages
English (en)
Inventor
韩怀龙
白永申
徐志德
张玲
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Lianren Healthcare Big Data Technology Co Ltd
Original Assignee
Lianren Healthcare Big Data Technology Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Lianren Healthcare Big Data Technology Co Ltd filed Critical Lianren Healthcare Big Data Technology Co Ltd
Priority to CN202110128398.7A priority Critical patent/CN112787910A/zh
Publication of CN112787910A publication Critical patent/CN112787910A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/04—Real-time or near real-time messaging, e.g. instant messaging [IM]
    • H04L51/046—Interoperability with other network applications or services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/903—Querying
    • G06F16/9038—Presentation of query results
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/906—Clustering; Classification
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H80/00—ICT specially adapted for facilitating communication between medical practitioners or patients, e.g. for collaborative diagnosis, therapy or health monitoring
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/07—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail characterised by the inclusion of specific contents
    • H04L51/18—Commands or executable codes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/21—Monitoring or handling of messages
    • H04L51/216—Handling conversation history, e.g. grouping of messages in sessions or threads

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Mining & Analysis (AREA)
  • Medical Informatics (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Computational Linguistics (AREA)
  • Biomedical Technology (AREA)
  • Pathology (AREA)
  • Epidemiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Public Health (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本发明实施例公开了一种消息处理方法、装置、电子设备和存储介质，该方法包括：当检测到用户更换用于安装消息接收端的终端设备时，基于预设策略从消息服务端获取与所述用户关联的历史消息；确定所述历史消息所属的维度类别；根据所述维度类别确定对所述历史消息进行显示的显示策略，以使不同维度类别的历史消息显示在不同的聊天界面；其中，所述维度类别包括业务场景类别。通过本发明实施例的技术方案，实现了当用户更换用于安装消息接收端的终端设备时，将历史消息同步至新终端设备的消息接收端的目的，同时实现了对不同维度消息的分开显示，有利于提高用户获取消息的效率。

Description

一种消息处理方法、装置、电子设备和存储介质
技术领域
本发明实施例涉及计算机技术领域，尤其涉及一种消息处理方法、装置、电子设备和存储介质。
背景技术
IM(Instant Messaging，即时通讯)是目前互联网上最为流行的一种通讯方式，大部分的应用APP都开发或集成了IM模块。
目前通过IM进行对话时，即用户登录成功后，通过APP与另一个登录用户进行聊天时，在APP的同一聊天界面中显示当前用户与另一用户聊天的所有信息。
但当业务复杂的时候，例如医疗行业的会诊业务、复诊业务或者医疗咨询业务等，医生与同一用户之间关于不同业务的聊天信息并不希望全部显示在同一聊天界面，这样不利于医生快速获取有效信息，降低了医生与用户之间的沟通效率。而且若用户更换了手机，在新手机登录APP时，由于本地数据库并没有聊天数据，因此用户无法查看历史聊天记录。
发明内容
本发明实施例提供了一种消息处理方法、装置、电子设备和存储介质，实现了当用户更换用于安装消息接收端的终端设备时，将历史消息同步至新终端设备的消息接收端的目的，同时实现了对不同维度消息的分开显示，有利于提高用户获取消息的效率。
第一方面，本发明实施例提供了一种消息处理方法，应用于消息接收端，该方法包括：
当检测到用户更换用于安装消息接收端的终端设备时，基于预设策略从消息服务端获取与所述用户关联的历史消息；
确定所述历史消息所属的维度类别；
根据所述维度类别确定对所述历史消息进行显示的显示策略，以使不同维度类别的历史消息显示在不同的聊天界面；
其中，所述维度类别包括业务场景类别。
第二方面，本发明实施例还提供了一种消息处理装置，集成于消息接收端，该装置包括：
获取模块，用于当检测到用户更换用于安装消息接收端的终端设备时，基于预设策略从消息服务端获取与所述用户关联的历史消息；
第一确定模块，用于确定所述历史消息所属的维度类别；
第二确定模块，用于根据所述维度类别确定对所述历史消息进行显示的显示策略，以使不同维度类别的历史消息显示在不同的聊天界面；
其中，所述维度类别包括业务场景类别。
第三方面，本发明实施例还提供了一种电子设备，所述电子设备包括：
一个或多个处理器；
存储器，用于存储一个或多个程序；
当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如本发明任意实施例所提供的消息处理方法步骤。
第四方面，本发明实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如本发明任意实施例所提供的消息处理方法步骤。
上述发明中的实施例具有如下优点或有益效果：
通过当检测到用户更换用于安装消息接收端的终端设备时，基于预设策略从消息服务端获取与所述用户关联的历史消息；确定所述历史消息所属的维度类别；根据所述维度类别确定对所述历史消息进行显示的显示策略，以使不同维度类别的历史消息显示在不同的聊天界面；其中，所述维度类别包括业务场景类别的技术手段，实现了当用户更换用于安装消息接收端的终端设备时，将历史消息同步至新终端设备的消息接收端的目的，同时实现了对不同维度消息的分开显示，有利于提高用户获取消息的效率。
附图说明
图1是本发明实施例一提供的一种消息处理方法的流程图；
图2是本发明实施例二提供的一种消息处理方法的流程图；
图3是本发明实施例二所涉及的一种消息发送端、消息接收端、消息服务端相互配合工作的消息处理流程示意图；
图4是本发明实施例二所涉及的一种维度类别接口的链式链接示意图；
图5是本发明实施例二所涉及的一种消息接收端执行的消息处理方法流程示意图；
图6是本发明实施例二所涉及的一种在消息发送时，对消息进行处理的代码实现流程图；
图7是本发明实施例二所涉及的另一种消息处理方法的流程示意图；
图8是本发明实施例二提供的又一种消息处理方法的流程示意图；
图9是本发明实施例二所涉及的一种历史消息查询处理的流程示意图；
图10是本发明实施例二所涉及的一种未读消息数量的处理方法流程示意图；
图11是本发明实施例三提供的一种消息处理装置的结构示意图；
图12是本发明实施例四提供的一种电子设备的结构示意图。
具体实施方式
下面结合附图和实施例对本发明作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本发明，而非对本发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本发明相关的部分而非全部结构。
实施例一
图1为本发明实施例一提供的一种消息处理方法的流程图，本实施例的技术方案应用于消息接收端，具体可以是某咨询类的APP，例如医疗行业的网上会诊类应用APP，该类APP可以安装于患者(可以理解为用户)的手机或者电脑，同时在医生的手机或者电脑也安装有与患者端的APP匹配的APP，患者可以通过其手机或者电脑的APP与医生发起即时聊天，医生通过其手机或者电脑的APP与患者进行沟通。
所述消息处理方法可以由消息处理装置来执行，该装置可以由软件和/或硬件的方式来实现。如图1所示，该方法具体包括以下步骤：
步骤110、当检测到用户更换用于安装消息接收端的终端设备时，基于预设策略从消息服务端获取与所述用户关联的历史消息。
其中，消息接收端可以是用于接收消息和/或发送消息的应用APP，终端设备可以是智能手机或者电脑等。与所述用户关联的历史消息可以是指通过登录所述用户的APP发送、接收的消息。例如张三在其旧手机安装了医疗咨询类APP，并且张三使用自己的身份信息进行了注册，则张三为该APP的一个有效用户，张三通过该APP与医生李四针对自己皮肤长痘的情况进行了医疗会诊，当张三更换新手机后，在新手机重新安装所述APP，但是登录账号依然是张三之前注册的账号，因此与张三关联的历史消息可以是指张三通过旧手机的所述APP与医生李四针对自己皮肤长痘的情况进行医疗会诊时产生的消息。APP的每个用户(指注册的用户)对应一个标识token，用户登录成功后获取唯一的标识token，所有发送和接收的消息都与这个标识token唯一对应。因此，可以基于用户的标识token从众多消息中筛选出与特定用户关联的消息。
示例性的，所述基于预设策略从消息服务端获取与所述用户关联的历史消息，包括：
从消息服务端获取设定时间段内与所述用户关联的历史消息。
设定时间段例如可以是最近3天或者最近1周。通常时间太久的消息对用户的参考价值不大，因此，设定时间段可以是距离当前时间最近的3天或者1周，当然也可以是1个月、1年等，这与消息服务端存储消息的周期也有关，有的消息服务端每隔一定时间会清理一次历史消息，以释放更多的存储空间。可以理解的是，从消息服务端获取到与所述用户关联的历史消息之后，可将所述历史消息存储至所述终端设备的本地数据库，当需要对历史消息进行显示时，通常是用户激活具体的聊天界面时，从本地数据库获取对应的历史消息到内存，而后实现消息的显示。
步骤120、确定所述历史消息所属的维度类别。
其中，所述维度类别包括业务场景类别。所述业务场景类别包括下述至少一种：医疗会诊业务、医疗复诊业务以及医疗咨询业务。其中，医疗会诊业务可以指患者第一次就诊相关的业务，该业务场景下通常会涉及患者诉说自己的症状、不适感等，医生会为患者开具检查单，例如B超的检查单或者验血的检查单等。医疗复诊业务可以指患者在第一次就诊后的几天之内的会诊，可以通俗地理解为是复查，以前一次的就诊记录为基础，患者就相同的病症与相同的医生进行沟通。医疗咨询业务可以指一些保健方面的信息咨询，该种业务场景下通常不存在病症。
所述维度类别还可以包括用户类别。“用户类别”可通过如下场景进行理解，例如张三在其手机安装了医疗咨询类APP，并且张三使用自己的身份信息进行了注册和登录，则张三为该APP的一个有效用户，张三通过该APP与医生李四针对自己皮肤长痘的情况进行了医疗会诊，则张三为一具体的用户类别，对应的业务场景类别为医疗会诊业务。同时，张三本人或者张三的母亲通过张三手机上的所述APP针对张三母亲血压高的事项与医生李四进行了医疗咨询，询问平时的注意事项，则张三母亲也为一具体的用户类别，对应的业务场景类别为医疗咨询业务。需要说明的是，由于使用的是利用张三的身份信息注册的APP针对张三母亲的个人情况与医生李四进行的沟通，因此，张三母亲并不是所述APP的有效用户，但是张三母亲为一具体的用户类别，张三母亲可以理解为是有效用户张三的分支用户。本实施例的技术方案包括实现在上述场景下，实现针对不同用户类别在不同业务场景下消息的单独显示，即针对张三皮肤长痘与医生李四进行沟通过程中的相关消息显示在一个聊天界面，而针对张三母亲高血压事项与医生李四进行医疗咨询的过程中产生的相关消息显示在另一聊天界面，上面两类消息分开显示，虽然是通过同一APP与同一医生进行沟通产生的消息，但是需要根据消息所属的业务场景类别以及用户类别进行单独显示，以方便医生或者患者及时捕获消息所传达的内容，提高消息获取效率。
步骤130、根据所述维度类别确定对所述历史消息进行显示的显示策略，以使不同维度类别的历史消息显示在不同的聊天界面。
具体的，将不同维度类别下的历史消息显示在不同的聊天界面，例如将针对张三母亲关于医疗咨询业务的消息显示在用于沟通针对张三母亲关于医疗咨询业务的聊天界面；将针对张三皮肤长痘的情况进行医疗会诊业务的消息显示在另一聊天界面，该聊天界面仅用于会诊关于张三皮肤长痘的情况。通过根据消息所属的业务场景类别以及用户类别进行单独显示，可以方便医生或者患者及时捕获消息所传达的内容，提高消息获取效率。
本实施例的技术方案，通过当检测到用户更换用于安装消息接收端的终端设备时，基于预设策略从消息服务端获取与所述用户关联的历史消息；确定所述历史消息所属的维度类别；根据所述维度类别确定对所述历史消息进行显示的显示策略，以使不同维度类别的历史消息显示在不同的聊天界面；其中，所述维度类别包括业务场景类别的技术手段，实现了当用户更换用于安装消息接收端的终端设备时，将历史消息同步至新终端设备的消息接收端的目的，同时实现了对不同维度消息的分开显示，有利于提高用户获取消息的效率。
实施例二
图2为本发明实施例二提供的一种消息处理方法的流程图，本实施例在上述实施例的基础上，对上述步骤120和步骤130进行了进一步细化，给出了可选的实施方式。其中与上述实施例相同或相应的术语的解释在此不再赘述。
参见图2，本实施例提供的消息处理方法具体包括以下步骤：
步骤210、当检测到用户更换用于安装消息接收端的终端设备时，基于预设策略从消息服务端获取与所述用户关联的历史消息。
步骤220、对所述历史消息进行解析，获取所述历史消息的扩展字段数据，根据所述扩展字段数据确定所述历史消息所属的维度类别。
其中，消息在被消息发送端发送时，在消息的扩展字段添加了用于标识消息所属维度类别的数据，因此可以通过对历史消息进行解析，获取历史消息的扩展字段数据，从而根据扩展字段数据确定历史消息所属的维度类别。
步骤230、根据所述扩展字段数据从预设工具获取预先注册的过滤规则对象；将所述历史消息添加至所述过滤规则对象，获得过滤结果。
所述将所述历史消息添加至所述过滤规则对象，获得过滤结果，包括：
将所述历史消息的维度类别与所述过滤规则对象记录的类别标识进行比对；
若所述历史消息的维度类别与所述过滤规则对象记录的类别标识一致，则确定过滤结果为通过；
其中，所述过滤规则对象记录的类别标识包括当前聊天界面的类别标识，所述维度类别还包括用户类别。
其中，所述过滤规则对象记录的类别标识为预先设置的类别标识，不同业务方的APP可以设置不同的类别标识，所属类别标识例如可以为level＝4表示业务场景类别为医疗复诊业务，level＝7表示业务场景类别为医疗咨询业务。用户类别可以通过targetId进行表示，例如targetId＝1表示APP的有效用户(例如上述张三)，targetId＝1.1表示的有效用户的母亲，targetId＝1.2表示的有效用户的父亲。targetId＝1.1且level＝7表示针对张三母亲关于医疗咨询业务的消息。所述当前聊天界面的类别标识例如可以是targetId＝1.1且level＝7，表示当前聊天界面适用于沟通针对张三母亲关于医疗咨询业务的界面。
步骤240、根据所述过滤结果确定是否将所述历史消息显示在当前聊天界面。
若过滤结果为“通过”，则将历史消息显示在当前聊天界面，若过滤结果为“不通过”，则不将历史消息显示在当前聊天界面，而是当当前聊天界面切换为与所述历史消息的维度类别对应的界面时，对所述历史消息进行显示。
进一步的，可参考图3所示的一种消息发送端、消息接收端、消息服务端相互配合工作的消息处理流程示意图，具体包括：
步骤301、制定消息分类的规则，主要分为维度和过滤规则；
步骤302、在应用的全局变量中注册规则；
步骤303、发送消息时将规则信息加入到扩展字段中；
具体的，在进行APP开发时，预先制定消息的分类规则，通常包括维度类别和过滤规则。例如定义两个接口，其中一个为维度类别接口，根据业务的实际情况来划分几个维度，例如业务场景类别和用户类别两个维度。
维度类别接口的代码实现具体可以为：
(Level＜T)：+opration()：returnT
-leve：int
-next：Level
维度类别接口的链式链接可参考图4所示。
过滤规则接口的代码实现具体可以为：
(Rule＜T)：+computeRule(T t)：returnboolean
过滤规则的实现类与维度类别对应，不同的维度类别对应的过滤规则可以不同，例如第一个维度--业务场景类别对应的过滤规则可以为：
Rule1<Bean1>：+computeRule(Bean1 t)：returnboolean
根据传入的String类型的参数，判断业务编号，如果当前的业务编号为4，则代表当前的消息是医疗复诊业务的消息，如果type＝curType，则返回true，如果type≠curType，则返回false。所以通过逻辑判断如果返回结果为true，则表示消息与当前聊天界面的业务场景类别相同，则显示消息，如果是false，则表示消息与当前聊天界面的业务场景类别不同，程序终止。
第二个维度--用户类别对应的过滤规则可以是：
Rule2<Bean>：+computeRule(Bean t)：returnboolean
这个维度的过滤规则是判断用户ID targetId是否和当前用户的ID相同，如果相同，则表示消息是发送给当前用户的，程序继续，否则终止程序。
预先定义了几个维度的标准，就相应地判断几层，全部满足了才会将消息展示给用户。如图5所示的一种消息接收端执行的消息处理方法流程示意图，接收到消息时，将消息的扩展字段extra转换成Level对象，通过规则管理器获取level对象对应的规则方法，通过规则方法判断消息是否满足过滤条件，如果不满足，则结束程序，如果满足则显示消息。消息的extra字段是扩展字段，消息接收端获取消息后先存入本地数据库，而显示消息的动作是在adapter类的方法中，所以在向adapter类添加消息的时候进行消息过滤，过滤规则是判断两个维度的过滤方法返回的布尔值，例如若当聊天界面是有效用户张三的医疗复诊业务的界面时，如果返回的布尔值中level值是1(表示第一个维度)并且业务编号是4(表示业务场景类别为医疗复诊业务场景)，level值是2(表示第二维度)并且targetId(表示用户类别标识)是当前用户id则可以向adapter类添加消息，以在当前聊天界面进行显示，如果不符合上述条件，则不向adapter类添加消息，即不在当前聊天界面对消息进行显示。
在应用APP的全局变量中注册上述分类规则，定义一个全局的规则管理器RuleManager，其结构可以为：
RuleManager：+rules：Map<Level＜T>.class,Rule<T>>＝new HashMap()
+getRule(Level＜T>.class I)：Rule＜T>
-registeRule(Level＜T>.class I，Rule＜T>r)
通常APP的消息分类规则是预先设定好的，因此在APP的Application中注册相应的维度和过滤规则对象即可，其中，以过滤维度类别的字节码为key，获取到对应的过滤规则的对象实例。
在发送消息时，可以通过两种方式对消息进行处理，其中一种是每次发送消息时，在消息的扩展字段里面添加分类规则，根据业务需求定义几个维度，就向消息的扩展字段中添加几个维度对象，每个维度对象的next字段都指定一个维度对象。第二种方式，在消息的预处理方法中进行处理，通常在进行消息发送时都会对消息进行一定的预处理，具体是调用预处理接口实现，因此可以将在扩展字段中添加分类规则的操作设置在预处理方法中，每次对消息进行预处理时捎带对消息的扩展字段进行分类规则的添加，此时无需关注消息类型是字符、图片还是语音，只关注扩展字段即可，处理效率与稳定性较高。
在消息发送时，对消息进行处理的代码实现流程图可参考图6所示，将具体的分类规则转换成json，然后赋值给消息的extra字段。
步骤304、接收消息时对消息的扩展字段进行处理；
步骤305、点击通知栏的跳转处理；
当接收到所述消息通知栏的触发指令时，基于所述维度类别确定目标聊天界面，并跳转至所述目标聊天界面，其中，所述消息显示于所述目标聊天界面。
具体是根据所述维度类别确定标识一致的或者相对应的聊天界面，例如所述维度类别为targetId＝1.1且level＝7(表示针对张三母亲关于医疗咨询业务的消息)，则目标聊天界面应是用于沟通针对张三母亲关于医疗咨询业务的界面。具体可参考图7所示的另一种消息处理方法的流程示意图。
可以理解的是，为了提高APP的稳定性，避免宕机时消息丢失，当接收到消息时，若当前某聊天界面为激活状态，即当前页面为聊天界面，则将消息存储至本地数据库以及内存，而后进行消息的分类显示策略，若当前页面不是聊天界面，则弹出消息通知栏，消息仅被保存至内存，若在用户点击消息通知栏之前发生了宕机现象，则该消息可能会丢失。对应的，可参考图8所示的另一种消息处理流程示意图。
步骤306、IM聊天界面的显示规则；
具体的，当接收到消息时，确定消息的维度类别，根据所述维度类别确定是否将所述消息显示在当前聊天界面。示例性的，所述根据所述维度类别确定是否将所述消息显示在当前聊天界面，包括：
根据所述扩展字段数据从预设工具获取预先注册的过滤规则对象；
将所述消息添加至所述过滤规则对象，获得过滤结果；
根据所述过滤结果确定是否将所述消息显示在当前聊天界面。
所述将所述消息添加至所述过滤规则对象，获得过滤结果，包括：
将所述消息的维度类别与所述过滤规则对象记录的类别标识进行比对；
若所述消息的维度类别与所述过滤规则对象记录的类别标识一致，则确定过滤结果为通过；
其中，所述过滤规则对象记录的类别标识包括当前聊天界面的类别标识，所述维度类别还包括用户类别。
步骤307、历史消息查询的处理；
其中，步骤307、历史消息查询的处理具体指当APP更换手机然后登录新手机的APP时，本地数据库中并没有聊天数据，这时会从远程服务端拉取聊天消息，处理方式同样是先保存到本地数据库中，此时聊天消息也是没有分类的，然后像步骤306一样，按照维度和过滤规则来确定是否显示聊天消息，以及如何显示聊天消息。对应的，可参考如图9所示的一种历史消息查询处理的流程示意图。
步骤308、未读消息数量的处理；
具体的，消息服务端接收各消息发送端发送的消息，并将所述消息的状态设置为未读状态。
通常同一业务方开发的APP对应同一消息服务端。安装于张三手机的APP与安装于李四手机的APP可以看作两个消息发送端，不论是张三还是李四通过所述APP与在线医生进行沟通时，发送的消息先到达消息服务端，由消息服务端分发至对应在线医生的APP。因此，消息服务端接收的消息来自很多的消息发送端。消息优先达到消息服务端，而后才到达消息接收端，因此，当消息达到消息服务端时，消息的状态显然是未读状态，没有被对方接收并阅读。
根据消息接收端在线用户的用户标识确定与所述在线用户关联的目标消息。
其中，在线用户指登录APP的用户，与在线用户关联的目标消息指需要发送至在线用户APP的消息。APP的每个用户(指注册的用户)对应一个token，用户登录成功后获取唯一的token，所有发送和接收的消息都与这个token唯一对应。因此，可以基于在线用户的token从众多消息中筛选出与在线用户关联的消息，该类消息称为目标消息。
根据所述在线用户关联的维度类别标识对所述目标消息进行分类，以确定各维度类别下目标消息的数量。
其中，在线用户关联的维度类别标识可以指在线用户涉及的业务场景类别、在线用户的用户类别，例如在线用户为张三，其涉及的业务场景类别为针对自己皮肤长痘的情况进行了医疗会诊，若张三为APP的有效用户，则其用户类别为有效用户，若张三通过其儿子张小三注册的APP针对自己皮肤长痘的情况进行了医疗会诊，则其用户类别可以是有效用户张小三的父亲。
通过根据在线用户关联的维度类别标识对所述目标消息进行分类，可以确定各维度类别下目标消息的数量，进而在APP的对应位置展示各维度类别下目标消息的数量。
将各维度类别下目标消息的数量发送至消息接收端，以使消息接收端在各维度类别所对应标识的关联位置展示对应维度类别下未读消息的数量。其中，所述维度类别包括业务场景类别和/或用户类别；所述业务场景类别包括下述至少一种：医疗会诊业务、医疗复诊业务以及医疗咨询业务。
具体的，在各维度类别所对应标识具体可以是图标，例如与张三本人在医疗会诊业务场景下对应图标1，与张三本人在医疗复诊业务场景下对应图标2，与张三本人在医疗咨询业务场景下对应图标3，与张三母亲在医疗会诊业务下对应图标4等，不同的患者在不同业务场景类别下对应不同的图标，对应的未读消息数量可以展示在对应图标的右上角或者左上角等位置，通过触发对应图标可以激活对于的聊天界面，并在该聊天界面显示对应的消息，实现根据消息所属的业务场景类别以及用户类别进行单独显示，以方便医生或者患者及时捕获消息所传达的内容，提高沟通效率的目的。
进一步的，当接收到特定维度类别的标识时，记录当前接收时刻；
将所述特定维度类别下、当前接收时刻之前的消息状态设置为已读状态，以使消息接收端更新展示于所述特定维度类别所对应标识的关联位置处未读消息的数量。
进一步的，若目标在线用户进入或者退出特定维度类别对应的聊天界面时，所述目标在线用户的消息接收端向消息服务端发送所述特定维度类别的标识。
示例性的，参考图10所示的一种未读消息数量的处理方法流程示意图，具体包括：用户通过手机APP，即消息发送端发送即时通讯IM消息至云服务器，云服务器负责对消息进行分发，具体是分发至匹配的APP客户端，即消息接收端，同时执行步骤A、设置将消息路由至额外设置的业务服务器(该服务器可以有，也可以没有，根据具体的业务方需求进行设置)，即APP服务器，APP服务器对路由过来的消息进行预处理，主要负责步骤B、对消息进行分类并设置每种类别下消息的数量。步骤C、手机APP从APP服务器获取对应维度消息的未读数量，一般APP的消息列表在一个界面统一管理，所以业务服务器会根据登陆用户所涉及的维度来查询相关消息的未读数量并返回给用户。APP再根据相应维度消息的未读数量进行未读消息的提示。例如因为业务的需要某APP只展示第一维度消息的未读数量，所以根据业务编号来判断是医疗复诊业务的未读消息还是医疗会诊业务的未读消息还是医疗咨询业务的未读消息，将未读消息的数量分别显示在对应的图标右上角。步骤D、若检测到进入聊天界面的操作，则将对应维度的消息状态设置为已读。当用户进入到IM界面(即聊天界面)，APP将当前聊天界面的维度标志发送给业务服务器，业务服务器将对应的消息设置为已读，当前时间点以前消息的消息状态都更改为已读，当前时间点之后的消息状态不变。步骤E、若检测到退出聊天界面的操作，则将对应维度的消息状态设置为已读。当用户退出IM界面时，将该IM界面的维度标志发送给业务服务器，业务服务器将对应的消息设置为已读，当前时间点以前的消息状态都更改，当前时间点之后的消息状态不变。退出IM界面时进行消息状态的更改是为了防止在进入IM聊天界面后路由到业务服务器的消息也被计算到未读消息数里。步骤F、每次收到消息并且无IM界面被激活时获取未读消息的数量。当用户只是打开APP或者退出了IM聊天界面之后，接收到的消息应算是未读的消息，此时应该设置消息为未读状态，APP应在相应的图标上有未读的红点。例如APP的Home界面底部tab的右上角，如果有未读数量的话会有小红点提示，同样在消息列表中，当收到消息后会请求业务服务器，根据业务维度来判断是复诊业务还是医疗咨询业务的未读数，并做相应UI更新。其他业务入口的处理：有时候进入IM界面并不是从IM列表中，有时候是从跟业务关联不大的界面进入的，比如推送的状态信息，跳转的逻辑上述实施例所述的技术方案类似，先根据消息的扩展字段确定消息所属的维度类别，然后跳转相应维度类别的IM聊天界面中。
综上所述即为消息处理方法的全部过程，依据此方法可以在现有的IM模块的功能上建立起逻辑上的维度分离，底层实际还是IM的点对点的通信。此方法对原有的项目架构的浸入非常少，并且分离的规则可以自行制定，可以1维、2维，也可以多维，只要注册好维度和规则，就可以按照自己的业务需求来过滤消息，并且不同维度之间的消息隔离显示。
步骤309、其它业务入口的处理。有时进入IM聊天界面并不是从IM列表中，有时是从跟业务关联不大的界面进入的，比如推送的状态信息，跳转的逻辑和步骤305类似，先判断消息里的扩展字段的维度类别，然后跳转至相应维度类别的IM聊天界面中。
本实施例的技术方案，通过对所述历史消息进行解析，获取所述历史消息的扩展字段数据；根据所述扩展字段数据确定所述历史消息所属的维度类别，实现了对历史消息所属维度类别的确定；通过根据所述扩展字段数据从预设工具获取预先注册的过滤规则对象；将所述历史消息添加至所述过滤规则对象，获得过滤结果；根据所述过滤结果确定是否将所述历史消息显示在当前聊天界面的技术手段，实现了对历史消息显示策略的确定，通过对不同用户类别在不同业务场景下历史消息的单独显示，有利于提高用户获取消息的效率。
以下是本发明实施例提供的消息处理装置的实施例，该装置与上述各实施例的消息处理方法属于同一个发明构思，在消息处理装置的实施例中未详尽描述的细节内容，可以参考上述消息处理方法的实施例。
实施例四
图11为本发明实施例三提供的一种消息处理装置的结构示意图，该装置集成于消息接收端，如图11所示，该装置具体包括：获取模块1110和第一确定模块1120和第二确定模块1130。
其中，获取模块1110，用于当检测到用户更换用于安装消息接收端的终端设备时，基于预设策略从消息服务端获取与所述用户关联的历史消息；第一确定模块1120，用于确定所述历史消息所属的维度类别；第二确定模块1130，用于根据所述维度类别确定对所述历史消息进行显示的显示策略，以使不同维度类别的历史消息显示在不同的聊天界面；其中，所述维度类别包括业务场景类别。
进一步的，所述业务场景类别包括下述至少一种：医疗会诊业务、医疗复诊业务以及医疗咨询业务。
进一步的，获取模块1110具体用于：从消息服务端获取设定时间段内与所述用户关联的历史消息。
进一步的，第一确定模块1120包括：
解析单元，用于对所述历史消息进行解析，获取所述历史消息的扩展字段数据；
确定单元，用于根据所述扩展字段数据确定所述历史消息所属的维度类别。
进一步的，第二确定单元1130包括：
获取子单元，用于根据所述扩展字段数据从预设工具获取预先注册的过滤规则对象；
过滤子单元，用于将所述历史消息添加至所述过滤规则对象，获得过滤结果；
确定子单元，用于根据所述过滤结果确定是否将所述历史消息显示在当前聊天界面。
进一步的，过滤子单元具体用于：将所述历史消息的维度类别与所述过滤规则对象记录的类别标识进行比对；若所述历史消息的维度类别与所述过滤规则对象记录的类别标识一致，则确定过滤结果为通过；其中，所述过滤规则对象记录的类别标识包括当前聊天界面的类别标识。
进一步的，所述维度类别还包括用户类别。
本实施例的技术方案，通过当检测到用户更换用于安装消息接收端的终端设备时，基于预设策略从消息服务端获取与所述用户关联的历史消息；确定所述历史消息所属的维度类别；根据所述维度类别确定对所述历史消息进行显示的显示策略，以使不同维度类别的历史消息显示在不同的聊天界面；其中，所述维度类别包括业务场景类别的技术手段，实现了当用户更换用于安装消息接收端的终端设备时，将历史消息同步至新终端设备的消息接收端的目的，同时实现了对不同维度消息的分开显示，有利于提高用户获取消息的效率。
本发明实施例所提供的消息处理装置可执行本发明任意实施例所提供的消息处理方法，具备执行消息处理方法相应的功能模块和有益效果。
实施例四
图12为本发明实施例四提供的一种电子设备的结构示意图。图12示出了适于用来实现本发明实施方式的示例性电子设备12的框图。图12显示的电子设备12仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。
如图12所示，电子设备12以通用计算电子设备的形式表现。电子设备12的组件可以包括但不限于：一个或者多个处理器或者处理单元16，系统存储器28，连接不同系统组件(包括系统存储器28和处理单元16)的总线18。
总线18表示几类总线结构中的一种或多种，包括存储器总线或者存储器控制器，外围总线，图形加速端口，处理器或者使用多种总线结构中的任意总线结构的局域总线。举例来说，这些体系结构包括但不限于工业标准体系结构(ISA)总线，微通道体系结构(MAC)总线，增强型ISA总线、视频电子标准协会(VESA)局域总线以及外围组件互连(PCI)总线。
电子设备12典型地包括多种计算机系统可读介质。这些介质可以是任何能够被电子设备12访问的可用介质，包括易失性和非易失性介质，可移动的和不可移动的介质。
系统存储器28可以包括易失性存储器形式的计算机系统可读介质，例如随机存取存储器(RAM)30和/或高速缓存存储器32。电子设备12可以进一步包括其它可移动/不可移动的、易失性/非易失性计算机系统存储介质。仅作为举例，存储系统34可以用于读写不可移动的、非易失性磁介质(图12未显示，通常称为“硬盘驱动器”)。尽管图12中未示出，可以提供用于对可移动非易失性磁盘(例如“软盘”)读写的磁盘驱动器，以及对可移动非易失性光盘(例如CD-ROM,DVD-ROM或者其它光介质)读写的光盘驱动器。在这些情况下，每个驱动器可以通过一个或者多个数据介质接口与总线18相连。系统存储器28可以包括至少一个程序产品，该程序产品具有一组(例如至少一个)程序模块，这些程序模块被配置以执行本发明各实施例的功能。
具有一组(至少一个)程序模块42的程序/实用工具40，可以存储在例如系统存储器28中，这样的程序模块42包括但不限于操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。程序模块42通常执行本发明所描述的实施例中的功能和/或方法。
电子设备12也可以与一个或多个外部设备14(例如键盘、指向设备、显示器24等)通信，还可与一个或者多个使得用户能与该电子设备12交互的设备通信，和/或与使得该电子设备12能与一个或多个其它计算设备进行通信的任何设备(例如网卡，调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口22进行。并且，电子设备12还可以通过网络适配器20与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器20通过总线18与电子设备12的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备12使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。
处理单元16通过运行存储在系统存储器28中的程序，从而执行各种功能应用以及消息处理，例如实现本发实施例所提供的一种消息处理方法步骤，该方法包括：
当检测到用户更换用于安装消息接收端的终端设备时，基于预设策略从消息服务端获取与所述用户关联的历史消息；
确定所述历史消息所属的维度类别；
根据所述维度类别确定对所述历史消息进行显示的显示策略，以使不同维度类别的历史消息显示在不同的聊天界面；
其中，所述维度类别包括业务场景类别。
当然，本领域技术人员可以理解，处理器还可以实现本发明任意实施例所提供的消息处理方法的技术方案。
实施例五
本实施例五提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如本发明任意实施例所提供的消息处理方法步骤，该方法包括：
当检测到用户更换用于安装消息接收端的终端设备时，基于预设策略从消息服务端获取与所述用户关联的历史消息；
确定所述历史消息所属的维度类别；
根据所述维度类别确定对所述历史消息进行显示的显示策略，以使不同维度类别的历史消息显示在不同的聊天界面；
其中，所述维度类别包括业务场景类别。
当然，本领域技术人员可以理解，处理器还可以实现本发明任意实施例所提供的消息处理方法的技术方案。
本发明实施例的计算机存储介质，可以采用一个或多个计算机可读的介质的任意组合。计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。计算机可读存储介质例如可以是但不限于：电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本文件中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。
计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。
可以以一种或多种程序设计语言或其组合来编写用于执行本发明操作的计算机程序代码，所述程序设计语言包括面向对象的程序设计语言，诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。
本领域普通技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个计算装置上，或者分布在多个计算装置所组成的网络上，可选地，他们可以用计算机装置可执行的程序代码来实现，从而可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件的结合。
注意，上述仅为本发明的较佳实施例及所运用技术原理。本领域技术人员会理解，本发明不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此，虽然通过以上实施例对本发明进行了较为详细的说明，但是本发明不仅仅限于以上实施例，在不脱离本发明构思的情况下，还可以包括更多其他等效实施例，而本发明的范围由所附的权利要求范围决定。

Claims (10)

1.一种消息处理方法，应用于消息接收端，其特征在于，包括：
当检测到用户更换用于安装消息接收端的终端设备时，基于预设策略从消息服务端获取与所述用户关联的历史消息；
确定所述历史消息所属的维度类别；
根据所述维度类别确定对所述历史消息进行显示的显示策略，以使不同维度类别的历史消息显示在不同的聊天界面；
其中，所述维度类别包括业务场景类别。
2.根据权利要求1所述的方法，其特征在于，所述业务场景类别包括下述至少一种：医疗会诊业务、医疗复诊业务以及医疗咨询业务。
3.根据权利要求1所述的方法，其特征在于，所述基于预设策略从消息服务端获取与所述用户关联的历史消息，包括：
从消息服务端获取设定时间段内与所述用户关联的历史消息。
4.根据权利要求1所述的方法，其特征在于，所述确定所述历史消息所属的维度类别，包括：
对所述历史消息进行解析，获取所述历史消息的扩展字段数据；
根据所述扩展字段数据确定所述历史消息所属的维度类别。
5.根据权利要求4所述的方法，其特征在于，所述根据所述维度类别确定对所述历史消息进行显示的显示策略，包括：
根据所述扩展字段数据从预设工具获取预先注册的过滤规则对象；
将所述历史消息添加至所述过滤规则对象，获得过滤结果；
根据所述过滤结果确定是否将所述历史消息显示在当前聊天界面。
6.根据权利要求5所述的方法，其特征在于，所述将所述历史消息添加至所述过滤规则对象，获得过滤结果，包括：
将所述历史消息的维度类别与所述过滤规则对象记录的类别标识进行比对；
若所述历史消息的维度类别与所述过滤规则对象记录的类别标识一致，则确定过滤结果为通过；
其中，所述过滤规则对象记录的类别标识包括当前聊天界面的类别标识。
7.根据权利要求1-6任一项所述的方法，其特征在于，所述维度类别还包括用户类别。
8.一种消息处理装置，集成于消息接收端，其特征在于，包括：
获取模块，用于当检测到用户更换用于安装消息接收端的终端设备时，基于预设策略从消息服务端获取与所述用户关联的历史消息；
第一确定模块，用于确定所述历史消息所属的维度类别；
第二确定模块，用于根据所述维度类别确定对所述历史消息进行显示的显示策略，以使不同维度类别的历史消息显示在不同的聊天界面；
其中，所述维度类别包括业务场景类别。
9.一种电子设备，其特征在于，所述电子设备包括：
一个或多个处理器；
存储器，用于存储一个或多个程序；
当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-7任一项所述的消息处理方法步骤。
10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求1-7中任一项所述的消息处理方法步骤。
CN202110128398.7A 2021-01-29 2021-01-29 一种消息处理方法、装置、电子设备和存储介质 Pending CN112787910A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110128398.7A CN112787910A (zh) 2021-01-29 2021-01-29 一种消息处理方法、装置、电子设备和存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110128398.7A CN112787910A (zh) 2021-01-29 2021-01-29 一种消息处理方法、装置、电子设备和存储介质

Publications (1)

Publication Number Publication Date
CN112787910A true CN112787910A (zh) 2021-05-11

Family

ID=75759968

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110128398.7A Pending CN112787910A (zh) 2021-01-29 2021-01-29 一种消息处理方法、装置、电子设备和存储介质

Country Status (1)

Country Link
CN (1) CN112787910A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115037713A (zh) * 2022-05-06 2022-09-09 北京淘友天下科技发展有限公司 消息显示方法、装置、电子设备及计算机可读存储介质

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104811366A (zh) * 2014-01-26 2015-07-29 阿里巴巴集团控股有限公司 一种网络通讯消息的漫游方法及装置
CN104883292A (zh) * 2015-04-16 2015-09-02 江苏中威科技软件系统有限公司 实现消息在不同终端漫游的方法及系统
CN107181668A (zh) * 2017-04-13 2017-09-19 合肥市群智科技有限公司 一种消息显示方法及装置
CN107517153A (zh) * 2017-07-27 2017-12-26 努比亚技术有限公司 消息推送控制方法及终端
CN107733785A (zh) * 2017-10-18 2018-02-23 苏州亿科赛卓电子科技有限公司 一种多终端聊天信息同步删除方法及装置
CN109818853A (zh) * 2019-02-19 2019-05-28 北京达佳互联信息技术有限公司 消息处理方法、装置、服务器、电子设备及计算机可读存储介质
CN109885604A (zh) * 2019-01-22 2019-06-14 平安科技（深圳）有限公司 聊天消息展示方法、电子装置及计算机可读存储介质
CN112134784A (zh) * 2020-09-03 2020-12-25 北京达佳互联信息技术有限公司 消息展示方法、装置、终端、服务器、系统及存储介质

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104811366A (zh) * 2014-01-26 2015-07-29 阿里巴巴集团控股有限公司 一种网络通讯消息的漫游方法及装置
CN104883292A (zh) * 2015-04-16 2015-09-02 江苏中威科技软件系统有限公司 实现消息在不同终端漫游的方法及系统
CN107181668A (zh) * 2017-04-13 2017-09-19 合肥市群智科技有限公司 一种消息显示方法及装置
CN107517153A (zh) * 2017-07-27 2017-12-26 努比亚技术有限公司 消息推送控制方法及终端
CN107733785A (zh) * 2017-10-18 2018-02-23 苏州亿科赛卓电子科技有限公司 一种多终端聊天信息同步删除方法及装置
CN109885604A (zh) * 2019-01-22 2019-06-14 平安科技（深圳）有限公司 聊天消息展示方法、电子装置及计算机可读存储介质
CN109818853A (zh) * 2019-02-19 2019-05-28 北京达佳互联信息技术有限公司 消息处理方法、装置、服务器、电子设备及计算机可读存储介质
CN112134784A (zh) * 2020-09-03 2020-12-25 北京达佳互联信息技术有限公司 消息展示方法、装置、终端、服务器、系统及存储介质

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115037713A (zh) * 2022-05-06 2022-09-09 北京淘友天下科技发展有限公司 消息显示方法、装置、电子设备及计算机可读存储介质

Similar Documents

Publication Publication Date Title
US11508012B2 (en) System and method for generating proactive underwriting offers using social media data
US10558684B2 (en) Auditing database access in a distributed medical computing environment
US9905112B1 (en) Contextual assessment of current conditions
US11477068B2 (en) Data network notification bar user interface
JP6178795B2 (ja) ソーシャルアクティビティフィードおよび連絡先情報のための集約プロバイダ
US10911565B2 (en) Method, device and system for associating a service account
US10992559B2 (en) Diagnostic and recovery signals for disconnected applications in hosted service environment
US11870741B2 (en) Systems and methods for a metadata driven integration of chatbot systems into back-end application services
WO2015002663A1 (en) Identifying business type using public information
JP2013527543A (ja) ソーシャル・ネットワークに基づく動的リアルタイム・レポート
CN115437933A (zh) 自动化测试方法、装置、计算机设备及存储介质
CN112787910A (zh) 一种消息处理方法、装置、电子设备和存储介质
CN112769683A (zh) 一种未读消息处理方法、装置、电子设备和存储介质
WO2018166339A1 (zh) 一种信息处理方法
CN115629743A (zh) 服务组件的编排方法、服务调度方法、装置、电子设备及存储介质
US20140067602A1 (en) Sanctions Screening
US11418503B2 (en) Sensor-based authentication, notification, and assistance systems
CN116136801A (zh) 云平台的数据处理方法、装置、电子设备及存储介质
CN112769682A (zh) 消息显示方法、处理方法、装置、电子设备和存储介质
US8453166B2 (en) Data services framework visibility component
CN109542646A (zh) 用于调用应用程序编程接口的方法和装置
US20230282319A1 (en) Method and system for automated population outreach
US20230290115A1 (en) Method, apparatus and non-transitory computer readable medium
US20210306808A1 (en) Systems and methods for digital contact tracing
CN115798737A (zh) 一种生存状态的获取方法、装置、终端设备及存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
RJ01 Rejection of invention patent application after publication

Application publication date: 20210511

RJ01 Rejection of invention patent application after publication