存在使得用户能够通过计算机网络进行通信的各种技术，无论所讨论的网络是因特网还是诸如公司内联网的另一种类型的网络。这些技术包括即时消息传递(IM)、语音呼叫(如互联网协议语言(VoIP)呼叫)、视频呼叫、共享静态图像(图片消息传递)、共享视频剪辑(视频消息传递)以及共享一方的地理位置。
用户的人身安全是一个问题，因此这种通信系统通常基于联系人的原则工作。这意味着系统通常在服务器上(其中，这里的服务器可以指包括位于一个或多个地理位置的一个或多个服务器单元的逻辑服务器)维护每个用户的联系人列表。联系人列表是所讨论的用户接受作为联系人的通信系统的其他用户列表。联系人和非联系人被授予不同的权限。特别是，其他用户可以与给定用户通信的方式以及他们可以查看有关该用户的信息是受限的，直到被接受作为联系人。
例如，作为默认设置，可允许其他用户发送呼叫请求以发起语音或视频呼叫，但不能将IM消息发送给给定用户，直到该用户已接受其他用户作为联系人为止。其他限制也可能适用。例如，用户的在场状态、地理位置、状态消息(有时也称为“情绪消息”)以及来自用户简档的某些信息可能无法对其他用户可用，直到他们被接受作为联系人。在某些情况下，这些权限可以通过用户设置进行更改。
为了发送联系请求，请求用户使用通信系统的搜索工具搜索期望的接收方用户，然后假设找到所讨论的用户，请求用户选择向接收方发送联系请求。当接收方用户接收到联系请求时，向该用户呈现提供关于如何处理联系请求的显式选项的按钮，例如，接受，阻止或忽略。
技术实现要素：
还希望尝试最大化可以在网络中的用户之间建立的潜在连接的数量，以便增加系统的效用。但是，基于联系人的模型实际上限制了用户之间可用连接的集合。因此存在冲突：一方面需要保护用户的安全性，但另一方面希望尝试在用户之间的互联性方面最大化系统的效用。在此确定，尽管出于安全目的应该保留基于联系人的模型，并且虽然在某种程度上基于联系人的系统将总是在连接性方面施加一些限制，但仍然有通过移除接受彼此作为联系人的用户的障碍来有助于构建更完整的可用连接的图表的余地。
特别地，即使接收用户事实上可能知道发送联系请求的用户，并且有时甚至可能已经通过非限制性通信模式之一(例如，VoIP呼叫)通过系统与该用户进行通信，但是联系请求通常被被动忽略(与接收用户显式选择忽略该请求相反)。本公开提供了一种系统，其保留联系人模型，但提供了用于形成联系人并由此增加系统的总体连通性的更流畅的机制。
根据在此公开的一个方面，提供了一种方法，该方法包括：从第一用户终端第一用户访问通信系统，用于经由网络与其他用户终端的多个其他用户进行通信，其中该通信系统维护第一用户的联系人列表，所述联系人是其他用户中的已经被第一用户接受作为联系人的用户。由此，联系人被授予关于经由通信系统与第一用户通信的一个或多个权限，所述一个或多个权限未被授予所述其他用户中的不在联系人中的任何用户。在第一终端上的用户界面的对话区域中，提供了消息传递字段，其中第一用户可以输入要传送给其他用户中的选定用户的内容(例如IM消息、图片、视频剪辑等)作为通过所述通信系统进行的双向对话的一部分。该方法还包括在第一用户终端处接收来自第二用户终端的第二用户的联系请求，第二用户是其他用户中的还不是第一用户的联系人中的一个联系人的用户，并且联系请求请求第二用户成为所述联系人中的一个。此外，根据本公开，响应于用户通过消息传递字段回复所述消息，自动接受联系请求，从而接受第二用户作为第一用户的所述联系人中的一个。
因此，当第一用户与第二用户交互时，这被视为第二用户作为联系人的隐式接受。有利地，这打破了在用户之间形成连接的障碍，同时保留了基于联系人的模型。
例如，在联系请求中接收到的消息可以显示在对话窗格中，几乎就像它是任何其他IM消息一样，并且如果第一用户使用通过IM字段(该字段与一般用于IM对话的是同一字段)输入的IM消息进行回复，则系统推断第二用户被第一用户所知，因此可以添加作为联系人。在实施例中，第一用户还可以通过回复诸如图片消息、视频消息或共享位置之类的其他类型的消息来使得第二用户被接受。
根据这里公开的另一方面，提供了一种在计算机可读存储装置上体现的计算机程序产品，并且被配置为当在一个或多个处理器上运行时使得所公开的方法被执行时。计算机程序产品可以采取在第一用户终端上运行的客户端应用的形式。可替代地，计算机程序产品可以采取网络客户端的形式，用于托管在服务器上，以便由第一终端通过互联网访问。
根据这里公开的另一方面，提供了一种配置成执行根据这里公开的任何实施例的方法的网络元件。网络元件可以是第一用户终端，或者可以是服务器(包括一个或多个地理位置处的一个或多个服务器单元)。
提供该发明内容以便以简化的形式来引入下面的具体实现方式中进一步描述的概念的选择。该发明内容不旨在确定所要求保护的主题的关键特征或主要特征，也不旨在用于限定所要求保护的主题的范围。所要求保护的主题也不限于解决本文提到的任何或全部缺点的实现方式。
附图说明
为了帮助理解本公开并示出如何实施实施例，通过示例的方式参考附图，在附图中：
图1是通信系统的示意图，
图2是客户端应用的用户界面的示意模型，以及
图3是客户端应用的用户界面的另一示意模型。
具体实施方式
图1示意性地示出了根据这里公开的实施例的通信系统100。该通信系统包括多个用户终端102，每个用户终端102被配置为连接到计算机网络101，并且每个用户终端都安装有通信客户端应用103的相应实例。每个用户终端102还被至少一个相应的用户106使用。在图1中，为了说明的目的，示出了五个用户终端102a-e及其各自的客户端103a-e和用户106a-e，但是应该意识的是，在本公开涵盖的其他情况下可能涉及不同数量的用户终端102。网络101优选是基于分组的网络。在实施例中，它可以采取诸如通常被称为因特网的广域互联网络的形式。可替代地，网络101可以采用诸如公司内联网、移动蜂窝网络或无线局域网(WLAN)或者这些和/或因特网中的任何一种的组合之类的另一种类型的网络的形式。
每个用户终端102可以采取各种不同形式中的任何一种，例如台式计算机、笔记本电脑、平板电脑、智能手机、智能手表、智能眼镜、智能电视、机顶盒或会议室电话单元(并且不同的用户终端102不一定需要采取彼此相同的形式)。因此请注意，这里使用的术语“计算机”不限于传统的台式或膝上型计算机。
通信客户端103各自安装在其各自的用户终端102的计算机可读存储装置上，并且被安排用于在相应用户终端102的相应处理装置上执行。存储装置可以采取在一个或多个存储器单元中实现的一个或多个存储介质(例如，磁性存储器、电子存储器或光学存储器)的形式。处理装置可以采取一个或多个处理单元的形式。每个通信客户端103被配置为使得能够与在一个或多个其他各个用户终端102上运行的一个或多个其他通信客户端103建立通信会话。然后，每个用户终端102的用户能够向参与会话的用户终端102中彼此的用户彼此发送消息。在实施例中，消息可以包括任何一种或多种“传统”类型的消息，诸如：IM消息，(发送用户语音的)实时语音(例如，VoIP)流和/或现场视频流(例如，发送用户的头和肩部拍摄)。可替代地或附加地，消息可以包括一个或多个其他类型的消息，诸如：静止图像(图片消息传递)，预先记录的视频剪辑(视频消息传递)，预先记录的音频剪辑(例如语音邮件)，共享的地理位置(例如，如由诸如GPS的定位系统检测到的)，屏幕共享流，远程幻灯片表示，和/或电子或虚拟白板流。
在实施例中，通信系统101包括连接到网络101的服务器104，服务器104被布置为提供通信服务，经由该通信服务至少部分地进行通信会话。在这样的实施例中，来自任何给定的一个用户的消息是从发送用户终端(例如，102a)发送到服务器104，并且服务器104被配置为将消息转发到接收方用户终端102b-e中的每个。然而，可替代地，可以基于对等(P2P)拓扑来发送消息，在这种情况下，为了将消息转发到其目的地而不需要服务器104。
还要注意，在又一些实施例中，系统不需要包括安装在每个用户终端102上的通信客户端103。例如，可替代地，用户终端中的一个、一些或全部可以替代地安装有通用web浏览器，其可操作来访问在服务器104上托管的客户端应用的基于web的版本(“web客户端”)。在这种情况下，所描述的功能性可以由web客户端而不是本地安装的客户端(即，本地地安装在个人用户终端102上的客户端)来实现。或者更一般地，本文公开的功能性可以通过本地客户端应用103(在每个用户终端102上)和/或服务器托管的功能性(例如web客户端)的任何组合来实现。为了简洁起见，每当描述下面的功能性时，这方面的各种选项都不会被重复，但是应该理解，这些选项始终适用。
不管这些消息是否经由服务器104发送，或者是否它们是对等发送的，并且无论本地客户端是否安装在每个用户终端102上或者是否使用了服务器托管的客户端，服务器104还可以被布置为提供与通信服务相关联的附加功能性。具体来说，服务器104为每个用户106维护联系人列表105。给定用户的联系人列表105是该用户已经接受作为联系人的其他用户的列表。这将在稍后更详细地讨论。注意：将联系人列表集中存储在服务器104不是必要的。相反，给定用户的联系人列表可以存储在用户自己的用户终端102上。然而，这意味着，在该用户从不同设备102登录时，联系人列表不一定可用于他或她。作为另一种替代方案，联系人列表可以存储在分布式P2P数据库中。但是，以这种方式存储他们的个人详情用户可能不舒服。
服务器104可以可选地还为每个用户106保存附加的补充信息，诸如相应的用户简档、相应的状态消息、相应的存在状态和/或相应的位置信息。该补充信息通过网络101从服务器104使得可用于用户106b-e中的至少一些其他用户。在实施例中，这些信息中的一些或全部可能仅能够对于所讨论的用户已经接受作为联系人的服务的任何其他用户可用。
每个用户的简档中的信息可以包括例如以下各项中的任何一个或多个：相应用户的电子邮件地址，相应用户的简档图片，相应用户的居住地点，和/或相应用户的时区或本地时间等。用于给定用户的相应简档信息通常由该用户自己经由相应的客户端应用103设置，该客户端应用103将其发送以存储在服务器104处。
状态消息有时也被称为“情绪消息”。它是由相应的用户自己对其当前状态(例如，“感觉良好，因为今天太阳出来了”或“OOO，在1月25日星期一回来”)编写的简要陈述。
存在状态指示用户在通信系统内通信的可用性，例如，从包括以下中的两个或更多个的集合中选择：免打扰(DND)，离线，不活动或在线。在实施例中，存在状态至少部分地自动确定，例如，通过检测用户何时未登录并因此离线，和/或通过检测用户是否没有与他或她的用户终端102交互(例如，没有移动鼠标)，则他或她是不活动的。DND通常由相应用户手动设置。如果用户既不是离线也不是不活动的，并且没有选择DND，则可以自动确定在线状态。一些可能的存在状态可以被客户端应用103检测到并且被报告给服务器104，例如，用户是否处于非活动状态。其他可能的状态可以由服务器104直接检测，例如，用户是否离线。客户端103或服务器104可以检测到一些可能的状态，例如，用户是否选择了DND，和/或他或她是否在线。
位置信息可以由相应的用户106手动设置，但是在实施例中，基于一个或多个定位技术，例如诸如GPS或Galileo的基于卫星的定位技术，或者通过参考诸如移动通信系统的蜂窝塔、室内定位系统的锚节点或Wi-Fi热点等的其他无线节点，来自动地检测位置信息。客户端103检测相应用户终端102的位置并将其报告给服务器104。
注意：关于这个补充信息(例如，简档信息、状态消息、存在状态和/或位置信息)，将其集中存储在服务器104不是必需的。然而，与关于联系人列表105所讨论的类似考虑可以适用。即该信息可以存储在用户自己的用户终端102上，但是这意味着当他或她从不同的设备102登录时该信息对于该用户不一定可用；或者信息可以存储在分布式P2P数据库中，但以这种方式存储他们的个人详情用户可能不舒服。
用于给定用户的联系人列表105记录用户已经接受作为联系人的通信系统的其他用户中的哪一个。这进而确定根据他们每个是否是联系人，关于经由通信系统与用户进行通信，其他用户被授予什么权限。作为说明，将从第一用户终端102a的第一用户106a的联系人列表105的角度来描述以下内容，其中第一用户106a正在从第二用户终端102b的第二用户106b接收联系请求，但是可以意识到，类似的教导可以适用于关联任何用户组合。
存在联系人列表确定的至少两种可能的权限类别。第一类别定义第二用户106b可以与第一用户106a建立的通信的类型，或者实际上第二用户106b是可以与第一用户106a通信还是根本不可以与第一用户106a通信(至少经由所讨论的通信系统)。例如，在实施例中，第二用户106b被允许发送呼叫建立请求以开始与第一用户106a的语音或视频呼叫(例如，VoIP呼叫)，而第二用户106a并没有被接受为第一用户102a的联系人。这意味着第一用户的终端102a上的客户端103a将使其“振铃”以提醒第一用户106a来电，第一用户106a可以以他或她对联系人的相同方式应答来电。然而，在实施例中，第二用户106b在未首先被接受为第一用户106a的联系人的情况下不能向第一用户106a发送其他类型的通信。例如，第二用户106b可能不被允许向第一用户106a发送IM消息、图片消息、视频消息、语音邮件和/或共享位置，直到他或她被接受为第一用户106a的联系人。通常，对于非联系人可以强制允许和不允许的通信类型的任何组合。
如所提到的，系统还可以存储关于第一用户106a的补充信息，诸如相应的用户简档、状态消息、存在状态和/或位置信息。该补充信息涉及经由通信系统与第一用户106a的通信，因为其经由相同的通信系统被访问并且提供补充与第一用户106a进行通信的体验的信息。例如，存在状态指示用户是否可用于与之通信；并且用户简档、状态消息和/或位置向与第一用户106a的通信添加上下文(例如，与第一用户106a进行通信的体验可以通过了解关于用户的个人信息或者知道他或者她一天过得很糟糕，或者他或她目前在某个城镇或国家而成形或被告知)。
第二类权限因此定义第二用户106b可以经由通信系统查看第一用户106a的哪些补充信息。例如，在实施例中，第二用户106b不被允许查看第一用户的状态消息、存在或位置，直到第二用户106b已被接受为第一用户106a的联系人为止。在实施例中，在未被接受为第一用户106a的联系人的情况下，可以允许第二用户106b经由通信系统查看第一用户的简档信息的某些选定部分，而简档信息的其他部分可以保持不可用直到被接受作为联系人。一般来说，对于非联系人可以强制执行可见和不可见补充信息的任何组合。
在一些实施例中，第一用户的联系人和非联系人的权限可以至少部分地由可由第一用户106a自己设置的一组用户偏好(即设置)来定义。这些设置可以存储在服务器104处或本地地存储在用户自己的相应用户终端102a上(其中，与基于服务器或非基于服务器的存储位置类似的考虑可以适用，如关于联系人列表和这样的使用用户简档的补充信息所讨论的)。因此，维护联系人的第一组权限和非联系人的第二组权限(其中第二组可以是第一组的子集，或者可以与第一组重叠)，其中这些权限中的一个或多个可以由第一用户106a设置为用户偏好。这些可设置的权限可以包括第一类别中的一个或多个权限，即哪些通信类型不被允许用于非联系人，和/或第二类别中的一个或多个权限，即哪些类型的补充信息对非联系人可见(例如，简档信息、存在等)。
在实施例中，某些偏好可具有默认设置，默认设置当第一用户的客户端应用103a首次安装在第一用户终端102a上时、或者当第一用户106a首次向通信系统注册时在适当的位置，但是第一用户106a可以稍后将其覆盖。例如，默认设置可能是非联系人可以向第一用户106a进行语音和视频呼叫，但不能发送IM消息、图片消息、视频消息或留下语音邮件。一般而言，任何默认组合都是可能的。
本公开使用如上所述的基于联系人的模型以防止系统变得开放滥用，但同时提供更流畅的机制来接受联系人以增加用户之间可用连接的数量。
通过比较，首先关于图2描述现有机制。这示出了在第一用户的终端102a上运行的客户端应用103a(或者从第一用户的终端102a访问的web客户端)的前端用户界面(UI)200。UI 200包括诸如本地用户窗格201、历史窗格202和对话窗格204的多个UI区域。本地用户窗格201示出关于第一用户106a(UI被显示在其上的终端102a的用户)的信息，例如他或她的名字、用户名、简档图片和/或存在状态。历史窗格202示出第一用户106a已经参与或在过去的特定时间窗口内接收到的对话和联系请求的列表。对话窗格204示出当前在历史窗格202中选择的对话或联系请求。UI 200还可以包括用户可操作的联系人控件206(例如标签或按钮)和用户可操作的历史控件208(例如，再次是标签或按钮)。致动(例如，点击或触摸)联系人控件206调出第一用户的联系人的列表105，他或她可以从该列表选择来与这些联系人建立通信。致动(例如，点击或触摸)历史控件208调出历史窗格202。在所示的布置中，当联系人控件206被致动时，将显示联系人列表窗格来代替历史窗格202，反之亦然，但是不一定必须这样。
对话窗格204是第一用户实际进行与其他用户的双向对话(经由所讨论的通信系统)的地方。当另一用户向第一用户106a发送消息时，其出现在对话窗格204中。此外，对话窗格204包括消息传递字段210，第一用户可在其中输入要发送给对话的另一端的(多个)用户106的消息。在所示的示例中，对话窗格204包括对第一用户106a的便条212，邀请他或她在消息字段210中键入IM消息(一种基于文本的消息)，由此使用户能够与其他用户进行IM对话。例如，这可以显示在消息传递字段210中，可能是黯淡的。然而，请注意，此处使用的术语“对话”不限制被交换的消息的类型。例如，作为对话的一部分交换的消息可以包括以下中的任何一个或多个：基于文本的消息(例如IM消息)，现场语音和/或视频流(语音和/或视频呼叫)，静止图像(图片消息)，预先录制的音频剪辑(语音邮件)，预先录制的视频剪辑(视频消息)，共享位置，幻灯片放映，屏幕共享，来自电子或虚拟白板的内容或此类消息类型的任意组合。例如，第一用户106a可以将视频剪辑粘贴或拖放到消息传递字段210中，并且剪辑将通过网络101发送给另一端的用户。任何这样的交换在这里可以被称为“对话”。
当第一用户终端102a从第二用户106b接收到联系请求时，一些专用UI元素在对话窗格204中被呈现给第一用户106a。这些包括到第一用户106a的通知214、216，即第二用户106b请求成为联系人(例如通过真实姓名或用户名来标识第二用户106b的通知)；以及还有关于对请求做什么的两个或更多显式的用户可选择选项217i、217ii。这些显式选项包括至少一个接受选项217i和一个或多个其他否定选项217ii，其中一个或多个其他选项可以包括下列中的一个或多个：拒绝，忽略，阻止和/或报告为垃圾邮件。例如，这些选项217i、217ii可以采取屏幕上按钮的形式。因此，第一用户106a必须做出关于是否将第二用户106b包括在联系人列表105中的他或她的联系人中的主动决定。如果第一用户106b什么都不做，则第二用户106b永远不会被添加为联系人，并且联系请求在第一个用户的历史记录中保持为永久或至少是长期的项目。
然而，尽管联系人模型对安全性有益，但在此确定出，上述特定机制还用于不适当地限制用户之间的可用连接的数量，因此就进行的通信量以及进行这些通信的端点的组合数量而言限制了系统的效用。特别地，已经确定，接收用户106a简单地被动地忽略了(而不是主动选择忽略选项)许多联系请求，即使该用户实际上可能知道请求用户106b，并且/或者甚至可能已经继续在不接受联系请求的情况下通过仅使用允许非联系人的通信模式之一(例如，VoIP呼叫)作为替代与他或她进行通信。
图3示出了根据本公开的实施例的更“无摩擦”机制。除非另有解释，图3中的元件与图2中所示的元件相似。
如图3所示，从第二用户106b接收的联系请求的有效载荷包含由第二用户106b编写的消息302。该消息302在对话窗格204中被显示给第一用户106a。通知307也可以被显示在对话窗口中，但是仅仅告诉用户第二用户106b向他们发送了消息，而不是明确地提醒第一用户106a需要接受联系请求这一事实。此外，不需要任何按钮或其他这样的专用控件217i、217ii请求第一用户显式地接受或不接受联系请求。相反，第一用户106a可以通过简单地使用通过对话窗格204的消息传递字段210输入的另一消息来回复第二用户的消息302来隐式地接受联系请求，就好像这是在已经接受彼此作为联系人的用户之间的对话中的任何其他消息交换一样。客户端应用103或服务器104自动检测到第一用户106a已经经由第一用户终端102a上的消息传递字段210回复给第二用户106b，并且据此推断第一用户106a愿意与第二用户106a通信，因此接受他或她作为联系人。即第一用户106a与第二用户106b交互的行为被视为第二用户106b作为联系人的默认接受。因此，响应于第一用户106a向在第二用户的联系请求中接收到的消息302发送的回复，第二用户106b被自动地添加到第一用户的联系人列表105中，即没有第一用户106c专用以接受第二用户106b作为联系人的行为的单独用户交互。
给第一用户106a的便条304也可以显示在对话窗格204中，以通知第一用户106a回复消息302将被视为第二用户106b作为联系人的隐式许可。例如，这可以显示在消息传递字段210中，可能是黯淡的。
在实施例中，与第二用户106b的任何交互都被自动视为隐式接受联系请求。
可替代地，客户端应用103或服务器104(或它们的组合)可被配置为自动处理由第一用户106a通过消息传递字段210发送的回复的实际内容，并且基于此来做出是否回复相当于接受的决定。例如，客户端103或服务器104可以被配置为识别第一用户的回复中的一组预定否定词或短语中的一个或多个的存在，例如，“走开”或“你是谁？”，并且响应于检测到这些中的任何一个，第二用户106b将不会自动添加为联系人(或者甚至针对某些词或短语子集自动阻止或报告为垃圾邮件)。并且/或者，客户端103或服务器104可以被配置为识别第一用户的回复中的一组预定肯定词或短语中的一个或多个的存在，例如“很高兴收到你的来信”，并且响应于检测到任何这些第二用户106b将被自动添加为联系人。
作为另一种可能性，客户端103或服务器104可以被配置为将自然语言处理技术应用于第一用户的回复，以尝试提取回复的实质含义而不是依赖于(或者仅依赖于)检测预定的短语。然后，取决于所提取的含义是肯定还是否定，可以自动添加或不添加第二用户106b(并且在实施例中甚至可以根据所提取的含义被阻止或报告为垃圾邮件)。
另一方面，如果第一用户106a不采取行动，则忽略联系请求。
还要注意，在实施例中，第一用户106a的回复不必是IM消息。在实施例中，以通过消息传递字段210提交的一组可能的消息类型中的任何消息类型的形式的回复可以隐含地引起自动接受，其中所述集合可以包括以下中的任何一个、一些或全部：IM消息或其他基于文本消息，语音或视频呼叫(例如VoIP呼叫)，预先录制的视频剪辑(视频消息)，静止图像(图片消息)，预先录制的音频剪辑(例如语音邮件)，第一用户106c(例如来自基于卫星的定位系统或室内定位系统)的共享位置，幻灯片放映，屏幕共享，和/或来自电子或虚拟白板的内容。
在实施例中，阻止选项306和/或报告为垃圾邮件选项可以浮动在对话窗格204中(例如按钮或超文本)。如果第一用户106b致动阻止选项306，则将阻止第二用户106b发送任何更多的联系请求和通信中的任何其他尝试(例如，请求VoIP呼叫)，或者至少这样的尝试和请求如果进行了也将不被显示给第一用户106b。如果第一用户106a将报告致动为垃圾邮件选项，则不仅如上所述地阻止第二用户106b，而且也触发投诉在服务器104处记录，其中可以分析来自多个用户106的这种投诉从而识别系列垃圾邮件制造者并从系统中删除系列垃圾邮件制造者。
然而，请注意，即使在对话窗格204中显示阻止选项306或报告为垃圾邮件选项的情况下，仍没有用如图2中的与消息传递字段210分开的显式的肯定用户可操作控件217i来提示第一用户106a。即，仍然不使用显式的接受/拒绝或接受/忽略范例等，如在图2的常规情况下那样。
在实施例中，作为抵制滥用的另一替代或额外的预防措施，与可在已接受的联系人之间交换的消息相比，对联系请求中的消息302施加限制。例如，消息302可以被限制为仅包含文本，而不包含任何“丰富的内容”(例如，没有音频、图像或视频；没有文件；没有软件；和/或没有链接)。并且/或者，与联系人之间的正常消息相比，消息长度可能受到限制。例如，消息302可以被限制为某个预定的最大数量的字符，比如200；而在联系人之间的对话中发送的IM消息可能具有更高的限制，例如，1000个字符，或者可能没有任何限制。并且/或者，可以发送联系请求的次数可以被限制到某个预定义的最大数量，例如，五个，而不限制可以在联系人之间发送的IM的数量(或者至少更高的限制)。
在又一些实施例中，第二用户106b在他或她的用户终端102b上在发送联系请求的一侧显示类似的UI 200。在这样的实施例中，可选地，第二用户106b可以能够通过输入消息以通过消息字段210发送给第一用户106a(例如，通过搜索工具或自动推荐特征找到了第一用户106a)来发送联系请求。即，发送用户106b不必通过UI 200显式地选择发送联系请求选项，而是使发送联系请求的体验感觉就像发送正常IM消息一样。这再次为连接用户提供了更加无摩擦的机制，同时保留了基于联系人的安全模型。
然而注意，在实施例中，尽管联系请求302可以在其有效载荷中包含消息302，但联系请求仍然是通信系统的单独的，预先存在的机制，与现有联系人之间交换的IM消息分开。也就是说，上面公开的机制重新使用通信系统的预先存在的联系请求格式，具有比IM消息更小的有效载荷和不同的消息类型ID(并且实际上在实施例中，不同于设计用于在现有联系人之间发送用户内容的任何其他类型的消息的消息类型ID)。
应该意识到，上述实施例仅通过示例的方式进行了描述。
更一般地，根据这里公开的一个方面，提供了一种方法，包括：从第一用户终端，第一用户访问用于经由网络与其他用户终端的多个其他用户进行通信的通信系统，其中，所述通信系统维护所述第一用户的联系人列表，所述联系人是其他用户中的已经被第一用户接受为联系人的用户并且由此所述联系人被授予关于经由所述通信系统与第一用户通信的一个或多个权限，所述一个或多个权限不被授予给所述其他用户中的不在所述联系人之中的任一个；在所述第一终端上的用户界面的对话区域中提供消息传递字段，在所述消息传递字段中，所述第一用户可以输入要传达给所述其他用户中的选择的用户的内容，作为经由所述通信系统进行的双向对话的一部分；在所述第一用户终端处，接收来自第二用户终端的第二用户的联系请求，第二用户是其他用户中的还不是第一用户的联系人中的一个的用户，并且所述联系请求请求所述第二用户成为所述联系人中的一个；以及响应于用户通过消息传递字段回复所述消息，自动接受所述联系请求，由此接受所述第二用户作为所述第一用户的所述联系人中的一个。
在实施例中，联系请求可以包括来自所述第二用户的、与所述消息传递字段相关联地显示在所述对话区域中的消息。
在实施例中，第二用户可发送的联系请求的数量可限于预定的请求数量。
在实施例中，所述一个或多个权限可以包括经由通信系统向第一用户发送IM消息的能力。例如，联系请求中的消息可以被限制为第一预定长度，而IM消息可以被限制为比第一预定长度长的第二预定长度，或者而IM消息的长度可以不受限制。
在实施例中，可以不允许在联系请求中发送的消息包含除文本以外的媒体，而由所述第一用户终端经由所述通信系统从所述第一用户的联系人接收的通信可以包含除了文本之外的媒体。
在实施例中，所述一个或多个权限可以包括经由通信系统发起与第一用户的语音呼叫的权限。
在实施例中，所述一个或多个权限可以包括经由通信系统发起与第一用户的视频通话的权限。
在实施例中，所述一个或多个权限可以包括经由通信系统查看第一用户的存在状态的权限。
在实施例中，所述一个或多个权限可以包括经由通信系统查看第一用户的状态消息的权限。
在实施例中，所述一个或多个权限可以包括经由通信系统查看第一用户的地理位置的权限。
在实施例中，所述一个或多个权限包括根据由所述第一用户针对所述联系人设置的第一组通信偏好，而不是由所述第二用户针对非联系人设置的第二组通信偏好来处理的权限。
在实施例中，在所述第一终端的用户界面上可以不显示关于所述联系请求的接受/拒绝按钮。
在实施例中，由所述联系请求的接收触发，可以在所述对话区域中与所述消息传递字段相关联地包括阻止联系选项和/或作为垃圾邮件报告选项。
在实施例中，由所述联系请求的接收触发，可以将针对第一用户的通知与消息传递字段相关联地显示在对话区域中，向第一用户解释他或她可以通过消息传递字段进行回复来接受联系请求。
在实施例中，消息传递字段可以使第一用户能够将IM消息作为对话的所述内容的至少一部分发送，并且可以使第一用户能够通过利用通过消息传递字段输入的IM消息进行回复来接受联系请求。
在实施例中，消息传递字段可以使得第一用户能够将静止图像作为对话的所述内容的至少一部分来发送，并且可以使第一用户能够通过利用通过消息传递字段输入的静止图像进行回复来接受联系请求。
在实施例中，消息传递字段可以使第一用户能够发送视频消息作为对话的所述内容的至少一部分，并且第一用户可以通过利用通过消息传递字段输入的视频消息进行回复来接受该联系请求。
在实施例中，消息传递字段可以使得第一用户能够共享第一用户的地理位置作为对话的所述内容的至少一部分，并且可以使第一用户能够通过利用通过消息传递字段输入的第一用户的共享位置进行回复来接受该联系请求。
在实施例中，通过消息传递字段输入的任何回复可以接受该联系请求。
可选地，该方法可以包括：包括自动检测第一用户在回复中的内容，其中可以根据检测到的回复的内容来执行对联系请求的所述自动接受。
例如，对所述回复的内容的自动检测可以包括自动检测在回复中是否识别出一个或多个预定词语或短语，并且所述自动接受联系请求可以取决于是否在所述回复中识别出所述一个或多个预定词语或短语中的至少一个来执行。
并且/或者，对所述回复的内容的所述自动检测可以包括自动将自然语言处理应用于回复以提取回复的含义，并且所述自动接受所述联系请求可以根据所提取的含义来执行。
在实施例中，可以在第二终端上的用户界面中提供对话区域，提供消息传递字段，其中第二用户可以输入要传送给第一用户的内容作为经由所述通信系统进行的双向对话的一部分(被接受为联系人后)；并且可以响应于第二用户通过第二用户终端上的消息传递字段向第一用户输入消息而自动发送联系请求。
一旦给出了本文的公开内容，其他变体和使用情况对于本领域技术人员而言会变得显而易见。本公开的范围不受所描述的实施例的限制，而仅受所附权利要求限制。