CN1619564A - 通过共享表示在保护隐私的同时协商进度的系统、方法和服务 - Google Patents

Abstract

一种会议协商系统提供了一种通过将会议协商与会议邀请分开的共享表示，在保护隐私的同时，通过协商进度安排事件进度的新途径。该协商系统集成了所有与安排进度相关的信息，如用户可以开会的时间、地点等，并降低了对可能的会议参加者将时间指定为闲或忙的依赖。因此，该协商系统能够提供比闲或忙更丰富的时间偏好，从而允许可能的会议参加者指定除可用时间以外的偏好。该协商系统支持作为讨论机制的注释和评论，在发出会议邀请之前向会议安排进度者给出反馈。对会议所提供的可能时间是以有界协商的形式提供的；参加者可以根据有界协商选择他们参加会议的最优时间。会议组织者根据由参加者提供的响应确定会议时间。

Description

通过共享表示在保护隐私的同时 协商进度的系统、方法和服务

技术领域

本发明总体上涉及电子日历。更具体地说，本发明涉及用于协商如时间等会议细节的方法，而不需要参加者把对他们的日历或其日历上信息的控制交给会议组织者。

背景技术

会议的安排进度通常充满问题；对所有参与者这个过程都是麻烦和破坏性的。当会议安排进度者对那些希望出席或必须出席的人没有管理手段或其它控制的时候，情况尤其是这样。一种典型的会议安排进度方法是向会议安排进度者希望在特定时间、特定地点参加特定议程的所有人发邀请。因此，邀请呈现出在工作流程结构和语气上都非常正式的形象，这阻碍了关于会议、议程等的必要讨论。经常在邀请发出后，会议安排进度者不得不重新修订邀请并且重发，广播一些微小的改变。

安排会议进度问题的一种传统解决方法是让希望参加会议的每个员工或者人员都张贴一个可以让其它员工或人员在网络上查看的电子日历。希望安排会议进度的人然后就能够看到那些他们希望参加会议的人的电子日历并且将会议时间与参加者的可用时间设置成一致。但是，电子日历由于种种原因通常并不是用户时间的精确反映。许多用户并不维护电子日历。大多数用户并不记录所有的活动，尤其是日常事件(例如，来回上班、午饭、慢跑等)。许多用户不会把例如和医生的约定等敏感信息放到电子日历中，这会影响到他们是否在会议时有空。

即使日历精确地反映了用户时间，但许多问题与个人隐私及对什么时候一个人忙或可以参加会议的信息和时间(忙时间对闲时间)的控制有关。关于他们自己的个人信息，员工有不同的期望隐私水平。信息是否是隐私的与这是谁的信息有关。例如，某人认为他的医疗约定是隐私的，而其他人则认为这是没什么害处的。

即使当信息对个人来说不是隐私的时候，它仍然会是社会敏感的。例如，对申请者的内部工作面试也许是申请者不想让他的组员或者上司知道的信息。张贴在电子日历上的其它员工可见的信息可能会泄露公司安全。例如，电子日历上的会议主题或参加者名单可能会向未授权人员暴露机密信息或泄露未公开的商业策略。另外，员工电子日历的分发会带来对员工时间使用的不故意的描述，这导致同行对时间管理和分配的判断。而且，有些人不希望放弃对他们进度表或就象进度表上所反映的他们自己的控制。

方便会议安排进度的常规方法包括开放日历和日历代理(闲时间访问)的广泛种类。由于会议安排进度者能够看见同事的时间分配并且还可以对同事日历上分配的时间质量或性质产生影响，从而允许会议安排进度者选择一个所有受邀者都能参加的会议时间，因此开放日历提高了协调。

但是，存在大量与开放日历方法相关的隐私和社会问题。这些问题可以通过多种方法来控制，例如，通过访问设置限制什么内容其它人可以看见、创建使用密码和上下文敏感的项来掩盖项的含义、略去私人项及安排日历中的工作时间或假约会的进度来限制可能时间安排进度的闲时间。

一种试图解决安排进度问题的较不开放的方法是把个人日历简化为闲或忙时间。例如，某个员工指定一天中的一部分时间忙，而其它时间是闲的可以用来安排会议进度。尽管这种方法除去了员工日历上特定主题的暴露，但它仍然把对日历的控制委派给其它人。尽管员工在特定时间可能是空闲的，但他可能会有对会议时间的偏好，这种偏好不能由简单的闲/忙指定传达出来。另外，在员工日历上闲或忙时间的指定会允许同事或上司对员工时间管理的干涉。员工又一次暴露了他们宁愿保密的信息。

