一种未读消息处理方法、装置、电子设备和存储介质与流程

本发明实施例涉及计算机技术领域，尤其涉及一种未读消息处理方法、装置、电子设备和存储介质。

背景技术：

im(instantmessaging，即时通讯)是目前互联网上最为流行的一种通讯方式，大部分的应用app都开发或集成了im模块。

目前通过im进行对话时，即用户登录成功后，通过app与另一个登录用户进行聊天时，在app的同一聊天界面中显示当前用户与另一用户聊天的所有信息。且当有未读消息时，也是在同一图标处提示所有未读消息的数量。

但当业务复杂的时候，例如医疗行业的会诊业务、复诊业务或者医疗咨询业务等，医生与同一用户之间关于不同业务的聊天信息并不希望全部显示在同一聊天界面，这样不利于医生快速获取有效信息，降低了医生与用户之间的沟通效率。同时，若在同一图标处提示所有未读消息的数量，也不利于用户及时获知未读消息所属的业务类别，同样不利于用户快速获取有效信息。

技术实现要素：

本发明实施例提供了一种未读消息处理方法、装置、电子设备和存储介质，实现了对不同维度的未读消息进行分开统计与提示的目的，有利于提高用户获取有效消息的效率。

第一方面，本发明实施例提供了一种未读消息处理方法，应用于消息服务端，该方法包括：

接收各消息发送端发送的消息，并将所述消息的状态设置为未读状态；

根据消息接收端在线用户的用户标识确定与所述在线用户关联的目标消息；

根据所述在线用户关联的维度类别标识对所述目标消息进行分类，以确定各维度类别下目标消息的数量；

将各维度类别下目标消息的数量发送至消息接收端，以使消息接收端在各维度类别所对应标识的关联位置展示对应维度类别下未读消息的数量；

其中，所述维度类别包括业务场景类别。

第二方面，本发明实施例还提供了一种未读消息处理装置，集成于消息服务端，该装置包括：

接收模块，用于接收各消息发送端发送的消息，并将所述消息的状态设置为未读状态；

确定模块，用于根据消息接收端在线用户的用户标识确定与所述在线用户关联的目标消息；

分类模块，用于根据所述在线用户关联的维度类别标识对所述目标消息进行分类，以确定各维度类别下目标消息的数量；

发送模块，用于将各维度类别下目标消息的数量发送至消息接收端，以使消息接收端在各维度类别所对应标识的关联位置展示对应维度类别下未读消息的数量；

其中，所述维度类别包括业务场景类别。

第三方面，本发明实施例还提供了一种电子设备，所述电子设备包括：

一个或多个处理器；

存储器，用于存储一个或多个程序；

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如本发明任意实施例所提供的未读消息处理方法步骤。

第四方面，本发明实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如本发明任意实施例所提供的未读消息处理方法步骤。

上述发明中的实施例具有如下优点或有益效果：

通过接收各消息发送端发送的消息，并将所述消息的状态设置为未读状态；根据消息接收端在线用户的用户标识确定与所述在线用户关联的目标消息；根据所述在线用户关联的维度类别标识对所述目标消息进行分类，以确定各维度类别下目标消息的数量；将各维度类别下目标消息的数量发送至消息接收端，以使消息接收端在各维度类别所对应标识的关联位置展示对应维度类别下未读消息的数量的技术手段，实现了对不同维度的未读消息进行分开统计与提示的目的，有利于提高用户获取有效消息的效率。

附图说明

图1是本发明实施例一提供的一种未读消息处理方法的流程图；

图2是本发明实施例一所涉及的一种未读消息数量的处理方法流程示意图；

图3是本发明实施例二提供的一种未读消息处理方法的流程示意图；

图4是本发明实施例二所涉及的一种维度类别接口的链式链接示意图；

图5是本发明实施例二所涉及的一种消息接收端执行的未读消息处理方法流程示意图；

图6是本发明实施例二所涉及的一种在消息发送时，对消息进行处理的代码实现流程图；

图7是本发明实施例二所涉及的一种消息发送端、消息接收端、消息服务端相互配合工作的未读消息处理流程示意图；

图8是本发明实施例三提供的一种未读消息处理装置的结构示意图；

