KR20130009932A - 프로세스 관리 방법, 시스템 및 장치 - Google Patents

Abstract

프로세스 관리는, 프로세스의 전자 메시징 동작에 응답하여 스레드 (thread)를 식별하는 것을 수반한다. 상기 스레드는 상기 프로세스의 서로 관련된 태스크들의 상태들 및 관계들을 집합적으로 (collectively) 기술하는 데이터를 포함한다. 상기 전자 메시징 동작에 응답하여, 상기 스레드의 상태를 생성된다. 그 스레드의 상태는 상기 프로세스의 상태를 표시한다. 상기 전자 메시징 동작에 응답하여, 사용자 인터페이스가 상기 스레드를 렌더링하는 것이 촉진된다.

Description

프로세스 관리 방법, 시스템 및 장치 {Method, system, and apparatus for process management}

본 명세서는 일반적으로 컴퓨터 애플리케이션에 관련되며, 더 상세하게는, 프로세스 관리 방법, 시스템 및 장치에 관한 것이다.

본원은 정보 기술 (information technology (IT))을 이용하여 생산성을 향상시키는 것에 관련된다. 얼마동안, 상업적인 기업들은 자산들의 일상적인 비즈니스 프로세스들을 자동화하고 질을 높이기 위해 컴퓨터 시스템을 사용하여 왔다. 컴퓨터들의 첫 번째 애플리케이션들 중에 대부분의 모든 기업에서 발견되는 기본적인 프로세스들이 존재한다: 회계, 주문 관리 및 고객 등록.

가장 초기의 컴퓨터화된 해결책들은 문서 (document) 생성, 저장 및 송신 그리고 개인들의 접촉 네트워크들 관리와 같은 비즈니스 프로세스의 일반적인 기능들을 지원하려고 시도했다. 시스템들이 개발됨에 따라, 완전한 기업-확장 프로세스들을 자동화하기 위한 특징들이 추가되어, 상기 프로세스들은 중앙 집중된 방식으로 모니터링 되고 관리될 수 있도록 되었다. 이는 프로세스의 참여자들 각각으로부터 필요로 하는 단계들과 정보를 모호하지 않은 용어로 정의하는 것을 수반했다.

결국, 이런 목표들은 1980년부터의 Zachman 프레임워크 (framework)와 같은 비즈니스 프로세스 모델링 (Business Process Modeling (BPM)) 방법들을 개발하도록 이끌었다. 이런 방법들은 특정 비즈니스 프로세스에 관련된 모든 모습들을 캡쳐할 것을 시도한다. 다른 기술적인 개발 경로는 다른 기업들에 의한 임의의 목적을 위해 특화된 자동화 프로세스 구현을 생성하는 효율적인 방식이 가능하게 하는 목표를 가지는 비즈니스 프로세스 관리 시스템 (Business Process Management Systems (BPMS))을 산출했다. 상업적인 시스템들의 첫 번째 파동은 많은 기업들 사이에서 유사한 또는 한 기업에서의 특정한 비즈니스 프로세스의 요구들에 맞추어서 철저하게 구축된, 자동화된 일반적인 프로세스들을 사용했다. 새로운 BPMS 구현들은 자신들이 인간 참여자들과 다른 컴퓨터 애플리케이션들 모두를 포함하는 기업 내의 어떤 프로세스도 자동화할 수 있다고 주장한다.

비즈니스 프로세스 관리 시스템들은 종종 모델에 처리되는 구조이며, 예를 들면, 그 시스템들은 자동화된 프로세스의 워크플로우 (workflow)를 정의하는 형식적인 모델을 실행한다. 그 모델을 구현하는 공통의 기술은 비즈니스 프로세스 실행 언어 (Business Process Execution Language (BPEL))이지만, 수많은 다른 모델링 언어들이 또한 개발되고 있다. 일부 경우에, 상기 모델은 프로세스의 상태 데이터의 구조 및 상기 상태를 수정하기 위한 외부 참여자들에 의한 상호 작용 단계들의 시퀀스를 기술한다 (describe). 또한 상기 모델은 상기 프로세스가 필요로 하는, 데이터베이스와 같은 다른 리소스 (resource)들을 기술할 수 있다.

본 발명이 이루고자 하는 기술적인 과제는, 상기와 같은 프로세스를 관리하는 방법, 시스템 및 장치를 제공하는 것이다.

본원은 프로세스 관리를 위한 시스템, 장치, 컴퓨터 프로그램 및 방법을 개시한다. 한 모습에서, 프로세스 관리를 위한 장치, 컴퓨터프로그램 및 방법은, 프로세스의 전자 메시징 동작에 응답하여 스레드 (thread)를 식별한다. 상기 스레드는 상기 프로세스의 서로 관련된 태스크 (task)들의 상태들 및 관계들을 집합적으로 (collectively) 기술하는 데이터를 포함한다. 상기 전자 메시징 동작에 응답하여, 상기 스레드의 상태가 생성된다. 상기 스레드의 상태는 상기 프로세스의 상태를 표시한다. 상기 전자 메시징 동작에 응답하여, 상기 스레드를 렌더링하는 사용자 인터페이스가 촉진되어, 상기 렌더링은 상기 스레드의 상태를 지시한다.

한 변형에서, 상기 전자 메시징 동작은 상기 프로세스의 태스크들을 모델링하는 워크플로우 템플리트 (workflow template)를 기반으로 하여 전송에 대한 문서 메타데이터를 생성하는 것을 포함할 수 있을 것이다. 그런 경우에, 상기 전자 메시징 동작은 상기 워크플로우 템플리트를 기반으로 하여, 상기 문서 메타데이타가 내장된 전자 문서를 생성하는 것을 포함할 수 있을 것이다. 또한, 그런 경우에,

상기 문서 메타데이터는 상기 생성된 문서들을 프로세싱하는 개인들의 역할들을 기반으로 하여 상기 프로세스들의 전자 문서들 생성을 변경하는 역할 정보를 포함할 수 있을 것이다. 상기의 경우들에서, 상기 워크플로우 템플리트는 마크업 언어 문서를 포함할 수 있을 것이며, 상기 전자 문서의 사용자 인터페이스는 상기 워크플로우 템플리트를 기반으로 하여 런타임 (runtime)에서 동적으로 생성될 수 있을 것이다.

다른 변형에서, 상기 스레드를 렌더링하는 사용자 인터페이스를 촉진시키도록 하는 것은, 상기 프로세스의 태스크들의 목록에 각 태스크들과 연관된 상태들을 제공하는 것을 포함하며, 상기 스레드의 시각화 (visualization)는 상기 스레드의 상태 변화를 기반으로 하여 변경되며, 그리고/또는 상기 스레드는 상기 스레드에 의해 기술되는 상기 프로세스의 태스크들의 각 상태들에 의해 정의된 순서로 렌더링된다. 다른 변형에서, 상기 프로세스의 태스크들 중의 적어도 하나는 적어도 하나의 서브태스크를 포함하며, 상기 스레드를 렌더링하는 것은 상기 적어도 하나의 태스크와 상기 적어도 하나의 서브태스크를 계층적인 시야 (view)에서 렌더링하는 것을 포함한다.

이런 그리고 다양한 다른 이점들 및 신규한 특성들은 본원에 첨부되어 본원의 일부를 형성하는 청구항들에서 특이성을 구비하여 지적된다. 그러나, 변형들과 이점들을 더 잘 이해하기 위해, 본 발명의 예시의 실시예들에 따른 시스템들, 장치들, 컴퓨터 프로그램 제품들 및 방법들의 설명되고 기술된 대표적인 예들이 존재하는 본원의 추가적인 일부인 도면들과 동반된 도형 내용을 참조해야 한다.

본 발명의 효과는 본 명세서의 해당되는 부분들에 개별적으로 명시되어 있다.

본 발명은 다음의 도면들에서 도시된 예시의 실시예들과 연결되어 설명되었다.
도 1a 및 도 1b는 본 발명의 예시적인 실시예들에 따른 태스크 관리 시스템에서 역할들과 네트워크 채널들 사이에서의 상호작용을 도시한 블록도이다.
도 2는 본 발명의 예시적인 실시예들에 따른 태스크 관리 시스템에서의 문서 흐름들을 도시한 블록도이다.
도 3은 본 발명의 예시적인 실시예들에 따른 프로세스 흐름 네트워크들을 도시한 블록도이다.
도 4는 본 발명의 예시적인 실시예들에 따른 프로세스 네트워크들 사이에서 리소스들을 분배하는 것을 도시한 블록도이다.
도 5는 본 발명의 예시적인 실시예들에 따른 문서의 데이터 구조를 도시한 블록도이다.
도 6은 본 발명의 예시적인 실시예들에 따른 스레드 상태 관리를 활용하는 시나리오를 도시한 블록도이다.
도 7은 본 발명의 예시적인 실시예들에 따른 도 6의 시나리오의 스레드 상태들을 반영한 사용자 인터페이스를 도시한 블록도이다.
도 8 및 도 9는 본 발명의 예시적인 실시예들에 따른 도 6의 시나리오에서와 같이, 대안의 사용자 인터페이스 시야 스레드 상태들을 도시한 블록도이다.
도 10은 본 발명의 예시적인 실시예들에 따른 사용자 장치의 블록도이다.
도 11은 본 발명의 예시적인 실시예들에 따른 서비스 장치의 블록도이다.
도 12a 및 도 12b 그리고 도 13a 및 도 13b는 본 발명의 예시적인 실시예들에 따른 절차들을 도시한 흐름도들이다.
도 14는 본 발명의 예시적인 실시예들에 따른 추가적인 절차들을 도시한 흐름도이다.

본 특허 문서에서 개시되는 내용의 일부는 저작권 보호의 문제인 요소를 포함한다. 상기 저작권 소유자는 그 내용이 특허청의 특허 문서나 기록에 나타나는 한 특허 문서나 특허 개시의 임의의 것에 의한 모사 복제에 어떤 이의도 가지지 않지만, 문서나 기록에 나타나지 않는다면 어떤 것이라도 모든 저작권 권한을 보유한다.

다양한 예시의 실시예들에 대한 다음의 설명에서, 본원의 일부를 구성하며, 다양한 예시의 실시예들을 도시한 것으로 보여지는, 첨부된 도면들을 참조한다. 다른 실시예들도 활용될 수 있을 것이며, 본 발명의 범위를 벗어나지 않으면서도 구조적이며 운용상에 있어서의 변경이 가해질 수 있다는 것이 이해되어야 한다.

일반적으로, 본 발명이 개시하는 내용은 태스크/프로세스 관리 시스템에서의 문서 흐름 (flow)을 관리하는 것과 관련된다. 전통적인 BPMS는 개별적인 프로세스 흐름들의 상태를 추적할 능력을 제공한다. 예를 들면, 주문이 언제 제출되는가, 누가 그것을 처리할 것인가, 언제 그것이 확인되었는가 그리고 그것이 언제 배송되었는가를 관찰할 수 있을 것이다. 중앙 집중화된 시스템에서, 태스크 관리 프로세스 상태는 중앙 서버에 의해 추적될 수 있다. 클라이언트들은 상기 중앙 서버 상에서 상기 상태를 업데이트할 수 있으며, 상태 변화들은 온라인에 있는 모든 사람에게 급히 보일 수 있도록 될 수 있다. 분산 문서 흐름 시스템에서, 관리-기반의 통신 범례 (paradigm)와 어울리는 분산 해결 방안이 필요하다. 그런 분산 해결 방안은, 예를 들면, 제한된 또는 간헐적인 네트워크 접속성을 구비한 모바일 사용자들 또는 형식적인 네트워크 외부에서 직접적인/근접의 데이터 교환을 통해서 데이터 교환을 할 수 있는 사람을 목표로 하는 오프라인 이용을 또한 지원할 수 있을 것이다.

중앙 집중화된 BPMS에서, 참여자들은 공통의 공유 프로세스 인스턴스 (instance)에 액세스할 필요가 있을 수 있다. 분산 BPMS를 생성하기 위한 시도가 있어 왔으며, 그 분산 BPMS에서, 각 참여자는 상기 공유 프로세스 인스턴트의 가상 복제에 액세스하거나 그렇지 않으면 국부적으로 (locally) 이용 가능한 프로세스 기술 (description)의 자신의 관련된 부분을 구비한다. 그러나, 이런 시스템들은 관여된 모든 당사자들에게로의 즉각적인 상태 업데이트와 같이 BPMS가 가져줄 것으로 기대되는 이익들의 일부를 잃을 수 있을 것이다.

본 발명이 개시하는 내용은, 태스크들, 개체 (entity)들, 개인들, 유형/무형의 자산들, 프로젝트들, 계약들, 이벤트들, 서비스들 등을 포함하는 프로세스들 (예를 들면, 비즈니스 또는 워크플로우 프로세스들)의 모습들에 관하여 당사자들을 개시하고, 기록하고, 형식화하고, 추적하고 그리고/또는 공시하기 위해 사용되는 문서들에 관련된다. 여기에서 설명된 문서 흐름 프레임워크에서, 태스크 관리는 문서들을 "스레드들"로 조직함으로써 처리될 수 있으며, 이 경우 각 스레드가 하나의 프로세스에 대응한다. 과거에는, 스레드들의 개념은 이메일 교환, 온라인 메시지 게시판, 텍스트 메시지 교환, 유즈넷 (Usenet) 그룹 등과 연관되었다. 그런 유형의 통신들에서, 진행하는 통신들은 특별한 메시지 또는 주제에 따라 스레드들로 그룹화된다. 상기 통신들은 어떤 순서 (예를 들면, 생성된/수신된 시각에 의해 소팅되어)로 제시될 수 있을 것이며 그리고 다른 요소들을 기반으로 하여 계층적으로 배치될 수 있을 것이다 (예를 들면, 특정 메시지에 응답하여 원래 포스트되었던 메시지 아래로 그룹화될 수 있을 것이다).

그런 용어가 여기에서 일반적으로 사용되는 것과 같이, 스레드들은 진행하는 거래들의 상태 및 관계들을 설명하기 위해 사용되는 데이터 범례이다. 예를 들어, "스레드"의 용어는 기초를 이루는 거래의 상태들을 반영하는 사용자 기기들 내에 존재하는 데이터/실행 가능한 객체들을 언급하는 것일 수 있을 것이다. 이 스레드 객체는 또한 시각적인 표현 성분을 구비할 수 있을 것이다. 스레드들에 의해 표시되는 진행하는 거래들은 문서들의 전송, 유형의 자산들, 서면의 또는 말로 하는 통신 등을 포함할 수 있을 것이다. 또한, 스레드들에 의해 표시되는 상기 프로세스들은 이익 개체들을 위한 용도로 연관될 필요는 없다. 그러므로, "비즈니스 프로세스들"의 예는 여기에서 비즈니스 조직의 면에서 설명될 수 있을 것이지만, 본 발명이 속한 기술분야의 통상의 지식을 가진 자는 "프로세스들" 또는 "비즈니스 프로세스들"은 정의된 목표를 순서 바른 방식으로 집합적으로 달성하는 전자 메시지 교환들을 활용하는 태스크들의 임의의 형식을 포함할 수 있을 것이라는 것을 알 것이다. 예를 들면, 당사자 조직, 자금 조달, 공동체 인식, 탄원서를 돌리는 것 등과 같이 개인들에 의해 수행되는 공통의 태스크들은, 전자 메시징을 경유하여 추적될 수 있고 참여자들에게로의 스레드들로서 표현될 수 있는 교환 (exchange)들을 포함할 수 있을 것이다.

본 발명의 상세한 설명에서, 문서 스레드는 비즈니스 프로세스의 현재의 전반적인 상태를 기술하는, 예를 들면, "주문 송신", "배송 수신" 등을 기술하는, 상태를 구비할 수 있을 것이다. 서브-프로세스들은 겹쳐진 (nested) 스레드들로서 표현될 수 있을 것이다. 문서들을 스레드들로서 표현하는 사용자 인터페이스는 이메일에 충분하게 근접할 수 있을 것이며 그래서 사용자들에게 그것을 어떻게 사용해야 하는가에 대한 직관적인 이해를 줄 수 있을 것이다. 그러나, 그런 시스템은 표준의 이메일과는 다른 점들을 드러낼 수 있을 것이다. 예를 들면, 표준 이메일은 겹쳐진 스레드들을 지원하지 않을 것이며, 그래서 스레드들은 상태와 같은 자기 자신들의 속성들을 구비한 독립적인 객체들로서 존재하지 않을 것이다.

일 예시적인 실시예에서, 각 문서는 하나 또는 그 이상의 기술자 (descriptor)들을 나른다. 이런 기술자들은 어떤 조상 (ancestor) 스레드들은 물론이며 어떤 인접한 부모 스레드(예를 들면, 상기 문서가 직접적으로 속해있는 스레드)라도 참조할 수 있을 것이다. 비록 일부 실시예에서, (예를 들면, 트리 그래프와 같이 계층이 표시될 때) 어떤 프레임워크는 문서를 하나의 부모 스레드로 한정할 수 있을 것이며, 다른 실시예들에서는 복수의 부모 스레드들을 허용할 수 있을 것이다. 문서가 도달하면, 클라이언트는 근접한 부모 스레드의 기술자를 검사하여 그것이 그 기술자와 부합하는 스레드를 이미 가지고 있는가를 판별하고, 만일 그렇다면, 그 문서는 그 스레드에 첨부된다. 그런 스레드가 상기 클라이언트에 존재하지 않는다면, 그런 스레드가 생성되며 상기 문서는 그 스레드에 첨부된다. 스레드를 생성하기 위해 필요한 데이터 (예를 들면, 주제, 기술, 상태, 겹쳐진 스레드들인 경우 부모 스레드)의 일부는 기술자로부터 얻을 수 있을 것이며, 일부는 그 스레드가 생성되도록 한 문서로부터 얻을 수 있을 것이다. 결국, 다른 스레드 기술자들은 검사되며 대응하는 스레드들은 그 스레드들이 이미 존재하지 않는다면 상기 클라이언트 상에서 생성된다.

