用于实现文字概括的方法和设备的制作方法

专利名称：用于实现文字概括的方法和设备的制作方法
技术领域：
本发明涉及文字的概括。
背景技术：
存在有使用计算机的两种主要的人对人通讯电子邮件和各种形式的实时交谈(例如使用IBM公司提供的LotusSametime)。实时交谈系统允许人们彼此输入消息，并且这些允许消息几乎立即出现在接收者的显示屏幕上。这种系统允许比经由电子邮件所可能发生的交互和讨论更加自然的交互和讨论。(IBM、Lotus和Sametime是在美国、或者其他国家或者两者的国际商用机器公司的商标)。
当用户打字时，他们的交谈系统产生“交谈抄本(transcript)”显示每个用户说的是什么。格式通常是“姓名言语”(例如，尼科你什么时候吃午饭？)通常，将交谈抄本保留在正在参与交谈的每个客户的本地。每个参与者的交谈抄本通常从参与者开始加入交谈的时候以后以及仅仅当该参与者与他们正在运行的即时消息接发软件连接的时候才显示交谈对话。所以除非当前的参与者解释之前的情况，否则交谈的新参与者、或者临时断开的参与者在他们离线的时候可能错过基于即时消息接发的小组讨论。
人们已经知道用于概括信息的技术。例如，可以在下面网址找到对现存概括工具的评论itt.nissat.tripod.com/itt0202/ruoi0202.htm。此外，美国专利6,101,532示教了对线程化(threaded)讨论的概括。而且，美国专利公开2004/0122657公开了一种用于基于交互话题概括的技术，其中基于从例如一篇文字的句子位置得来的关联高分(high score)在基于话题的概括中对于结论选择句子。
但是，在业界需要用于概括文字的改进的技术。

发明内容
根据一个方面，提供一种用于实现文字概括的方法，包括根据文字在文档内相对于其他文字的位置或者在一种文档结构中的多个文档内包含该文字的文档的位置，来请求对文档中该文字的概括。
根据另一个方面，提供一种用于实现文字概括的方法，包括结合文档的版本或者包括该文档的文档结构根据用户与应用程序的交互，请求在该文档中对文字的概括。
当然，对概括的请求可以是远程服务或者可以对请求者是本地的(例如在相同的机器上)。
在一个实施方式中，应用程序是即时消息接发应用程序，而文档是即时消息接发对话抄本。当然，上述情形仅仅是示例的形式。可以将本发明应用于诸如电子邮件的文档、文字处理文档和博客文档、以及诸如新闻组讨论和wikis之类的文档结构。
在一个实施方式中，在与即时消息接发对话抄本关联的即时消息接发对话中存在多个参与者，而且每个参与者具有对话抄本的版本。为了概括文字，最好请求对话抄本的版本(例如，最完整的版本)。
如果给出了文档中的文字位置，则可以使用规则来指示用于请求的概括等级。
最好在文档中较后出现的文字与在文档中较早出现的文字相比需要较少程度的概括。
在一个实施方式中，将即时消息接发对话抄本分段。然后最好请求每个段内的文字概括的不同等级。
分段可以基于抄本中的行数。或者，可以使用在期间产生抄本的时间段。可以使用用户偏好来确定如何对即时消息接发对话抄本进行分段。
当接收到概括的交谈抄本段时，最好将它们合并在一起显示给用户。这种合并涉及对段进行格式化以指示用于每个段的概括等级。
在一个实施方式中，结合文档的版本或者结合文档结构根据从用户与应用程序的最后交互所经过的时间，来确定是否请求对文字的概括。
在即时消息接发情形中，可以存在几个版本的文档(交谈抄本)，并且每个用户经由他们的本地应用程序来访问他们文档的版本。
在一个实施方式中，根据在由用户所发送的最后消息和用户希望发送另一个即时消息以参与对话并因此修改抄本的指示之间的即时消息接发对话抄本所关联的即时消息接发对话中，由其他参与者所发送的即时消息的数量，作出是否请求文字概括的决定。
注意，用户与即时消息接发对话抄本的交互可以不是直接的交互。例如，消息的发送可能导致与潜在消息抄本的交互。还要注意，用户的交互历史可能为空-换句话说，他们对于即时消息对话是新来的，之前没有打开过文字处理文档或者查看过特别的新闻组等。
最好，在即时消息接发情形中，接收关于用户希望发送即时消息的指示。
在一个实施方式中，根据用户最后访问文档或者文档结构的时间来确定是否请求概括。可以使用文档的长度。在另一个实施方式中，可以使用当用户最后与文档结构进行交互时所相关的文档结构中的文档数量来确定是否请求概括。
根据另一个方面，提供一种用于实现文字概括的设备，包括用于根据文字在文档内相对于其他文字的位置，或者根据在文档结构中的多个文档内包含该文字的文档的位置，请求概括该文档中的文字的装置。
根据另一个方面，提供一种用于实现文字概括的设备，包括用于结合文档的版本或者结合包括该文档的文档结构，根据用户与应用程序的交互来请求概括该文档中的文字的装置。
可以用计算机软件来实现本发明。


