专利名称：用于过程管理的方法、系统和装置的制作方法
技术领域：
本申请一般地涉及计算机应用，更具体地说，涉及用于过程管理的系统、装置、计算机程序和方法。
背景技术：
本公开涉及利用信息技术(IT)提高生产率。一段时间以来，商业企业使用计算机系统来使其日常业务过程自动化并对之进行增强。计算机的最初应用是基本上在每一个企业中都存在的基本过程清算帐目、定单管理和客户登记。
最早的计算机化解决方案寻求支持诸如创建、存储和发送文档以及管理个人联系网络之类的业务过程的一般功能。随着这些系统的发展，添加了特性以便以这样的方式使全部企业范围内的过程自动化以集中方式监视和管理所述过程。这涉及以明确的术语定义从过程的每个参与者所需的步骤和信息。
这些目标最终导致对业务过程建模(BPM)方法的开发，如1980年以来的Zachman框架。这些方法试图捕获与特定业务过程相关的所有方面。另外，技术开发跟踪产生的业务过程管理系统(BPMS)，其具有这样的目标实现有效的方式来由不同企业针对任何目的创建专用的自动化过程实施方式。第一波商业系统使用在许多企业间都类似的自动化的普通过程，或从被头开始定制，直到满足企业中特定业务过程的要求。新的BPMS实施方式声称其可以使企业中的任何过程自动化，包括人工参与的和其他计算机应用两者。
业务过程管理系统通常是模型驱动的，例如，它们执行定义自动化过程的工作流的规范模型。实现模型的一种常用技术是业务过程执行语言(BPEL)，但是还开发了大量其他建模语言。在某些情况下，模型描述了过程的状态数据的结构，以及由外部参与者修改状态的一系列交互步骤。模型还可以描述过程所需的诸如数据库之类的其他资源。
发明内容
本申请公开了一种用于过程管理的系统、装置、计算机程序和方法。在一个方面中，用于过程管理的装置、计算机程序和方法标识线程以响应过程的电子消息传送操作。所述线程包括总体地描述所述过程的相关任务的状态和关系的数据。生成所述线程的状态以响应所述电子消息传送操作。所述线程的状态代表所述过程的状态。帮助用户接口呈现所述线程以响应所述电子消息操作，使得所述呈现指示所述线程的状态。
在一种变型中，所述电子消息传送操作可以包括基于为所述过程的所述任务建模的工作流模板创建文档元数据以便传输。在此情况下，所述电子消息传送操作可以包括基于所述工作流模板生成其中嵌入所述文档元数据的电子文档。进而，在此情况下，所述文档元数据可以包括角色信息，所述角色信息基于处理所生成文档的个体的角色改变所述过程的电子文档的生成。在上述情况下，所述工作流模板可以包括标记语言文档，并且可以基于所述工作流模板在运行时动态生成所述电子文档的用户接口。
在其他变型中，帮助用户接口呈现所述线程包括提供所述过程的任务的列表连同与相应任务关联的状态。在其他方面中，基于所述线程的状态变化改变所述线程的显示，和/或以由所述线程描述的所述过程的任务的相应状态所定义的顺序来呈现所述线程。在另一种变型中，所述过程的任务中的至少一个任务包括至少一个子任务，并且呈现所述线程包括以分级视图呈现所述至少一个任务和所述至少一个子任务。
在附加到说明书并形成其一部分的权利要求书中详细指出了这些和各种其他优点和新颖特性。但是，为了更好地理解变型和优点，应参考形成说明书一部分的附图并参考所附的描述内容，其中示例性示出和描述了根据本发明的示例实施例的系统、装置、计算机程序产品和方法的代表性示例。
结合附图中示出的示例实施例描述了本发明，其中 图1A-B是示出根据本发明的示例实施例的任务管理系统中的角色与网络信道之间的交互的框图； 图2是示出根据本发明的示例实施例的任务管理系统中的文档流的框图； 图3是示出根据本发明的示例实施例的过程流网络的框图； 图4是示出根据本发明的示例实施例的在过程网络间分布资源的框图； 图5是示出根据本发明的示例实施例的文档的数据结构的框图； 图6是示出根据本发明的示例实施例的利用线程状态管理的方案的框图； 图7是示出根据本发明的示例实施例的反映图6的方案的线程状态的用户接口视图的框图； 图8-9是示出根据本发明的替代示例实施例的反映诸如图6的方案中的线程状态的替代用户接口视图的框图； 图10是根据本发明的示例实施例的用户装置的框图； 图11是根据本发明的示例实施例的服务装置的框图； 图12A-12B和13A-13B是示出根据本发明的示例实施例的过程的流程图；以及 图14是示出根据本发明的示例实施例的附加过程的流程图。
具体实施例方式 本申请文档的公开的一部分包含受版权保护的资料。版权所有人不反对任何人对专利文档或专利公开进行复制再现，因为其出现在专利和商标局的专利文件和记录中，但是无论如何以其他方式保留所有版权。
在以下对各个示例实施例的描述中，参考了形成本说明书一部分并且其中通过示例性的方式示出各个示例实施例的附图。要理解的是，可以使用其他实施例，因为可以做出结构和操作上的更改而不脱离本发明的范围。
一般来说，本发明公开涉及在任务/过程管理系统中对文档流进行管理。传统的BPMS提供了跟踪单个过程流的状态的能力。例如，可以观察定单何时被提交、谁正在对其进行处理、定单何时被确认以及定单何时被递送。在集中式系统中，中央服务器可以跟踪任务管理过程状态。客户端可以更新中央服务器上的状态，并且每个在线的人都可以很快见到状态改变。在分布式文档流系统中，需要与基于消息传送的通信范例相配合的分布式解决方案。此类分布式解决方案还可支持离线使用，例如，针对具有有限或间断的网络连通性的移动用户，或可能通过规范的网络外部的直接/邻近数据交换来交换数据的移动用户。
在集中式BPMS中，参与者可能需要访问公共的共享过程实例。已尝试创建这样的分布式BPMS系统其中每个参与者或者访问共享过程实例的虚拟副本，或者仅具有本地可用的过程描述的相关部分。但是，这些系统可能缺失BPMS应该提供的某些益处，例如对所有感兴趣方立即更新状态。
本发明公开涉及用于启动、记录、形式化、跟踪，和/或通知各方有关过程(例如，业务或工作流过程)的各方面的文档，所述方面包括任务、实体、个人、有形/无形资产、项目、合同、事件、服务等。在此处描述的文档流框架中，可以通过将文档组织成“线程(thread)”来处理任务管理，其中每个线程对应于过程。在过去，线程的概念与电子邮件交换、在线消息板、文本消息交换、Usenet组等关联。在这些类型的通信中，根据特定消息或主题将正在进行的通信分组成线程。可以按照某种顺序(例如，根据创建/接收时间分类)呈现通信或者可以基于其他因素对其进行分级布置(例如，对特定消息的响应可以被分组在原始发布的消息之下)。
如通常在此使用的此类术语，线程是用于说明正在进行的事务的状态和关系的数据范例。例如，术语“线程”可以指位于用户设备中的反映基础事务的状态的数据/可执行对象。此线程对象还可以具有可视呈现组件。由线程表示的正在进行的事务可以包括文档传输、有形资产、书面或口头通信等。此外，由线程表示的过程无需与赢利实体关联。因此，尽管在此根据业务组织描述了示例“业务过程”，但是本领域技术人员将理解，“过程”或“业务过程”可以包括任何形式的利用电子消息交换、共同以有序方式完成规定目标的任务。例如，由个体执行的公共任务(如组织聚会、募捐、团体意识、巡回请愿等)可涉及通过电子消息传送跟踪并对参与者表示为线程的交换。
在本说明书中，文档线程可以具有描述业务过程的当前总体状态的状态，如“定单已发送”、“已收到递送”等。子过程可以被表示为嵌套式线程。将文档表示为线程的用户接口可以足够接近电子邮件，以便赋予用户如何对其使用的直观理解。但是，此类系统可以表现出与标准电子邮件的不同。例如，标准电子邮件不支持嵌套式线程，并且线程不能作为带有其自己的属性(如状态)的独立对象而存在。
在一个示例实施例中，每个文档都带有一个或多个线程描述符。这些描述符可以涉及任何直接的父线程(例如，文档直接所属的线程)以及任何先辈线程(ancestor thread)。尽管在某些实施方式中，框架可以将文档限于一个父线程(例如，当分级被表示为树图时)，但是其他实施方式可以允许多个父线程。当文档到达时，客户端检查直接父线程的描述符以确定其是否已具有匹配该描述符的线程，如果是，则将文档附加到该线程。如果客户端上不存在该线程，则创建线程并将文档附加到该线程。创建线程所需的某些数据(例如，主题、描述、状态、父线程(在嵌套式线程的情况下))可以来自描述符，并且某些数据可以来自导致线程被创建的文档。最后，检查其他线程描述符并且在客户端上创建相应的线程(如果它们尚不存在)。
当基于另一文档创建文档时(例如，回复或转发)，原始文档中的线程描述符可以被复制到新的文档。有时，可以添加线程描述符(新的文档开始新的线程)或可以删除一个或多个父线程描述符(新的文档不属于这些线程)。可以通过所接收的属于该线程的文档来更新线程的状态。以下描述了更新线程状态的方法，即简单的受限方法和更灵活但可能更复杂的方法。简单的方法可能不充分地处理嵌套式线程、复杂文档流或线程完成状态，但是对于某些问题范围已经足够。
出于用户接口(UI)目的，可能希望知道过程何时完成，以便根据相应过程完成与否来不同地(例如，使用不同的图标)显示线程。确定和传达线程完成的方式可以取决于技术方案和解决方案域。以下进一步描述的各个示例实施例表明了一些显示线程完成的方式。
通常，在此描述的任务管理解决方案的域可以包括小型和中型企业、个人专业用户和具有日常过程需求的客户。此类解决方案对于未接入固定互联网连接的个人用户或个人计算机(例如，可能完全依赖于其移动设备的那些用户)可能有用。在某些情况下，不可能或不必标识过程的所有者，并且在某些情况下，参与者可以是彼此对等的。在这些情况下，用户可以形成复杂的网络，随着用户的业务联系的发展，用户可以动态地管理该网络。这些网络可以包括用于用户的日常过程中的所有通信的主要部分。
图1A-1B的框图中示出了可以利用本发明概念的实体的实例，其中使用相同的标号来指示其间相同的组件。所述实体总体上可以分成服务提供商102和服务客户104。各个服务提供商102和客户104可以被分组成其他分类。例如，服务提供商106和108可以被分组成协作提供商的同事网络110。路径112也指示了服务提供商106与108之间的这种同事关系。如边界116所示，提供商108还与服务提供商114相关。在此情况下，此实例中的服务提供商108、114之间的关系是，这些实体108、114形成了用于服务客户118的提供商网络116。此外，服务客户118是包括服务客户120的对等网络122的一部分。最后，服务提供商124和服务客户126可以独立于特定的同事/提供商/对等网络110、116、122，但是仍然可以已经与这些网络110、116、122内的其他实体建立了关系，如路径128、130和132所示。
用户形成这些(和其他)网络110、116、122以随着其业务联系的发展动态地管理事务。这些网络110、116、122可以包括用于用户的日常过程中的某些或所有通信的主要部分。网络110、116、122可以与为其使用网络110、116、122的基础相互关系一样简单或复杂。例如，网络110、116、122在其性质上可以有些非正式，例如“我的邻居(myNeighbors)”，或更加事务性和正式，例如“我的客户(myCustomers)”。可以在这些网络110、116、122之间执行参与者的日常过程。
现在参考图1B，框图示出了图1A所示的实体之间的各种文档流。这些流包括定义、启动、支持、记录和以其他方式协助业务过程的文档，所述过程如服务间委托140、客户间推荐142、客户间邀请144、146、客户-提供商请求150以及响应于请求150的报告148。与这些不同的流140、142、144、146、148、150相关的文档可以随业务过程中的不同时间而变化。例如，请求150可以包括带有各种空白/未知值的文档，一个或多个服务提供商106、108将在委托140和报告148之前、期间，和/或之后填充所述值。以下描述的框架包括实现基于作为过程的任务/事件的一部分而被交换的文档的状态来跟踪过程中的这些变化的特性。
文档管理框架的一个方面涉及用户如何能够理解和定制提供给他们的解决方案。某些用户可能期望使用所提供的工具从头开始构建其服务。在其他情况下，可以提供涵盖特定公共或公知任务的易于使用的模板。在此描述的示例实施例的其他技术特性包括但不限于a)允许参与者在没有到中央服务的网络接入的情况下执行相关(日常)活动；b)将过程概念直接映射到现有的基于物理文档的过程，以帮助服务参与者在没有陡峭的学习曲线的情况下理解所述概念；c)帮助针对每个参与者的专用网络的维护；以及d)支持用于流实施方式的相同通信架构内的数据资源的受控共享。
以下描述的示例实施例提供了业务域中用户可定制的移动过程。一种方式是基于消息传递范例的文档中央工作流模型。该模型促进了参与者自主性和推动型活动分配。在图2中，框图示出了根据本发明的示例实施例的分布式移动文档系统中的通信流。流的参与者通过彼此发送文档(例如，文档202)来通信。通信节点(例如，移动客户端204、206以及服务器205、207)可以是在困难的连通性状况下协助容易和直观的操作的“存储-转发”型处理节点。节点204-207包括相应的角色配置模块208-211，每个模块都维护和应用路由/动作规则以便处理和路由在系统中传送的各种文档212-215。
如图2的示例实施例中所示，文档流中可以存在两种类型的参与者。电话用户由移动客户端204、206表示并且组织由服务器205、207(在此称为组织服务器)表示。服务器205、207可以被连接到固定互联网并且在文档流过程中可以是对等体。移动客户端204、206也可以作为对等体在彼此之间进行通信，以及作为对等体和/或作为客户端-服务器与组织服务器205、207通信。
在组织服务器207如何参与文档流的示例中，考虑具有移动客户端206的客户向服务提供商公司发送定单文档215的情况。公司的组织服务器207接收该文档并且通过从其角色配置211中查找路由规则来对文档做出反应。此类规则通常对应于“定单”文档类型和文档215中角色描述符内的公司的角色。在此情况下的角色信息可以是“服务提供商＝公司X”。路由规则可以说明组织服务器207应将定单文档215转发到公司X的组织服务器实例中的“销售员”网络内的移动用户之一(例如参见图3)。
在此示例情况中，组织服务器207代表公司的通信端点，并且在此情况下可充当公司的客户与公司的工作人员之间的媒介。可能的是组织服务器基于其接收的文档创建新的文档，在此情况下，可以将元信息从原始文档215复制到创建的文档。
如文档202中所示，系统中的每个文档都携带有与流的应用相关的业务数据216，例如，定单行。系统的每个文档还包括可以由流的所有参与者解释并用于各种目的的结构化元数据218。例如，基于用户的角色和文档类型来选择用于处理文档的表单。因此，可以针对接收的每个文档定义用户的角色。为了确保这一点，在文档可以被发送之前，需要已知和/或限制接收用户的角色。
元数据218的各种用途包括报告业务过程的线程的状态。通过使用文档212-215实现的各个相关任务的状态，可以集体地确定线程的状态。因此，无需中央实体来跟踪这些过程状态是可能的，因为文档212-215自身包含足够的数据用于使参与节点确定感兴趣的线程状态。例如，节点205-207能够确定与通过节点205-207的所有文档212-215关联的线程状态。但是，仍希望提供传达业务过程网络的任务、文档以及线程的状态的替代手段。例如，如果文档212未直接在客户端204与206之间传送，而是通过中间物传递，则客户端204、206可能没有任何方法来确定文档的状态改变。
在某些实施例中，可以通过发送目的只是传递状态更新的文档来传递状态更新。例如，当客户向供应商发出定单时，供应商发回定单确认文档，其包含状态更新“已确认”以及诸如预计递送日期之类的某些附加信息。此类文档将作为单独文档在用户接口中可见，可以打开该文档以查看附加信息。但是，另一种可能是定单确认文档仅包含状态更新“已确认”而不包含任何附加信息。在此情况下，文档甚至不能作为单独文档而在用户接口中可见，并且接收到文档的唯一可见结果是线程状态更改为“已确认”。此类纯状态更新文档可用于使用正常的文档发送机制来发送针对性的状态更新。
另一种检测过程状态更改的方法是确保每个处理文档212-215和/或实现对元数据218的更改的实体都将文档212-215(或至少文档212-215的元数据218)存储在中央储存库220中。储存库220的身份可以嵌入(例如，作为URI)文档212-215自身，或可以由参与实体204-207预先配置。在某些实施例中，这可以用于补充嵌入元数据方法。
另一种可以分布工作流状态数据的方法是将参与者的标识符(例如，URL、用户身份、消息传送地址)嵌入工作流中。这些参与者标识符可以附加有元数据的多个部分，以便例如基于业务流中参与者的角色来仅传达对文档/任务/线程状态的特定更改。可以使用带外机制(例如，与用于传送文档212-215的那些机制独立的机制)来传送该状态数据，如客户端206与服务器207之间的替代数据路径222所指示的。
这些带外机制222可以是对在电子文档中嵌入数据的补充。例如，在某些情况下，参与者可能不愿或不能处理电子文档。在此情况下，参与者可以接收带有条形码的纸质文档。参与者可以确定和/或影响存储在其他位置(例如，在储存库220中)的与纸质文档的电子版本关联的元数据。通过扫描条形码(例如，使用移动设备)并在用户接口(例如，针对移动设备简化的用户接口)中输入数据，参与者仍能够以与接收到电子文档中嵌入的元数据的其他参与者类似的方式来处理数据。在此类情况下，过程中的其他电子文档可以包括对元数据中嵌入的储存库220的引用，以便如果需要，感兴趣的各方可以取回与该个体相关的线程状态。
将理解的是，传递文档212-215的示例只是示意性的，并且图2中描述的概念可应用于任何类型的文档创建/传送、文档/任务/线程状态的更新、定义角色等。使用文档自身和/或对等带外机制222传送状态更改可以允许具有有限连通性和/或带宽的设备(例如，移动设备)确定或传送状态更改，而不必借助于对服务器的轮询。其技术效果是减小了网络带宽使用并提高了系统可靠性，因为其消除了可能的单点故障。
现在参考图3，框图示出了根据本发明的示例实施例的业务过程架构的另一视图。如前所述，业务过程可以包括任何有组织的任务，可以通过个体之间的电子文档交换而促进所述任务。除了组织服务器304(如根据图2描述的)以外，所述架构还包括用于引导与文档的用户交互的移动客户端302。分布式文档流系统的架构至少包括通信流的参与者。这些参与者可以包括移动客户端(例如，客户端302)，该移动客户端代表有关的(out in the field)参与文档流的个体。某些参与者可以是被认为在本质上是固定(例如，非移动)的组织。所述组织由组织服务器系统(例如，组织服务器304和图2中的服务器204-207)表示。例如，有关的移动销售代理可以向代表其公司的服务器发送“购买定单”文档。但是，流并非一定需要组织参与者；某些流可以是对等体之间发生的特别(ad-hoc)事务。
移动用户和组织都具有相对于文档流定义的角色和网络。例如，在实现移动定制过程的文档流中，可以建立诸如销售代理、客户、提供商公司以及定单处理者之类的角色。移动用户的角色可以利用显示和动作表单，所述显示和动作表单控制用户如何查看进入的文档。例如，与客户相比，定制流中的“定单确认”文档可以为销售代理显示某些额外的数据。在此情况下，销售代理的文档可以具有访问定单文档上的“取消定单”功能，而客户则在同一或关联定单文档上看到“请求定单取消”操作。
在此环境中管理角色可以包括在适合的“网络”内隔离文档和流，所述网络广泛地指具有查看过程和/或促进过程的能力的过程和个体的集合。例如，移动用户或组织的网络可以定义用户或组织可以发起文档流的参与者空间。如图3所示，移动客户端302可被配置为维护网络306，网络306用于发起与其他移动用户(例如，移动用户308)或组织(例如，组织310)的文档流。某些网络306可以是专用的并仅在用户的移动设备内维护。其他网络(例如，网络309)可以由组织服务器304维护并自动与组织中维护的其他网络同步。例如，组织可以具有“销售员”网络312和另一称为“客户”的网络314。客户网络314可被定义为对销售员网络312可见(如路径316所示)，并且系统可以负责将客户网络314的更改传送给销售员网络312中的移动客户端302，如路径318所示。
在此描述的文档流框架利用了资源的概念。资源可以是数据的任何集合(例如，表格式数组)，如公司的“产品列表”和/或诸如图像的二进制数据。表单可以在其用户接口窗口小部件中使用本地可用的资源。例如，“定单”表单可以显示其从产品列表资源取回的产品选择列表。图4的框图中示出了可以如何配置资源的示例，其示出了图3所示的示例移动客户端302和组织服务器304的其他方面。
可以以与网络类似的方式来控制资源的管理和可见性。资源可以由移动客户端302本地地管理，或者可以由可定义该资源对给定网络的可见性的组织来管理。系统负责将更改的资源发送到其中使资源可见的网络。组织可以在组织服务器304处管理资源并因此将资源同步到整个给定网络。例如，产品列表资源402可以对“客户”网络314可见，如路径404所示。在此情况下，所有客户(例如，客户端302和用户406-407)都看到同一产品列表402。
有时可能必须对可分步到不同网络的资源创建动态管理的视图。在此情况下，表格式资源格式可以被逐行标记为在不同网络中可见。例如，组织可以将客户分为“关键客户”和“常规客户”。在此情况下，产品列表402中的某些列可被标记为仅对“关键客户”可见。
如前所述，在此描述的文档流框架描述了将任务管理文档组织成“线程”，其中每个线程都对应于业务过程。此类框架适于在以上根据图1A、1B和2-4示出和描述的上下文和环境中使用。在以下的段落中，示出和描述了文档流框架的特定具体实施方式
。
现在参考图5，框图示出了根据本发明的示例实施例的各种文档数据结构。框502代表文档流框架的文档。文档502可以被分成元数据504和业务数据506，如针对图2中的文档202描述的。以下描述的各种实施方式可以涉及在元数据5034中包括含有状态描述的状态更新字段508。状态描述可以是未做改变而示出给用户的人工可读的描述，和/或可以是由客户端映射到人工可读的描述的标记(token)。前者允许自由形式的状态描述(如“48％的定单已完成”)，而后者使得允许容易地定位，并且状态描述随文档流中的用户角色而改变(例如，客户可以看到状态“已接收的每件事务”，而供应方看到状态“已发送的每件事务”)。还可以使用两者的组合，其中提供标记和自由形式的描述两者，例如，标记为“正在进行中”，自由形式的描述为“48％”，并且客户端组合这两者以形成状态字符串“定单正在进行中(48％)”。注意，代替单独的状态更新字段508，还可以使用元数据504中的文档类型字段514。在此实施例中的文档类型514用作由客户端映射到人工可读状态描述的标记。这可能需要针对每个导致线程状态改变的文档使用单独的文档类型，但是可以不必需要单独的状态更新字段508。
可以通过在配置中为每个角色单独列出线程状态来处理线程完成，所述线程状态意味着从该角色的角度而言线程已经完成。可选地，每个文档可以携带有“线程完成”标志510，如果如从高级视图所见的，文档完成了整个线程(例如，对于过程流的所有贡献者而言已完成)，则标志510可以被设置为真。在此情况下，文档发送者必须知道对于接收者而言文档是否完成了线程。尽管这可能是可行的，但是更容易的是每个客户端只需知道其自己的角色，而不是必须知道每个其他客户端的角色。但是，某些客户端可能至少偶尔地对所有角色的完成感兴趣，如高级管理者或系统管理员。在此情况下，可以为特定角色中的常规查看过滤完成状态，其中状态仅反映与该特定角色有关的完成。特定客户端可以自动地或基于特定的请求查看反映所有角色的完成状态的复合完成状态。
注意，可以允许线程更改状态，即使是在线程已被完成之后。例如，在票已被发送的情况下，旅行预定线程可以被视为已完成(从旅行者的角度)，但是在此之后仍可以改变线程状态以指示已对旅行代理的发货清单付款。在另一示例中，如果航空公司取消或更改了航班并且需要发出新票，则可以相应地更新线程状态。
可以以多种方式处理经由线程完成标志510更新嵌套线程的状态，包括1)将状态更新传送到所有先辈线程；2)将状态更新限于文档所属的线程；和/或3)仅在文档完成直接的父线程时才将状态更新传送到所有先辈线程。第一种可选方法可以显示细粒度的状态，与正在访问哪个线程无关。但是，此类详细状态可能包括与特定角色的总体过程状态不相关的信息。例如，可能无需此类详细状态或此类详细状态与特定先辈线程无关。第二种可选方法可以提供较简单的视图，但是子线程中的更改(甚至完成子线程)不能更新父线程的状态。第三种可选方法是一种折衷，在许多情形下可以相对良好地工作。例如，当只有一级嵌套时选择性状态传送可以很有用，并且仔细地选择线程状态描述以便同一描述对于子线程和父线程都有意义。
每个文档还包含时间戳511，所述时间戳通常指示了与文档操作关联的日期/时间。例如，线程的状态可以由线程中具有最晚的时间戳511的文档的状态更新字段508来确定。时间戳511可用于指示一个或多个文档创建、修改、批准、提交、删除、归档等的日期/时间。
可包括在文档502中的其他元数据504包括服务ID 513。服务ID 513描述了文档所属的服务，例如，旅行预定服务、家庭清洁服务、维修服务等。在移动用户接口中，每个已安装的服务可以存在单独的部分，并且在此情况下，服务ID 513可用于确定文档应出现在哪个部分中。服务ID 513还可以用作文档类型514的一种名称空间，以便可以在不知道所有现有文档类型的情况下分配文档类型514。文档502可以包括线程ID 513，其可以包括对形成线程的特定业务任务集合的内部/外部引用。文档类型514可以指示文档数据格式、为之使用文档的业务任务、文档子类型(例如，购买定单-服务、购买定单-资金等)、文档名称等中的一个或多个。类似地，线程类型516可以在较高级别(例如，购买、工程、销售)或在较细致的粒度级别(例如，工程请求报价原型材料)指示文档的线程的类型。
元数据504还可以包括一个或多个线程描述符517。线程描述符517可以包括线程的文字描述(例如，线程主题)并且还包括其他元数据项(例如，线程ID 513、父线程ID、线程类型516、父线程描述符，和/或先辈线程描述符)的组合。后两个被表示为相关线程数据520。在过程是分级的情况下(例如，线程“嵌套”，其中一个过程是父过程的子线程)，此指示符520可以标识父/子线程并用于适当地显示和更新状态的目的。其他过程可以并行地发生而不必一定需要分级关系。在此情况下，相关线程数据520可以指示线程间的同辈类型的关系。
角色描述符518可以包括对可能与文档有关的业务模型中定义的一个或多个角色的引用。描述符518中列出的角色无需限于处理文档502的那些角色。例如，诸如审计和质量保证之类的某些业务功能相对于不实际处理文档502的业务过程而言可以具有监督角色。角色描述符518可以与其他元数据504相组合，以便用于诸如过滤/传送状态更新508和线程完成510之类的目的。角色描述符518还可以包括允许将状态数据(例如，数据508、510)直接或间接传送到执行这些角色的个体的地址。可以发生此类更新以响应业务过程的实体创建/修改文档502。
如以下(例如，根据图8-9)将更详细描述的，状态更新指示符508只是确定任务/文档/线程状态的一种方法。代替状态更新指示符508或除了状态更新指示符508以外，元数据504可包括状态标签522和/或一个或多个状态表524。标签522可以定义(单独地或与表524结合)对文档或任务的状态更改如何被映射到线程状态更改。标签522可以包括状态更改如何流动(例如，如在以下的列表1中)或如何用作对提供这些输出(例如，如在以下的表1中)的状态表524的查找的规则。注意，元数据504可以携带有可应用于特定过程中的多个角色的状态数据508、522、524。因此，可以基于角色描述符518针对每个特定角色定制经由元数据504对线程/任务/文档状态的更改的最终传送。
文档502包括促进过程线程的特定任务的业务数据506，并且此数据506可以包括诸如文本、图像之类的用于呈现文档502以用于其期望目的的呈现数据526。随着文档502在各种实体和角色之间被移动，该文档可以适于接受附加用户输入数据528。用户输入数据528还可以由系统监视并用于更新元数据504。例如，对于包括复选框的呈现数据526，复选框的选择可以被本地存储为用户输入数据528并且还可以用于改变在元数据504中维护的状态。
字段描述符530(其可能对用户可见，也可能不可见)可以帮助来自文档的数据526、528的输入、解析和提取。例如，在针对多种语言定制文档的情况下，此类描述符530可以很有用。字段描述符530可以对所有本地化的版本都是公共的，从而便于为了诸如修改元数据504之类的目的而提取用户输入数据。
还作为业务数据的一部分示出的是表单/模板/操作532，其可显式地包括捕获业务过程的某些信息的功能。此数据532可以被包括为其他用户数据526、528、530的一部分，或者可以被视为单独的实体。例如，可以从仅包括模板数据532的模板形成文档502，并且此模板532与用户输入结合使用以便形成文档502的初始元数据504和业务数据506。模板数据532可以仍保留在文档502中，例如用于生成附加文档或子文档。在另一示例中，此数据532可以包含基于用户输入和/或其它系统事件而作用于其他数据526、528、530的处理器可执行代码(例如，脚本、嵌入式二进制对象)。
图6-7的框图中示出了根据本发明示例实施例的如何使用此嵌入文档元数据的示例。在图6中，各种角色(例如，批准者602)被示为有向图的顶点，文档(例如，已批准的计划604)被示为图的边。图6中的图涉及支持旅行计划和票务预定的文档流的特定示例。具体地说，针对处理旅行计划和票务购买操作中的多个步骤的秘书606的角色定制文档管理系统的视图(例如，视图608)。
当秘书606接收到已批准计划文档604时，他/她的用户接口将显示线程式文档流，如框608中所示。十字形符号610表示线程，而纸状符号612表示属于该线程的文档。注意，虽然线程在此示为完全打开的树视图，但是它们还可以被每次一级地显示，类似于文件系统那样。后者在移动设备(有限的水平屏幕空间使得缩进较为困难)上可以更好地工作。框614、616示出了替代视图的示例。在视图614中，分级的选定级别(此处为线程级别)在左侧面板618中示出，选定级别之下的项在右侧面板620中示出。在视图616中，每个分级级别以“单调”视图(“flat”view)显示，具有指示当前“容器”的标题部分622和显示该容器内的所有项的列表部分624。用户通过选择控件626来向上导航并且通过选择列表624中的项来向下导航该层级。还可以使用适合解决方案域和目标用户接口的本领域中公知的其他视图(例如，有向图、注释列表等)。
在此实例中，建立旅行线程610以便查看与秘书角色有关的过程。因此在此情况下，当秘书606接收到已批准计划文档604时，将创建旅行线程610。尽管可以构想由某种较早的事件(例如，当旅行者630将初始计划628提交给批准者602时)创建旅行线程，但是此线程对于秘书606是特殊的，秘书606可能全然不知文档628。
已批准计划文档604包含旅行线程的描述符，其可以包括线程的主题(“旅行”)、唯一线程ID，以及可能包括该线程的父线程的ID(在嵌套线程的情况下)。由于这是客户端606接收到的属于该线程的第一个文档，所以在客户端606上未发现任何对应的线程，将创建新的线程并将文档附加到该线程。从状态更新字段(例如，图5中的字段508)设置新的线程的状态(在与图标610关联的文本中的引号内示出)。在附随图标612的描述性文本中的括号内示出了状态更新字段的内容。注意，视图608中示出的加括号的文本以及箭头是为了显示文档612的状态更新与线程610的状态之间的关系/更新，其不必是用户接口的一部分。
接着，秘书606打开已批准计划文档604。用于打开该文档的表单允许秘书606向旅行代理636的预定角色634发送定票请求文档632。该表单将旅行线程描述符复制到新的文档632。在此示例中，过程的此部分(例如，由代理636执行的步骤)被模拟为创建服务时的子过程。因此，表单还将新的线程描述符“定票”附加到文档632、将新的线程描述符标记为文档532的直接父辈，并且将旧的“旅行”线程描述符标记为新的线程描述符的父辈。状态更新字段(例如，图5中的字段508)被表单设置为包含文本“票已定”。
图7的视图702中示出了所得到的用户接口(例如，基于视图608的更新后的接口)的实施例。新的线程704被示为线程610的孩子，新的线程包含票务请求文档706。与文档706关联的图标706(例如，内部具有箭头的纸状符号)表示已发送的文档。与视图608一样，视图702中的加括号的文本和细箭头示例了状态传送并且不必存在于用户接口中。注意在视图702中，如何通过定票请求706的状态来更新定票线程704的状态，但是该更新未传送到旅行线程702。
返回参考图6，包含票和发货清单的文档637从旅行代理636到达。图7的视图708中的图标710反映了此文档637。从视图708还可以看到，基于票务和发货清单文档710的状态更新字段而更新了定票线程704A的状态。由于“收到票”状态意味着定票线程完成(基于一个或多个表示线程完成的状态值的经配置的角色特定列表，和/或文档元数据504中的线程完成标志510)，线程704A被标记为完成。由于线程704A的更改状态还包括线程完成(例如，通过设置如图5中所示的线程完成标志510)，所以状态更新被传送到父辈旅行线程610A，现在父辈旅行线程610A反映文档710的状态。注意，仅为最后的消息示出了显示状态更新字段内容的加括号的文本。
返回参考图6，秘书606接着打开票务和发货清单文档637。用于打开文档的表单可以包括用于将票638转发到旅行者630的按钮。秘书检查信息，然后按下“转发给旅行者”按钮。表单知道新的票务文档不属于定票线程，并从票务文档删除定票线程描述符并使剩余的旅行线程描述符成为该文档的直接父辈。这在图7的视图712中示出。用户接口组件714表示票被发送给旅行者，并且组件714指示文档的状态更新字段被设置为“票已递送”。由于票714是最新的文档组件，所以旅行线程610B的状态现在变为“票已递送”。
再次返回参考图6，秘书606稍后处理所有发货清单(例如，在月底)。通过再次打开票务和发货清单文档637来完成，但是这次按下“转发到清算帐目”。表单要求秘书填写预算相关的信息(费用代码、评估等)，并且在完成后将发货清单文档640发送给清算帐目642。此时(基于不同按钮的使用)表单将新的文档的状态更新字段设置为“发货清单已发送”。此新的文档在图7中示为视图716中的组件718。基于表示线程完成的状态值的经配置的角色特定列表，和/或文档元数据504中的线程完成标志510，状态的更改导致旅行线程610C的状态更改并且对于秘书606，还将导致线程610C被标记为完成。
上述情形可能不能处理其中未定义文档到达顺序的情况。例如，假设旅行代理使用宾馆预定文档和航班预定文档两者来响应定票请求，但是顺序由先发现哪个文档来确定(例如，预先不知道哪个文档首先到达)。在此情况下的期望行为是当宾馆预定文档到达时，如果航班预定文档尚未到达，则线程状态变为“宾馆已预定”，但是如果航班预定文档已到达，则新的状态应为“预定完成”(因为航班和宾馆预定两者都已到达)。这可以通过使每个文档都包含若干状态更新字段(其中每个状态更新字段包含新的状态和当前状态的情况两者)来解决。以下的列表1中示出了此示例中接收到宾馆预定的情况的示例状态更新字段。
<状态更新当前状态＝“航班已预定” 新的状态＝“预定完成”/> <状态更新当前状态＝“票已定” 新的状态＝“宾馆已预定”/> 版权
2008，诺基亚公司 列表1 列表1中示出的示例的完整行为可以被模拟为有限状态机，其中由触发特定状态转变的基础文档(和/或文档状态)表示状态之间的转变。此解决方案可相当直接地实现，尽管其并非总是很好地适合以不确定顺序到达的文档的数量。必须为所接收文档的每个可能组合给出状态描述，因此n个文档所需的描述总数为
(例如，对于n＝5，所需描述的数量是31) 文档描述框架中的另一个可能期望的特性是对于先辈线程具有不同的状态描述，并且支持在子线程中间改变父线程状态。例如，如果旅行代理在单独的文档中发送票和发货清单，并且有时票在发货清单之前到达，则只要票已到达，旅行线程就将状态更改为“定票已结束”可以是有意义的，尽管由于缺失发货清单文档，定票线程自身在技术上并未完成。其可能不支持对于先辈线程具有不同的状态描述。例如，在接收到发货清单之后，定票线程完成，所以其状态成为“已结束”将是有意义的，但是并不能使用该状态，因为此时父线程的状态不能被描述为“已结束”。
为了提供此附加的灵活性，替代状态描述(或除了状态描述之外)，每个文档可以携带一个或多个标签。每个标签对应于过程中已发生的事件。当包含标签的文档到达时，线程将接收到该标签，并且该线程是文档的直接父辈。每个线程都留意其接收到哪些标签，以及其接收到每个标签多少次。
用于将标签转换为状态的规则可以包括在客户端配置中。为了将规则映射到线程，表征线程是所希望的，例如，使线程描述符还包含线程的类型。这类似于如何指示文档的类型，如通过文件名扩展、文件系统元数据，以及嵌入文件中的元数据。与旅行线程示例相关的配置然后可以包含类似于下表1中的下列状态的信息。
表1 将理解的是，图1中的表格表示是为了易于阅读而提供的示例实施例。在文档框架中，可以使用计算机可读和可解析的数据结构和/或指令，如可扩展标记语言(XML)代码、二进制数据格式、嵌入式二进制对象(例如，JavaTM小应用程序)、链接列表、散列集合等。跟踪线程状态的客户端(或其他实体)可以在每次线程的标签发生更改时参考例如表1所示的数据结构。客户端可以按照顺序(从上到下)遍历表的各行并使用与线程类型、角色以及标签匹配的第一行以便确定应采取的操作。线程类型列给出了线程应匹配的线程类型。角色列给出了线程中的用户/参与者需要匹配的角色，并且状态列给出了线程的新的状态。传送到父辈给出了应被添加到匹配线程的父线程的标签列表。如果完成列为真，则匹配线程应被标记为完成。标签给出了线程必须匹配的标签计数的列表。计数区间(最小-最大)可以被附加到每个标签，并且如下表2所示，通过使用预定义的简写，可以全部地或部分地省略这些区间。
表2 注意，根据这些规则，为(0)的计数区间简写意味着标签不出现在线程中，并且无区间意味着标签必须至少出现一次。通过以状态进展逆序来列出状态，在多数情况下可以省略使用(0)区间(其仅在预先不知道状态进展顺序时才需要)。例如，如果“等待票”状态的行是第一行而不是第四行，则可能必须在标签列中使用“计划已批准，票已接收(0)”，而不是仅使用“计划已批准”。
在类似课程注册的情况下区间很有用，在课程注册中，可能希望具有状态“空”(0次注册)、“参与者过少”(1-9次注册)、“已确认”(10-20次注册)，以及“预定过多”(21或更多次注册)。除了标签以外，文档还可以携带有诸如“48％完成”之类的自由形式的状态描述。其将被附加到直接父线程的状态描述，但是无需传送到先辈线程。
现在参考图8和9，框图包括根据本发明替代示例实施例的文档管理框架的视图。图8和9中的用户接口视图显示了图6所示的票务预定情况的线程状态。此示例利用了通过使用如表1所示的标签而提供的灵活性。
如视图802所示(以及类似于图6所示的情况)，在接收到已批准计划文档时创建旅行线程。从文档的标签(在括号中示出)复制新的线程的标签(在括号中示出)。通过将线程的标签与状态表相匹配来确定线程的状态(在引号中示出)。顺序地检查每行，并且第一个匹配的行被应用。在此情况下，表1的行4匹配并且线程状态被设置为“等待票”。
接着，秘书打开已批准计划文档。用于打开文档的表单允许秘书向旅行代理发送定票请求文档。该表单将旅行线程描述符复制到新的文档。由于在创建服务时这被模拟为子过程，所以表单还将新的线程描述符“定票”附加到文档，将新的线程描述符标记为直接父辈，并且将旧的旅行线程描述符标记为新的线程描述符的父辈。新的文档的标签被设置为“票已定”。视图804中示出了得到的用户接口。注意在视图804中(如箭头所指示的)，新的文档(定票请求)如何更新定票线程的标签列表。通过与表1的行8匹配来确定线程的结果状态(票已定)。
在此用例中，旅行代理可以在单独的消息中发送票和发货清单(它们可以以任意顺序到达)，或者代理可以在单个消息中发送两者(类似于先前在图6中示出的用例)。状态表考虑了所有这些情况。但是，允许单个消息携带票和发货清单两者意味着表1的行5传送票已接收标签，因而如果为票和发货清单两者使用一个消息，则旅行线程将接收到票已接收标签一次，如果使用单独的消息，则将接收到票已接收标签两次。因此，表1的行3指定票已接收可以出现1次或2次以匹配该行。表1中的区间(1-2)用于示例目的；在未给出区间时使用的缺省(1-无穷大)也可以使用。
在此示例中，票和发货清单单独到达。首先，包含票的文档从旅行代理到达。这在视图808中示出。基于票务文档的标签来更新定票线程的标签列表。将该标签列表与状态表1相比较，其中行7匹配“票已填写”标签。自由形式的文本“业务类别”被附加在圆括号中，所以定票线程的完整状态现在是“票已接收(业务类别)”。由于表1中的匹配行包含将标签票已接收传送到父辈，所以该标签被添加到父(旅行)线程。传送到旅行线程的新状态是“票已接收”，如箭头809所示。旅行线程现在匹配状态表中的第3行并且获得状态“定票完成”(从旅行线程的角度，在接收到票时定票可以是完成的，尽管定票过程可能尚未完成)。
接着，包含发货清单的文档从旅行代理到达，如视图808所示。基于发货清单文档的标签更新定票线程的标签列表。将该标签列表与状态表1相比较。表1的第5行匹配并且新的状态是“完成”。第5行上的完成标志为真，所以定票线程现在完成(图中标记有“已完成”)。圆括号中的自由形式文本“5000欧元”被附加到状态描述，所以定票线程的完整状态现在是“完成(5000欧元)”。由于状态表中的匹配行包含将标签票已接收传送到父辈，所以该标签被添加到父(旅行)线程，现在父(旅行)线程包含票已接收标签两次。旅行线程仍匹配状态表中的第3行，所以其状态不变(例如，保持“定票完成”)。
接着，秘书打开票务文档。用于打开文档的表单具有将票转发到旅行者的按钮。秘书检查信息，然后按下“转发到旅行者”按钮。表单知道该新的文档不属于定票线程，从新的文档删除定票线程描述符，并且使剩余的旅行线程描述符成为该文档的直接父辈。文档的标签被设置为“票已递送”，如视图810所示。由于发送的文档被添加到旅行线程，所以票已递送标签被添加到旅行线程的标签。线程现在匹配状态表中的第2行并且获得状态描述“票已递送”。
在月底，秘书处理所有的发货清单。这通过打开发货清单文档并按下表单中的“转发到清算帐目”按钮来完成。表单要求秘书填写预算相关的信息(费用代码、评估等)并且在完成后，将发货清单文档发送到清算帐目。表单将新的文档的标签设置为“发货清单已递送”。由于发送的文档被添加到旅行线程，所以发货清单已递送标签被添加到旅行线程的标签，如图9的视图910中所示。线程现在匹配状态表1中的第1行并且获得状态描述“发货清单已发送”。第1行上的完成标志为真，所以旅行线程现在也已完成(图中标记有“已完成”)。
如上所述，可以使用模板生成与文档流框架集成的文档。模板可以模拟业务过程和当前工作流状态的信息。通常，通过使用通用和易于定制的内容和工作流模板，可以使工作流更有效。例如，可以使用由工作流参与者创建和/或从过程流中的其他文档复制/继承的元数据描述(例如，XML格式的描述符)来定制工作流文档。可以使用诸如浏览器(例如，经由基于Web的向导)之类的标准工具来输入/收集此元数据。对于移动设备或其他具有有限处理和/或网络带宽的装置，作为第一步，系统可以仅传递具有选定内容的元数据。如果需要进一步的操作，用户可以选择是否下载额外的附件数据(例如，如在移动电子邮件中)。
用户或开发者可以使用易于使用的向导或文本编辑器(例如，在开发者的情况下)创建工作流模板。模板可以被创建为描述工作/文档流步骤以及其他规则的XML或可扩展超文本标记语言(XHTML)文档。可以向用户显示表单用于进一步的数据输入并且在完成后，文档可以通过流被转发给其他实体。文档可以包括描述工作流元数据的嵌入式XML、表单描述、线程描述、线程状态标签等。嵌入式XML在以下可以被描述为“票”，并且可以包括允许接收者根据业务过程规则对基础表单/文档进行操作的最小数据集合。
对于表单的每个字段可以存在若干属性设置。属性可以例如包括将特定数据字段(包括元数据和业务数据)设置为“嵌入”或“附加”。“嵌入”属性可以表示输入的数据(例如，名称、地址等)被在表单内部传递到下一步骤/接收者。“附加”属性可以表示暗示或提供了下载附件的“操作”。下载内容的选项对于移动用户可以是有益的，以便在接收到新的文档时改进响应时间。由服务器在运行中生成此类附件的唯一的统一资源定位符(URL)。
基于元数据和发送的内容，移动客户端可以在运行中生成用户接口(例如，充当类似基于XHTML的浏览器)。取决于模板中描述的角色和限制，工作流中的下一个人可以更改表单的允许字段的内容(例如，字段级许可可以包括“只读”、“添加到现有数据”、“修改”、“删除”等)。如果希望保护模板本身以及结果文档和元数据的多个部分(例如，工作流描述)，则可以通过数字签名来保护模板，例如，以便保护与过程关联的任务和文档以及过程的完整性。如以上详细说明的，可以通过文档创建、删除、修改等来改变对文档以及嵌入文档的元数据/与文档关联的元数据两者的更改。因此，动态生成的用户接口可用于产生文档的各种版本以供查看和/或编辑。此外，如以上结合图2所述，其中在接收的电子文档以外(例如，纸质文档)传送元数据的情况中，工作流模板也可用于创建用于修改和传送元数据的表单。例如，在个人查看和签署纸质文档时，其可以使用移动设备扫描文档上的条形码，使得设备可以以易于使用的格式(例如，选择按钮)访问和呈现元数据，以便可以相应地更新线程数据。
此种类型的模板可以1)定义预定义的工作流；2)提供“发起者”选项以执行特定工作流的步骤/任务的预定义列表以及向这些特定步骤/任务指派模板中描述的接收者；和/或3)对于工作流的每个步骤，提供对“接收者”的完全自由的搜索。“接收者”可以包括服务用户注册表中的用户名称、电子邮件地址，和/或短消息服务(SMS)号码的任意组合。作为服务的用户的接收者在连接到服务时将收到输入的票的通知。电子邮件用户可以接收具有到票的链接的电子邮件，并且SMS用户可以接收具有到票的链接的SMS，然后可选择票用于工作流客户端。例如，Java MIDlet可被配置为在新的SMS到达预定端口时自动启动。具有服务帐户的用户在使用客户端访问服务时将具有其已打开票的列表。
文档框架可以包括一个或多个服务器，所述服务器支持1)在其中搜索目标个人/实体并获取关于这些实体的相关信息(例如，业务过程中的角色)的用户注册表；2)用于存储模板、元数据以及附件数据的“服务”；3)文档接收者的设备中的“工作流引擎”，该引擎可以根据业务规则(其本身可以嵌入票中)接收票(以及可能地，票被嵌入其中的文档)并将其发送给下一接收者；4)“进展通知”服务，其通知过程发起者和其他定阅跟踪特定票/线程(例如，跟踪线程/子线程状态和完成事件)的成员；5)支持安全特性，如数字签名验证(例如，用于模板部分的完整性)、内容加密。在生成模板时，整个系统可以使用一个证书(例如，通过验证服务器验证)来对模板的所需部分签名，并进一步在工作流中每次提交模板/文档时对其进行验证。
可以使用支持XML解析和动态UI呈现的客户端来实现所述实施例的工作流客户端。此类客户端可以利用可替代技术。例如，Nokia WidSets(www.widsets.com)包括客户端和服务器组件两者并且能够支持票元数据的嵌入和动态呈现。WidSets允许开发者创建从Web取回信息的窗口小部件。可以使用WidSets脚本语言(WSL)在文本编辑器中创建窗口小部件以访问Web信息、提供功能性，以及控制窗口小部件的外观和效果。WSL类似于JavaTM编程语言并且使得开发者能够熟悉Java开发以快速和有效地创建窗口小部件。
在文档流框架的示例性实施例中，可以通过添加动态工作流引擎插件来扩展WidSets服务器，以便处理与文档存储/生成、线程状态管理、线程状态消息传送有关的各种集中式任务。在客户端侧，可以将“动态工作流窗口小部件”部署到客户端/移动设备。作为WidSets客户端技术的替代方案，可以使用其他技术。例如，也可以使用诸如“浏览器组件(BrowserComponent)”(该组件是S60和其他平台中的Web Runtime(WRT，Web运行时)窗口小部件的核心)之类的现有组件来完成客户端/移动设备中的表单呈现。WRT中支持JavaScript和Ajax(异步JavaScript和XML)，可用于处理表单输入提交以及处理请求的附件加载。
在其他实施例中，具有本地XML解析器的客户端的本地实现(例如，Symbian C++，S40C，Java，Maemo等)可以与“工作流引擎”服务连接。此类服务然后可以被宿主(host)为专用或公共Web服务。桌面客户端可以使用标准浏览器，Javascript(例如，具有特殊的工作流库)和/或Ajax。将理解的是，提供这些特定用户接口技术的描述是为了示例而非限制。
如上所述，由于实施例可以利用嵌入式工作流元数据，所以并非业务过程中的每一个步骤/任务都需要服务器连接来推进工作流和/或向线程和文档状态传送更改。例如，可以通过将票传递给嵌入式工作流中的下一步骤，来本地地和/或经由对等体更新状态数据。当更有能力(例如，更大处理/网络带宽)的工作流客户端处理票时，该客户端则可以将未决进展更新发送给服务。还可以通过发布到URL(类似于http://..../wfstep？workflow_id＝123&step＝7)来向服务器报告流的进展。在客户端的情况下，可以通过发送具有类似内容的SMS来完成此类报告，如果工作流所有者对每步报告进展的操作者感兴趣的话。还可以通过服务器(推送或拉回)、电子邮件、SMS、多媒体消息传送服务(MMS)等向前传递票，只要接收设备具有可以取回并理解票的客户端。
如果工作流模板在XML中，则可能存在能够编写新的模板的管理员、用户和/或开发者。参与标准或公知业务过程的实体可以具备现成的模板以便在这些情况下(例如，端用户安排娱乐事件，其中不同的参与者都具有某些安排职责)准备好部署。可以经由基于Web的向导来完成这些现成模板和业务/文档流逻辑的生成/定制。在此类向导中，端用户可以输入步骤的数量、每个步骤的描述文本以及操作，并且添加每个步骤的负责人员(来自地址薄的联系信息)。此外，如果需要，用户可以通过勾选复选框来激活来自选定步骤的反馈。可以在向导的更高级的模式中添加诸如转移线程、标识子线程以及同步线程/子线程的更高级的特性。还可以使用其他类型的输入，如通过使用GUI构建定义业务过程的有向图(例如，如图6所示)。
端用户可以使用许多类型的装置来处理如在此所述的文档流。例如，用户越来越多地使用移动电话作为其主要或辅助计算设备。现在参考图10，示例了能够执行根据本发明示例实施例的操作的代表性用户计算设备1000的示例实施例。本领域技术人员将理解，示例用户计算设备1000只是代表可以与此类用户装置关联的通用功能，还将理解，固定计算系统类似地包括计算电路以执行此类操作。用户计算设备1000可以例如是移动计算设备、移动电话、移动通信设备、移动式计算机、膝上型计算机、台式计算机、电话设备、视频电话、会议电话、电视装置、数字录像机(DVR)、机顶盒(STB)、无线电装置、音频/视频播放器、游戏设备、定位设备、数码相机/摄像机等，或它们的任意组合。此外，用户计算设备1000可以包括图2-4所示的用户装置的特性并且可用于显示如图6-9所示的用户接口视图。
处理单元1002控制设备1000的基本功能。这些关联的功能可以被包括为存储在程序存储装置/存储器1004中的指令。在本发明的示例实施例中，与存储装置/存储器1004关联的程序模块存储在非易失性电可擦除可编程只读存储器(EEPROM)、闪速只读存储器(ROM)、硬盘驱动器等中，以便在移动设备断电时不会丢失信息。用于执行根据本发明的移动终端操作的相关软件还可以通过计算机程序产品、计算机可读介质来提供，和/或通过数据信号被发送给移动计算设备1000(例如，通过一个或多个网络(例如，互联网和中间无线网络)电子地下载)。
移动计算设备1000可以包括耦合到处理/控制单元1002以便执行网络数据交换的硬件和软件组件。移动计算设备1000可以包括多个网络接口以便维护有线或无线数据连接的任意组合。示例的移动计算设备1000包括无线数据传输电路以便执行网络数据交换。此无线电路包括数字信号处理器(DSP)1006，其用于执行各种功能，包括模数(A/D)转换、数模(D/A)转换、语音编码/解码、加密/解密、检错和纠错、码流转换(bit streamtranslation)、过滤等。通常连接到天线1010的收发器1008发送输出的无线电信号1012并接收与无线设备关联的输入的无线电信号1014。这些组件使得设备1000能够加入一个或多个通信网络1015，包括移动服务提供商网络、本地网络，以及诸如互联网和PSTN的公共网络。
移动计算设备1000还可以包括耦合到处理/控制单元1002的可选网络/数据接口1016。可选网络/数据接口1016可以包括使用任何方式的数据传输介质(包括有线和无线介质)经由辅助数据路径进行通信的能力。可选网络/数据接口1016的示例包括USB、蓝牙、以太网、1002.11 Wi-Fi、IRDA、超宽带、WiBree等。这些替代接口1016还能够经由网络1015或经由直接和/或对等通信链路进行通信。
处理器1002还耦合到与移动终端关联的用户接口硬件1018。移动终端的用户接口1018可以例如包括诸如液晶显示器之类的显示器1020和变换器1022。变换器1022可以包括任何能够接收用户输入的输入设备。变换器1022还可以包括能够产生媒体(如文本、静止图片、视频、声音等的任意组合)的传感设备。其他用户接口硬件/软件可以包括在接口1018中，如键区(keypad)、扬声器、麦克风、语音命令、开关、触摸板/屏、指点设备、轨迹球、游戏杆、振动发生器、光源等。如现有技术中所知的，这些和其他用户接口组件耦合到处理器1002。
程序存储装置/存储器1004包括用于执行移动计算设备1000上的功能和与功能相关的应用的操作系统。程序存储装置1004可以包括下列中的一个或多个只读存储器(ROM)、闪速ROM、可编程和/或可擦除ROM、随机存取存储器(RAM)、用户接口模块(SIM)、无线接口模块(WIM)、智能卡、硬盘驱动、计算机程序产品、或其他可移动存储设备。移动计算设备1000的存储装置/存储器1004还可以包括用于执行根据本发明示例实施例的功能的软件模块。
例如，程序存储装置/存储器1004包括文档接口1024，其被配置为经由一个或多个网络接口1026发送和/或接收与过程相关的文档。网络接口1026可以包括用于处理一个或多个公共网络数据传输协议(例如，HTTP、文件传输协议(FTP)、简单邮件传输协议(SMTP)、SMS、MMS等)的软件模块。文档解析器1028可以对输入和输出的文档上的数据结构执行操作(例如，解析、编码、解码、验证、认证)，这使得能够在文档用户接口1030上呈现文档。文档用户接口1030还可以接受用户输入以便修改文档，并且解析器1028可以基于这些输入更新文档的数据结构。
如以上所述，文档通常包括嵌入式元数据，其用于跟踪其中使用了文档的业务过程的状态。此元数据可以借助文档接口1024被直接传送到设备1000，并且元数据处理器1032可以独立于文档解析器1028而处理元数据。元数据的一个用途是跟踪和更新文档、任务以及线程的状态，这借助线程跟踪用户接口1034在设备上直接示出。线程跟踪用户接口1034可以显示过程/任务流状态，如图6-9的示例视图中那样，并且独立于文档用户接口1030。
文档/任务/线程状态的确定可以取决于针对特定情况定义的特定角色1036和规则1038。角色1036可以影响线程跟踪用户接口1034如何向特定用户显示状态，以及可能限制可以经由文档用户接口1030采取的操作。规则1038可以限定在过程的不同角色之间发生的文档流并且还可以限定响应于输入的文档而采取的本地步骤。例如，处理输入的文档可能需要例如经由模板数据库1040和/或经由嵌入在文档自身中的数据/模板来生成附加的文档。规则1038可以进一步限定业务过程网络的哪些其他实体1044(例如，客户端、服务器)应是接收这些文档的目标。
如以上详细说明的，由设备1000处理的文档自身可以包括通过文档传输传送给其他实体1044的过程状态的自含式指示符。在其他布置中，元数据接口1042可以使用带内或带外机制来向其他实体1044传送元数据(其通常指示过程状态)。处理器1032可以基于本地处理的文档内包括的数据以及经由角色和规则数据库1036、1038确定的目标地址/协议的任意组合来引导接口1042传送此数据。
图10的移动计算设备1000被提供为其中可以应用本发明原理的计算环境的代表性示例。根据在此提供的描述，本领域技术人员将理解，本发明同样可应用于各种其他当前已知和未来的移动和陆线计算环境。例如，台式和服务器计算设备类似地包括处理器、存储器、用户接口以及数据通信电路。因此，本发明可应用于任何已知的其中可经由网络传送数据的计算结构。
现在参考图11，框图示出了根据本发明示例实施例的提供集成任务和文档管理服务的网络服务1100的细节。服务1100可以通过一个或多个常规计算设备1101来实现。计算设备1101可以包括定制或通用电子组件。计算设备1101包括一个或多个中央处理器(CPU)1102，中央处理器(CPU)1102可以连接到随机存取存储器(RAM)1104和/或只读存储器(ROM)1106。ROM 1106可以包括各种类型的存储介质，例如可编程ROM(PROM)、可擦除PROM(EPROM)等。处理器1102可以通过输入/输出(I/O)电路1108与其他内部和外部组件通信。处理器1102可以包括一个或多个处理核心，并且可以包括位于独立功能性模块(例如，芯片组)内的通用和专用处理器的组合。如本领域所知，处理器1102执行由固定逻辑、软件指令和/或固件指令规定的各种功能。
计算设备1101可以包括一个或多个数据存储设备，包括可移动盘驱动器1112、硬盘驱动器1113、光盘驱动器1114，以及其他能够读取和/或存储信息的硬件。在一个实施例中，可以在光介质1116、磁介质1118、闪存1120或其他形式的能够便携地存储信息的介质上存储和分发用于执行根据本发明的操作的软件。这些存储介质可以被插入诸如光盘驱动器1114、可移动盘驱动器1112、I/O端口1108之类的设备并由其读取。软件也可以通过数据信号被发送到计算设备1101，例如通过诸如互联网之类的网络被电子地下载。计算设备1101可以被连接到用户输入/输出接口1122以便进行用户交互。用户输入/输出接口1122可以包括诸如鼠标、键盘、麦克风、触摸板、触摸屏、语音识别系统、监视器、LED显示器、LCD显示器等的装置。
服务1100配置有可存储在存储器1104和永久性存储装置(例如，硬盘驱动器1113)的任意组合上的软件。此类软件可以包含在固定逻辑或只读存储器1106中，或通过便携计算机可读存储介质和计算机程序产品(包括诸如只读存储器磁盘、光介质、闪存设备、固定逻辑、只读存储器等的介质)置于读-写存储器1104内。软件还可以通过与输入-输出总线1108耦合的数据传输链路被置于存储器1106中。此类数据传输链路可以包括有线/无线网络接口、通用串行总线(USB)接口等。
软件通常包括指令1128，指令1128导致处理器1102与其他计算机硬件一起工作以提供在此所述的服务功能。指令1128包括促进与业务过程网络1134的实体1132的通信的网络接口1130。网络接口1130可以包括硬件和软件组件(包括介质访问电路、驱动器、程序以及协议模块)的组合。网络接口1130还可以包括用于处理一个或多个公共网络数据传输协议(例如，HTTP、FTP、SMTP、SMS、MMS等)的软件模块。
网络接口1130可以是支持元数据和文档接口1136、1138的特定功能的通用模块。文档接口1138被配置为与网络实体1132交换过程相关的文档。在一个实施例中，服务1100可以通过储存库1140促进中央文档存储。类似地，模板储存库1150可以提供对实体1132所使用的模板的中央访问以便为特定处理任务生成文档。服务1100可以包括管理文档的存储、生成以及路由的文档处理器1142。如上所述，文档通常包括用于跟踪其中使用文档的业务过程的状态的嵌入式元数据。可以借助文档接口1142与服务交换此元数据，并且工作流引擎1144可以独立于文档处理器1142来处理元数据。元数据的一个用途是跟踪和更新文档、任务以及线程的状态，并且可以借助文档自身和/或元数据接口1136将状态传送给客户端(例如，图10中的装置1000)。尽管服务1000可以在没有直接用户接口硬件的情况下工作，但是服务1100也可以配置有用户接口(未示出)，所述用户接口允许跟踪此类元数据和文档(例如类似于图10中的UI 1030、1034)。
工作流引擎1144可以基于针对特定任务管理情况定义的特定角色1146和规则1148来确定文档/任务/线程的状态。角色1146可以影响如何传送线程状态更改以及可能限制实体1132可以对特定文档采取的操作。规则1146可以限定过程的不同角色之间发生的文档流，并且还可以限定特定实体1132(或服务1100自身)响应于输入的文档而采取的步骤。例如，对输入的文档的处理可能需要生成附加的文档，例如经由模板数据库1050和/或经由嵌入在文档自身中的数据/模板。规则1148可以进一步限定业务过程网络的哪些其他实体1132(例如，客户端、服务器)应是接收这些文档的目标。
如以上详细说明的，由服务1100处理的文档自身可以包括通过文档传输传送给其他实体1132的过程状态的自含式指示符。在其他布置中，元数据接口1136可以使用带内或带外机制来向其他实体1132传送元数据(其通常指示过程状态)。工作流引擎1144可以基于本地处理的文档内包括的数据以及经由角色和规则数据库1146、1148确定的目标地址/协议的任意组合来引导接口1136传送此数据。
服务1100可以包括其他支持业务过程的集中式功能。例如，可以使用验证数据库1152来确保文档完整性、实施对文档1140和模板1150的编辑限制、帮助文档加密等。由工作流引擎1144管理的任务/文档/线程状态还可用于更新遗留业务过程数据库1154。
出于示例目的，根据进行交互以提供特定结果的功能电路/软件模块描述了服务1100的操作。本领域技术人员将理解其他功能模块布置也是可能的。此外，本领域技术人员使用本领域通常公知的技术可以容易地在模块级别或在整体上实现此类描述的功能。计算结构1101只是可用于提供如在此所述的基于文档流的服务的网络基础设施硬件的代表性示例。通常，计算服务1100的功能可以遍及大量处理和网络元件，并且可以与其他服务(如Web服务、网关、移动通信消息传送等)集成。例如，服务1100的某些方面可以通过客户端-服务器交互、对等交互、分布式计算等在用户设备(和/或诸如图2所示的服务器204-207之类的中间物)中实现。
现在参考图12A，流程图示出了根据本发明示例实施例的显示线程状态的过程1200。该过程涉及标识1202线程以响应业务过程的电子消息传送操作。线程可以至少包括总体地描述业务过程的相关任务的状态和关系的数据。生成1204线程的状态以响应电子消息传送操作，其中线程的状态代表业务过程的状态。促进1206用户接口呈现线程以响应电子消息操作。可选地，可以基于线程状态的改变来更改1208线程的显示。
现在参考图12B，流程图示出了根据本发明示例实施例的设置文档元数据的过程1220。该过程涉及标识1222包括数据的线程，所述数据总体地描述业务过程的相关任务的状态和关系。标识1224与业务过程有关的线程的状态。在业务过程的电子文档中设置1226元数据，使得元数据描述线程的状态。经由业务过程的电子消息传送操作传送1228元数据。
现在参考图13A，流程图示出了根据本发明示例实施例的过程1300。过程1300涉及促进1302向电子文档应用更改线程状态的用户操作。线程至少包括总体地描述业务过程的相关任务的状态和关系的数据。更改1304电子文档的元数据以反映线程的更改后的状态。经由业务过程的电子消息传送操作传送1306更改后的元数据以更新线程的更改后的状态。
现在参考图13B，流程图示出了根据本发明示例实施例的过程1320。过程1300涉及根据与业务过程的执行中使用的电子文档相关的元数据确定1322线程。线程至少包括总体地描述业务过程的相关任务的状态和关系的数据。确定1324线程的用户角色数据并且促进1326由业务过程的参与者处理电子文档。通过与业务过程中的参与者的用户角色相关的用户角色数据来管理电子文档的处理。
现在参考图14，流程图示出了根据本发明示例实施例的过程1400。过程1400通常包括接收文档1402，线程(例如，业务过程的多个链接/相关的事务)中涉及所述文档。从文档的元数据确定1404线程标识符。如果确定1406线程尚不存在(例如，未由处理文档的实体本地地记录)，则创建1408新的线程。创建1408通常涉及创建实现跟踪线程及其状态的元数据。
处理文档的实体可以根据元数据设置1410线程状态并确定作为线程状态更新的目标的实体(例如，线程中的下游/上游参与者)。如果确定1412用户编辑文档，则用户接口可以促进1414编辑文档。在某些情况下，业务过程可以包括基于所接收的文档创建新的文档。如果确定1416创建了新的文档，则将元数据(例如，新的数据和/或从接收的文档得到的数据)插入1418新的文档并且促进1420编辑。注意，编辑1420是可选的；可以自动生成文档而无需任何用户编辑。
循环1422在每个更新目标和文档之间重复。如果确定1424编辑当前文档和/或创建新的文档导致线程状态更改，则将更改应用1426于文档元数据。如果更新目标被确定1428为是直接文档接收者，则文档可以被发送1430给该目标。否则，可以经由常用信道将线程状态和元数据发送1432给目标。可以借助带外机制(例如，在文档之外传送)来进行元数据的这种发送1432。在另一种情况下，实体可以最终(尽管不是直接地)接收到文档，在此情况下，可以通过将文档发送1430给线路中的下一接收者(假设文档最终将到达目标)来完成传送1432状态。注意，并非过程中的所有参与者都需要被通知更新或作为更新的目标。例如，某些参与者只需查看其自身处理的文档的线程状态。
出于示例和描述目的提供了本发明示例实施例的以上描述。其并非旨在是穷举的或将本发明限于所公开的精确形式。根据上述教导，许多修改和变化都是可能的。本发明的范围并非旨在由此详细描述来限制，而是由在此所附的权利要求来确定。
权利要求
1.一种设备，包括
标识线程以响应过程的电子消息传送操作的装置，其中所述线程包括总体地描述所述过程的相关任务的状态和关系的数据；
生成所述线程的状态以响应所述电子消息传送操作的装置，其中所述线程的状态代表所述过程的状态；以及
帮助用户接口呈现所述线程以响应所述电子消息传送操作的装置，其中所述呈现指示所述线程的状态。
2.根据权利要求1所述的设备，其中所述电子消息传送操作包括基于为所述过程的所述任务建模的工作流模板创建文档元数据以便传输。
3.根据权利要求2所述的设备，其中所述电子消息传送操作包括基于所述工作流模板生成其中嵌入所述文档元数据的电子文档。
4.根据权利要求2或3所述的设备，其中所述文档元数据包括角色信息，所述角色信息基于处理所生成电子文档的个体的角色来改变所述过程的电子文档的所述生成。
5.根据权利要求3所述的设备，其中所述工作流模板包括标记语言文档，并且其中基于所述工作流模板在运行时动态生成所述电子文档的用户接口。
6.根据权利要求1至3、5中任一项所述的设备，其中帮助用户接口呈现所述线程包括提供所述过程的任务的列表和与相应任务关联的状态。
7.根据权利要求1至3、5中任一项所述的设备，其中所述设备还包括基于所述线程的状态变化来改变所述线程的显示的装置。
8.根据权利要求1至3、5中任一项所述的设备，其中所述设备包括以由所述线程描述的所述过程的任务的相应状态所定义的顺序来呈现所述线程的装置。
9.根据权利要求1至3、5中任一项所述的设备，其中所述过程的所述任务中的至少一个任务包括至少一个子任务，并且其中呈现所述线程包括以分级视图呈现所述至少一个任务和所述至少一个子任务。
10.根据权利要求1至3、5中任一项所述的设备，其中所述元数据包括与所述过程的任务的计时有关的一个或多个时间戳，并且所述设备还包括基于所述一个或多个时间戳呈现所述线程的状态的装置。
11.根据权利要求1至3、5中任一项所述的设备，其中所述设备由处理器实现；或者所述设备存储在存储介质，优选地存储在计算机可读存储介质上。
12.一种方法，包括
标识线程以响应过程的电子消息传送操作，其中所述线程包括总体地描述所述过程的相关任务的状态和关系的数据；
生成所述线程的状态以响应所述电子消息传送操作，其中所述线程的状态代表所述过程的状态；以及
帮助用户接口呈现所述线程以响应所述电子消息传送操作，其中所述呈现指示所述线程的状态。
13.根据权利要求12所述的方法，其中所述电子消息传送操作包括基于为所述过程的所述任务建模的工作流模板创建文档元数据以便传输。
14.根据权利要求13所述的方法，其中所述电子消息传送操作包括基于所述工作流模板生成其中嵌入所述文档元数据的电子文档。
15.根据权利要求13或14所述的方法，其中所述工作流模板包括标记语言文档，并且其中基于所述工作流模板在运行时动态生成所述电子文档的用户接口。
16.根据权利要求12至14中任一项所述的方法，其中帮助用户接口呈现所述线程包括提供所述过程的任务的列表和与相应任务关联的状态。
17.根据权利要求12至14中任一项所述的方法，还包括基于所述线程的状态变化来改变所述线程的显示。
全文摘要
本发明涉及一种用于过程管理的方法、系统和装置。过程管理涉及标识线程以响应过程的电子消息传送操作。所述线程包括总体地描述所述过程的相关任务的状态和关系的数据。生成所述线程的状态以响应所述电子消息传送操作。所述线程的状态代表所述过程的状态。帮助用户接口呈现所述线程以响应所述电子消息传送操作。
文档编号G06F9/46GK101727621SQ20091017406
公开日2010年6月9日 申请日期2009年10月22日 优先权日2008年10月24日
发明者O·科斯基米耶斯, A·卡尔希宁, H·海基拉 申请人:诺基亚公司