어떤 문서가 다른 문서를 기반으로 하여 생성되면 (예를 들면, 답장 또는 포워딩), 원래의 문서 내의 스레드 기술자들은 새로운 문서로 복사될 수 있다. 때로는 어떤 문서 기술자가 부가될 수 있을 것이며 (상기 새로운 문서가 새로운 스레드를 시작한다) 또는 하나 또는 그 이상의 부모 스레드 기술자들이 제거될 수 있을 것이다 (상기 새로운 문서가 그 기술자들에 속하지 않는다). 스레드의 상태는 그 스레드에 속한 수신 문서들에 의해 업데이트될 수 있을 것이다. 스레드 상태들을 업데이트하는 접근 방식들은 이하에서 설명되는, 단순하게 제한된 접근 방식 및 더 유연하지만 아마도 더 복잡한 접근 방식이다. 간단한 접근 방식은 겹쳐진 스레드들, 복잡한 문서 흐름들 또는 스레드 완결 상태를 완전하게 처리하지 않을 수 있을 것이지만, 일부 문제의 영역들에 대해서는 충분할 수 있을 것이다.

*사용자 인터페이스 (UI) 목적을 위해, 언제 프로세스가 완료되는가를 아는 것이 필요할 수 있을 것이며, 그래서 스레드들은 대응 프로세스가 완료되었는가 아닌가의 여부에 따라서 (예를 들면, 서로 다른 아이콘을 사용하여) 서로 다르게 디스플레이될 수 있다. 스레드 완료가 판별되어 전달되는 방식은 기술적인 접근 방식과 해결 영역에 종속될 수 있을 것이다. 이하에서 더 설명되는 다양한 예의 실시예들이 스레드 완료를 보여주는 몇 가지 방식들을 보여준다.

일반적으로, 여기에서 설명되는 태스크 관리 해결을 위한 영역은 중소 규모의 기업들, 매일의 프로세스들에 대한 필요를 가지는 개별 직업 사용자들과 소비자들을 포함할 수 있을 것이다. 그런 해결 방식들은 고정된 인터넷 연결이나 개인용 컴퓨터에 전혀 액세스하지 않는 개별 사용자들, 예를 들면, 그 대신 자신들의 모바일 기기에 전적으로 의존하는 그런 사용자들에게 유용할 수 있을 것이다. 어떤 시나리오들에서, 프로세스에 대한 소유자를 식별하는 것이 가능하지 않거나 필요하지 않을 수 있을 것이며, 일부 경우들에서, 참여자들은 서로가 피어 (peer)인 것이 가능하다. 이런 예들에서, 사용자들은 자신들의 비즈니스 계약들이 발전함에 따라서 자신들이 동적으로 관리하는 복잡한 네트워크를 형성할 수 있다. 이런 네트워크들은 우리 사용자들의 매일의 프로세스들 내에서의 모든 통신에 대한 백본 (backbone)을 포함할 수 있을 것이다.

본 발명의 개념들을 활용하는 개체들의 일 예가 도 1a 내지 도 1b의 블록도에서 보여지며, 이 경우 동일한 참조 번호들은 서로 유사한 컴포넌트들을 가리키기 위해 사용된다. 상기 개체들은 일반적으로 서비스 공급자들 (102)과 서비스 소비자들 (104)로 나누어질 수 있을 것이다. 다양한 서비스 공급자들 (102) 및 소비자들은 다른 카테고리들로 그룹화될 수 있을 것이다. 예를 들면, 서비스 공급자들 (106, 108)은 협동하는 공급자들의 동료 네트워크 (110)로 그룹화될 수 있을 것이다. 서비스 공급자들 (106, 108) 사이에서의 동료 관계는 112의 경로에 의해서도 표시된다. 또한 참조번호 108의 공급자도 참조번호 116의 경계에 의해 표시되는 것과 같이 참조번호 114의 서비스 공급자와 관련된다. 이 경우에, 이 예에서 서비스 공급자들 (108, 114) 사이의 관계는 이 개체들 (108, 114)이 서비스 소비자 (118)를 위한 공급자 네트워크 (116)를 형성한다는 것이다. 또한, 서비스 소비자 (118)는 서비스 소비자 (120)를 포함하는 피어 네트워크 (122)의 일부이다. 결국, 서비스 공급자 (124) 및 서비스 소비자 (126)는 특정 동료/공급자/피어 네트워크 (110)에 독립적일 수 있을 것이지만, 참조번호 128, 130 및 132의 경로들에 의해 표시되는 것과 같이 네트워크들 (110, 116, 122) 내에서 다른 개체들과 설립된 관계를 여전히 가지고 있을 수 있다.

사용자들은 자신들의 계약들이 발전됨에 따라 거래들을 동적으로 관리하게 위해 이런 (그리고 다른) 네트워크들 (110, 116, 122)을 형성한다. 이런 네트워크들 (110, 116, 122)은 우리 사용자들의 매일의 프로세스들 내에서의 일부 또는 모든 통신에 대한 백본 (backbone)을 포함할 수 있을 것이다. 상기 네트워크들 (110, 116, 122)은 상기 네트워크들 (110, 116, 122)이 이용되는 근원적인 상호 관계에 따라서 단순할 수도 있고 또는 복잡할 수도 있다. 예를 들면, 상기 네트워크들 (110, 116, 122)은 자신들의 속성상 다소 비공식적일 수 있으며, 예를 들면, "myNeighbors (내이웃들)", 또는 더 사업적이며 공식적일 수 있다, 예를 들면, "myCustomers (내고객들)". 참여자들의 매일의 프로세스들은 이런 네트워크들 (110, 116, 122) 사이에서 수행될 수 있을 것이다.

이제 도 1b를 참조하면, 도 1b의 블록도가 도 1a에서 도시된 개체들 사이에서의 다양한 문서 흐름들을 도시한다. 이런 흐름들은, 서비스-간의 위임 (140), 소비자-사이에서의 추천들 (142), 소비자-사이에서의 초대들 (144, 146), 소비자로부터 공급자로의 요청들 (150) 및 상기 요청들에 응답하는 보고들 (148)과 같은 비즈니스 프로세스들을 정의, 개시, 지원, 기록 그리고 그렇지 않은 경우에는 용이하게 하는 문서들을 포함한다. 이런 다양한 흐름들 (140, 142, 144, 146, 148, 150)와 관련된 상기 문서들은 상기 비즈니스 프로세스에서 서로 다른 시간들에 걸쳐서 변경될 수 있을 것이다. 예를 들면, 상기 요청 (150)은 위임 (140) 및 보고 (148)하기 이전에, 위임 및 보고하는 동안에 그리고/또는 이후에 하나 또는 그 이상의 서비스 공급자들 (106, 108)에 의해 채워질 다양한 빈칸/미지의 값들을 구비한 문서들을 포함할 수 있을 것이다. 아래에서 설명되는 프레임워크는 프로세스들의 태스크들/이벤트들의 일부로서 교환되는 상기 문서들의 상태를 기반으로 하여 상기 프로세스들에서의 이런 변화들을 추적하는 것을 가능하게 하는 특징들을 포함한다.

문서 관리 프레임워크의 한 가지 모습은 사용자들이 자신들에게 제공된 해결 방안들을 어떻게 이해하고 개별적으로 맞출 수 있는가에 관한 것이다. 일부 사용자들은 제공된 도구들을 이용하여 자신의 서비스들을 철저하게 정교하게 할 것으로 기대될 수 있을 것이다. 다른 경우에, 사용하기 용이한 템플리트들 (templates)이 제공되어 특정한 공통의 또는 잘 알려진 태스크들을 커버한다. 여기에서 설명된 실시예들의 다른 기술적인 특징들은, a) 참여자들이 중앙 서비스로의 네트워크 액세스를 하지 않고 관려된 (일상적인) 활동을 수행하도록 한다; b) 프로세스 개념들을 현존하는 물리적인 문서-기반의 프로세스들에 직접 매핑하여, 서비스 참여자들이 무리한 학습 커브 없이도 상기 개념들을 이해하는 것을 용이하게 한다; c) 각 참여자들이 애플리케이션 특정 네트워크들을 유지하는 것을 용이하게 한다; 그리고 d) 상기 플로두 구현을 위해 사용되는 동일한 통신 구조 내의 데이터 리소스들의 제어된 공유를 지원하는 것을 포함하지만, 그것들로 한정되는 것은 아니다.

이하에서 설명되는 예시적인 실시예들은 비즈니스 영역에서 맞춤 가능한 모바일 프로세스들을 사용자에게 제공한다. 하나의 접근 방법은 메시지 통과 (message passing) 방식을 기반으로 하는 문서 중심 워크플로우 모델이다. 그 모델은 참여자들이 자율적이며 푸시 유형 행동 할당이도록 장려한다. 도 2에서, 블록도는 본 발명의 예시적인 일 실시예에 따른 분산 모바일 문서 시스템에서의 통신 흐름들을 도시한다. 상기 흐름의 참여자들은 서로에게 문서들(예를 들면, 참조번호 202의 문서)을 송신하여 통신한다. 상기 통신 노드들 (예를 들면, 모바일 클라이언트들 (204, 206)과 서버들 (205, 207))은 어려운 접속 상태에서 쉽고 직관적인 동작을 용이하게 하는 "저장-그리고-포워딩(store-and-forward)" 유형의 프로세싱 노드들일 수 있을 것이다. 상기 노드들 (204 내지 207) 각각은 상기 시스템을 통해서 순환하는 다양한 문서들 (212-215)을 처리하고 라우팅하기 위한 라우팅/행동 규칙들을 유지하고 적용하는 역할 설정 모듈들 (208-211)이 각각을 포함한다.

도 2의 예시적인 실시예에서 보는 것과 같이, 문서 흐름에는 두가지 유형의 참여자들이 존재할 수 있다. 전화기 사용자들은 모바일 클라이언트들 (204, 206)으로 표시되며, 서버들 (205, 207)로 표시되는 단체들은 여기에서는 단체 서버들로 언급된다. 상기 서버들 (205, 207)은 고정된 인터넷에 연결될 수 있을 것이며, 문서 흐름 프로세스에서는 피어들 (peers)일 수 있다. 또한 상기 모바일 클라이언트들 (204, 206)은 서로 간에 피어들로서 통신할 수 있을 것이며, 단체 서버들 (205, 207)과는 피어들 및/또는 클라이언트-서버로서 통신할 수 있을 것이다.

단체 서버 (207)가 어떻게 문서 흐름에 참여할 수 있는가에 대한 예에서, 모바일 클라이언트 (206)를 구비한 소비자가 서비스 공급자 회사로 주문 문서 (215)를 송신하는 경우를 고려한다. 상기 회사의 단체 서버 (207)는 상기 문서를 수신하고 그 문서에 반응하여 자신의 역할 설정 모듈 (211)로부터 라우팅 규칙을 찾는다. 그런 규칙은 보통은 "주문 (order)" 문서 유형과 문서 (215)의 역할 기술자 내의 상기 회사의 역할에 대응할 수 있을 것이다. 그런 경우에서의 역할 정보는 "서비스 공급자 = 회사 X (Service Provider = Company X)"가 될 수 있을 것이다. 상기 라우팅 규칙은 상기 단체 서버 (207)가 상기 주문 문서 (215)를 회사 X의 단체 서버 인스턴스의 "판매원들 (salespersons)" 네트워크에서의 모바일 사용자들 중의 하나에게 포워딩해야 한다고 말할 수 있을 것이다 (예를 들면 도 3 참조).

이 예시의 시나리오에서, 상기 단체 서버 (207)는 회사를 위한 통신 엔드-포인트 (end-point)를 대표하며, 이런 기능의 면에서, 상기 회사의 소비자들과 회사의 근로자들 사이에서의 중개자로서 행동할 수 있을 것이다. 상기 단체 서버는 자신이 수신한 문서들을 기반으로 하여 새로운 문서들을 생성하는 것이 가능하며, 그 경우 메타 정보가 원래의 문서 (215)에서 상기 생성된 문서로 복사될 수 있을 것이다.

문서 (202)에서 보이는 것과 같이, 상기 시스템 내의 각 문서는 상기 흐름의 응용, 예를 들면 주문 열 (order row)들과 관련된 비즈니스 데이터 (216)를 나른다. 또한 상기 시스템의 각 문서는 상기 흐름의 모든 참여자들에 의해 번역되고 다양한 목적들을 위해서 사용될 수 있는 구조화된 메타데이터 (218)를 포함할 수 있을 것이다. 예를 들면, 한 문서를 처리하기 위해 사용되는 형식들은 사용자의 역할과 문서 유형을 기반으로 하여 선택된다. 그러므로, 수신된 모든 문서에 대해서 사용자의 역할이 정의될 수 있을 것이다. 이를 보장하기 위해, 상기 수신 사용자의 역할은 문서가 송신될 수 있기 전에 알려지거나 그리고/또는 범위가 정해질 것을 필요로 할 수 있을 것이다.

메타데이터 (218)의 다양한 사용들 중에 비즈니스 프로세스의 스레드의 상태를 보고하는 것이 있다. 상기 스레드의 상태는 상기 문서들 (212-215)을 이용하여 구현된 개별적인 서로 관련된 태스크들의 상태에 의해 집합적으로 결정될 수 있을 것이다. 그처럼, 중앙 집중화된 어떤 개체도 이런 프로세스 상태들을 추적하기 위해서 필요하지 않다는 것이 가능하며, 참여하는 노드들이 관심 대상인 스레드 상태들을 결정하기에 충분한 데이터를 상기 문서들 (212-215) 스스로가 포함한다. 예를 들면, 상기 노드들 (205-207)은 상기 노드들 (205-207)을 통해서 지나가는 모든 문서들 (212-215)과 연관된 스레드 상태를 결정할 수 있을 것이다. 그러나, 태스크들의 상태들, 문서들 및 비즈니스 프로세스 네트워크들의 스레드들을 전달하는 대체의 수단을 제공하는 것이 여전히 필요할 수 있을 것이다. 예를 들면, 문서 (212)가 클라이언트들 (204, 206) 사이에서 직접 전달되지 않고 중개자들을 통해서 통과되면, 상기 클라이언트들 (204, 206)은 상기 문서들의 상태 변화들을 결정하는 어떤 방식도 구비하지 않을 수 있다.

일부 실시예들에서, 상태 업데이트를 통과시키는 것 외에 어떤 다른 목적도 가지고 있지 않은 문서들을 송신하여 상태 업데이트들이 통과될 수 있다. 예를 들면, 소비자가 공급자에게 주문을 하면, 그 공급자는 "확인됨 (confirmed)"으로의 상태 업데이트 그리고 예측된 배송 날자와 같은 부가적인 정보의 둘 다를 포함하는 주문 확인 문서를 돌려보낸다. 이런 유형의 문서는 사용자 인터페이스에서는 상기 부가 정보를 보여주기 위해 열릴 수 있는 별개의 문서로서 보여질 수 있을 것이다. 그러나, 그 주문 확인 문서만이 "확인됨"으로의 상태 업데이트를 포함하며, 어떤 부가 정보도 포함하지 않을 다른 가능성이 있을 수 있다. 이런 경우에는, 상기 문서는 상기 사용자 인터페이스에서 개별적인 문서로서 보이지 않을 것이며, 그것을 수신한 결과로 오직 볼 수 있는 것은 상기 스레드의 상태가 "확인됨"으로 변경된다는 것이다. 이런 순수한 상태 업데이트 문서들은, 목표 상태 업데이트들을 보통의 문서 송신 메커니즘들을 이용하여 송신하기 위해 사용될 수 있다.

프로세스 상태로의 변화들을 탐지하는 다른 방식은, 상기 문서들 (212-215)을 처리하고 그리고/또는 상기 메타데이터 (218)로의 변화들에 영향을 주는 개체 각각에 의해서 상기 문서들 (212-215)이 중앙 저장소 (220)에 저장된다는 것을 보장하는 것이다. 상기 저장소 (220)의 신원 (identity)은 상기 문서들 (212-215) 자체 내에 (예를 들면 URI로서) 내장될 수 있을 것이며, 또는 참여하는 개체들 (204-207)에 의해 미리 설정될 수 있을 것이다. 이는 일부 실시예들에서 상기 내장된 메타데이터 접근 방식을 보충하기 위해 사용될 수 있을 것이다.

워크플로우 상태 데이터가 분배되는 다른 방식은 참여자들의 식별자들 (예를 들면, URL들, 사용자 신원들, 메시징 주소들)을 상기 워크플로우에 내장시키는 것이다. 참여자의 이런 식별자들은 메타데이터의 일부들에 첨부될 수 있을 것이며, 그래서, 문서/태스크/스레드 상태로의 특정한 변화들만이, 예를 들면, 상기 비즈니스 흐름의 참여자의 역할을 기반으로 하여 전달될 것이다. 이런 상태 데이터는, 클라이언트 (206)와 서버 (207) 사이의 대체 데이터 경로 (222)에 의해 표시되는 것과 같이, 대역 외 (out of band) 메커니즘 (예를 들면, 문서들 (212-215)을 전달하기 위해 사용되는 것들에 독립적인 메커니즘)을 이용하여 전달될 수 있을 것이다.

이런 대역 외 메커니즘들 (222)은 데이터를 전자 문서들 내에 내장시키는 것에 보조적일 수 있다. 예를 들면, 일부 시나리오에서, 참여자가 전자 문서를 프로세스하기를 꺼리거나 할 수 없을 수 있다. 그런 경우에, 그 참여자는 바코드를 구비한 종이 문서를 받을 수 있을 것이다. 그 참여자는 그 종이 문서의 전자 문서 버전에 연관된, 다른 곳에 (예를 들면, 저장소 (220)에) 저장된 메타데이터를 결정하고 그리고/또는 영향을 미칠 수 있을 것이다. (예를 들면, 모바일 기기를 이용하여) 그 바코드를 스캐닝하고 (예를 들면, 모바일 기기들을 위해 간략화 된) 사용자 인터페이스에 데이터를 입력하여, 그 참여자는 전자 문서들에 내장된 메타데이터를 수신한 다른 참여자들과 유사한 방식으로 데이터를 여전히 프로세스할 수 있다. 그와 같은 경우에, 상기 프로세스 내의 다른 전자 문서들은 상기 메타데이터 내에 내장된 저장소 (220)에 대한 참조를 포함할 수 있을 것이며, 그래서 관심 대상인 당사자들은 필요하다면 그 개인과 관련된 스레드 상태들을 검색할 수 있다.

