一种生成消息索引以便向接收者呈现消息的方法及装置制造方法
【专利摘要】一种生成消息索引以便向接收者呈现消息的方法，该方法包括：生成待发布的消息；检测所述消息的接收者的状态；以及基于所述接收者的不同状态，在不同的时刻生成与所述消息相对应的消息索引并将所述消息索引拷贝到所述接收者的消息索引队列中。根据本申请的技术方案，通过依据消息接收者的不同状态，在不同时刻生成消息索引以便向接收者呈现消息，减少了消息发送中的资源消耗，提高了消息的时效性，使得用户得到的消息更多，大大提升了用户体验。对于在线用户可以及时的看到他们关注或者他们好友产生的消息，对于离线用户他们也不会错过他们关注或他们好友产生的消息。
【专利说明】一种生成消息索引以便向接收者呈现消息的方法及装置
【技术领域】
[0001] 本申请涉及计算机网络领域，尤其涉及一种生成消息索引以便向接收者呈现消息 的方法及装置。
【背景技术】
[0002] 随着互联网技术的进步，人们更多地使用SNS (社交网络服务)网站，同时SNS网站 的功能和应用也越来越多，动态/消息（Feed)的传播也成为SNS网站最基础的一项服务， 例如，在SNS网站中用户可以发布自己的动态/消息，然后使用SNS系统将动态/消息发送 给好友或粉丝，让他们可以看到。
[0003] 目前动态/消息发送的系统有推送和拉取模式，动态/消息的推模式是指当用户 产生了一个动态/消息之后，系统会将该动态/消息实时地推送给其好友或者粉丝(消息接 收者)，而动态/消息的拉模式是指当用户产生了一个动态/消息之后，系统不会马上将这 个动态/消息推送给其好友或者粉丝，而是等到其好友或者粉丝主动访问SNS网站时，来拉 取这条动态/消息。目前的消息传送方法主要是如下方式：对于粉丝或者好友比较少的用 户，该系统采用推送模式传播动态/消息，而对于粉丝或者好友比较多的用户，该系统则采 用拉模式推送动态/消息。
[0004] 对于以上的现有技术，其中存在两个问题：一是，活跃用户（使用SNS网站比较频 繁的用户)在整个SNS用户中占比比较小，而非活跃用户由于不经常访问SNS系统，因此，针 对这部分人的推送在消耗计算资源的同时，没有得到应有的回报；二是，由于每个热门用户 (粉丝或好友比较多的用户）能够被拉取的动态/消息有比较严格的数量限制，而随着SNS 中热门用户数量的增加，关注热门用户或者是热门用户好友的用户越来越多，因此可能会 导致热门用户产生的动态/消息时效性过短（热门用户之前产生的动态/消息会很快被新 产生的动态替换掉），这样能够看到这些动态/消息的人就会比较少，而由于目前的传播机 制，这一点对于活跃用户和非活跃用户来说是一样的。
[0005] 综上所述，针对现有技术中存在的消息发送资源消耗大，消息的时效性过短的问 题，有必要提出改进的技术方案来解决上述问题。
【发明内容】
[0006] 本申请为克服上述缺陷，提供一种生成消息索引以便向接收者呈现消息的方法和 装置，以解决在消息发送资源消耗大，消息的时效性过短的问题。
[0007] 根据本申请的一个方面，一种生成消息索引以便向接收者呈现消息的方法，该方 法包括：生成待发布的消息；检测所述消息的接收者的状态；以及基于所述接收者的不同 状态，在不同的时刻生成与所述消息相对应的消息索引，并将所述消息索引拷贝到所述接 收者的消息索引队列中。
[0008] 根据本申请实施例的方法，还包括：当生成所述消息时接收者的状态为在线时，则 在生成所述消息时生成与所述消息对应的消息索引并将所述消息索引拷贝到所述接收者 的消息索引队列中。
[0009] 根据本申请实施例的方法，还包括：当生成所述消息时接收者的状态为离线，如果 所述接收者的状态在所述消息被生成之后的预定时刻仍然为离线，则在所述预定时刻生成 与所述消息对应的消息索引并将所述消息索引拷贝到所述接收者的消息索引队列中。
[0010] 根据本申请实施例的方法，还包括：当生成所述消息时接收者的状态为离线，如果 所述接收者的状态在所述消息被生成之后的预定时刻之前变为在线，则在所述接收者的状 态变为在线时生成与所述消息对应的消息索引并将所述消息索引拷贝到所述接收者的消 息索引队列中。
[0011] 根据本申请实施例的方法，其中，所述预订时刻为每天的预订时刻。
[0012] 根据本申请实施例的方法，还包括：当所述接收者在线时基于所述消息索引队列 中的消息索引将所述消息向所述接收者进行呈现
[0013] 根据本申请的另一个方面，一种生成消息索引以便向接收者呈现消息的装置，该 装置包括：消息生成模块，用于生成待发布的消息；检测模块，用于检测所述消息的接收者 的状态；以及消息索引生成及拷贝模块，用于基于所述接收者的不同状态，在不同的时刻生 成与所述消息相对应的消息索引并将所述消息索引拷贝到所述接收者的消息索引队列中。
[0014] 根据本申请的实施例，在所述装置中，当生成所述消息时接收者的状态为在线，则 在生成所述消息时生成与所述消息对应的消息索引并将所述消息索引拷贝到所述接收者 的消息索引队列中。
[0015] 根据本申请的实施例，在所述装置中，当生成所述消息时接收者的状态为离线，如 果所述接收者的状态在所述消息被生成之后的预定时刻仍然为离线，则在所述预定时刻生 成与所述消息对应的消息索引并将所述消息索引拷贝到所述接收者的消息索引队列中。
[0016] 根据本申请的实施例，在所述装置中，生成所述消息时接收者的状态为离线，如果 所述接收者的状态在所述消息被生成之后的预定时刻之前变为在线，则在所述接收者的状 态变为在线时生成与所述消息对应的消息索引并将所述消息索引拷贝到所述接收者的消 息索引队列中。
[0017] 与现有技术相比，根据本申请的技术方案，能够通过避免给非活跃用户发送消息 来回收这部分计算资源，同时对于活跃用户，他们所关注或者他们的好友所产生的消息，特 别是其中的热门用户所产生的消息，这些消息的实效性将会更长，所以活跃用户将能够比 非活跃用户看到更多的动态。对于在线用户可以及时的看到他们关注或者他们好友产生的 消息，对于离线用户他们也不会错过他们关注或他们好友产生的消息。
【专利附图】
【附图说明】
[0018] 此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申 请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：
[0019] 图1是根据本申请实施例的一种生成消息索引以便向接收者呈现消息的方法的 流程图；
[0020] 图2是根据本申请实施例的实时推送模式的流程图；
[0021] 图3是根据本申请实施例的离线拉取模式的流程图；
[0022] 图4是根据本申请实施例的实时拉取模式的流程图；
[0023] 图5是根据本申请实施例的实时拉取模式和离线拉取模式的子系统的示意图；以 及
[0024] 图6是根据本申请实施例的一种生成消息索引以便向接收者呈现消息的装置的 结构框图。
【具体实施方式】
[0025] 本申请的主要思想在于，通过对不同状态的消息接收者在不同时刻生成与消息对 应的消息索引，以便向接收者进行消息呈现，这减少了消息发送中的资源消耗，提高了消息 的时效性，使得用户得到的消息更多，大大提升了用户体验。
[0026] 为了更好地理解本申请，应当注意，根据本发明的实施例，术语"社交网站"或"社 交网络"（social network)是指向对特定对象感兴趣或只是一起"闲逛"的人们提供虚拟 社区的Web站点。成员通过语音、聊天、即时消息、视频会议和博客等进行通信，并且该服务 通常向成员提供了联系其他成员的好友的方法。这种站点还可以用作亲自会面的媒介。"社 交网站"或"社交网络"是针对"虚拟社区"（一群人使用因特网彼此之间就任何事乃至所有 事进行通信）的21世纪术语。
[0027] 社交网络向其用户（也可称为成员）提供与该社交网络的其他成员进行通信和交 互的能力。在使用中，成员加入社交网络，继而向其希望连接的多个其他成员添加连接。连 接可以由成员显式地添加，例如成员选择将要成为好友的特定其他成员；或者基于成员的 共同特征(例如，相同教育机构的校友)而由社交网络自动创建。如在此使用的，术语"好友" 是指成员通过该网站与之形成连接、关联或者关系的任何其他成员。社交网络中的连接通 常是双向的(但这不是必须的)，因此，术语"成员"、"用户"、和"好友"可能依赖于参照系。另 夕卜，术语"好友"并非必须要求成员在现实生活中实际上是朋友(在成员之一是商户或者其 他实体时，一般更是这样）；其仅表明在社交网络中存在的连接关系。
[0028] 此外，在本申请中，发出动态/消息的用户可以称为发布者，而接收该动态/消息 的用户/成员/好友可以称为接收者。可以理解，发布者和接收者是相对而言的，也即是说， 对于某一条动态/消息而言，A用户是发布者，B用户是接收者；但是，对于另一条动态/消 息而言，A用户可能是接收者、B用户可能是发布者。
[0029] 现在，将在下文中参考附图更全面地描述本发明的示例实施例，附图中示出了本 发明的某些而不是所有实施例。实际上，本发明可以体现为很多不同的形式并且不应当解 释为限于在此阐明的实施例；相反，提供这些实施例从而使得本公开内容将满足适用的法 律要求。贯穿说明书，类似的参考标号指代类似的元素。基于本申请中的实施例，本领域普 通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的 范围。
[0030] 针对现有技术中消息发送资源消耗大、消息的时效性过短的问题，本申请的实施 例提供一种生成消息索引以便向接收者呈现消息的方法，图1是根据本申请实施例的一种 生成消息索引以便向接收者呈现消息的方法的流程图，该方法包括以下步骤。
[0031] 在步骤S101处，生成待发布的消息。用户在使用SNS网站时，如果要发布自己的 消息，就是在SNS系统中指定位置输入自己要发布的消息并点击发布，用户在该指定位置 输入自己要发布的消息，即可以是用户自己输入的，也可以是用户转发而输入的。这时系统 会记录下用户输入的消息，并生成一条待发布的消息。接下来，该方法进行到步骤S102。
[0032] 在步骤S102处，检测所述消息的接收者的状态。消息发布的时候，会对该消息的 接收者状态进行检测，检测消息接收者的状态是在线还是离线，再依据接收者不同的状态 进行不同的处理。
[0033] 在步骤S103处，基于所述接收者的状态，在不同时刻生成与所述消息相对应的消 息索引，并将所述消息索引拷贝到所述接收者的消息索引队列中。这里的接收者可以是消 息发布者的粉丝或好友。在消息发布者发布消息时，接收者的状态为在线状态或是离线状 态，则基于不同的状态，可以在不同的时刻生成对应消息的消息索引，并将所述消息索引拷 贝到所述接收者的消息索引队列中，基于接收者的状态不同，生成及拷贝的时刻也不同，就 形成了不同的生成及拷贝方式。其中，不同的生成及拷贝方式可以包括实时推送模式、离线 拉取模式以及实时拉取模式或以上模式的相互组合等。下面结合图2、图3和图4分别对本 申请的不同模式做进一步的详细说明。
[0034] 参考图2,图2是根据本申请实施例的实时推送模式的流程图。在图2中步骤S201 与图1中的步骤S101类似，生成待发布的消息。由消息发布者进行消息的输入以进行发送， 在步骤S201处，根据消息发布者输入的消息生成待发布的消息。
[0035] 在步骤S202处，系统检测接收者的状态，并判断消息发布者发布消息时接收者的 状态是否为在线状态。如果接收者的状态为在线状态，则以实时推送的模式对消息索引进 行生成及拷贝。即当生成所述消息时接收者的状态为在线状态，则在生成消息时生成与所 述消息对应的消息索引并将所述消息索引拷贝到所述接收者的消息索引队列中。
[0036] 接着进行到步骤S203,生成与所述消息对应的消息索引。当消息发布者发布消息 时，系统会把消息内容存储在数据库中，这些存储下来的消息就是消息本体。在要对消息进 行发送时，会根据消息本体生成与之对应的消息索引，发送时只需对消息索引进行生成及 拷贝，不需要对消息本体直接发送，消息索引的大小很小，这样就大大节约了发送的资源， 对于需要对多个接收者进行消息发送的，则将会生成多个消息索引的副本，用来将消息发 送个多个接收者。
[0037] 生成消息索引后进行到步骤S204,将所述消息索引拷贝到所述接收者的消息索引 队列中。接收者能看到的消息条数和消息内容取决于接收者消息索引队列中保存有哪些消 息索引。
[0038] 然后进行到步骤S205,基于所述消息索引，将所述消息向所述接收者进行发送。依 据消息索引从数据库中找到对应的消息本体，再以一定的格式将消息本体向接收者呈现， 最终完成消息发送的工作。
[0039] 接下来对图3进行参考，图3是根据本申请实施例的离线拉取模式的流程图。在 图3中步骤S301与图1中的步骤S101类似，生成待发布的消息。由消息发布者进行消息 的输入以进行发送，在步骤S301处，根据消息发布者输入的消息，生成待发布的消息。
[0040] 在步骤S302处，系统检测接收者的状态，并判断消息发布者发布消息时接收者的 状态是否为在线状态。如果接收者的状态为离线状态，则进行步骤S303,判断接收者的状 态在消息发布后的预定时刻之前是否变为在线。如果接收者在消息发布后的预定时刻之前 一直为离线状态，则以离线拉取的模式对消息索引进行生成及拷贝。即当生成所述消息时 接收者的状态为离线，如果所述接收者的状态在所述消息被生成之后的预定时刻仍然为离 线，则在所述预定时刻生成与所述消息对应的消息索引，并将所述消息索引拷贝到所述接 收者的消息索引队列中，当所述接收者的状态变为在线时，基于所述消息索引，将所述消息 向所述接收者进行呈现。
[0041] 根据本申请的实施例，预订时刻可以为每天的预订时刻，例如，每天的零点，或者 预定时刻可以选择为系统负担小的时刻，这样在预定时刻为离线用户进行消息发送时会减 少系统资源的压力，让消息发送效果更好。在本申请中预定时刻还可以是任意适当的时刻， 可以为间隔不同时间段的时刻，也可以为间隔固定时间段的时刻。另外，预定时刻也可以是 连续的时刻，即离线拉取模式可以一直处于运行状态，这样可以减少实时拉取模式所需要 获取的数据量，从而加速系统的响应时间，但也会给整个系统带来额外的负载。
[0042] 消息发布后，因为现有的技术中对消息保存的时间和数目都有限，如果接收者离 线的时间过长，此消息会被新的消息或太多的消息所替换，那么在接收者下一次在线的时 候就无法看到此条消息，于是在本申请中会在预定时刻对接收者离线的这段时间中需要接 收的消息进行离线拉取，并保存消息索引，这样在接收者下一次在线时就能看到他在离线 时他所关注或他好友的所有产生的消息。具体而言，在步骤S303判断接收者的状态在消息 发布后的预定时刻之前没有变为在线，则该方法进行到步骤S304。
[0043] 在步骤S304处，在所述预定时刻生成与所述消息对应的消息索引。例如，可以在 每天的预定时刻对接收者所要接收的消息都会进行拉取工作，于是对于每条消息，在该预 定时刻就会生成与之对应的消息索引。
[0044] 然后进行到步骤S305,将所述消息索引拷贝到所述接收者的消息索引队列中。可 参照步骤S204。
[0045] 接着进行到步骤S306,当所述接收者的状态变为在线时，基于所述消息索引，将所 述消息向所述接收者进行呈现。可参照步骤S205。这样也就完成了消息的发送工作。
[0046] 参考图4,图4是根据本申请实施例的实时拉取模式的流程图。在图3中步骤S401 与图1中的步骤S101类似，生成待发布的消息。由消息发布者进行消息的输入以进行发送， 在步骤S401处，根据消息发布者输入的消息，生成待发布的消息。
[0047] 在步骤S402处，系统检测接收者的状态，并判断消息发布者发布消息时接收者的 状态是否为在线状态。如果接收者的状态为离线状态，则进行步骤S403,判断接收者的状 态在消息发布后的预定时刻之前是否变为在线。如果接收者在消息发布后的预定时刻之前 变为在线状态，则以实时拉取的模式对消息索引进行生成及拷贝。即当生成所述消息时接 收者的状态为离线，如果所述接收者的状态在所述消息被生成之后的预定时刻之前变为在 线，则在所述接收者的状态变为在线时，生成与所述消息对应的消息索引，并将所述消息索 引拷贝到所述接收者的消息索引队列中，基于所述消息索引将所述消息向所述接收者进行 呈现。
[0048] 如果接收者从离线状态变为在线状态所间隔的时间比较短，即在预定时刻之前就 变为在线状态，这时接收者所要接收的消息并没有超过预定的保存时间和保存数目，所以 可以通过实时拉取的模式对消息索引进行生成及拷贝。具体而言，在步骤S403判断接收者 的状态在消息发布后的预定时刻之前已经变为在线，则该方法进行到步骤S404。
[0049] 在步骤S404处，在所述接收者的状态变为在线时，生成与所述消息对应的消息索 引。
[0050] 然后进行到步骤S405,将所述消息索引拷贝到所述接收者的消息索引队列中。可 参照步骤S204。
[0051] 接着进行到步骤S406,基于所述消息索引，将所述消息向所述接收者进行发送。可 参照步骤S205。这样也就完成了该消息的发送工作。
[0052] 对于上述实时推送模式、离线拉取模式和实时拉取模式在消息索引生成及拷贝的 方法中也可以相互协作、相互补充。例如，图5中所示的消息索引生成及拷贝方法。图5是 根据本申请实施例的实时拉取模式和离线拉取模式的子系统的示意图。
[0053] 在图5中所示的系统中，离线拉取模式子系统采用离线拉取模式进行消息发送， 实时拉取模式子系统采用实时拉取模式进行消息发送。
[0054] 离线拉取模式子系统可以在某个固定时间（例如，在每天的某个固定时刻，例如， 系统负担较轻的时刻）开始运行以获取相关消息数据，将消息索引生成及拷贝给那些在实 时推送模式下没有接收到消息的接收者，然后将每个接收者对于其粉丝和好友的最后一次 拉取的时间信息记录下来。
[0055] 接收者状态变为在线后，开始执行实时拉取模式子系统，由于预定时刻的设定，所 以接收者变为在线的时间可能为两次离线拉取子系统执行时间的中间，这样在第一次执行 离线拉取子系统到接收者变为在线的这一段时间内用户产生的消息就由实时拉取子系统 进行获取，这时，实时拉取子系统就会根据上面离线拉取子系统记录下来的接收者最后一 次拉取的时间信息，进行消息索引的获取。这样实时拉取子系统获得的消息索引连同离线 拉取子系统获得的消息索引都在接收者的消息索引队列中，再根据消息索引队列中的消息 索引向接收者进行消息呈现。
[0056] 由于离线拉取模式子系统的存在，使得需要经过实时拉取模式子系统拉取的数据 量就会比较有限，从而提高了整个系统的性能和稳定性。
[0057] 上述只是本申请的一个实施例，本申请还有其他实施例的变形，对于多种发送模 式的相结合或单个执行以达到消息发送的目的都属于本申请的保护范围。
[0058] 根据本申请的一个实施例，本申请还提供一种生成消息索引以便向接收者呈现消 息的装置。具体可以参考图6,图6是根据本申请实施例的一种生成消息索引以便向接收者 呈现的装置的结构框图。该装置可以包括：消息生成模块10、检测模块20和消息索引生成 及拷贝模块30,消息呈现模块70。消息生成模块10可以用于生成待发布的消息。消息发 布者进行消息内容输入并点击发布后，系统会根据输入的内容生成待发布的消息。
[0059] 检测模块20可以用于检测所述消息的接收者的状态。消息发布的时候，会对该消 息的接收者状态进行检测，检测用户的状态是在线还是离线，再依据接收者不同的状态进 行不同的处理。
[0060] 消息索引生成及拷贝模块30可以用于基于所述接收者的状态，在不同时刻生成 与所述消息相对应的消息索引，并将所述消息索引拷贝到所述接收者的消息索引队列中。 得到待发布的消息后，根据接收者的状态，接收者是否在线或消息发布后的预定时刻之前 接收者是否变为在线状态，基于接收者不同的状态，可以在不同的时刻生成对应消息的消 息索引，并将所述消息索引拷贝到所述接收者的消息索引队列中，基于接收者的状态不同， 生成及拷贝的时刻也不同，就形成了不同的生成及拷贝方式。不同生成及拷贝方式包括实 时推送模式、离线拉取模式以及实时拉取模式或以上模式的相互组合等。
[0061] 消息呈现模块70可以用于当所述接收者在线时，基于所述消息索引队列中的消 息索引将所述消息向所述接收者进行呈现。当接收者变为在线时，根据接收者消息索引队 列中的消息索引，到数据库中找到与之对应的消息本体，再以一定的格式将消息本体向接 收者进行呈现。
[0062] 根据本申请的实施例，其中，消息索引生成及拷贝模块30还可以包括：实时推送 模块40、离线拉取模块50和实时拉取模块60。
[0063] 实时推送模块40可以被配置成当生成所述消息时接收者的状态为在线，则生成 与所述消息对应的消息索引，并将所述消息索引拷贝到所述接收者的消息索引队列中。
[0064] 离线拉取模块50可以被配置成当生成所述消息时接收者的状态为离线，如果所 述接收者的状态在所述消息被生成之后的预定时刻仍然为离线，则在所述预定时刻生成与 所述消息对应的消息索引，并将所述消息索引拷贝到所述接收者的消息索引队列中。
[0065] 实时拉取模块60可以被配置成生成所述消息时接收者的状态为离线，如果所述 接收者的状态在所述消息被生成之后的预定时刻之前变为在线，则在所述接收者的状态变 为在线时，生成与所述消息对应的消息索弓丨，并将所述消息索引拷贝到所述接收者的消息 索引队列中。
[0066] 由于本实施例的装置所实现的功能基本相应于前述图1-图5所示的方法实施例， 故本实施例的描述中未详尽之处，可以参见前述实施例中的相关说明，在此不做赘述。
[0067] 本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序 模块或单元。一般地，程序模块或单元可以包括执行特定任务或实现特定抽象数据类型的 例程、程序、对象、组件、数据结构等等。一般来说，程序模块或单元可以由软件、硬件或两者 的结合来实现。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过 通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块或单元可 以位于包括存储设备在内的本地和远程计算机存储介质中。
[0068] 最后，还需要说明的是，术语"包括"、"包含"或者其任何其他变体意在涵盖非排他 性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且 还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的 要素。在没有更多限制的情况下，由语句"包括一个……"限定的要素，并不排除在包括所 述要素的过程、方法、商品或者设备中还存在另外的相同要素。
[0069] 本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说 明只是用于帮助理解本申请的方法及其主要思想；同时，对于本领域的一般技术人员，依据 本申请的思想，在【具体实施方式】及应用范围上均会有改变之处，凡在本申请的精神和原则 之内，所作的任何修改、等同替换、改进等，均应包括在本申请的权利要求范围之内。综上所 述，本说明书内容不应理解为对本申请的限制。
[0070] 本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序 产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实 施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机 可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等）上实施的计算机程序产 品的形式。
[0071] 在一个典型的配置中，计算设备包括一个或多个处理器（CPU)、输入/输出接口、 网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器 (RAM)和/或非易失性内存等形式，如只读存储器（ROM)或闪存（flash RAM)。内存是计算 机可读介质的示例。
[0072] 计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法 或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。 计算机的存储介质的例子包括，但不限于相变内存（PRAM)、静态随机存取存储器（SRAM)、 动态随机存取存储器（DRAM)、其他类型的随机存取存储器（RAM)、只读存储器（ROM)、电 可擦除可编程只读存储器（EEPR0M)、快闪记忆体或其他内存技术、只读光盘只读存储器 (CD-ROM)、数字多功能光盘（DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁 性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中 的界定，计算机可读介质不包括暂存电脑可读媒体（transitory media),如调制的数据信 号和载波。
[0073] 以上所述仅为本申请的实施例而已，并不用于限制本申请，对于本领域的技术人 员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、 等同替换、改进等，均应包含在本申请的权利要求范围之内。
【权利要求】
1. 一种生成消息索引以便向接收者呈现消息的方法，其特征在于，该方法包括： 生成待发布的消息； 检测所述消息的接收者的状态；以及 基于所述接收者的不同状态，在不同的时刻生成与所述消息相对应的消息索引，并将 所述消息索引拷贝到所述接收者的消息索引队列中。
2. 根据权利要求1所述的方法，其特征在于，所述消息索引的生成及拷贝的步骤包括： 当生成所述消息时接收者的状态为在线，则在生成所述消息时，生成与所述消息对应 的消息索引并将所述消息索引拷贝到所述接收者的消息索引队列中。
3. 根据权利要求1所述的方法，其特征在于，所述消息索引的生成及拷贝的步骤包括： 当生成所述消息时接收者的状态为离线，如果所述接收者的状态在所述消息被生成之 后的预定时刻仍然为离线，则在所述预定时刻生成与所述消息对应的消息索引并将所述消 息索引拷贝到所述接收者的消息索引队列中。
4. 根据权利要求1所述的方法，其特征在于，所述消息索引的生成及拷贝的步骤包括： 当生成所述消息时接收者的状态为离线，如果所述接收者的状态在所述消息被生成之 后的预定时刻之前变为在线，则在所述接收者的状态变为在线时生成与所述消息对应的消 息索引并将所述消息索引拷贝到所述接收者的消息索引队列中。
5. 根据权利要求3或4所述的方法，其特征在于，所述预订时刻为每天的预订时刻。
6. 根据权利要求2-4所述的方法，其特征在于，还包括：当所述接收者在线或者所述接 收者从离线变成在线时时基于所述消息索引队列中的消息索引将所述消息向所述接收者 进行呈现。
7. -种生成消息索引以便向接收者呈现消息的装置，其特征在于，该装置包括： 消息生成模块，用于生成待发布的消息； 检测模块，用于检测所述消息的接收者的状态；以及 消息索引生成及拷贝模块，用于基于所述接收者的不同状态，在不同的时刻生成与所 述消息相对应的消息索引并将所述消息索引拷贝到所述接收者的消息索引队列中。
8. 根据权利要求7所述的装置，其特征在于，所述消息索引生成及拷贝模块还用于： 当生成所述消息时接收者的状态为在线，则在生成所述消息时生成与所述消息对应的 消息索引并将所述消息索引拷贝到所述接收者的消息索引队列中。
9. 根据权利要求7所述的装置，其特征在于，所述消息索引生成及拷贝模块还用于： 当生成所述消息时接收者的状态为离线，如果所述接收者的状态在所述消息被生成之 后的预定时刻仍然为离线，则在所述预定时刻生成与所述消息对应的消息索引并将所述消 息索引拷贝到所述接收者的消息索引队列中。
10. 根据权利要求7所述的装置，其特征在于，所述消息索引生成及拷贝模块还用于： 当生成所述消息时接收者的状态为离线，如果所述接收者的状态在所述消息被生成之 后的预定时刻之前变为在线，则在所述接收者的状态变为在线时生成与所述消息对应的消 息索引并将所述消息索引拷贝到所述接收者的消息索引队列中。
【文档编号】G06F17/30GK104123296SQ201310149223
【公开日】2014年10月29日 申请日期:2013年4月26日 优先权日:2013年4月26日
【发明者】马天笑 申请人:阿里巴巴集团控股有限公司