微型博客(Micro-blogging)是一种允许用户及时更新简短文本并公开发 布的博客的形式，允许任何人阅读或者只能由用户选择的群组阅读。可以用 来表达用户此时此刻的所想所思的话或者正在做的事情等，也被称为迷你博 客或即时博客。通过微型博客，用户之间可以共享信息。目前主要的一些微 型博客有Twitter、饭否、滔滔等。
用户可以通过网页、手机上网、即时通信工具、短消息或者多媒体消息 等方式发布信息到微型博客。然而通常用户发布信息之后，很快这条信息就 被淹没在巨量的信息中了，即使存在对这条信息感兴趣的其他用户，也很难 看到以及回复这条信息。另外如果当用户通过网页方式浏览微型博客网站 时，一般在网页上显示已经发布的信息的同时还可以在网页上提供一个文本 输入框供用户发布信息，但目前用户在发布信息之后，在网页上除了增加显 示刚发布的信息外，通常仍旧显示用户发布信息之前的那些已经显示过的信 息记录，这些信息可能用户已经都看过了，与用户发布的信息也没有关系。
搜索引擎技术已经是一种发展多年的成熟技术，尤其是对文字信息的搜 索。一般搜索引擎由搜索器、索引器、检索器和用户接口等四个部分组成。 其中搜索器用于在互联网中漫游，发现和搜集信息。它常常是一个计算机程 序，日夜不停地运行，也被称为网络蜘蛛。索引器用于理解搜索器所搜索的 信息，从中抽取出索引项，用于表示文档以及生成文档库的索引表。检索器 的功能是根据用户的查询在索引库中快速检出文档，进行文档与查询的相关 度评价，对将要输出的结果进行排序。用户接口用于输入用户查询、显示查 询结果等。将搜索引擎的索引和检索技术应用到微型博客业务中，可以有助 于微型博客中海量信息的发掘和共享。
另外目前用户通过微型博客或者即时通信业务获知好友当前正在做的 事情如正在播放的音乐视频等媒体信息后，也无法使用户获得并同步播放好 友正在播放的媒体，也无法获得并同步显示好友所播放音乐的歌词、视频的 字幕等。

本发明实施例提出了一种对用户发布的信息进行处理的方法，使用户在 发布信息的同时，获得已经发布的相似信息。
本发明实施例还提出了一种对用户发送的信息进行处理的方法，为用户 发布的信息赋予相应的位置属性，可以为用户提供与位置相匹配的信息。
本发明实施例还提出了一种对用户发布的信息进行处理的方法，可以对 用户发布的信息直接通过一次点击操作就可以进行搜索。
本发明实施例还提出了一种媒体信息共享的方法，使用户之间可以同步 播放媒体或同步显示相应媒体的歌词、字幕文本等。
本发明实施例还提出了一种对即时通信签名信息进行处理的方法，可以 对用户在即时通信工具发布的签名信息直接通过一次点击操作就可以进行 搜索。
本发明实施例还提出了一种提供呈现信息的方法，可以将用户在微型博 客发布的信息同时在呈现业务中进行发布。
本发明实施例还提出了一种服务器，使用户在发布信息的同时，获得已 经发布的相似信息。
本发明实施例还提出了一种客户端，可以使用户之间共享应用程序信 息，尤其是媒体信息。
本发明实施例还提出了一种微型博客浏览器界面，可以按信息类型在相 应的子页面显示信息记录。
本发明实施例还提出了一种系统，可以使用户在发布信息的同时，获得 已经发布的相似信息。
本发明实施例提出的技术方案如下：
一种对用户发布的信息进行处理的方法，该方法包括步骤：
接收用户发送的信息；
在信息库中搜索与所述信息相匹配的信息记录，发布所述信息，将其记录 到所述信息库中；
将发布成功的提示信息和匹配的信息一起返回并呈现。
一种对用户发送的信息进行处理的方法，该方法包括步骤：
在接收用户发送的信息；
获取所述用户的位置信息，根据所述位置信息生成位置属性；
将所述的位置属性与所述信息一起保存。
一种对用户发布的信息进行处理的方法，该方法包括步骤：
在显示信息记录时，同时显示一个相应的搜索按钮；
所述搜索按钮被点击时，调用搜索引擎对相应的信息记录内容进行查询。
一种媒体信息共享的方法，该方法包括步骤：
收集正在播放媒体的媒体信息并发布，其中媒体信息中包含了播放的时间 信息；
获取所订阅的媒体信息；
根据所述的时间信息同步播放相应的媒体，或者同步显示相应媒体的歌词 或字幕文本。
一种对即时通信签名信息进行处理的方法，该方法包括步骤：
在显示好友的签名信息时，同时显示一个对应的查询按钮；
所述查询按钮被点击时，以对应的签名信息作为搜索关键字调用搜索引擎 进行查询；
接收查询结果并显示。
一种提供呈现信息的方法，该方法包括步骤：
微型博客服务器记录微型博客用户的呈现业务用户标识；
微型博客服务器接收用户终端发送的信息；
微型博客服务器将所述信息转换为呈现信息元素；
微型博客服务器根据所述的呈现业务用户标识为对应用户发布所述的呈现 信息元素。
一种服务器，包括：
信息接收单元，用于接收用户客户端所发送的信息，并将其记录到信息 存储单元，通知搜索匹配单元对信息存储单元中的信息记录进行搜索匹配；
信息存储单元，用于记录信息接收单元所接收的信息；
搜索匹配单元，用于对信息接收单元所接收的信息在信息存储单元中搜 索相匹配的信息记录，将匹配的信息返回给客户端。
一种客户端，包括：
信息搜集单元，用于搜集用户终端中运行的应用程序的信息；
信息发布单元，用于将信息搜集单元所搜集的应用程序信息发布出去；
信息接收单元，用于接收其他用户的所发布的应用程序信息；
应用启动单元，用于根据信息接收单元所接收的应用程序信息启动相应 的应用程序。
一种微型博客浏览器界面，按信息类型在相应的子页面显示信息记录， 所述的子页面包括以下至少其中之一：
报料子页面，用于显示报料类型的信息记录；
问题子页面，用于显示问题类型的信息记录；
愿望子页面，用于显示愿望类型的信息记录。
一种系统，包括：微型博客服务器，所述微型博客服务器包括信息接收 单元，信息存储单元和搜索匹配单元，
信息接收单元用于接收用户客户端所发送的信息，并将其记录到信息存 储单元，通知搜索匹配单元对信息存储单元中的信息记录进行搜索匹配，
信息存储单元用于记录信息接收单元所接收的信息，
搜索匹配单元用于对信息接收单元所接收的信息在信息存储单元中搜 索相匹配的信息记录，将匹配的信息返回。
本发明的有益效果如下：
本发明实施例通过在接收用户所发布的信息后，立即在信息库中搜索与 所发布信息的内容相匹配的信息记录，使得用户可以在发布信息的同时马上 获得与自己发布信息相似的其他信息记录。通过巧妙的将用户发布的信息同 时作为检索的输入条件，来检索已经被发布的其他信息记录，在完成信息发 布的同时提供了信息匹配的功能，一举两得，尤其适合微型博客这种信息发 布量较少的情形。通过本发明，用户可以在微型博客这类社会化网络(SNS) 中更容易发现与自己有“共同语言”的人。而且使得用户在发布信息之后可 以看到与发布之前不同的信息记录，这些信息记录与用户自己发布的信息相 关，提高了用户界面的利用效率，使用户可以看到更多更相关的信息。
还通过搜集应用程序信息并在结构化后进行共享发布，利用搜索技术使 用户可以发现使用类似应用程序的其他用户，并可以根据结构化的应用程序 信息进入相同或相似的应用场景界面。另外通过传送包含播放时间信息的媒 体信息，并优选地使用服务器侧的系统时间，使不同客户端之间可以很精确 的进行媒体播放的同步处理。利用搜索技术还可以查询并下载相应的媒体资 源文件。
另外还通过为信息记录生成并保存位置属性，使用户可以获得与自己位 置匹配相关的信息。
还通过在网页或即时通信客户端界面提供相应的搜索按钮，使用户直接 通过一次点击操作就可以进行相应的搜索。
附图说明
图1为本发明实施例对用户发布的信息进行处理的基本流程图；
图2为本发明第一实施例的流程图；
图3为本发明第二实施例的流程图；
图4为本发明第三实施例的流程图；
图5为本发明第四实施例的流程图；
图6为本发明第五实施例的流程图；
图7为本发明第六实施例向外部服务器发送搜索请求的流程图；
图8为本发明第六实施例向外部服务器发布信息的流程图；
图9为本发明第七实施例的流程图；
图10为本发明第七实施例的即时通信客户端与好友进行通信时的通信 状态界面示意图；
图11为本发明第七实施例的即时通信客户端中显示签名信息和对应搜 索和播放按钮的示意图；
图12为本发明第八实施例的浏览器中显示信息记录和对应搜索超链接 的示意图；
图13为本发明第八实施例的流程图；
图14为本发明第九实施例的计算时间差的示意图；
图15为本发明第九实施例的流程图；
图16为本发明第十实施例的流程图；
图17为本发明第十一实施例的在浏览器中显示子区域的示意图；
图18为本发明第十一实施例的在浏览器中显示报料子页面的示意图；
图19为本发明第十一实施例的流程图；
图20为本发明实施例服务器的基本结构示意图；
图21为本发明实施例服务器包含自动标注和虚拟机器人单元的结构示 意图；
图22为本发明实施例应用程序信息共享工具的结构示意图；
图23为本发明实施例应用程序信息共享工具包含查询、下载和同步播 放单元的结构示意图。