문서들 (212-215)을 통과시키는 설명은 단지 예시일 뿐이며, 도 2에 설명된 개념들은 어떤 유형의 문서 생성/전달, 문서/태스크/스레드 상태의 업데이트 하기, 역할들을 정의하는 것 등에도 적용될 수 있다. 문서들 그 자체 그리고/또는 피어-투-피어 대역 외 (peer-to-peer out-of-band) 메커니즘 (220)을 이용하는 통신 상태 변화들은 제한된 연결성 및/또는 대역폭을 가진 기기들 (예를 들면, 모바일 기기들)이 서버들을 폴링 (polling)하는 것에 의지하지 않고 상태 변화들을 결정하거나 전달하는 것을 허용할 수 있을 것이다. 이것의 기술적인 효과는 네트워크 대역폭 이용이 감소되고 시스템 신뢰성이 증가하여, 일어날 수 있는 단일 포인트 실패를 제거한다는 것이다.

이제 도 3을 참조하면, 도 3의 블록도는 본 발명의 예시적인 일 실시에에 따른 비즈니스 프로세스 구조의 다른 모습을 보여준다. 이전에 설명된 것과 같이, 상기 비즈니스 프로세스는 개인들 사이에서 전자 문서들을 교환하는 것에 의해 진행될 수 있는 어떤 조직된 태스크들이라도 포함한다. 도 2에 관련하여 설명된 것과 같은 단체 서버 (304)에 추가하여, 그 구조는 문서들을 구비한 직접적인 사용자 상호 작용 (interaction)을 위해 사용되는 모바일 클라이언트 (302)를 포함한다. 상기 분산 문서 흐름 시스템의 구조는 흐름들을 전달하기 위해서 참여자들을 적어도 포함한다. 이 참여자들은 문서 흐름 현장에 참여하는 개인들을 나타내는 모바일 클라이언트 (예를 들면, 참조번호 302의 클라이언트)를 포함할 수 있을 것이다. 일부 참여자들은 속성상 고정된 (예를 들면, 모바일이 아닌) 것으로 간주되는 단체들일 수 있다. 그 단체들은 단체 서버 시스템들 (예를 들면, 단체 서버 (304) 및 도 2의 서버들 (204-207))로 표현된다. 예를 들면, 현장에서의 모바일 판매 대리인은 자신의 회사를 나타내는 서버에 "구매 주문 (purchase order)" 문서들을 송신할 수 있다. 그러나, 그 흐름들은 단체 참여자들을 꼭 필요로 하는 것은 아니며; 일부는 피어들 사이에서 떠맡아진 애드혹 (ad-hoc) 거래일 수 있다.

모바일 사용자들 및 단체들은 둘 다 상기 문서 흐름에 관련하여 정의된 역할들과 네트워크들을 구비한다. 예를 들면, 모바일 주문 프로세스를 구현하는 문서 흐름에서, 판매 대리인, 소비자, 공급 회사 및 주문 처리자와 같이 역할들이 설립될 수 있을 것이다. 모바일 사용자의 역할들은 디스플레이들을 활용하고 어떻게 사용자가 들어오는 문서들을 보는가를 제어하는 동작 형식들을 활용할 수 있을 것이다. 예를 들면, 주문하는 흐름에서의 "주문 확인 (order confirmation)" 문서는 소비자에 비하면 판매 대리인을 위한 일부 추가적인 데이터를 구비하는 것으로 보일 수 있을 것이다. 그런 경우에, 판매 대리인의 문서는 상기 주문 문서상에서 "주문 취소 (cancel order)" 기능으로의 액세스를 구비할 수 있을 것이며, 그때에 소비자는 그 대신에 동일한 또는 연관된 주문 문서상에서 "주문 취소 요청 (request order cancellation)" 동작을 볼 수 있을 것이다.

이런 환경에서 역할들을 관리하는 것은 적절한 "네트워크들" 내에서 문서들 및 흐름들을 분리하는 것을 관련시키며, 이는 프로세스를 보고 그리고/또는 기여하는 능력을 구비한 프로세스들 및 개인들의 수집들을 광범위하게 언급한다. 예를 들면, 모바일 사용자 또는 단체의 네트워크들은 상기 사용자나 단체가 문서 흐름들을 같이 개시할 수 있는 참여자들의 공간을 정의할 수 있을 것이다. 도 3에 도시된 것과 같이, 상기 모바일 클라이언트 (302)는 다른 모바일 사용자들 (예를 들면, 참조번호 308의 모바일 사용자)이나 단체들 (예를 들면, 참조번호 310의 단체)과 함께 문서 흐름들을 개시하기 위해 사용되는 네트워크들 (306)을 유지하도록 구성될 수 있을 것이다. 상기 네트워크들 (306)의 몇몇은 개인에 속하는 것이며 상기 사용자의 모바일 기기 내부에서만 유지될 수 있다. 다른 네트워크들 (예를 들면, 참조번호 309의 네트워크들)은 상기 단체 서버들 (304)에 의해 유지될 수 있으며 상기 단체에서 유지되는 다른 네트워크들에 자동적으로 동기될 수 있다. 예를 들면, 상기 단체는 "판매자 (sales persons)" 네트워크 (312)와 "소비자들 (customers)"이라고 불리는 다른 네트워크 (314)를 구비할 수 있다. 상기 소비자 네트워크 (314)는 (경로 (316)에 의해 지시되는 것과 같이) 판매자 네트워크 (312)에 보일 수 있도록 정의될 수 있으며, 상기 시스템은 경로 (318)에 의해 지시되는 것과 같이 판매자 네트워크 (312)에서 상기 모바일 클라이언트 (302)로 소비자 네트워크 (314)의 변화를 전달하는 것을 책임질 수 있다.

여기에서 설명된 데이터 흐름 프레임워크는 리소스의 개념을 활용한다. 리소스는 회사의 "제품 목록 (product list)"과 같은 데이터의 임의의 집합 그리고/또는 이미지와 같은 이진 데이터일 수 있을 것이다. 상기 모습들은 자신들의 사용자 인터페이스 위젯들 (widgets)에서 국부적으로 (locally) 이용 가능한 리소스들을 사용할 수 있다. 예를 들면, "주문" 모습은 제품 목록 리소스로부터 가져왔던 제품들의 선택 목록을 보여줄 수 있다. 리소스들이 어떻게 설정될 수 있을 것인가의 일 예가 도 4의 블록도에서 보여지며, 도 4는 도 3에서 도시된 예시의 모바일 클라이언트 (302)와 단체 서버 (304)의 추가적인 모습들을 보여준다.

리소스들의 관리 및 가시성 (visibility)은 상기 네트워크들과 유사한 방식으로 제어될 수 있을 것이다. 리소스는 상기 모바일 클라리언트 (302)에 의해 또는 주어진 네트워크들에 의해서 국부적으로 또는 주어진 네트워크들로의 그 리소스의 가시성을 정의할 수 있는 단체에 의해 관리될 수 있다. 상기 시스템은 변화된 리소스의 상기 리소스가 보이게 된 네트워크들로의 송신을 책임진다. 상기 리소스는 상기 단체 서버 (304)에서 상기 단체에 의해 관리될 수 있을 것이며, 전체의 주어진 네트워크로 그처럼 동기된다. 예를 들면, 제품 목록 리소스 (402)는 경로 (404)에 의해 표시되는 것과 같이 "소비자" 네트워크 (314)에 보일 수 있다. 이런 경우에, 모든 소비자들 (예를 들면, 클라이언트 (302) 및 사용자들 (406-407))은 동일한 제품 목록 (402)을 보게된다.

때때로, 상이한 네트워크들로 분배될 수 있는 리소스들에 동적으로 관리되는 시야들을 생성하는 것이 필요할 수 있을 것이다. 그와 같은 경우에, 표 모습의 리소스 포맷이 상이한 네트워크들로 보이도록 행마다 태그가 될 수 있다. 예를 들면, 단체는 "keyCustomers" 및 "regularCustomers"로 소비자들이 분할할 수 있을 것이다. 이런 시나리오에서, 상기 제품 목록 (402)에서 일부 행들은 "keyCustomers"에게만 보이도록 태그가 될 수 있다.

이전에 설명된 것처럼, 여기에서 설명된 상기 문서 흐름 프레임워크는 "스레드들"로 태스크 관리 문서들을 조직하는 것을 설명했으며, 이 경우 각 스레드는 하나의 비즈니스 프로세스에 대응한다. 그런 프레임워크는 도 1a, 1b 및 도 2 내지 도 4에 관하여 상기에서 도시되고 설명된 맥락과 환경에서 사용되기 위해서 적응된다. 다음의 섹션에서, 문서 흐름 프레임워크의 특별한 특정 구현들이 도시되고 설명된다.

이제 도 5를 참조하면, 도 5의 블록도는 본 발명의 예시적인 일 실시예에 따른 다양한 문서 데이터 구조를 도시한다. 블록 (502)은 상기 문서 흐름 프레임워크의 문서 (502)를 나타낸다. 상기 문서 (502)는 도 2의 문서 (202)에서 설명된 것과 같이 메타데이터 (504)와 비즈니스 데이터 (506)로 나누어질 수 있을 것이다. 아래에서 설명되는 다양한 구현예들은 상기 메타데이터 (504) 내에 상태 기술자 (descriptor)를 포함하는 StateUpdate 필드 (508)를 포함시키는 것을 결부시킬 수 있을 것이다. 상기 상태 기술자는 사용자에게 그대로 보여지는 사람이 읽을 수 있는 설명이고 그리고/또는 그것은 클라이언트에 의해 사람이 읽을 수 있는 설명으로 매핑되는 토큰일 수 있다. 전자는 "주문 48% 완료"와 같은 자유스러운 형태의 상태 기술들을 허용하며, 후자는 문서 흐름에서 사용자 역할에 의존하여 변화하는 상태 기술들과 (예를 들면, 공급자가 "모든 것이 송신됨"의 상태를 보는 반면에, 소비자들은 "모든 것이 수신됨"의 상태를 볼 수 있을 것이다) 쉬운 국부화 (localization)를 허용한다. 상기의 두 가지의 결합 또한 사용될 수 있으며, 그때에 토큰과 자유스러운 형태의 설명의 두 가지 모두가 제공되어, 예를 들면, 토큰은 "진행 중" 그리고 자유스러운 형태 설명은 "48%"이이면, 상기 클라이언트는 이 두 가지를 결합하여 상태 스트링 "주문 진행 중 (48%)"을 형성한다. 상기 메타데이터 (504) 내의 문서 유형 필드 (514) 또한 개별적인 StateUpdate 필드 (508) 대신에 사용될 수 있을 것이라는 것에 유의한다. 그런 실시예에서의 상기 문서 유형 (514)은 사람이 읽을 수 있는 상태 설명으로 상기 클라이언트에 의해 매핑되는 토큰으로서 사용된다. 이는 스레드 상태 변화를 일으키는 각 문서를 위해서 사용되는 개별적인 문서 유형을 필요로 할 것이지만, 개별적인 StateUpdate 필드 (508)를 불필요하게 만들 수 있을 것이다.

스레드 완결은 상기 설정의 목록에 의해 스레드 상태들의 각 역할에 대해 개별적으로 처리될 수 있을 것이며, 상기 스레드 상태는 그 스레드가 그 역할의 관점으로부터 완결되었다는 것을 의미한다. 대안으로, 각 문서는, 상위 레벨의 관점에서 보이는 것과 같이 (예를 들면, 상기 프로세스 흐름으로의 모든 기여자들에 대해 완료) 상기 문서가 전체 스레드를 완료하면 참으로 설정되는, "ThreadComplete" 필드 (510)를 나를 수 있을 것이다. 그런 경우에, 상기 문서 송신자는 상기 문서가 수신기를 위한 스레드를 완료하는가의 여부를 알아야만 한다. 이것이 실행할 수 있을 것이지만, 모든 클라이언트가 모든 다른 사람들의 역할들에 관해서 알아야 하기보다는 자신의 스스로의 역할들에 관해서 알기를 원할 필요가 있으면 그것은 더 쉬울 것이다. 그러나, 일부 클라이언트들은, 높은 레벨의 관리자 또는 시스템 관리자와 같이, 모든 역할들을 완료하는 것에 적어도 때로 흥미가 있을 수 있을 것이다. 그런 경우에, 상기 완료 상태는 특정한 역할들에서 정례적으로 보는 것을 위해서 필터링될 수 있을 것이며, 그 경우 상기 상태는 그 특정한 역할에 관한 완료만을 반영한다. 모든 역할들에 대한 완료 상태를 반영하는 혼성 (composite)의 완료 상태는 자동적으로 또는 특별한 요청에 따라서 특정 클라이언트들에 의해 보여질 수 있을 것이다.

어떤 스레드는 그 스레드가 완료된 후에라도 상태를 변경하도록 허용될 수 있을 것이라는 것에 유의한다. 예를 들면, 여행 예약 스레드는 티켓들이 송신되면 (여행자의 관점으로부터는) 완료된 것으로 간주될 수 있을 것이지만, 스레드 상태는 여행 대리인의 송장 (invoice)이 지불된 것을 표시하기 위해서 그 이후에 여전히 변경될 수 있을 것이다. 다른 예에서, 항공편이 취소되거나 항공편이 변경되고새로운 티켓들을 발행할 필요가 있으면, 상기 스레드 상태는 그에 따라서 업데이트될 수 있다.

겹쳐진 스레드들의 상태를 ThreadComplete 플래그 (510)를 경유하여 업데이트하는 것은 다음을 포함하는 많은 방식들로 처리될 수 있다: 1) 상태 업데이트들을 모든 조상 스레드들로 전파한다 (propagating); 2) 상기 문서가 속하는 스레드들로 상태 업데이트들을 제한한다; 그리고/또는 3) 근접한 부모 스레드가 문서에 의해 완료될 때에만 모든 조상 스레드들로 상태 업데이트들을 전파한다. 첫 번째 대안은 어떤 스레드가 액세스되더라도 잘게 쪼개진 (fine-grained) 상태를 보여줄 수 있다. 그러나, 그런 상세한 상태는 특정한 역할에 대한 전반적인 프로세스 상태에 적절하지 않은 정보를 포함할지도 모른다. 예를 들면, 그런 상세한 상태는 필요하지 않거나 또는 특정한 조상 스레드들에게는 적절하지 않을 수 있다. 두 번째 대안은 더 간단한 시야들을 제공할 수 있을 것이지만, 그러나 자녀 스레드 내에서의 변화들은 (비록 그것이 완료된 경우에도) 부모 스레드의 상태를 업데이트하지 않을 수 있다. 세 번째 대안은 많은 상황들에서 비교적 잘 동작할 수 있는 어떤 절충안이다. 예를 들면, 오직 하나의 겹치는 레벨만이 존재하고 그리고 스레드 상태 기술 (description)들이 신중하게 선택되어 동일한 기술이 자녀 스레드와 부모 스레드 둘 모두에 대해 이해될 수 있도록 될 때에, 선택적인 상태 전파는 유용할 수 있다.

또한 각 문서는 문서 행동과 연관된 날자/시각을 일반적으로 표시하는 타임스탬프 (511)를 포함한다. 예를 들면, 어떤 스레드의 상태는 가장 늦은 타임스탬프 (511)를 구비한 스레드 내 문서의 StateUpdate 필드 (508)에 의해 결정될 수 있을 것이다. 그 타임스탬프 (511)는 문서 생성, 수정, 승인, 제출, 삭제, 기록 등 중에서 하나 또는 그 이상에 대한 날자/시각을 표시하기 위해 사용될 수 있을 것이다.

상기 문서 (502) 내에 포함될 수 있는 다른 메타데이터 (504)는 서비스 ID (513)을 포함한다. 상기 서비스 ID (513)는, 예를 들면, 여행 예약 서비스, 홈 청소 서비스, 유지보수 서비스 등에 속한 문서에 대한 서비스를 설명한다 (describe). 모바일 사용자 인터페이스에서, 설치된 각 서비스에 대해 개별적인 선택이 있을 수 있으며, 그런 경우 상기 서비스 ID (513)는 상기 문서가 어느 부분에서 보여져야 하는가를 결정하기 위해 이용될 수 있을 것이다. 또한 상기 서비스 ID (513)는 문서 유형 (514)을 위한 이름 공간의 정렬로서 기능하여, 상기 문서 유형들 (514)은 존재하는 모든 문서 유형들을 알지 못해도 지정될 수 있다. 상기 문서 (502)는 스레드 ID (514)를 구비할 수 있을 것이며, 그 스레드 ID는 하나의 스레드를 형성하는 비즈니스 태스크들의 특별한 수집에 대한 내부의/외부의 참조들을 포함할 수 있을 것이다. 상기 문서 유형 (514)은 문서 데이터 포맷들, 상기 문서가 이용되는 비즈니스 태스크, 문서 서브-유형 (예를 들면, 구매 주문-서비스들; 구매 주문-자본 등), 문서 이름 등 중에서 하나 또는 그 이상을 나타낼 수 있을 것이다. 유사하게, 스레드 유형 (516)은 높은 레벨에서의 문서의 스레드의 유형 (예를 들면, 구매, 엔지니어링, 판매), 또는 미세함 (granularity)의 더 정제된 레벨들에서의 문서의 스레드의 유형 (예를 들면, 엔지니어링: 인용 (quotes) 요청; 프로토타입 재료들)을 표시할 수 있을 것이다.

메타데이터 (504)는 하나 또는 그 이상의 스레드 기술자들 (517)을 또한 포함할 수 있을 것이다. 상기 스레드 기술자들 (517)은 상기 스레드의 단어 설명을 포함할 수 있을 것이며 (예를 들면, 스레드 주제), 그리고, 스레드 ID (513), 부모 스레드 ID, 스레드 유형 (516), 부모 스레드 기술자 및/또는 조상 스레드 기술자들과 같은 다른 메타데이터 아이템들의 결합을 또한 포함할 수 있을 것이다. 나중의 두 가지는 관련된 스레드 데이터 (520)로서 표시된다. 프로세스들이 계층적인 경우들에서 (예를 들면, 하나의 프로세스가 부모의 서브-스레드인 스레드 "겹침 (nesting)"), 이 지시자 (520)는 부모/자녀 스레드들을 식별할 수 있을 것이며 그리고 상태를 적절하게 디스플레이하고 업데이트할 목적으로 사용될 수 있을 것이다. 다른 프로세스들은 계층적인 관계를 필수적으로 요청하지 않으면서 병렬로 발생할 수 있을 것이다. 그런 경우에, 관련된 스레드 데이터 (520)는 스레드들 사이에서의 형제-유형의 관계를 나타낼 수 있을 것이다.