iCalendar^TM是一种为通过互联网开放地交换日历和调度信息定义了公共格式的对象模型。iCalendar定义了闲/忙时间类型，缺省是忙。这种模型将员工日历上可能的时间类别定义为闲、忙、不能利用的忙或暂时忙。闲时间指其他人可以自由安排进度的时间段。忙时间指已经有一个或多个事件要安排进度的时间段。不能利用的忙指不仅忙而且不能被安排进度的时间段。暂时忙指由于一个或多个事件已经被暂时安排进度因此忙的时间段。

基于闲/忙时间的日历系统尽管是一种有用的模型，但仅与参加者或组织者可以访问的情况一样有效，与各个参加者的日历一样精确。由于日历系统的参加者通常不能保持他们的日历是最近的，因此实现这样的系统时就会引起许多困难。

尽管这种技术已经被证明是有用的，但希望出现其它的改进。因此，所需要的是允许用户协商会议细节而不暴露个人信息的系统、计算机程序产品及相关的方法。这样的方法允许会议安排进度者在发出邀请之前协商会议的细节，从而消除对会议微小改变的广播。对这种解决方案的需求迄今为止一直不能令人满意。

发明内容

本发明满足了这个需求，并且提出了一种用新方法来通过共享表示为安排进度、协商进度同时又保护隐私的系统、计算机程序产品、服务及相关的方法(这里全部称为“此系统”或“本系统”)。本系统集成了所有与安排进度相关的信息，如用户可以开会的时间、地点等。

另外，本系统减少了对可能的会议参加者将时间指定为闲或忙的依赖。因此，本系统使得能够有更丰富的时间偏好而不仅仅是闲或忙，从而允许可能的会议参加者指定除可用时间外的偏好。本系统支持作为讨论机制的注释和评论，在会议邀请发出之前给会议安排进度者反馈。而且，本系统补充了对会议细节的协商，这通常是通过电子邮件、即时消息传送、电话等发生的。

本系统提供了向参加者提供可能的会议时间而不是提前指定会议时间的特征。另外，给会议提供的可能时间是以有界协商的形式提供的，例如，参加者可以从周四或周五，下午2:00到下午5:00的有界协商中选择对他们来说参加会议的最佳时间。此外，本系统是动态的协商对象，与会议组织者和参加者交互来识别会议的最佳时间。

另外，本系统允许对除时间之外的会议的所有方面，如地点、主题、议程等，进行多样性的协商。本系统可以用来协商任何需要参加者出席的事件的任何方面，参加者可以从参加者或其它人的提前输入中受益。例如，本系统可以用来在朋友中组织周末滑雪、钓鱼旅行、扑克之夜或者是参加者还要指定要带的食物项的家常便饭。

本系统将协商与邀请分开。另外，本系统还分散了协商，从会议组织者身上除去了协商的负担。作为代替，会议组织者把这个过程委托给协商对象。每个参加者都与协商对象进行交互，直到确定一个相互满意的时间。本系统的协商过程把会议组织者从管理协商细节中拯救了出来。另外，本系统还使会议参加者能够预订会议组织者的时间而不是会议组织者预订参加者的时间，这给安排会议进度提供了更成功和更少费时的途径。

由本系统调节的协商包括双方或多方。在一种典型的例子中，协商包括一个会议组织者和一些参加者。会议组织者发起与n个参加者的协商；参加者向协商提供他们的输入。在看到协商中所有的集成安排进度信息后，本系统把协商定下来。协商的确定发出这个事件的邀请。

本系统安排一个典型会议进度的协商时间过程在下面的步骤中概述。组织者通过指定已知的会议属性(例如，会议主题、地点、持续时间、参加者)发起协商。组织者还“提供”他愿意开会的时间段，将每个时间段与他对在那个时间开会的希望程度(例如，优选的、可以接受的、不赞成的)联系起来。例如，周一下午是优选的，而周五上午9点到11点是可以接受的。当提供他的时间段时，组织者可以选择查看并考虑他或她自己的日历及如果可以得到的话还有所有参加者闲时间的聚合视图。

当得到未决协商的通知时，参加者就访问该协商。在与协商者后面的人相似的过程中，参加者提供他想开会的时间段，将每个时间段与他自己对在那个时间开会的期望程度联系起来。依赖于协商选项，参加者可以或不必被组织者提供的原始时间段所界定。如果没有界定，则参加者可以自由地提供与组织者最初建议时间段不同的时间段。在任何一种情况下，参加者都指出了他对时间段的偏好。当提供他或她的时间段时，参加者可以选择查看并考虑他或她自己的日历以及那些已经由其他人提供的时间段及其期望的聚合视图。

