專利名稱：用于實現(xiàn)文字概括的方法和設(shè)備的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及文字的概括。
背景技術(shù)：
存在有使用計算機的兩種主要的人對人通訊電子郵件和各種形式的實時交談(例如使用IBM公司提供的LotusSametime)。實時交談系統(tǒng)允許人們彼此輸入消息，并且這些允許消息幾乎立即出現(xiàn)在接收者的顯示屏幕上。這種系統(tǒng)允許比經(jīng)由電子郵件所可能發(fā)生的交互和討論更加自然的交互和討論。(IBM、Lotus和Sametime是在美國、或者其他國家或者兩者的國際商用機器公司的商標(biāo))。
當(dāng)用戶打字時，他們的交談系統(tǒng)產(chǎn)生“交談抄本(transcript)”顯示每個用戶說的是什么。格式通常是“姓名言語”(例如，尼科你什么時候吃午飯？)通常，將交談抄本保留在正在參與交談的每個客戶的本地。每個參與者的交談抄本通常從參與者開始加入交談的時候以后以及僅僅當(dāng)該參與者與他們正在運行的即時消息接發(fā)軟件連接的時候才顯示交談對話。所以除非當(dāng)前的參與者解釋之前的情況，否則交談的新參與者、或者臨時斷開的參與者在他們離線的時候可能錯過基于即時消息接發(fā)的小組討論。
人們已經(jīng)知道用于概括信息的技術(shù)。例如，可以在下面網(wǎng)址找到對現(xiàn)存概括工具的評論itt.nissat.tripod.com/itt0202/ruoi0202.htm。此外，美國專利6,101,532示教了對線程化(threaded)討論的概括。而且，美國專利公開2004/0122657公開了一種用于基于交互話題概括的技術(shù)，其中基于從例如一篇文字的句子位置得來的關(guān)聯(lián)高分(high score)在基于話題的概括中對于結(jié)論選擇句子。
但是，在業(yè)界需要用于概括文字的改進的技術(shù)。

發(fā)明內(nèi)容
根據(jù)一個方面，提供一種用于實現(xiàn)文字概括的方法，包括根據(jù)文字在文檔內(nèi)相對于其他文字的位置或者在一種文檔結(jié)構(gòu)中的多個文檔內(nèi)包含該文字的文檔的位置，來請求對文檔中該文字的概括。
根據(jù)另一個方面，提供一種用于實現(xiàn)文字概括的方法，包括結(jié)合文檔的版本或者包括該文檔的文檔結(jié)構(gòu)根據(jù)用戶與應(yīng)用程序的交互，請求在該文檔中對文字的概括。
當(dāng)然，對概括的請求可以是遠程服務(wù)或者可以對請求者是本地的(例如在相同的機器上)。
在一個實施方式中，應(yīng)用程序是即時消息接發(fā)應(yīng)用程序，而文檔是即時消息接發(fā)對話抄本。當(dāng)然，上述情形僅僅是示例的形式?？梢詫⒈景l(fā)明應(yīng)用于諸如電子郵件的文檔、文字處理文檔和博客文檔、以及諸如新聞組討論和wikis之類的文檔結(jié)構(gòu)。
在一個實施方式中，在與即時消息接發(fā)對話抄本關(guān)聯(lián)的即時消息接發(fā)對話中存在多個參與者，而且每個參與者具有對話抄本的版本。為了概括文字，最好請求對話抄本的版本(例如，最完整的版本)。
如果給出了文檔中的文字位置，則可以使用規(guī)則來指示用于請求的概括等級。
最好在文檔中較后出現(xiàn)的文字與在文檔中較早出現(xiàn)的文字相比需要較少程度的概括。
在一個實施方式中，將即時消息接發(fā)對話抄本分段。然后最好請求每個段內(nèi)的文字概括的不同等級。
分段可以基于抄本中的行數(shù)?；蛘?，可以使用在期間產(chǎn)生抄本的時間段?？梢允褂糜脩羝脕泶_定如何對即時消息接發(fā)對話抄本進行分段。
當(dāng)接收到概括的交談抄本段時，最好將它們合并在一起顯示給用戶。這種合并涉及對段進行格式化以指示用于每個段的概括等級。
在一個實施方式中，結(jié)合文檔的版本或者結(jié)合文檔結(jié)構(gòu)根據(jù)從用戶與應(yīng)用程序的最后交互所經(jīng)過的時間，來確定是否請求對文字的概括。
在即時消息接發(fā)情形中，可以存在幾個版本的文檔(交談抄本)，并且每個用戶經(jīng)由他們的本地應(yīng)用程序來訪問他們文檔的版本。
在一個實施方式中，根據(jù)在由用戶所發(fā)送的最后消息和用戶希望發(fā)送另一個即時消息以參與對話并因此修改抄本的指示之間的即時消息接發(fā)對話抄本所關(guān)聯(lián)的即時消息接發(fā)對話中，由其他參與者所發(fā)送的即時消息的數(shù)量，作出是否請求文字概括的決定。
注意，用戶與即時消息接發(fā)對話抄本的交互可以不是直接的交互。例如，消息的發(fā)送可能導(dǎo)致與潛在消息抄本的交互。還要注意，用戶的交互歷史可能為空-換句話說，他們對于即時消息對話是新來的，之前沒有打開過文字處理文檔或者查看過特別的新聞組等。
最好，在即時消息接發(fā)情形中，接收關(guān)于用戶希望發(fā)送即時消息的指示。
在一個實施方式中，根據(jù)用戶最后訪問文檔或者文檔結(jié)構(gòu)的時間來確定是否請求概括。可以使用文檔的長度。在另一個實施方式中，可以使用當(dāng)用戶最后與文檔結(jié)構(gòu)進行交互時所相關(guān)的文檔結(jié)構(gòu)中的文檔數(shù)量來確定是否請求概括。
根據(jù)另一個方面，提供一種用于實現(xiàn)文字概括的設(shè)備，包括用于根據(jù)文字在文檔內(nèi)相對于其他文字的位置，或者根據(jù)在文檔結(jié)構(gòu)中的多個文檔內(nèi)包含該文字的文檔的位置，請求概括該文檔中的文字的裝置。
根據(jù)另一個方面，提供一種用于實現(xiàn)文字概括的設(shè)備，包括用于結(jié)合文檔的版本或者結(jié)合包括該文檔的文檔結(jié)構(gòu)，根據(jù)用戶與應(yīng)用程序的交互來請求概括該文檔中的文字的裝置。
可以用計算機軟件來實現(xiàn)本發(fā)明。