역할 기술자 (518)는 문서가 부속될 수 있는 비즈니스 모델에서 정의된 하나 또는 그 이상의 역할들에 대한 참조를 포함할 수 있을 것이다. 상기 기술자 (518) 내에 목록으로 된 역할들은 상기 문서 (502)를 처리하는 그런 역할들로 한정될 필요는 없다. 예를 들면, 일부 비즈니스는 회계 감사와 같이 기능하며 그리고 품질 보증은 실제 문서 (502)를 프로세싱하지 않으면서 비즈니스 프로세스에 관해서 감독 역할을 가질 수 있을 것이다. 상태 업데이트들 (508)을 필터링/전달 그리고 스레드 완료 (510)와 같은 목적을 위해, 상기 역할 기술자 (518)는 다른 메타데이터 (504)와 결합될 수 있을 것이다. 상기 역할 기술자 (518)는 상태 데이터 (예를 들면, 참조번호 508, 510의 데이터)가 그런 역할들을 수행하는 개인들에게 직접적으로 또는 간접적으로 전달되도록 하는 주소들을 또한 포함할 수 있을 것이다. 그런 업데이트들은 비즈니스 프로세스의 개체에 의한 상기 문서 (502) 생성 및/또는 수정에 응답하여 발생할 수 있을 것이다.

(예를 들면, 도 8 및 도 9에 관련하여) 아래에서 더욱 상세하게 설명될 것처럼, 상태 업데이트 표시자 (508)는 태스크/문서/스레드 상태들을 결정하는 단 하나의 방식이다. 메타데이터 (504)는 상태 업데이트 표시자 (504) 대신에 또는 그것에 추가하여 상태 태그들 (522) 및/또는 하나 또는 그 이상의 상태 테이블들 (524)을 포함할 수 있을 것이다. 태그들 (522)은, 단독으로 또는 상기 테이블 (524)와 결합하여, 문서들 또는 태스크들로의 상태 변화들이 어떻게 스레드 상태에서의 변화들로 매핑되는가를 정의할 수 있을 것이다. 상기 태그들 (522)은 상태 변화가 어떻게 흐르는가 (예를 들면, 아래의 목록 1에서와 같이) 또는 (예를 들면, 아래에서 표 1에서와 같은) 그런 출력들을 제공하는 상태 테이블로의 룩업들 (lookups)로서 어떻게 이용될 수 있는가의 규칙들을 포함할 수 있을 것이다. 상기 메타데이터 (504)는 특정한 프로세스에서 복수의 역할들에 적합한 상태 데이터 (508, 522, 524)를 나를 수 있다는 것에 유의한다. 그와 같이, 메타데이터 (504)를 경유하여 스레드/태스크/문서 상태로의 변화들을 최종적으로 전달하는 것은 특정 역할들의 각각에 대해 역할 기술자들 (518)을 기반으로 하여 맞추어질 수 있을 것이다.

상기 문서 (502)는 프로세스 스레드의 특정 태스크들을 진전시키는 비즈니스 데이터 (506)을 포함하며, 이 데이터 (506)는 자신의 의도된 목적을 위해 문서 (502)를 렌더링하기 위해 사용되는 텍스트, 이미지 등과 같은 렌더링 데이터 (526)를 포함할 수 있을 것이다. 상기 문서 (502)는 상기 문서가 다양한 개체들과 역할들 사이에서 이동함에 따라 추가적인 사용자 입력 데이터 (528)를 수용하기 위해 적응될 수 있을 것이다. 또한 상기 사용자 입력 데이터 (528)는 시스템에 의해 모니터링 될 수 있을 것이며 메타데이터 (504)를 업데이트하기 위해 사용될 수 있을 것이다. 예를 들면, 체크박스를 포함하는 렌더링된 데이터 (526) 중에서 상기 체크박스를 선택하는 것은 사용자 입력 데이터 (528)로서 로컬에서 저장될 것이며 그리고 상기 메타데이터 (504)에서 유지되는 상태들을 변경하기 위해서 또한 사용될 수 있을 것이다.

상기 문서로부터 데이터 (526, 528) 추출, 파싱 (parsing) 및 입력은 필드 기술자들 (530)에 의해 도움을 받을 수 있을 것이며, 그 필드 기술자들은 사용자에게는 보일 수도 있고 보이지 않을 수도 있을 것이다. 그런 기술자들 (530)은, 예를 들면, 문서가 복수의 언어들을 위해서 부합되는 경우에 유용할 수 있을 것이다. 상기 필드 기술들 (530)은 모든 로컬화된 버전들에는 공통일 것이며, 그래서 상기 메타데이터 (504)를 수정하는 것과 같은 목적들 위해서 사용자가 입력한 데이터를 추출하는 것을 용이하게 한다.

또한 비즈니스 데이터의 일부로서 도시된 것은, 비즈니스 프로세스들에 대한 일부 지식을 캡쳐하는 기능을 명시적으로 포함하는 형태/템플리트/행동 (532)이다. 이 데이터 (532)는 다른 사용자 데이터 (526, 528, 530)의 일부로서 포함될 수도 있을 것이며, 또는 별개의 개체로서 간주될 수도 있을 것이다. 예를 들면, 상기 문서 (502)는 템플리트 데이터 (532)만을 포함하는 하나의 템플리트로부터 형성될 수 있을 것이며, 그리고 이 템플리트 (532)는, 사용자 입력들과 결합하여, 상기 문서 (502)의 초기 메타데이터 (504)와 비즈니스 데이터 (506)를 형성하기 위해 사용된다. 이 템플리트 데이터 (532)는, 추가적인 문서나 서브-문서들을 생성하기 위한 것처럼, 상기 문서 (502) 내에 남아있을 수 있을 것이다. 다른 예에서, 이 데이터 (532)는 사용자 입력들 및/또는 다른 시스템 이벤트들을 기반으로 하여 다른 데이터 (526, 528, 530)에 따라서 행동하는, 프로세서 동작 가능한 코드 (예를 들면, 스크립트, 내장된 바이너리 객체)를 포함할 수 있을 것이다.

이런 문서-내장된 메타데이터가 본 발명의 예시적인 실시예들에 따라서 어떻게 사용되는가에 대한 일 예가 도 6 및 도 7의 블록도들에서 보여진다. 도 6에서, 다양한 규칙들 (예를 들면, 승인자 (602))이, 그래프의 가장자리들로서 도시된 문서들 (예를 들면, 승인된 계획 (604))을 구비한, 지시된 그래프의 정점들로서 도시된다. 도 6에서의 그래프는 여행 계획 및 티켓 예약을 지원하는 문서 흐름의 특정한 예에 관련된다. 특히, 문서 관리 시스템의 시야들 (예를 들면, 참조번호 608의 시야)은 여행 계획과 티켓 구매 동작들의 수많은 단계들을 프로세스하는 비서 (606)의 역할에 대해 부합된 것이다.

비서 (606)가 승인된 계획 문서 (604)를 수신하면, 그 비서의 사용자 인터페이스는 블록 (608)에 도시된 것과 같은, 스레드로 된 문서 흐름을 보여줄 것이다. 십자가 모습의 심볼 (610)은 스레드를 나타내며, 종이 심볼 (612)은 그 스레드에 속한 문서를 나타낸다. 스레드들이 여기에서는 완전하게 개방된 트리 시야인 것으로 도시되지만, 그것들은 파일 시스템과 유사하게 동시에 하나의 레벨로 디스플레이될 수도 있다는 것에 유의한다. 파일 시스템은, 제한된 수평 스크린 공간이 들여 쓰기를 어렵게 만드는, 모바일 기기 상에서 더 잘 동작할 수 있을 것이다. 대체의 시야들이 블록들 (614, 616)에서 도시된다. 시야 (614)에서, 계층의 선택된 레벨 (여기에서는 스레드 레벨)이 왼쪽의 구획 (618)에 도시되며, 상기 선택된 레벨의 아래의 아이템들은 오른쪽 구획 (620)에 도시된다. 시야 (616)에서, 각각의 계층적인 레벨은 "평평한" 시야로 디스플레이되며, 이때에 헤더 부분 (622)은 현재의 "컨테이너 (container)"를 가리키며, 목록 부분 (624)은 상기 컨테이너 내의 모든 아이템들을 보여준다. 사용자는 제어부 (526)을 선택하여 상기 계층의 상향으로 이동하며, 상기 목록 (624)으로부터 어떤 아이템을 선택하여 상기 계층의 하단으로 이동한다. 본 발명이 속한 기술 분야에서 알려진 다른 시야들 (예를 들면, 지시된 그래프, 주석이 달린 목록 등) 또한 해결 방안 영역과 목표 사용자 인터페이스들로 적절하게 사용될 수 있을 것이다.

상기 여행 스레드 (610)는 비서의 역할에 대한 프로세스들을 보여주기 위해서 설립된 이런 인스턴스이다. 그러므로, 이 시나리오에서, 승인된 계획 문서 (604)가 상기 비서 (606)에 의해 수신될 때에 상기 여행 스레드 (610)가 생성된다. 비록 여행 스레드가 일부 더 빠른 이벤트에 의해, 예를 들면, 여행자 (630)가 승인자 (602)에게 초기 계획 (628)을 제출할 때에, 생각처럼 생성될 수 있을 것이지만, 이 스레드는 그 문서 (628)에 대한 지식을 전혀 가지고 있지 않은 상기 비서 (606)에게는 특별한 것이다.

승인된 계획 문서 (604)는 여행 스레드에 대한 기술자를 포함하며, 그 여행 스레드는 상기 스레드 ("여행 (Travel)")의 주제, 고유 스레드 ID 그리고 아마도 (겹쳐진 스레드들의 경우) 상기 스레드의 부모 스레드의 ID를 포함할 수 있을 것이다. 이것이 상기 클라이언트 (606)가 수신한 그 스레드에 속한 첫 번째 문서이기 때문에, 대응하는 어떤 스레드도 클라이언트 (606)에서는 발견되지 않으며 새로운 것이 생성되며 상기 문서가 그 새로운 스레드에 첨부된다. (아이콘 (610)과 연관된 텍스트 내의 인용 마크들 내에 도시된) 상기 새로운 스레드의 상태는 StateUpdate 필드 (예를 들면, 도 5의 필드 (508))로부터 설정된다. 상기 StateUpdate 필드의 내용들은 아이콘 (612)을 동반하는 설명의 텍스트 내의 괄호들 내에 도시된다. 시야 (608)에서 도시된 상기의 괄호가 쳐진 텍스트와 화살표는 상기 문서 (612)의 StateUpdate 그리고 상기 스레드 (610)의 상태 사이에서의 관계/업데이트들을 도시하는 것이 목적이며, 상기 사용자 인터페이스의 부분일 필요는 없다는 것에 유의한다.

다음에 상기 비서 (606)는 승인된 계획 문서 (604)를 연다. 상기 문서를 열기 위해 사용되는 형식은 비서 (606)가 티켓팅 요청 문서 (632)를 여행사 (636)의 예약 역할 (634)로 송신할 것을 허용한다. 상기 형식은 여행 스레드 기술자를 상기 새로운 문서 (632)로 복사한다. 이 예에서, 상기 프로세스의 이런 부분 (예를 들면, 여행사 (636)에 의해 취해지는 단계들)은 상기 서비스를 생성할 때에 하나의 서브-프로세스로서 모델링된다. 그러므로, 상기 형식은 상기 문서 (632)에 새로운 스레드 기술자 "티켓팅 (Ticketing)"을 또한 첨부하며, 그 새로운 스레드 기술자를 상기 문서 (632)의 인접 (immediate) 부모로서 표시하며, 그리고 오래된 "여행 (Travel)" 스레드 기술자를 그 새로운 스레드 기술자의 부모로서 표시한다. 상기 StateUpdate 필드 (예를 들면, 도 5의 필드 (508))는 텍스트 "티켓들이 주문되었음 (Tickets Ordered)"을 포함하기 위해 상기 형식에 의해 설정된다.

결과인 사용자 인터페이스 (예를 들면, 시야 (608)를 기반으로 하는 업데이트된 인터페이스)가 도 7의 시야 (702)에서 도시된다. 새로운 스레드 (704)는 스레드 (610)의 자녀로서 도시되며, 상기 새로운 스레드는 티켓 요청 (ticket request) 문서 (706)를 포함한다. 상기 문서 (706)과 연과된 아이콘 (706)은 (예를 들면, 내부에 화살표가 있는 종이 심볼) 송신된 문서를 나타낸다. 시야 (608)에서와 같이, 시야 (702)에서 괄호가 된 텍스트와 가는 화살표는 상태 전파 (state propagation)를 도시하며 사용자 인터페이스에는 꼭 나타날 필요는 없다. 시야 (702)에서 티켓팅 (Ticketing) 스레드 (704)의 상태가 티켓팅 요청 (Ticketing Request, 706)의 상태에 의해 어떻게 업데이트 되는가에 주목하며, 그렇지만 상기 업데이트는 여행 스레드 (702)로는 전파되지 않는다는 것에 주목한다.

돌아가서 도 6을 참조하면, 티켓들을 포함하는 문서 (637)와 송장 (invoice)이 여행사 (636)로부터 도착한다. 이 문서 (637)는 도 7의 시야 (708)에서의 아이콘 (710)에 의해 반영된다. 또한 이 시야 (708)에서 보이는 것과 같이, 티켓팅 (Ticketing) 스레드 (704A)의 상태는 티켓들의 StatusUpdate 필드 그리고 송장 (Invoice) 문서 (710)를 기반으로 하여 업데이트된다. "티켓 수신됨 (Tickets Received)" 상태는 (스레드 완료를 나타내는 상태 값들의 설정된 역할-특정 목록 중의 하나 또는 그 이상 그리고/또는 문서 메타데이터 (504) 내의 THREAD_COMPLETE 플래그 (510)를 기반으로 하여) 상기 티켓팅 (Ticketing) 스레드가 완료된 것을 의미하기 때문에, 스레드 (704A)는 완료된 것으로 표시된다. (예를 들면, 도 5에서 보여지는 것과 같이 ThreadComplete 플래그 (510)를 설정함으로써) 스레드 (704A)의 변화된 상태가 스레드 완료를 또한 포함하기 때문에, 상기 상태 업데이트는 부모 여행 스레드 (610A)로 전파되며, 부모 여행 스레드 (610A)는 문서 (710)의 상태를 이제 반영한다. 상기 StateUpdate 필드 콘텐츠들 보여주는, 괄호가 쳐진 텍스트는 마지막 메시지에 대해서만 보일 뿐이라는 것에 유의한다.

도 6을 다시 참조하면, 비서 (606)는 상기 티켓들 및 송장 문서 (637)를 다음에 연다. 상기 문서를 열기 위해 사용된 형식은 티켓들 (638)을 여행자 (630)에게 포워딩하기 위한 버튼을 포함할 수 있을 것이다. 상기 비서는 상기 정보를 검사하고 "여행자에게 포워딩 (Forward to traveler)" 버튼을 누른다. 그 형식은 새로운 티켓들 (Tickets) 문서는 티켓팅 (Ticketing) 스레드에는 속하지 않는다는 것을 알고 있으며, 상기 티켓들 문서로부터 상기 티켓팅 스레드 기술자를 제거하고, 그리고 상기 남아있는 여행 스레드 기술자를 상기 문서의 인접 부모로 만든다. 이는 도 7의 시야 712에서 보여진다. 사용자 인터페이스 컴포넌트 (714)는 상기 여행자에게 송신된 티켓들을 나타내며, 컴포넌트 (714)는 상기 문서의 StateUpdate 필드가 "티켓들 배송됨 (Tickets Delivered)"으로 설정된 것을 나타낸다. 상기 티켓들 (714)은 가장 최근의 문서 컴포넌트이기 때문에, 상기 여행 스레드 (610B)의 상태는 이제 "티켓들 배송됨 (Tickets Delivered)"으로 된다.

다시 도 6을 참조하면, 비서 (606)는 나중에 모든 송장들을 나중에 프로세스한다 (예를 들면, 달의 말일에). 이는 티켓들 및 송장 문서(637)를 다시 열어서, 이번에는 "계산으로 포워딩" 버튼을 눌러서 실행된다. 상기 형식은 상기 비서에게 경비-관련 정보 (가격 코드들, 예정 비용 등)로 채울 것을 요구하고 일단 완료되면 그 송장 문서 (640)를 계산 (642)으로 송신한다. 이번에는 (다른 버튼을 사용하는 것을 기반으로 하여) 상기 형식은 새로운 문서의 StateUpdate 필드를 "송장 송신 (Invoice Sent)"으로 설정한다. 이 새로운 문서는 도 7에서 시야 (716) 내의 컴포넌트 (718)로서 보여진다. 상태의 변화는 여행 스레드 (610C)의 상태의 변화를 일으키게 하고, 스레드 완료를 나타내는 상태값들의 설정된 역할-특정 목록 및/또는 문서 메타데이타 (504) 내의 THREAD_COMPLETE 플래그 (510)를 기반으로 하여, 또한 상기 스레드 (610C)가 상기 비서 (606)에 대해서는 완료로서 표시되도록 할 것이다.

상기에서 설명된 시나리오는 문서 도착 순서가 정의되지 않은 경우들을 처리하지 않을 것이다. 예를 들면, 여행사가 티켓팅 요청에 대해 호텔 예약 문서 그리고 항공 예약 문서의 두 가지 모두로 응답하지만, 순서는 먼저 발견된 것에 의해 결정되는 것으로 가정한다 (예를 들면, 먼저 도착한 것이 어느 것인지 미리 알려지지 않았다). 그런 경우에 필요한 행위는 호텔 예약 문서가 도착했을 때에, 비행 예약 문서는 아직 도착하지 않았다면 스레드 상태는 "호텔 예약됨 (Hotel Reserved)"으로 되지만, 비행 예약 문서가 이미 도착했으면, (항공 및 호텔 예약들이 둘 다 도착했기 때문에) 상기 새로운 상태는 "예약들 완료 (Reservations Complete)"가 되어야 한다. 이는 각 문서가 여러 개의 StateUpdate 필드들을 포함하도록 하고, 각 StateUpdate 필드는 새로운 상태와 현재 상태를 위한 조건을 둘 다 포함하도록 하여 해결될 수 있을 것이다. 호텔 예약이 수신되는 경우에 대한 StateUpdate 필드의 예는 이 예에서 다음의 목록 1과 같이 도시된다.

