专利名称：用于多方的电子邮件接收方法和系统的制作方法
技术领域：
本发明一般涉及电子邮件(e-mail)，特别涉及用于向用户通知消息处置(disposition)的方法和系统。
背景技术：
在很多情形下，除了电子邮件消息的原始发件人之外的人也想要知道特定收件人是否阅读了消息。例如需要共享项目信息的合作环境下的人就是如此。例如，当一起工作进行客户服务的工作组中有成员向客户发送有关工作日程的消息时，该工作组中的人也是如此。如果各个组成员知道客户是否阅读了工作日程信息，则与客户的以后交流将更高效。然而，使用传统接收通知(receipt notification)，传统电子邮件实现只能向原始发件人通知收件人阅读了消息。因此，需要一种填补传统电子邮件方法中的这一空缺的系统和方法。
发明内容
对上述问题的解决方案的一个例子包括从发件人接收消息；将消息提供给收件人；以及响应来自发件人的请求，将多方接收通知(multiple-partyreceipt notification)自动发送给多个人。因此，多个人可以被通知向收件人提供了消息内容。在某些情况下，这种解决方案可以包括提供对多方接收通知的限制。
当结合下面附图考虑下面详细描述时，可以更好地理解本发明。在不同附图中使用相同的标号表示类似或相同项目。
图1示出能够执行本发明的计算机系统的简化例子。
图2是根据本发明内容的用于提供电子邮件服务的方法和系统的示例高级方框图。
图3是根据本发明内容的用于发送电子邮件的方法的示例流程图。
图4是根据本发明内容的向用户提供输出的用户界面的示例图。
图5是用户界面的另一个示例图。
图6是用于提供电子邮件服务的方法和系统的另一个示例高级方框图。
具体实施例方式
下面例子涉及使用一台或多台计算机，并且可能涉及使用一个或多个通信网络，或者使用能够处理电子邮件的各种设备如蜂窝电话或双向寻呼机。本发明对于在其上运行它的计算机或其他设备的类型不受限制，并且对于所用网络的类型不受限制。
下面是在本发明的说明书和权利要求中所使用的术语的定义“应用”是指对计算机技术的任何特定使用，或者允许对计算机技术的特定使用的任何软件。
“比较”是指放在一起以便找出任何相同点或不同点，包括定性或定量相同点或不同点。
“组件”是指任何单元或部件，并且可以包括由硬件或软件或两者组成的单元。
“计算机可用介质”是指用于与计算机通信的任何载波、信号或传输设施以及任何类型的计算机存储器如软盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、CD-ROM、快闪ROM、非易失性ROM以及非易失性存储器。
“多方收件通知”是指在将另一条消息成功递送给收件人之后向多方报告该另一条消息的处置的任何通知消息。
“通知”是指报告另一条消息的处置的任何通知消息。这在传统上称作“消息处置通知”(MDN)、“阅读接收”、“确认”或“接收通知”。尽管在此所述的MDN的细节不同于传统MDN，但在本文中可以使用这些传统术语。
“输出”或“正在输出”是指以某种方式产生、发送或表现(turning out)，包括但不限于在纸上打印、在屏幕上显示、向盘写入或者使用音频设备。
“选择信号”是指来自利用任何输入设备包括键盘，语音识别接口，或者指向设备如跟踪球、游戏棒、触摸式输入板或屏幕或者鼠标进行选择的用户的任何信号。
使用计算机“存储”数据或信息是指在任意长度的时间内将数据或信息置于任何类型的计算机存储器如软盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、CD-ROM、快闪ROM、非易失性ROM以及非易失性存储器内。
“标记”是指传达关于消息或者关于如何处理消息的信息的任何元素、标签、字段或值。
图1示出可以用来实施本发明的信息处理系统的简化例子。本发明可以在各种硬件平台包括嵌入系统、蜂窝电话、双向寻呼机、手持计算机、个人计算机、工作站、服务器和大型机上实现。图1的计算机系统具有至少一个处理器110。处理器110通过系统总线112互连到随机存取存储器(RAM)116、只读存储器(ROM)114以及输入/输出(I/O)适配器118，其中输入/输出(I/O)适配器118用于将诸如盘单元120和磁带驱动器140的外围设备连接到总线112。该系统还具有用户接口适配器122，用于将键盘124、鼠标126或其他用户接口设备如音频输出设备166和音频输入设备168连接到总线112。该系统还具有用于将该信息处理系统连接到通信网络150的通信适配器134，以及用于将总线112连接到显示设备138的显示适配器136。通信适配器134可以将图1所示的系统与成百或者甚至是上千的类似系统或其他设备如远程打印机、远程服务器或远程存储单元进行链接。图1所示的系统可以链接到局域网(有时称作内部网)和诸如因特网的广域网。
虽然图1所示的计算机系统能够执行在此所述的过程，但是该计算机系统只是计算机系统的一个例子。本领域的技术人员应该理解，很多其他计算机系统设计也能够执行在此所述的过程。
图2是根据本发明内容的用于提供电子邮件服务的方法和系统的示例高级方框图。如同这样的系统可以通过内部网或例如因特网或者通过某种其他网络(如220所示)运行。在左上部，名称为约翰的用户(未示出)是电子邮件消息201的原始发件人。该系统允许使用发件人的电子邮件客户端230从约翰传送电子邮件给名称为“比尔”的收件人(未示出)，他利用收件人的电子邮件客户端250。发件人的电子邮件客户端230从发件人接收输入，为电子邮件消息201请求多方接收通知。电子邮件消息201通过网络220发送到收件人的电子邮件客户端250。在本例中，比尔是原始收件人。比尔与位于260的多方(多个用户)约瑟和N合作一个项目，当向比尔提供了消息201的内容时约瑟和N需要对此知道。
在将另一条消息成功递送给收件人之后报告该另一条消息的处置的电子邮件通知消息在传统上称作“消息处置通知”(MDN)、“阅读接收”、“确认”或“接收通知”。在本文中可以使用这些术语，但是在此所述的MDN的细节不同于传统MDN。在本例中，多方接收通知通过网络220从收件人的电子邮件客户端250自动发送(MDN 204)到多方的电子邮件客户端260。
概括一下到此所述的例子，图2涉及以下操作在250接收来自位于230的发件人的消息201；将消息提供给位于250的收件人；并且响应于来自发件人(位于230)的请求，自动发送多方接收通知(204)给多个人(位于260)。因此，这些人可以被通知向位于250的收件人提供了消息201的内容。
继续描述图2中的例子的细节，约瑟和任何个数的其他人(以“N”代表，因为其他人可以编号为1到N)利用位于260的电子邮件客户端。位于230、250和260的电子邮件客户端可以包括能够处理电子邮件的任何软件和硬件。
图2中的例子涉及向用户(例如，位于260的约瑟)提供关于向谁提供了电子邮件消息201的内容的信息(基于MDN 204)。该信息将标识通过其电子邮件客户端250向其提供了消息内容的比尔。还可以涉及存储和更新该信息。这可以通过当MDN 204到达时位于260的约瑟保存它们来完成。存储和更新信息也可以在一定程度上进行组织和自动化(例如使用通知数据库210)。
通知数据库210可以是电子邮件客户端260的组件，或者通知数据库210可以与电子邮件客户端260相独立，但是可以对其进行访问。
图2中的例子涉及将次级接收通知205发送给位于230的发件人。次级接收通知205向发件人通知，位于260的多个人之一接收到多方接收通知204之一。因此，在任何时间点，位于230的发件人将完全了解本例中的通信(即，完全了解谁阅读了消息201、或者谁被通知向位于250的收件人提供了消息201的内容)。从250到230的传统MDN(未示出)在此可以起到使位于230的发件人完全了解谁阅读了消息201的作用。
图3是根据本发明内容的用于发送电子邮件的方法的示例流程图。处理在310开始，这可以表示用户(发件人)启动电子邮件应用以准备发送电子邮件给一个或多个收件人。在决定操作320中，例如如果发件人决定在不请求任何多方接收通知的情况下发送消息，则可以采取“否”分支。在这种情况下，发件人将直接进行编写和编辑消息(350)并且发送置有传统标记(tag)的消息(360)。
另一方面，如果需要任何多方接收通知，则可以在决定操作320中采取“是”分支，这代表从发件人接收对电子邮件消息的多方接收通知的请求。然后，本例中的下一个步骤是提供输入字段或菜单330。这是一种为多方接收通知和电子邮件消息的其他选项从发件人接收输入的方式。一种可能性是向发件人提供一组菜单项。另一种可能性是在不存在来自发件人的相反输入的情况下自动提供缺省行为。
在340从发件人接收输入。这可以涉及接收名称和电子邮件地址的文本输入，或者从发件人接收表示多个人要自动接收多方接收通知的选择信号。这可以涉及从发件人接收表示这些人还要接收电子邮件消息的选择信号。
下一步，允许编写和编辑消息，350。然后，在360对消息置上标记并且发送。这涉及为消息创建表示多个人要自动接收多方接收通知的至少一个标记，并且发送置有该标记的消息。创建标记是响应于在320的原始发件人对多方接收通知的请求。对消息置上标记，并且将其发送给一个或多个收件人。这可以涉及将消息发送给将要接收多方接收通知的多人组。例如，电子邮件应用可以使用传输控制协议(TCP)，并且将单独的消息副本递送到每个收件人的邮箱。将适当标签施加于每个副本。在本例中，当发送完成时，处理在370结束。另外参见图5和图4，其中，图5示出用户界面的另一个例子，而图4涉及向接收多方接收通知的人的输出。
关于图3，上述操作的次序可以改变。例如，在块340接收输入发生于在块350进行编辑之后或者与其同时发生也在本发明的范围内。本领域的技术人员应该认识，图3中的块可以以不同的次序方式排列，但是仍然描述了本发明。可以对上述图增加若干块来描述细节或者可选特性；还可以减去一些块来表示简化例子。
现在描述图3中可能涉及的细节，考虑在块360对消息置上标记并发送中的操作。多方接收通知的一种实现可以使用标记来传达关于如何处理消息的信息。电子邮件消息的一些预定义、通用标记是公知的，但是在此所述的标记是新的，并且它们传达关于消息处理新类型的信息。对于本发明，可以使用各种实现方法。可以考虑两个实现因素(factor)。一个因素是将元数据加入到消息中，包括多方接收通知的请求和要自动接收多方接收通知的人的电子邮件地址。例如，考虑名称为“Multi-Notification(多通知)”的假设字段，根据该字段，可以采取特殊操作。这可能增加到消息中，并且如果被填充，则将包含想要自动接收多方接收通知的人的电子邮件地址。第二因素是由电子邮件应用读取该元数据。
本发明可以使用发件人的软件和收件人的软件双方都理解的任何标记。例如，对于一个组织的内部电子邮件系统，可以采用独特的实现方案。另一方面，本发明可以基于公知的电子邮件标准来实现。
标准的一些例子是简单邮件传输协议(SMTP)、多用途网际邮件扩展(MIME)以及安全多用途网际邮件扩展(S/MIME)。关于这些标准，参考下列文献Jonathan B.Postel，请求注解(Request for Comments，RFC)#821，SimpleMail Transfer Protocol(简单邮件传输协议)，1982；David H.Crocker.RFC#822，Standard for the Format of ARPA Internet Text Message(ARPA网际文本消息的格式标准)，1982；J.Palme，RFC#2076，Common Internet Message Header(公共网际消息首标)，1997；以及R.Faiman，RFC#2298，An Extensible MessageFormat for Message Disposition Notifications(消息处置通知的可扩展消息格式)，1998。网际电子邮件消息包括两个部分首标和主体。首标可以用来实现本发明。首标具有传达关于消息的信息的字段-值对的集合。例如，名称为“Multi-Notification”的假设字段可能具有“jose@acmecorp.com”和“n@acmecorp.com”的值，以标识想要自动接收多方接收通知的人的电子邮件地址。
在RFC#2298中给出的一个例子是其值为至少一个邮箱的“Disposition-Notification-To(处置通知至)”字段。然而，根据RFC#2298，“如果在‘Disposition-Notification-To’首标中存在多于一个的不同地址，则应当获得用户确认(或者不发送MDN)”。消息中的Disposition-Notification-To首标仅是消息处置通知(MDN)的请求。
扩展字段提供一种通过基于RFC#2298中描述的标准来实现多方接收通知的方式。以“X-”开头的扩展字段名称未被定义为标准字段；根据RFC#2298，这些名称被保留用于实验的用途。应用的名称应当遵循“X-”。
例如，考虑名称为“X-Multimail-Multi-Notification-To(X多邮件多通知至)”的扩展字段，其中具有两个或多个邮箱的值来标识想要自动接收多方接收通知的人的电子邮件地址。本例用于将实现多方接收通知的、名称为“Multimail(多邮件)”的电子邮件应用。本例假设该标记通过原始发件人的软件施加于消息(在图3的块360)，并且被收件人的软件理解。因而，收件人的软件自动发送MDN到想要自动接收多方接收通知的人的电子邮件地址。
继续描述图3中可能涉及的细节，可扩展标记语言(XML)提供一种包含和管理设计成处理不同数据系统之间的数据交换的信息的方式。因此，它适合于实现本发明。参考Elliotte Rusty Harold和W.Scott Means的书籍XML ina Nutshell(XML简要)，(O’Reilly & Associates，2001)。作为一般规则，XML消息使用“属性”来包含关于数据的信息，并且使用“元素”来包含实际数据。
多方接收通知可以通过以诸如电子商务XML(ebXML)的基于XML的标准、特别是ebXML消息服务为基础来实现。参考Pim van der Eijk的文章TheebXML Messageing Service(ebXML消息服备)，(O’Reilly & Associates，2003)，该文章可从O’Reilly的XML.com网站上获得。ebXML消息服务规范扩展了简单对象访问协议(SOAP)规范，以提供安全和可靠特性。ebXML消息服务可以用来在SMTP、超文本传输协议(HTTP)、或者一些其他通信协议上传输消息。对消息内容不存在任何限制。用户可以选择由不同厂商提供的ebXML消息服务实现，包括开放源码实现。关于接收通知，ebXML消息服务定义<SOAPHeader>的可选<ebAckRequested>扩展元素。响应消息处理程序可以发送包含<ebAcknowledgment(确认)>扩展元素的消息，其中<ebRefToMessageId>元素指定哪一条消息正被确认。
参考由结构化信息标准促进组织(OASIS)技术委员会提出的规范ebXMLMessaging Services Specification 2.0(ebXML消息服务规范2.0)(OASIS 2002)，它给出了下面的AckRequested元素的例子，其中带有这样的注释“所生成的Acknowledgment(确认)元素的目标必须是沿着反向消息路径担当发件方(From Party)角色的ebXML MSH节点…”。在下面例子中，向担当收件方(ToParty)角色的消息处理程序(MSH)节点请求确认消息<ebAckRequested SOAPmustUnderstand＝″1″ebversion＝″2.0″ebsigned＝″false″/>
ebXML消息服务规范给出了下面规则“如果存在AckRequested元素，则生成确认消息作为响应(这可以作为另一条消息的一部分)”。
ebXML消息服务规范给出了目标为收件方MSH的确认消息的下面例子<ebAcknowledgment SOAPmustUnderstand＝″1″ebversion＝″2.0″>
<ebTimestamp>2001-03-09T122230</ebTimestamp>
<ebRefToMessageId>323210e52151ec747ffc@xtacy</ebRefToMessageId>
<ebFrom><ebPartyId>uriwww.example.com</ebPartyId></ebFrom>
</ebAcknowledgment>
根据OASISebXML消息服务规范2.0，如果正在发送确认消息，则MessageHeader(消息首标)元素的值如下设置“To(至)元素可以(MAY)填充从所接收消息提取的From(来自)元素”。
多方接收通知可以如下基于ebXML消息服务来实现。例如，考虑名称为“MultiAckRequested(多确认请求)”的扩展元素。本例假定该标记通过原始发件人的软件施加于消息(在图3的块360)，并且被收件人的软件理解。可以指定新的多方接收通知的行为，从而电子邮件应用遵循如下规则“如果存在MultiAckRequested元素，则作为响应生成确认消息，并且将它们直接发送到指定电子邮件地址(想要自动接收多方接收通知的人的电子邮件地址)”。电子邮件应用向“To”元素填充要接收接收通知的多个用户的列表。用户列表可以在从所接收消息中提取的MultiAckRequested元素中找到。
图4是根据本发明内容的向用户提供输出的用户界面的示例图。首先概述一下，图4示出适于多个用户(如图2中位于260的约瑟和N)的用户界面401。图4中的例子涉及基于接收多方接收通知的输出。图4示出向用户提供电子邮件消息的表示(410或405或两者)以及关于谁察觉(perceive)了电子邮件消息的内容或者向谁提供了电子邮件消息的内容的信息(420)的一个例子。如同这样的用户界面可以与如同图2-3所示的例子的方法和系统一起使用。如同这样的用户界面可以采用文本和图形来显示，如在401所示。还可以通过音频输出向发件人提供可听接口(audible interface)。
现在描述图4的细节，接口401提供基于接收多方接收通知的输出。界面401的顶部是位于410的消息表示，其中包括消息标识符如“主题”描述或标识号。多方接收通知可以通过将消息中的消息标识符与多方接收通知中的消息标识符进行比较来与消息进行匹配。包括在位于410的消息表示中的还有消息日期以及发件人和收件人的名称。在另一种格式中，如同401的界面可以提供多条消息的表示。例如，用户可以从列表中选取感兴趣的消息。
在界面401中，存在显示谁打开了该消息的区域420，在本例中，在411、412和413列出的三个收件人打开了该消息。一个可选特性是在405提供或显示至少一些消息内容，作为消息的表示。在405可见或可访问的内容可以包括文本、图形、音频内容或视频内容。换句话说，图4示出用于向用户提供电子邮件消息的表示(410或405或两者)以及关于向谁提供了电子邮件消息内容的信息(420)的装置的一个例子。
显示谁打开了该消息、在区域420提供的信息可以不时地改变。这将涉及存储和更新信息，如上面结合图2的通知数据库210所述。区域420可以用作通知电子邮件消息内容已被提供给至少一个收件人的装置。区域420可以用作通知电子邮件消息已被至少一个收件人接收和删除(不一定打开)的装置。区域420可以根据如下一种或多种多方接收通知来提供输出(1)报告消息已经被以某种方式(例如，转发或传真)发送到某处的通知；(2)报告消息内容已经被提供给阅读收件人邮箱的某人的通知；(3)报告消息被删除(也许没有被显示)的通知。
通过如同401的界面，可以通过语音识别接口从发件人接收语音输入，或者发件人可能标记(mark)显示在屏幕上的文字。例如，用户的输入可能指定用户感兴趣的特定消息，或者指定界面401的特定行为。
图5是用户界面的另一个示例图。菜单502可以用作从发件人接收对电子邮件消息的多方接收通知的请求的装置。图5示出用于从发件人接收输入(在列525或框526中)来指定两个或更多人接收电子邮件消息的多方接收通知的装置的一个例子。菜单可以采用文本和图形来显示，如502所示。还可以通过音频输出向发件人提供可听菜单。还可以通过语音识别接口从发件人接收语音输入，或者发件人可以标记显示在屏幕上的文字。这些例子是从发件人接收输入以创建标记的方式。这些例子可以与如图2-3所示的方法和系统一起使用。菜单502可以用作电子邮件客户端的用户界面。电子邮件客户端可以用作创建表示两个或更多人要接收多方接收通知的至少一个标记的装置，以及用于发送置有标记的消息的装置。
菜单502的顶部是输入请求520。在菜单502中，可以选择的名称包括“用户1”521、“用户N”522、“我的组”523、以及“其他组”524。名称“用户N”代表可以存在例如编号为1-N的任意个数的用户的名称。列525中的带阴影圆圈表示来自发件人的输入，以标记显示在屏幕上的名称。这代表熟悉的图形输入技术，如将光标或指针定位于圆形按钮或复选框之上，并且单击它以发送选择信号。另一种可能性是在没有来自发件人的相反输入的情况下自动提供缺省设置(例如，“我的组”523)。还可能存在另外的输入可能性，如用于输入文本的输入空白框(在菜单502的底部以框526表示)。
如同502的菜单可以用作适合于多个用户(图2中位于260的约瑟和N)的限制设置装置。例如，用户可以设置仅允许发送多方接收通知至日常合作者的组(例如，“我的组”523)的权限策略。另外参见下面参照图6对限制的描述。
图6是根据本发明内容的用于提供电子邮件服务的方法和系统的另一个示例高级方框图。考虑合作环境的情况，其中位于250的组成员玛丽和比尔以及位于260的约瑟和N共享关于向谁提供了发送给该组的电子邮件消息的内容的信息可能是有用的(通过箭头201和601所示的路径)。位于250和260的每个电子邮件客户端可以用作提供消息给收件人的装置。位于250和260的每个电子邮件客户端可以用作响应于标记而自动发送多方接收通知(606)给位于250和260的其他组成员的装置。位于250和260的每个电子邮件客户端可以用作向用户提供电子邮件消息表示以及关于向谁提供了电子邮件消息内容的信息的装置。可以涉及存储和更新信息(例如，使用通知数据库210)。换句话说，图6中的例子涉及多个用户将多方接收通知(606)发送给多个用户。
位于260的每个电子邮件客户端可以用作将次级接收通知205发送给位于230的发件人的装置。这向发件人通知位于250的组成员之一接收到多方接收通知606之一。
图6中的例子涉及提供对多方接收通知的限制。提供对多方接收通知的限制(以限制器670代表)可以涉及如下一个或多个限制行为禁止多方接收通知，限制多方接收通知的内容，以及根据域策略或权限策略限制多方接收通知的操作。该策略可以涉及例如检查要接收多方接收通知的人的位置或身份。
电子邮件客户端(位于250或260)可以用作提供限制的装置。例如，考虑用于响应用户请求而禁止多方接收通知(位于606的MDN)的装置。电子邮件客户端(位于250或260)通过遵循如下规则强制禁止“如果用户请求禁止多方接收通知，则滤掉它们”。因而，电子邮件客户端将不显示或保存多方接收通知(位于606的MDN)。作为另一个例子，考虑用于限制多方接收通知内容的装置。位于250的玛丽可能希望与位于260的大组仅打有限的交道。玛丽的电子邮件客户端(位于250)可以通过在多方接收通知中仅包括玛丽的名称而不包括其电子邮件客户端(位于250)的电子邮件地址，为玛丽提供一些隐私保护。作为另一个例子，考虑根据权限策略限制多方接收通知操作的装置。位于260的约瑟可以设置仅允许将多方接收通知(位于606的MDN)发送给其日常合作者的组的权限策略。约瑟的电子邮件客户端(位于260)在发送多方接收通知(位于606的MDN)给其他用户之前检测权限。约瑟的电子邮件客户端(位于260)根据如下规则“如果其他用户没有接收MDN的权限，则不发送MDN给该用户”，在某些情况下拒绝发送MDN。该权限策略可以类似于例如UNIX或相关操作系统中的访问权限。
在图6中，限制器670的位置代表存在集中方式来实现限制。通过网络220的箭头代表消息通过各个网络组件。在限制器670附近经过的箭头606和205代表诸如电子邮件路由系统或邮件服务器的一个或多个组件可以遵循对MDN 606和次级MDN 205施加限制的规则。例如，考虑用于根据域策略限制多方接收通知发送的装置。电子邮件路由系统通过遵循如下规则“如果消息不在域X中发起，则不发送MDN”或者“如果消息在该公司内部网之外发起，则不发送MDN”，根据原始发件人的电子邮件客户端230的域，在某些情况下拒绝发送MDN。
总之，上文示出了递送关于向谁提供了电子邮件消息内容的信息的解决方案的一些例子。
本发明的可能实现之一是应用程序，即来自计算机可用介质如计算机存储器的、由计算机处理器执行的指令(程序代码)集。在计算机需要之前，该指令集可以存储在另一个计算机存储器例如硬盘驱动器、或者移动存储器如光盘(最终用于CD ROM中)或软盘(最终用于软盘驱动器中)中，或者通过因特网或其他计算机网络下载。因此，本发明可以作为具有用于计算机中的计算机可执行指令的计算机可用介质来实现。另外，虽然所述各个方法便于在采用软件选择性激活或重新配置的通用计算机中实现，但是本领域的普通技术人员应该知道，这些方法可以采用构造成执行该方法的硬件、固件或者更专用的设备来实现。
尽管本发明是参照其特定实施例来描述的，但本领域的技术人员应该理解，在不脱离本发明的精神和范围的情况下，可以对其进行形式和细节的前述和其他变更。所附权利要求在其范围内包括属于本发明的实质精神和范围内的所有这些变更和修改。此外，应该理解，本发明仅由所附权利要求限定。本领域的技术人员应该理解，如果希望特定数目的引入的权利要求元素，则将在权利要求中明确表达该意图，并且在缺少该表达的情况下，不存在这样的限定。对于非限制例子，为有助于理解起见，所附权利要求可能包含介绍性的短语“至少一个”或“一个或多个”来引入权利要求元素。然而，使用这样的短语不应解释成，由诸如“a”或“an”的不定冠词引入的权利要求元素限制包含该被引入权利要求元素的任何特定权利要求仅包含一个该元素，即使当同一权利要求包含引入短语“至少一个”或“一个或多个”以及诸如“a”或“an”的不定冠词时也是如此；这同样适用于权利要求中定冠词的使用。
权利要求
1.一种用于提供电子邮件服务的方法，所述方法包括从发件人接收对电子邮件消息的多方接收通知的请求；响应所述请求，为所述消息创建至少一个标记，该标记表示多个人要自动接收所述多方接收通知；以及发送置有所述标记的所述消息。
2.如权利要求1所述的方法，其中，所述接收请求还包括向所述发件人提供一组菜单项；以及从所述发件人接收表示所述多个人要自动接收所述多方接收通知的选择信号。
3.如权利要求1所述的方法，还包括从所述发件人接收表示所述多个人还要自动接收所述电子邮件消息的选择信号；以及将所述电子邮件消息发送给所述多个人。
4.如权利要求1所述的方法，还包括从所述发件人接收所述消息；将所述消息提供给收件人；以及响应所述请求，将所述多方接收通知自动发送给所述多个人。
5.如权利要求1所述的方法，还包括向用户提供所述电子邮件消息的表示，以及关于向谁提供了所述电子邮件消息的内容的信息；其中所述用户是所述多个人之一。
6.如权利要求5所述的方法，还包括存储和更新所述信息。
7.如权利要求1所述的方法，还包括从以下项选择的至少一个限制行为响应用户的请求，禁止对所述用户的所述多方接收通知；根据域策略，限制所述多方接收通知的操作；根据权限策略，限制所述多方接收通知的操作；以及限制所述多方接收通知的内容。
8.如权利要求1所述的方法，还包括将次级接收通知发送给所述发送者；其中所述次级接收通知向所述发件人通知所述多个人之一接收到所述多方接收通知之一。
9.一种用于提供电子邮件服务的方法，所述方法包括从发件人接收消息；将所述消息提供给收件人；以及响应于来自所述发件人的请求，自动发送多方接收通知给多个人；从而所述多个人可以被通知向所述收件人提供了所述消息的内容。
10.如权利要求9所述的方法，还包括向用户提供所述电子邮件消息的表示，以及关于向谁提供了所述电子邮件消息的内容的信息，其中所述用户是所述多个人之一。
11.如权利要求10所述的方法，还包括存储和更新所述信息。
12.如权利要求9所述的方法，还包括从以下项中选择的至少一个限制行为响应用户请求，禁止对所述用户的所述多方接收通知；根据域策略，限制所述多方接收通知的操作；根据权限策略，限制所述多方接收通知的操作；以及限制所述多方接收通知的内容。
13.如权利要求9所述的方法，还包括将次级接收通知发送给所述发送者；其中所述次级接收通知向所述发件人通知所述多个人之一接收到所述多方接收通知之一。
14.一种用于提供电子邮件服务的系统，所述系统包括用于从发件人接收对电子邮件消息的多方接收通知的请求的装置；用于响应于所述请求、为所述消息创建表示所述多个人要自动接收所述多方接收通知的至少一个标记的装置；用于将所述消息提供给收件人的装置；用于响应于所述标记、将所述多方接收通知自动发送给所述多个人的装置；以及用于提供对所述多方接收通知的限制的装置。
15.如权利要求14所述的系统，还包括用于向用户提供所述电子邮件消息的表示、以及关于向谁提供了所述电子邮件消息的内容的信息的装置；其中所述用户是所述多个人之一。
16.如权利要求15所述的系统，还包括用于存储和更新所述信息的装置。
17.如权利要求14所述的系统，其中所述用于提供限制的装置还包括以下装置中的至少之一用于根据域策略限制所述多方接收通知的操作的装置；用于限制所述多方接收通知的内容的装置；用于根据权限策略限制所述多方接收通知的操作的装置；以及用于响应于用户请求禁止而禁止所述用户的所述多方接收通知的装置。
18.如权利要求14所述的系统，还包括用于将次级接收通知发送给所述发送者的装置；其中所述次级接收通知向所述发件人通知所述多个人之一接收到所述多方接收通知之一。
19.一种计算机可用介质，具有计算机可执行指令，用于提供电子邮件服务，所述计算机可用介质包括用于从发件人接收指定多个人接收电子邮件消息的多方接收通知的请求的装置；用于响应于所述请求、为所述消息创建表示所述多个人要自动接收所述多方接收通知的至少一个标记的装置；用于将所述消息提供给收件人的装置；用于响应于所述标记、将所述多方接收通知自动发送给所述多个人的装置；以及用于提供对所述多方接收通知的限制的装置。
20.如权利要求19所述的计算机可用介质，还包括用于向用户提供所述电子邮件消息的表示、以及关于向谁提供了所述电子邮件消息的内容的信息的装置；其中所述用户是所述多个人之一。
21.如权利要求20所述的计算机可用介质，还包括用于存储和更新所述信息的装置。
22.如权利要求19所述的计算机可用介质，其中所述用于提供限制的装置还包括以下装置中的至少之一用于根据域策略限制所述多方接收通知的操作的装置；用于限制所述多方接收通知的内容的装置；用于根据权限策略限制所述多方接收通知的操作的装置；以及用于响应于用户请求而禁止对所述用户的所述多方接收通知的装置。
23.如权利要求19所述的计算机可用介质，还包括用于将次级接收通知发送给所述发送者的装置；其中所述次级接收通知向所述发件人通知所述多个人之一接收到所述多方接收通知之一。
全文摘要
一种用于多方的电子邮件接收方法和系统。在此提供的解决方案的一个例子包括从发件人接收消息；将消息提供给收件人；以及响应于来自发件人的请求，将多方接收通知自动发送给多个人。因此，多个人可以被通知向收件人提供了消息的内容。在某些情况下，这种解决方案可以包括提供对多方接收通知的限制。
文档编号H04L12/58GK1578275SQ200410034829
公开日2005年2月9日 申请日期2004年4月15日 优先权日2003年7月24日
发明者卡尔·P·古斯勒, 里克·A·汉密尔顿第二, 哈里·沙茨, 詹姆斯·W·西曼 申请人:国际商业机器公司