将参照附图仅仅通过例子来描述本发明的优选实施方式图1示出了如何实施这种消息接发系统；图2a和2b示出了根据本发明的优选实施方式的通过其创建即时消息接发抄本的概括的处理和部件；图3a和3b示出了根据本发明的优选实施方式的可以通过其将交谈抄本进行分段并且进行不同程度概括的处理和部件；和图4a和4b示出了根据本发明的优选实施方式的，可以通过其根据参与者最后参与即时消息接发对话的时间将摘要提供给即时消息接发参与者的处理和部件。
具体实施例方式
能够以各种不同的方式来实施即时消息接发。用户通常具有“朋友”列表，他们与这些朋友经常通讯。例如使用即时消息程序ICQ，用户联系ICQ服务器，从而该服务器可以确定用户的那些朋友在线。然后，ICQ服务器将关于用户的在线朋友的必要联系详情发送给用户，而且确保其他用户可以看见该用户。随后，在用户和其他人之间发生直接的通讯。服务器不需要介入实际的对话。仅仅当用户终止他们的会话时，他们的机器才通知ICQ服务器，从而其可以将用户的状态改为“离线”。
诸如微软即时消息者之类的其他消息接发系统使用中间服务器以将每个消息转发到所期望的接收者。图1示出了如何实现这种消息接发系统的例子。
客户端A和B同时运行即时消息接发软件10、20。如果客户端A的用户想要与客户端B的用户进行实时通讯，则客户端A发送即时消息给中央即时消息接发服务器40。即时消息包含发送者和接收者识别信息，而服务器40使用用户查询部件50来访问已知用户列表55，以确定该消息的发送者对于服务器来说是否是已知的。(注意在实际使用即时消息接发软件之前用户通常经由用户注册部件60与服务器进行注册。)假设用户对于服务器40已经是已知的，并且还使用用户查询部件50和用户列表55来确定消息的接收者对于服务器来说是否是已知的。而且假设该接收者是已知的，交谈抄本创建部件70创建新交谈抄本。服务器以[用户姓名][即时消息的文字]的形式来对抄本进行添加。然后，将该信息转发到客户端B以经由客户端的即时消息接发软件10进行显示。还将相同的信息转发到客户端A以经由客户端的即时消息接发软件20进行显示。如果客户端B的用户随后回应该消息，则服务器40根据上述相同的格式来创建新的一行文字，并且将该文字转发到客户端A、B两者。然后每个客户端可以使用所接收到的信息以对交谈抄本进行添加，并且将此显示给客户端的用户。
在本例中由交谈中的每个参与者将交谈抄本保留在本地。
在所述的例子中，在关于即将来临的会议的对话中涉及A和B。在他们对话中间，在点n，C上线并且A或B邀请C加入他们的对话。
C不知道在被邀请加入A和B的交谈之前他们已经讨论了什么。根据优选实施方式，本发明提供一种机制，通过该机制将对C加入之前已经发生的对话的摘要提供给C。
参照附图2a和2b示出了经由其产生A和B的交谈抄本的摘要的部件和处理。
在步骤100，C的邀请接收器200从当前交谈参与者之一(例如A或B)接收加入他们的交谈的邀请。在步骤110，C的邀请接收器200(使用联系详情部件205)询问邀请者关于当前交谈参与者的联系详情。因为邀请者一直在与其他参与者进行交谈，所以他们具有对这些详情的访问。邀请者发送所请求的详情给C，C使用这些详情(经由抄本尺寸部件210)来请求由每个参与者所保持的交谈(相关抄本的)的行数(步骤120)。最好接收这种信息作为带外(out-of-band)控制消息。然后抄本尺寸部件210选择最完整的抄本，并且请求拥有该抄本的交谈参与者将其发送给C(步骤130)。
注意，可以简单地将参与者识别符提供给C，并且C可以通过中间消息接发服务器40请求交谈抄本尺寸，或者可以将完整的联系详情(例如IP地址)提供给C。在后一种情况中，C可以直接联系参与者。
如果所有交谈参与者都已经参与交谈了相同的时间，则所有抄本应该长度相同。在这种情况中，抄本尺寸部件可以简单地随机地或者根据某些预定条件(例如，从网络距离的角度来说最接近的抄本)来选择一个交谈抄本。
在另一方面，如果一个或者多个参与者半途加入交谈，则该参与者的交谈抄本将具有不同的长度。
由抄本尺寸部件210在步骤140接收所选择的交谈抄本。
由抄本概括器部件220将所接收的交谈抄本作为输入提供给概括服务240(步骤150)。可以在横跨网络230的某个位置提供这种概括服务。或者，可以将这种服务作为即时消息接发服务器的一部分提供，或者在交谈参与者之一处提供。
概括软件最好是诸如IBM的DB2Intelligent MinerTM或者在市场上可获得的多种其他概括引擎之一之类的非定制(off the shelf)概括引擎。可以在网址itt.nissat.tripod.com/itt0202/ruoi0202.htm上发现对现存系统的评价。
(DB2和Intelligent Miner是在美国、其他国家或者两者的国际商用机器公司的商标)将概括引擎的输出提供给C。因此C能够接收对在交谈参与者A和B之间之前已经发生的交谈的摘要。
如上所述，消息接发服务器可以在交谈抄本中创建每一行以转发给交谈中的参与者。这样的交谈行通常遵循这样的格式[用户姓名][即时消息的文字]。由即时消息接发服务器提供给客户端的用户名字可以是用户的电子邮件地址。然后，每个客户端根据预设的短名来解释该电子邮件地址。因此交谈抄本可能被特别客户端所使用的名字弄乱。所以，最好在将交谈抄本发送给进行请求的客户端之前，由拥有交谈抄本的即时消息接发软件将这样的绰号转换回完整的识别符。然后，进行请求的客户端可以以这种形式提交抄本或者使用转换部件(未示出)来将完整的识别符映射到已经为交谈参与者设置的绰号。
但是，还非常可能在多方对话中不是所有的对话都与后加入者非常相关。可能因为最近所说的某些事情与他们相关或者需要他们的意见，所以已经邀请这样的用户加入正在进行的对话。因此，在替代实施方式中，根据较近的交流比较先的交流具有更少的可舍弃内容，将交谈抄本的多个部分进行不同程度的概括。
参照图3a和3b来描述本替代实施方式的处理和部件。
当新参与者进入多方对话时，经由上述过程(例如使用抄本尺寸部件210)来获得至今现存的参与者之间的整个对话的抄本(步骤300)。
使用抄本尺寸部件210在步骤310确定在抄本中的行数。可能已经在图2a的步骤130处接收了该行数。
由分段器400将抄本分为x个段(步骤S320)。用户喜好(未示出)指示所期望的段数，然后分段器使用这些来将所接收到的交谈抄本分为适当数量的相等长度的段。例如，如果用户喜好指示需要四段并且确定在该交谈抄本中有十五行，则产生具有四行的三个相等的段和包含剩余的三行的第四段。注意，用户喜好可能指示所期望的段数依赖于在交谈抄本中的行数。例如，对于少于50行的抄本执行“a”，而对于多于50行的那些执行“b”。
在另一种实施方式中，用户可以不指定分段喜好。而可以将所使用的段数硬编码(hard-code)为即时消息接发应用程序。
分段器400为每个分段分配识别符(例如，数字识别符)，从而给出段的顺序。
对于每个段，使用规则访问器420来访问概括规则410。概括规则指示所需要的概括等级(步骤330)。例如，具有标识符1的段可能需要70％的概括。而具有识别符5的段可能需要5％的概括。这后面的原因就是较早的段可能比较新的段包含较少的相关信息，从而可以压缩得更多。
抄本概括器部件220输入每个段到概括服务240并且指示所需要的概括等级(步骤340)。注意，当前的概括软件已经能够将文字概括到不同的等级。例如，Sinope的概括器工具允许用户指定所需要的概括的长度。网址www.sinope.info/en/info/25/解释了用户可以通过拖动滑动条来选择概括长度。在本发明的实施方式中，使用自动的代理来选择适当的滑动条位置并且输入文字到概括软件。
对于某些段，根本就不需要概括。在这样的情况中，不将这样的段提供给服务但是将它们保留在客户端处。
概括器部件220在步骤S350接收关于每个段的概括的输出。然后段合并器部件430将所有的x个段再次合并回到一起，并且将所概括的输出呈现给客户端C的用户(步骤360)。合并器部件最好将输出适当地进行格式化。例如，可以将指示概括等级、发送消息的时间帧等的头部给予每个段。
虽然在上述实施方式中，根据交谈抄本中的行数来产生段，但是本发明并不限于此。在另一种实施方式中，对不同发言(contribution)的时间标记进行分析并且创建对话的时间安排(timeline)。然后，将这种时间安排分为几个部分(例如，四个)，表示讨论的不同“阶段”。
在本实施方式中，在将每个消息发送到参与的客户端之前由即时消息服务器40将其进行时间标记。使用服务器的时钟对即时消息进行时间标记，确保所有消息的时间标记都同步并且不存在分布的时钟不符合性。提供规则来确定在分割对话时如何使用时间标记。例如，如果对话已经持续了30分钟，则可以将对话分割为10分钟的段。
还可以使用其他更加先进的方法将对话更加准确的分割为“早期”、“中期”、“后期”等阶段。例如，可以对不同人的发言数量进行分析以搜集关于对话结构的进一步情况。作为“Jabber”(不是相同名字的更加新近的即时消息系统)项目的一部分，多伦多大学在该领域已经进行了工作。该工作涉及对研讨会、多方电话、讨论等的存档抄本进行分析以添加描述元数据到其中，从而使得识别抄本的感兴趣部分成为可能。例如，对涉及的人数和交互速度(速度可能指示争论(argument))进行分析。该工作还涉及使用对话类型来确定对话结构。例如，在多方电话中，前序部分通常涉及各方自我介绍，所以当对电话内容进行概括时对前序部分的兴趣小于对电话的结束部分。
在本发明的实施方式中，还可以根据对话结构来确定阶段数量。在该例子实施方式中，认为四个到六个阶段就足够了。
不论使用任何方法，不同程度地概括即时消息接发对话的这种机制允许新参与者能够快速地跟上之前已经进行的对话的速度，而且帮助他们完全地参与到在讨论中最近已经发生的事情中来。
最好使用其标准API，将随后的概括经由正在使用的合作工具(例如，即时消息)发送给新参与者。最好将赶上(catch-up)文字呈现在新参与者的屏幕上的新窗口中，或者在他们要加入的对话中作为头几行出现。
上述讨论对于即时消息接发对话的新加入者或者也许已经被临时断开的参与者都特别相关。但是，已经参与即时消息接发对话的客户端不一定想要看见对于之前讨论的摘要(除非特别请求)。因此提供一种机制，其中根据他们最后参与讨论的时间来将摘要提供给用户。例如，如果他们在最后5分钟内或者最后5次交互中发了言，则不需要概括。但是如果用户已经离开了较长时间，则概括可能确实非常有用。用户最好可以配置在参与者会自动地接收新摘要之前所应该经过的交互次数或者时间。无论用户的即时消息接发客户端是否在整个参与期间保持连接到讨论，最好都可以应用这些选择。
将参照图4a和4b来讨论本发明的实施方式的过程和部件。
在步骤500，C的即时消息接发软件接收关于C想要参与即时消息接发对话的指示(参与部件600)。可以经由相关的交谈窗口获得对这种指示的关注。但是在某些实施方式中，用户的交谈窗口可以保持受到关注同时他们参加会议或者以其他方式变得注意力分散。因此可能需要用户主动指定他们现在想要参与对话。例如，可以将按钮呈现给用户以选择他们何时想要参与。
一旦接收到了指示，则在步骤510确定从用户最后参与对话所经过的时间(时间部件610)。其最好是从用户最后发送被监测到并且在该点被使用的消息所经过的时间。
如果所经过的时间少于“y”秒(即，用户相对新近参与过)，则用户正常地参与对话(步骤520、530)。如果在另一方面已经经过了多于“y”秒，则由抄本概括器部件220来请求和接收(步骤520、540)完整的交谈抄本。
由抄本概括器部件220将抄本输入到概括引擎并且从其接收概括以呈现给用户(步骤550、560)。
用户最好能够配置什么时候需要摘要(即，“y”)。将这种信息作为用户喜好620存储。
再次，用户可能不想要全部交谈抄本的完整摘要。相反地，如上所述，概括等级可能变化。
如上所述，概括软件可以位于许多位置的任何一个处。其可能形成即时消息软件自己的一部分，其可以是在横跨网络的某处的独立的服务，其可以形成即时消息接发服务器的部分或者与服务器布置在一起。由于概括软件可能消耗大量的存储空间和处理能力，所以最好将其提供为独立的服务。
如上所述，对于概括处理最好使用非现货概括引擎。对于不能处理由即时消息服务所提供的对话类型的任何这种软件，可以使用参照共同未决的美国专利申请号10/660063(内部档号GB92002082)所描述的技术。该专利申请描述了一种机制，通过该机制可以将上下文添加到交谈抄本以指示其中一个用户传递信息给另一个用户的方式(情绪)。因此将关于其中叙说某些事情的方式的信息添加到即时消息抄本(愤怒、大声地等)。然后可以进一步地操控即时消息抄本以形成连续文字并且去除任何识别符/绰号信息。还可以提供规则来添加适当的标点并且适当地解释短形式的词语(例如，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”。
可以提供概括服务中所使用的任何规则作为即时消息软件的一部分，或者有即时消息接发服务器或者概括服务来提供它们。然后可以由即时消息接发客户端请求这些规则。
任何交谈抄本的分段都不是必须通过即时消息接发客户端来进行，而是相反地可以通过概括服务(由插件)或者通过即时消息接发服务器自己来执行。
虽然已经从每个即时消息客户端处所存储的交谈抄本的角度描述了本发明，但是并不必须是这样。还可以将抄本存储在即时消息接发服务器处。但是，为了升级的原因较不推荐这种方案。
最后，虽然已经从即时消息接发的角度描述了本发明，但是本发明并不限于此。可以将本发明等同地应用于诸如电子邮件、博客等之类的文档、或者诸如线程化的新闻组或者wikis之类的文档结构。
例如，可以使用本发明根据最后打开电子邮件的时间来概括电子邮件。是否概括电子邮件还可以依赖于其长度。对于文字处理文档也是如此。可以考虑在wiki文档结构中的文档数量，或者在wiki结构中的具体文档的长度。因此根据文档最后被打开的时间以及其长度来将概括呈现给用户。例如，可以概括500个词以上的文档，而将不概括较小的文档。利用wiki，可以将时间标记过的cookie存储在用户的计算机上并且用于确定用户最后访问wiki的时间。可以根据用户最后访问新闻组的时间来概括新闻组讨论。例如，用户可以为进行概括而选择新闻组内的特定线程化的讨论。然后使用代理从每个新闻组文章中提取文字，并且在提交文字用于进行概括之前对文字进行格式化(例如指示该文章来自谁)。还可以考虑从用户最后与文档结构交互起新文章的数量。
而且可以将文档的不同部分根据文字出现的位置而进行不同程度的概括。这可以是基于句子的总数或者期间添加文字的时间段。在线程化的新闻组讨论中，可以根据特别的回应深入到该讨论中的程度来对该讨论进行不同的概括。在随机添加文档和文档结构的情况中，改变概括的程度特别有用。换句话说，其中将新情况添加到文档或者结构的末尾的文档/文档结构。例如，这对于包括巨大数量的引导至事件的最新近状态的历史文字(以前的电子邮件)的电子邮件非常有用。
应该理解所述的各种实施方式可以彼此结合使用。
权利要求
1.一种用于实现文字概括的方法，包括根据文字在文档内相对于其他文字的位置或者在文档结构中的多个文档内包含该文字的文档的位置，来请求对文档中该文字的概括。
2.根据权利要求1所述的方法，其中，应用程序是即时消息接发应用程序，而文档是即时消息接发对话抄本。
3.根据权利要求2所述的方法，其中，在与即时消息对话抄本关联的即时消息接发对话中存在多个参与者，而且每个参与者具有对话抄本的版本，根据该文字在即时消息抄本内相对于其他文字的位置在文档中概括该文字的步骤包括请求对话抄本的版本。
4.根据权利要求3所述的方法，其中，根据文字在即时消息抄本内相对于其他文字的位置在文档中概括该文字的步骤包括如果给出了文字在文档中的位置，则访问指示用于请求的概括等级的规则。
5.根据权利要求4所述的方法，其中，在文档中较后出现的文字与在文档中较早出现的文字相比需要较低程度的概括。
6.根据权利要求3、4或者5所述的方法包括将即时消息对话抄本分段；和在每个段内请求文字概括的不同等级。
7.根据权利要求6所述的方法，包括根据抄本中的行数来将即时消息对话抄本分段。
8.根据权利要求7所述的方法，包括根据其间创建抄本的时间段来对即时消息对话抄本分段。
9.根据权利要求6、7、或者8所述的方法，包括使用用户喜好来确定如何对即时消息对话抄本进行分段。
10.根据权利要求6到9中的任何一项所述的方法，包括接收概括的交谈抄本段；和将分段合并到一起以显示给用户。
11.根据权利要求10所述的方法，其中将分段合并到一起的步骤包括对段进行格式化以指示用于每个段的概括等级。
12.一种用于实现文字概括的方法，包括结合文档的版本或者包括该文档的文档结构根据用户与应用程序的交互，请求在该文档中对文字的概括。
13.根据权利要求12所述的方法，其中应用程序是即时消息接发应用程序，而文档是即时消息接发对话抄本。
14.根据权利要求12或者13所述的方法，其中结合文档的版本根据用户与应用程序的交互来请求对文档中的文字进行概括的步骤包括根据在由用户所发送的最后消息和用户希望发送另一个即时消息以在对话中发言并因此修改抄本的指示之间的即时消息接发对话抄本所关联的即时消息接发对话中由其他参与者所发送的即时消息的数量，作出是否请求文字概括的决定。
15.根据权利要求14的方法，包括接收用户想要发送即时消息的指示。
16.根据权利要求12所述的方法，其中，结合文档的版本或者包括该文档的文档结构根据用户与应用程序的交互来请求对文档中的文字进行概括的步骤包括根据用户最后访问文档的版本或者文档结构的时间来确定是否请求概括。
17.根据权利要求16所述的方法，包括使用文档的长度来确定是否请求概括。
18.根据权利要求16所述的方法，包括使用与在用户最后与文档结构交互时所存在的文档数量相对的文档结构中的文档数量来确定是否请求概括。
19.一种用于实现文字概括的设备，包括用于根据文字在文档内相对于其他文字的位置，或者根据在文档结构中的多个文档内包含该文字的文档的位置，请求概括该文档中的文字的装置。
20.根据权利要求19所述的设备，其中应用程序是即时消息接发应用程序，而文档是即时消息接发对话抄本。
21.根据权利要求20所述的设备，其中，在与即时消息接发对话抄本关联的即时消息接发对话中存在多个参与者，而且每个参与者具有对话抄本的版本，其中用于根据文字在即时消息抄本内相对于其他文字的位置在文档中概括该文字的装置包括用于请求对话抄本的版本的装置。
22.根据权利要求21所述的设备，其中根据文字在即时消息抄本内相对于其他文字的位置在文档中概括该文字的装置包括用于在给出了文档中的文字位置的情况下访问指示用于请求的概括等级的规则的装置。
23.根据权利要求22所述的设备，其中在文档中较后出现的文字与在文档中较早出现的文字相比需要较低程度的概括。
24.根据权利要求21、22或者23所述的设备包括用于将即时消息接发对话抄本分段的装置；和用于在请求每个段内的文字概括的不同等级的装置。
25.根据权利要求24所述的设备包括用于根据抄本中的行数来将即时消息对话抄本分段的装置。
26.根据权利要求25所述的设备包括用于根据其间创建抄本的时间段来对即时消息对话抄本分段的装置。
27.根据权利要求24、25或者26所述的设备包括用于使用用户喜好来确定如何对即时消息对话抄本进行分段的装置。
28.根据权利要求24到27中的任何一项所述的设备，包括用于接收经概括的交谈抄本段的装置；和用于将各分段合并到一起以显示给用户的装置。
29.根据权利要求28所述的设备，其中，用于将各分段合并到一起的装置包括用于对段进行格式化以指示用于每个段的概括等级的装置。
30.一种用于实现文字概括的设备，包括用于结合文档的版本或者包括该文档的文档结构根据用户与应用程序的交互，请求在该文档中对文字的概括的装置。
31.根据权利要求30所述的装置，其中应用程序是即时消息接发应用程序，而文档是即时消息对话抄本。
32.根据权利要求30或者31所述的设备，其中用于结合文档的版本根据用户与应用程序的交互来请求对文档中的文字进行概括的装置包括用于根据在由用户所发送的最后消息和用户希望发送另一个即时消息以在对话中发言并因此修改抄本的指示之间的即时消息接发对话抄本所关联的即时消息接发对话中，由其他参与者所发送的即时消息的数量，作出是否请求文字概括的决定的装置。
33.根据权利要求32的设备，包括用于接收用户想要发送即时消息的指示的装置。
34.根据权利要求30所述的设备，其中用于结合文档的版本或者包括该文档的文档结构根据用户与应用程序的交互来请求对文档中的文字进行概括的装置包括用于根据用户最后访问文档的版本或者文档结构来确定是否请求概括的装置。
35.根据权利要求34所述的设备，包括用于使用文档的长度来确定是否请求概括的装置。
36.根据权利要求34所述的设备，包括用于使用在用户最后与该文档结构交互时所存在的文档数量相对的文档结构中的文档数量来确定是否请求概括的装置。
全文摘要
公开了用于实现文字概括的方法和设备。可以根据文字在文档内相对于其他文字的位置或者根据在文档结构中的多个文档内包含文字的文档的位置，来请求对文档中的文字进行概括。还可以结合文档的版本或者结合包括该文档的文档结构根据用户与应用程序的交互来请求对文档中的文字的概括。
文档编号H04L12/58GK1971551SQ20061012166
公开日2007年5月30日 申请日期2006年8月28日 优先权日2005年11月24日
发明者卢卡斯·W·帕特里奇, 马丁·J·盖尔, 马克·S·卡特, 安德鲁·J·斯坦福-克拉克, 巴拉特·V·贝迪 申请人:国际商业机器公司