[목록 1]

<StateUpdate currentState="Flights Reserved"

newState="Reservations Complete"/>

<StateUpdate currentState="Tickets Ordered"

newState="Hotel Reserved"/>

(Copyright^c 2008, Nokia Inc.)

목록 1에서 도시된 예의 완전한 행동은, 상태들 사이에서의 천이가 특정 상태 천이를 유발하는 기초가 되는 문서들 (및/또는 문서 상태들)에 의해 표시될 수 있는, 유한 상태 머신으로서 모델링될 수 있을 것이다. 이 해결책은, 비록 정해지지 않은 순서로 도착하는 문서들의 개수를 항상 잘 어림잡아 계산하는 것은 아닐 수 있겠지만, 구현하기에 상당히 직접적이다. 상태 기술은 수신된 문서들의 가능한 결합 각각에 대해 주어져야 하며, 그러므로, n 개의 문서들에 필요한 기술들의 총 개수는

이다. (예를 들면, n=5인 경우, 필요한 기술들의 개수는 31이다)

문서 기술 프레임워크에서 필요할 수 있는 다른 특징은 조상 스레드들에 대한 상이한 상태 기술들을 구비하며, 자녀 스레드 중간에 부모 스레드 상태를 변경하는 것을 지원하는 것을 구비하는 것이다. 예를 들면, 티켓들과 송장이 별개의 문서로 여행사에 의해 송신되고, 티켓들이 때로는 송장보다 먼저 도착하면, 비록 티켓팅 스레드 그 자체가 분실된 송장 문서로 인해서 기술적으로는 완료되지 않았지만, 티켓들이 도착할 때마다 여행 스레드는 상태를 "티켓팅 종료됨 (Ticketing Finished)"으로 변경하는 것이 타당할 것이다. 그것은 조상 스레드들에 대한 상이한 상태 기술들을 가지는 것을 지원하지 않을 수 있을 것이다. 예를 들면, 송장을 수신한 후에, 티켓팅 스레드는 완료되며, 그래서 그 상태를 "종료됨 (Finished)"으로 될 것이라는 것이 타당할 것이지만, 부모 스레드의 상태가 그 시점에는 "종료됨"으로 기술될 수 없기 때문에 그런 방식은 사용될 수 없다.

이런 부가적인 유연성을 제공하기 위해, 각 문서는 하나의 상태 기술 대신에 하나 또는 그 이상의 태그들을 나를 수 있을 것이다. 각 태그는 그 프로세스에서 이미 발생한 하나의 이벤트에 대응한다. 그 태그를 포함하는 문서가 도착하면 스레드는 하나의 태그를 수신하며, 그러면 그 스레드는 상기 문서의 근접한 부모이다. 각 스레드는 자신이 수신했던 태그들의 자취 그리고 자신이 각 태그를 얼마나 여러 번 수신했는가를 보유한다.

태그들을 상태들로 변환하는 규칙들은 클라이언트 설정에 포함될 수 있을 것이다. 상기 규칙들을 스레드들로 매핑하기 위해, 상기 스레드들의 유형을 정하는 것이, 예를 들면, 스레드 기술자가 스레드의 유형을 또한 포함하도록 하는 것이 필요할 것이다. 이는, 문서의 유형이 파일 이름 확장자, 파일 시스템 메타데이터 및 파일 내에 내장된 메타데이터를 이용하는 것처럼, 문서의 유형이 어떻게 표시될 것인가와 유사하다. 여행 스레드 예에 관련된 설정은 아래의 표 1에서의 다음의 상태들과 유사한 정보를 포함할 수 있을 것이다.

행	스레드 유형	역할	태그들	상태	부모로 전파	완료
1	여행 (Travel)	비서	InvoiceDelivered	"송장 송신 (Invoice Sent)"		TRUE
2	여행 (Travel)	비서	TicketsDelivered	"티켓들 배송 (Tickets Delivered)"		false
3	여행 (Travel)	비서	TicketsReceived (1-2)	"티켓팅 완료 (Ticketing Complete)"		false
4	여행 (Travel)	비서	PlanApproved	"티켓들 대기 (Waiting for Tickets)"		false
5	티켓팅 (Ticketing)	비서	TicketsWritten, InvoiceWritten	"완료 (Complete)"	TicketsReceived	TRUE
6	티켓팅 (Ticketing)	비서	InvoiceWritten, TicketsWritten(0)	"송장 수신 (Invoice Received)"		false
7	티켓팅 (Ticketing)	비서	TicketsWritten, InvoiceWritten(0)	"티켓들 수신 (Tickets Received)"	TicketsReceived	false
8	티켓팅 (Ticketing)	비서	TicketsOrdered	"티켓들 주문 (Tickets Ordered)"		false
	...	...	...	...	...	...

표 1에서의 표의 표현은 용이하게 읽을 수 있도록 제시된 예시의 일 실시예라는 것이 이해될 것이다. 문서 프레임워크에서, 확장 가능한 마크업 언어 (eXtensible Markup Language (XML)) 코드, 이진 데이터 포맷들, 내장된 이진 객체들 (예를 들면, Java™ 애플릿들), 링크된 목록들, 해쉬 집합들 등과 같은, 컴퓨터로 읽을 수 있는 그리고 파싱 (parsing) 가능한 데이터 구조 및/또는 명령어들이 사용될 수 있을 것이다. 스레드 상태들을 추적하는 클라이언트 (또는 다른 개체)는, 각 시각마다 스레드의 태그가 변화하는, 도 1에서 도시된 것과 같은 데이터 구조를 참조할 수 있을 것이다. 취해야 하는 행동을 결정하기 위해, 상기 클라이언트는 표의 행들을 순서대로 (위에서부터 밑으로) 가로질러서 스레드 유형, 역할, 및 태그들과 부합하는 첫 번째 행을 이용할 수 있을 것이다. 스레드 유형 열은 상기 스레드가 부합해야 하는 스레드 유형을 제시한다. 역할 열은 부합할 필요가 있는 스레드에서의 사용자/참여자 역할을 제시하며, 그리고, 상태 열은 스레드의 새로운 상태를 제시한다. 부모로의 전파는 부합하는 스레드의 부모 스레드로 부가되어야 하는 태그들의 목록을 제시한다. 완료 열이 참 (true)이면, 부합하는 스레드는 완료로 표시되어야만 한다. 태그들은 상기 스레드가 부합해야만 하는 태그 카운트들의 목록을 제시한다. 카운트 간격 (최소-최대)은 각 태그에 부착될 수 있을 것이며, 이 간격들은 아래의 표 2에서 도시된 것과 같이 미리 정의된 속기를 이용하여 전체적으로 또는 부분적으로 누락될 수 있다.

카운트 간격 속기	카운트 간격
(n)	(n-n)
(n-)	(n-무한)
(-n)	(1-n)
간격이 주어지지 않음	(1-무한)

이런 규칙들에 따라서, 카운트 간격 속기 (0)은 상기 태그는 스레드에 나타나지 않아야 한다는 것을 의미하며, 구간이 없다는 것은 태그가 반드시 적어도 한번은 나타냐야 한다는 것을 의미한다. 상태 진행의 역방향 순서에서의 상태들을 목록으로 하여, 대부분의 경우에 (0) 간격을 사용하는 것을 생략할 수 있다 (그것은 상태 진행 순서가 미리 알려지지 않은 경우에만 필요할 것이다). 예를 들면, "티켓들 대기 (Waiting for Tickets)" 상태가 네 번째가 아니라 첫 번째이면, 태그 열에서 "PlanApproved" 대신에 "PlanApproved, TicketsReceived (0)"을 사용하는 것이 필요할 것이다.

상기 구간들은, 당신이 상태들을 "Empty" (0 등록), "너무 적은 등록자들 (Too few participants)" (1-9 등록자들), "확인됨 (Confirmed)" (10-20 등록자들) 그리고 "과다예약 (Overbooked)" (21 또는 그 이상의 등록자들) 상태로 구비하기를 원하는 경우인, 코스 (course) 등록과 유사한 경우에 유용하다. 태그들에 추가로, 문서는 "48% 완료"와 같은 자유스러운 형식 상태 기술들 또한 운송할 수 있다. 이는 근접한 부모 스레드의 상태 기술에 첨부될 수 있지만, 조상 스레드들로 전파될 필요는 없다.

도 8 및 도 9를 이제 참고하면, 블록도들은 본 발명의 대체의 예시적인 실시예에 따른 문서 관리 프레임워크의 시야들을 포함한다. 도 8 및 도 9에서의 사용자 인터페이스 시야들은 도 6에서 보여진 티켓 예약 경우의 스레드 상태들을 보여준다. 이 예는 표 1에서 도시된 것과 같이 태그들의 사용에 의해 제공되는 유연성의 이점을 취한다.

시야 (802)에서 보여지는 것과 같이 (그리고 도 6에서 보여진 시나리오와 유사하게), 여행 스레드는 승인된 계획 문서가 수신될 때에 생성된다. 새로운 스레드의 (괄호들 내에 보여지는) 태그들은 상기 문서의 태그들로부터 복제된다. (인용 마크들 내에서 보여지는) 상기 스레드의 상태는 상기 스레드의 태그들을 상태 표와 비교하여 결정된다. 각 행이 순서대로 검사되고, 부합되는 첫 번째 것이 적용된다. 이 경우에, 표 1의 4행이 부합되며 그래서 스레드 상태는 "티켓들 대기 (Waiting for Tickets)"로 설정된다.

다음, 비서가 상기 승인된 계획 (Approved Plan) 문서를 연다. 그 문서를 열기 위해 사용된 형식은 상기 비서가 여행사로 티켓팅 요청 문서를 송신하는 것을 허용한다. 그 형식은 상기 여행 스레드 기술자를 새로운 문서로 복사한다. 이는 상기 서비스를 생성할 때에 서브-프로세스로서 모델링되었기 때문에, 상기 형식은 새로운 스레드 기술자 "티켓팅 (Ticketing)"을 상기 문서에게도 또한 부착하며, 상기 새로운 스레드 기술자를 근접한 부모로서 표시하며, 오래된 여행 스레드 기술자를 상기 새로운 스레드 기술자의 부모로서 표시한다. 상기 새로운 문서의 태그들은 "TicketsOrdered"로 설정된다. 결과인 사용자 인터페이스는 시야 (804)에서 보여진다. 시야 (804)에서 (화살표에 의해 지시된 것과 같이) 티켓팅 스레드의 태그 목록이 상기 새로운 문서에 의해 어떻게 업데이트 되는가를 주목한다 (티켓팅 요청 ((Ticketing Request)). 상기 스레드의 결과 상태 (티켓들 주문 ((Tickets Ordered))는 표 1의 8행과 비교하여 결정된다.

이런 사용의 경우에, 상기 여행사는 티켓들과 송장을 개별적인 메시지들로 송신할 수 있을 것이며, 이들은 임의 순서로 도착할 것이고, 또는 상기 여행사는 티켓들과 송장의 두 가지 모두를 (도 6에 보여진 이전의 사용 경우와 유사하게) 단일의 메시지로 송신할 수 있을 것이다. 상태 표는 이런 경우들 모두를 허용한다. 그러나, 단일의 메시지가 티켓들과 송장 두 가지 모두를 운송하도록 하는 것은 표 1의 5행이 TicketsReceived 태그를 전파했으며, 그러므로, 한 메시지가 티켓들과 송장 모두를 위해 사용되었으면, 상기 여행 스레드는 상기 TicketsReceived 태그를 한차례 수신할 것이며, 별개의 메시지들이 사용되었으면 두 번 수신할 것이다. 그러므로, 표 1의 3행은, 행과 비교하기 위해서 TicketsReceived 태그가 한번 또는 두 번 나타날 것으로 지정한다. 구간 (1-2)는 예시의 목적으로 사용된 표이며; 구간이 주어지지 않을 때에 사용되는 디폴트 구간 (1-무한) 역시 동작할 것이다.

이 예에서, 상기 티켓들 및 송장은 개별적으로 도착한다. 먼저, 상기 티켓들을 포함하는 문서가 여행사로부터 도착한다. 이는 시야 (808)에서 보여진다. 상기 티켓팅 (Ticketing) 스레드의 태그 목록은 티켓들 문서 (Tickets document)의 태그들을 기반으로 하여 업데이트된다. 상기 태그 목록은 상태 표 1과 비교되며, 표 1에서 7행이 "티켓들 쓰여짐 (Tickets Written)" 태그와 부합된다. 자유 형식의 텍스트 "비즈니스 클래스 (business class)"가 괄호 내에 첨부되며, 그래서 티켓팅 스레드의 전체 상태는 이제 "티켓 수신 (비즈니스 클래스), Tickets Received (business class)"이다. 표 1에서 행을 맞추어보는 것이 부모 태그 TicketsReceived 로의 전파를 포함하기 때문에, 그 태그는 부모 (여행) 스레드에 부가된다. 여행 스레드로 전파된 상기 새로운 상태는 화살표 (809)에 의해 표시된 것과 같이 "티켓들 수신 (Tickets Received)"이다. 이제 상기 여행 스레드는 상태 테이블의 3번째 행을 맞추어보고, (여행 스레드의 관점에서) "티켓팅 완료 (Ticketing Complete)" 상태를 얻는다 (그리고 티켓들이 수신되면, 비록 그 티켓팅 프로세스가 아직 완료되지 않았다고 해도 티켓팅은 완료될 수 있을 것이다).

다음, 시야 (808)에서 보여지는 것처럼, 송장을 포함하는 문서가 여행사로부터 도착한다. 티켓팅 스레드의 태크 목록인 송장 문서의 태그들을 기반으로 하여 업데이트된다. 그 태그 목록은 상태 표 1과 비교된다. 표 1의 다섯 번째 행이 부합되고 그러면 새로운 상태는 "완료 (Complete)"이다. 5번째 행의 완료 플래그는 참 (true)이며, 그래서 티켓팅 스레드는 이제 완료된다 (도면에서 "COMPLETED"로 표시됨). 자유 형식의 텍스트 "5000 EUR"가 괄호 속의 상태 기술에 추가되어, 티켓팅 스레드의 완전한 상태는 이제 ""Complete (5000 EUR)"이다. 상태 표에서 부합하는 행이

부모 태그 TicketsReceived 로의 전파 (Propagate)를 포함하기 때문에, 그 태그는 부모 (여행) 스레드에 부가되며, 그래서 그 부모 스레드는 TicketsReceived 태그를 두 번 포함하게 된다. 여행 스레드는 여전히 상기 상태 표의 3번째 행과 부합하며, 그래서 그 상태는 변화하지 않는다 (예를 들면, "티켓팅 완료 (Ticketing Complete)"로 유지된다).

다음, 비서가 티켓들 문서를 연다. 그 문서를 열기 위해 사용된 형식은 티켓들을 여행자에게 포워딩하기 위한 버튼을 구비한다. 그 비서는 정보를 체크하고 "여행자에게 포워딩 (Forward to traveler)" 버튼을 누른다. 상기 형식은 새로운 문서가 상기 티켓팅 스레드에 속하지 않는다는 것을 알고, 그래서 그 새로운 문서에서 상기 티켓팅 스레드 기술자를 제거하고 남아있는 여행 스레드 기술자를 상기 문서의 근접한 부모로 만든다. 상기 문서의 태그들은 시야 (810)에서 보여지는 것과 같이 "TicketsDelivered"로 설정된다. 그 송신된 문서가 상기 여행 스레드에 추가되기 때문에, 상기 TicketsDelivered 태그는 상기 여행 스레드의 태그들에 추가된다. 그 스레드는 이제 상태 표에서의 두 번째 행과 부합하며 그래서 상태 기술 "티켓들 배송 (Tickets Delivered)"을 얻는다.

그 달의 마지막에서, 비서는 모든 송장들을 프로세싱한다. 이는 송장 문서를 열고 그 사용 형식에서 "계산으로 포워딩" 버튼을 눌러서 실행된다. 그 형식은 상기 비서가 경비-관련 정보 (가격 코드들, 예정 비용 등)로 채울 것을 요청하며, 일단 완료하면, 그 송장 문서를 계산하는 곳으로 송신한다. 상기 형식은 새로운 문서의 태그들을 "InvoiceDelivered"으로 설정한다. 상기 송신된 문서가 여행 스레드에 추가되기 때문에, 상기 InvoiceDelivered 태그는, 도 9의 시야 (910)에서 보이는 것과 같이, 상기 여행 스레드의 태그에 추가된다. 그 스레드는 이제 상태 표 1 내의 첫 번째 행과 부합하며, 상태 기술 "송장 송신 (Invoice Sent)"을 얻는다. 상기 첫 번째 행 상의 완료 플래그는 참 (true)이며, 그래서 여행 스레드 또한 (도면에서 "-COMPLETED"로 표시되어) 완료된다.

상기에서 설명된 것과 같이, 문서 흐름 프레임워크와 같이 통합된 문서들을 생성하기 위해 템플리트들이 사용된다. 상기 템플리트들은 현재 워크플로우 상태들과 비즈니스 프로세스들에 대한 지식을 모델링할 수 있다. 일반적으로, 워크플로우는 일반적이며 쉽게 맞춤 가능한 콘텐트와 워크플로우 템플리트들을 이용하는 것을 통해 더 효율적으로 될 수 있다. 예를 들면, 워크플로우 문서들은, 워크플로우 참여자들에 의해 생성된 그리고/또는 상기 프로세스 흐름들에서 다른 문서들로부터 복사/상속받은 메타데이터 기술들 (예를 들면, XML 포맷된 기술자들)을 이용하여 맞춤으로 될 수 있다. 이런 메타데이터는 브라우저들과 같은 표준화된 도구들을 사용하여 (예를 들면, 웹 기반의 위자드 (wizard)를 경유하여) 입력되고/모을 수 있다. 제한된 프로세싱 및/또는 네트워크 대역폭을 가진 모바일 기기들이나 다른 장치에 대해, 상기 시스템은 선택된 콘텐트를 구비한 메타데이타만을 첫 번째 단계로서 통과시킬 수 있을 것이다. 추가의 행동들이 필요하면, 사용자는 (예를 들면, 모바일 이메일과 유사하게) 추가적인 첨부 데이터를 다운로드할 것을 선택할 수 있을 것이다.

사용자나 개발자는 사용하기 쉬운 위자드나 (개발자의 경우에는) 텍스트 편집기를 사용하여 워크플로우 템플리트를 생성할 수 있다. 템플리트는 워크/문서 흐름 단계들 및 다른 규칙들을 설명하는 XML 또는 확장 가능한 하이퍼텍스트 마크업 언어 (eXtensible Hypertext Markup Language (XHTML))로서 생성될 수 있을 것이다. 형식은 추가의 데이터 입력을 하기 위해 사용자에게 보여질 수 있을 것이며, 일단 완료되면, 그 문서들은 흐름을 통해서 다른 개체들로 포워딩될 수 있다. 그 문서는 내장된 XML 기술 (describing) 워크플로우 메타데이터, 형식 기술들, 스레드 기술들, 스레드 상태 태그들 등을 포함할 수 있을 것이다. 상기 내장된 XML은 이하에서는 '티켓 (ticket)'으로서 설명될 것이며, 수용자 (recipient)가 비즈니스 프로세스의 규칙들에 따라서 기초가 되는 형식들/문서들 상에서 동작하는 것을 허용하는 데이터의 최소 집합을 포함할 수 있을 것이다.

상기 형식의 각 필드에 대해, 몇가지 속성 설정들이 있을 수 있다. 속성들은, 예를 들면, (메타데이터와 비즈니스 데이터를 포함하는) 특정 데이터 필드들을 "내장 (embed)" 또는 "첨부 (attach)"로서 설정하는 것을 포함한다. 상기 "내장" 속성은 (이름, 주소 등과 같은) 입력된 데이터가 상기 형식 내에서 다음의 단계/수용자로 통과하는 것을 표시할 수 있을 것이다. 상기 "첨부" 속성은 첨부된 것을 다운로드하려는 행동이 추론되거나 제공되는 것을 표시할 수 있을 것이다. 콘텐트를 다운로드하기 위한 옵션은 새로운 문서들을 수신할 때에 응답 시간을 개선하기 위한 모바일 사용자들에게 이익을 줄 수 있을 것이다. 그런 첨부된 것에 대한 고유 URL (Uniform Resource Locator)은 서버에 의해 즉석에서 생성된다.

메타데이터와 송신된 콘텐츠를 기반으로 하여, 모바일 클라이언트는 (예를 들면, XHTML 기반의 브라우저처럼 행동하는) 사용자 인터페이스를 즉석에서 생성할 수 있다. 상기 워크플로우의 다음 사람은 템플리트에서 설명된 형식 의존 역할들과 제한들의 허용된 필드들의 콘텐트를 변화시킬 수 있을 것이다 (예를 들면, 필드 레벨 허가들은 "읽기 전용", "현존 데이터에 추가", "수정", "삭제" 등을 포함할 수 있을 것이다). 예를 들면, 프로세스와 태스크들 그리고 그 프로세스와 연관된 문서들의 무결성을 보호하기 위해, 결과 문서들과 메타데이터 (예를 들면, 워크플로우 기술 (description))의 부분들을 보호하는 것은 물론이며 템플리트 자체를 보호하기를 원하면 상기 템플리트는 디지털 서명에 의해 보호될 수 있을 것이다. 상기에서 아주 상세하게 설명된 것과 같이, 문서들 그리고 그 문서들에 내장되거나/연관된 메타데이터 모두에 대한 변화는 문서 생성, 삭제, 수정 등에 의해 바뀔 수 있을 것이다. 그처럼, 동적으로 생성된 사용자 인터페이스는 보고 그리고/또는 편집하기 위한 상기 문서의 다양한 버전들을 생산하기 위해 사용될 수 있을 것이다. 또한, 상기에서 도 2와 관련하여 설명된 것과 같이, 수신한 전자 문서들의 외부에서 메타데이터가 전달되는 경우 (예를 들면, 종이 문서), 상기 워크플로우 템플리트들은 상기 메타데이터를 수정하고 전달하기 위한 형식들을 생성하기 위해 또한 사용될 수 있다. 예를 들면, 사람이 종이 문서를 리뷰하고 사인하는 경우, 그 사람은 상기 문서상의 바코드를 모바일 기기를 이용하여 스캔할 수 있을 것이며, 그 기기가 상기 메타데이터에 액세스하고 그 메타데이터를 사용하기 쉬운 포맷으로 (예를 들면, 선택 버튼들) 제공하도록 하여 상기 스레드 데이터는 그에 따라서 업데이트될 수 있다.

이런 유형의 템플리트들은 1) 미리 정의된 워크플로우를 정의하고; 2) 특정 워크 플로우의 단계들/태스크들의 미리 정의된 목록을 실행하기 위한 "개시" 옵션을 제공하고 템플리트에서 기술된 수용자들을 그 특정한 단계들/태스크들에 할당하고; 그리고/또는 3) 상기 워크플로우의 각 단계에 대해 "수용자 (recipient)"를 검색하기 위한 완전한 자유를 부여할 수 있을 것이다. 상기 "수용자"는 서비스 사용자 등록에서의 사용자 이름, 이메일 주소 및/또는 단문 메시지 서비스 (Short Message Service (SMS)) 번호의 어떤 조합도 포함할 수 있을 것이다. 서비스의 사용자인 수용자는 서비스에 접속할 때에 들어오는 티켓들에 대해 통지 받을 것이다. 이메일 사용자는 티켓으로의 링크를 구비한 이메일을 수신할 수 있을 것이며, SMS 사용자는 티켓으로의 링크를 구비한 SMS를 수신할 수 있을 것이며, 그러면 이는 워크플로우 클라이언트에게로 입수될 수 있다. 예를 들면, 새로운 SMS가 미리 결정된 포트에 도착하면 Java 미들릿 (MIDlet)은 자동적으로 구동하도록 설정될 수 있다. 상기 서비스와 계정을 가진 사용자들은 클라이언트를 사용하여 그 서비스에 액세스할 때에 자신들의 개방 티켓들의 목록을 구비한다.