参照图1，该图是本发明实施例对用户发布的信息进行处理的基本流程 图，包括如下步骤：
步骤101、接收用户所发送的信息。用户终端如计算机或手机等可以通 过HTTP(HyperText Transfer Protocol)、WAP(Wireless Application Protocol)、 即时消息、短消息或多媒体消息等协议将消息发送到服务器。服务器对接收 的消息按相应协议解析，获取其中的内容信息和用户标识等。
步骤102、在信息库中搜索与所述信息相匹配的信息记录，发布所述信 息，将其记录到所述信息库中。服务器在信息库中搜索与用户所发布信息相 匹配的类似信息。所说的匹配可以是信息的内容相关、信息的标签相同或者 信息的位置属性相同或相近等。对于信息内容的匹配处理，简单的可以利用 目前成熟的搜索引擎技术，对保存的信息记录的内容建立索引，将用户发布 的信息内容作为搜索的输入进行检索，然后可以将匹配的结果按照相关度以 及时间顺序进行排序。在搜索时，还可以排除用户自己以前所发送的信息记 录，只搜索其他用户发送的信息记录。
服务器对接收到的信息进行记录，一般要同时记录当前时间、发送途径 信息(如是通过即时消息还是短消息等)等；然后将原始的信息以及时间和 途径信息等一起进行发布。发布后的信息保存在信息库中，通常服务器还会 对信息库建立索引库，以供通过关键词进行检索使用。本步骤中可以先搜索 匹配信息再记录发布信息，也可以先记录发布信息然后再搜索匹配信息。搜 索的结果不会影响记录和发布，如即使没有搜索到任何匹配的信息，也可以 成功得发布信息。
步骤103、将发布成功的提示信息和匹配的信息一起返回并呈现。将匹 配的信息内容，以及信息的发送者标识、发布时间等返回给用户。例如用户 如果通过网页发送了信息，则发送信息之后，返回网页所呈现的内容中就可 以包括与其发送信息相匹配的信息。另外该返回信息如返回网页中也同时包 括用户发布信息成功的提示，该提示可以是一段提示文字如“您发送的信息 已发布”，或者也可以直接以发布消息的形式呈现用户刚发布的这条信息作 为发布成功的提示，据此形式(如呈现该信息的发布时间)可以让用户意识 到该信息已经成功发布。如果用户是通过即时消息工具发送信息，则可以将 匹配的信息也通过即时消息返回给用户的即时消息客户端。
由上述步骤可见，在用户发布信息的同时，以其发布的信息作为输入的 检索条件进行搜索，而且搜索的目标也是其他用户已经发布的信息。这种方 式正好适合了微型博客中简单短小的信息内容。对于内容较多的传统普通博 客文章的发布并不适合上述方法。
第一实施例中详细描述了对用户通过网页发布的信息进行处理的方法。 首先用户要先登录微型博客网站，如果在发送消息时还没有登录则应提示用 户先进行登录。用户通过网页发送的消息中除了可以包含文字信息外，还可 以包括图片、声音和视频等，本实施例中主要考虑对文字信息的处理。
本实施例中还可以采用标签(tag)技术，以增强搜索能力，如提升匹配 信息的精确度。标签技术的实现方式包括手工标签方法和自动标签方法，手 工标签方法即在用户通过网页发送信息时，由用户对该信息指定分配一个标 签，随信息一起传送给服务器。标签通常为一个或多个关键词文本，如“游 戏”、“工作”、“饮食”、“音乐”、“电影”、“运动”和“心情”等。 在微型博客中可以提供按人们日常生活中的活动进行分类，每种活动类别对 应一个标签。考虑到将用户发送的信息可以作为呈现信息，或者反之将呈现 信息作为用户向博客网站发送的信息，可采用IETF(Internet Engineering Task Force)SIMPLE组呈现业务规范RFC 4480(RIPD)中的活动Activities 元素中的分类作为标签，如约会appointment，早餐breakfast，晚餐dinner，休 假holiday，开会meeting，旅行travel等。另外该规范中定义的心情mood也可 以作为标签。而文字信息内容与活动Activities和心情mood元素中的备注 note元素内容对应。这样当用户发布了一个活动Activities或心情mood呈现 信息后，呈现服务器可以将该呈现信息也发布到用户的博客网站中。或者用 户向博客网站发布了带有活动Activities和心情mood标签的信息后，服务 器可以将这些信息作为呈现信息分发给该用户的呈现信息订阅者。
服务器也可以在接收用户所发送的信息后，为所述信息自动生成相应的标 签。主动通过分析用户发送的文字信息中关键词来生成标签。关键词是从文字 信息的正文中选取出来的，是对表述该文字信息的中心内容有实质意义的词汇。 在确定关键词时，要进行基于语义的主题分析，根据结果选取若干词汇(通常 为意义清晰稳定的名词和动词)作为该文字信息的关键词集合。基于关键词分 析的自动标注方法正是结合了传统分类方法和手工标注的优点，在文字信息内 容本身的情景下进行标注，同时提供每个关键词对内容的贡献度作为参考，规 范了标注的标准，从而保证了质量。可以简单的建立关键词和分类标签的对应 关系表，如“早餐”、“绿豆汤”和“牛排”等关键词可以对应“饮食”标签， 当用户发送的信息中包含如“牛排”的关键词时，则服务器自动为其标注相应 的标签如“饮食”。一个信息记录可以被标注有一个或多个标签。
还可以采用一种简单对文字信息的标注方法，将文字信息中的第一个空格 之前的部分自动截取作为标签。这种标注方法很适合采用短消息来发布信息的 情形，如用户用手机发送短消息“舞蹈大赛周五决赛要去看看”。服务器将接 收到的文字信息首先去掉最前和最后面的空格和回车换行符等，然后将文字内 容中的第一个空格之前的文字部分截取出来作为标签。如果该截取的文字部分 过长，超过一个预设的长度上限，如多于5个字符，则不会将其作为标签，另 外也可能文字内容中不包含空格，这些情况下，可以不为文字信息自动生成标 签，或者仍旧使用关键词方法生成标签。还有第一个空格之前的文字开头如果 为功能标识字符如“！”、“*”等，或者第一个空格之前的文字为功能文字，用 于指示该条信息为特定类型的信息，如“报”指示该信息为报料信息，这时则 不能将第一个空格之前的文字其作为关键词。
服务器将标签用于搜索与所述信息的内容相匹配的信息记录。可以简单的 将包含有相同标签的信息记录判定为相似，如两条信息记录都具有“饮食”标 签，则可以判定为相似的信息。为了提高匹配的精确度，可以进一步对比信息 中关键词的匹配程度，关键词的匹配频度越高的，相似度即匹配度越高。另外 还有很多计算文字信息相似度的成熟技术，都可以应用到本实施例中，此处就 不再赘述了。
和搜索引擎不同，考虑到用户的目的并不是搜索，此处不必提供太多的匹 配结果。可以预先设置一个匹配结果的返回数量上限，如5或10条，可以在一 屏页面内显示完即可。在返回匹配结果时，最多只返回该预置上限数量的信息 记录即可，并全部显示在返回的页面内。服务器可以将要返回的所有匹配结果 按照发布时间顺序进行排序，使最新发布的信息显示在前面，较旧的信息显示 在后面。另外为了提高检索速度，可以只对当天或最近1小时等一定时间期限 内的信息记录进行匹配。实际上用户也往往只对较新的信息有兴趣，而且如果 匹配的信息和用户发送信息的发布时间相近，两个信息发布者可以进行聊天交 流的几率更大。
另外用户还可以预先对匹配消息发送者属性进行过滤设置，如通过对发 送者的地区、性别等属性进行过滤，可以让用户只看到与自己在相同地区的 其他用户发送的类似信息。服务器保存这些过滤设置，在搜索与所述信息的 内容相匹配的信息记录时，同时对信息记录的发送者应用过滤设置。这样即 使文字信息是匹配的，而根据发送者的属性这条信息也可能会被过滤掉，服 务器不会将其返回给用户。另外发送者属性中的是否为用户好友(或联系人) 也可以作为过滤设置，如用户可以只想在自己好友发送的信息中搜出与自己 发布信息类似的记录，则可以对是否为好友属性进行过滤设置，服务器据此 过滤设置仅在其好友发送的信息中搜索相匹配的信息记录。
在搜索之前，如果服务器检测到发布信息的用户绑定到一个频道或专栏， 则可以仅在该频道或专栏内搜索相匹配的信息记录。所谓的绑定即用户发送的 信息都会被服务器自动划分到其预先设置的一个固定频道或专栏分类中，例如 对于记者身份的用户，可以绑定到新闻频道专栏，该用户发布的信息默认被分 类到该新闻频道专栏。其他用户可以在该新闻频道专栏浏览看到该用户发布的 信息。另外将用户绑定到标签也可以达到同样效果，即用户发送的信息自动为 其分配预先设置的对应标签。例如对某个用户发布的信息服务器可以根据该用 户的设置为其分配“笑话”标签。
有些信息记录可以是用户对其他用户发布信息的回复评论，服务器记录这 种信息之间的回复关系。如果一条匹配的信息为回复信息，则服务器还同时返 回对应原始信息的链接，或者直接将原始信息的内容也一起返回。在显示返回 的信息时，原始信息可以显示在匹配的回复信息的下面相邻区域，并明确表明 其为回复信息对应的原始信息。
有些发布信息的用户可以是提供信息服务的业务提供商(SP)，如可以提供 笑话、天气情况、股市行情等。普通用户可以将这些SP用户加为联系人，获 取这些SP用户提供的咨询信息。对于这类特殊的SP用户可以不进行搜索匹配。 具体的可以为每个用户保存相应搜索设置，服务器根据该设置判断是否需要进 行搜索匹配。
服务器可以在记录用户所发布的信息时，即时生成索引；也可以在特定的 时间对信息记录生成索引。服务器在搜索匹配信息时，可以根据提取出的关键 词在索引库中检索匹配的信息记录。具体索引和检索的技术，都有很多成熟的 现有技术，此处就不再赘述了。
信息的标签可能并不存在于信息内容中，如标签“饮食”并不存在于信息 “正在麦当劳啃着鸡”中。将生成的标签也建立索引，可以使检索更加智能。 服务器在将所述信息记录到信息库时，同时为其生成索引项，将所述索引项 保存到索引库，其中也包括为所述的标签与所述信息的对应关系而生成的索 引项，在搜索与所述信息的内容相匹配的信息记录时，提取所述信息中的关键 词，使用所述关键词和所述标签在所述索引库中进行检索匹配的索引项，并在 信息库中获取与匹配的索引项对应的信息记录。
服务器在收到用户发布的信息之后，可以根据用户自身注册的信息如年龄、 性别、兴趣爱好、地区等查询匹配合适的广告内容信息，广告信息可以是文字、 图片或视频等内容。还可以结合用户所发布的信息获取相应的广告信息，如用 户发布的信息中包含有“吃饭”关键词，则可以选定一条餐饮类广告信息。在 服务器选定广告信息之后，将广告信息和匹配的信息一起返回并呈现。广告信 息可以用与匹配信息的相同的方式进行呈现，即可将广告信息也作为一条匹配 信息。服务器可以先在用户信息库中查询匹配的信息，然后再从广告信息库中 查询匹配的广告信息，接着将广告信息和匹配信息混合，如可以将广告信息排 在第1条匹配信息的前面或后面的位置。
在广告信息库中，每条广告信息可以设置对应的一个或多个匹配关键词， 如果服务器检测到用户发布的信息中有相应的关键词，则可以向其提供对应的 广告信息。另外每条广告信息还可以设置对应的用户信息匹配条件，如年龄、 地区条件等，服务器只向满足相应条件设置的用户提供对应的广告信息。
参照图2，下面再结合流程图进行举例描述：
步骤201，接收用户通过网页发送的文字信息。
步骤202，分析用户发送的文字信息中关键词来生成标签。
步骤203，获取与所述文字信息具有相同标签的信息记录，并应用所述用 户对消息发送者属性的过滤设置。
步骤204，选取少于预置数量上限的匹配信息。
步骤205，根据用户信息和/或用户所发布的信息和/或所匹配的信息获取相 应的广告信息。如根据用户的兴趣爱好信息，或者用户所发布的信息、所匹配 的信息中的关键词选取对应的广告。
步骤206，将匹配的信息和广告信息一起返回并呈现。
第二实施例主要描述微型博客与聊天室的结合。微型博客网站可以同时提 供聊天系统，当用户进入一个聊天室后，服务器可以获取该用户最近在微型博 客已发布的信息记录，然后在聊天室中显示，如作为该用户的公开发言在聊天 室里进行显示。
在第一实施例中用户发布信息后，获得了其他用户相匹配的信息后，也可 以向其他的用户发起聊天。在发起的聊天中，服务器可以首先在建立的临时聊 天室里显示两个人之前所发送的相似消息，以此作为聊天室的开场白或主题。 服务器为建立的临时聊天室可以分配一个标识，如可以用一个唯一的随机字符 串表示。在第一实施例中服务器将匹配的信息返回并呈现的同时，还可将所匹 配信息的发送者所在聊天室的地址链接也一起返回并呈现，聊天室的地址链接 中包含所述的标识。当用户点击该聊天室的地址链接后，服务器可以根据相应 的请求将用户加入到该聊天室中。
参照图3，下面再结合流程图进行举例描述：
步骤301，检测到有用户进入聊天状态。如检测到有用户加入到聊天室， 或者检测到一个用户邀请另一用户进行聊天。
步骤302，获取用户最近在微型博客已发布的信息记录。
步骤303，在聊天室中显示所获取的信息记录。
用WAP网页方式发布信息与第一实施例类似，第三实施例中主要描述通过 即时通讯工具发布信息的情形。可以利用即时通讯的虚拟机器人技术来发布信 息，具体的即设立一个业务处理服务器并与一个即时通讯帐号相对应，用户可 以将该业务处理服务器对应的即时通讯帐号加为好友，该业务处理服务器就像 用户的普通好友一样，可以收发即时消息和呈现信息。所以将这种非自然人的 好友即联系人称为虚拟机器人，实际为进行业务处理的程序实体。虚拟机器人 对应的业务处理服务器可以独立于微型博客服务器，也可以同时作为微型博客 服务器。
通过即时通讯工具发布信息有两种途径，一种是通过即时消息，即直接 向微型博客业务对应的虚拟机器人发送即时消息，虚拟机器人将接收到的即 时消息中的信息进行记录并发布。并且搜索与所述信息的内容相匹配的信息 记录，然后将匹配的信息通过即时消息返回并呈现。用户的体验就像是在和 机器人进行即时消息的对话。除了匹配的信息本身之外，最好还能带有一些 提示信息，表明这些返回信息为自动匹配的信息，提示信息举例如“最近发 布的相似信息还有：”。如果这些匹配信息的发送者也绑定有即时消息帐号， 则也可以将其帐号连同信息一起返回，这样用户可以利用帐号信息直接与对 应的其他用户进行即时消息对话，或者将其加为好友等。
另外一种发布信息的途径是通过呈现信息。典型的呈现信息(Presence)是 在线、离线、忙等用户的当前状态，另外即时通讯工具里的签名也可以作为一 种呈现信息。虚拟机器人通过订阅用户的呈现信息，可以获得用户的最新的状 态和签名等信息，虚拟机器人可以将这些信息发布到微型博客中。用户可以预 先设置哪些呈现信息可以被发布到博客中，虚拟机器人根据用户的设置进行选 择性的发布信息。在第一实施例中提到的RFC 4480，是基于IETF的SIMPLE 规范的一些扩展呈现信息，用户在即时通讯系统中发布这些呈现信息的同 时，可以利用虚拟机器人将其发布到自己的微型博客网站。
参照图4，下面再结合流程图进行举例描述：
步骤401，接收用户的即时消息和/或呈现信息并发布。
步骤402，搜索与所述信息的内容相匹配的信息记录。
步骤403，将匹配的信息记录通过即时消息返回并呈现。可以在一条即时 消息中返回所有检索出的匹配信息记录，也可以用多条即时消息中返回，每条 即时消息包含一条匹配的信息记录。
用户发布的信息可以是自己撰写的内容，还可以包括应用程序信息。第四 实施例描述用户发布的信息包含应用程序信息的情形。应用程序信息主要用来 描述用户终端当前正在运行应用程序的情况，包括应用程序的名称和参数等。 具体如浏览器(Internet Explorer)和当前正在浏览的网站地址参数，或者地图 客户端(Google Earth)和当前地图的中心点坐标参数。
应用程序信息的发布通常不是用户手工发布，而是可以通过应用程序信息 共享工具自动搜集然后受控的进行发布。用户可以预先设置哪些应用程序信息 允许发布，以控制隐私受到保护。可以通过对终端的进程信息进行监控来搜集 获得正在运行应用程序的信息，而对一些复杂具体的应用程序信息(如网络游 戏中用户角色的等级、位置坐标等)，可能无法从操作系统的进程信息中获得， 这样可以定义对应的应用程序接口，使应用程序可以将一些特定的信息通过接 口传送给应用程序信息共享工具。可以将应用程序信息共享工具直接集成到即 时通讯工具中，这些应用程序信息本质上也属于呈现信息。也可以使用独立的 应用程序信息共享工具，专门进行应用程序信息的搜集、发布和共享等。
应用程序信息共享工具可以自动根据搜集的应用程序信息生成文字或图片 等信息，将其发布到服务器。自动生成的信息可以允许用户进行修改补充。如 发布的信息为：“正在玩扫雷游戏，手都麻了”，前半句由工具自动生成，后半 句由用户补充。
应用程序信息共享工具最好向服务器提供结构化的应用程序信息，如用可 扩展标识语言XML(Extensible Markup Language)格式描述的应用程序信息，具 体举例如下：
<？xml version＝″1.0″encoding＝″UTF-8″？>

    Google Earth
    4.2.198.2451
    Microsoft Windows XP Professional
    113.9434371827877，22.52881806088745，0

