專利名稱：用于多方的電子郵件接收方法和系統(tǒng)的制作方法
技術領域：
本發(fā)明一般涉及電子郵件(e-mail)，特別涉及用于向用戶通知消息處置(disposition)的方法和系統(tǒng)。
背景技術：
在很多情形下，除了電子郵件消息的原始發(fā)件人之外的人也想要知道特定收件人是否閱讀了消息。例如需要共享項目信息的合作環(huán)境下的人就是如此。例如，當一起工作進行客戶服務的工作組中有成員向客戶發(fā)送有關工作日程的消息時，該工作組中的人也是如此。如果各個組成員知道客戶是否閱讀了工作日程信息，則與客戶的以后交流將更高效。然而，使用傳統(tǒng)接收通知(receipt notification)，傳統(tǒng)電子郵件實現(xiàn)只能向原始發(fā)件人通知收件人閱讀了消息。因此，需要一種填補傳統(tǒng)電子郵件方法中的這一空缺的系統(tǒng)和方法。

發(fā)明內(nèi)容
對上述問題的解決方案的一個例子包括從發(fā)件人接收消息；將消息提供給收件人；以及響應來自發(fā)件人的請求，將多方接收通知(multiple-partyreceipt notification)自動發(fā)送給多個人。因此，多個人可以被通知向收件人提供了消息內(nèi)容。在某些情況下，這種解決方案可以包括提供對多方接收通知的限制。