图9是本发明实施例四提供的一种电子设备的结构示意图。

具体实施方式

下面结合附图和实施例对本发明作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本发明，而非对本发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本发明相关的部分而非全部结构。

实施例一

图1为本发明实施例一提供的一种未读消息处理方法的流程图，本实施例的技术方案应用于消息服务端，与消息服务端配合工作的系统还包括消息接收端和消息发送端，消息发送端发送的消息通过消息服务端中转和一定的预处理到达消息接收端。消息接收端或者消息发送端具体可以是某咨询类的app，例如医疗行业的网上会诊类应用app，该类app可以安装于患者(可以理解为用户)的手机或者电脑，同时在医生的手机或者电脑也安装有与患者端的app匹配的app，患者可以通过其手机或者电脑的app与医生发起即时聊天，医生通过其手机或者电脑的app与患者进行沟通。

参见图1，本实施例提供的未读消息处理方法具体包括以下步骤：

步骤110、接收各消息发送端发送的消息，并将所述消息的状态设置为未读状态。

通常同一业务方开发的app对应同一消息服务端。例如安装于张三手机的app与安装于李四手机的app可以看作两个消息发送端或者消息接收端，不论是通过张三手机的所述app还是通过李四手机的所述app与在线医生进行沟通时，发送的消息都是先到达消息服务端，由消息服务端再将消息分发至对应在线医生的app。同理，在线医生回复的消息也是先达到消息服务端，由消息服务端将与张三相关的消息分发至张三手机的app，将与李四相关的消息分发至李四手机的app。因此，消息服务端接收的消息来自很多的消息发送端。由于消息优先达到消息服务端，而后才到达消息接收端，因此，当消息达到消息服务端时，消息的状态显然是未读状态，没有被对方接收并阅读。

步骤120、根据消息接收端在线用户的用户标识确定与所述在线用户关联的目标消息。

其中，在线用户指登录app的用户，与在线用户关联的目标消息指需要发送至在线用户app的消息。app的每个用户(指注册的用户)对应一个标记token，用户登录成功后获取唯一的标记token，所有发送和接收的消息都与这个标记token唯一对应。因此，可以基于每个在线用户的标记token从众多消息中筛选出与在线用户关联的消息，该类消息称为目标消息。

步骤130、根据所述在线用户关联的维度类别标识对所述目标消息进行分类，以确定各维度类别下目标消息的数量。

其中，在线用户关联的维度类别标识可以指在线用户涉及的业务场景类别、在线用户的用户类别。例如在线用户为张三针对自己皮肤长痘的情况进行了医疗会诊，其涉及的业务场景类别为“医疗会诊业务”。若张三为app的注册用户，则其用户类别为“有效用户”，若张三通过其儿子张小三注册的app针对自己皮肤长痘的情况进行了医疗会诊，则其用户类别可以是“有效用户张小三的父亲”。

示例性的，所述维度类别包括业务场景类别，所述业务场景类别包括下述至少一种：医疗会诊业务、医疗复诊业务以及医疗咨询业务。其中，医疗会诊业务可以指患者第一次就诊相关的业务，该业务场景下通常会涉及患者诉说自己的症状、不适感等，医生会为患者开具检查单，例如b超的检查单或者验血的检查单等。医疗复诊业务可以指患者在第一次就诊后的几天之内的会诊，可以通俗地理解为是复查，以前一次的就诊记录为基础，患者就相同的病症与相同的医生进行沟通。医疗咨询业务可以指一些保健方面的信息咨询，该种业务场景下通常不存在病症。

所述维度类别还可以包括用户类别。“用户类别”可通过如下场景进行理解，例如张三在其手机安装了医疗咨询类app，并且张三使用自己的身份信息进行了注册和登录，则张三为该app的一个有效用户，张三通过该app与医生李四针对自己皮肤长痘的情况进行了医疗会诊，则张三为一具体的用户类别，对应的业务场景类别为医疗会诊业务。同时，张三本人或者张三的母亲通过张三手机上的所述app针对张三母亲血压高的事项与医生李四进行了医疗咨询，询问平时的注意事项，则张三母亲也为一具体的用户类别，对应的业务场景类别为医疗咨询业务。需要说明的是，由于使用的是利用张三的身份信息注册的app针对张三母亲的个人情况与医生李四进行的沟通，因此，张三母亲并不是所述app的有效用户，但是张三母亲为一具体的用户类别，张三母亲可以理解为是有效用户张三的分支用户。