상기 문서 프레임워크는 다음을 지원하는 하나 또는 그 이상의 서버들을 포함할 수 있을 것이다: 1) 목표 개인들/개체들을 검색하여 그 개체들에 관한 관련된 정보 (예를 들면, 비즈니스 프로세스에서의 역할들)를 획득하는 사용자 등록; 2) 템플리트,들, 메타데이터 및 첨부 데이터를 저장하기 위한 "서비스"; 3) 티켓을 수신할 수 있고 티켓을 (그리고 그 내부에 티켓들이 내장된 문서를) (그 자체가 티켓 내에 내장될 수 있는) 비즈니스 규칙에 따라서 다음 수용자에게 송신할 수 있는 문서들의 수용자들의 기기들 내의 "워크플로우 엔진"; 4) 프로세스 개시자들과 특정 티켓/스레드 (예를 들면, 스레드/서브-스레드 상태들 및 완료 이벤트들)를 추적하기 위해 가입한 다른 멤버들에게 신호를 주는 "진행 통고"; 5) (예를 들면, 템플리트 부분 무결성을 위한) 디지털 서명 확인, 콘텐트 암호화와 같은 보안 특징들을 지원. 템플리트들이 생성될 때에 템플리트들의 필요한 부분들에 서명하고 워크플로우에서 매번의 추가의 제출마다 템플리트들/문서들을 확인하기 위해 전반적인 시스템에 의해 인증이 사용될 수 있을 것이다.

상기에서 설명된 실시예들을 위한 워크플로우 클라이언트는 XML 파싱 (parsing)과 동적인 UI 렌더링을 지원하는 클라이언트로 구현될 수 있을 것이다. 그런 클라이언트는 대안의 기술들을 활용할 수 있을 것이다. 예를 들면, Nokia WidSets (www.widsets.com)는 클라이언트와 서버 컴포넌트들 모두를 포함하며, 티켓 메타메이터 및 동적인 렌더링을 지워할 수 있을 것이다. WidSets는 개발자들이 웹으로부터 정보를 검색하는 위젯 (widget)들을 생성하도록 허용하다. 그 위젯들은 웹 정보에 액세스하고 기능성을 제공하며 그리고 위젯의 보고 느끼는 (look and feel) 것을 제어하기 위해 WidSets 스크립 언어 (WidSets Scripting Language (WSL))를 사용하는 텍스트 편집기로 생성될 수 있다. 상기 WSL은 Java™ 프로그래밍 언어와 유사하며 자바 개발과 친숙한 개발자들이 빠르고 효율적으로 위젯들을 생성하는 것을 가능하게 한다.

문서 흐름 프레임워크의 설명된 실시예들에서, WidSets 서버는 문서 저장/생성, 스레드 상태 관리, 스레드 상태 메시징에 연관된 다양한 중앙화된 태스크들을 다루기 위해서 동적인 워크플로우 엔진 플러그-인을 추가하여 확장될 수 있을 것이다. 클라이언트 측에서는, "동적인 워크플로우 위젯"이 클라이언트/모바일 기기들에 배치될 수 있을 것이다. WidSets 클라이언트 기술에 대안으로서, 다른 기술들이 사용될 수 있을 것이다. 예를 들면, 클라이언트/모바일 기기들에서의 형식 렌더링은 S60과 다른 플랫폼에서 웹 런타임 (Web Runtime (WRT)) 위젯들의 심장인 "BrowserComponent"와 같은 현존하는 컴포넌트들을 사용하여 또한 실행될 수 있다. 자바스크립트 (JavaScript)와 Ajax (asynchronous JavaScript and XML)은 WRT에서 지원되며, 요청에 의한 첨부물 로딩을 다루는 것은 물론이며 형식 입력 제출을 다루는데 사용될 수 있다.

다른 실시예들에서, 고유 XML 파서 (parser)를 구비한 클라이언트의 고유한 구현들 (예를 들면, Symbian C++, S40 C, Java, Maemo 등)이 "워크플로우 엔진" 서비스와 인터페이스할 수 있을 것이다. 그러면 그런 서비스는 개인의 또는 공공의 웹 서비스로서 호스팅될 수 있을 것이다. 데스크탑 클라이언트들은 표준의 브라우저들, (예를 들면, 특수한 워크플로우 라이브러리를 구비한) 자바스크립트 및/또는 Ajax를 사용할 수 있을 것이다. 특정 사용자 인터페이스 기술들의 이런 설명들은 예시의 목적으로 제공된 것이며 한정하는 것이 아닌 것이 이해될 것이다.