在所有的参加者都对协商作出反应后，为了确定会议的时间，组织者查看包含在协商中的集成安排进度信息。这包括全部提供的时间段及其期望的聚合视图。然后组织者选择实际的会议开始时间，预先定义好的持续时间。根据参加者提供的信息和原始的会议界定，组织者将协商定下来。协商的确定发出事件邀请，包括会议的日期/时间、地点、主题、参加者等。

本系统与组织会议的传统方法相比显示出以下优势。因为它不依赖于使用电子日历并在日历中保留精确进度的个人或参加者，所以本系统的协商支持更大的用户基础。另外，本系统的协商对象还保护了隐私。用户不必授权其它人访问他的日历，也不必放弃对其信息和时间的控制。协商对象只包含对那个事件用户输入的信息。日历委托或闲时间、忙时间的访问是不必要的。但是，如果闲时间、忙时间的访问可用，则本系统可以在协商过程中利用该信息。

而且，因为每一方都直接与协商对象打交道，所以组织者和参加者之间的更新通信减少了。另外，本系统的协商对象总是为被协商的事件反映最新的状态。协商对象还可以反映影响协商的外部行为(例如，时间段不再可用)。此外，协商提供了一种一般并不与官方的安排进度事件关联的非正式水平(例如提供开会的时间)，从而鼓励组织者与参加者之间的对话并建立更有效的会议气氛。同样，本系统协商对象中的协商不限于时间；例如，会议参加者、地点、议程等也可以被协商。

本系统的一个特征是称作提供时间的时间指定。提供时间是用来表示接受或拒绝的时间段，即，那些用户提供的日期/时间是可用的时间段。在精确日历的情况下，提供的日期/时间最有可能与闲时间相同或是其子集。在不精确日历的情况下，提供的日期/时间最有可能是闲时间的超集。但是，提供的时间可以与闲时间完全无关。例如，尽管用户可能已经有一个已经安排进度的会议，但那个时间仍然可以被提供为可用的。然后协商在组织者和要开会的参加者所提供的时间中发生。

建议的事件也许没有预定的时间；在这种情况下，本系统提出有界的协商时间段。例如，组织者可以提议与他的同事在本周三或周五下午任何时间有一个小时的事件。这些提供的时间被有界协商时间段界定。组织者的同事可以通过提供他们自己的有界协商时间段来“协商”。这些时间段会限制组织者的时间段(例如，周三从下午2点-4点)或者会扩展组织者的时间段(例如，周三全天)。有界协商时间段提供了灵活性，允许建议事件的各方集中到事件而不是后勤上。以其更大的界限，有界协商时间段还提供了一个更好的机会来寻找相互同意的时间。

提议的事件也许不要求特定的参加者。在某些情况下，一个组中有一个代表或者有特殊角色的某个人等就可满足该事件的需要。例如，在计算机软件公司，讨论在开发中产品状态的事件可能要求从服务器组，客户机组和安全组出一个代表。当提议事件时，组织者可以用许多方法指定参加者，包括特别地指定一个参加者、指定一个允许代替的参加者、指定在指定组中的一个参加者必须出席及指定具有特定角色(例如，律师、会计、VP)的参加者必须出席。

协商对象集成了所有与安排进度相关的信息。作为聚集，过去和当前事件的协商对象提供了可以从中检测到模式的历史。这些活动的模式可以用来通过使得能够进行自动处理促进当前或将来的协商。自动处理在合适的时候可以包括如基于用户的安排进度事件来预选协商界限、预选最早的开始和结束点(例如，用户很少在上午8点之前或下午5点之后开会)、基于事件的主题预选参加者、优化事件的最终确定及接受事件等事情。

本系统的协商对象集成了所有与安排进度相关的信息，如用户可以开会的时间、地点等。本系统总是反映被协商事件的最新状态。它还反映了影响协商的外部行为，如时间段不再可用。

协商对象包括由组织者和参加者提供的时间段。有些时间段可以不考虑，而其它的则可能要加到考虑中来。取消提供时间的一个原因可能是这个时间不再可用；例如，提供的时间已经被其它的事件安排进度了。当一个时间段作为可能的会议时间提供给许多人时，用户可能需要撤销该提供的时间。当一个完全独立的事件在这段时间被安排进度时，该提供的时间也会被撤销。如果现在那段时间可用，则该提供的时间会被加上，例如以前的进度事件取消了。用户可以选择在以前提供的时间内安排进度的新事件是否应当自动地在协商对象中反映出来。用户总是能够手动地更改其提供的时间。

动态协商对象的好处是当被用户打开或查看时，动态协商对象反映了访问时的最新信息，从而消除了在典型安排进度和重新安排进度操作中包含的持续更新。