结构化的应用程序信息中可以包括应用名称、 版本号、运行的操作系统和参数等。可以有一个或多 个参数元素，这个例子中只有一个参数，其中包括当前Google Earth 应用中卫星地图的中心位置坐标。应用程序信息中还可以包括一个备注 元素，可以允许用户补充文字内容信息。例如：
这里的房价08年会涨到三万
应用程序信息共享工具通过HTTP或SIP(Session Initiation Protocol)等 协议将结构化的应用程序信息发送到服务器，服务器将接收到的应用程序信 息保存。服务器可以根据结构化的应用程序信息自动生成可读的自然语言文 字信息，如根据上述例子中的应用程序信息可以生成文字信息：“正在使用 Google Earth，这里的房价08年会涨到三万”，服务器将生成的文字信息进 行发布。服务器还可以同时提供一个指向结构化应用程序信息的链接，使其 他用户可以获得文字信息对应的原始结构化应用程序信息，并且进一步可以 据此重现应用场景，如获取观看同样坐标位置的卫星地图等。
服务器在接收到结构化应用程序信息后，可以搜索与应用程序信息相匹 配的信息记录。简单的如果应用程序名称相同则可判定相匹配，为了减少匹 配结果数量和提高匹配精确度，可以进一步对参数或备注元素内容进行匹 配。如备注的文字信息中关键词匹配。对于应用程序参数匹配，往往是和具 体应用相关的，应用程序不同，参数匹配判定的方法也可能会不同。服务器 根据应用程序名称选择相应的匹配判定程式，如对于地图类应用中的坐标参 数，可以判定位置坐标的接近程度来判定匹配度；而对于网络游戏应用中的 用户团队帮派参数，可以判定是否相同，只有相同才判定为匹配。
服务器将所匹配的结构化应用程序信息返回给应用程序信息共享工具， 应用程序信息共享工具据此可以依用户请求来启动相应的应用程序，重现所 对应的应用程序场景。如果应用程序信息共享工具在本地终端上无法发现有 相应的应用程序，则可以提示无法启动相应的应用程序。
参照图5，下面再结合流程图进行举例描述：
步骤501，应用程序信息共享工具根据用户设置自动搜集应用程序信息。
步骤502，将搜集到的应用程序信息转换为XML格式并发布。
步骤503，服务器在接收到应用程序信息后，搜索与应用程序信息相匹配 的信息记录。
步骤504，服务器将所匹配的结构化应用程序信息返回给应用程序信息共 享工具。
步骤505，应用程序信息共享工具依用户请求启动相应的应用程序，重现 与所匹配的应用程序信息相对应的应用程序场景。
微型博客也可以作为不公开的个人日记或备忘录来使用。第五实施例描 述了对备忘信息的处理。在发布信息时，用户可以设置该信息为不公开的个 人日记，或称为备忘录。一种简单的方法是可以在发布信息内容的开头用特 殊字符进行标识，如服务器当接收到一条信息中的文字内容以“*”字符开 始，则判定该条信息为备忘信息。或者在通过网页发布时，用信息内容输入 字段之外的单独一个信息字段指出信息是否为备忘信息。
备忘信息发布之后，只能由发布者自己才能查看，即服务器只向备忘信 息发布者提供他自己的备忘信息。当服务器接收到用户发布的备忘信息之 后，服务器可以搜索该用户已经发布的备忘信息记录，将相似的备忘信息匹 配出来，返回给该用户。这样可以让用户容易的发现自己之前发布的类似信 息，增强了备忘功能。
更一般的，服务器可以根据用户发布信息的方式确定搜索的范围，并在 所确定的范围内搜索相匹配的信息记录。用户发布信息的方式可以根据发布 途径(如短信、彩信)或发布信息时所处的网页类型等所确定。例如当用彩 信发布信息时，则可以在包含图片内容的信息记录范围内进行搜索匹配。又 如当发布信息时处于备忘录网页，则服务器只在用户自己的备忘录范围内进 行搜索；而当发布信息时处于浏览好友发布的信息的网页时，则服务器只在 用户好友的信息记录范围内进行搜索。通常微型博客网站在很多页面都提供 的发布信息的功能区域，不同页面发布信息时对应处理程序不同，或者发布 信息时传递相应的发布方式参数，使服务器对不同发布方式进行识别并做相 应处理。
参照图6，下面再结合流程图进行举例描述：
步骤601，检测到用户发布的信息为备忘信息，或者检测到用户是在备忘 信息浏览页面发布的信息。
步骤602，搜索该用户已经发布的备忘信息记录。
步骤603，将相似的备忘信息匹配出来，返回给该用户客户端。
第六实施例主要描述微型博客之间的互联互通。目前已经有多家微型博 客在运营，各自互相独立，这样对用户来说很不方便，如无法将另一个微型 博客网站的用户加为好友等。首先举例介绍一下添加好友的过程：
微型博客网站A的用户UserA在微型博客网站A提供的添加好友页面 上选择欲添加好友所在的微型博客网站的标识名称如B，然后输入好友的标 识名称如UserB，点击添加好友按钮后，浏览器向微型博客网站A的服务器 A发送添加好友的请求，服务器A向微型博客网站B的服务器B发送消息， 消息中包括用户UserA和UserB的标识名称，服务器B检测是否有UserB 存在，如果存在还可以进一步检测UserB的安全设置，根据安全设置验证 UserA是否能够添加UserB为好友。添加成功时服务器B增加一条UserB的 好友记录，包含UserA的标识名称以及微型博客网站A的标识名称。然后 服务器B向服务器A返回添加成功的响应消息，服务器A也增加一条UserA 的好友记录，包含UserB的标识名称以及微型博客网站B的标识名称。于 是两个微型博客网站就分别建立了UserA和UserB的好友关系记录。如果服 务器B没有添加成功，则向服务器A返回添加失败的响应消息，还可以包 括添加失败的原因，如包括不存在UserB，或UserB不允许添加等原因描述。 另一方面，当删除UserA的好友UserB时，服务器A在删除本地的相应好 友关系记录之外，还向服务器B发送删除通知，服务器B也将相应的好友 关系记录删除。
服务器可以只保存本网站的用户所发布的信息，这样在需要其他外部网 站的信息记录时则要访问外部服务器。例如，如果搜索的范围限定在好友发 布的信息记录，当用户的一些好友属于其他微型博客网站时，则服务器需要 向其他微型博客网站的服务器提交相应的搜索请求。搜索请求中包括用户所 发布的信息、用户所属网站标识名称以及用户标识名称等，接收到搜索请求 的服务器根据搜索请求中的用户所属网站标识名称以及用户标识名称在好 友关系记录中查询确定本网站中该用户的好友列表，然后在这些好友发布的 信息记录中搜索与用户所发布的信息相匹配的记录，并将其返回给发送搜索 请求的服务器，发送搜索请求的服务器将其他服务器返回的信息记录与本地 检索出的信息记录合并后一起返回给客户端。简单的合并可以是把本网站匹 配出的信息记录放到页面前面显示，而把其他网站匹配出的信息记录依次放 到后面显示。当然为了能按照匹配度来对所有的信息记录排序，一个服务器 可以对其他服务器返回的信息记录计算匹配度，并与本地所匹配出信息记录 一起按照匹配度进行排序。如果由其他服务器返回信息记录时同时返回匹配 度，则可能由于匹配度的计算方法不一致而无法进行合理的排序，这里统一 由发送搜索请求的服务器来计算，可以保证匹配度计算的一致性。如果只是 简单的按照时间排序，则可以根据其他服务器返回的信息记录中的时间信息 进行排序即可，可以认为各个服务器的系统时间是准确一致的，当然也考虑 时差因素。一般还可以限定搜索请求返回匹配记录的数量上限或者时间范围 等，这些限定可以在搜索请求中用相应的参数指定即可。
微型博客网站还可以开放搜索请求接口，具体的可以是基于HTTP协议 的接口，该接口不仅可以提供给其他微型博客网站，也可以提供给其他的互 联网业务使用。搜索请求接口中包括搜索条件参数，如文字内容或关键词参 数，还可以包括时间参数、用户标识等。服务器根据搜索请求接口中提供的 参数进行查询，并将相匹配的信息记录返回给发送搜索请求者。具体的接口 可以采用HTTP GET或HTTP POST方法，其中HTTP GET方法将搜索条件 参数放在消息的请求行中，而HTTP POST方法可以将搜索条件参数放到消 息体中。另外还可以采用基于HTTP的SOAP协议来实现搜索请求接口，此 处不再赘述。基于HTTP GET方法的接口举例如下：
GET http://www.example.com/search？uid＝123456&txt＝hello HTTP/1.1
其中参数“uid”和“txt”分别为用户标识和发布信息。该HTTP GET请求 消息被发往外部服务器，外部服务器在依据参数进行检索后，将匹配的信息记 录通过HTTP协议的200 OK响应消息体中返回。
参照图7，下面再结合流程图进行举例描述：
步骤701，客户端发布信息到服务器。
步骤702，服务器获取用户的好友关系记录。
步骤703，服务器向外部服务器发送搜索请求。可能会向一个或多个外部 服务器发送搜索请求。
步骤704，接收外部服务器返回的搜索结果。
步骤705，将返回搜索结果中的信息记录与本地检索出的信息记录合并。
步骤706，将合并的信息记录返回给客户端。
服务器在接收到本网站用户发布的信息后，也可以该信息同时发布到与之 互联互通的外部服务器。反之，即服务器也可以接收外部服务器所转发的发布 信息。一个外部网站的用户向外部服务器发布信息后，外部服务器除了在本地 存储该信息外，外部服务器还检测该用户的好友关系记录，确定该用户好友所 属的网站，用户的好友可能会分布在多家不同的网站。外部服务器将发布的信 息以及用户的标识通过发布请求发送给好友所属网站对应的服务器。好友对应 的服务器则将所述发布请求中的用户标识和所发布的信息、以及外部服务器对 应的网站标识等一起存储在本地的信息库中。
服务器在后续匹配处理时，如果有匹配的信息来自外部服务器，则将外部 服务器对应的网站标识或名称和信息记录一起返回并呈现。
上述的发布请求可以采用与HTTP(Hypertext Transfer Protocol，超文本传 输协议)协议绑定的SOAP(Simple Object Access Protocol，简单对象访问协议) 协议来实现。具体举例如下：
POST/publish HTTP/1.1
Content-Type：text/xml；charset＝″utf-8″
Content-Length：nnnn
SOAPAction：″http://www.example.com/publish/″
Host：www.example.com
<？xml version＝″1.0″encoding＝″UTF-8″？>

  
    
      example
      www.example.net
      xyz@example.net
      Hello World
    
  