상기에서 이전에 설명된 것과 같이, 실시예들이 내장된 워크플로우 메타데이터를 활용하기 때문에, 워크플로우를 전진시키고 그리고/또는 스레드와 문서 상태로의 변화를 전달하기 위해 비즈니스 프로세스의 모든 단계/태스크가 서버 접속을 할 필요가 있는 것은 아니다. 예를 들면, 상태 데이터는 국부적으로 업데이트 될 수 있을 것이며 그리고/또는 티켓을 통과하여 내장된 워크플로우의 다음 단계로의 피어-투-피어를 경유하여 업데이트될 수 있을 것이다. 더욱 더 큰 능력 (예를 들면, 더 큰 프로세싱/네트워크 대역폭)이 있는 워크플로우 클라이언트가 상기 티켓을 처리할 때에, 그러면 그 클라이언트는 미정의 진행 업데이트들을 어떤 서비스로 송신할 수 있을 것이다. 흐름의 진행은 (http://..../wfstep?workflow_id=123& step=7 과 유사한) 어떤 URL로의 포스팅에 의해 서버로 또한 보고될 수 있을 것이다. 클라이언트의 경우에, 워크플로우 소유자가 보고 진행의 각 단계에서 참가자들에 관심이 있으면, 그런 보고는 유사한 콘텐트와 같이 SMS를 송신하여 이루어질 수 있을 것이다. 수신 기기가 티켓을 검색할 수 있고 이해할 수 있는 클라이언트를 가지고 있는 한, 티켓들은 (푸시 또는 풀) 서버, 이메일, SMS, 멀티미디어 메시징 서비스 (Multimedia Messaging Service (MMS)) 등을 경유하여 전방으로 또한 통과할 수 있을 것이다.

워크플로우 템플리트들이 XML이면, 새로운 템플리트들을 작성할 수 있는 관리자들, 사용자들, 그리고/또는 개발자들이 존재할 것이다. (예를 들면, 상이한 참여자들이 일부 조정 책임을 가지는 경우에 최종 사용자가 재창조적인 이벤트를 조정하는 경우인) 그런 상황들에서, 준비가 된 배치를 위해서 미리 만들어진 템플리트들이 표준의 또는 잘 알려진 비즈니스 프로세스들에 종사하는 개체들에게 제공될 수 있을 것이다. 이런 미리 만들어진 템플리트들과 비즈니스/문서 흐름 로직을 생성/맞춤 제작하는 것은 웹 기반의 위자드를 경유해서 실시될 수 있을 것이다. 그런 위자드에서, 최종 사용자들은 단계들의 개수, 행동들 및 각 단계에 대한 설명 텍스트를 입력하고, 각 단계에 대해서 책임을 지는 사람들 (주소록으로부터의 접촉 정보)을 추가할 수 있을 것이다. 추가로, 상기 사용자는, 필요하다면 체크박스를 선택하여 선택된 단계들로부터의 피드백을 활성화할 수 있을 것이다. 스레드들을 분기시키기, 서브-스레드들 식별 및 스레드들/서브스레드들 동기화와 같은 더욱 앞선 특징들이 상기 위자드의 더 진보된 모드들에 추가될 수 있을 것이다. 도 6에 도시된 것과 같이, 비즈니스 프로세스들을 정의하는 지시된 (directed) 그래프들을 구축하기 위해서 GUI를 이용하는 것과 같은 다른 유형의 입력들 또한 사용될 수 있을 것이다.

많은 유형의 장치들이 여기에서 설명된 것과 같이 최종 사용자가 문서 흐름들을 프로세싱하기 위해 사용될 수 있을 것이다. 예를 들면, 사용자들이 모바일 전화기들을 자신의 주된 또는 부차적인 컴퓨팅 기기들로서 사용하는 것이 증가하고 있다. 이제 도 10의 참조에서, 예시의 일 실시예인, 본 발명의 예시적인 일 실시예에 따른 동작들을 수행할 수 있는 대표적인 사용자 컴퓨팅 설비 (1000)가 도시된다. 본 발명이 속한 기술 분야의 통상의 지식을 가진 자는 예시의 사용자 컴퓨팅 설비 (1000)가 그런 사용자 장치들과 연관될 수 있는 일반적인 기능들을 단지 대표하는 것이며, 또한 고정된 컴퓨팅 시스템들은 그런 동작들을 수행하기 위한 컴퓨팅 회로를 유사하게 구비한다는 것을 인식할 것이다. 상기 사용자 컴퓨팅 설비 (1000)는 예를 들면 컴퓨팅 설비, 모바일 전화기, 모바일 통신 기기, 모바일 컴퓨터, 랩탑 컴퓨터, 데스크 탑 컴퓨터, 전화 기기, 비디오 전화기, 컨퍼런스 전화기, 텔레비전 장치, 디지털 비디오 녹화기 (DVR), 셋탑 박스 (STB), 무선 장치. 오디오/비디오 플레이어, 게임 기기, 위치 확인 기기, 디지털 카메라/캠코더 및/또는 유사한 것 또는 상기의 것들의 임의의 결합일 수 있다. 또한 상기의 사용자 컴퓨팅 설비 (1000)는 도 2 내지 도 4에 도시된 사용자 장치들의 특징들을 구비할 수 있을 것이며, 도 6 내지 도 9에 도시된 것과 같이 사용자 인터페이스 시야들을 디스플레이하기 위해 사용될 수 있을 것이다.

프로세싱 유닛 (1002)은 상기 설비 (1000)의 기본적인 기능들을 제어한다. 연관된 그런 기능들은 프로그램 저장/메모리 (1004)에 저장된 명령어들로서 포함될 수 있을 것이다. 본 발명의 예시적인 실시예에서, 상기 저장/메모리 (1004)와 연관된 프로그램 모듈들은 비휘발성의 전자적으로 소거 가능한, 프로그램 가능한 읽기 전용 메모리 (EEPROM), 플래시 읽기 전용 메모리 (ROM), 하드 드라이브 등에 저장되어, 모바일 단말의 전력 다운 시에 정보가 분실되지 않도록 한다. 본 발명에 따라서 모바일 단말 동작들을 수행하기 위한 관련 소프트웨어는 컴퓨터 프로그램 제품, 컴퓨터로 읽을 수 있는 매체를 통해서 또한 제공될 수 있을 것이며 그리고/또는 (예를 들면, 인터넷과 중개 무선 네트워크들과 같은 하나 또는 그 이상의 네트워크들을 통해서 전자적으로 다운로드 되는) 데이터 신호를 통해서 상기 모바일 컴퓨팅 설비 (1000)로 전송될 수 있을 것이다.

상기 모바일 컴퓨팅 설비 (1000)는 네트워크 데이터 교환을 수행하기 위해 프로세싱/제어 유닛 (1002)으로 연결된 하드웨어 및 소프트웨어 컴포넌트들을 포함할 수 있을 것이다. 상기 모바일 컴퓨팅 설비 (1000)는 유선이나 무선 데이터 연결의 어떤 조합도 유지할 수 있도록 복수의 네트워크 인터페이스들을 포함할 수 있을 것이다. 도시된 상기 모바일 컴퓨팅 설비 (1000)는 네트워크 데이터 교환을 수행하기 위한 무선 데이터 전송 회로를 포함한다. 이 무선 회로는 아날로그-디지털 (A/D) 변환, 디지털-아날로그 (D/A) 변환, 음성 코딩/디코딩, 암호/해독, 오류 검출 및 정정, 비트 스트림 전송, 필터링 등을 포함하는 다양한 기능들을 수행하기 위해 채택된 디지털 신호 프로세서 (digital signal processor (DSP); 1006)를 포함한다. 보통 안테나 (1010)에 연결되는 트랜시버 (1008)는 나가는 무선 신호들 (1012)을 전송하고, 무선 기기와 연관된 들어오는 무선 신호들 (1014)을 수신한다. 이런 컴포넌트들은 상기 설비 (1000)가, 모바일 서비스 공급자 네트워크들, 로컬 네트워크들 및 인터넷과 PSTN과 같은 공중 네트워크들을 포함하는, 하나 또는 그 이상의 통신 네트워크들 (1015)과 연결되는 것을 가능하게 한다.

상기 모바일 컴퓨팅 설비 (1000)는 프로세싱/제어 유닛 (1002)과 연결된 대체의 네트워크/데이터 인터페이스 (1016)을 또한 포함할 수 있을 것이다. 상기 대체의 네트워크/데이터 인터페이스 (1016)는 유선 및 무선 매체들을 구비하는 어떤 방식의 데이터 전송 매체라도 이용하는 이차적인 데이터 경로들을 경유하여 통신하는 능력을 제공할 수 있을 것이다. 대체의 네트워크/데이터 인터페이스 (1016)의 예들은 USB, 블루투스 (Bluetooth), 이더넷 (Ethernet), 1002.11 Wi-Fi, IRDA, 초광대역 (Ultra Wide Band), WiBree 등을 포함한다. 또한 이런 대체적인 인터페이스들 (1016)은 네트워크들 (1015)을 경유해서 통신하거나 또는 직접 및/또는 피어-투-피어 통신 링크들을 경유해서 통신할 수 있다.

상기 프로세서 (1002)는 상기 모바일 단말과 연관된 사용자 인터페이스 하드웨어 (1018)와 또한 연결된다. 상기 모바일 단말의 사용자 인터페이스 (1018)는, 예를 들면, 액정 디스플레이와 같은 디스플레이 (1020)와 트랜듀서 (1022)를 포함할 수 있을 것이다. 상기 트랜듀서 (1020)는 사용자 입력들을 수신할수 있는 어떤 입력 기기도 포함할 수 있을 것이다. 상기 트랜듀서 (1022)는 텍스트, 정지 화면, 비디오, 사운드 등의 임의의 결합과 같은 미디어를 생성할 수 있는 센싱 기기들을 또한 포함할 수 있을 것이다. 다른 사용자 인터페이스 하드웨어/소프트웨어는 키패드들, 스피커, 마이크로폰, 음성 명령들, 스위치, 터치 패드/스크린, 포인팅 기기들, 트랙볼, 조이스틱, 진동 생성기, 라이터 등과 같은 인터페이스 (1018) 내에 포함될 수 있을 것이다. 이런 그리고 다른 사용자 인터페이스 컴포넌트들은 당 업계에서 알려진 것과 같이 상기 마이크로프로세서 (1002)로 연결되다.

상기 프로그램 저장/메모리 (1004)는 상기 모바일 컴퓨팅 설비 (1000) 상에서의 기능들과 연관된 기능들 및 애플리케이션들을 수행하기 위한 운영 시스템들을 포함한다. 상기 프로그램 저장 (1004)은 ROM (read-only memory), 플래시 ROM, 프로그램가능 그리고/또는 삭제 가능한 ROM, RAM (random access memory), 가입자 인터페이스 모듈 (subscriber interface module (SIM)), 무선 인터페이스 모듈 (wireless interface module (WIM)), 스마트 카드, 하드 드라이브, 컴퓨터 프로그램 제품, 또는 다른 탈부착 가능한 메모리 기기 중의 하나 또는 그 이상을 포함할 수 있을 것이다. 상기 모바일 컴퓨팅 설비 (1000)의 저장/메모리 (1004)는 본 발명의 예시의 실시예들에 따른 기능들을 수행하기 위한 소프트웨어 모듈들을 또한 포함할 수 있을 것이다.

예를 들면, 상기 프로그램 저장/메모리 (1004)는 하나 또는 그 이상의 네트워크 인터페이스들 (1028)을 경유하여 프로세스 관련된 문서들을 송신하고 그리고/또는 수신하도록 구성된 문서 인터페이스 (1024)를 포함한다. 상기 네트워크 인터페이스 (1026)는, HTTP, FTP (File Transfer Protocol), SMTP (Simple Mail Transfer Protocol), SMS, MMS 등과 같은 하나 또는 그 이상의 공통의 네트워크 데이터 전송 프로토콜들 다루기 위한 소프트웨어 모듈들을 포함할 수 있을 것이다. 문서 파서 (1028)는 문서가 문서 사용자 인터페이스 (1030) 상에서 렌더링되는 것을 가능하게 하는 들어오고 나가는 문서들 상에서의 데이터 구조들에 관한 동작 (예를 들면, 파싱 (parsing), 인코딩, 디코딩, 인증, 확인)을 수행할 수 있을 것이다. 상기 문서 사용자 인터페이스 (1030)는 문서들을 수정하기 위한 사용자 입력들을 또한 받아들 수 있을 것이며, 상기 파서 (1028)는 이런 입력들을 기반으로 하여 문서들의 데이터 구조를 업데이트할 수 있을 것이다.

상기에서 설명된 것과 같이, 상기 문서들은 상기 문서가 사용되는 비즈니스 프로세스들의 상태들을 추척하기 위해 사용되는 내장된 메타데이터를 보통은 포함한다. 이 메타데이터는 문서 인터페이스 (1024)에 의해 상기 장치 (1000)로 직접 전달될 수 있을 것이며, 메타데이터 프로세서 (1032)는 그 메타데이터를 상기 문서 파서 (1028)와는 독립적으로 처리할 수 있을 것이다. 메타데이터에 대한 한가지 사용은 문서들, 태스크들 및 스레드들의 상태를 추적하고 업데이트하는 것이며, 이는 사용자 인터페이스 (1034)를 추적하는 스레드에 의해 상기 장치 상에서 직접 보여질 수 있을 것이다. 이 스레드 추적 사용자 인터페이스 (1034)는 프로세스/태스크플로우 상태를 상기 문서 사용자 인터페이스 (1030)와는 무관하게, 도 6 내지 도 9의 예시적인 시야들에서와 같이, 보여줄 수 있을 것이다.

문서들/태스크들/스레드 상태를 판별하는 것은 특정 시나리오를 위해서 정의된 특정한 역할들 (1036)과 규칙들 (1038)에 의존할 수 있을 것이다. 상기 역할들 (1036)은, 문서 사용자 인터페이스 (1030)를 경유하여 취해질 수 있는 행동들을 아마도 제한하는 것에는 물론이며, 상기 스레드 추적 사용자 인터페이스 (1034)가 어떻게 특정한 사용자의 상태들을 디스플레이 하는가에도 영향을 미칠 수 있을 것이다. 상기 규칙들 (1038)은 한 프로세스의 상이한 역할들 사이에서 발생하는 문서 흐름들을 정의할 수 있을 것이며, 들어오는 문서에 응답하여 취해지는 로컬 단계들을 또한 정의할 수 있을 것이다. 예를 들면, 들어오는 문서를 프로세싱하는 것은 추가적인 문서들을 템플리트 데이터베이스 (1040)를 경유하여 그리고/또는 상기 문서들 그 자체에 내장된 데이터/템플리트들을 경유하여 생성할 것을 필요로 할 것이다. 상기 규칙들 (1038)은 비스니스 프로세스 네트워크의 어떤 다른 개체들 (1044) (예를 들면, 클라이언트들, 서버들)이 그런 문서들을 수신하기 위한 타겟이 되어야만 하는가를 또한 정의할 수 있을 것이다.

상기에서 더 상세하게 설명된 것과 같이, 상기 장치 (1000)에 의해 처리되는 문서들은 문서 전송에 의해서 다른 개체들 (1044)로 전달되는 프로세스 상태를 표시하는 자체적으로 구비한 표시기를 포함할 수 있을 것이다. 다른 설비들에서, 메타데이터 인터페이스 (1042)는 (보통 프로세스 상태를 나타내는) 상기 메타데이터를 다른 개체들 (1044)로 전달하기 위해 대역내 또는 대역외 메커니즘을 사용할 수 있을 것이다. 상기 프로세서 (1032)는 상기 인터페이스 (1042)에게 국부적으로 처리된 문서들 그리고 상기 규칙들 및 규칙 데이터베이스 (1036, 1038)를 통해서 결정된 타겟 주소들/프로토콜들의 임의의 결합을 기반으로 하여 이 데이터를 전달하도록 지시할 수 있을 것이다.

도 10의 상기 모바일 컴퓨팅 설비 (1000)는 본 발명의 원칙들이 적용될 수 있는 컴퓨팅 환경의 대표적인 예로서 제공된다. 여기에서 제공된 설명으로부터, 본 발명의 당업자는 본 발명이 다양한 현재 알려진 다른 그리고 미래의 모바일 및 지상선 컴퓨팅 환경들에서 마찬가지로 적용 가능하다는 것을 이해할 것이다. 예를 들면, 데스크 탑 및 서버 컴퓨팅 기기들은 유사하게 프로세서, 메모리, 사용자 인터페이스 및 데이터 통신 회로를 포함한다. 그러므로, 본 발명은 데이터가 네트워크를 경유하여 전달될 수 있는 어떤 알려진 컴퓨팅 구조에서도 적용 가능하다.

이제 도 11을 참조하면, 도 11의 블록도가 본 발명의 예시적인 실시예들에 따른 통합된 태스크 및 문서 관리 서비스들을 제공하는 네트워크 서비스 (1100)의 상세한 내용을 제공한다. 상기 서비스 (1100)는 하나 또는 그 이상의 전통적인 컴퓨팅 설비들 (1101)을 통해서 구현될 수 있을 것이다. 상기 컴퓨팅 설비 (1101)는 맞춤 또는 범용 전자 컴포넌트들을 포함할 수 있을 것이다. 상기 컴퓨팅 설비 (1101)는 RAM (1104) 및/또는 ROM (1106)에 연결될 수 있는 하나 또는 그 이상의 중앙 프로세서들 (CPU) (1102)를 포함한다. 상기 ROM (1106)은 프로그램 가능한 ROM (PROM), 삭제 가능한 ROM (EPROM) 등과 같은 다양한 유형의 저장 매체를 포함할 수 있을 것이다. 상기 프로세서 (1102)는 입력/출력 (I/O) 회로 (1108)를 통해서 다른 내부 및 외부의 컴포넌트들과 통신할 수 있을 것이다. 상기 프로세서 (1102)는 하나 또는 그 이상의 프로세싱 코어들을 포함할 수 있을 것이며, 독립적인 기능 모듈들 (예를 들면, 칩셋들)에 있는 범용 및 특수 목적의 프로세서들이 결합된 것을 포함할 수 있을 것이다. 상기 프로세서 (1102)는 고정된 로직, 소프트웨어 명령어 및/또는 펌웨어 명령어들에 의해 지시된 것과 같이, 당 업계에서 알려진 다양한 기능들을 수행한다.

상기 컴퓨팅 설비 (1101)는 탈부착 가능한 디스크 드라이브 (1112), 하드 드라이브 (1113), 광학 드라이브 (1114) 및 정보를 읽고 그리고/또는 저장할 수 있는 다른 하드웨어를 포함하는 하나 또는 그 이상의 데이터 저장 기기들을 포함할 수 있을 것이다. 일 실시예에서, 본 발명에 따른 동작들을 수행하기 위한 소프트웨어가 광학 미디어 (1115), 자기 미디어 (1118), 플래시 메모리 (1120) 또는 휴대하면서 정보를 저장할 수 있는 다른 형상의 미디어 상에 저장되어 배포될 수 있을 것이다. 이런 저장 미디어는 광학 드라이브 (1114), 탈부착 가능한 디스크 드라이브 (1112), I/O 포트들 (1108) 등과 같은 기기들로 삽입되고 그 기기들에 의해 읽혀질 수 있을 것이다. 또한 상기 소프트웨어는 인터넷과 같은 네트워크들을 경유하여 전자적으로 다운로드 되고 있는 것과 같이 데이터 신호들을 통해서 컴퓨터 설비 (1101)로 전송될 수 있을 것이다. 상기 컴퓨팅 설비 (1101)는 사용자의 상호작용을 위해서 사용자 입력/출력 인터페이스 (1122)에 연결될 수 있을 것이다. 상기 사용자 입력/출력 인터페이스 (1122)는 마우스, 키보드, 마이크로폰, 터치 패드, 터치 스크린, 음성 인식 시스템, 모니터, LED 디스플레이, LCD 디스플레이 등과 같은 장치를 포함할 수 있을 것이다.

상기 서비스 (1100)는 메모리 (1104)와 영속적인 저장소 (예를 들면, 하드 드라이브 (1113))의 임의의 조합에 저장될 수 있을 것이다. 그런 소프트웨어는 고정된 로직 또는 읽기 전용 메모리 (1106)에 포함될 수 있을 것이며, 읽기 전용 메모리 자기 디스크, 광학 미디어, 플래시 메모리 기기, 고정된 로직, 읽기 전용 메모리 등을 포함하는, 휴대용의 컴퓨터로 읽을 수 있는 저장 매체 및 컴퓨터 프로그램 제품들을 통해서 읽기-쓰기 메모리 (1104)에 위치될 수 있을 것이다. 또한 상기 소프트웨어는 입력-출력 버스들 (1108)에 연결된 데이터 전송 링크들에 의해 메모리 (1106) 내에 위치할 수 있을 것이다. 그런 데이터 전송 링크들은 유선/무선 네트워크 인터페이스, 범용 시리얼 버스 (Universal Serial Bus, USB) 인터페이스 등을 포함할 수 있을 것이다.

소프트웨어는 일반적으로 프로세서 (1102)로 하여금 다른 컴퓨터 하드웨어와 같이 동작하여 여기에서 설명된 서비스 기능들을 제공하도록 하는 명령어들 (1128)을 보통은 포함한다. 그 명령어들 (1128)은 비즈니스 프로세스 네트워크 (1134)의 개체들 (1132)과 통신하는 것을 촉진시키는 네트워크 인터페이스 (1130)를 포함한다. 상기 네트워크 인터페이스 (1130)는, 미디어 액세스 회로, 드라이버들, 프로그램들 및 프로토콜 모듈들을 포함하는, 하드웨어와 소프트웨어 컴포넌트들의 결합을 포함할 수 있을 것이다. 또한 상기 네트워크 인터페이스 (1130)는 HTTP, FTP, SMTP, SMS, MMS 등과 같은 하나 또는 그 이상의 네트워크 공통의 네트워크 데이터 전송 프로토콜들을 처리하기 위한 소프트웨어 모듈들을 포함할 수 있을 것이다.

상기 네트워크 인터페이스 (1130)는 메타데이터와 문서 인터페이스들 (1136, 1138)의 특정 기능들을 지원하는 일반적인 모듈이다. 상기 문서 인터페이스 (1138)는 프로세스 관련된 문서들을 네트워크 개체들 (1132)과 교환하도록 구성된다. 일 실시예에서, 상기 서비스 (1100)는 저장소 (1140)을 경유한 중앙 문서 저장을 촉진시킬 수 있을 것이다. 유사하게, 템플리트 저장소 (1150)는 특정 프로세싱 태스크들을 위한 문서들을 생성하기 위해 개체들 (1132)에 의해 사용되는 템플리트들로의 중앙 집중화된 액세스를 제공할 수 있을 것이다. 상기 서비스 (1110)는 문서들의 저장, 생성 및 라우팅을 관리하는 문서 프로세서 (1142)를 포함할 수 있을 것이다. 상기에서 설명된 것처럼, 상기 문서들은 상기 문서들이 사용되는 비즈니스 프로세스들의 상태들을 추적하기 위해 사용되는 내장된 메타데이터를 보통은 포함한다. 이 메타데이터는 문서 인터페이스 (1142)에 의해 서비스와 교환될 수 있을 것이며, 워크플로우 엔진 (1144)은 문서 프로세서 (1142)에 독립적으로 상기 메타데이터를 처리할 수 있을 것이다. 상기 메타데이터를 한번 사용하면 문서들, 태스크들 및 스레드들의 상태를 추적하고 갱신하게 되며, 이는 문서들 스스로에 의해 그리고/또는 메타데이터 인터페이스 (1136)에 의해 클라이언트들 (예를 들면, 도 10의 장치 (1000))로 전달될 수 있을 것이다. 직접 사용자 인터페이스 하드웨어 없이 상기 서비스 (1100)가 동작할 수 있을 것이지만, 상기 서비스 (1100)는 그와 같은 메타데이터와 문서들을 추적하는 것을 허용하는 사용자 인터페이스들 (도시되지 않음)과 같이 또한 설정될 수 있을 것이다 (예를 들면, 도 10의 UI들 (1030, 1034)과 유사함).

상기 워크플로우 엔진 (1144)은 특정 역할 (1146) 및 특정한 태스크 관리 시나리오를 위해 정의된 규칙들 (1146)을 기반으로 하여 문서들/태스크들/스레드의 상태들을 판별할 수 있을 것이다. 상기 역할 (1146)은 개체들 (1132)이 특정 문서들에 가할 수 있는 행동들을 아마도 제한하는 것은 물론이며 스레드 상태 변화들이 어떻게 전달되는가에 관해서도 영향을 미칠 수 있을 것이다. 상기 규칙들 (1146)은 한 프로세스의 상이한 역할들 사이에서 발생하는 문서 흐름들을 정의할 수 있을 것이며, 그래서 들어오는 문서들에 반응하여 상기 특정 개체들 (1132) (또는 상기 서비스 (1100) 그 자체)에 의해 취해진 단계들을 정의할 수도 있을 것이다. 예를 들면, 들어오는 문서를 처리하는 것은 추가적인 문서들을, 템플리트 데이터베이스 (1050)를 경유하여 그리고/또는 상기 문서들 자체 내에 내장된 데이터/템플리트들을 경유하여 생성할 것을 요청할 것이다. 상기 규칙들 (1148)은 비즈니스 프로세스 네트워크의 어떤 다른 개체들 (1132) (예를 들면, 클라이언트들, 서버들)이 그 문서들을 수신하기 위해 타겟이 되어야만 하는가를 추가로 정의해야 할 것이다.

상기에서 더 상세하게 설명된 것과 같이, 상기 서비스 (1100)에 의해 처리되는 상기 문서들은 문서 전송에 의해서 다른 개체들 (1132)로 전달되는 프로세스 상태를 표시하는 자체적으로 구비한 표시기를 포함할 수 있을 것이다. 다른 설비들에서, 메타데이터 인터페이스 (1136)는 (보통 프로세스 상태들을 나타내는) 상기 메타데이터를 다른 개체들 (1132)로 전달하기 위해 대역내 또는 대역외 메커니즘을 사용할 수 있을 것이다. 상기 워크플로우 엔진 (1144)은 상기 인터페이스 (1136)에게 국부적으로 처리된 문서들 그리고 상기 규칙들 및 규칙 데이터베이스 (1146, 1148)를 통해서 결정된 타겟 주소들/프로토콜들의 임의의 결합을 기반으로 하여 이 데이터를 전달하도록 지시할 수 있을 것이다.

상기 서비스 (1100)는 비즈니스 프로세스들을 지원하기 위해 다른 중앙 집중화된 기능들을 포함할 수 있을 것이다. 예를 들면, 인증 데이터베이스 (1152)는 문서의 무결성을 보장하기 위해 사용될 수 있으며, 문서들 (1140) 및 템플리트들 (1150) 상의 제한을 편집하는 것을 강제하기 위해 사용될 수 있으며, 문서 암호화를 촉진시키기 위해 사용될 수 있으며, 기타의 용도로 사용될 수 있을 것이다. 상기 워크플로우 엔진 (1144)에 의해 관리되는 태스크/문서/스레드 상태들은 레거시 (legacy) 비즈니스 프로세스 데이터베이스 (1154)를 갱신하기 위해 또한 사용될 수 있을 것이다.

예시의 목적으로, 상기 서비스 (1100)의 동작은 특정한 결과들을 제공하기 위해 상호 작용하는 기능적인 회로/소프트웨어 모듈들의 관점에서 설명되었다. 본 발명이 속한 기술 분야의 통상의 지식을 가진 당업자는 기능적인 모듈들의 다른 배치가 가능하다는 것을 이해할 것이다. 또한, 당업자는 그렇게 설명된 기능을 당 업계에서 일반적으로 알려진 지식을 이용하여 모듈 레벨로 아니면 전체적으로 쉽게 구현할 수 있다. 상기 컴퓨팅 구조 (1101)는 여기에서 설명된 문서 흐름 기반의 서비스들을 제공하기 위해 사용될 수 있는 네트워크 하부구조 하드웨어의 대표적인 예일 분이다. 일반적으로, 상기 컴퓨팅 서비스 (1100)의 기능들은 많은 프로세싱 엘리먼트들 및 네트워크 엘리먼트들에 걸쳐서 분포될 수 있으며, 그리고, 웹 서비스들, 게이트웨이들, 모바일 통신 메시징 등과 같은 다른 서비스들과 통합될 수 있다. 예를 들면, 상기 서비스 (1100)의 일부 모습들은 클라이언트-서버 상호 작용들 interactions_, 피어-투-피어 상호 작용들, 분산 컴퓨팅 등을 경유하여 사용자 기기들 (및/또는 도 2에 도시된 서버들 (204-207)과 같은 중개자)에서 구현될 수 있을 것이다.

도 12a의 참조에서, 도면의 흐름도는 본 발명의 예시적인 일 실시예에 따라서 스레드 상태들을 디스플레이하기 위한 절차 (1200)를 도시한다. 이 절차는 비즈니스 프로세스의 전자 메시징 동작에 응답하여 스레드를 식별하는 (1202) 것을 수반한다. 상기 스레드는 상기 비즈니스 프로세스의 서로 관련된 태스크들의 상태들 및 관계들을 집합적으로 (collectively) 기술하는 (describe) 데이터를 적어도 포함한다. 상기 전자 메시징 동작에 응답하여 상기 스레드의 상태가 생성되며, 그 경우 상기 스레드의 상태는 상기 비즈니스 프로세스의 상태를 표시한다. 상기 전자 메시징 동작에 응답하여, 사용자 인터페이스가 상기 스레드를 렌더링하는 것이 촉진된다 (1206). 옵션으로, 상기 스레드를 시각화하는 것은 상기 스레드의 상태의 변화를 기반으로 하여 변경될 수 있을 것이다 (1208).

이제 도 12b를 참조하면, 도면의 흐름도는 본 발명의 일 실시예에 따라서 문서 메타데이터를 설정하는 절차 (1220)를 도시한다. 상기 절차는 비즈니스 프로세스의 서로 관계가 있는 태스크들의 상태들 및 관계들을 집합적으로 기술하는 데이터를 포함하는 스레드를 식별하는 것 (1222)을 수반한다. 상기 비즈니스 프로세스에 관한 상기 스레드의 상태가 식별된다 (1224). 메타데이터는 상기 비즈니스 프로세스의 전자 문서 내에서 설정되어 (1226) 상기 메타데이터가 상기 스레드의 상태를 기술하도록 한다. 상기 메타데이터는 상기 비즈니스 프로세스의 전자 메시징 동작을 경유하여 전달된다 (1228).

이제 도 13a를 참조하면, 도면의 흐름도는 본 발명의 일 실시예에 따른 절차 (1300)를 도시한다. 상기 절차 (1300)는 스레드의 상태를 변화시키는 전자 문서로의 사용자 행동의 적용을 촉진시키는 것 (1302)을 수반한다. 상기 스레드는 비즈니스 프로세스의 서로 관련된 태스크들의 상태들 및 관계들을 집합적으로 (collectively) 기술하는 (describe) 데이터를 적어도 포함한다. 상기 전자 문서의 메타데이터는 사기 스레드의 변화된 상태를 반영하기 위해 변화된다 (1304). 그 변화된 메타데이터는 상기 스레드의 변화된 상태를 갱신하기 위해 상기 비즈니스 프로세스의 전화 메시징 동작을 경유하여 전달된다 (1306).

이제 도 13b를 참조하면, 도면의 흐름도는 본 발명의 일 실시예에 따른 절차 (1320)를 도시한다. 상기 절차 (1320)는 비즈니스 프로세스의 실행에 사용된 전자 문서에 관련된 메타데이터로부터 스레드를 판별하는 것 (1322)을 수반한다. 상기 스레드는 비즈니스 프로세스의 서로 관련된 태스크들의 상태들 및 관계들을 집합적으로 (collectively) 기술하는 (describe) 데이터를 적어도 포함한다. 상기 스레드의 사용자 역할 데이터가 판별되고 (1324) 그리고 상기 비즈니스 프로세스의 참여자에 의해서 상기 전자 문서를 처리하는 것이 촉진된다 (1326). 전자 문서를 처리하는 것은 상기 비즈니스 프로세스에서의 참여자의 사용자 역할에 관련된 사용자 역할 데이터에 의해 지배된다.

이제 도 14를 참조하면, 도면의 흐름도는 본 발명의 일 실시예에 따른 절차 (1400)를 도시한다. 상기 절차 (1400)는 스레드 [예를 들면, 비즈니스 프로세스의 수많은 링크된/관련된 거래들]에 포함된 문서를 수신하는 것 (1402)을 보통 수반한다. 상기 문서의 메타데이터로부터 스레드 식별자를 판별한다 (1404). 상기 스레드가 아직 존재하지 않다고 (예를 들면, 개체가 상기 문서를 처리하는 것에 의해 국부적으로 기록되지 않는 경우) 판별되면 (1404) 새로운 스레드가 생성된다 (1408). 상기의 생성 (1408)은 상기 스레드와 그 스레드의 상태가 추적되는 것을 가능하게 하는 메타데이터를 생성하는 것을 보통은 수반한다.

상기 문서를 처리하는 개체는 메타데이터로부터 상기 스레드 상태를 설정할 수 있으며, 스레드 상태 업데이트들에 대해 타겟이 된 엔티티들 (예를 들면, 상기 스레드 내의 다운스트림/업스트림 스레드 상태)을 판별한다 (1410). 사용자가 상기 문서를 편집한다고 판별되면 (1412), 그러면 사용자 인터페이스는 그 문서를 편집하는 것을 촉진시킨다 (1414). 일부 경우에, 상기 비즈니스 프로세스는 상기 수신 문서를 기반으로 하여 새로운 문서를 생성하는 것을 포함할 수 있을 것이다. 새로운 문서가 생성된다고 판별되면 (1416), 그러면 메타데이터 (예를 들면, 새로운 데이터 및/또는 수신 문서로부터 유도된 데이터)는 새로운 문서에 삽입되고 (1418), 편집하는 것이 촉진된다 (1420). 편집하는 것 (1420)은 선택적인 것이며; 상기 문서는 사용자의 어떤 편집들도 필요로 하지 않으면서 자동적으로 생성될 수 있을 것이라는 것에 유의한다.

루프 (1422)가 각 업데이트 타겟과 문서 사이에서 반복된다. 현재의 문서를 편집하는 것 그리고/또는 새로운 문서를 생성하는 것이 스레드 상태에서 변화를 일으키게 했는가 (1424) 그러면 변화들이 상기 문서 메타데이터에 적용되었는가 (1426)에 대한 것이 판별된다. 업데이트 타겟이 직접 문서 수용자인가의 여부가 판별되며 (1428), 그러면 그 문서는 그 타겟으로 송신 (1430)될 수 있을 것이다. 그렇지 않으면, 상기 스레드 상태와 메타데이터는 통상의 채널들을 경유하여 상기 타겟으로 송신 (1432)될 수 있다. 메타데이터의 이런 송신 (1432)은 대역외 메커니즘 (예를 들면, 상기 문서 밖에서 전달됨)에 의해 발생할 수 있을 것이다. 다른 경우에는, 상기 개체는 결국은, 비록 직접은 아니지만, 상기 문서를 수신할 수 있을 것이며, 그런 경우에 상기 상태를 전달하는 것 (1432)은, 결국은 상기 타겟에 도달할 것이라는 가정을 하고, 상기 문서를 다음의 수용자에게 송신 (1430)함으로써 달성될 수 있을 것이다. 상기 프로세스 내의 모든 참여자들이 업데이트들에 대해 통보를 받거나 또는 타겟이 될 필요는 없다는 것에 주목한다. 예를 들면, 일부 참여자들만이 자신들이 스스로 다루는 문서들을 위한 스레드 상태를 볼 필요가 있을 뿐이다.

본 발명의 예시의 실시에들에 대한 상술한 설명은 예시 및 설명의 목적들을 위해서 제공되었다. 본 발명을 총망라하거나 또는 개시된 엄밀한 형상으로 본 발명을 한정하려는 의도는 아니다. 상기의 가르침을 참조하면 많은 수정들과 변형들이 가능하다. 본 발명의 범위는 이 상세한 설명으로 한정되는 것이 아니라, 여기에 첨부된 청구항들에 의해서 결정되는 것으로 의도된 것이다.

Claims (19)

1. 실행 가능한 명령어들을 구비한 프로세서를 포함하는 장치로서,
   상기 실행 가능한 명령어들은 상기 장치로 하여금,
   프로세스의 전자 메시징 동작에 응답하여, 상기 프로세스의 서로 관련된 태스크들의 상태들 및 관계들을 집합적으로 (collectively) 기술하는 데이터를 포함하는 스레드 (thread)를 식별하도록 하고;
   상기 전자 메시징 동작에 응답하여, 상기 스레드의 상태를 생성하도록 하며 [이 경우 상기 스레드의 상태는 상기 프로세스의 상태를 표시한다] ; 그리고
   상기 전자 메시징 동작에 응답하여, 사용자 인터페이스가 상기 스레드를 렌더링하는 것을 용이하게 하도록 하며 [이 경우 상기 렌더링은 상기 스레드의 상태를 나타낸다],
   상기 전자 메시징 동작은 상기 프로세스의 태스크들을 모델링하는 워크플로우 템플리트 (workflow template)를 기반으로 하여 전송에 대한 문서 메타데이터를 생성하는 것을 구비하는, 장치.
2. 제1항에 있어서,
   상기 전자 메시징 동작은 상기 워크플로우 템플리트를 기반으로 하여, 상기 문서 메타데이타가 내장된 전자 문서를 생성하는 것을 포함하는, 장치.
3. 제2항에 있어서,
   상기 문서 메타데이터는 상기 생성된 문서들을 프로세싱하는 개인들의 역할들을 기반으로 하여 상기 프로세스들의 전자 문서들 생성을 변경하는 역할 정보를 포함하는, 장치.
4. 제2항에 있어서,
   상기 워크플로우 템플리트는 마크업 언어 문서를 포함하며,
   상기 전자 문서의 사용자 인터페이스는 상기 워크플로우 템플리트를 기반으로 하여 런타임 (runtime)에서 동적으로 생성되는, 장치.
5. 제1항에 있어서,
   사용자 인터페이스가 상기 스레드를 렌더링하는 것을 용이하게 하도록 하는 것은, 상기 프로세스의 태스크들의 목록에 각 태스크들과 연관된 상태들을 제공하는 것을 포함하는, 장치.
6. 제1항에 있어서,
   상기 실행 가능한 명령어들은 또한 상기 장치로 하여금 상기 스레드의 상태 변화를 기반으로 하여 상기 스레드의 시각화 (visualization)를 변경하도록 하는, 장치.
7. 제1항에 있어서,
   상기 실행 가능한 명령어들은 또한 상기 장치로 하여금 상기 스레드에 의해 기술되는 상기 프로세스의 태스크들의 각 상태들에 의해 정의된 순서로 상기 스레드를 렌더링하도록 하는, 장치.
8. 제1항에 있어서,
   상기 프로세스의 태스크들 중의 적어도 하나는 적어도 하나의 서브태스크를 포함하며,
   상기 스레드를 렌더링하는 것은 상기 적어도 하나의 태스크와 상기 적어도 하나의 서브태스크를 계층적인 시야에서 렌더링하는 것을 포함하는, 장치.
9. 제1항에 있어서,
   상기 메타데이터는 상기 프로세스의 태스크들의 타이밍에 관련된 하나 이상의 타임스탬프들을 포함하며,
   상기 실행 가능한 명령어들은 또한 상기 장치로 하여금 상기 하나 이상의 타임스탬프들을 기반으로 하여 상기 스레드의 상태를 렌더링하도록 하는, 장치.
10. 프로세스의 전자 메시징 동작에 응답하여, 상기 프로세스의 서로 관련된 태스크들의 상태들 및 관계들을 집합적으로 기술하는 데이터를 포함하는 스레드 (thread)를 식별하며;
    상기 전자 메시징 동작에 응답하여, 상기 스레드의 상태를 생성하며 [이 경우 상기 스레드의 상태는 상기 프로세스의 상태를 표시한다] ; 그리고
    상기 전자 메시징 동작에 응답하여, 사용자 인터페이스가 상기 스레드를 렌더링하는 것을 용이하게 하도록 하는 [이 경우 상기 렌더링은 상기 스레드의 상태를 나타낸다] 것을 포함하며,
    상기 전자 메시징 동작은 상기 프로세스의 태스크들을 모델링하는 워크플로우 템플리트 (workflow template)를 기반으로 하여 전송에 대한 문서 메타데이터를 생성하는 것을 구비하는, 방법.
11. 제10항에 있어서,
    상기 전자 메시징 동작은 상기 워크플로우 템플리트를 기반으로 하여, 상기 문서 메타데이타가 내장된 전자 문서를 생성하는 것을 포함하는, 방법.
12. 제11항에 있어서,
    상기 워크플로우 템플리트는 마크업 언어 문서를 포함하며,
    상기 전자 문서의 사용자 인터페이스는 상기 워크플로우 템플리트를 기반으로 하여 런타임 (runtime)에서 동적으로 생성되는, 방법.
13. 제10항에 있어서,
    사용자 인터페이스가 상기 스레드를 렌더링하는 것을 용이하게 하도록 하는 것은, 상기 프로세스의 태스크들의 목록에 각 태스크들과 연관된 상태들을 제공하는 것을 포함하는, 방법.
14. 제10항에 있어서, 상기 방법은,
    상기 스레드의 상태 변화를 기반으로 하여 상기 스레드의 시각화 (visualization)를 변경하도록 하는 것을 더 포함하는, 방법.
15. 명령어들을 구비하여 인코드된, 컴퓨터로 읽을 수 있는 저장 매체로서,
    상기 명령어들은, 장치에 의해 실행될 때에,
    프로세스의 전자 메시징 동작에 응답하여, 상기 프로세스의 서로 관련된 태스크들의 상태들 및 관계들을 집합적으로 기술하는 데이터를 포함하는 스레드 (thread)를 식별하며;
    상기 전자 메시징 동작에 응답하여, 상기 스레드의 상태를 생성하며 [이 경우 상기 스레드의 상태는 상기 프로세스의 상태를 표시한다] ; 그리고
    상기 전자 메시징 동작에 응답하여, 사용자 인터페이스가 상기 스레드를 렌더링하는 것을 용이하게 하도록 하는 [이 경우 상기 렌더링은 상기 스레드의 상태를 나타낸다] 것을 수행하며,
    상기 전자 메시징 동작은 상기 프로세스의 태스크들을 모델링하는 워크플로우 템플리트 (workflow template)를 기반으로 하여 전송에 대한 문서 메타데이터를 생성하는 것을 구비하는, 컴퓨터로 읽을 수 있는 저장 매체.
16. 제15항에 있어서,
    상기 전자 메시징 동작은 상기 워크플로우 템플리트를 기반으로 하여, 상기 문서 메타데이타가 내장된 전자 문서를 생성하는 것을 포함하는, 컴퓨터로 읽을 수 있는 저장 매체.
17. 제16항에 있어서,
    상기 워크플로우 템플리트는 마크업 언어 문서를 포함하며,
    상기 전자 문서의 사용자 인터페이스는 상기 워크플로우 템플리트를 기반으로 하여 런타임 (runtime)에서 동적으로 생성되는, 컴퓨터로 읽을 수 있는 저장 매체.
18. 제15항에 있어서,
    사용자 인터페이스가 상기 스레드를 렌더링하는 것을 용이하게 하도록 하는 것은, 상기 프로세스의 태스크들의 목록에 각 태스크들과 연관된 상태들을 제공하는 것을 포함하는, 컴퓨터로 읽을 수 있는 저장 매체.
19. 제15항에 있어서,
    상기 명령어는, 상기 스레드의 상태 변화를 기반으로 하여 상기 스레드의 시각화 (visualization)를 변경할 것을 또한 수행하는, 컴퓨터로 읽을 수 있는 저장 매체.
    

Images