协商的典型情景是“组事件”，其中组织者同参加者安排会议进度。另一常见的情景包括同伴集体安排事件进度(比如，滑雪周末)。在这些情况下，有一种协商对象可以用来表示这一事件的协商。一种较不常见的情景包括安排一系列各个会议的进度。例如，经理想要每周一次单独会见其团队中的每个成员。或者申请者与团队中的每个成员面试。在这种情况下，有一种协商对象能用来表示许多事件的协商，“组织者”和每个参加者有一个。例如，经理可能需要会见五个员工。只需要一个协商对象来建立这一系列的会见，而不是五个。后续的协商跨越五个事件，每个参加者一个。

附图说明

本发明的各种特征及获得它们的方式将参考下面的描述、权利要求书和附图更详细地描述，其中标号在适当时候是重用的，用来指示参考项之间的对应性，其中：

图1是一种示例性操作环境的示意图，其中能够使用本发明的会议协商系统；

图2是图1会议协商系统的高层体系结构的方框图；

图3是说明图1和2会议协商系统操作方法的概况的方法流程图；

图4是说明图1和2会议协商系统让会议组织者发起会议协商的用户界面图；

图5是说明图1和2会议协商系统让参加者响应会议协商的用户界面图；

图6是说明图1和2会议协商系统让会议组织者确定会议协商的用户界面图；

图7是说明图1和2会议协商系统用户登录的操作方法的方法流程图；

图8是说明图1和2会议协商系统发起协商的操作方法的方法流程图；及

图9是说明图1和2会议协商系统响应协商的操作方法的方法流程图。

具体实施方式

下面的定义和解释提供了关于本发明技术领域的背景信息，目的是方便对本发明的理解而不是要限制其范围：

API(应用程序接口)：由计算机操作系统或另一应用程序指定的特定方法，通过该方法写应用程序的程序员可以进行向操作系统或另一应用程序的请求。

EJB(企业Java控件)：由Sun Microsystems开发的Java API，它为多层客户机/服务器系统定义了组件体系结构。EJB的类型包括执行处理的会话控件、表示诸如数据库中行或表等数据的实体控件及处理Java消息服务(JMS)消息的消息驱动控件。

IIOP(互联网ORB间协议)：基于共同对象请求代理体系结构(CORBA)的协议，它定义了分布式对象如何通信并且允许许多平台上的客户端软件访问和使用服务器上相同的对象。

Internet：互连的公共和专用计算机网络的集合，通过一组标准协议与路由器连接在一起形成全球化的分布式网络。

Java：由Sun Microsystems开发的一种面向对象的编程语言，设计为产生可以不加修改地运行在所有小型、中型或大型硬件平台上的应用程序。

JDBC(java数据库连接)：允许Java应用程序通过SQL语言访问数据库的一种编程界面。

NP-完全：多项式时间简化提供了一种正式的方法来说明一个问题至少同另一个问题是同样困难的，在一个多项式时间因子中。如果任何其它NP问题可以在多项式时间内简化到它，则这个NP问题是NP完全的。

SMTP(简单邮件传输协议)：用来交付电子邮件的服务器到服务器协议，这是互联网上使用的标准协议；SMTP也用在其它TCP/IP网络中。

SQL(结构化查询语言)：用于在关系数据库中查询和处理数据的语言。

图1描绘了一种示例性总体环境，其中可以使用根据本发明通过共享表示在保护隐私的同时协商进度的系统及相关方法。系统10包含通常嵌入或安装在协商服务器15上的软件程序代码或计算机程序产品。可选地，系统10可以存储在合适的存储介质上，如磁盘、光盘、硬盘或类似的设备。

如远程互联网用户的用户由多个计算机表示，如计算机20、25、30，它们可以通过网络35访问协商服务器15。计算机20、25、30每个都包含允许用户与协商服务器15安全接口的软件。协商服务器15通过如电话、电缆或卫星链路的通信链路40连接到网络35。计算机20、25、30可以分别通过通信链路40、45、50、55连接到网络35。尽管系统10是关于网络35进行描述的，但计算机20、25、30也可以本地而不是远程访问系统10。计算机20、25、30可以手动地或通过使用应用程序自动地访问系统10。

图2的高层体系结构包括系统10的概观。会议组织者创建会议协商，请求参加者参加。会议组织者和参加者是操作计算机20、25、30的系统10的用户。协商服务器15从协商客户机205接受请求。可能的请求包括：“创建新协商”、“更新现有协商”或“确定现有协商”。

协商服务器15与协商存留器210交互，以便在协商数据库215中存储、检索或更新协商。另外，协商服务器15与通知器220交互，以便在新的协商创建时发出通知。而且，协商服务器15与协商确定器225交互，从而最终确定协商。此外，协商服务器15还使用日历检索器230从外部的日历系统访问闲时间信息。