將參照附圖僅僅通過例子來描述本發(fā)明的優(yōu)選實施方式圖1示出了如何實施這種消息接發(fā)系統(tǒng)；圖2a和2b示出了根據(jù)本發(fā)明的優(yōu)選實施方式的通過其創(chuàng)建即時消息接發(fā)抄本的概括的處理和部件；圖3a和3b示出了根據(jù)本發(fā)明的優(yōu)選實施方式的可以通過其將交談抄本進行分段并且進行不同程度概括的處理和部件；和圖4a和4b示出了根據(jù)本發(fā)明的優(yōu)選實施方式的，可以通過其根據(jù)參與者最后參與即時消息接發(fā)對話的時間將摘要提供給即時消息接發(fā)參與者的處理和部件。
具體實施例方式
能夠以各種不同的方式來實施即時消息接發(fā)。用戶通常具有“朋友”列表，他們與這些朋友經(jīng)常通訊。例如使用即時消息程序ICQ，用戶聯(lián)系ICQ服務(wù)器，從而該服務(wù)器可以確定用戶的那些朋友在線。然后，ICQ服務(wù)器將關(guān)于用戶的在線朋友的必要聯(lián)系詳情發(fā)送給用戶，而且確保其他用戶可以看見該用戶。隨后，在用戶和其他人之間發(fā)生直接的通訊。服務(wù)器不需要介入實際的對話。僅僅當(dāng)用戶終止他們的會話時，他們的機器才通知ICQ服務(wù)器，從而其可以將用戶的狀態(tài)改為“離線”。
諸如微軟即時消息者之類的其他消息接發(fā)系統(tǒng)使用中間服務(wù)器以將每個消息轉(zhuǎn)發(fā)到所期望的接收者。圖1示出了如何實現(xiàn)這種消息接發(fā)系統(tǒng)的例子。
客戶端A和B同時運行即時消息接發(fā)軟件10、20。如果客戶端A的用戶想要與客戶端B的用戶進行實時通訊，則客戶端A發(fā)送即時消息給中央即時消息接發(fā)服務(wù)器40。即時消息包含發(fā)送者和接收者識別信息，而服務(wù)器40使用用戶查詢部件50來訪問已知用戶列表55，以確定該消息的發(fā)送者對于服務(wù)器來說是否是已知的。(注意在實際使用即時消息接發(fā)軟件之前用戶通常經(jīng)由用戶注冊部件60與服務(wù)器進行注冊。)假設(shè)用戶對于服務(wù)器40已經(jīng)是已知的，并且還使用用戶查詢部件50和用戶列表55來確定消息的接收者對于服務(wù)器來說是否是已知的。而且假設(shè)該接收者是已知的，交談抄本創(chuàng)建部件70創(chuàng)建新交談抄本。服務(wù)器以[用戶姓名][即時消息的文字]的形式來對抄本進行添加。然后，將該信息轉(zhuǎn)發(fā)到客戶端B以經(jīng)由客戶端的即時消息接發(fā)軟件10進行顯示。還將相同的信息轉(zhuǎn)發(fā)到客戶端A以經(jīng)由客戶端的即時消息接發(fā)軟件20進行顯示。如果客戶端B的用戶隨后回應(yīng)該消息，則服務(wù)器40根據(jù)上述相同的格式來創(chuàng)建新的一行文字，并且將該文字轉(zhuǎn)發(fā)到客戶端A、B兩者。然后每個客戶端可以使用所接收到的信息以對交談抄本進行添加，并且將此顯示給客戶端的用戶。
在本例中由交談中的每個參與者將交談抄本保留在本地。
在所述的例子中，在關(guān)于即將來臨的會議的對話中涉及A和B。在他們對話中間，在點n，C上線并且A或B邀請C加入他們的對話。
C不知道在被邀請加入A和B的交談之前他們已經(jīng)討論了什么。根據(jù)優(yōu)選實施方式，本發(fā)明提供一種機制，通過該機制將對C加入之前已經(jīng)發(fā)生的對話的摘要提供給C。
參照附圖2a和2b示出了經(jīng)由其產(chǎn)生A和B的交談抄本的摘要的部件和處理。
在步驟100，C的邀請接收器200從當(dāng)前交談參與者之一(例如A或B)接收加入他們的交談的邀請。在步驟110，C的邀請接收器200(使用聯(lián)系詳情部件205)詢問邀請者關(guān)于當(dāng)前交談參與者的聯(lián)系詳情。因為邀請者一直在與其他參與者進行交談，所以他們具有對這些詳情的訪問。邀請者發(fā)送所請求的詳情給C，C使用這些詳情(經(jīng)由抄本尺寸部件210)來請求由每個參與者所保持的交談(相關(guān)抄本的)的行數(shù)(步驟120)。最好接收這種信息作為帶外(out-of-band)控制消息。然后抄本尺寸部件210選擇最完整的抄本，并且請求擁有該抄本的交談參與者將其發(fā)送給C(步驟130)。
注意，可以簡單地將參與者識別符提供給C，并且C可以通過中間消息接發(fā)服務(wù)器40請求交談抄本尺寸，或者可以將完整的聯(lián)系詳情(例如IP地址)提供給C。在后一種情況中，C可以直接聯(lián)系參與者。
如果所有交談參與者都已經(jīng)參與交談了相同的時間，則所有抄本應(yīng)該長度相同。在這種情況中，抄本尺寸部件可以簡單地隨機地或者根據(jù)某些預(yù)定條件(例如，從網(wǎng)絡(luò)距離的角度來說最接近的抄本)來選擇一個交談抄本。
在另一方面，如果一個或者多個參與者半途加入交談，則該參與者的交談抄本將具有不同的長度。
由抄本尺寸部件210在步驟140接收所選擇的交談抄本。
由抄本概括器部件220將所接收的交談抄本作為輸入提供給概括服務(wù)240(步驟150)。可以在橫跨網(wǎng)絡(luò)230的某個位置提供這種概括服務(wù)?；蛘?，可以將這種服務(wù)作為即時消息接發(fā)服務(wù)器的一部分提供，或者在交談參與者之一處提供。
概括軟件最好是諸如IBM的DB2Intelligent MinerTM或者在市場上可獲得的多種其他概括引擎之一之類的非定制(off the shelf)概括引擎。可以在網(wǎng)址itt.nissat.tripod.com/itt0202/ruoi0202.htm上發(fā)現(xiàn)對現(xiàn)存系統(tǒng)的評價。
(DB2和Intelligent Miner是在美國、其他國家或者兩者的國際商用機器公司的商標(biāo))將概括引擎的輸出提供給C。因此C能夠接收對在交談參與者A和B之間之前已經(jīng)發(fā)生的交談的摘要。
如上所述，消息接發(fā)服務(wù)器可以在交談抄本中創(chuàng)建每一行以轉(zhuǎn)發(fā)給交談中的參與者。這樣的交談行通常遵循這樣的格式[用戶姓名][即時消息的文字]。由即時消息接發(fā)服務(wù)器提供給客戶端的用戶名字可以是用戶的電子郵件地址。然后，每個客戶端根據(jù)預(yù)設(shè)的短名來解釋該電子郵件地址。因此交談抄本可能被特別客戶端所使用的名字弄亂。所以，最好在將交談抄本發(fā)送給進行請求的客戶端之前，由擁有交談抄本的即時消息接發(fā)軟件將這樣的綽號轉(zhuǎn)換回完整的識別符。然后，進行請求的客戶端可以以這種形式提交抄本或者使用轉(zhuǎn)換部件(未示出)來將完整的識別符映射到已經(jīng)為交談參與者設(shè)置的綽號。
但是，還非常可能在多方對話中不是所有的對話都與后加入者非常相關(guān)?？赡芤驗樽罱f的某些事情與他們相關(guān)或者需要他們的意見，所以已經(jīng)邀請這樣的用戶加入正在進行的對話。因此，在替代實施方式中，根據(jù)較近的交流比較先的交流具有更少的可舍棄內(nèi)容，將交談抄本的多個部分進行不同程度的概括。
參照圖3a和3b來描述本替代實施方式的處理和部件。
當(dāng)新參與者進入多方對話時，經(jīng)由上述過程(例如使用抄本尺寸部件210)來獲得至今現(xiàn)存的參與者之間的整個對話的抄本(步驟300)。
使用抄本尺寸部件210在步驟310確定在抄本中的行數(shù)?？赡芤呀?jīng)在圖2a的步驟130處接收了該行數(shù)。
由分段器400將抄本分為x個段(步驟S320)。用戶喜好(未示出)指示所期望的段數(shù)，然后分段器使用這些來將所接收到的交談抄本分為適當(dāng)數(shù)量的相等長度的段。例如，如果用戶喜好指示需要四段并且確定在該交談抄本中有十五行，則產(chǎn)生具有四行的三個相等的段和包含剩余的三行的第四段。注意，用戶喜好可能指示所期望的段數(shù)依賴于在交談抄本中的行數(shù)。例如，對于少于50行的抄本執(zhí)行“a”，而對于多于50行的那些執(zhí)行“b”。
在另一種實施方式中，用戶可以不指定分段喜好。而可以將所使用的段數(shù)硬編碼(hard-code)為即時消息接發(fā)應(yīng)用程序。
分段器400為每個分段分配識別符(例如，數(shù)字識別符)，從而給出段的順序。
對于每個段，使用規(guī)則訪問器420來訪問概括規(guī)則410。概括規(guī)則指示所需要的概括等級(步驟330)。例如，具有標(biāo)識符1的段可能需要70％的概括。而具有識別符5的段可能需要5％的概括。這后面的原因就是較早的段可能比較新的段包含較少的相關(guān)信息，從而可以壓縮得更多。
抄本概括器部件220輸入每個段到概括服務(wù)240并且指示所需要的概括等級(步驟340)。注意，當(dāng)前的概括軟件已經(jīng)能夠?qū)⑽淖指爬ǖ讲煌牡燃墶＠?，Sinope的概括器工具允許用戶指定所需要的概括的長度。網(wǎng)址www.sinope.info/en/info/25/解釋了用戶可以通過拖動滑動條來選擇概括長度。在本發(fā)明的實施方式中，使用自動的代理來選擇適當(dāng)?shù)幕瑒訔l位置并且輸入文字到概括軟件。
對于某些段，根本就不需要概括。在這樣的情況中，不將這樣的段提供給服務(wù)但是將它們保留在客戶端處。
概括器部件220在步驟S350接收關(guān)于每個段的概括的輸出。然后段合并器部件430將所有的x個段再次合并回到一起，并且將所概括的輸出呈現(xiàn)給客戶端C的用戶(步驟360)。合并器部件最好將輸出適當(dāng)?shù)剡M行格式化。例如，可以將指示概括等級、發(fā)送消息的時間幀等的頭部給予每個段。
雖然在上述實施方式中，根據(jù)交談抄本中的行數(shù)來產(chǎn)生段，但是本發(fā)明并不限于此。在另一種實施方式中，對不同發(fā)言(contribution)的時間標(biāo)記進行分析并且創(chuàng)建對話的時間安排(timeline)。然后，將這種時間安排分為幾個部分(例如，四個)，表示討論的不同“階段”。
在本實施方式中，在將每個消息發(fā)送到參與的客戶端之前由即時消息服務(wù)器40將其進行時間標(biāo)記。使用服務(wù)器的時鐘對即時消息進行時間標(biāo)記，確保所有消息的時間標(biāo)記都同步并且不存在分布的時鐘不符合性。提供規(guī)則來確定在分割對話時如何使用時間標(biāo)記。例如，如果對話已經(jīng)持續(xù)了30分鐘，則可以將對話分割為10分鐘的段。
還可以使用其他更加先進的方法將對話更加準(zhǔn)確的分割為“早期”、“中期”、“后期”等階段。例如，可以對不同人的發(fā)言數(shù)量進行分析以搜集關(guān)于對話結(jié)構(gòu)的進一步情況。作為“Jabber”(不是相同名字的更加新近的即時消息系統(tǒng))項目的一部分，多倫多大學(xué)在該領(lǐng)域已經(jīng)進行了工作。該工作涉及對研討會、多方電話、討論等的存檔抄本進行分析以添加描述元數(shù)據(jù)到其中，從而使得識別抄本的感興趣部分成為可能。例如，對涉及的人數(shù)和交互速度(速度可能指示爭論(argument))進行分析。該工作還涉及使用對話類型來確定對話結(jié)構(gòu)。例如，在多方電話中，前序部分通常涉及各方自我介紹，所以當(dāng)對電話內(nèi)容進行概括時對前序部分的興趣小于對電話的結(jié)束部分。
在本發(fā)明的實施方式中，還可以根據(jù)對話結(jié)構(gòu)來確定階段數(shù)量。在該例子實施方式中，認為四個到六個階段就足夠了。
不論使用任何方法，不同程度地概括即時消息接發(fā)對話的這種機制允許新參與者能夠快速地跟上之前已經(jīng)進行的對話的速度，而且?guī)椭麄兺耆貐⑴c到在討論中最近已經(jīng)發(fā)生的事情中來。
最好使用其標(biāo)準(zhǔn)API，將隨后的概括經(jīng)由正在使用的合作工具(例如，即時消息)發(fā)送給新參與者。最好將趕上(catch-up)文字呈現(xiàn)在新參與者的屏幕上的新窗口中，或者在他們要加入的對話中作為頭幾行出現(xiàn)。
上述討論對于即時消息接發(fā)對話的新加入者或者也許已經(jīng)被臨時斷開的參與者都特別相關(guān)。但是，已經(jīng)參與即時消息接發(fā)對話的客戶端不一定想要看見對于之前討論的摘要(除非特別請求)。因此提供一種機制，其中根據(jù)他們最后參與討論的時間來將摘要提供給用戶。例如，如果他們在最后5分鐘內(nèi)或者最后5次交互中發(fā)了言，則不需要概括。但是如果用戶已經(jīng)離開了較長時間，則概括可能確實非常有用。用戶最好可以配置在參與者會自動地接收新摘要之前所應(yīng)該經(jīng)過的交互次數(shù)或者時間。無論用戶的即時消息接發(fā)客戶端是否在整個參與期間保持連接到討論，最好都可以應(yīng)用這些選擇。
將參照圖4a和4b來討論本發(fā)明的實施方式的過程和部件。
在步驟500，C的即時消息接發(fā)軟件接收關(guān)于C想要參與即時消息接發(fā)對話的指示(參與部件600)?？梢越?jīng)由相關(guān)的交談窗口獲得對這種指示的關(guān)注。但是在某些實施方式中，用戶的交談窗口可以保持受到關(guān)注同時他們參加會議或者以其他方式變得注意力分散。因此可能需要用戶主動指定他們現(xiàn)在想要參與對話。例如，可以將按鈕呈現(xiàn)給用戶以選擇他們何時想要參與。
一旦接收到了指示，則在步驟510確定從用戶最后參與對話所經(jīng)過的時間(時間部件610)。其最好是從用戶最后發(fā)送被監(jiān)測到并且在該點被使用的消息所經(jīng)過的時間。
如果所經(jīng)過的時間少于“y”秒(即，用戶相對新近參與過)，則用戶正常地參與對話(步驟520、530)。如果在另一方面已經(jīng)經(jīng)過了多于“y”秒，則由抄本概括器部件220來請求和接收(步驟520、540)完整的交談抄本。
由抄本概括器部件220將抄本輸入到概括引擎并且從其接收概括以呈現(xiàn)給用戶(步驟550、560)。
用戶最好能夠配置什么時候需要摘要(即，“y”)。將這種信息作為用戶喜好620存儲。
再次，用戶可能不想要全部交談抄本的完整摘要。相反地，如上所述，概括等級可能變化。
如上所述，概括軟件可以位于許多位置的任何一個處。其可能形成即時消息軟件自己的一部分，其可以是在橫跨網(wǎng)絡(luò)的某處的獨立的服務(wù)，其可以形成即時消息接發(fā)服務(wù)器的部分或者與服務(wù)器布置在一起。由于概括軟件可能消耗大量的存儲空間和處理能力，所以最好將其提供為獨立的服務(wù)。
如上所述，對于概括處理最好使用非現(xiàn)貨概括引擎。對于不能處理由即時消息服務(wù)所提供的對話類型的任何這種軟件，可以使用參照共同未決的美國專利申請?zhí)?0/660063(內(nèi)部檔號GB92002082)所描述的技術(shù)。該專利申請描述了一種機制，通過該機制可以將上下文添加到交談抄本以指示其中一個用戶傳遞信息給另一個用戶的方式(情緒)。因此將關(guān)于其中敘說某些事情的方式的信息添加到即時消息抄本(憤怒、大聲地等)。然后可以進一步地操控即時消息抄本以形成連續(xù)文字并且去除任何識別符/綽號信息。還可以提供規(guī)則來添加適當(dāng)?shù)臉?biāo)點并且適當(dāng)?shù)亟忉尪绦问降脑~語(例如，u-＞you，r-＞are等)。因此下面LucasWhen have you scheduled that meeting for？BharatOh gosh I had forgotten all about it！LucasNever mind-)BharatRight，lets meet at 2pm.
LucasIn the conference roomBharaGood idea.
LucasSee you then.
BharatBye.
可能變成Lucas問“When have you scheduled that meeting for？”。Bharat嚷到“Ohgosh I had forgotten all about it！”。Lucas笑著說“Never mind”。Bharat說“Right，lets meet at 2pm”。Bharat同意“Good idea”。Lucas說“See you then”。Bharat說“Bye”。
可以提供概括服務(wù)中所使用的任何規(guī)則作為即時消息軟件的一部分，或者有即時消息接發(fā)服務(wù)器或者概括服務(wù)來提供它們。然后可以由即時消息接發(fā)客戶端請求這些規(guī)則。
任何交談抄本的分段都不是必須通過即時消息接發(fā)客戶端來進行，而是相反地可以通過概括服務(wù)(由插件)或者通過即時消息接發(fā)服務(wù)器自己來執(zhí)行。
雖然已經(jīng)從每個即時消息客戶端處所存儲的交談抄本的角度描述了本發(fā)明，但是并不必須是這樣。還可以將抄本存儲在即時消息接發(fā)服務(wù)器處。但是，為了升級的原因較不推薦這種方案。
最后，雖然已經(jīng)從即時消息接發(fā)的角度描述了本發(fā)明，但是本發(fā)明并不限于此?？梢詫⒈景l(fā)明等同地應(yīng)用于諸如電子郵件、博客等之類的文檔、或者諸如線程化的新聞組或者wikis之類的文檔結(jié)構(gòu)。
例如，可以使用本發(fā)明根據(jù)最后打開電子郵件的時間來概括電子郵件。是否概括電子郵件還可以依賴于其長度。對于文字處理文檔也是如此?？梢钥紤]在wiki文檔結(jié)構(gòu)中的文檔數(shù)量，或者在wiki結(jié)構(gòu)中的具體文檔的長度。因此根據(jù)文檔最后被打開的時間以及其長度來將概括呈現(xiàn)給用戶。例如，可以概括500個詞以上的文檔，而將不概括較小的文檔。利用wiki，可以將時間標(biāo)記過的cookie存儲在用戶的計算機上并且用于確定用戶最后訪問wiki的時間?？梢愿鶕?jù)用戶最后訪問新聞組的時間來概括新聞組討論。例如，用戶可以為進行概括而選擇新聞組內(nèi)的特定線程化的討論。然后使用代理從每個新聞組文章中提取文字，并且在提交文字用于進行概括之前對文字進行格式化(例如指示該文章來自誰)。還可以考慮從用戶最后與文檔結(jié)構(gòu)交互起新文章的數(shù)量。
而且可以將文檔的不同部分根據(jù)文字出現(xiàn)的位置而進行不同程度的概括。這可以是基于句子的總數(shù)或者期間添加文字的時間段。在線程化的新聞組討論中，可以根據(jù)特別的回應(yīng)深入到該討論中的程度來對該討論進行不同的概括。在隨機添加文檔和文檔結(jié)構(gòu)的情況中，改變概括的程度特別有用。換句話說，其中將新情況添加到文檔或者結(jié)構(gòu)的末尾的文檔/文檔結(jié)構(gòu)。例如，這對于包括巨大數(shù)量的引導(dǎo)至事件的最新近狀態(tài)的歷史文字(以前的電子郵件)的電子郵件非常有用。
應(yīng)該理解所述的各種實施方式可以彼此結(jié)合使用。
權(quán)利要求
1.一種用于實現(xiàn)文字概括的方法，包括根據(jù)文字在文檔內(nèi)相對于其他文字的位置或者在文檔結(jié)構(gòu)中的多個文檔內(nèi)包含該文字的文檔的位置，來請求對文檔中該文字的概括。
2.根據(jù)權(quán)利要求1所述的方法，其中，應(yīng)用程序是即時消息接發(fā)應(yīng)用程序，而文檔是即時消息接發(fā)對話抄本。
3.根據(jù)權(quán)利要求2所述的方法，其中，在與即時消息對話抄本關(guān)聯(lián)的即時消息接發(fā)對話中存在多個參與者，而且每個參與者具有對話抄本的版本，根據(jù)該文字在即時消息抄本內(nèi)相對于其他文字的位置在文檔中概括該文字的步驟包括請求對話抄本的版本。
4.根據(jù)權(quán)利要求3所述的方法，其中，根據(jù)文字在即時消息抄本內(nèi)相對于其他文字的位置在文檔中概括該文字的步驟包括如果給出了文字在文檔中的位置，則訪問指示用于請求的概括等級的規(guī)則。
5.根據(jù)權(quán)利要求4所述的方法，其中，在文檔中較后出現(xiàn)的文字與在文檔中較早出現(xiàn)的文字相比需要較低程度的概括。
6.根據(jù)權(quán)利要求3、4或者5所述的方法包括將即時消息對話抄本分段；和在每個段內(nèi)請求文字概括的不同等級。
7.根據(jù)權(quán)利要求6所述的方法，包括根據(jù)抄本中的行數(shù)來將即時消息對話抄本分段。
8.根據(jù)權(quán)利要求7所述的方法，包括根據(jù)其間創(chuàng)建抄本的時間段來對即時消息對話抄本分段。
9.根據(jù)權(quán)利要求6、7、或者8所述的方法，包括使用用戶喜好來確定如何對即時消息對話抄本進行分段。
10.根據(jù)權(quán)利要求6到9中的任何一項所述的方法，包括接收概括的交談抄本段；和將分段合并到一起以顯示給用戶。
11.根據(jù)權(quán)利要求10所述的方法，其中將分段合并到一起的步驟包括對段進行格式化以指示用于每個段的概括等級。
12.一種用于實現(xiàn)文字概括的方法，包括結(jié)合文檔的版本或者包括該文檔的文檔結(jié)構(gòu)根據(jù)用戶與應(yīng)用程序的交互，請求在該文檔中對文字的概括。
13.根據(jù)權(quán)利要求12所述的方法，其中應(yīng)用程序是即時消息接發(fā)應(yīng)用程序，而文檔是即時消息接發(fā)對話抄本。
14.根據(jù)權(quán)利要求12或者13所述的方法，其中結(jié)合文檔的版本根據(jù)用戶與應(yīng)用程序的交互來請求對文檔中的文字進行概括的步驟包括根據(jù)在由用戶所發(fā)送的最后消息和用戶希望發(fā)送另一個即時消息以在對話中發(fā)言并因此修改抄本的指示之間的即時消息接發(fā)對話抄本所關(guān)聯(lián)的即時消息接發(fā)對話中由其他參與者所發(fā)送的即時消息的數(shù)量，作出是否請求文字概括的決定。
15.根據(jù)權(quán)利要求14的方法，包括接收用戶想要發(fā)送即時消息的指示。
16.根據(jù)權(quán)利要求12所述的方法，其中，結(jié)合文檔的版本或者包括該文檔的文檔結(jié)構(gòu)根據(jù)用戶與應(yīng)用程序的交互來請求對文檔中的文字進行概括的步驟包括根據(jù)用戶最后訪問文檔的版本或者文檔結(jié)構(gòu)的時間來確定是否請求概括。
17.根據(jù)權(quán)利要求16所述的方法，包括使用文檔的長度來確定是否請求概括。
18.根據(jù)權(quán)利要求16所述的方法，包括使用與在用戶最后與文檔結(jié)構(gòu)交互時所存在的文檔數(shù)量相對的文檔結(jié)構(gòu)中的文檔數(shù)量來確定是否請求概括。
19.一種用于實現(xiàn)文字概括的設(shè)備，包括用于根據(jù)文字在文檔內(nèi)相對于其他文字的位置，或者根據(jù)在文檔結(jié)構(gòu)中的多個文檔內(nèi)包含該文字的文檔的位置，請求概括該文檔中的文字的裝置。
20.根據(jù)權(quán)利要求19所述的設(shè)備，其中應(yīng)用程序是即時消息接發(fā)應(yīng)用程序，而文檔是即時消息接發(fā)對話抄本。
21.根據(jù)權(quán)利要求20所述的設(shè)備，其中，在與即時消息接發(fā)對話抄本關(guān)聯(lián)的即時消息接發(fā)對話中存在多個參與者，而且每個參與者具有對話抄本的版本，其中用于根據(jù)文字在即時消息抄本內(nèi)相對于其他文字的位置在文檔中概括該文字的裝置包括用于請求對話抄本的版本的裝置。
22.根據(jù)權(quán)利要求21所述的設(shè)備，其中根據(jù)文字在即時消息抄本內(nèi)相對于其他文字的位置在文檔中概括該文字的裝置包括用于在給出了文檔中的文字位置的情況下訪問指示用于請求的概括等級的規(guī)則的裝置。
23.根據(jù)權(quán)利要求22所述的設(shè)備，其中在文檔中較后出現(xiàn)的文字與在文檔中較早出現(xiàn)的文字相比需要較低程度的概括。
24.根據(jù)權(quán)利要求21、22或者23所述的設(shè)備包括用于將即時消息接發(fā)對話抄本分段的裝置；和用于在請求每個段內(nèi)的文字概括的不同等級的裝置。
25.根據(jù)權(quán)利要求24所述的設(shè)備包括用于根據(jù)抄本中的行數(shù)來將即時消息對話抄本分段的裝置。
26.根據(jù)權(quán)利要求25所述的設(shè)備包括用于根據(jù)其間創(chuàng)建抄本的時間段來對即時消息對話抄本分段的裝置。
27.根據(jù)權(quán)利要求24、25或者26所述的設(shè)備包括用于使用用戶喜好來確定如何對即時消息對話抄本進行分段的裝置。
28.根據(jù)權(quán)利要求24到27中的任何一項所述的設(shè)備，包括用于接收經(jīng)概括的交談抄本段的裝置；和用于將各分段合并到一起以顯示給用戶的裝置。
29.根據(jù)權(quán)利要求28所述的設(shè)備，其中，用于將各分段合并到一起的裝置包括用于對段進行格式化以指示用于每個段的概括等級的裝置。
30.一種用于實現(xiàn)文字概括的設(shè)備，包括用于結(jié)合文檔的版本或者包括該文檔的文檔結(jié)構(gòu)根據(jù)用戶與應(yīng)用程序的交互，請求在該文檔中對文字的概括的裝置。
31.根據(jù)權(quán)利要求30所述的裝置，其中應(yīng)用程序是即時消息接發(fā)應(yīng)用程序，而文檔是即時消息對話抄本。
32.根據(jù)權(quán)利要求30或者31所述的設(shè)備，其中用于結(jié)合文檔的版本根據(jù)用戶與應(yīng)用程序的交互來請求對文檔中的文字進行概括的裝置包括用于根據(jù)在由用戶所發(fā)送的最后消息和用戶希望發(fā)送另一個即時消息以在對話中發(fā)言并因此修改抄本的指示之間的即時消息接發(fā)對話抄本所關(guān)聯(lián)的即時消息接發(fā)對話中，由其他參與者所發(fā)送的即時消息的數(shù)量，作出是否請求文字概括的決定的裝置。
33.根據(jù)權(quán)利要求32的設(shè)備，包括用于接收用戶想要發(fā)送即時消息的指示的裝置。
34.根據(jù)權(quán)利要求30所述的設(shè)備，其中用于結(jié)合文檔的版本或者包括該文檔的文檔結(jié)構(gòu)根據(jù)用戶與應(yīng)用程序的交互來請求對文檔中的文字進行概括的裝置包括用于根據(jù)用戶最后訪問文檔的版本或者文檔結(jié)構(gòu)來確定是否請求概括的裝置。
35.根據(jù)權(quán)利要求34所述的設(shè)備，包括用于使用文檔的長度來確定是否請求概括的裝置。
36.根據(jù)權(quán)利要求34所述的設(shè)備，包括用于使用在用戶最后與該文檔結(jié)構(gòu)交互時所存在的文檔數(shù)量相對的文檔結(jié)構(gòu)中的文檔數(shù)量來確定是否請求概括的裝置。
全文摘要
公開了用于實現(xiàn)文字概括的方法和設(shè)備?？梢愿鶕?jù)文字在文檔內(nèi)相對于其他文字的位置或者根據(jù)在文檔結(jié)構(gòu)中的多個文檔內(nèi)包含文字的文檔的位置，來請求對文檔中的文字進行概括。還可以結(jié)合文檔的版本或者結(jié)合包括該文檔的文檔結(jié)構(gòu)根據(jù)用戶與應(yīng)用程序的交互來請求對文檔中的文字的概括。
文檔編號H04L12/58GK1971551SQ20061012166
公開日2007年5月30日 申請日期2006年8月28日 優(yōu)先權(quán)日2005年11月24日
發(fā)明者盧卡斯·W·帕特里奇, 馬丁·J·蓋爾, 馬克·S·卡特, 安德魯·J·斯坦福-克拉克, 巴拉特·V·貝迪 申請人:國際商業(yè)機器公司