通过根据在线用户关联的维度类别标识对所述目标消息进行分类，可以确定各维度类别下目标消息的数量，进而使app在其对应位置展示各维度类别下目标消息的数量。例如通过统计确定维度类别“张三-医疗会诊业务”下目标消息的数量为10条，维度类别“张三母亲-医疗咨询业务”下目标消息的数量为8条，则在张三app的显示界面中与维度类别“张三-医疗会诊业务”对应的第一图标的关联位置显示对应的未读消息提示图标，例如可以是红色的“10”；在张三app的显示界面中与维度类别“张三母亲-医疗咨询业务”对应的第二图标的关联位置显示对应的未读消息提示图标，例如可以是红色的“8”。

步骤140、将各维度类别下目标消息的数量发送至消息接收端，以使消息接收端在各维度类别所对应标识的关联位置展示对应维度类别下未读消息的数量。其中，所述维度类别包括业务场景类别；所述业务场景类别包括下述至少一种：医疗会诊业务、医疗复诊业务以及医疗咨询业务。

具体的，各维度类别所对应标识具体可以是图标，例如与张三本人在医疗会诊业务场景下对应图标1，与张三本人在医疗复诊业务场景下对应图标2，与张三本人在医疗咨询业务场景下对应图标3，与张三母亲在医疗咨询业务下对应图标4等。不同的患者在不同业务场景类别下对应不同的图标，对应的未读消息数量可以展示在对应图标的右上角或者左上角等位置，通过触发对应图标可以激活对应的聊天界面，并在该聊天界面显示对应的消息，实现根据消息所属的业务场景类别以及用户类别进行单独显示，以方便医生或者患者及时捕获消息所传达的内容，提高沟通效率的目的。

进一步的，所述未读消息处理方法还包括：

当接收到特定维度类别的标识时，记录当前接收时刻；

将所述特定维度类别下、当前接收时刻之前消息的状态设置为已读状态，以使消息接收端更新展示于所述特定维度类别所对应标识的关联位置处未读消息的数量。

进一步的，若目标在线用户进入或者退出特定维度类别对应的聊天界面时，所述目标在线用户的消息接收端向消息服务端发送所述特定维度类别的标识。

示例性的，参考图2所示的一种未读消息数量的处理方法流程示意图，具体包括：用户通过手机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维，也可以多维，只要注册好维度和规则，就可以按照自己的业务需求来过滤消息，并且不同维度之间的消息隔离显示。

本实施例的技术方案，实现了根据维度类别对未读消息进行分类与统计的目的，进而使app对各维度类别下未读消息的数量进行分开提示，提高了用户的使用体验。

实施例二

在上述实施例技术方案的基础上，参考图3所示的另一种未读消息处理方法的流程示意图，本实施例对上述步骤130“根据所述在线用户关联的维度类别标识对所述目标消息进行分类，以确定各维度类别下目标消息的数量”进行了进一步细化，具体是给出了一种可选的实施方式。其中与上述实施例相同或相应的术语的解释在此不再赘述。

参见图3，本实施例提供的未读消息处理方法具体包括以下步骤：

步骤310、接收各消息发送端发送的消息，并将所述消息的状态设置为未读状态。

步骤320、根据消息接收端在线用户的用户标识确定与所述在线用户关联的目标消息。

步骤330、对所述目标消息进行解析，获取所述目标消息的扩展字段数据；根据所述扩展字段数据以及所述在线用户关联的维度类别标识确定各维度类别下目标消息的数量。

其中，所述消息在被消息发送端发送时，在消息的扩展字段添加了用于标识消息所属维度类别的数据。不同业务方的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，表示当前张三母亲在进行关于医疗咨询业务的沟通。

具体的，在进行app开发时，预先制定消息的分类规则，通常包括维度类别和过滤规则。例如定义两个接口，其中一个为维度类别接口，根据业务的实际情况来划分几个维度，例如业务场景类别和用户类别两个维度。