协商客户机205在协商服务器15上提供用于创建、修改或确定协商的用户界面。协商客户机205使用进度聚合器235来合并协商对象及其关联的用户反馈。协商客户机205与认证器240通信，检索出访问协商服务器15需要的必要凭证。

假设有一个包括带参加者偏好的反馈的协商，进度聚合器235把反馈合并到用于支持事件最佳时隙选择的聚合表示中。偏好包括至少一个偏好指示符。偏好指示符可以是例如但不限于：提供的偏好、优选的偏好、可以接受的偏好、有问题的偏好、不赞成的偏好、不可以接受的偏好、基于拇指的指示符(例如，2个拇指向上、1个拇指向上、没有拇指、1个拇指向下及2个拇指向下)。

许多算法都可以用来聚合进度，例如在时标上对时隙及其所关联偏好设置(优选的、可以接受的、不赞成的或不可以接受的)简单求平均。在系统10的一种实施方案中，当协商被更新时，协商服务器15直接调用进度聚合器235，并且把最优的进度合并到协商对象中。

协商存留器210负责将协商存到永久存储器，协商DB 215中。协商存留器210创建、删除或更新协商DB215中的协商。

协商DB215包含协商。协商状态可以是确定的或不确定的。在系统10的一种实施方案中，协商DB215实现为关系数据库。

当协商已经被确定后，协商确定器225与邀请器245交互，使得邀请发送给所有的参加者。协商确定器225还与协商存留器210交互并且把数据库中的协商状态标记为确定的。可选地，协商确定器225可以从数据库中删除该确定的协商；这种功能也可以在稍后当数据库被压缩的阶段实现。

协商服务器15利用通知器220向参加者发送通知，通知需要他们参加的协商已经被创建了。通知可以用例如电子邮件发送。

邀请器245负责当协商确定后向参加者发送邀请。邀请可以用例如带有来自外部日历的嵌入数据的电子邮件发送。

全局优化器250是在服务器上提供开放协商的全局优化的可选组件。全局优化器250周期性地或手动地被触发。全局优化器250把所有在服务器上的协商作为输入，并且在假定全部现有约束的情况下为每个协商计算最优的进度。这个问题是NP-完全的，但存在适当的近似算法，如IceCube算法，在例如由Anne-Marie Kermarrec等人所著的“The Ice Cube approach to the reconciliation of divergentreplicas，”Twentieth ACM Symposium on Principles of DistributedComputing(PODC2001)，2001年8月26-29日，Newport，RhodeIsland(USA)中进行了描述。优化结果支持会议组织者为协商的事件确定最优时间。

客户机与认证器240交互，以获得访问协商服务器15的合适凭证。如果认证成功，则返回的凭证包含在到协商服务器15的每个请求中。

如果可用的话，日历检索器230就访问外部日历和安排进度系统，从而把进度和闲时间信息合并到协商对象中。这种信息用于支持对事件最优时隙的选择，而且用于当外部进度更新时自动地更新提供的时间。

从会议组织者和参加者的角度来看协商会议的方法300在图3的高层方法流程图中进行说明。在步骤305，会议组织者开始协商。图4的示例性屏幕快照说明了会议组织者在发起协商时使用的选项和特征。在步骤310参加者指示了会议偏好。参加者可用的选项和特征由图5的示例性屏幕快照说明。在块315会议组织者确定协商，如图6的示例性屏幕快照所说明的。

图4以屏幕快照的形式说明了用于让会议组织者利用系统10开始协商的示例性用户界面400。多日期选择器402允许会议组织者选择想要开会的一天或若干天。由于可协商时间的事件可以发生在若干天的范围内，因此对标准日期选择器组件进行扩充以便支持多天的选择。会议组织者选择这些天并利用提供的时间404来为每天设置时间范围。参加者可以通过点击选择的日期一次查看多天。

会议组织者选择的日子加亮显示，如由围绕选定日期406的边框所指示的。不同的加亮显示可以为每个日期指示不同的状态。例如，标记为红色的日子表示是由组织者留出时间的日子；但是，那天所有可用的时隙都已经被参加者删除了。

选定日期406允许会议组织者使用系统10的一个特征，有界协商。有界协商允许会议组织者在指定界限内的任何时间提议开会，其中会议时间是可以协商的。相反，组织会议的传统方法是提前设置会议时间，然后协商出席人数。

如用户界面400所说明的系统10的其它选项和特征是主题408、地点410及可变的持续时间412。会议组织者在主题408输入会议主题。在地点410处输入事件地点410。事件的持续时间及开始时间是可以协商的。会议组织者可以在持续时间412处为会议指定一个时间段。

