在基于对话的电子邮件系统中标注对话和消息的制作方法

专利名称：在基于对话的电子邮件系统中标注对话和消息的制作方法
在基于对话的电子邮件系统中标注对话和消息
本申请是申请日为2005年3月25日、申请号为200580016413.8(国际申请号为 PCT/US2005/010137)、发明名称为“在基于对话的电子邮件系统中显示对话”的发明专利申请的分案申请。技术领域
本发明总体上涉及客户机-服务器计算机网络系统领域，具体地，本发明涉及一种允许用户以有效的和用户界面友好的方式管理大量消息的系统与方法。
背景技术：
为了工作和悠闲，每天，人们在计算机网络上发送和接收数以百万计的电子邮件 (也写为“E-mail”)。在许多情况下，由于方便、容易使用以及近乎瞬间完成，电子邮件已成为人们交换信息的极为流行的通信渠道。
传统上，到达用户电子邮件账户的电子邮件消息以时间顺序由专用电子邮件客户机或者在Web浏览器窗口中单独地显示，例如，最近的消息出现在浏览器窗口的顶部，而最旧的消息出现在浏览器窗口的底部。然而，普遍的现象是，在不同时刻，由两个或两个以上的人发送的多条消息可能覆盖相同的标题。一起查看消息，将有助于用户按适当的上下文理解各条消息。
人们特别希望具有一种根据它们各自的主题来组织和显示多条消息的系统与方法，该多条消息包括由用户接收的消息和由用户发送的消息。人们还特别希望涉及相同标题的所有消息和相同对话的形成部分被直观地显现，使得用户能够有效地标识由具体发送者所提交的具体消息，以及使得用户相对于对话中的其它消息，能够在上下文中知道该对话中的这些消息。发明内容
在一个实施例中，一种处理消息的方法，接收导向用户的多条消息，其中，每条消息具有唯一的消息标识符。所述多条消息中的每一条消息与各自的对话相关联，其中，每一对话具有各自的对话标识符。而且，每一对话包括一条或多条消息的集合，其共享满足第一预先定义准则的公共特征集合。按第二预先定义准则所确定的次序，作为行集合，显示对话的列表，其中，每行对应于所列对话的一个，并且至少包括发送者列表、对话标题以及日期/ 时间值。当用户从所显示的对话列表中选择对话时，就显示对话的内容。
根据本发明的一个方面，提供一种管理消息的方法，在具有一个或多个处理器和存储由所述一个或多个处理器执行的程序的存储器的服务器执行，该方法包括存储包括多个消息的对话，其中，所述对话与第一标签相关联并且所述多个消息中的消息与第二标签相关联；从位于远程的客户机系统接收预先定义的请求；以及通过产生并向所述客户机系统发送对话的列表来响应所述预先定义的请求，包括当所述预先定义的请求对应于与第一标签相关联的对话的请求时，按照第一列表中的所有对话都与第一标签相关联的准则，产生并向所述客户机系统发送对话的第一列表，其中，第一列表中的一个或多个对话中的每一个包括多个消息；以及当所述预先定义的请求对应于包括与第二标签相关联的消息的对话的请求时，按照第二列表中的所有对话都包括已经向其分配第二标签的至少一个消息的准则，产生并向所述客户机系统发送对话的第二列表，其中，第二列表中的一个或多个对话中的每一个包括多个消息。
根据本发明的另一个方面，提供一种服务器系统，包括用于存储包括多个消息的对话的装置，其中，所述对话与第一标签相关联并且所述多个消息中的消息与第二标签相关联；用于从位于远程的客户机系统接收预先定义的请求；以及用于通过产生并向所述客户机系统发送对话的列表来响应所述预先定义的请求的装置，包括当所述预先定义的请求对应于与第一标签相关联的对话的请求时，按照第一列表中的所有对话都与第一标签相关联的准则，产生并向所述客户机系统发送对话的第一列表，其中，第一列表中的一个或多个对话中的每一个包括多个消息；以及当所述预先定义的请求对应于包括与第二标签相关联的消息的对话的请求时，按照第二列表中的所有对话都包括已经向其分配第二标签的至少一个消息的准则，产生并向所述客户机系统发送对话的第二列表，其中，第二列表中的一个或多个对话中的每一个包括多个消息。