上述SOAP协议中采用与HTTP POST方法绑定，在消息体中包含了用户 标识“uid”以及发布信息“txt”。另外还直接将用户归属的外部服务器的标识 “domain_name”和名称“domain”也包含在消息体中。
参照图8，下面再结合流程图进行举例描述：
步骤801，服务器接收并保存本网站用户发布的信息。
步骤802，查询用户的好友关系记录，确定用户好友所在的外部服务器。
步骤803，将该信息同时发布到外部服务器。
第七实施例描述媒体信息共享的方法，媒体如音乐、视频等。即时通信客 户端可以收集正在播放媒体的媒体信息，如正在播放的音乐或电影信息，媒体 信息一般包括媒体的名称，还可以包括专辑名称、艺术家等信息，媒体信息实 际上也是一种应用程序信息，一般可以从媒体播放程序获取媒体信息。客户端 还可以获取媒体播放的时间信息如开始时间，具体的如果媒体播放开始之后即 时通信客户端才启动，则可以根据当前媒体的播放时间来确定播放的开始时间， 如果媒体播放开始时即时通信客户端已经启动了，则客户端可以直接记录播放 的开始时间。然后客户端可以将包含播放开始时间的媒体信息进行发布；一般 发布到即时通信服务器，由即时通信服务器将其向订阅者分发，实际上即向用 户的好友进行分发。
另外为了避免客户端的时间不准确，可以按以下方法处理：客户端发布媒 体信息时，将当前的播放进度信息作为时间信息一起发布到服务器，进度信息 即当前媒体已经播放的时间长度，如果媒体播放开始之后即时通信客户端才启 动，则进度时间信息为一个正数，可以用秒计算；如果媒体播放开始时即时通 信客户端已经启动了，则可以立即发布相应的媒体信息，这是相应的进度时间 信息为0秒。服务器在接收到播放进度信息后，根据自身的系统时间计算出媒 体播放的开始时间，然后将以服务器系统时间为基准的播放开始时间替换媒体 信息中的播放进度信息，并分发给订阅者。订阅者的即时通信客户端可以根据 记录的自身时间和服务器时间的差值来计算出实际的播放进度。由于客户端与 服务器进行通信时很多实时的请求和响应的时间差一般都会在最多几秒以内， 所以可以近似得将客户端向服务器发送实时请求的时间与获得的对应服务器响 应中所带服务器时间的差值作为客户端与服务器之间的系统时间差值，考虑请 求和响应之间的延迟，还可以增加一两秒的补偿量。具体的，如可以根据服务 器发送的SIP NOTIFY消息或200 OK响应消息中的时间如Date或Timestamp 头字段信息来计算系统时间差值。
服务器没有直接将所发布的播放进度进行分发的原因是由于服务器可能并 不能立即将播放进度进行分发。服务器接收到发布的播放进度时某个好友还没 有上线，当该好友上线时，由于已经过了一段时间了，显然不能直接将原来的 播放进度发送给他。另一种方案是，如果服务器记录发布的播放进度信息和当 时的发布时间，当服务器发送播放进度信息时，需要计算发送时的时间与发布 时间的差值，将差值增加到播放进度上再进行发送。当然如果服务器在接收到 发布的播放进度信息时，立即进行分发，则不需要计算差值，直接分发所接收 到的播放进度信息即可。客户端在接收到服务器分发的播放进度信息时，记录 自身当时的系统时间，后续客户端即可利用接收到的播放进度信息以及所记录 的自身当时的系统时间来计算出当前实际的播放进度，从而进行同步处理。
好友的客户端获取所订阅的媒体信息，其中包括了播放的时间信息。通常 客户端并不会在接收到媒体信息后就立即进行同步处理，而是可能会在后续当 检测到与发布媒体信息者处于通信状态时，或者当检测到发布媒体信息者被选 中时，才进行同步处理，这时客户端根据播放的时间信息同步播放相应的媒体， 或者同步显示相应媒体的歌词或字幕文本。客户端可以根据媒体信息中的音乐 或视频的信息如标题和艺术家的名称等去查询获取相应歌词或字幕文件，如歌 词(Lyric)文件通常为LRC格式，具体格式举例如下：
[ti:Hello Goodbye]
[ar:Cheyenne Kimball]
[al:The Day Has Come]
[00:00.00]07.Hello Goodbye
[00:02.47]Am I speaking Japanese
[00:04.46]I told you 20 times when neat
[00:07.11]but you still don′t get it。
其中包括标题等信息，而每句歌词前有时间信息，如[00:02.47]，通用格式 为″[mm:ss.fff]″，即″分钟数:秒数″。字幕(subtitle)文件格式如SRT等与歌词 文件类似，此处不再赘述。客户端根据播放的时间信息计算出播放的实际进度， 然后在本地播放显示的字幕或歌词调整到相应的时间点即可。
另外客户端在获取所订阅的媒体信息后，可以自动调用搜索引擎查询并下 载对应的媒体资源文件，或者歌词、字幕文本等。如媒体信息中包含一首歌曲 的名称和歌手的名称，则将这些媒体信息作为搜索关键词调用搜索引擎进行查 询，并可以进一步从查询结果中取出媒体资源文件或者歌词、字幕文本等的地 址，然后将其下载到客户端。当然也可以首先在客户端本地进行搜索相应的媒 体资源文件，如果本地已经有了则不必进行下载了。查询或下载之前还可以向 用户进行提示确认，在用户确认之后才进行查询或下载操作。
另外在发布媒体信息时，还可以包含媒体的总时长信息，这样可以据此判 断该媒体当前是否已经播放完了。客户端在一个媒体播放完成之后，可以播放 其它媒体或者重复播放媒体，在检测到任一媒体开始播放之时，客户端可以进 行媒体信息的发布。
参照图9，下面再结合流程图进行举例描述：
步骤901，即时通信客户端收集并发布正在播放媒体的媒体信息，其中包 括媒体播放的时间信息。
步骤902，服务器接收并分发媒体信息。
步骤903，好友的客户端获取所订阅的媒体信息。
步骤904，调用搜索引擎查询并下载媒体信息对应的媒体资源文件。
步骤905，当检测到与发布媒体信息者处于通信状态时，或者当检测到发 布媒体信息者被选中时，进行同步处理。
参照图10，为即时通信客户端与好友进行通信时的通信状态界面，主要包 括聊天文字显示区域B1，歌词同步显示区域B2，文字输入区域B3，发送按钮 B4。用户在文字输入区域B3输入文字信息，然后点击发送按钮B4将文字发送 出去，文字信息显示在聊天文字显示区域B1中，将好友正在播放音乐对应的 歌词显示在歌词同步显示区域B2，可以从上到下进行滚动播放。
很多即时通信客户端都提供设置和显示签名信息的功能，签名信息可以是 用户自己输入的一段文字或者是客户端自动获取到的媒体信息。可以在显示好 友的签名信息时，同时显示一个对应的查询按钮；当所述查询按钮被点击时， 以对应的签名信息作为搜索关键字调用搜索引擎进行查询。可以在即时通信客 户端或者浏览器中显示查询结果。这样可以方便用户在互联网上查询好友签名 相关的信息，尤其是可以根据媒体信息查询到相关的媒体资源文件。当然也可 以在客户端本地查询相关的媒体资源文件。不需要用户将签名信息进行复制或 者手工输入到搜索引擎中去了，节省了操作步骤。
如果签名信息为媒体信息，则客户端在接收到查询结果时，根据查询结果 提供的资源链接下载对应的媒体资源文件。客户端可以边下载边播放，也可以 下载完成后再播放。在下载完成之后，可以在签名信息旁边显示一个播放按钮 或同步播放按钮，当播放按钮被点击，可以从头开始播放相应媒体，而当同步 播放按钮被点击，可以根据媒体信息中的时间信息进行同步播放处理。
参照图11，为即时通信客户端界面，一般会显示联系人列表即好友列表， 每个好友项目显示有一个图标，好友的名称以及签名。当鼠标停留到中的一个 项目如好友1时，则在签名信息的后面显示相应的查询按钮A1。如果签名信息 包含媒体信息，则当媒体被下载或获得媒体资源的地址后，在签名信息后显示 一个相应的播放按钮A2。
第八实施例描述使用微型博客外部的搜索引擎对用户发布信息进行查询的 方法。以网页方式为例，用户访问微型博客网站时，在网页中显示每条信息记 录时，同时显示一个相应的搜索按钮；当所述搜索按钮被点击时，调用搜索引 擎对相应的信息记录内容进行查询。具体的可以在每条显示的信息记录下面显 示一个“搜索”按钮或超链接。所述每个“搜索”按钮或超链接对应的网页源 文件中的代码由微型博客服务器根据每条信息记录的内容生成。举例如下，如 果一条信息记录的文字内容为“Hello”，则服务器为该信息记录生成的对应“搜 索”超链接源代码可以是：
搜索
从上可见直接将信息记录中的文字内容传递了搜索引擎如 “http://www.example.com/s”。
如果信息记录中的文字内容较多，如超过30个汉字，则最好不要直接向搜 索引擎传递全部的文字内容。服务器可以预置文字数量上限，如30，当服务器 检测到信息记录的文字内容多于预置文字上限时，则提取信息记录的文字内容 中的关键词，并将提取的关键词传送给搜索引擎，以供查询使用。这样向搜索 引擎传递的信息量减少，而且微型博客网站更了解用户，如用户在微型博客网 站注册时提供了爱好、职业、地区等信息，微型博客网站可以基于用户的特征 来提取到更合适的关键词。
例如服务器从一条信息记录中提取出的关键词为“weekend”和“overtime”， 则服务器为该条信息记录生成对应的“搜索”超链接源代码可以是：
搜索
当用户在浏览器中点击在信息记录下面显示的相应的“搜索”超链接时， 浏览器会向搜索引擎服务器发送HTTP GET请求，搜索结果在响应消息中返回 给浏览器。
用户发布的信息有多种类型，除了普通的纯文字信息外，还可以包括图片 信息等。另外还可以包括媒体信息，如正在听的音乐名称，或正在看的电影名 称等。服务器可以首先判断信息记录的内容类型，然后根据内容类型调用相应 的搜索引擎。如在检测到一条信息记录只包含普通的纯文字信息，则可以调用 普通的通用搜索引擎进行查询，而如果检测到一条信息记录中除了文字信息还 包含图片时，则可以调用图片搜索引擎，当然传递给图片搜索引擎的可以是信 息记录中的文字信息和/或图片。
如果服务器检测到信息记录中包括媒体信息时，媒体信息可以包括媒体名 称、艺术家名称和媒体类型等。微型博客的虚拟机器人可以在即时通信客户端 获得媒体名称、艺术家名称和媒体类型等信息后，将这些媒体信息发布到微型 博客服务器。服务器将媒体名称等传送给媒体类型所对应的垂直搜索引擎进行 查询，垂直搜索引擎是相对于通用的搜索引擎来说的，专用于某一领域内的搜 索，如图片搜索引擎、音乐搜索引擎或视频搜索引擎等。如虚拟机器人发布的 一条信息记录：“正在听音乐：青花瓷周杰伦”，则服务器根据信息中内容类型 指示“正在听音乐”确定为音乐类型的媒体，对应一个音乐搜索引擎，并将媒 体名称、艺术家名称一起传送给该音乐搜索引擎。在服务器中可以预先保存有 信息类型和搜索引擎的对应关系。服务器为该信息记录生成的“搜索”超链接 源代码可以是：
href＝″http://music.example.cn/m？w＝％C7％E0％BB％A8％B4％C9+％D6％DC％B D％DC％C2％D7″>搜索
此外还可以为显示的每条信息记录提供一个“站内搜索”的按钮或超链接， 当其被点击时，服务器将在本站内的信息库中查询与该信息记录相关的信息。
参照图12，为浏览器中显示信息记录的界面，所显示的每条信息记录主要 包括用户名如“用户A”以及用户的图标，还有文字信息内容A13，如果有图 片内容，也可以在右侧显示图片。在信息记录的下面可以显示一些超链接如“评 论”，还有“搜索”A11、“站内搜索”A12等。当点击“搜索”A11超链接时， 调用搜索引擎对信息记录中的文字信息进行检索，然后将检索结果在一个新的 网页中显示给用户。
参照图13，下面再结合流程图进行举例描述：
步骤1301，服务器检测到信息记录的文字内容多于预置文字上限时，提取 信息记录的文字内容中的关键词。
步骤1302，判断信息记录的内容类型，根据内容类型调用相应的搜索引擎。
步骤1303，生成调用相应的搜索引擎对提取出的关键词进行查询的搜索超 链接。
步骤1304，显示每条信息记录时，同时显示一个相应的搜索超链接。
上述第七和第八实施例中通过在网页或即时通信客户端界面提供相应的搜 索按钮，使用户直接通过一次点击操作就可以进行相应的搜索。还可以根据信 息类型调用相应的搜索引擎进行搜索，并对搜到的媒体资源文件进行下载，进 而同步播放。
第九实施例描述基于会话初始协议SIP的事件发布和通知机制来实现 应用(如媒体播放)的同步。这里还是以媒体播放为例，不同客户端之间同 步播放媒体所需要的信息主要包括媒体名称和播放进度等，同步的关键问题 在于如何基本准确的传递实际的播放进度信息，因为不同客户端之间的系统 时间很可能是不一致的，用户可以基于一些目的任意设置自己计算机或手机 的系统时间。其他的应用如地图程序进行同步(即同步应用界面场景)可能 需要当前的地图坐标等，来实现不同客户端同时显示基本相同的地图场景。
客户端首先获取服务器的系统时间，具体可以根据服务器发送的一些消 息如SIP NOTIFY消息或200 OK响应消息中的时间如Date或Timestamp头 字段信息。从而可以算出客户端与服务器之间的系统时间差值。
第一客户端使用SIP PUBLISH发布方法发布媒体信息事件包到服务器， 事件包中包括媒体信息，媒体信息中包括媒体播放的开始时间，这个开始时 间以服务器的系统时间为准，而不是客户端的系统时间。具体举例如下：
PUBLISH sip:usera@example.com SIP/2.0
Event：mediainfo
Content-Type：application/mediainfo+xml
<？xml version＝″1.0″encoding＝″UTF-8″？>

 
   
   2008-01-09T11:10:00Z
   242
 