當結(jié)合下面附圖考慮下面詳細描述時，可以更好地理解本發(fā)明。在不同附圖中使用相同的標號表示類似或相同項目。
圖1示出能夠執(zhí)行本發(fā)明的計算機系統(tǒng)的簡化例子。
圖2是根據(jù)本發(fā)明內(nèi)容的用于提供電子郵件服務的方法和系統(tǒng)的示例高級方框圖。
圖3是根據(jù)本發(fā)明內(nèi)容的用于發(fā)送電子郵件的方法的示例流程圖。
圖4是根據(jù)本發(fā)明內(nèi)容的向用戶提供輸出的用戶界面的示例圖。
圖5是用戶界面的另一個示例圖。
圖6是用于提供電子郵件服務的方法和系統(tǒng)的另一個示例高級方框圖。
具體實施例方式
下面例子涉及使用一臺或多臺計算機，并且可能涉及使用一個或多個通信網(wǎng)絡，或者使用能夠處理電子郵件的各種設備如蜂窩電話或雙向?qū)ず魴C。本發(fā)明對于在其上運行它的計算機或其他設備的類型不受限制，并且對于所用網(wǎng)絡的類型不受限制。
下面是在本發(fā)明的說明書和權(quán)利要求中所使用的術語的定義“應用”是指對計算機技術的任何特定使用，或者允許對計算機技術的特定使用的任何軟件。
“比較”是指放在一起以便找出任何相同點或不同點，包括定性或定量相同點或不同點。
“組件”是指任何單元或部件，并且可以包括由硬件或軟件或兩者組成的單元。
“計算機可用介質(zhì)”是指用于與計算機通信的任何載波、信號或傳輸設施以及任何類型的計算機存儲器如軟盤、硬盤、隨機存取存儲器(RAM)、只讀存儲器(ROM)、CD-ROM、快閃ROM、非易失性ROM以及非易失性存儲器。
“多方收件通知”是指在將另一條消息成功遞送給收件人之后向多方報告該另一條消息的處置的任何通知消息。
“通知”是指報告另一條消息的處置的任何通知消息。這在傳統(tǒng)上稱作“消息處置通知”(MDN)、“閱讀接收”、“確認”或“接收通知”。盡管在此所述的MDN的細節(jié)不同于傳統(tǒng)MDN，但在本文中可以使用這些傳統(tǒng)術語。
“輸出”或“正在輸出”是指以某種方式產(chǎn)生、發(fā)送或表現(xiàn)(turning out)，包括但不限于在紙上打印、在屏幕上顯示、向盤寫入或者使用音頻設備。
“選擇信號”是指來自利用任何輸入設備包括鍵盤，語音識別接口，或者指向設備如跟蹤球、游戲棒、觸摸式輸入板或屏幕或者鼠標進行選擇的用戶的任何信號。
使用計算機“存儲”數(shù)據(jù)或信息是指在任意長度的時間內(nèi)將數(shù)據(jù)或信息置于任何類型的計算機存儲器如軟盤、硬盤、隨機存取存儲器(RAM)、只讀存儲器(ROM)、CD-ROM、快閃ROM、非易失性ROM以及非易失性存儲器內(nèi)。
“標記”是指傳達關于消息或者關于如何處理消息的信息的任何元素、標簽、字段或值。
圖1示出可以用來實施本發(fā)明的信息處理系統(tǒng)的簡化例子。本發(fā)明可以在各種硬件平臺包括嵌入系統(tǒng)、蜂窩電話、雙向?qū)ず魴C、手持計算機、個人計算機、工作站、服務器和大型機上實現(xiàn)。圖1的計算機系統(tǒng)具有至少一個處理器110。處理器110通過系統(tǒng)總線112互連到隨機存取存儲器(RAM)116、只讀存儲器(ROM)114以及輸入/輸出(I/O)適配器118，其中輸入/輸出(I/O)適配器118用于將諸如盤單元120和磁帶驅(qū)動器140的外圍設備連接到總線112。該系統(tǒng)還具有用戶接口適配器122，用于將鍵盤124、鼠標126或其他用戶接口設備如音頻輸出設備166和音頻輸入設備168連接到總線112。該系統(tǒng)還具有用于將該信息處理系統(tǒng)連接到通信網(wǎng)絡150的通信適配器134，以及用于將總線112連接到顯示設備138的顯示適配器136。通信適配器134可以將圖1所示的系統(tǒng)與成百或者甚至是上千的類似系統(tǒng)或其他設備如遠程打印機、遠程服務器或遠程存儲單元進行鏈接。圖1所示的系統(tǒng)可以鏈接到局域網(wǎng)(有時稱作內(nèi)部網(wǎng))和諸如因特網(wǎng)的廣域網(wǎng)。
雖然圖1所示的計算機系統(tǒng)能夠執(zhí)行在此所述的過程，但是該計算機系統(tǒng)只是計算機系統(tǒng)的一個例子。本領域的技術人員應該理解，很多其他計算機系統(tǒng)設計也能夠執(zhí)行在此所述的過程。
圖2是根據(jù)本發(fā)明內(nèi)容的用于提供電子郵件服務的方法和系統(tǒng)的示例高級方框圖。如同這樣的系統(tǒng)可以通過內(nèi)部網(wǎng)或例如因特網(wǎng)或者通過某種其他網(wǎng)絡(如220所示)運行。在左上部，名稱為約翰的用戶(未示出)是電子郵件消息201的原始發(fā)件人。該系統(tǒng)允許使用發(fā)件人的電子郵件客戶端230從約翰傳送電子郵件給名稱為“比爾”的收件人(未示出)，他利用收件人的電子郵件客戶端250。發(fā)件人的電子郵件客戶端230從發(fā)件人接收輸入，為電子郵件消息201請求多方接收通知。電子郵件消息201通過網(wǎng)絡220發(fā)送到收件人的電子郵件客戶端250。在本例中，比爾是原始收件人。比爾與位于260的多方(多個用戶)約瑟和N合作一個項目，當向比爾提供了消息201的內(nèi)容時約瑟和N需要對此知道。
在將另一條消息成功遞送給收件人之后報告該另一條消息的處置的電子郵件通知消息在傳統(tǒng)上稱作“消息處置通知”(MDN)、“閱讀接收”、“確認”或“接收通知”。在本文中可以使用這些術語，但是在此所述的MDN的細節(jié)不同于傳統(tǒng)MDN。在本例中，多方接收通知通過網(wǎng)絡220從收件人的電子郵件客戶端250自動發(fā)送(MDN 204)到多方的電子郵件客戶端260。
概括一下到此所述的例子，圖2涉及以下操作在250接收來自位于230的發(fā)件人的消息201；將消息提供給位于250的收件人；并且響應于來自發(fā)件人(位于230)的請求，自動發(fā)送多方接收通知(204)給多個人(位于260)。因此，這些人可以被通知向位于250的收件人提供了消息201的內(nèi)容。
繼續(xù)描述圖2中的例子的細節(jié)，約瑟和任何個數(shù)的其他人(以“N”代表，因為其他人可以編號為1到N)利用位于260的電子郵件客戶端。位于230、250和260的電子郵件客戶端可以包括能夠處理電子郵件的任何軟件和硬件。
圖2中的例子涉及向用戶(例如，位于260的約瑟)提供關于向誰提供了電子郵件消息201的內(nèi)容的信息(基于MDN 204)。該信息將標識通過其電子郵件客戶端250向其提供了消息內(nèi)容的比爾。還可以涉及存儲和更新該信息。這可以通過當MDN 204到達時位于260的約瑟保存它們來完成。存儲和更新信息也可以在一定程度上進行組織和自動化(例如使用通知數(shù)據(jù)庫210)。
通知數(shù)據(jù)庫210可以是電子郵件客戶端260的組件，或者通知數(shù)據(jù)庫210可以與電子郵件客戶端260相獨立，但是可以對其進行訪問。
圖2中的例子涉及將次級接收通知205發(fā)送給位于230的發(fā)件人。次級接收通知205向發(fā)件人通知，位于260的多個人之一接收到多方接收通知204之一。因此，在任何時間點，位于230的發(fā)件人將完全了解本例中的通信(即，完全了解誰閱讀了消息201、或者誰被通知向位于250的收件人提供了消息201的內(nèi)容)。從250到230的傳統(tǒng)MDN(未示出)在此可以起到使位于230的發(fā)件人完全了解誰閱讀了消息201的作用。
圖3是根據(jù)本發(fā)明內(nèi)容的用于發(fā)送電子郵件的方法的示例流程圖。處理在310開始，這可以表示用戶(發(fā)件人)啟動電子郵件應用以準備發(fā)送電子郵件給一個或多個收件人。在決定操作320中，例如如果發(fā)件人決定在不請求任何多方接收通知的情況下發(fā)送消息，則可以采取“否”分支。在這種情況下，發(fā)件人將直接進行編寫和編輯消息(350)并且發(fā)送置有傳統(tǒng)標記(tag)的消息(360)。
另一方面，如果需要任何多方接收通知，則可以在決定操作320中采取“是”分支，這代表從發(fā)件人接收對電子郵件消息的多方接收通知的請求。然后，本例中的下一個步驟是提供輸入字段或菜單330。這是一種為多方接收通知和電子郵件消息的其他選項從發(fā)件人接收輸入的方式。一種可能性是向發(fā)件人提供一組菜單項。另一種可能性是在不存在來自發(fā)件人的相反輸入的情況下自動提供缺省行為。
在340從發(fā)件人接收輸入。這可以涉及接收名稱和電子郵件地址的文本輸入，或者從發(fā)件人接收表示多個人要自動接收多方接收通知的選擇信號。這可以涉及從發(fā)件人接收表示這些人還要接收電子郵件消息的選擇信號。
下一步，允許編寫和編輯消息，350。然后，在360對消息置上標記并且發(fā)送。這涉及為消息創(chuàng)建表示多個人要自動接收多方接收通知的至少一個標記，并且發(fā)送置有該標記的消息。創(chuàng)建標記是響應于在320的原始發(fā)件人對多方接收通知的請求。對消息置上標記，并且將其發(fā)送給一個或多個收件人。這可以涉及將消息發(fā)送給將要接收多方接收通知的多人組。例如，電子郵件應用可以使用傳輸控制協(xié)議(TCP)，并且將單獨的消息副本遞送到每個收件人的郵箱。將適當標簽施加于每個副本。在本例中，當發(fā)送完成時，處理在370結(jié)束。另外參見圖5和圖4，其中，圖5示出用戶界面的另一個例子，而圖4涉及向接收多方接收通知的人的輸出。
關于圖3，上述操作的次序可以改變。例如，在塊340接收輸入發(fā)生于在塊350進行編輯之后或者與其同時發(fā)生也在本發(fā)明的范圍內(nèi)。本領域的技術人員應該認識，圖3中的塊可以以不同的次序方式排列，但是仍然描述了本發(fā)明。可以對上述圖增加若干塊來描述細節(jié)或者可選特性；還可以減去一些塊來表示簡化例子。
現(xiàn)在描述圖3中可能涉及的細節(jié)，考慮在塊360對消息置上標記并發(fā)送中的操作。多方接收通知的一種實現(xiàn)可以使用標記來傳達關于如何處理消息的信息。電子郵件消息的一些預定義、通用標記是公知的，但是在此所述的標記是新的，并且它們傳達關于消息處理新類型的信息。對于本發(fā)明，可以使用各種實現(xiàn)方法?？梢钥紤]兩個實現(xiàn)因素(factor)。一個因素是將元數(shù)據(jù)加入到消息中，包括多方接收通知的請求和要自動接收多方接收通知的人的電子郵件地址。例如，考慮名稱為“Multi-Notification(多通知)”的假設字段，根據(jù)該字段，可以采取特殊操作。這可能增加到消息中，并且如果被填充，則將包含想要自動接收多方接收通知的人的電子郵件地址。第二因素是由電子郵件應用讀取該元數(shù)據(jù)。
本發(fā)明可以使用發(fā)件人的軟件和收件人的軟件雙方都理解的任何標記。例如，對于一個組織的內(nèi)部電子郵件系統(tǒng)，可以采用獨特的實現(xiàn)方案。另一方面，本發(fā)明可以基于公知的電子郵件標準來實現(xiàn)。
標準的一些例子是簡單郵件傳輸協(xié)議(SMTP)、多用途網(wǎng)際郵件擴展(MIME)以及安全多用途網(wǎng)際郵件擴展(S/MIME)。關于這些標準，參考下列文獻Jonathan B.Postel，請求注解(Request for Comments，RFC)#821，SimpleMail Transfer Protocol(簡單郵件傳輸協(xié)議)，1982；David H.Crocker.RFC#822，Standard for the Format of ARPA Internet Text Message(ARPA網(wǎng)際文本消息的格式標準)，1982；J.Palme，RFC#2076，Common Internet Message Header(公共網(wǎng)際消息首標)，1997；以及R.Faiman，RFC#2298，An Extensible MessageFormat for Message Disposition Notifications(消息處置通知的可擴展消息格式)，1998。網(wǎng)際電子郵件消息包括兩個部分首標和主體。首標可以用來實現(xiàn)本發(fā)明。首標具有傳達關于消息的信息的字段-值對的集合。例如，名稱為“Multi-Notification”的假設字段可能具有“jose@acmecorp.com”和“n@acmecorp.com”的值，以標識想要自動接收多方接收通知的人的電子郵件地址。
在RFC#2298中給出的一個例子是其值為至少一個郵箱的“Disposition-Notification-To(處置通知至)”字段。然而，根據(jù)RFC#2298，“如果在‘Disposition-Notification-To’首標中存在多于一個的不同地址，則應當獲得用戶確認(或者不發(fā)送MDN)”。消息中的Disposition-Notification-To首標僅是消息處置通知(MDN)的請求。
擴展字段提供一種通過基于RFC#2298中描述的標準來實現(xiàn)多方接收通知的方式。以“X-”開頭的擴展字段名稱未被定義為標準字段；根據(jù)RFC#2298，這些名稱被保留用于實驗的用途。應用的名稱應當遵循“X-”。
例如，考慮名稱為“X-Multimail-Multi-Notification-To(X多郵件多通知至)”的擴展字段，其中具有兩個或多個郵箱的值來標識想要自動接收多方接收通知的人的電子郵件地址。本例用于將實現(xiàn)多方接收通知的、名稱為“Multimail(多郵件)”的電子郵件應用。本例假設該標記通過原始發(fā)件人的軟件施加于消息(在圖3的塊360)，并且被收件人的軟件理解。因而，收件人的軟件自動發(fā)送MDN到想要自動接收多方接收通知的人的電子郵件地址。
繼續(xù)描述圖3中可能涉及的細節(jié)，可擴展標記語言(XML)提供一種包含和管理設計成處理不同數(shù)據(jù)系統(tǒng)之間的數(shù)據(jù)交換的信息的方式。因此，它適合于實現(xiàn)本發(fā)明。參考Elliotte Rusty Harold和W.Scott Means的書籍XML ina Nutshell(XML簡要)，(O’Reilly & Associates，2001)。作為一般規(guī)則，XML消息使用“屬性”來包含關于數(shù)據(jù)的信息，并且使用“元素”來包含實際數(shù)據(jù)。
多方接收通知可以通過以諸如電子商務XML(ebXML)的基于XML的標準、特別是ebXML消息服務為基礎來實現(xiàn)。參考Pim van der Eijk的文章TheebXML Messageing Service(ebXML消息服備)，(O’Reilly & Associates，2003)，該文章可從O’Reilly的XML.com網(wǎng)站上獲得。ebXML消息服務規(guī)范擴展了簡單對象訪問協(xié)議(SOAP)規(guī)范，以提供安全和可靠特性。ebXML消息服務可以用來在SMTP、超文本傳輸協(xié)議(HTTP)、或者一些其他通信協(xié)議上傳輸消息。對消息內(nèi)容不存在任何限制。用戶可以選擇由不同廠商提供的ebXML消息服務實現(xiàn)，包括開放源碼實現(xiàn)。關于接收通知，ebXML消息服務定義<SOAPHeader>的可選<ebAckRequested>擴展元素。響應消息處理程序可以發(fā)送包含<ebAcknowledgment(確認)>擴展元素的消息，其中<ebRefToMessageId>元素指定哪一條消息正被確認。
參考由結(jié)構(gòu)化信息標準促進組織(OASIS)技術委員會提出的規(guī)范ebXMLMessaging Services Specification 2.0(ebXML消息服務規(guī)范2.0)(OASIS 2002)，它給出了下面的AckRequested元素的例子，其中帶有這樣的注釋“所生成的Acknowledgment(確認)元素的目標必須是沿著反向消息路徑擔當發(fā)件方(From Party)角色的ebXML MSH節(jié)點…”。在下面例子中，向擔當收件方(ToParty)角色的消息處理程序(MSH)節(jié)點請求確認消息<ebAckRequested SOAPmustUnderstand＝″1″ebversion＝″2.0″ebsigned＝″false″/>
ebXML消息服務規(guī)范給出了下面規(guī)則“如果存在AckRequested元素，則生成確認消息作為響應(這可以作為另一條消息的一部分)”。
ebXML消息服務規(guī)范給出了目標為收件方MSH的確認消息的下面例子<ebAcknowledgment SOAPmustUnderstand＝″1″ebversion＝″2.0″>
<ebTimestamp>2001-03-09T122230</ebTimestamp>
<ebRefToMessageId>323210e52151ec747ffc@xtacy</ebRefToMessageId>
<ebFrom><ebPartyId>uriwww.example.com</ebPartyId></ebFrom>
</ebAcknowledgment>
根據(jù)OASISebXML消息服務規(guī)范2.0，如果正在發(fā)送確認消息，則MessageHeader(消息首標)元素的值如下設置“To(至)元素可以(MAY)填充從所接收消息提取的From(來自)元素”。
多方接收通知可以如下基于ebXML消息服務來實現(xiàn)。例如，考慮名稱為“MultiAckRequested(多確認請求)”的擴展元素。本例假定該標記通過原始發(fā)件人的軟件施加于消息(在圖3的塊360)，并且被收件人的軟件理解。可以指定新的多方接收通知的行為，從而電子郵件應用遵循如下規(guī)則“如果存在MultiAckRequested元素，則作為響應生成確認消息，并且將它們直接發(fā)送到指定電子郵件地址(想要自動接收多方接收通知的人的電子郵件地址)”。電子郵件應用向“To”元素填充要接收接收通知的多個用戶的列表。用戶列表可以在從所接收消息中提取的MultiAckRequested元素中找到。
圖4是根據(jù)本發(fā)明內(nèi)容的向用戶提供輸出的用戶界面的示例圖。首先概述一下，圖4示出適于多個用戶(如圖2中位于260的約瑟和N)的用戶界面401。圖4中的例子涉及基于接收多方接收通知的輸出。圖4示出向用戶提供電子郵件消息的表示(410或405或兩者)以及關于誰察覺(perceive)了電子郵件消息的內(nèi)容或者向誰提供了電子郵件消息的內(nèi)容的信息(420)的一個例子。如同這樣的用戶界面可以與如同圖2-3所示的例子的方法和系統(tǒng)一起使用。如同這樣的用戶界面可以采用文本和圖形來顯示，如在401所示。還可以通過音頻輸出向發(fā)件人提供可聽接口(audible interface)。
現(xiàn)在描述圖4的細節(jié)，接口401提供基于接收多方接收通知的輸出。界面401的頂部是位于410的消息表示，其中包括消息標識符如“主題”描述或標識號。多方接收通知可以通過將消息中的消息標識符與多方接收通知中的消息標識符進行比較來與消息進行匹配。包括在位于410的消息表示中的還有消息日期以及發(fā)件人和收件人的名稱。在另一種格式中，如同401的界面可以提供多條消息的表示。例如，用戶可以從列表中選取感興趣的消息。
在界面401中，存在顯示誰打開了該消息的區(qū)域420，在本例中，在411、412和413列出的三個收件人打開了該消息。一個可選特性是在405提供或顯示至少一些消息內(nèi)容，作為消息的表示。在405可見或可訪問的內(nèi)容可以包括文本、圖形、音頻內(nèi)容或視頻內(nèi)容。換句話說，圖4示出用于向用戶提供電子郵件消息的表示(410或405或兩者)以及關于向誰提供了電子郵件消息內(nèi)容的信息(420)的裝置的一個例子。
顯示誰打開了該消息、在區(qū)域420提供的信息可以不時地改變。這將涉及存儲和更新信息，如上面結(jié)合圖2的通知數(shù)據(jù)庫210所述。區(qū)域420可以用作通知電子郵件消息內(nèi)容已被提供給至少一個收件人的裝置。區(qū)域420可以用作通知電子郵件消息已被至少一個收件人接收和刪除(不一定打開)的裝置。區(qū)域420可以根據(jù)如下一種或多種多方接收通知來提供輸出(1)報告消息已經(jīng)被以某種方式(例如，轉(zhuǎn)發(fā)或傳真)發(fā)送到某處的通知；(2)報告消息內(nèi)容已經(jīng)被提供給閱讀收件人郵箱的某人的通知；(3)報告消息被刪除(也許沒有被顯示)的通知。
通過如同401的界面，可以通過語音識別接口從發(fā)件人接收語音輸入，或者發(fā)件人可能標記(mark)顯示在屏幕上的文字。例如，用戶的輸入可能指定用戶感興趣的特定消息，或者指定界面401的特定行為。
圖5是用戶界面的另一個示例圖。菜單502可以用作從發(fā)件人接收對電子郵件消息的多方接收通知的請求的裝置。圖5示出用于從發(fā)件人接收輸入(在列525或框526中)來指定兩個或更多人接收電子郵件消息的多方接收通知的裝置的一個例子。菜單可以采用文本和圖形來顯示，如502所示。還可以通過音頻輸出向發(fā)件人提供可聽菜單。還可以通過語音識別接口從發(fā)件人接收語音輸入，或者發(fā)件人可以標記顯示在屏幕上的文字。這些例子是從發(fā)件人接收輸入以創(chuàng)建標記的方式。這些例子可以與如圖2-3所示的方法和系統(tǒng)一起使用。菜單502可以用作電子郵件客戶端的用戶界面。電子郵件客戶端可以用作創(chuàng)建表示兩個或更多人要接收多方接收通知的至少一個標記的裝置，以及用于發(fā)送置有標記的消息的裝置。
菜單502的頂部是輸入請求520。在菜單502中，可以選擇的名稱包括“用戶1”521、“用戶N”522、“我的組”523、以及“其他組”524。名稱“用戶N”代表可以存在例如編號為1-N的任意個數(shù)的用戶的名稱。列525中的帶陰影圓圈表示來自發(fā)件人的輸入，以標記顯示在屏幕上的名稱。這代表熟悉的圖形輸入技術，如將光標或指針定位于圓形按鈕或復選框之上，并且單擊它以發(fā)送選擇信號。另一種可能性是在沒有來自發(fā)件人的相反輸入的情況下自動提供缺省設置(例如，“我的組”523)。還可能存在另外的輸入可能性，如用于輸入文本的輸入空白框(在菜單502的底部以框526表示)。
如同502的菜單可以用作適合于多個用戶(圖2中位于260的約瑟和N)的限制設置裝置。例如，用戶可以設置僅允許發(fā)送多方接收通知至日常合作者的組(例如，“我的組”523)的權(quán)限策略。另外參見下面參照圖6對限制的描述。
圖6是根據(jù)本發(fā)明內(nèi)容的用于提供電子郵件服務的方法和系統(tǒng)的另一個示例高級方框圖。考慮合作環(huán)境的情況，其中位于250的組成員瑪麗和比爾以及位于260的約瑟和N共享關于向誰提供了發(fā)送給該組的電子郵件消息的內(nèi)容的信息可能是有用的(通過箭頭201和601所示的路徑)。位于250和260的每個電子郵件客戶端可以用作提供消息給收件人的裝置。位于250和260的每個電子郵件客戶端可以用作響應于標記而自動發(fā)送多方接收通知(606)給位于250和260的其他組成員的裝置。位于250和260的每個電子郵件客戶端可以用作向用戶提供電子郵件消息表示以及關于向誰提供了電子郵件消息內(nèi)容的信息的裝置?？梢陨婕按鎯透滦畔?例如，使用通知數(shù)據(jù)庫210)。換句話說，圖6中的例子涉及多個用戶將多方接收通知(606)發(fā)送給多個用戶。
位于260的每個電子郵件客戶端可以用作將次級接收通知205發(fā)送給位于230的發(fā)件人的裝置。這向發(fā)件人通知位于250的組成員之一接收到多方接收通知606之一。
圖6中的例子涉及提供對多方接收通知的限制。提供對多方接收通知的限制(以限制器670代表)可以涉及如下一個或多個限制行為禁止多方接收通知，限制多方接收通知的內(nèi)容，以及根據(jù)域策略或權(quán)限策略限制多方接收通知的操作。該策略可以涉及例如檢查要接收多方接收通知的人的位置或身份。
電子郵件客戶端(位于250或260)可以用作提供限制的裝置。例如，考慮用于響應用戶請求而禁止多方接收通知(位于606的MDN)的裝置。電子郵件客戶端(位于250或260)通過遵循如下規(guī)則強制禁止“如果用戶請求禁止多方接收通知，則濾掉它們”。因而，電子郵件客戶端將不顯示或保存多方接收通知(位于606的MDN)。作為另一個例子，考慮用于限制多方接收通知內(nèi)容的裝置。位于250的瑪麗可能希望與位于260的大組僅打有限的交道?，旣惖碾娮余]件客戶端(位于250)可以通過在多方接收通知中僅包括瑪麗的名稱而不包括其電子郵件客戶端(位于250)的電子郵件地址，為瑪麗提供一些隱私保護。作為另一個例子，考慮根據(jù)權(quán)限策略限制多方接收通知操作的裝置。位于260的約瑟可以設置僅允許將多方接收通知(位于606的MDN)發(fā)送給其日常合作者的組的權(quán)限策略。約瑟的電子郵件客戶端(位于260)在發(fā)送多方接收通知(位于606的MDN)給其他用戶之前檢測權(quán)限。約瑟的電子郵件客戶端(位于260)根據(jù)如下規(guī)則“如果其他用戶沒有接收MDN的權(quán)限，則不發(fā)送MDN給該用戶”，在某些情況下拒絕發(fā)送MDN。該權(quán)限策略可以類似于例如UNIX或相關操作系統(tǒng)中的訪問權(quán)限。
在圖6中，限制器670的位置代表存在集中方式來實現(xiàn)限制。通過網(wǎng)絡220的箭頭代表消息通過各個網(wǎng)絡組件。在限制器670附近經(jīng)過的箭頭606和205代表諸如電子郵件路由系統(tǒng)或郵件服務器的一個或多個組件可以遵循對MDN 606和次級MDN 205施加限制的規(guī)則。例如，考慮用于根據(jù)域策略限制多方接收通知發(fā)送的裝置。電子郵件路由系統(tǒng)通過遵循如下規(guī)則“如果消息不在域X中發(fā)起，則不發(fā)送MDN”或者“如果消息在該公司內(nèi)部網(wǎng)之外發(fā)起，則不發(fā)送MDN”，根據(jù)原始發(fā)件人的電子郵件客戶端230的域，在某些情況下拒絕發(fā)送MDN。
總之，上文示出了遞送關于向誰提供了電子郵件消息內(nèi)容的信息的解決方案的一些例子。
本發(fā)明的可能實現(xiàn)之一是應用程序，即來自計算機可用介質(zhì)如計算機存儲器的、由計算機處理器執(zhí)行的指令(程序代碼)集。在計算機需要之前，該指令集可以存儲在另一個計算機存儲器例如硬盤驅(qū)動器、或者移動存儲器如光盤(最終用于CD ROM中)或軟盤(最終用于軟盤驅(qū)動器中)中，或者通過因特網(wǎng)或其他計算機網(wǎng)絡下載。因此，本發(fā)明可以作為具有用于計算機中的計算機可執(zhí)行指令的計算機可用介質(zhì)來實現(xiàn)。另外，雖然所述各個方法便于在采用軟件選擇性激活或重新配置的通用計算機中實現(xiàn)，但是本領域的普通技術人員應該知道，這些方法可以采用構(gòu)造成執(zhí)行該方法的硬件、固件或者更專用的設備來實現(xiàn)。
盡管本發(fā)明是參照其特定實施例來描述的，但本領域的技術人員應該理解，在不脫離本發(fā)明的精神和范圍的情況下，可以對其進行形式和細節(jié)的前述和其他變更。所附權(quán)利要求在其范圍內(nèi)包括屬于本發(fā)明的實質(zhì)精神和范圍內(nèi)的所有這些變更和修改。此外，應該理解，本發(fā)明僅由所附權(quán)利要求限定。本領域的技術人員應該理解，如果希望特定數(shù)目的引入的權(quán)利要求元素，則將在權(quán)利要求中明確表達該意圖，并且在缺少該表達的情況下，不存在這樣的限定。對于非限制例子，為有助于理解起見，所附權(quán)利要求可能包含介紹性的短語“至少一個”或“一個或多個”來引入權(quán)利要求元素。然而，使用這樣的短語不應解釋成，由諸如“a”或“an”的不定冠詞引入的權(quán)利要求元素限制包含該被引入權(quán)利要求元素的任何特定權(quán)利要求僅包含一個該元素，即使當同一權(quán)利要求包含引入短語“至少一個”或“一個或多個”以及諸如“a”或“an”的不定冠詞時也是如此；這同樣適用于權(quán)利要求中定冠詞的使用。
權(quán)利要求
1.一種用于提供電子郵件服務的方法，所述方法包括從發(fā)件人接收對電子郵件消息的多方接收通知的請求；響應所述請求，為所述消息創(chuàng)建至少一個標記，該標記表示多個人要自動接收所述多方接收通知；以及發(fā)送置有所述標記的所述消息。
2.如權(quán)利要求1所述的方法，其中，所述接收請求還包括向所述發(fā)件人提供一組菜單項；以及從所述發(fā)件人接收表示所述多個人要自動接收所述多方接收通知的選擇信號。
3.如權(quán)利要求1所述的方法，還包括從所述發(fā)件人接收表示所述多個人還要自動接收所述電子郵件消息的選擇信號；以及將所述電子郵件消息發(fā)送給所述多個人。
4.如權(quán)利要求1所述的方法，還包括從所述發(fā)件人接收所述消息；將所述消息提供給收件人；以及響應所述請求，將所述多方接收通知自動發(fā)送給所述多個人。
5.如權(quán)利要求1所述的方法，還包括向用戶提供所述電子郵件消息的表示，以及關于向誰提供了所述電子郵件消息的內(nèi)容的信息；其中所述用戶是所述多個人之一。
6.如權(quán)利要求5所述的方法，還包括存儲和更新所述信息。
7.如權(quán)利要求1所述的方法，還包括從以下項選擇的至少一個限制行為響應用戶的請求，禁止對所述用戶的所述多方接收通知；根據(jù)域策略，限制所述多方接收通知的操作；根據(jù)權(quán)限策略，限制所述多方接收通知的操作；以及限制所述多方接收通知的內(nèi)容。
8.如權(quán)利要求1所述的方法，還包括將次級接收通知發(fā)送給所述發(fā)送者；其中所述次級接收通知向所述發(fā)件人通知所述多個人之一接收到所述多方接收通知之一。
9.一種用于提供電子郵件服務的方法，所述方法包括從發(fā)件人接收消息；將所述消息提供給收件人；以及響應于來自所述發(fā)件人的請求，自動發(fā)送多方接收通知給多個人；從而所述多個人可以被通知向所述收件人提供了所述消息的內(nèi)容。
10.如權(quán)利要求9所述的方法，還包括向用戶提供所述電子郵件消息的表示，以及關于向誰提供了所述電子郵件消息的內(nèi)容的信息，其中所述用戶是所述多個人之一。
11.如權(quán)利要求10所述的方法，還包括存儲和更新所述信息。
12.如權(quán)利要求9所述的方法，還包括從以下項中選擇的至少一個限制行為響應用戶請求，禁止對所述用戶的所述多方接收通知；根據(jù)域策略，限制所述多方接收通知的操作；根據(jù)權(quán)限策略，限制所述多方接收通知的操作；以及限制所述多方接收通知的內(nèi)容。
13.如權(quán)利要求9所述的方法，還包括將次級接收通知發(fā)送給所述發(fā)送者；其中所述次級接收通知向所述發(fā)件人通知所述多個人之一接收到所述多方接收通知之一。
14.一種用于提供電子郵件服務的系統(tǒng)，所述系統(tǒng)包括用于從發(fā)件人接收對電子郵件消息的多方接收通知的請求的裝置；用于響應于所述請求、為所述消息創(chuàng)建表示所述多個人要自動接收所述多方接收通知的至少一個標記的裝置；用于將所述消息提供給收件人的裝置；用于響應于所述標記、將所述多方接收通知自動發(fā)送給所述多個人的裝置；以及用于提供對所述多方接收通知的限制的裝置。
15.如權(quán)利要求14所述的系統(tǒng)，還包括用于向用戶提供所述電子郵件消息的表示、以及關于向誰提供了所述電子郵件消息的內(nèi)容的信息的裝置；其中所述用戶是所述多個人之一。
16.如權(quán)利要求15所述的系統(tǒng)，還包括用于存儲和更新所述信息的裝置。
17.如權(quán)利要求14所述的系統(tǒng)，其中所述用于提供限制的裝置還包括以下裝置中的至少之一用于根據(jù)域策略限制所述多方接收通知的操作的裝置；用于限制所述多方接收通知的內(nèi)容的裝置；用于根據(jù)權(quán)限策略限制所述多方接收通知的操作的裝置；以及用于響應于用戶請求禁止而禁止所述用戶的所述多方接收通知的裝置。
18.如權(quán)利要求14所述的系統(tǒng)，還包括用于將次級接收通知發(fā)送給所述發(fā)送者的裝置；其中所述次級接收通知向所述發(fā)件人通知所述多個人之一接收到所述多方接收通知之一。
19.一種計算機可用介質(zhì)，具有計算機可執(zhí)行指令，用于提供電子郵件服務，所述計算機可用介質(zhì)包括用于從發(fā)件人接收指定多個人接收電子郵件消息的多方接收通知的請求的裝置；用于響應于所述請求、為所述消息創(chuàng)建表示所述多個人要自動接收所述多方接收通知的至少一個標記的裝置；用于將所述消息提供給收件人的裝置；用于響應于所述標記、將所述多方接收通知自動發(fā)送給所述多個人的裝置；以及用于提供對所述多方接收通知的限制的裝置。
20.如權(quán)利要求19所述的計算機可用介質(zhì)，還包括用于向用戶提供所述電子郵件消息的表示、以及關于向誰提供了所述電子郵件消息的內(nèi)容的信息的裝置；其中所述用戶是所述多個人之一。
21.如權(quán)利要求20所述的計算機可用介質(zhì)，還包括用于存儲和更新所述信息的裝置。
22.如權(quán)利要求19所述的計算機可用介質(zhì)，其中所述用于提供限制的裝置還包括以下裝置中的至少之一用于根據(jù)域策略限制所述多方接收通知的操作的裝置；用于限制所述多方接收通知的內(nèi)容的裝置；用于根據(jù)權(quán)限策略限制所述多方接收通知的操作的裝置；以及用于響應于用戶請求而禁止對所述用戶的所述多方接收通知的裝置。
23.如權(quán)利要求19所述的計算機可用介質(zhì)，還包括用于將次級接收通知發(fā)送給所述發(fā)送者的裝置；其中所述次級接收通知向所述發(fā)件人通知所述多個人之一接收到所述多方接收通知之一。
全文摘要
一種用于多方的電子郵件接收方法和系統(tǒng)。在此提供的解決方案的一個例子包括從發(fā)件人接收消息；將消息提供給收件人；以及響應于來自發(fā)件人的請求，將多方接收通知自動發(fā)送給多個人。因此，多個人可以被通知向收件人提供了消息的內(nèi)容。在某些情況下，這種解決方案可以包括提供對多方接收通知的限制。
文檔編號H04L12/58GK1578275SQ200410034829
公開日2005年2月9日 申請日期2004年4月15日 優(yōu)先權(quán)日2003年7月24日
發(fā)明者卡爾·P·古斯勒, 里克·A·漢密爾頓第二, 哈里·沙茨, 詹姆斯·W·西曼 申請人:國際商業(yè)機器公司