为了更好地理解本发明的特性与实施例，应结合下列附图，参照以下各实施例的描述，其中，在所有附图中，相同的参照数字指向相同的部分。
图1示意性地说明了根据本发明的基于客户机-服务器的网络系统的一个实施例。
图2是一个总流程图，说明了对话助手如何生成用于显示由对话管理系统提供的对话的各种表格。
图3A是一个流程图，说明了对话助手如何生成容纳对话列表的表格。
图;3B为根据本发明的一个实施例的“收件箱”范畴中的对话列表的示意性屏幕截图(screenshot)0
图4A是一个流程图，说明了“更多动作”下拉列表的操作。
图4B为用户如何使用“更多动作”下拉列表把对话从一个范畴移至另一个范畴的屏幕截图。
图5A是一个流程图，说明了“添加标签”下拉列表的操作。
图5B为用户如何使用“添加标签”下拉列表向对话添加标签的屏幕截图。
图6A是一个流程图，描述了对话助手如何响应对话管理系统的显示指令生成对话视图(view)。
图6B为根据本发明的一个实施例的对话视图的屏幕截图，其中，按压缩模式显示所有的消息。
图6C为根据本发明的一个实施例的对话视图的屏幕截图，其中，按压缩模式显示某些消息，并且按扩展模式显示某些消息。
图6D为根据本发明的一个实施例的对话视图的屏幕截图，其中，按扩展模式显示所有的消息。
图6E为根据本发明的各种实施例的其中显示消息的对话视图的屏幕截图。
图7A为一个流程图，说明了对话助手如何生成用于显示匹配用户的搜索请求的对话的各种表格。
图7B为根据本发明的一个实施例的屏幕截图，其包括与查询项“Tahoe”相匹配的 3个对话。
图7C为根据本发明的一个实施例的、与查询项相匹配或不相匹配的对话中的消息的屏幕截图，而且其中按不同的模式对消息加以显示。
图8为一个流程图，说明了对话助手如何与用户交互，以纠正所有可能错拼的单词。
图9A为包含由用户所编写的回答消息的对话的屏幕截图。
图9B描述了处于拼写检查过程不同阶段的3个独立的浏览窗口的屏幕截图。
图10描述了对话服务器的实施例。
图11是一个流程图，表示了处理所接收的消息的方法。
图12是一个流程图，表示了把消息匹配于对话的方法。
图13是一个流程图，表示了把属性赋予消息的方法。
图14是一个流程图，表示了把属性赋予对话的方法。
图15是一个流程图，表示了用于搜索对话并且生成所标识的对话的表示的方法。
图16描述了消息数据库。
图17描述了用户数据库和用于具体用户的索引。
图18描述了一组数据结构，用于标识对应于所接收消息的对话和用于确定与所接收的消息相关的属性。
图19描述了对话服务器的实施例。
具体实施方式
本发明涉及用于组织和显示发送于用户以及由用户所发送的消息的客户机-服务器系统与对应的方法。
图1示意性地说明了客户机-服务器系统的一个实施例。该系统包括对话管理系统102、通信网络106以及多个客户机104。对话包括覆盖对话标题的一个或多个相关的消息。如以下描述的，除对话标题外，还可以使用附加的准则判断哪些消息为每一不同对话的一部分。消息的发送者和接收者为对话的参与者。把所有导向对话管理系统102的用户的所有消息编组为多个对话，并且按基于对话的格式逐一或共同提交于用户。以下，将给出有关对话管理系统102的实现的更详细的讨论。
客户机104包括浏览器108和对话助手110。浏览器108可以为具有用于显示对话的浏览器窗口的通用hternet浏览器(有时也称为Web浏览器)，其也可以为具有用于显示对话的窗口的专用浏览器应用。浏览器108使用超文本标记语言(HTML)或任何其它适当翻译方法翻译对话和对话中的消息。在用户通过浏览器108向对话管理系统102提交了用于存取存储在其个人账户中的消息的请求之后，对话管理系统102根据用户的请求，标识用户的个人账户中的多个对话，并且将它们以及一组显示指令传送回客户机104。作为响应，对话助手110生成一个或多个跟随显示指令的表格，每一个表格包括某些对话的信息。然后，把表格提交于浏览器108，并且由浏览器108加以翻译。在另一个实施例中，作为选择，对话助手110也可以存在于对话管理系统102中，并且操作于对话管理系统102中。
图2是一个总流程图，说明了对话助手110如何生成用于显示由对话管理系统102 提供的对话的各种表格。在步骤202，在接收了多个对话和相关的显示指令之后，在步骤 204中，对话助手110判断用户是请求了多个对话还是请求了单个对话。如果用户要求多个对话，则在步骤206，对话助手110生成容纳对话列表的表格，每一个对话占据表格中的一行。针对表格中的每一行，在步骤208，对话助手110还根据显示指令生成列集合以及将加以显示的相关的特性。以下，将结合图3A和:3B，给出如何翻译这些列中的信息和相关的特性的更多的细节。
如果用户请求单个对话，则对话助手110在步骤210生成用于容纳一系列与对话相关的消息的不同的表格。在步骤212中，对话助手110针对每一条跟随对应显示指令的消息，生成子表格和将显示的一组相关的特性。以下，将结合6A 6D给出对话助手如何翻译这样的子表格和相关特性的更多的细节。
在生成了用于容纳对话的列表或单个对话的表格之后，在步骤214，对话助手110 生成用于容纳一组系统定义的范畴的表格。可以把每一个系统定义的范畴与0或多个对话相关联。在一个实施例中，系统定义的范畴是这样的属性响应用户动作或当满足预先定义的准则时，对话管理系统102选定对话。例如，当用户把对话标记为删除，但尚未采取永久性地从用户的邮件账户中去除对话所需的步骤时，该系统把“废纸篓”属性与该对话相关联。更具体地讲，如果需要的话，对话管理系统102把属性“废纸篓”附接于对话，并且从对话中去除现存的属性，例如“收件箱”。注意，某些系统定义的范畴可能是互斥的。在另一个例子中，该系统可以自动地把“收件箱”属性和“未被读取”属性与新接收的流入消息相关联。以下，结合图4A和4B，给出对系统定义的范畴的更详细的讨论。
接下来，在步骤216，对话助手110生成容纳一组用户定义的标签的另一个表格。 图3B描述了其中显示了这一表格的编组框347。可以把每一个用户定义的标签与0或多个对话相关联。在一个实施例中，用户定义的标签为可以将其与所指定的对话相关联的属性。可以通过特定的用户动作或者通过过滤器或类似机构的操作，确定用户定义的标签赋予它们的那些对话。与系统定义的范畴不同，由用户任意地定义这些标签，而且它们是不互斥的。换句话说，可以同时把对话与多个标签相关联。例如，在用户的个人账户中，可能存在两个标签“购物列表”和“感恩节”。可以由用户，也可以由用户所建立的过滤器把标签 “购物列表”赋予与购物相关的对话，同时可以把标签“感恩节”赋予有关感恩节活动的对话，包括感恩节购物。由于用户定义了标签，所以用户也可以删除这一标签。以下，结合图 5A和5B，给出了用户定义的标签的更详细的讨论。对于编组框347，当用户选择(例如，点击)了编组框347中的用户定义的标签时，对话助手110把用于定位与该用户选择的标签相关的对话的查询提交于对话管理系统。然后，执行这一查询，并且向用户提交这样的对话的列表，即如果存在这样的对话的列表，则向用户提交这一列表。
对话管理系统102和对话助手110协同运作，以允许用户搜索用户的邮件账户中的消息，并且允许以十分直观的方式提交搜索结果。对话管理系统102从用户的电子邮件账户抽取信息，或者处理由用户编写的消息，同时，对话助手110翻译由对话管理系统102 所准备的信息。在其它实施例中，可以使用在对话管理系统102和对话助手110之间的任务的不同的划分。由于可以通过对话管理系统102或对话助手110，也可以通过这两者的协同运作，实现该系统所执行的许多任务，所以此处有时把这两个部件统称为“对话系统”。
在步骤218，对话系统(102和/或110)可以生成用于容纳由用户所提交的一组搜索的表格，以致用户可以重新访问(或者更精确地说，可以重新生成)新近的搜索结果。以下，结合图7A 7C，给出了基于搜索的对话列表生成的更详细的描述。另外，在步骤220，对话系统还可以生成用于容纳由用户新近访问的一组对话的表格(例如，图3B的编组框349 中所显示的表格)。这一特性类似于Web浏览器的退回按钮。在步骤222，对话助手110把这些表格提交于浏览器108用于显示。
除按图2中所示的次序之外，还可以以多种可能的次序执行步骤214 220。在某些实施例中，可以省略这些表格生成步骤中的某些步骤。
生成对话列表
现在，参照图3A，例如，响应用户或客户机对用户的邮件账户的收件箱视窗的请求，对话管理系统102生成对话列表(步骤30 。如以下将更详细加以解释的，通过执行对用户的邮件账户的搜索，生成对话的列表。为了生成针对收件箱视窗的对话的列表，针对与“收件箱”属性(有时将其称为标签)相关的对话，搜索用户的邮件账户。然后，在步骤 304，对话管理系统102准备有关这些对话的信息，以加以显示，如以下将更详细加以描述的。另外，在步骤305，对话管理系统还生成用户可选择的动作的列表和用户可选择的标签的列表。以下结合图4和5的讨论，说明这些用户可选择列表的使用。然后，在步骤306，把所得结果信息发送于对话助手，以加以翻译。
在步骤304，对话管理系统102反复执行一系列步骤(从步骤306至步骤324)，以生成一组字段用于对话列表中的每一对话。在某些实施例中，可以按列由对话助手110翻译这些字段，以使得用户能够容易地扫描对话列表。
对于每一对话和一组相关的消息，对话管理系统102首先在步骤307生成发送者列表。发送者列表包括多个发送者标识符，每一个标识符对应于已创作了至少一条消息的发送者。可根据其教名、姓、全名、电子邮件地址、照片或唯一的图标，或者它们的组合，来标识发送者。在某些实施例中，如果至少两个发送者具有相同的教名，则把每一发送者的姓的足够的部分包含在相应的发送者标识符中，以互相区别发送者。例如，如果两个发送者均具有教名Paul和第一个字母不同的姓，则可以使用Paul与姓的第一个字母的拼接(例如， PaulB和PaulK)来区别这两个发送者。本技术领域的普通技术人员将会意识到标识具有相同教名的两个发送者的其它方式。在其它实施例中，发送者的标识符可以基于与驻留在用户联系列表中的特定发送者相关的信息。在又一些其它实施例中，用户可以针对特定的发送者，创建出现在发送者列表中的昵称。如果发送者已创作了对话中的多条消息，则在发送者列表中其标识符依然仅出现一次。在一个实施例中，可以根据发送者标识符的相应消息到达系统102的到达时间，对列表中的发送者标识符进行排序。在另一个实施例中，根据发送者标识符的相应的名字，按字母顺序对表中的发送者标识符进行排序。接下来，在步骤 308，对话管理系统102根据显示指令，对发送者列表进行格式化，以突出显示列表中的一个或多个发送者标识符。此处，对术语“突出显示”的使用，意指按视觉上有区别的方式加以显示，例如按粗体、加下划线、改变背景颜色、改变字体颜色、改变字体等方式加以显示。另外，在这一上下文中，术语“突出显示”意指以有区别的方式生成用于显示某些东西(例如，文本的所指定的部分)的格式化信息。例如，在某些实施例中，如果用户尚未查看他的消息或者尚未将他的消息标记为读取，则对发送者的名字进行格式化，以用粗体字符加以显示。
在某些实施例中，对话助手接收对话的发送者列表和/或接收者列表中所列的一个或多个人的照片，并且具有对它们的存取权。当用户查看对话的列表或单一对话以及把光标定位在发送者列表的名字或标识符上时，显示该发送者的照片。在某些实施例中，当查看对话时，对于所列消息接收者，提供了相同的功能。对于由大型机构使用的电子邮件系统来说，这一特性可能是特别有用的。
在某些实施例中，如果用户本身已创作了对话中的至少一条消息，则在步骤310， 对话管理系统102用针对用户的、作为发送者列表中他的标识符的唯一字符串、或图标、或其它输出提示，取代发送者列表中该用户的名字或其它标识符。唯一字符串的一种选择是某一特定语言中的自我参照标识符。例如，英语中的代词“me (我)”可用于表示发送者列表中的该用户。因为许多人共享相同的教名，所以与通过发送者列表中发送者的名字标识发送者相比，这一特性更为有用(当然，在可选的实施例中可以这样做)。通过唯一的标识符表示用户，还有助于用户容易地标识那些其中用户已通过至少贡献一条消息主动参与的对话。
如果许多人都已向对话贡献了消息，则发送者列表可能会变得过长，以致不能适应浏览器窗口中有限的空间。如果通过发送者的电子邮件地址标识发送者列表中的一个或多个发送者，则情况尤其如此。如果情况如此，则在步骤312，对话管理系统102根据各种信息对发送者列表中的发送者进行优先化处理，以标识在浏览器窗口中显示的发送者的子集。在一个实施例中，该子集至少包括对话中最后消息的发送者，而且在可行的情况下，还可以包括尚未由用户加以查看或尚未由用户将其标记为读取的消息的发送者。在另一个实施例中，该子集包括对话中第一所接收消息的发送者、对话中最后所接收消息的发送者，以及根据优先化或打分方法所选择的0或多个更多发送者。在某些实施例中，把较高的优先级给予在时间上较晚到达的消息的发送者。这种类型的优先化往往会增加将显示未被读取消息的发送者的可能性。也可以使用其它类型的优先化方案。在某些实施例中，当发送者列表仅标识对话中的消息发送者的子集时，发送者列表包括省略标记“...”或者其它表示发送者列表未满的符号。在某些实施例中，在存在着一个以上的其消息尚未由用户加以查看或尚未由用户将其标记为被读取的情况下，该子集标识为可以与可用空间所允许的发送者一样多。
在步骤314，对话管理系统102针对对话创建消息数目指示符，该消息数目指示符指示对话中消息的数目，不包括永久性删除的或被标识为将加以删除的消息。消息数目指示符可以为一对括号中的数字，例如，“ (3) ”表示对话中存在3条消息。在某些实施例中，当对话仅包括一条消息时，不为该对话生成消息数目。消息数目指示符也可以为图标。图标可以为彩色编码的，以提供额外的信息，例如，以表示对话中的多少条消息仍未被读取(即尚未被查看或将其标记为被读取的)。接下来，在步骤316，对话管理系统102为被处理的对话生成对话标题。通常，对话标题为对话中第一条消息的主题，或者如果其超过预先定义的长度，则为该题目的截断的版本。在另一个实施例中，通过试探性地检查第一条消息的内容确定对话标题，或者作为选择，也可不仅仅检查第一条消息。在一个实施例中，如果对话至少包括一条具有“未被读取的”属性的消息，则在浏览器窗口中既突出显示消息数目标识符，也突出显示对话标题，以引起用户的注意。在另一个实施例中，仅突出显示对话标题，以指示一个或多个未被读取的消息。
根据已建立的电子邮件标准，可以把消息发送于至少3种类型的接收者，一个主要类接收者，在“To: ”字段中列出了其地址；两个次要类接收者，在“Ce: ”字段中或者在 "Bcc ”字段中列出了它们的地址。因此，对话管理系统102在步骤318创建了针对该用户的接收者状态指示符，接收者状态指示符为对话中用户参与性的另一个指示符。在一个实施例中，使用第一有区别的指示符，例如“>>”，标记其中用户为任何消息的主接收者的对话，使用第二有区别的指示符，例如“> ”，标记其中用户为至少一条消息的次接收者而且不是任何消息的主接收者的对话，以及其中未明确把用户列为任何消息的接收者的对话(例如，因为把消息被发送于编组或邮寄列表)不接收特殊标记。在其它实施例中，可以按其它视觉上有区别的方式，例如通过突出显示代表这些对话的一个或多个部分行，表示其中用户为至少一条消息的主接收者的对话以及其中用户仅为次接收者的对话。在另一个实施例中，使用第一有区别的指示符，例如“ > > ”，标记其中用户为至少一条消息的唯一主接收者的对话，使用第二有区别的指示符，例如“ > ”，标记其中把至少一条消息直接发送于用户的电子邮件地址而不是邮寄列表的对话，以及其中未明确把用户列为任何消息的接收者的对话(例如，因为把消息被发送于组或邮寄列表)不接收特殊标记。
在某些实施例中，对话管理系统102在步骤320创建对话的摘录。这一摘录向用户提供了对话的内容的预览，而用户不必打开对话。在一个实施例中，根据对话中最近的消息生成摘录。在另一个实施例中，从对话中的第一条消息(即最旧的消息)抽取摘录。在又一个实施例中，根据预先定义的试探性规则，例如列出对话中最频繁出现的一组关键字， 从对话中的所有消息中抽取摘录。如果对话管理系统102响应于用户所提交的搜索而正在准备对话列表，则其在步骤322创建摘录，该摘录包括与用户所提交的查询项目相匹配的突出显示部分，在一个或多个方面，这类似于包括诸如Google搜索引擎的搜索引擎所返回的搜索结果的摘录。
最后，在步骤324，对话管理系统102标识对话的日期/时间值。这一日期/时间值通常规定了浏览器窗口中对话的列表的显示次序。在某些实施例中，向对话的列表中的每一对话赋予等于与用于生成该对话列表的搜索准则相匹配的最新消息的日期/时间的日期/时间。例如，如果使用了用户指定的搜索查询(例如，“Tahoe湖”)，则对于对话的列表中的每一匹配对话，所赋予的日期/时间为与用户指定的搜索查询相匹配的最新消息的日期/时间。在另一个例子中，如果搜索准则为“收件箱”(即，具有至少一条赋予了收件箱标签的消息的对话)，则赋予对话列表中的每一对话的日期/时间为与收件箱标签相关的最新消息的日期/时间。在某些实施例中，按它们的所赋予的日期/时间值的相反的时间次序列出对话列表中的对话(即，首先列出最近的对话)。如此处所使用的，“日期/时间” 值指的是与某一具体消息相关的日期值和/或时间值。可以根据消息的创建、传输、接收或其它事件的日期和/或时间，把日期和/或时间与消息相关联。
在其它实施例中，可以使用其它方法或准则把日期/时间赋予对话列表中的每一对话，也可以使用其它方法，根据对话的日期/时间值来排序这些对话。例如，在某些实施例中，当使用先进的搜索查询工具时，给予用户对那些其日期/时间落入指定时间窗口的 (以及如果存在其它用户指定的搜索要求就满足这些要求的)对话进行搜索的选项。根据用户指定的目标日期或目标日期/时间和列表中每一对话的日期/时间之间的时间长度， 列出对话的所得到的列表。因此，可以在目标日期或日期/时间之前和之后把对话插入对话的所得到的列表中。
图;3B为根据本发明的一个实施例的“收件箱”范畴中的对话列表的示意性屏幕截图。在该屏幕截图的左上角，有“编写邮件”链路340。用户点击这一链路，开始写新消息。 与链路340相邻，有文本框341以及“搜索邮件”按钮342。在用户通过文本框341提交了一个或多个查询项目和接下来点击“搜索邮件”按钮342之后，系统生成与查询项目相匹配的新显示列表对话。在某些实施例中，由于存在相应查询项目的一个或多个同义语，所以可能出现匹配。在某些实施例中，根据相应查询项目的根，可能出现匹配。例如，对于“book” 的搜索，可能为单词“b00k”、“b00ks”、以及“booking”加以匹配。有关详细的情况，请参照图7A和7B。与按钮342相邻的是两个下拉列表“更多动作”列表344和“添加标签”列表 345。关于这两个下拉列表的更详细的情况，请分别参照图4和5。在“编写邮件”链路340 的正下方，有一系列编组框，每一个框对应于图2中步骤214 220之一所生成的表格。例如，编组框346显示系统定义的范畴，包括“收件箱”、“加星号的”、“发送邮件”、“草稿”、“全部邮件”、“垃圾邮件”以及“废纸篓”等。在其它实施例中，所述系统定义的范畴集合可以不同，其包括这些范畴和/或附加范畴的子集。在某些实施例中，“加星号的”范畴包括其中用户计划主动涉及(例如，通过向其它参与者发送消息)的对话，这类似于“To Do”列表。因此，在一个实施例中，可以使用星号标志消息，使得用户可以例如搜索加星号的消息。在一个实施例中，“全部邮件”范畴包括未处于“垃圾邮件”或“废纸篓”范畴中的所有对话。注意，由于当前的屏幕截图仅显示了属于“收件箱”范畴的对话，所以突出显示了编组框346 中的对应链路。
图;3B中的示意性的屏幕截图的主要区域是包括对话的列表360的表格，每一个对话占据该表格中的一行。每一行还包括检查框362、发送者列表364、接收者状态指示符 366、对话标题和摘录368以及日期/时间值369。在其它实施例中，针对每一对话行的字段的集合可以不同，包括这些字段和/或附加字段的子集。在某些实施例中，当显示对话的列表时，所有行具有统一的高度。在其它实施例中，高度可为可变的，以接纳不同的摘录长度。如果用户决定把对应的对话从一个系统定义的范畴(例如，“收件箱”)移至另一个系统定义的范畴(例如，“废纸篓”)，或者如果用户决定向对应的对话附接用户定义的标签， 则由用户检查检查框362。以上已经结合图3A给出了所述表格中的其它列或字段的定义。 注意，在第一对话中存在两条消息，并且已在第一行中突出显示了发送者S2，这意味着还尚未读取S2所发送的消息或者尚未将其标记为被读取的。相比之下，第二对话包括全部已被读取或已被标记为被读取的4条消息，因此，在第二行中没有突出显示任何东西。在某些实施例中，提供了用于加星号状态的视觉指示符。如果对话中的任何消息具有加星号的状态， 则“收件箱”将提供指示对话至少包含一条加星号的消息的视觉指示符。
在一个实施例中，尽管尚未描述，但图IBB所代表的浏览器窗口还包括持续显示的消息编写区域、相关寻址和主题字段、以及通常与允许编写和发送消息的表格相关联的其它选项和字段。例如，把这样的区域显示在对话的列表360之下。因此，在一个实施例中， 在单一用户接口(例如，浏览器窗口)中，用户可具有查看对话列表的选项，并且还可编写新消息，而无需要求打开新窗口(例如，消息编写窗口)，并且无需从当前浏览器窗口去除对话的列表。
图4A是一个流程图，说明了“更多动作”下拉列表344的操作。在用户点击了该下拉列表之后，在步骤402，浏览器显示系统定义动作的列表。在步骤404，用户在下拉列表中选择具体的动作以及对话列表中的至少一个对话。然后，在步骤406，浏览器把用户选择的对话与用户选择的动作相关联，并且在步骤408把它们返回于对话管理系统，以进一步加以处理。在步骤410，如果用户选择的动作导致用户选择的对话从先前所显示的对话列表中被去除，则对话助手从对话管理系统接收新的对话的列表，而且对话助手在浏览器中显示对话的新列表。
参照图4B，图4B描述了当用户检查第二对话的检查框413、点击了“更多动作”下拉列表、以及选择了项目“垃圾邮件115时所产生的从图:3B的示意性屏幕截图的变化。结果，将从“收件箱”范畴去除第二对话，而且“垃圾邮件”范畴将具有新的成员。注意，下拉列表中的某些动作，例如“忽视”和“瞌睡”不具有对应的范畴。“忽视”和“瞌睡”均对应于 “全部邮件”范畴。具体地讲，当用户检查对话的检查框，然后点击“忽视”项目时，将把对话传送至“全部邮件”范畴。如果与“忽视”对话相关的任何新的消息到达，则系统仍把这一新的消息与该对话相关联，但并不自动地把该对话带回用户的注意范围。然而，用户可以停止对对话的忽视，并且可通过访问“全部邮件”范畴、检查所忽视的对话的检查框、然后选择相应“更多动作”下拉列表中的“收件箱”项目，将其带回到“收件箱”范畴。如这一例子所示，不同范畴的下拉列表可以具有不同的动作项目集合。“瞌睡”动作项目允许用户通过设置触发条件暂时忽视对话，所述触发条件可以为时间驱动的，例如，对话应该从“收件箱，， 范畴消失一段时间(例如，一小时、一天、一星期等)，然后自动地返回，或者由事件驱动，例如，对话不应返回到“收件箱”范畴，直至未检查的消息的数目已达到预先确定的极限、或者特定的人已向对话贡献了消息、接收到把用户指定为主接收者的消息、或者所接收的消息包含特定的单词或短语。本技术领域中的普通技术人员将会意识到也可以使用的其它触发条件。
范畴化对话
图5A是一个流程图，说明了“添加标签”下拉列表345的操作。在用户点击了该下拉列表之后，在步骤502，浏览器显示用户定义标签的列表，以供该用户加以选择。在步骤 504，用户选择下拉列表中的具体标签和对话列表中的至少一个对话。然后，在步骤506，浏览器把用户选择的对话与用户选择的标签相关联，并且在步骤508把它们发送回对话管理系统，以进一步地加以处理。结果，与用户选择的标签相关的对话的列表将包括与步骤506 中的那一标签相关的对话。如以下更详细描述的，当把标签或属性与对话相关联时，把一个或多个条目添加于索引1710(图17，18)，以使载有该标签的对话的搜索能够得以定位。在某些实施例中，也把该标签或属性添加于对话数据库1808中的一个或多个条目(图18)。 在某些实施例中，当用户查看对话时，显示与该对话相关的标签。在某些实施例中，在针对列表中每一对话所提供的信息行中显示与对话的列表中的每一对话相关的标签。
图5B是一个示意性的屏幕截图，描述了当用户检查第二对话的检查框512、然后点击“添加标签”下拉列表、并且选择了项目“标签2”514时所产生的浏览器窗口。(注意， “标签2”代表了用户指定的标签名)。这将导致把“标签2”与所检查的对话相关联。因此，可以把所检查的对话包括在响应于对与“标签2”相关的消息的查询所产生的搜索结果中。在某些实施例中，把与对话的列表中的每一对话相关的标签显示在表格的对应的行中， 于是，“标签2”将会被显示在对应于步骤506中与“标签2”相关的对话的行中。当然，本技术领域中的普通技术人员将会意识到，用户可以输入定制化的标签名和/或系统可以提供预先定义的标签。
查看对话
图6A是一个流程图，描述了对话助手如何响应对话管理系统的显示指令生成对话视图。在某些实施例中，在把对话信息发送于客户机中的对话助手之前，由对话管理系统执行图6A中所示的某些动作，例如，用于对要显示的对话信息进行格式化的动作。
在步骤602，对话助手首先接收一系列属于具体对话的消息，以及一组相关的显示指令。在步骤604，对话助手标识对话的标题，以及与对话相关的任何系统定义的范畴和用户定义的标签。根据这些范畴和标签，对话分别生成用户可选择的动作的列表和用户可选择的标签的列表。这两个列表类似于图3B中所示的两个下拉列表344和345。在一个实施例中，用户可选择的动作的列表仅包括适用于具体对话(即，将要显示的对话)的动作。因此，不能再次把已经处于“废纸篓”范畴的对话与“废纸篓”范畴相关联。出于同样的原因， 用户可选择的标签的列表仅包括尚未与具体对话相关联的标签。
从步骤608开始，对话助手为对话中的各条消息分别生成子表格，该子表格至少包括详细消息报头和消息体。如此处所使用的，消息体指的是用户所创建的消息，包括主题参照，不包括通过消息处理软件添加于消息的任何系统信息。每一个详细消息报头包括发送者的名字和/或地址以及所有主与次接收者、消息的主题、一组消息级的动作、以及日期 /时间值。消息级的动作之一包括按消息的原始格式查看消息的选项，其包括路由信息以及其它消息系统提供的信息，例如“我的版本”、“内容类型”等。在步骤610，对话助手还根据详细消息报头创建简要消息报头。简要消息报头包括发送者和接收者的标识符。在某些实施例中，把接收者从简要消息报头中排除。如果用户处于接收者列表中，则在步骤610， 对话助手把唯一的字符串或图标用作用户的标识符，这类似于发送者列表中的用户的标识符。例如，可以把英语中的代词“me(我)”用于表示简要消息报头中的用户。如果消息为标识这一对话中的具体接收者的第一条消息(即，消息报头的主或次接收者字段中的)，则对话助手将在步骤614在简要消息报头中突出显示接收者的标识符。另一方面，在某些实施例中，当不再包括先前包括在接收者的列表中的接收者时，对话助手将按视觉上有区别的方式，例如按“叠影”字体，显示该接收者的标识符。在其它实施例中，简要消息报头包括发送者标识符、消息部分、以及消息的日期/时间表示。
接下来，在步骤616，对话代理决定如何显示子表格。如果与子表格相关的消息尚未由用户加以查看或尚未由用户将其标记为被读取的，则在步骤618按扩展的模式显示子表格，即，既显示简要消息报头，也显示完整的消息体。如果消息已被查看或将其标记为被读取的，则在步骤620，以压缩的模式默认地显示子表格，仅包括简要消息报头和消息体的一部分(例如，消息的前几行)。接下来，用户可以通过点击所压缩的子表格来对其加以扩展。相类似，子表格不描述详细消息报头，但包括供用户选择的选项，即如果用户希望查看详细消息报头，则在步骤622选择这一选项。最后，在步骤624，对话助手在子表格的底部创建一组回答选项，例如“回答”、“回答所有人”以及“转发”。在某些实施例中，针对对话中的每一消息执行以上所描述的动作的子集。在某些实施例中，执行一个或多个附加的格式化动作。
图6B为根据本发明的一个实施例的图:3B中的第二对话的示意性屏幕截图。这一屏幕截图的顶部和左部与图3B的顶部和左部相同。但对话的列表360已由消息的列表640 取代。在消息的列表的顶部，是对话的标题“标题2”630、与对话相关的所有用户定义的标签632、以及“扩展所有消息”按钮634。由于用户已经查看了这4条消息，并且把它们标记为被读取的，所以按压缩的模式显示列表中的头3条消息，并且按扩展的模式显示最后(和最新)的消息。在某些实施例中，当不存在未被读取的消息(即，尚未由用户加以查看或尚未由用户将它们标记为被读取的)时，也可以按扩展的模式显示已经被标记为加星号的对话中的消息。这提供了把对话中的所有消息聚集在一起的视觉效果。每一个压缩的子表格显示简要消息报头641和诸如消息体的前几个单词的摘录643。在某些实施例中，以彩色标识简要消息报头中的发送者，使得可以按不同的颜色提交每一发送者的文本表示。这有助于在所显示的对话中对发送者加以区别。在某些实施例中，由系统生成颜色，直到系统用尽了与发送者相关的颜色为止。在某些实施例中，把颜色与每一对话相关联，以致同一发送者可以具有与其相关的不同的颜色，其取决于所显示的对话。注意，在简要消息报头641中突出显示了所有的接收者，因为这是对话的第一条消息。相比之下，仅在第二压缩的子表格中仅仅突出显示一个标识符“Si”，因为这是其中Sl为对话中的参与者的第一条消息。扩展的子表格包括完整的消息体645、当选择时将导致详细消息报头得以显示的“更多选项”链路647、以及回答选项649的列表。由于S4发送了最后的消息，所以回答选项之一为“回答 S4”，其提醒用户将对S4进行回答。
在某些实施例中，当对话中的消息的数目超过阈值(例如，8或10条消息)，以及将按压缩的子表格显示该对话中的多条连续的消息(例如，从对话的收件箱列表所选择的对话中标记为被读取的消息)时，按不包括文本的第二压缩的子表格显示这些消息，从而无发送者列表，而且无摘录。取而代之，第二压缩的子表格以小线条表示这些消息中的每一消息。视觉效果是，这些子表格就像叠卡片中的卡片的边缘一样加以显现。在某些实施例中，永远不按第二压缩的子表格显示对话中的第一和最后的消息，而且更一般地，也不按第二压缩的子表格表示某些消息，例如那些具有“加星号”标签的消息。第二压缩的子表格的使用有助于对具有大量消息的对话的查看。该方法可用于表示与用户指定的搜索查询相匹配的对话中的消息，其中对话具有大于阈值数目的消息。在这一情况下，由第二压缩的子表格所表示的消息为不与搜索查询相匹配的连续消息组。
图6C是类似于图6B中所示意性屏幕截图的示意性屏幕截图，所不同的是(1)在用户点击了第一子表格650之后，按扩展模式显示该子表格，(2)最后子表格包括详细消息报头660，以及(3)在用户点击了“回答S4”链路之后，把消息回答表格670附接于最后子表格。在一个实施例中，当用户正在查看对话的内容时，可以持续地显示用于对某一消息(例如，最后消息)进行回答的文本框，即与该消息相关联地显示这一文本框。换句话说，显示消息回答表格670，而且与其相关的回答文本框可为用户加以存取，而不要求用户点击“回答S4”链路。在其它实施例中，可以针对对话中的所有消息，或者针对所有按扩展模式所显示的消息，持久地显示消息回答表格。
在结构上，第一扩展的子表格650与图6B中所示的最后子表格相同。其包括简要消息报头、“更多选项”链路、消息体以及一组处于子表格底部的回答选项。除了消息发送者和接收者的电子邮件地址或其它标识符之外，详细消息报头660还包括用户可以采取的动作的列表。例如，“把这一消息放入废纸篓”动作661允许用户把消息从对话中去除。作为默认形式，消息回答表格670仅把S4的地址包括在“至，，字段中，因为用户正在对其进行回答的消息的发送者为S4。然而，如果用户希望把回答消息发送给更多的接收者，则消息回答表格还向用户提供附加的选项(例如，“添加Ce”，“添加Bcc”)。消息回答表格670还允许用户编辑原始消息的主题和把文档附接于回答消息。
图6D为用户点击了 “扩展全部消息”按钮634之后图6B中所示对话的示意性的屏幕截图。结果，按扩展模式显示所有4条消息608。注意，按钮634中的文本改变为“压缩全部消息”。在用户再次点击了按钮634之后，对话的显示返回到图6B中所示的格式。
图6E是说明了先前所描述的某些特性的对话的示意性的屏幕截图。具体地讲，图 6E说明了在682处当对话中消息的数目超过了阈值时所使用的第二压缩子表格的例子。尽管用户不能够看到这些消息的任何报头信息，但用户仍可以看到在该第二压缩的子表格中有多少条消息。在某些实施例中，在描述了如简要消息报头684和686中所说明的简要消息报头的压缩子表格中，描述了第二压缩子表格中的消息的两端上的消息。在某些实施例中，以及如图6E中所示，简要消息报头包括发送者、消息部分、以及消息的日期/时间值，而未描述消息的其它接收者。可以在消息688处看到“加星号”的特性的例子。消息688中的星号不同于其它消息在于其星号被填写了，其表示这一消息具有加星号的状态，而其它消息不具有这样的状态。当然，可以使用任何提供了有区别的状态的视觉指示符，而且这一概念不局限于“星号”，以及是否“填写”了星号。如以上所描述的，在一个实施例中，当显示了对话，而且不存在未被读取的消息(如图6E中所示)时，按扩展模式显示具有加星号状态的消息。在另一个实施例中，如果存在尚未被读取的或尚未被查看的消息，则将按压缩的子表格但不是按第二压缩的子表格显示加星号的消息688，例如682处的那些消息。其它实施例预计了不同的排列，例如总是按扩展模式看到加星号的消息，而不管是否存在任何尚未被读取或尚未被查看的消息。
使用查询定位、列表以及显示对话
如以上所提到的，用户可以搜索与用户指定的查询相匹配的对话。对话管理系统 102和对话助手110协同运作，以生成对应于查询的搜索结果，并且按十分直观的方式把结果提交于用户。图7A是一个流程图，说明了对话助手110如何生成用于显示与用户的搜索请求相匹配的对话的各种表格。在某些实施例中，在向客户机中的对话助手发送对话信息之前，由对话管理系统执行图7A中所示的某些动作，例如用于对将要显示的对话信息进行格式化的动作。
在步骤702，对话助手110从对话管理系统102接收代表多个与搜索查询(其可以包括一个或多个查询项目)相匹配的对话的信息以及相关的显示指令。在步骤704，对话助手110生成用于容纳对话列表的表格，每一个对话占据该表格中的一行。对于该表格中的每一行，在步骤706，对话助手110还生成包含匹配查询项目的摘录。在某些实施例中，对话助手110还突出显示与搜索查询中任何查询项目相匹配的摘录项目。在步骤710，显示对话的列表。图7B为根据这些步骤所产生的对话的列表的示意性屏幕截图。在某些实施例中， 用户可以指定致使摘录的生成和/或显示受到抑制的用户偏好。在某些实施例中，当把与搜索查询相匹配的文本放置在消息的报头或其它信息中时，所提供的摘录为消息的第一部分。
在某些实施例中，如果用户选择(例如点击)了代表对话列表中的对话的行(例如，图7B中所示的对话列表中的行)(步骤712)，则在步骤714，对话助手110显示所选择的对话。为了做到这一点，对话助手生成一系列容纳一系列与所选择对话相关的消息的子表格。具体地讲，如果从响应于用户指定的搜索查询所产生的对话列表中选择了所选择的对话，则按压缩模式显示那些其相关的消息不包含搜索查询中任何查询项目的子表格，而按扩展模式显示那些其相关消息至少包括一个查询项目的子表格。对话助手110还突出显示消息体中的匹配查询项目。与指定查询相匹配的所选择对话的显示例子被描述为图7C 中的示意性屏幕截图。如果从对话的范畴列表，例如从对话的收件箱列表选择了所选择对话，则消息的最初的显示如以上针对图6C所描述的。
图7B是一个列出了 3个与查询项目“TahOe”720相匹配的对话730的浏览器窗口的示意性的屏幕截图。在3个对话730之上，是“搜索选项”链路732。用户可以点击该链路，以修改那些用于进行搜索的选项。例如，用户可以指定是把搜索限制于一个范畴中的对话，还是限制于所有的范畴中的对话。当所列对话属于两个或两个以上不同的范畴时，不突出显示编组框346中的任何一个范畴。在每一匹配的对话中，标识了包含项目“Tahoe”的摘录，并且以突出显示了单词“Tahoe”的方式显示这一摘录。这些摘录指出3个对话覆盖了 3个不同的标题，即第一个对话涉及到Tahoe湖的滑雪旅行，第二个对话涉及Tahoe模型 SUV，而第三个对话涉及Tahoe国家森林公园的野营地点。因此，用户可以使用摘录中的信息以决定其希望打开哪一具体的对话。
图7C是一个示意性的屏幕截图，该屏幕截图显示了在用户对其进行点击之后第三个对话中的所有消息。注意，在这一屏幕截图中(在编组框346中)已经突出显示了“全部邮件”范畴，表明当前把第三个对话定位在“全部邮件”范畴中。由于第二条消息包括查询项目“Tahoe”，所以按扩展模式显示第二子表格，具有突出显示了的单词“Tahoe”。
拼写检查
图8为一个流程图，说明了对话助手如何与用户交互，以纠正用户所编写的消息中可能错拼的单词。在编写了消息之后和在将其向外发送之前，用户可以点击“更多动作” 下拉列表，并且选择“拼写检查”项目。注意，图4B中没有显示这一项目，因为其中下拉列表仅包括对话级动作。“拼写检查”为仅当正在使用一个消息编写表格时才显示在下拉动作列表中的消息级动作。响应于“拼写检查”动作的用户选择，对话助手把所编写的消息发送于对话管理系统，然后在步骤802接收所编写消息的经过拼写检查的拷贝以及显示指令。在可选的实施例中，通过对话助手或者通过使用局部字典的局部客户机应用，执行此处所描述的与拼写检查器相关的对话管理系统所执行的动作。根据显示指令，对话助手在步骤804 突出显示消息中每一可能错拼的单词，在步骤806，把每一突出显示的单词与系统生成的候选单词的列表相关联，并且在步骤808，在独立的浏览窗口中显示重新格式化的消息。当用户选择了浏览窗口中的具体突出显示的单词时，对话助手在拼写纠正窗口中确定用户选择的单词的位置，并且在步骤810，在该窗口附近附接候选替换项目的列表(应该加以注意的是，替换项目可以包括一个或多个单词)。然后，对话助手在步骤812使用候选列表中用户指定的替换项目，修改拼写纠正窗口中的错拼的单词。对话助手还可以在步骤814在用户指定的方向扩展拼写纠正窗口，以致用户可以在步骤816修正拼写纠正窗口中的一个以上的单词。
图9A为一个屏幕截图，说明了与图6C中所示的对话相同的对话，所不同的是用户已经编写了针对S4的回答消息817。在发送该消息之前，用户决定进行拼写检查。因此， 用户点击了“更多动作”下拉列表，然后选择了“拼写检查”项目818。作为响应，对话助手把所编写的消息发送于对话管理系统，然后把拼写检查结果显示在独立浏览窗口中。在某些实施例中，把拼写检查结果显示在与其中用户正在编写消息的窗口相同的窗口中。实际上，显示大体保持相同，所不同的是某些与拼写检查器相关的特性的切换(toggling)，以及可能错拼单词的突出显示。这一实施例增添了这样的好处当编写消息时，用户可以在向用户提供的等效的视觉上下文中执行拼写检查，而不是向用户提交不具有这种上下文的独立的新窗口。
图9B描述了包括处于拼写检查过程不同阶段的3个独立的浏览窗口的屏幕截图。第一窗口 820包括消息的经过拼写检查的拷贝。具体地讲，已经在该窗口中突出显示了 3个可能错拼的单词821、823以及825。在用户点击了第二单词823之后，接下来把单词“delying”并入一个如第二浏览窗口 830中所示的拼写纠正窗口 832。另外，在拼写纠正窗口之下或者与拼写纠正窗口相邻地显示由系统所生成的候选单词的列表834。然后， 用户选择第三替换项目“delaying”，以取代错拼的项目“delying”。如果用户希望在所纠正的单词“delaying”之前添加单词“temporarily”，则用户可以点击如第三窗口 840中所示的左箭头841，把浏览器窗口指针定位在错拼项目“delying”之前的位置，然后录入单词 “temporarily”。最终，在纠正了所有错拼的单词之后，用户点击“完成”按钮845，这将导致把消息发送于S4。
对话服务器
图10 19有助于描述先前所描述的对话服务器102的实施例。图10说明了对话服务器102的一个实施例。对话服务器102包括对话引擎1002、修改器引擎1004、消息索引1006、查询引擎1008、消息数据库1010、一个或多个辅助服务服务器1012、拼写检查器 1014 以及 SMTP 1016。
对话引擎1002经由其与通信网络106的连接，处理来自对话助手110的请求和对对话助手110的答复。通信网络106可以包括Internet、一个或多个局域网(LAN)、一个或多个广域网(WAN)、其它类型的网络、或者这样的网络的组合。还把对话引擎连接于各种辅助性服务机构，例如，辅助服务服务器1012和拼写检查器1014。把查询引擎1008连接于对话引擎1002、消息索引1006以及消息数据库1010。把修改器引擎1004连接在对话引擎1002和消息索引1006以及消息数据库1010之间。把SMTP网关1016连接在对话引擎 1002和通信网络106之间。尽管图10把对话服务器102描述为多个离散的项目，但该图更多的意图是对对话服务器102中可提交的各种特性进行功能上的描述，而不是对此处所描述的实施例的结构上的示意。实际上，正如本技术领域的普通技术人员将会意识到的，可以把独立描述的项目加以组合，也可以把某些项目加以分离。例如，可以在单一的服务器上实现图中独立描述的某些项目，也可以在一个或多个服务器上实现单一的项目。对话服务器 102中服务器的实际数目以及如何在它们之间分配特性，将随实现的不同而不同，并且可能部分地取决于高峰使用期间以及平均使用期间系统必须处理的电子邮件吞吐量。
如以上简要提及的，对话引擎1002可以响应来自对话助手110的、与消息相关的各种请求，并且经由其与通信网络106的连接返回基于对话的答复。尽管也可以把SMTP网关1016连接于通信网络106，但也可以使SMTP网关1016更直接地涉及消息的接收与发送。 例如，在某些实施例中，SMTP网关1016使用简单邮件传送协议(SMIP)传输和接收消息。 SMTP网关1016可以从通信网络106接收新的消息，并且把该消息发送于对话引擎1002，以进行附加处理。另外，SMTP网关1016还从对话服务器1002接收消息，然后(经由通信网络106)把这些消息传输于消息中所指定的接收者地址。
对话引擎1002还可以处理对可能正在被编写的消息进行拼写检查的请求。对话引擎1002向拼写检查器1014发送将要检查的文本的各部分，以进行拼写检查。拼写检查器 1014返回相应的信息，包括被标识为可能不正确的拼写的文本的标识。在某些实施例中，拼写检查器1014提供了有关向被标识为可能不正确的拼写的文本提出建议的信息。在某些实施例中，把这一信息发送于对话助手110，以进行相继的处理。
一个或多个辅助服务服务器1012向对话引擎1002提供了附加的服务。在某些实施例中，辅助服务服务器1012包括垃圾邮件检测模块。以下，参照图11讨论垃圾邮件检测模块的操作。在某些实施例中，辅助服务服务器1012包括附件管理模块，该附件管理模块对附接于电子邮件消息的文件的有效存储与检索进行管理。
图11描述了用于处理所接收消息的实施例。接收消息、将其赋予对话、对其进行索引、向其赋予一个或多个属性、并且将其加以存储。例如，最初可以由SMTP网关1016接收消息，其中，可进行某些处理和操作，然后可以将其传送于对话引擎1002 (阶段1102)。对话引擎1002可以为该消息生成消息标识符。消息标识符可用于互相区别消息。在实施例中，该标识符为由一个或多个部分构成的N个比特的数字。例如，在实施例中，消息标识符可以为64个比特的数字，该数字由Y个比特(例如32个比持或48个比特)的时标和64-Y 个比特的消息内容的杂凑(hash)组成。杂凑为数学函数，其把值从大的域映像至较小的域。本技术领域中的普通技术人员将会意识到，存在着许多创建消息标识符的不同的方法， 这些消息标识符提供了用于将消息互相区别的足够信息。
然后，对话引擎1002可以把消息解析为其若干构成成分(阶段1104)。这些成分可能包括发送者的地址、一个或多个接收者地址、消息的主题、“Reference ”字段，如先前所描述的RFC 2822(2001年4月)中所描述的字段、RFC观22中还描述的“In-R印Iy-To ” 字段、消息的内容、或任何可能包含在消息中的其它信息。在接收了消息之后，在解析消息之前或之后，把消息传送于垃圾邮件检查模块(阶段1105)，以判断消息是否与垃圾邮件准则相匹配。在某些实施例中，各垃圾邮件检查模块与消息的其它处理异步地、并行地运行。 在某些实施例中，垃圾邮件准则的设计旨在判断消息是否可能为用户可能不希望读取的未经请求的消息。
把所解析的消息添加于消息数据库(阶段1106)。在一个实施例中，把该消息添加于消息数据库，而且不进行相继的修改，除非可能要删除。
在消息解析期间所抽取的消息的某些或所有成分被用于帮助对所接收的消息所属的对话(如果存在这样的对话)的判断(阶段1108)。例如，可以把消息的主题与具有相同主题的其它消息进行比较，因为对话中的消息很可能将具有相同的、或几乎相同的主题。 如果尚未发现相匹配的对话，则把该消息与新的对话相关联。
在已经进行了对话关联之后，为消息加索引，以用于搜索(阶段1110)。在一个实施例中，为消息的整个文本和报头信息的部分加索引。在某些实施例中，不对消息体中的 “干扰词”(例如“the (这一)”、“a(某一)，，以及“or (或者)，，等单词)加索引，但对消息的相关部分中的所有其它文本加索引。本技术领域中的普通技术人员将会意识到，应该为可加以搜索的消息的那些部分加索引。如以下所提到的，在某些实施例中，在消息处理的较后阶段，把涉及与消息相关的属性的信息添加于索引中。
接下来，把属性的初始集合赋予消息(阶段111 。例如，这些类型的属性可以包括为所接收消息加“未被读取”标签(这通常意味着消息尚未被查看，或尚未被标记为被读取的)，以表示该消息为新的。除了用户发送的消息外，最初赋予消息的另一个属性是“收件箱”属性。最初赋予每一消息的另一组属性是与同一对话中的其它消息(如果存在的话) 相关的用户定义的属性。通过搜索以下参照图18所描述的对话数据库，确定与对话中的其它消息相关的用户定义的属性。最初也可以把其它属性赋予消息。与消息相关的属性可用于搜索消息数据库，以获取具有类似属性的消息。例如，可以执行搜索以搜索所有被标明为 “未被读取”的消息。另外，也可以把对话的属性添加于消息，因为，在一个实施例中，消息继承了其对话的属性。
在某些实施例中，与消息相关的属性可以包括与对话中单条消息相关而不必与所有消息相关联的属性。例如，可以把“标记为删除”属性(有时也将其称为“废纸篓”属性) 与对话中的单一的消息相关联，而不与同一对话中的其它消息相关联。标记为删除的消息还由系统加以存储，并且还与对话相关联，但通常在显示对应的对话时不对它们加以显示。 使用一个或多个特定的视图，以使得用户能够查看具有属性“标记为删除”的消息。这样的视图向用户提供了“不删除”消息的机会。另一方面，在某些实施例中，当把用户定义的标签与对话相关联时，把该标签与对话中的所有消息相关联。在某些其它实施例中，当把用户定义的标签与对话相关联时，把该标签与对话中的所有满足预先定义的准则的消息(例如，除那些标记为删除的消息之外的消息)相关联。
接下来，把用户已经建立的用户定义的过滤器施用于消息(阶段1114)。每一用户定义的过滤器包括一组过滤条件和一组动作。过滤条件定义了哪些消息与过滤器相匹配， 动作包括指定将添加于消息或从消息去除的标签的动作。过滤条件可以包括与发送者、接收者、消息主题中的文本、消息中的文本等相关的准则。在某些实施例中，动作可以包括“从收件箱去除”(即，如果存在，则从消息中去除收件箱标签)、向消息添加系统标签(有时称为范畴)、以及向消息添加用户定义的标签。例如，过滤器可以指定所有具有特定项目或者项目组合的消息都应该用“废纸篓”标签标明。另一个过滤器可以指定，如果项目“Tahoe 湖”出现在消息中的任何地方，则把“假日”标签添加于该消息。
注意，在某些实施例中，阶段1112和1114涉及把标签赋予正被处理的消息。在执行或准备执行阶段1112和1114时，检索来自垃圾邮件检查模块的结果(阶段1105)。如果垃圾邮件检查模块把消息归类为垃圾邮件，则把“垃圾邮件”标签赋予该消息，并且从该消息去除任何冲突的标签(例如，“收件箱”或“废纸篓”)。
在已建立了赋予消息的标签集合之后，修改对话引擎1002中的索引和某些表(阶段1116)，以反映赋予该消息的标签集合。通过添加表示把标签赋予哪一消息的信息来修改索引。结果，在这些标签的每一标签上的索引搜索将产生包括正被处理的当前消息的消息列表。另外，修改对话引擎中的至少一个表或数据库，以表示赋予正被处理的当前消息的标签集合。以下，将参照图18描述这一点。
最后，可以向消息的发送者发送认可(阶段1118)。在某些实施例中，可以发送认可，而在另一些实施例中，可以不发送认可。
尽管图11按特定的次序描述了这些阶段，但并不旨在不适当地限制这些阶段的次序。在其它实施例中，可以对这些阶段进行不同的排序。例如，在对消息进行索引之前， 可以把消息添加于该消息数据库，从而阶段1114后可跟阶段1110。本技术领域中的普通技术人员将会意识到对这些阶段重新进行排序的各种方式。
把每一消息与对话相关联
参照图12，以下为如何可把消息与对话相匹配(阶段1106)的更详细的描述。在对消息进行解析(图11的阶段1104)之后，构成成分的各部分可用于规划对候选对话的搜索查询(步骤1202)。例如，可以根据时间信息、发送者信息、主题信息、报头中的其它信息、或系统提供的信息、或者它们的任何组合来对对话加以关联。一个实施例使用带有 "Reference ”和/或“In-R印Iy-To ”字段的消息的主题规划搜索查询。其它实施例包括搜索查询中消息的发送者或者接收者。本技术领域中的普通技术人员将会意识到用于产生可与当前消息相关的消息的许多不同的搜索查询。
针对先前所存储的消息施用搜索查询，并且接收候选消息(阶段1204)。对消息或有关消息的信息进行检查，以判断哪些消息(如果存在的话)可最好地与当前消息相匹配(阶段1206)。该消息所属于的对话很可能为当前消息所属于的对话。可以使用多种不同的方案确定当前消息所属于的对话。一种方案可以使用当前消息的主题。具有相同主题的消息很可能属于同一对话。因此，可以规划使用当前消息的主题的查询。例如，如果流入的消息具有主题“今天我们应去哪里吃午饭？ ”，则当前消息所属于的对话(如果存在的话) 就有可能包括一条或多条具有相同主题的消息。当对主题进行比较时，在进行比较之前，对主题进行正规化可能是人们所希望的。在某些实施例中，对主题进行正规化包括去除前缀， 例如去除“Re: ”和“Fwd: ”，其通常由某些系统把它们添加于主题。
然而，可能人们希望检查的不仅仅是主题。如果两条消息具有同样的主题，但其中的一条早在另一条消息之前就接收了，则它们很可能不是同一对话的一部分。例如，如果相隔一个月接收到两条具有主题“今天我们应去哪里吃午饭？，，的消息，则它们不可能为同一对话的一部分。因此，在本发明的一个实施例中，如果当前消息和来自候选对话的消息的正常化主题相匹配，则对该消息的日期/时间值的检查可能是人们所希望的。
当把消息与对话相匹配时，可以考虑其它因素，例如接收者、消息内容的各部分、 发送者的域地址、或其它因素。本技术领域中的普通技术人员将会意识到，存在用于确定新消息所属于的对话的许多不同方式。一旦当前消息与令人满意的匹配消息相匹配，则可以把与该匹配消息相关的对话与当前消息相关联(阶段1206)。另一方面，如果没有发现令人满意的匹配消息(因而，无对话)，则把新的对话标识符与该消息相关联(阶段1206)。
在某些实施例中，可以根据对话中所接收的初始消息来创建对话标识符。例如，可以把系统提供的初始消息的消息标识符(由传输或接收系统提供的)用作对话标识符。然后，把相继的消息与目前用作为对话标识符的该消息标识符相关联。本技术领域中的普通技术人员将会意识到可用于提供对话标识符的初始消息的各种特性。在某些实施例中，这些特性应该提供这样的良好支持该值唯一于该初始消息，使得将不会把同一对话标识符赋予多个对话。
如先前所提到的，在把当前消息与对话(先前存在的或新创建的)相关联(阶段 1106)之后，添加初始属性(阶段1108)。参照图13可以更好地理解用于添加这些初始属性(阶段1108)的一个实施例。最初，可以检查消息的发送者。如果当前消息的发送者不是针对其正在执行这一消息处理的用户，则当前消息很可能已被别人发送至该用户。因此， 如果在阶段1302断定当前消息的发送者不是该用户，则可以把“收件箱”的初始属性(也称收件箱标签)与当前消息相关联(阶段1304)。“收件箱”的属性可用于标识那些已经发送给该用户的消息。例如，在某些实施例中，把具有“收件箱，，属性的消息的搜索用于用户的收件箱视图的产生。
在本文献中，可交换地使用术语“属性”和“标签”。另外，把具体属性与消息“相关联”，以及使用具体属性或标签“标记”消息被视为是相同的或等效的操作。
由于当前消息很可能是新的，所以用户此前尚未查看这一消息也是很可能的。因此，可以把如此指示的“未被读取”属性与当前消息相关联(阶段1306)。本技术领域中的普通技术人员将会意识到，可以按能够达到同样结果的多种方式实现消息属性。例如，预先定义的值可以代表“收件箱”。可以根据这些属性搜索具有所希望的属性的消息足以。也可以把其它属性与消息相关联。尽管搜索具体属性的能力比有区别更为重要，但仍可以按多种形式考虑属性。属性可以包括系统定义的属性，例如，收件箱、废纸篓、垃圾邮件、全部文档以及未被读取。在某些实施例中，某些系统属性可能是互斥的(例如，收件箱、废纸篓以及垃圾邮件)。属性还可以包括用户定义的属性，此处，有时把它们称为范畴。
如果用户为正被处理的消息的发送者(如在阶段1302所断定的)，或者在把任何可施用的系统属性添加于消息之后，例如，在添加了 “未被读取”(阶段1306)之后，则把属于对话的附加的属性添加于消息(阶段1307)。
可以针对流入的消息检查和施用某些过滤条件(阶段1308)。在实施例中，用户可以建立当满足预先确定的条件时把属性施用于所接收的消息的过滤器。在另一个实施例中，系统可以把一个或多个预先定义的过滤器施用于所接收的消息。
如果当前消息与过滤准则相匹配，则接下来可以根据过滤器把属性施用于该消息 (阶段1310)。在一个实施例中，系统提供了使用户能够建立过滤器的工具，以便不把某些消息放置于“收件箱”中。换句话说，过滤器将导致把“收件箱”属性从消息中去除。在另一个实施例中，可以把当前消息与特定的用户定义的属性相关联，例如与指示可以把一个或多个对话与其关联的那一用户所感兴趣的领域的标签相关联。例如，可以把流入的消息与具有标签“食物”的对话相关联，然后，将把“食物”标签与当前消息相关联。总体上讲，消息继承了将消息与其相关联的对话的标签。由于可以把多个过滤器施用于所接收的消息， 所以可以把新接收的消息以及它们相关的对话与一个以上的用户定义的标签相关联。
在另一个实施例中，用户可以把瞌睡条件与对话相关联。在某些实施例中，当用户特别命令系统这样做时，才把瞌睡条件与对话相关联。在某些实施例中，当过滤器与对话中的消息相匹配时，把瞌睡条件与对话相关联。当在已经把瞌睡条件施加于其的对话中接收到新消息时，瞌睡条件指定将要执行的某些动作。例如，瞌睡条件可以使系统免于把收件箱标签与对话中的新消息相关联。更具体地讲，用户可以把瞌睡条件与对话相关联(直接地， 或者通过过滤器的操作)，从而使对话中的新消息免于被放置在用户的收件箱中，除非满足了某些触发条件。一个这样的触发条件可以是直接导向用户(作为唯一的主接收者)的流入的消息。另一个这样的触发条件可以是由用户或系统所选择的一段时间的流逝。再一些触发条件可以是包含所指定的单词或短语的所接收的消息。在这一情况下，当接收到满足瞌睡条件的消息时，从对话中去除该瞌睡条件，并且使用“收件箱”标签标记该流入的消息。 在某些实施例中，还采取了额外的动作，例如，把“收件箱”标签添加于对话中的其它消息。 在另一个实施例中，使用“收件箱”标签标明具有“未被读取”标签的对话中的所有消息。因此，“收件箱”的搜索将返回该对话。在某些实施例中，通过生成瞌睡过滤器而把瞌睡条件与对话相关联，从而使与对话相关联的新消息免于被以“收件箱”标签加以标记，直至出现预先定义的事件或条件，在此之后，删除或修改该瞌睡过滤器。
另一种可施用于所接收的消息的过滤器是“垃圾邮件”过滤器，其能够标识不希望的消息，并且使用“垃圾邮件”标签对它们加以标记(即，把“垃圾邮件”属性与这样的消息相关联)。
图14说明了用于修改对话的属性的一个实施例。当对话、或者与对话相关联的流入的消息与过滤准则相匹配时，可以修改对话的属性。当用户指出对话应具有特定的用户定义的属性时，也可以修改对话的属性。例如，用户可以指定应该把具体的对话与“食物”范畴相关联。在这种情况下，使该对话(和其各自的消息)用“食物”属性来标记以便与“食物”属性相关联。用户还可以指定标记为删除的对话。
在某些方式下，就概念而言，用户定义的属性可比于文件夹。然而，本发明的各实施例允许把对话与多个用户定义的属性相关联。在某些实施例中，当把新的属性与对话相关联时，使用新属性标记对话中的所有消息。
参照图14，当要修改对话的给定属性时，规划搜索(阶段1402)以定位对话(阶段1404)。在发现对话(阶段1404)之后，可以修改对话的属性(阶段1406)。用于完成阶段1402、1404以及1406的具体机构依赖于用于把属性与对话相关联的机构。在某些实施例中，以对话为基础把属性与对话相关联。例如，对话引擎可以维持与每一具体对话相关的属性的列表。作为选择，或者另外，对话引擎可以维持索引，该索引把每一所定义的属性映像为用该属性标记的所有对话。作为选择，在某些实施例中，把与对话相关的属性与该对话中的各条消息相关联。在这样的实施例中，对话引擎可以维持把每一所定义的属性映像为用该属性标记的所有消息的索引，而且还可以维持用于把每条消息映像至与该消息相关的对话的表或其它机构。
与消息相对照，本发明的许多特性把对话使用作为信息的基本单元。例如，收件箱向用户提交对话的列表。本发明的某些特性使用搜索以标识在用户电子邮件账户中的多个不同对话视图中所列的对话。以下，将参照图15描述搜索对话以及生成所标识对话的表示。最初，接收搜索查询(阶段1502)。搜索查询可以为用户所指定的，或者为系统所生成的(例如，响应于用户点击“收件箱”图标)。搜索查询可以基于多种因素。搜索查询中的搜索项目可以按单词或单词的组合的形式来自用户。例如，用户可以搜索包含单词“硬面包圈”和“便宜”的消息，而且如果存在相关对话，则将返回该相关对话。系统可以响应某些用户动作，生成搜索查询。例如，如果用户希望得到收件箱视图，则系统生成搜索查询可以搜索具有属性“收件箱”的对话。
可搜索项目的任何组合均可用于搜索查询。如以上所提到的，可搜索项目可以包括消息的文本；与消息、对话相关的任何属性；或者与消息相关联的报头信息。在一个实施例中，把搜索查询施加于消息的数据库将返回一组消息(阶段1504)。简单参照图10，例如，可以通过向查询引擎1008发送搜索查询来实现这一点。查询引擎1008可以把搜索查询施加于该消息索引1006，消息索引1006可以返回消息的列表。可以在阶段1504接收这一消息列表。如果希望的话，其它实施例可以按多种不同的方式返回消息的列表，包括返回一组消息标识符、文档标识符、全部或部分消息、或者它们的任何组合。
在某些实施例中，针对作为整体的对话，而不是针对各个消息进行搜索。于是，当查询包含第一和第二查询项目，其中一个在第一条消息中被发现，另一个在同一对话的第二条消息中被发现时，将把这一对话视为与所述的查询相关联，因而将其包括在搜索结果中。例如，考虑这样一个对话其中第一条消息请求关于午餐地点的想法和相续的消息，同时指定具体的餐馆，不包括原始消息的文本。如果用户感兴趣于找出其中讨论特定餐馆和午餐的对话，则如果针对整个对话的文本施加这一搜索，好象对话中不存在消息边界，则搜索更可能产生所希望的结果。
把对话与在阶段1504所返回的消息集合相关联。可以使用多种方法标识相关的对话。当从在步骤1504所返回的消息集合选择了消息(阶段1506)时，标识消息所属于的那一对话(步骤1508)。在一个实施例中，可维持把每一消息与对话相匹配的数据结构。 如果维持了这样的数据结构，则对与具体消息标识符相关的数据结构条目的检查，可以标识消息所属于的对话。作为结果集合，可以把所返回的对话的数目限制为预先定义的数目。 如果进行了这一限制，则该组消息的处理继续，直到标识了足够数目的对话为止，并且返回结果。另一方面，可以标识与所返回的消息组相关联的所有对话，但仅返回子集。
一旦通过标识全部或部分返回结果所属于的对话创建了对话的列表(阶段 1510)，则格式化对话信息，以返回于请求者(阶段1512)。格式化阶段1512可以格式化多个不同类型的与所标识的对话相关联的信息，它们的细节将随实施例的不同而不同。在某些实施例中，格式化信息为可由用于把对话信息提交于用户的对话助手110加以识别的类型。
在某些实施例中，根据预先定义的规则或规则组，依照赋予每一对话的日期/时间值，排序在阶段1510所生成的对话列表中的对话。如以上所解释的，在某些实施例中， 向对话列表中的每一个对话赋予等于与用于生成对话列表的搜索准则相匹配的最近消息的日期/时间的日期/时间，并且根据这些所赋予的日期/时间值，排序对话列表中的对话 (例如，按反时间次序)。本技术领域中的普通技术人员将会意识到，存在着对对话列表中的对话进行排序和提交的各种其它的方法。
在某些实施例中，代表对话的列表的经过格式化的对话数据(在阶段1512产生) 包括对含于对话列表中每一对话中的消息的数目的统计。在某些实施例中，由对话助手110 显示每一对话的消息统计，以向用户指示多少消息包含于对话中。
在一个实施例中，针对对话的列表中的每一对话创建简要对话报头(例如，在阶段1512期间)，对话报头可以标识对话中消息的发送者的列表。这一列表可以包括对话中全部发送者或发送者的子集。在某些实施例中，对发送者的列表进行格式化，以便可视地区别那些已经发送了当前由用户标明为“未被读取”的(对话中的)消息的发送者。在另一个实施例中，对话助手110按不同于其它发送者的格式提交这些发送者。例如，可以使用粗体或突出显示的文本标识“未被读取”消息的发送者。
在另一个实施例中，可以通过用自我参照标识符取代用户的名字或地址来处理 (简要对话报头中的)消息的发送者的列表。结果，当显示对话的发送者的列表而不是显示类似于非该用户的发送者的用户的名字或其它标识信息时，显示自我参照标识符(例如 “me (我)”)。也可以使用其它类型的自我参照标识符把正在查看的用户与其他用户相区别。
在另一个实施例中，对话的列表中的每一消息的简要对话报头可以包括指示用户如何接收消息的信息。换句话说，这些信息可以专门标识如何向用户发送消息。例如，可以直接向用户发送消息，可以针对消息拷贝用户，可以针对消息盲拷贝用户，或者可以令用户为把消息发送于其的分布列表的一部分。可以向用户指出用户接收消息的这些不同方式中的一个或多个方式。例如，如果向用户直接发送消息，则可以使用形象的表示(例如“>”) 指出何时把对话提交于用户。
在某些实施例中，对话的列表中的每一消息的简要信息报头包括对话内容的摘录，该摘录包括用于以粗体显示与搜索项目相匹配的文本的信息，而且还包括以正常字体格式化的围绕匹配文本的文本。当针对收件箱或其它系统范畴生成对话的列表时，摘录包括来自根据预先定义的准则所选择的对话的文本。在某些实施例中，摘录包括从对话中的最近消息的开始起的文本，而在另一个实施例中，摘录包括自动选择的、指示对话内容的文本。
在另一个实施例中，当用户从与搜索查询相匹配的对话中选择查看具体的对话时，对话引擎可以生成指示对话中的哪些消息与该查询相匹配以及哪些消息与该查询不相匹配的对话信息。对话信息还可以包括与该搜索查询相匹配的消息的文本的一部分。可以对这一对话信息进行格式化，以向用户加以显示。对话信息可以包括用于按扩展模式显示的格式化的匹配消息和用于按压缩模式显示的格式化的非匹配消息。可以按扩展模式把各种类型的信息提交于用户，包括下列所有或部分信息的任意组合报头信息、内容信息、与搜索查询相匹配的文本、以及围绕该搜索查询的文本。在某些实施例中，当按压缩模式(例如，响应于用户对“压缩所有消息”按钮或选项的选择)显示与搜索查询相匹配的一条或多条消息时，按压缩模式针对这样的消息所显示的信息包括消息内容的摘录，该摘录包括用于以粗体显示与查询项目相匹配的文本的信息，而且还包括围绕以正常字体格式化的匹配文本的文本。
在又一个实施例中，对话信息可以指示何时已向对话添加了某些用户或何时已从对话去除了某些用户。例如，如果已把用户包括于对话中的消息达到某一时间点，然后不再包括，则针对一条或多条相继消息的信息可以指示用户不再为对话的一部分。例如，对话助手可以通过使用某种不同于用于显示那些仍正在参与对话的用户的名字的字体显示该用户的名字来实现这一点。为此目的，对话助手可以使用“叠影”字体。
对话信息还可以向对话提供关于新参与者的加入的信息。例如，涉及包括新参与者的第一条消息的信息可以包括用于有区别地显示新参与者的名字的格式化信息。可以通过对话助手把这一信息显示于用户，以致新添加的发送者的名字或其它标识信息可按粗体或某些其它视觉上有区别的提交格式得以显现。
对话信息还可以包括关于拼写检查的信息。这一信息可以包括指出哪些单词被拼写检查器1014标识为可能不正确拼写的指示信息，以及与正确拼写的建议相关的信息。
图16提供了根据本发明的一个实施例的用于存储消息的格式的说明。当把消息存储在消息数据库中(图11的阶段1114)时，可以按图16中所说明的对其加以存储。消息数据库1602可以存储关于消息的信息，例如关于消息1(1604)至消息x(1606)的信息， 其中，χ代表对应于具体用户的消息的数目。在一个实施例中，把每一用户的消息存储于唯一于该用户的消息数据库1602中。在另一个实施例中，可以把属于一个以上用户的消息存储于相同的消息数据库1602中。本技术领域中的普通技术人员将会意识到许多使来自一个用户的消息免于作为属于另一用户的消息加以显示的方法。在又一个实施例中，可以把来自一个以上用户的消息存储在消息数据库1602中，而且每条消息仅具有一个存储条目， 以致多个用户可参照单一拷贝的消息。
在一个实施例中，消息(例如，消息1608)可以包括报头信息1612、内容1614以及附件1616。报头信息1614可以包括消息的报头信息，其含有诸如标识发送者和接收者、消息的时间/日期值以及主题的信息。其它的信息也可以包含于报头信息中，例如RFC 2822 中所描述的其它信息。内容1614可以包括消息的内容。内容1614可以包括文本和/或其它类型的内容(例如，图像或照片)。附件1616可以为附接于具体消息的任何信息的内容。 例如，可以把附接于消息的文档放置在消息1610的这一部分中。本技术领域中的普通技术人员将会意识到存储消息信息的其它方式。例如，可以把附件存储在另一个存储结构中，并且把对其的参照放置在附件1616中。
在可选的实施例中，把每一对话的所有消息作为单一的记录、文档或数据结构存储在消息数据库中。
用户、消息以及对话的数据结构
图17说明了根据本发明的实施例的用户数据库和消息索引。用户数据库1702可以存储有关用户的信息。所存储的信息可以包括用户信息1704。用户信息1704可能包括与用户偏好相关的各种类型的用户信息、安全信息、或者可由本发明的不同实施例所使用的任何其它信息。用户数据库可以包括用于标识用户的诸如用户ID(I) (1706)至用户ID(m) (1708)的用户标识信息，用户ID(I) (1706)至用户ID(m) (1708)的中m可代表系统的用户的数目。特定的用户ID(m) (1708)可以为针对每一用户的唯一的标识符，例如η个比特的二进制数字。也可以使用其它类型的用户标识。
在某些实施例中，使用用户的用户ID标识用于存储关于过滤器、与用户的邮件账户相关的查询和标签的信息的数据结构集合1720。在某些实施例中，这些数据结构包括用于存储代表用户所提交的最后几个查询的信息的查询超高速缓冲器1722 ；—组用于存储用户定义的过滤器(如果存在的话)的过滤器数据结构17Μ ；以及用于存储代表用户定义的标签的信息的标签数据结构17沈。可以把存储在查询超高速缓冲器1722中的信息所代表的新近的查询提交于用户，例如提交于编组框348 (图:3Β)中的用户，以使用户能够容易地把这些查询重新提交于对话管理系统。当把每一新消息添加于用户的邮件账户时，在对其处理期间，对话管理系统使用用户定义的过滤器。可以把涉及用户定义的标签的所存储信息提交于用户，例如提交于编组框347(图;3B)中的用户，以使用户能够容易地请求载有用户选择标签的对话的列表。
用户的用户ID可以用于标识对应于该用户的全文本与属性索引1710。可以把全文本与属性索引1710与具体的用户相关联，以致不同的用户不能够搜索与该具体用户相关的消息的索引。全文本与属性索引1710把关于消息的信息存储在用户的邮件账户中，以致针对全文本与属性索引1710所施加的查询可以返回匹配消息(如果存在的话)的列表。 该列表可作为消息标识符的列表被返回。
包含于针对具体消息的全文本与属性索引1710中的信息，可以包括消息的消息 ID 1712、消息1714的内容1714以及关于消息的属性1716的信息。消息ID 1712是消息的唯一的标识符(即，相对于针对同一用户所存储的所有其它消息而言，是唯一的)。消息 ID 1712可以为η个比特的数字，用于引用存储在消息数据库1702中的具体消息。在一个实施例中，消息ID 1712可以为64个比特数字。消息ID 1712可以由时标信息和与消息ID 1712所指消息的内容相关的信息构成。时标信息可以为由系统所提供的Y个比特(例如， 32个比特或48个比特)的时标，例如，其表示SMTP网关1018何时接收消息。与消息的内容相关的信息可以为消息内容的64-Y个比特的杂凑(hash)。
把消息的内容作为全索引的和可搜索的项目放入索引中。当针对项目或项目的组合搜索索引1710时，索引返回与项目或项目的组合相匹配的消息的消息列表(例如，消息 ID)。某些预先定义的条件可以规定比所有匹配的消息少的返回。在另一个实施例中，索引 1710返回与查询中的项目或项目的组合相匹配的对话列表(例如，对话ID)。
在一个实施例中，根据包含在每一被索引消息的消息ID 1712中的时标信息，对全文本与属性索引1710中的搜索项目的条目进行排序，以致可以优先返回与搜索项目相匹配的最近消息。例如，可以对相应于索引1710中的每一项目的消息的消息ID的列表进行排序，以致可以在列表中先于具有较旧时标的消息ID列出具有最新时标的消息ID。在其它实施例中，与每一消息相关的日期/时间信息表示每一消息的接收的日期和/或时间，但这一日期/时间信息未嵌入在消息ID中。然而，在这样的实施例中，对索引1710中的条目进行排列，以致在列表中可先于具有较旧日期/时间值的消息ID列出具有最新日期/时间值的消息的消息ID。
也对与消息相关联的任何属性1716进行索引(即，将它们包括在索引1710中)。 把属性1716添加于全文本与属性索引1710中，以致对于具体属性的查询可以返回那些与该具体属性相匹配的消息。当把标签或属性添加于对话或者从对话去除时，相应地修改索引1710。索引包括把每一所定义的标签或属性映像于载有该标签或属性的所有消息(或在其它实施例中，为对话)的条目或数据。于是，当把标签添加于对话时，也把数据添加于索引1710，以把该标签映像于对话中的所有消息。当把标签从对话去除时，也去除把该标签映像于对话中的消息的索引中的数据，或者使该索引无效。在某些实施例中，还把每一个与对话相关联的标签或属性添加于对话数据库1808(图18)中的一个或多个条目。
尽管可以把全文本与属性索引1710配置为能够把查询项目映像于各个消息ID 1712，然而也可以提供其它数据结构以把消息ID映像于对话标识符。图18描述了一个这样的数据结构集合的逻辑图。本技术领域中的普通技术人员将会意识到可以使用许多不同的数据结构把搜索查询项目映像于对话或对话标识符。
如先前所描述的，用户数据库1702可以包括引用与具体用户相关联的全文本与属性索引1710的用户ID 1708。参照图18，可以把具体消息ID 1712与消息至对话映像 1804中的具体对话ID 1802相关联。消息至对话映像1804中的每一个条目把消息ID 1712关联(即映像)于对话ID 1802。在某些实施例中，对话ID 1804为η个比特的数字。这一数字唯一地标识了消息ID 1712所标识的消息所属于的具体对话。在这些实施例中，用户的邮件账户中的每一对话具有不同的对话ID。
为了标识与具体对话相关联的其它消息，可以使用用户对话数据库1808。例如，当标识包括在其中一条或多条消息已与具体搜索查询相匹配的对话中的其余消息时，可以使用这样的数据库。用户对话数据库包括多个对话条目1810。每一个对话条目1810存储与该对话相关的消息的列表(或者代表消息的其它数据结构)。例如，对话条目1812可以包括消息条目1816的链接列表，每一个消息条目对应于对话中的具体消息。例如，根据与对话中的消息相关联的日期/时间值对链接列表进行排序。示例性的消息条目1816包括具体消息的消息ID 1712、报头1818以及标签1820。报头1818可以包括先前所描述的报头信息1612的全部或一部分。标签1820可以包括标识与消息相关联的某些属性的信息。可以把具体条目1822的消息ID(4) 1712与消息数据库1602中的具体消息相关联。在某些实施例中，消息条目1816不包括对应消息体的内容。
在某些实施例中，索引1708中的信息和对话条目1812中的信息有助于把新消息与具体对话相关联，在图11的阶段1106中可做到这一点，而且不必存取消息数据库1602。 当把消息标识为尽可能地与新到达的消息相匹配(图12的阶段1204)时，可以使用匹配消息的报头1818来实现对最佳匹配消息的判断以及因此对最佳匹配对话的判断。例如，报头 1818可以包括能够将它们(呈正常化形式的)与新到达消息的正常化主题加以比较的消息的主题信息。也可以把报头1818中的其它信息与正被处理的流入消息的报头信息进行比较。一旦已经把对话标识为匹配的，则可以把所标识对话的消息条目的标签1820中所标识的属性施用于流入的消息(图13的阶段1307)，而不必从消息数据库检索任何消息。
当从对话中删除消息时，可以修改对话条目1812，而不会影响对话中的其它消息。在这种情况下，可以从消息条目的链接列表中删除对应于将要删除的消息的消息条目 1816(在对话条目1812中)。于是，将不再把该消息与该对话相关联。在某些实施例中，考虑到删除操作，也可以对消息至对话映像1804进行修改。
如先前所描述的，在某些情况下，例如，人们可能希望使用特定属性对删除的消息进行标记，但不从对话中去除该消息。当条件为使得可以从对话中去除该消息时，可以象以上所描述的那样做。可允许从消息至对话映像1802和对话条目1812中去除消息的条件， 可包括自从把消息标记为删除后的一定量时间的消逝、用户的动作、或者其它触发事件。
也可以把对话标识为删除，但尚未从用户的邮件账户中去除。当把对话永久性地从用户的邮件账户中去除时，则可以去除针对该对话的消息至对话映象1802的条目。另外，还可以从对话数据库1808中去除对应的对话条目1812，而且还可以从索引1708中去除对话中的消息的索引条目。
如以上所示，在另一个实施例中，全文本消息索引1708响应查询，返回对话标识符的列表。在本实施例中，可以省略消息至对话映像1802。取而代之，由对话数据库提供完成相应于查询的对话的处理所需的主要映像。
参照图19，实现上述方法的对话服务器102的实施例包括一个或多个处理单元 (CPU) 1902、一个或多个网络或其它通信接口 1904、存储器1006以及一个或多个用于互连这些部件的通信总线1908。对话服务器102可以有选择地包括含有显示设备和键盘的用户接口。存储器1906可以包括高速随机存取存储器，并且还可以包括非易失存储器，例如一个或多个磁盘或光存储盘。存储器1906可以包括远离CPU 1902放置的海量存储器。存储器1906可以存储
操作系统1916，其包括用于处理各种基本系统服务和用于执行依赖于硬件的任务的规程；
网络通信模块(或指令)1918，其用于经由诸如^1切111讨、其它广域网、局域网、大都市区域网等的一个或多个网络通信接口 1904 (有线或无线)，把对话服务器102连接于其它计算机；以及
对话引擎1002模块，其用于响应来自对话助手110的请求，以及向对话助手110 提供答复，如先前所描述的，并且可以包括
处理新消息模块1920，其用于处理新消息，如先前所描述的；
搜索模块1922，其用于搜索用户的消息，如先前所描述的，搜索模块1922包括用于处理来自由用户1922所提供的输入的搜索请求的模块，以及用于处理由对话助手110所启动的系统生成搜索的模块1拟6 ；
对话助手加载器1928，其用于向对话助手110提供允许对话助手处理从对话服务器102提供于其的信息的信息。在某些实施例中，当首次把客户机计算机连接于对话服务器102以处理电子邮件消息时，引用对话助手加载器1928，以把对话助手110加载于客户机计算机。在某些实施例中，每次启动电子邮件对话期时，对话助手加载器19 把对话助手 110加载在客户机计算机上，而在其它实施例中，客户机计算机把对话助手110从一个电子邮件对话期保持到另一个电子邮件对话期；
回答格式化模块1930，其用于提供要被提供给对话助手110的格式化信息，如先前所描述的，包括对话排序模块1932，其用于根据预先定义的准则来排序对话，如先前所描述的；选择对话模块1034，其用于从可以被返回的总数中选择要被返回到对话助手110的对话的预先确定的数目；未被读取/未被查看消息的标识发送者1936，其用于标识被标记为“未被读取”(即消息未被查看或未被标记为被读取的)消息的消息，如先前所描述的；自我参照模块1938，其用于提供关于用自我参照信息取代用户标识的信息，如先前所描述的； 新接收者模块1940，其用于标识和提供关于向对话新添加接收者的信息，如先前所描述的； 去除接收者模块1942，其用于标识和提供关于不再为对话的一部分的接收者的信息，如先前所描述的；摘录模块1944，其用于获取和提供关于匹配消息的某一文本的信息，如先前所描述的；以及全文本模块1946，其用于检索传输于对话助手110的消息的全文本，如先前所描述的；以及格式拼写检查模块1948，其用于格式化从拼写检查器1014返回的信息；
修改属性模块1950，其用于修改对话和消息的属性，如先前所描述的；
删除/去除模块1095，其用于标记用于删除和随后去除它们的消息或对话，如先前所描述的；
过滤模块1954，其用于创建、监视以及执行过滤，如先前所描述的；以及
编写/发送模块1956，其允许用户编写消息，并且把所得到的消息提交于SMTP网关 1016。
应该认识到，以上所描述的各种特性，例如拼写检查处理的示例性实施例，以及显示方法，不局限于电子消息处理或电子邮件。例如，在其它实施例中，可以把上述的拼写检查方法或用户接口施用于各种类型的文档(例如，字处理文档)，或者与各种类型的文档相结合加以实现。
已参照具体的实施例解释性地进行了以上的描述。然而，上述说明性的讨论不旨在穷举性地描述本发明，或者把本发明限制于所公开的精确形式。鉴于以上的讲授，对本发明进行众多的修改与变更是可能的。对实施例的选择与描述，旨在最好地解释本发明的原理及其实际的应用，从而可使本技术领域中的其它技术人员能够通过所考虑的适合于具体应用的各种修改，来充分利用本发明及其各种实施例。
权利要求
1.一种管理消息的方法，在具有一个或多个处理器和存储由所述一个或多个处理器执行的程序的存储器的服务器执行，该方法包括存储包括多个消息的对话，其中，所述对话与第一标签相关联并且所述多个消息中的消息与第二标签相关联；从位于远程的客户机系统接收预先定义的请求；以及通过产生并向所述客户机系统发送对话的列表来响应所述预先定义的请求，包括当所述预先定义的请求对应于与第一标签相关联的对话的请求时，按照第一列表中的所有对话都与第一标签相关联的准则，产生并向所述客户机系统发送对话的第一列表，其中，第一列表中的一个或多个对话中的每一个包括多个消息；以及当所述预先定义的请求对应于包括与第二标签相关联的消息的对话的请求时，按照第二列表中的所有对话都包括已经向其分配第二标签的至少一个消息的准则，产生并向所述客户机系统发送对话的第二列表，其中，第二列表中的一个或多个对话中的每一个包括多个消息。
2.如权利要求1所述的方法，其中，第一标签是用户定义的标签。
3.如权利要求1至2中任何一项所述的方法，其中，第二标签是从由以下各项组成的组中选择的系统定义的属性未读、收件箱、草稿、垃圾邮件、以及废纸篓。
4.如权利要求1至2中任何一项所述的方法，其中，第二标签是星号标签，指示消息重要性。
5.如权利要求1所述的方法，其中，产生并向所述客户机系统发送对话的第一列表包括进行格式化，以便显示包括第一标签的对话的第一列表。
6.如权利要求1、2和5中任何一项所述的方法，其中，所述多个消息中的每个消息被自动分配系统定义的第二标签“全部邮件”。
7.一种服务器系统，包括用于存储包括多个消息的对话的装置，其中，所述对话与第一标签相关联并且所述多个消息中的消息与第二标签相关联；用于从位于远程的客户机系统接收预先定义的请求；以及用于通过产生并向所述客户机系统发送对话的列表来响应所述预先定义的请求的装置，包括当所述预先定义的请求对应于与第一标签相关联的对话的请求时，按照第一列表中的所有对话都与第一标签相关联的准则，产生并向所述客户机系统发送对话的第一列表，其中，第一列表中的一个或多个对话中的每一个包括多个消息；以及当所述预先定义的请求对应于包括与第二标签相关联的消息的对话的请求时，按照第二列表中的所有对话都包括已经向其分配第二标签的至少一个消息的准则，产生并向所述客户机系统发送对话的第二列表，其中，第二列表中的一个或多个对话中的每一个包括多个消息。
8.如权利要求7所述的系统，其中，第一标签是用户定义的标签。
9.如权利要求7至8中任何一项所述的系统，其中，第二标签是从由以下各项组成的组中选择的系统定义的属性未读、收件箱、草稿、垃圾邮件、以及废纸篓。
10.如权利要求7至8中任何一项所述的系统，其中，第二标签是星号标签，指示消息重要性。
11.如权利要求7所述的系统，其中，所述响应装置包括用于格式化的装置，用于显示包括所述列表中的各自的对话的第一标签的对话的第一列表。
12.如权利要求7、8和11中任何一项所述的系统，其中，所述多个消息中的每个消息被所述响应装置自动分配系统定义的第二标签“全部邮件”。
全文摘要
公开了管理消息的方法和服务器系统。该方法包括存储包括多个消息的对话，对话与第一标签相关联而多个消息中的消息与第二标签相关联；从远程客户机系统接收预先定义的请求；以及通过产生并向客户机系统发送对话的列表来响应预先定义的请求，包括当预先定义的请求对应于与第一标签相关联的对话的请求时，按照第一列表中的所有对话都与第一标签相关联的准则，产生并向客户机系统发送对话的第一列表；以及当预先定义的请求对应于包括与第二标签相关联的消息的对话的请求时，按照第二列表中的所有对话都包括已经向其分配第二标签的至少一个消息的准则，产生并向客户机系统发送对话的第二列表，其中，第一列表和第二列表中每一个对话包括多个消息。
文档编号G06Q10/00GK102521733SQ20111041643
公开日2012年6月27日 申请日期2005年3月25日 优先权日2004年3月31日
发明者保罗.T.布克海特, 布赖恩.D.拉科夫斯基, 张北为, 林景宜, 桑杰夫.辛 申请人:谷歌股份有限公司