其中该PUBLISH消息中，事件包的名称为“mediainfo”，事件包的内 容类型为“application/mediainfo+xml”，另外一些SIP字段为简明起见进行 了省略。事件包的内容中包括目前音乐“tune”的一些信息，如音乐标题名 称“title”，和音乐的总时长“total_time”等，还包括音乐开始时的服务器 的系统时间“server_start_time”。如果该音乐资源可以从一个具体的地址获 取，还可以包括对应资源地址如“uri”。如果播放的音乐为本地一个媒体文 件，则可以同时提供一些文件信息，以便对方客户端可以下载到相同的文件， 如文件大小“size”，文件名“name”，文件名要包括文件后缀，以便识别 文件类型。文件还可以包括文件数据的哈希值“shal”。
第二客户端通过SIP SUBSCRIBE订阅方法向服务器订阅好友对应的媒 体信息事件包，服务器通过SIP NOTIFY通知方法向订阅者如第二客户端分 发第一客户端发布的媒体信息事件包。第二客户端收到媒体信息事件包后， 可以根据自己系统时间与服务器系统时间的差值计算出相对于自身的播放 开始时间，即实际的播放进度，从而进行同步处理。
客户端和服务器之间系统时间差值的一种简单计算方法是，当客户端发 送一个实时请求消息(如SIP INFO)时记录客户端本地时间T1，服务器接 到请求后，将服务器本地系统时间T2放到响应消息(如200 OK)中，客户 端在接到响应消息时获取当时客户端系统时间T3，则客户端和服务器的系 统时间差值可以近似为：(T1+T3)/2-T3，即为客户端发送请求时的时间与 接到响应时的时间的均值和服务器在响应中返回时间的差值。参照图14， 客户端在第一时间T1发送实时请求到服务器，该请求在网络中耗时为X， 服务器将自身的系统时间即第二时间T2在响应中返回给客户端，耗时为Y， 客户端在第三时间T3接收到该响应。如果X和Y差不多或者值很小，则计 算出的客户端和服务器的系统时间差值就会比较精确。
注意选择的请求和响应消息最好具有很好的实时性，即服务器可以近似 实时的返回响应，不需要花较多时间进行处理，如服务器的处理时间最好不 超过1秒。服务器如果需要一定时间处理请求消息，则其返回的时间应当取 服务器处理期间的中间时刻值，而最好不是接到请求消息的时间或者发送响 应消息的时间。这样得出的差值其精确度取决于从客户端到服务器的请求消 息与从服务器到客户端的响应消息在网络中传输的时间差异，实际上传输时 间很短，而且来回传输经过的网络基本相同因此差异很小。这样不仅充分考 虑到了消息在网络中的传输时间，也考虑了服务器的处理时间，使得出的差 值更加精确，从而同步效果更好。另外也可以简单的通过RFC 868所定义的 时间协议使客户端获得服务器的系统时间。
参照图15，下面再结合流程图进行举例描述：
步骤1501，第一客户端使用SIP PUBLISH发布方法发布媒体信息事件包到 服务器，媒体信息中包括以服务器的系统时间为准的媒体播放开始时间。
步骤1502，服务器通过SIP NOTIFY通知方法向第二客户端发送第一客户 端发布的媒体信息事件包。
步骤1503，第二客户端收到媒体信息事件包后，根据自己系统时间与服务 器系统时间的差值计算出实际的播放进度。
步骤1504，第二客户端根据实际的播放进度进行同步处理。
第十实施例描述微型博客网站与呈现业务或即时通信业务的互通。用户 通过手机、计算机等终端发布的微型博客信息实际上也可以同时作为呈现信 息，具体可以如下实现：
微型博客服务器接收用户发布的信息，包括文字信息和图片信息等。然 后将这些信息放入相应的呈现信息元素中，如：

   very yellow，very violent