维度类别接口的代码实现具体可以为：

(level＜t)：+opration()：returnt

-leve：int

-next：level

维度类别接口的链式链接可参考图4所示。

过滤规则接口的代码实现具体可以为：

(rule＜t)：+computerule(tt)：returnboolean

过滤规则的实现类与维度类别对应，不同的维度类别对应的过滤规则可以不同，例如第一个维度--业务场景类别对应的过滤规则可以为：

rule1<bean1>：+computerule(bean1t)：returnboolean

根据传入的string类型的参数，判断业务编号，如果当前的业务编号为4，则代表当前的消息是医疗复诊业务的消息，如果type＝curtype，则返回true，如果type≠curtype，则返回false。所以通过逻辑判断如果返回结果为true，则表示消息与当前聊天界面的业务场景类别相同，则显示消息，如果是false，则表示消息与当前聊天界面的业务场景类别不同，程序终止。

第二个维度--用户类别对应的过滤规则可以是：

rule2<bean>：+computerule(beant)：returnboolean

这个维度的过滤规则是判断用户idtargetid是否和当前用户的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>>＝newhashmap()

+getrule(level＜t>.classi)：rule＜t>

-registerule(level＜t>.classi，rule＜t>r)

通常app的消息分类规则是预先设定好的，因此在app的application中注册相应的维度和过滤规则对象即可，其中，以过滤维度类别的字节码为key，获取到对应的过滤规则的对象实例。

在发送消息时，可以通过两种方式对消息进行处理，其中一种是每次发送消息时，在消息的扩展字段里面添加分类规则，根据业务需求定义几个维度，就向消息的扩展字段中添加几个维度对象，每个维度对象的next字段都指定一个维度对象。第二种方式，在消息的预处理方法中进行处理，通常在进行消息发送时都会对消息进行一定的预处理，具体是调用预处理接口实现，因此可以将在扩展字段中添加分类规则的操作设置在预处理方法中，每次对消息进行预处理时捎带对消息的扩展字段进行分类规则的添加，此时无需关注消息类型是字符、图片还是语音，只关注扩展字段即可，处理效率与稳定性较高。

在消息发送时，对消息进行处理的代码实现流程图可参考图6所示，将具体的分类规则转换成json，然后赋值给消息的extra字段。

步骤340、将各维度类别下目标消息的数量发送至消息接收端，以使消息接收端在各维度类别所对应标识的关联位置展示对应维度类别下未读消息的数量。

其中，所述维度类别包括业务场景类别和/或用户类别。进一步的，可参考图7所示的一种消息发送端、消息接收端、消息服务端相互配合工作的未读消息处理流程示意图，具体包括：

步骤301、制定消息分类的规则，主要分为维度和过滤规则；

步骤302、在应用的全局变量中注册规则；

步骤303、发送消息时将规则信息加入到扩展字段中；

步骤304、接收消息时对消息的扩展字段进行处理；

步骤305、点击通知栏的跳转处理；

步骤306、im聊天界面的显示规则；

步骤307、历史消息查询的处理；

步骤308、未读消息数量的处理；

步骤309、其它业务入口的处理。

其中，步骤307、历史消息查询的处理具体指当app更换手机然后登录新手机的app时，本地数据库中并没有聊天数据，这时会从远程服务端拉取聊天消息，处理方式同样是先保存到本地数据库中，此时聊天消息也是没有分类的，然后像步骤306一样，按照维度和过滤规则来确定是否显示聊天消息，以及如何显示聊天消息，具体是先根据消息的扩展字段确定消息所属的维度类别，然后将消息显示在相应维度类别的im聊天界面中。

本实施例的技术方案，实现了根据消息的扩展字段数据确定消息所属的维度类别，然后将消息所属的维度类别与在线用户关联的维度类别标识进行比对，确定在线用户关联的维度类别下未读消息的数量，达到了对未读消息进行分类与统计的目的，app对各维度类别下未读消息的数量进行分开提示，提高了用户的使用体验。

以下是本发明实施例提供的未读消息处理装置的实施例，该装置与上述各实施例的未读消息处理方法属于同一个发明构思，在未读消息处理装置的实施例中未详尽描述的细节内容，可以参考上述未读消息处理方法的实施例。