当会议组织者完成输入事件和协商的选项后，他可以通过选择提交414来“提交”协商。然后系统10向参加者通知这个未决的协商。当选择取消416时，协商过程就退出而且不存储任何改变。

系统10允许通过标注418做会议协商过程的注释。参加者和会议组织者能够通过选择增加标注420来评论事件的各个方面。加注释的评论可以包括例如参加者可否参加、特殊的环境、他们可能带到会议的项等。加注释的评论可以通过选择查看标注422来查看。

登录用户424显示当前的用户名。如果可以得到，则登录用户424的图片426会显示。如在用户界面400中所示出的，当前登录用户424是会议组织者。

浏览日期428显示登录用户424当前浏览的日期。浏览日期428的可能日期是由会议组织者利用选定日期406进行选择的。对于浏览日期428，会议组织者的时间线430显示组织者的时间范围及时间偏好。在示例性用户界面400中，时间线430由典型的营业日构成；但是，时间线430的终点是可以调整的。

在时间线430中，会议组织者能够通过提供的时间404指定时间段以及与将这些时间段相关的偏好434相联系。示例性偏好包括优选的434，可以接受的436，不赞成的438及不可以接受的440。利用偏好432，会议组织者能够指定一个更精确的粒度水平而不仅仅是闲/忙。

系统10不需要访问会议组织者的日历。但是，如果它可用的话，如会议组织者日历442所示出的，则系统10能够利用由会议组织者维护的电子日历中的信息向会议组织者展现暴露可能的冲突的概观。例如，已经安排进度的时间例如由例如块444的块指示。

会议组织者可以检查一个参加者或作为聚合的所有参加者的进度信息。用户界面400指示会议组织者是否正在参加者显示器446上查看个人或聚合的日历信息。在示例性用户界面400中，会议组织者检查聚合中的参加者，因此有一个标记为“所有参加者”的图标显示在参加者显示器446上。

因此，系统10显示来自参加者的聚合时间线448中的参加者的响应的聚合。用户界面400说明在协商创建阶段与会议组织者的示例性界面；因此，在参加者的聚合时间线448上没有时间显示。参加者的日历聚合显示在参加者的聚合日历450中。对参加者日历的访问是不必要的；但是，如果可以得到，则系统10可以利用由参加者维护的电子日历中的信息来向会议组织者展现暴露可能冲突的概观。例如，已经安排进度的时间由例如块452的块指示。

会议组织者能够选择作为参加者的用户显示在可能的参加者454中。这些用户可以来自会议组织者的地址簿等。已经被会议组织者选择的事件参加者在参加者456中列出。会议组织者可以通过选择增加参加者458或删除参加者460从事件中增加或删除参加者。如果会议组织者在创建会议协商时产生错误，则他可以选择擦除462。擦除462用来调整时间段。例如，如果参加者指示时间段下午2:00到下午5:00是优选的，但随后该参加者意识到他或她要在下午4:30离开，则该参加者可以擦除下午4:30到下午5:00的优选指示符。

图5以屏幕快照的形式说明了参加者利用系统10响应协商的示例性用户界面500。登录用户502显示当前的用户名，参加者1。如果可以得到，则登录用户502的图片504显示，如会议组织者506的图片。

浏览日期508显示登录用户当前浏览的日期。对于浏览日期508，时间线510显示会议组织者指定的时间范围和时间偏好。给定会议组织者提供的时间，参加者可以利用时间线512关联其自己的偏好。在时间线512中，参加者可以指定时间段并关联偏好432。示例性偏好包括优选的434、可以接受的436、不赞成的438及不可以接受的440。利用偏好432，参加者可以指定更精确的粒度水平而不仅仅是闲/忙。如果参加者的日历是系统10可以访问的，则系统10利用如块516的块显示参加者日历514中的安排进度事件。

比较参加者的日历514与所提供的会议时间518，参加者1注意到他在下午1:30到下午2:30之间有冲突。因此，如由块520所指示的，他在参加者时间线512中指示下午1:30到下午2:30是不可以接受的。如由块522所指示的，参加者1指示剩余可能的会议时间，下午2:30到下午5:00是优选的。对所有参加者都具有偏好的所有提供时间的聚合显示在参加者的聚合日历524中。

通过选择增加标注526，参加者可以注释他对会议协商的响应。由其他参加者提供的注释可以通过选择查看标注528来查看。