其中微型博客元素“microblog”中可以包括文本信息如“text”，还可 以包括图片信息如“picture”等子元素。微型博客服务器将呈现信息元素包 含在呈现信息事件包中，将其通过SIP PUBLISH方法或XCAP(XML Configuration Access Protocol，XML配置访问协议)协议发布到呈现服务器 或即时通信服务器。
另外微型博客服务器记录了用户所设置的SIP标识，即呈现业务或即时 通信业务的用户标识，如″sip:usera@example.com″，也可以是数字或电话号 码等标识。微型博客服务器在发布呈现信息时，将用户的标识包含在呈现信 息文档中。呈现服务器或即时通信服务器在接收到该微型博客呈现信息后可 以根据所述的用户标识将其与该用户其他的呈现信息进行合并，然后分发给 该用户呈现信息的订阅者。这样用户可以在发布微型博客信息的同时也将其 作为呈现信息发布，一举两得，节省了时间和操作步骤。
参照图16，下面再结合流程图进行举例描述：
步骤1601，微型博客服务器接收用户发布的信息。
步骤1602，将这些信息转换为相应的呈现信息元素。
步骤1603，通过SIP PUBLISH方法或XCAP协议发布信息到呈现服务器 或即时通信服务器。
第十一实施例主要描述了具有位置属性的信息记录的情形。实际上微型 博客还可以作为普通民众发布新闻消息即进行报料的平台，用户可以通过短 消息，多媒体消息或网页等将新闻事件的信息发布到微型博客网站，这种方 式使新闻传播更加及时和直接。为了将用户发布的报料信息与其他普通信息 进行区别，可以在通过在发布信息中增加报料功能标识。举例如下，如用户 通过短消息发布的信息为“报梅林关堵车了”，则服务器接收到该信息后， 检测到该信息的以报料功能标识“报”开始，则将报料功能标识后续空格之 后的信息内容部分“梅林关堵车了”保存，并标记该保存的信息记录为报料 信息。
如果用户通过网页发布报料信息，则在提供给用户输入报料信息的文本 框中设置缺省的初始内容为报料功能标识如“报”，这样用户就不用自己再 输入了。其他的一些特殊信息的输入也可以采用这种方式，如备忘录信息的 输入，在提供给用户输入备忘录信息的文本框中设置缺省的初始内容为备忘 功能标识如“*”或“备”等。
很多新闻事件都是和位置相关的，特别是普通用户进行报料的事件，但 用户发布的报料信息中可能没有提供位置信息或者提供的位置信息不准确。 另外用户对自己发布的信息有时也希望能记录一下自己发布信息时的位置， 可以仅供自己或某些好友查看已发布信息的位置属性。因此如何为用户发布 的信息添加位置属性信息，是个值得解决的问题。
微型博客服务器可以在接收用户发送的信息之后，根据发送信息者在网 站注册绑定的手机号码，向定位系统发送位置查询请求，位置查询请求中包括 该用户的手机号码。然后接收定位系统返回的手机号码对应的当前位置信息， 根据所述的当前位置信息确定位置属性。由于位置信息涉及用户的隐私，因此 用户一般会在定位系统中设置授权微型博客网站可以获取自己的位置信息，还 可以设置所提供的位置信息的精度等。微型博客服务器向定位系统发送位置查 询请求中可以携带微型博客的业务提供商SP标识，定位系统根据该SP标识 确定是否该服务器有获取用户位置信息的权限，如果有则提供相应精度的位 置信息。定位系统也可以同时返回多种精度的位置信息，而微型博客服务器 根据用户的设置向不同的信息查看者提供相应精度的位置信息，如向非好友 用户提供城市信息，向好友提供更精确的区域信息，而自己则可以查看精确 的坐标信息等。
另外短消息中心或多媒体消息中心在收到发送的信息后，向发送的信息的 手机号码对应的归属位置寄存器HLR发起位置查询请求，并将获得的位置查询 结果插入到所述信息中，然后转发给微型博客服务器，微型博客服务器根据所 述信息中的位置查询结果确定位置属性。如用户终端通过短消息或多媒体消息 发送的原始的文字信息为“报五辆车撞在一起了”，则短消息中心或多媒体消 息中心通过移动应用部分MAP(Mobile Application Part)协议如 MAP_Any_Time_Interrogate请求从HLR查询到位置信息即拜访小区标识 (Cell-ID)，然后翻译成可以直接应用的经纬度数据或位置名称信息，将经纬度 或位置名称插入到原始的文字信息中，如“报五辆车撞在一起了/！深圳南山”。 此处将位置信息插入到原信息的最后，并在位置信息前增加位置标识符“/！”， 使其与普通的文字信息内容进行区别。短消息中心或多媒体消息中心将插入了 位置信息的信息发送给微型博客服务器，微型博客服务器从中解析出所包含的 位置信息，然后将信息内容部分“五辆车撞在一起了”和位置信息一起保存。 注意根据用户的位置权限设置，即使可以查询一条信息的内容，但可能也不能 查看相应的位置信息。当然对于一些精度较低的位置信息，用户可以不限制查 看权限。
还可以简单的根据发送信息者的IP地址确定位置属性。如用户客户端通过 网页发布信息到服务器，则服务器获取客户端的IP地址，通过互联网的WHOIS 服务，一般可以获取到该IP地址所归属的城市，可以将城市名称作为信息的位 置属性。
类似的，根据发送信息者的电话号码的归属地确定位置属性。如在中国手 机号码的号段或电话号码的区号与城市有固定的对应关系，可以将电话号码的 归属城市名称作为信息的位置属性。
如果想要发布信息时，同时搜索出与发布信息的位置属性相匹配的信息 记录，则可以在发布时，在信息库中检索位置属性相同或相近的信息记录。 如同一城市或行政区名称，或者根据位置的经纬度坐标计算出的距离在预置 范围之内等。另外当一个信息浏览者向服务器获取信息时，服务器可以首先 获取信息浏览者的位置信息，然后在信息库中检索与其具有相同或相近位置 属性的信息记录，并将匹配的信息记录返回给信息浏览者的客户端。
用户在注册时一般填写自己生活的城市或地区，但这可能不是用户发布 消息时所在的城市或地区。微型博客网站可以提供按区域位置信息浏览方 式，如在网页上提供各个省或地区的位置超链接，对应在不同省或地区的用 户所发布的信息记录。当用户点击某个省或地区如“广东”位置超链接后， 服务器向浏览器返回位置属性与“广东”相匹配的信息记录。并且可以进一 步显示该省或地区内的城市超链接，如“深圳”位置超链接，对应位于该城 市内的用户所发布的信息记录，以此类推可以精确到“行政区”等。服务器 可以计算每个位置的当日所发布的信息记录总数量，在生成的向浏览器提供 的页面中的每个位置名称后显示对应的信息记录总数量，如果某个位置对应 的信息记录数量为零，则不显示该位置名称。参照图17，左侧为信息记录 显示区域D1，显示与选定位置匹配的信息记录，右侧显示当前位置包含的 子区域超链接如“福田区(56)”D2，其中的数字表示该位置区域对应的信息 记录总数量。
可以将用户的报料信息集中在一起显示，如增加“报料”子页面。参照图 18，为观察某个用户如“用户A”时的浏览器显示的页面，其中将用户A相关 的消息分为了几类分别显示，如“消息”C1，“和好友的消息”C2，以及“报 料”C3等。当点击“报料”C3时，在信息记录显示区域C4中显示用户所发送 的报料信息，可以按发布时间的先后次序对信息记录排序。
参照图19，下面再结合流程图举例描述对信息浏览者进行位置属性匹配的 情形：
步骤1901，信息浏览者向服务器请求获取信息记录。
步骤1902，服务器获取信息浏览者的位置信息。
步骤1903，在信息库中检索与其具有相同或相近位置属性的信息记录。
步骤1904，并将匹配的信息记录返回给信息浏览者的客户端。
可见本实施例通过为信息记录生成并保存位置属性，使用户可以获得与自 己位置匹配相关的信息。
更一般的，实际上对于没有确定对象的言论或自言自语，都适合发布在微 型博客中，如报料等，还有用户也可以在微型博客发布自己的愿望，表达自己 想要的事物等。参照图18，具体实现可以增加一个类似“报料”的“愿望”子 页面C6，集中显示用户所发布的“愿望”信息，用户发布的信息中包括与“愿 望”相应的功能标识，服务器据此识别信息类型，并将信息类型和信息内容一 起存储在信息库中。这种“愿望”信息比其他信息更有价值，因为这一般揭示 了用户的需求，利用这些信息可以选择匹配适当的广告信息提供给用户。除了 用明确的功能标识识别信息类型外，还可以通过语义分析确定是否为“愿望” 类型的信息，如用户发布信息“想换个手机”，通过其中的表达意愿的“想”关 键字，以及后续紧跟的动词和名词，可以确定该信息为“愿望”类型的信息， 服务器存储这条信息时同时将识别出的“愿望”类型一起存储。该信息发布后， 服务器可以将与“手机”相关的广告信息返回并呈现在信息发布后的页面中。 类似的还可以增加一个“问题”子页面C5，用户可以发布自己的问题信息，而 其他用户可以通过回复该问题信息来回答问题。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分步 骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算 机可读存储介质中，该程序在运行时，执行上述实施例方法中的全部或部分 步骤。上述提到的存储介质可以是只读存储器，磁盘或光盘等。
如图20所示，微型博客服务器可以包括：信息接收单元E1，用于接收 用户客户端所发送的信息，并将其记录到信息存储单元E3，通知搜索匹配 单元E2对信息存储单元E3中的信息记录进行搜索匹配；信息存储单元E3， 用于记录信息接收单元E1所接收的信息，对应上述实施例中的信息库，用 数据库来存储信息记录；搜索匹配单元E2用于对信息接收单元所接收的信 息在信息存储单元E3中搜索相匹配的信息记录，将匹配的信息返回给客户 端。
如图21所示，服务器进一步还可以包括自动标注单元E4，用于对信息 接收单元E1所接收的信息进行自动标注，然后将信息以及自动生成的标签 一起保存到信息存储单元E3。还可以包括虚拟机器人单元E5，用于接收用 户利用即时消息工具向虚拟机器人发送的即时消息和/或呈现信息，并将其 内容保存到信息存储单元E3，通知搜索匹配单元E2对信息存储单元E3中 的信息记录进行搜索匹配，将匹配信息通过即时消息返回给客户端。
如图22所示，应用程序信息共享工具即客户端可以包括：信息搜集单 元F1，用于搜集用户终端中运行的应用程序的信息；信息发布单元F2，用 于将信息搜集单元F1所搜集的应用程序信息发布出去；信息接收单元F3， 用于接收其他用户的所发布的应用程序信息；应用启动单元F4，根据信息 接收单元F3所接收的应用程序信息启动相应的应用程序。
如图23所示，应用程序信息共享工具还可以包括查询单元F5，用于对 信息接收单元F3所接收的应用程序信息进行搜索。应用程序信息可以是媒 体信息，还可以包括下载单元F6，用于根据查询单元F5获得的搜索结果下 载相应的媒体资源文件。还可包括同步播放单元F7，用于根据媒体信息中 的播放时间信息和下载单元F6获取到的媒体资源文件进行同步播放处理。
通过搜集应用程序信息并在结构化后进行共享发布，利用搜索技术使用 户可以发现使用类似应用程序的其他用户，并可以根据结构化的应用程序信 息进入相同或相似的应用场景界面。另外通过传送包含播放时间信息的媒体 信息，并优选地使用服务器侧的系统时间，使不同客户端之间可以很精确的 进行媒体播放的同步处理。利用搜索技术还可以查询并下载相应的媒体资源 文件。
关于微型博客服务器和应用程序信息共享客户端中的一些具体处理细 节，可以参照上述的几个实施例，此处不再赘述。微型博客服务器可以是即 时通信服务器，应用程序信息共享客户端可以是即时通信客户端。
显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本 发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要 求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。