实施例三

图8为本发明实施例三提供的一种未读消息处理装置的结构示意图，该装置集成于消息服务端，如图8所示，该装置具体包括：接收模块810、确定模块820、分类模块830和发送模块840。

其中，接收模块810，用于接收各消息发送端发送的消息，并将所述消息的状态设置为未读状态；确定模块820，用于根据消息接收端在线用户的用户标识确定与所述在线用户关联的目标消息；分类模块830，用于根据所述在线用户关联的维度类别标识对所述目标消息进行分类，以确定各维度类别下目标消息的数量；发送模块840，用于将各维度类别下目标消息的数量发送至消息接收端，以使消息接收端在各维度类别所对应标识的关联位置展示对应维度类别下未读消息的数量；其中，所述维度类别包括业务场景类别和/或用户类别；所述业务场景类别包括下述至少一种：医疗会诊业务、医疗复诊业务以及医疗咨询业务。

进一步的，所述装置还包括：

记录模块，用于当接收到特定维度类别的标识时，记录当前接收时刻；

设置模块，用于将所述特定维度类别下、当前接收时刻之前消息的状态设置为已读状态，以使消息接收端更新展示于所述特定维度类别所对应标识的关联位置处未读消息的数量。

进一步的，若目标在线用户进入或者退出特定维度类别对应的聊天界面时，所述目标在线用户的消息接收端向消息服务端发送所述特定维度类别的标识。

进一步的，分类模块830包括：

解析单元，用于对所述目标消息进行解析，获取所述目标消息的扩展字段数据；

确定单元，用于根据所述扩展字段数据以及所述在线用户关联的维度类别标识确定各维度类别下目标消息的数量。

进一步的，所述维度类别还包括：用户类别。

本实施例的技术方案，实现了根据维度类别对未读消息进行分类与统计的目的，app对各维度类别下未读消息的数量进行分开提示，提高了用户的使用体验。

本发明实施例所提供的未读消息处理装置可执行本发明任意实施例所提供的未读消息处理方法，具备执行未读消息处理方法相应的功能模块和有益效果。

实施例四

图9为本发明实施例四提供的一种电子设备的结构示意图。图9示出了适于用来实现本发明实施方式的示例性电子设备12的框图。图9显示的电子设备12仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图9所示，电子设备12以通用计算电子设备的形式表现。电子设备12的组件可以包括但不限于：一个或者多个处理器或者处理单元16，系统存储器28，连接不同系统组件(包括系统存储器28和处理单元16)的总线18。

总线18表示几类总线结构中的一种或多种，包括存储器总线或者存储器控制器，外围总线，图形加速端口，处理器或者使用多种总线结构中的任意总线结构的局域总线。举例来说，这些体系结构包括但不限于工业标准体系结构(isa)总线，微通道体系结构(mac)总线，增强型isa总线、视频电子标准协会(vesa)局域总线以及外围组件互连(pci)总线。

电子设备12典型地包括多种计算机系统可读介质。这些介质可以是任何能够被电子设备12访问的可用介质，包括易失性和非易失性介质，可移动的和不可移动的介质。

系统存储器28可以包括易失性存储器形式的计算机系统可读介质，例如随机存取存储器(ram)30和/或高速缓存存储器32。电子设备12可以进一步包括其它可移动/不可移动的、易失性/非易失性计算机系统存储介质。仅作为举例，存储系统34可以用于读写不可移动的、非易失性磁介质(图9未显示，通常称为“硬盘驱动器”)。尽管图9中未示出，可以提供用于对可移动非易失性磁盘(例如“软盘”)读写的磁盘驱动器，以及对可移动非易失性光盘(例如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)，连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。

本领域普通技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个计算装置上，或者分布在多个计算装置所组成的网络上，可选地，他们可以用计算机装置可执行的程序代码来实现，从而可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件的结合。

注意，上述仅为本发明的较佳实施例及所运用技术原理。本领域技术人员会理解，本发明不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此，虽然通过以上实施例对本发明进行了较为详细的说明，但是本发明不仅仅限于以上实施例，在不脱离本发明构思的情况下，还可以包括更多其他等效实施例，而本发明的范围由所附的权利要求范围决定。