图6以屏幕快照的形式说明了会议组织者利用系统10确定协商的示例性用户界面600。确定协商向所有会议参加者发出邀请。为了选择会议时间，会议组织者查看由参加者提供的参加者聚合时间线602和注释。通过选择查看标注604，会议组织者查看注释。然后系统10显示标注606，例如显示参加者可能已经提供的关于会议或他们可否参加的任何附加信息。会议组织者可以通过选择关闭608来消除标注606的显示。

参加者的聚合时间线602显示来自所有参加者的时间线输入。在用户界面600的例子中，参加者以及指示对于浏览日期610，如由块612所指示的，时间下午1:30到下午2:30是不可以接受的。会议参加者可以接受的时间由块614指示。可以接受的会议时间的总结由总结616提供。

给定显示在会议组织者时间线618、参加者聚合时间线602中的最初由组织者提供的时间段及显示在标注606中的参加者评论，会议组织者指定安排会议进度的实际时间段。会议组织者在会议组织者的时间线618上选择会议的实际时间段620，以便设置会议时间。

系统10用于登录的控制流程方法700由图7的方法流程图说明。在步骤705系统10客户端的用户登录到系统10中。在步骤710系统请求该用户的凭证，而在步骤715用户以用户ID和口令的形式输入其凭证。在步骤715系统10将用户的凭证传给协商服务器15。在步骤720系统10利用认证器240验证该凭证的真实性。如果在判定步骤725认证失败，则系统10前进到步骤710并再次向用户提出询问。否则，系统10可以可选地刷新系统10的高速缓冲存储器中该用户现有的日历数据。

系统10用于创建协商的控制流程方法800由图8的方法流程图说明。在步骤805作为会议组织者的用户发出或建立新的协商。例如，建立协商包括选择参加者及其角色、识别事件的主题及推荐所提供的日期和时间。如在Java中构建的数据对象携带关于该协商的信息；这种数据对象是协商值对象。在步骤810协商值对象发送到协商服务器15。在步骤815协商对象由协商存留器225存在如数据库的数据存储器中。在步骤820包括唯一协商标识符的通知发送到由会议组织者选定的所有参加者，向他们通知该未决的协商。

系统10用于让参加者检索协商的控制流程方法900由图9的方法流程图说明。参加者利用方法700的登录过程登录到系统10中。然后在步骤905协商的参加者选择如通知中所提供的协商的协商标识符。在任意时间参加者都可能有几个协商要进行处理。

在步骤910系统10将选定的协商标识符传给协商服务器15。在步骤915系统10从数据存储器中检索保存的协商信息。在步骤920，如果日历数据是系统10可用的，则系统10可选地更新参加者的日历数据高速缓冲存储器，以便显示其可用或提交时间的最新快照。

在步骤925系统10根据对协商标识符检索的数据及任何可用的日历数据重建协商值对象。在步骤930协商值对象返回到参加者。在步骤935参加者利用其自己的日历查看并协调该协商，提供会议偏好、注释等。

在系统10中支持永久性所需的实体控件/数据库表包括事件表、参加者表、用户表、时隙表、属性表及注释表。事件表包括如事件描述、地点、持续时间等事件信息。参加者表包括参加者身份、如需要或可选的参加者身份角色等。用户表包括用户ID、电子邮件地址、时区等。时隙表包括开始与结束时间、时区、偏好水平等。注释表包括用户ID、用户评论等。

应当理解已经描述的本发明特定实施方案仅仅是对本发明原理特定应用的说明。在不背离本发明主旨与范围的前提下，通过在此所述的共享表示发明，在保护隐私的同时，可以对协商进度进行许多修改。此外，尽管本发明出于说明性目的只关于互联网进行了描述，但应当清楚本发明还可以适用于如局域网、广域网或任何计算机可以彼此通信的应用中。

Claims (37)

1、一种用于在多个参加者中协商进度的日历方法，包括：

指定该多个参加者的可否参加的偏好；

自动提出反映该多个参加者的可否参加的偏好的事件计划；及

自动向该多个参加者提供接受该事件计划的选项，该选项包括拒绝事件计划的选项及重复地提出可替代事件计划的选项中的至少一个。

2、如权利要求1所述的方法，其中指定可否参加的偏好包括识别出至少一个偏好指示符。

3、如权利要求1所述的方法，还包括对偏好加权。

4、如权利要求1所述的方法，还包括将偏好连接到选择性访问的调整。

5、如权利要求1所述的方法，还包括图形地显示该偏好。

6、如权利要求1所述的方法，其中多个参加者包括会议组织者、参加者、允许的代替者及委托替身中的至少一个。

7、如权利要求1所述的方法，其中提出的可替代事件计划包括至少一个参数的有意不正确的指定。

8、如权利要求1所述的方法，其中提出的可替代事件计划包括至少一个约束的有意不正确的指定。

9、如权利要求1所述的方法，还包括根据过去事件计划的历史自动选择接受事件计划的选项。

10、如权利要求1所述的方法，其中自动提出事件计划包括允许多个参加者之间的有界协商，以便在可以协商会议时间的指定界限内提供会议。

11、一种具有用于在多个参加者中协商进度的指令代码的日历计算机程序产品，包括：

用于指定多个参加者可否参加的偏好的第一组指令代码；

用于自动提出反映该多个参加者可否参加的偏好的事件计划的第二组指令代码；及

用于自动向该多个参加者提供接受该事件计划的选项的第三组指令代码，其中选项包括拒绝事件计划的选项及重复地提出可替代事件计划的选项中的至少一个。

12、如权利要求11所述的计算机程序产品，其中该偏好包括来自提供的偏好、优选偏好、可以接受的偏好、有问题的偏好、不赞成偏好及不可以接受的偏好的至少一个偏好指示符。

13、如权利要求11所述的计算机程序产品，其中加权该偏好。

14、如权利要求11所述的计算机程序产品，其中该偏好连接到可选择性访问的调整。

15、如权利要求11所述的计算机程序产品，其中该偏好是图形地显示的。

16、如权利要求11所述的计算机程序产品，其中多个参加者包括会议组织者、参加者、允许的代替者及委托替身中的至少一个。

17、如权利要求11所述的计算机程序产品，其中提出的可替代事件计划包括至少一个参数的有意不正确的指定。

18、如权利要求11所述的计算机程序产品，其中提出的可替代事件计划包括至少一个约束的有意不正确的指定。

19、如权利要求11所述的计算机程序产品，还包括根据过去事件计划的历史自动选择接受事件计划的选项的第四组指令代码。

20、如权利要求19所述的计算机程序产品，其中第四组指令代码考虑到多个参加者之间的有界协商，以便在可以协商会议时间的指定界限内提供会议。

21、一种用于在多个参加者中协商进度的日历服务，包括：

指定多个参加者可否参加的偏好；

自动提出反映该多个参加者可否参加的偏好的事件计划；及

向该多个参加者自动提供接受该事件计划的选项，该选项包括拒绝事件计划的选项及重复地提出可替代事件计划的选项中的至少一个。

22、如权利要求21所述的服务，其中偏好包括来自提供的偏好、优选偏好、可以接受的偏好、有问题的偏好、不赞成的偏好及不可以接受的偏好的至少一个偏好指示符。

23、如权利要求21所述的服务，其中加权该偏好。

24、如权利要求21所述的服务，其中该偏好选择性地连接到可访问的调整。

25、如权利要求21所述的服务，其中该偏好是图形地显示的。

26、如权利要求21所述的服务，其中多个参加者包括会议组织者、参加者、允许的代替者及委托替身中的至少一个。

27、如权利要求21所述的服务，其中提出的可替代事件计划包括至少一个参数的有意不正确的指定。

28、如权利要求21所述的服务，其中提出的可替代事件计划包括至少一个约束的有意不正确的指定。

29、如权利要求21所述的服务，还包括根据过去事件计划的历史自动选择接受事件计划的选项。

30、如权利要求29所述的服务，其中自动选择接受事件计划的选项考虑到多个参加者之间的有界协商，以便在可以协商会议时间的指定界限内提供会议。

31、一种与联网计算机一起用于在组织者和多个参加者中协商进度的日历协商系统，包括：

用于创建协商的协商服务器，其中协商指定由组织者所提供的可否参加的偏好；

向参加者通知所创建的协商的通知器；

根据其与来自参加者的偏好关联的反馈确定协商的确定器；

当协商已经确定时向参加者发出邀请的邀请器。

32、如权利要求31所述的日历协商系统，其中可否参加的偏好包括由组织者提供的时间帧及其关联的偏好指示符。

33、如权利要求32所述的日历协商系统，其中关于偏好的反馈包括由参加者提供的时间帧及其关联的偏好指示符。

34、如权利要求31至33任何一项所述的日历协商系统，还包括协商客户机，其中该协商客户机在协商服务器上提供用于创建、修改或确定协商的用户界面。

35、如权利要求31至33任何一项所述的日历协商系统，其中协商客户机向参加者提供输入其反馈的用户界面。

36、如权利要求31至33任何一项所述的日历协商系统，还包括合并协商及其关联的来自参加者的反馈的进度聚合器，其中确定器根据协商与关联的反馈的合并来确定协商。

37、如权利要求33所述的日历协商系统，其中参加者提供的偏好指示符包括提供的偏好、优选偏好、可以接受的偏好、有问题的偏好、不赞成偏好及不可以接受的偏好的至少一个。

Images