KR100979073B1

KR100979073B1 - 자동 통지 및 응답 방법 및 장치

Info

Publication number: KR100979073B1
Application number: KR1020037014910A
Authority: KR
Inventors: 조안 제이. 오르딜; 토마스 에이. 페트스케; 필립 엘. 와들러
Original assignee: 아바야 인코포레이티드
Priority date: 2001-05-15
Filing date: 2002-05-14
Publication date: 2010-08-31
Also published as: CA2447436A1; WO2002093886A3; CN1520572A; KR20040000465A; EP1391102A2; AU2002303765A1; WO2002093886A2; JP2005515519A

Abstract

개시된 통지 및 응답 시스템은 많은 서로 다른 매체를 사용하여 애플리케이션들이 수신자들과 통신할 수 있게 한다. 통지 및 응답 시스템은 (i) 각 개개의 수신자에 의해 명시된 매체를 사용하여 하나 이상의 수신자들에게 요청들을 보내고, (ii) 응답들을 수집하여 처리하고, (iii) 최종 목적지에 의해 명시된 매체에 의해 최종 목적지에 응답들을 보낸다. 애플리케이션들은 적어도 한 지원되는 사람의 언어와 매체 포맷으로 요청들을 프레임하고, 요청은 적합한 수신자(들)의 선호도들에 따라 이들에 보내진다. 통신 흐름 표현들은 소정의 요청에 대한 수신자들을 명시하고, 각 수신자가 요청을 받게 될 방법, 시간 및 장소를 명시한다. 요청들은 동적으로 갱신되며, 통신 흐름 표현의 파라미터들은 요청이 전달될 때까지는 평가되지 않는다. 통신 흐름 규칙들은 수신자의 통신 선호도들을 명시하여, 통신 흐름을 송신자의 특성, 토픽 혹은 스케쥴링 제약에 맞게 맞춘다. 통신 흐름 표현들은 3값의 논리, 즉 통지 실패(maybe), 응답실패(거짓), 및 응답성공(참)을 사용하여 평가된다. 프리미티브는 동시 혹은 순차 연락과, 성공 테스트 결과들의 논리 조합을 정의함으로써 서브-표현의 실행을 언제 종료할 것인가를 명시한다.

통지, 응답 시스템, 수신자, 매체. 선호도

Description

자동 통지 및 응답 방법 및 장치{Method and apparatus for automatic notification and response}

(관련 출원들에 대한 상호 참조)

이 출원은 2001년 5월 15일에 출원된 미국 임시 출원번호 60/291,087의 이점을 청구한다.

본 발명은 일반적으로 하나 이상의 수신자들과 통신하기 위한 방법 및 장치에 관한 것으로, 특히 하나 이상의 서로 다른 매체 유형들을 사용하여 애플리케이션과 하나 이상의 수신자들 간에 자동 통지 및 응답을 위한 방법 및 장치에 관한 것이다.

기업 애플리케이션들은 사람들에게 연락할 필요가 있고 연락을 행할 방법 및 어떤 응답-있다면-을 수집할 것인가에 대한 요구를 갖고 있다. 예를 들면, 애플리케이션들은 어떤 관심을 갖고 있는 모든 사람들, 혹은 특정 사람 리스트 혹은 한 사람에게 연락할 필요가 있을 수도 있다. 애플리케이션들은 위기에 처한 사람들에 즉각 연락할 것을 필요로 할 수도 있고 혹은 이들은 어떤 사람에게 적합한 시간에 작업에 대해 상기시키기를 원할 수도 있다. 기업 애플리케이션들은, 연락 성공이란 것이 기업에서 정한 어떤 것인 경우, 연락을 성공하지 못하였을 때 무엇을 해야할 지에 대한 요구를 갖고 있다.

한편, 수신자들은 이들이 어떻게, 언제 연락될 것인가에 관한 그들 자신의 선호도를 갖고 있다. 예를 들면, 수신자들은 실시간 연락을 수립함에 있어 보다 융통성이 부여되도록, 사장이나 가족과 같은 특정한 사람들, 혹은 포춘 500 기업의 간부와 같이 특정한 관심을 나타내는 사람들을 원할 수도 있다. 또한, 수신자들은 주간 상태나 지출갱신과 같은 이미 알고 있는 작업들에 관한 연락을 일상적으로, 편한 시간 혹은 장소까지 미룰 수도 있다. 흔히, 수신자들의 선호들은 기업의 선호도들 혹은 특정의 애플리케이션의 구현과 맞지 않는다. 이러한 경우, 수신자들은 자신들의 선호도를 만족시키기 위해서 애플리케이션 제약들을 쉽게 처리할 방법을 모색해 내거나, 기업들의 처리가 방해되거나 심지어는 성가시다는 것을 알게 된다.

많은 통지 시스템들은 애플리케이션들이 하나 이상의 수신자들과 통신할 수 있게 제안 혹은 개발되었다. 그러나, 현존의 통지 시스템들은 통상 매체 및 기능으로 제한되어 있다. 예를 들면, 통지 시스템은 전자 메일 메시지를 셀룰라 전화 혹은 페이저로 보낼 수 있을 뿐이다. 또한, 현존의 통지 시스템들은 다른 통신 하부구조들의 적응적 사용을 지원하지 못한다. 예를 들면 WAP 포럼, "Wireless Access Protocol 1.2.1," June 2000에 기재된 WAP(Wireless Access Protocol)을 사용하는 것들과 같은 무선 서비스의 성장으로 인해서, 단지 한 장치에 연락하고 그 럼으로써 셀룰라 전화에 웹 형태로 응답들을 넣고 받는 많은 통지 및 응답 서비스들을 개발하게 되었다.

예를 들면 1999년 3월, M. Handley 등의 "SIP: Session Initiation Protocol, "RFC 2543에 기술된 바와 같은 SIP(Session Initiation Protocol)은 장치에 SIP의 URL(Uniform Resource Locator)를 등재시킴으로써 사용자들이 특정의 장치들에 연관지을 수 있는 레지스트리를 제공한다. 사용자와의 통신이 수립되게 동시에 혹은 순차적으로 소정의 사용자에 대해 레지스트리에 기록된 URL들 리스트에 연락하는 능력을 제공하는 많은 SIP 프록시들이 존재한다. 예를 들면, 2001년 11월 J. Lennox 및 H. Schulzrinne, "CPL: A language for User Control of Internet Telephony Services," Draft RFC draft-ietfiptel-cpl-05.txt에 기술된 바와 같은 CPL(Call Processing Language)는 SIP 프록시들용으로 제안된 언어이다.

CPL로서, 사용자들은 송신자의 스트링들 및 타겟 주소들 혹은 INVITE 주요 내용의 해석 등, SIP INVITE 메시지(사용자와 연락을 수립하기 위해 SIP 프로토콜에 따라 사용되는)의 특징이 부여되어 있는 특정 URL을 선택하는 방법을 미리 명시할 수 있다. CLP은 또한 사용자들이 타임아웃을 명시할 수 있게 하므로, 특정 장치들에의 순차적인 일련의 INVITE 메시지들이 수신자와의 통신 수립을 시도할 때 시도될 수 있다. 또한, SIP에 의해서 각각의 SIP 장치 혹은 엔드포인트는 이의 사용자의 선호도들을, 가중치를 부여한 매체 유형 및 사람의 언어 리스트로서 명시할 수 있다. 송신자들은 이들이 사용할 수 있는 매체 유형들 및 사람의 언어로부터, 가장 가중치가 높은 매체 유형 및 사람 언어를 제공하도록 요청받는다. SIP 및 CPL은 통신 결과를 해석하고 이 결과에 따라 다른 조치를 취하는 지원은 제공하지 못한다. 예를 들면, 일단 전화 호가 성공적으로 응답되었으면, SIP 및 CPL은 사용자가 전화를 끊었는지 아니면 실제로 요청에 응답하였는지 알아채지 못한다.

시스템을 통한 데이터 흐름 혹은 프로그램 흐름을 명시하는 충분한 기술들이 존재하지만, 통신 흐름을 명시하는데 사용할 수 있는 기술들은 통상 초보수준이다. 통신흐름은 요청자로부터 수신자들로의 경로이다. 통상, 이들 현존의 통신 흐름 기술들은 요청에 대해 수신자를 명시하는 것을, 전자 메일 메시지를 메일박스에 혹은 메시지를 페이저에 보내는 것과 같은 어떤 선정된 연락방법과 같은 것이라 본다. 통신 흐름 경로는 흔히 두 당사자들 간의 단순한 접속으로 생각되지만, 최근의 통신 능력은 다양한 통신 흐름들을 가능하게 하고 있다. 예를 들면, 소정의 통신 흐름은 (i) 수신자들 혹은 수신자가 사용하는 장치들에 동시에 혹은 순차적으로 연락할 수 있거나, (ii) 모든 수신자들 혹은 단지 일부 수신자들이 요청에 응답하는 것을 기다릴 수 있거나, (iii) 통신 오류가 발생했을 때 다른 방도를 취할 수 있다.

그러므로 이를테면 요청에 대한 수신자들, 각 수신자가 요청을 받게 될 방법, 시간 및 장소 및 응답들이 다른 통신을 지휘할 방법 등 통신 흐름의 파라미터들을 편리하고 정확하게 명시하는 일반적인 기술의 필요성이 존재한다. 또한 애플리케이션의 요구와 수신자들의 선호도를 포착해 결합하도록 통신 파라미터들을 명시하는 기술의 필요성이 존재한다.

발명의 개시

일반적으로, 이를테면 전자메일, 전화, 웹 페이지, 페이저 혹은 팩시밀리와 같은 다수의 서로 다른 매체를 사용하여 하나 이상의 애플리케이션들이 하나 이상의 수신자들과 통신할 수 있게 하는 통지 및 응답 시스템을 개시한다. 일반적으로, 통지 및 응답 시스템은 (i) 각각의 개개의 수신자에 의해 명시된 매체를 사용하여, 하나 이상의 수신자들에게 요청을 보내며, (ii) 응답들을 수집 및 처리하고, (iii) 최종 목적지에 의해 명시된 매체에 의해 최종 목적지에 응답을 보낸다.

애플리케이션들은 다수의 지원되는 사람의 언어 및 매체 포맷들 중 어느 하나로 요청들을 프레임할 수 있고, 요청은 각 수신자의 매체 및 사람 언어 선호도에 따라 적합한 수신자(들)에게 자동으로 보내진다. 따라서, 수신자들은 이들의 명시된 선호도들 및 엔드포인트 능력들에 따라 서로 다른 애플리케이션들 혹은 시스템(혹은 이들 모두)으로부터 메시지들을 수신한다. 응답들은 대응하는 애플리케이션에 편리한 포맷으로 각각의 애플리케이션에 리턴된다. 애플리케이션은 하나 이상의 지정된 수신자들에 혹은 기선정된 수신자 리스트들 혹은 역할들에 따라 메시지들을 보낼 수 있다. 수신자 선호도 및 역할 데이터베이스는 수신자 리스트들, 역할들 및 수신자 선호도들의 중앙 관리를 제어한다. 수신자 선호도 및 역할 데이터베이스는 역할, 사람들 및 장치 정보와, 관계된 통신 흐름 정보를 기록한다.

애플리케이션들은 연락할 어떤 조건하에서("Ann"이 예라고 말한 경우에만) 연락할 사람("Bob"), 및 연락 시간(평일, 오전 9시에서 오후 9시 사이)을 명시하기 위해 통신 흐름 표현을 사용한다. 수신자들은 방법, 즉 어느 장치들을 사용할 것 인가, 및 이들에 언제 연락할 것인가의 상세로서 통신 흐름 표현을 구체화하는 규칙들을 명시한다. 수신자들은 어떤 요청들을 다른 수신자들에 자동으로 위임할 수도 있다. 본 발명의 한 특징에 따라서, 요청들은 요청이 보내질 때까지 새로운 정보로 동적으로 갱신될 수 있으므로, 수신자들은 가장 현재의 업무정보를 수신한다. 또한, 통신 흐름 표현의 파라미터들(누가, 무엇을, 언제)은 요청이 전달될 때 평가되므로, 요청은 가장 최신의 수신자 선호도에 따라 전달된다.

애플리케이션은 하나 이상의 수신자들에게 특정의 통지 메시지를 보낼 것과 이 통지에 대한 응답들을 수집하여 요청자에 리턴하거나 또 다른 애플리케이션에 보낼 것을 청하는 요청을 개시된 통지 및 응답 시스템에 보낸다. 요청은 (i) 통지 메시지, (ii) 요청 파라미터들, (iii) 통신 흐름 표현, 및 (iv) 응답들로 구성된다. 통지 메시지는 많은 지원되는 사람의 언어 및 매체 포맷들 중 어느 하나로 프레임될 수 있고, 요청은 각 수신자의 사람 언어 선호도 및 매체에 따라 적합한 수신자(들)에게 자동으로 보내진다. 요청 파라미터들은 요청의 작용을 제어하거나 요청을 적합하게 포맷화하기 위해서(혹은 이들 모두를), 통지 및 응답 시스템이 사용할 수 있어야 하는 정보를 명시한다.

통신 흐름 표현들은 애플리케이션들의 요구 및 수신자들의 선호도들을 포착하여 결합한다. 요청의 통신 흐름 표현 부분은 요청에 연관된 수신자(들)("누가"), 및 이 수신자들이 요청을 받게 될 시간 및 장소를 명시한다. 수신자는 역할(예를 들면, "고객 서비스"), 사람(예를 들면, "Jerry"), 장치(예를 들면, "800-555-1234") 혹은 평가될 다른 통신 흐름 표현일 수 있다. 각각의 수신자는 활성상태인 데, 이는 수신자들의 통신 선호도들을 명시하는 통신 흐름 규칙들 및 송신자의 특성이나 요청의 토픽 혹은 이들의 스케쥴의 요구들에 맞게 통신 흐름을 맞추는 것을 제공할 수 있기 때문이다. 일반적으로, 통신 흐름 규칙들은 통신 흐름 내 수신자의 이름을 수신자의 선호도에 따라 수신자와 연락할 시간, 장소 및 방법에 관한 상세로 대치시킨다. 통신 흐름 표현은 또한 특정 수신자가 요청에 성공적으로 응답하지 못하였을 때 어떤 조치를 취할 것인가를 명시한다.

통지 및 응답 시스템은 특정 연락이 성공하였는지 여부를 판정하기 위해서 응답자에 의해 명시된 값들을 평가하기 위해 통신 흐름에 성공 테스트들을 채용할 수 있다. 응답자는 요청을 수신하고 응답을 리턴한 사람이다. 응답들이 수신되었을 때, 통지 및 응답 시스템은 각 개개의 응답의 속성 값 쌍들, 혹은 요청이 완료된 후엔 대조된 결과들을 초기 요청에 명시된 최종 목적지로 보낼 것이다.

통신 흐름 실패는 두 가지 이유로 발생할 수 있다. 먼저, 단순히, 통지 실패라 하는 것으로서는(그 역은 통지 성공이라 함) 수신자와의 연락에 실패가 있거나 수신자가 통지에 전혀 응답하지 않을 수 있다. 두 번째로, 수신자에 연락이 취해진 후에 응답 성공("참" 혹은 "예"라고 말하는) 혹은 응답 실패("거짓" 혹은 "아니오"라고 하는), 요청을 받아들이거나 거절할 수 있다.

본 발명의 또 다른 특징에 따라서, 통신 흐름 표현은 3값 논리를 사용하여 평가된다. 논리의 3개의 가능한 값들은 통지 실패(maybe), 응답 실패(거짓) 및 응답 성공(참)이다. 통지 성공은 응답 성공 혹은 응답 실패 전에 일어나는 확인된 일시적 상태이다. 많은 장치들에 있어서, 수신자로부터 응답이 수신되었을 때 통 지가 수신되었음을 아는 것만이 가능하다. 따라서, 요청에 연관된 성공 표현은 수신자로부터 수신된 응답에 포함되어 있을 수 있는 변수들로 3값 논리 표현을 명시할 수 있다. 성공 표현은 응답의 값들의 논리 조합을 테스트하고, 응답 성공이 있으면 연락은 "참"으로 평가하고, 응답 실패가 있으면 "거짓"으로 평가하며, 그렇지 않고, 응답에 더 이상의 시간이 허용되지 않으면, 통지 실패가 있고 연락은 "maybe"로 평가한다.

각 통신 흐름 표현은 수신자들을 동시에 혹은 순차로 연락할지 여부와, 성공 테스트 결과의 논리 조합을 정의함으로써 서브-표현의 실행을 언제 종료할 것인가를 명시하기 위해 하나 이상의 프리미티브들을 포함한다. 즉, 프리미티브들은 동시 혹은 순차 통신에 대한 지시를 수신자와의 통신 상태가 통신 흐름에 어떻게 영향을 미치는가의 평가와 조합한다. 이외 다른 프리미티브들은 연락이 행해질 시간 혹은 디렉토리를 탐색함으로써 발견된 객체 리스트로부터 통신 흐름을 구성할 방법을 제어한다.

개시된 통지 및 응답 시스템에 의해 채용된 프리미티브는 자연히 다음과 같이 동시/순차 쌍들로 그룹으로 묶을 수 있다. and/then, or/else, races/delegates, 및 votes/polls. 통시 및 순차 프리미티브들은 오퍼랜드들이 어떻게 평가되는가 하는 점에서 다르다. 동시 프리미티브들에서, 각 수신자에 동시에 연락이 취해진다. 현안의 요청들이 프리미티브의 참 값을 판정하는 데에 있어 더 이상 필요하지 않을 땐 이들 요청들은 취소된다. 순차 프리미티브들에서, 요청들은 이들이 나타내는 순서로 각 수신자에 행해진다. 이 수신자가 응답할 때, 요 청은-필요하다면-프리미티브의 참 값을 판정하기 위해서 다음 수신자에게 보내진다. 각 프리미티브는 수신자들과의 통신의 성공에 따라 참, 거짓 혹은 maybe로 평가된다.

본 발명의 보다 완전한 이해, 및 본 발명의 다른 특징들 및 잇점은 다음의 상세한 설명 및 도면을 참조하여 얻어질 것이다.

도 1은 본 발명의 특징들이 포함된 통지 및 응답 시스템을 도시한 것이다.

도 2는 도 1의 통지 및 응답 시스템을 보다 상세히 도시한 것이다.

도 3은 도 2의 요청 관리자에 의해 채용된 요청 데이터베이스로부터의 샘플 표이다.

도 4는 본 발명의 특징을 포함한 3값 논리 평가자를 예시한 흐름도이다.

도 5는 도 2의 수신자 선호도 및 역할 데이터베이스로부터의 샘플 표이다.

도 6은 다수의 수신자들의 개인 명명 콘텍스트를 나타낸 것으로, 도 5의 수신자 선호도 및 역할 데이터베이스로부터의 LDAP 디렉토리 트리의 부분을 도시한 것이다.

도 7은 도 5의 수신자 선호도 및 역할 데이터베이스의 또 다른 부분으로부터 샘플 표이다.

도 8은 본 발명에 따라 한 세트의 통신 흐름 표현 프리미티브들을 나타낸 샘플 표이다.

도 9a 내지 도 9e는 도 8에 나타낸 여러 가지 프리미티브들에 대한 진리표들을 도시한 것이다.

도 10은 도 8에 나타낸 각각의 프리미티브들에 대한 카운트 값들을 요약한 샘플 표이다.

도 11은 도 2에 도시한 요청 관리자와 통신 흐름 관리자 간 상호작용을 도시한 것이다.

도 12a 및 도 12b는 도 11의 요청 관리자의 동작을 보다 상세히 예시한 흐름도이다.

도 13은 도 11의 통신 흐름 관리자의 동작을 보다 상세히 예시한 흐름도이다.

도 14는 팀 회합 요청의 파라미터를 애플리케이션이 명시하게 하는 웹 형태를 도시한 것이다.

도 15는 도 14의 요청의 컴파일된 결과를 도시한 것이다.

도 16은 요청자가 4시간 동안에 선호하는 고객들에 새로운 회사의 IPO에서 일부의 주식 할당을 제공하는 것을 도시한 것이다.

도 17은 도 16의 요청에 따라 어떤 수신자들에게 보내지는 전자메일 메시지를 도시한 것이다.

본 발명을 수행하는 최상의 방식들

본 발명은 이하 일괄하여 애플리케이션들(110)이라 칭하는 하나 이상의 애플리케이션들(110-1 내지 110-N)이, 이하 일괄하여 수신자들(120)이라 칭하는 하나 이상의 수신자들(120-1 내지 120-N)과의 통신을 이를테면 전자 메일, 전화, 웹 페이지, 페이저 혹은 팩시밀리와 같은 다수의 서로 상이한 매체로 행할 수 있게 하는, 도 1에 도시한, 통지 및 응답 시스템(100)을 제공한다. 일반적으로, 통지 및 응답 시스템(100)은 (i) 각각의 개개의 수신자(120)가 명시한 매체를 사용해서 하나 이상의 수신자들(120)에 요청들을 보내고, (ii) 응답들을 수집하여 처리하고, (iii) 최종의 목적지에 의해 명시된 매체에 의해 응답들을 이들의 최종의 목적지로 보낸다.

도 2는 통지 및 응답 시스템(100)을 보다 상세히 도시한 것이다. 도 2에 도시하고 후술하는 바와 같이, 애플리케이션(110)은, 요청을 제출하거나 취소시키는 서비스, 요청 상태를 체크하는 서비스, 및 결과들을 애플리케이션들(110)로 리턴하는 서비스를 제공하는 애플리케이션 인터페이스(220)에 의해 요청을 요청 관리자(1200)에 제출한다. 애플리케이션들은 예를 들면 HTTP POST를 통해서, 통지 요청들을 제출할 수 있고 미결 통지들을 취소시킬 것을 적합한 애플리케이션 인터페이스(220)에 요청한다.

애플리케이션 인터페이스들(220)은 예를 들면, SOAP(Simple Object Access Protocol) 혹은, IBM 사로부터 구매가능한 MQSeries^TM 인터페이스나 선 마이크로시스템즈 사로부터 구매가능한 J2EE^TM 인터페이스와 같은 많은 상용 EAI(Enterprise Application Integration) 인터페이스들로서 구현될 수 있다. 각 요청에 대해서, 애플리케이션 인터페이스들(220)은 외부에서의 요청 표현과 통지 및 응답 시스템(100) 내에서의 표현을 매핑시킨다. 마찬가지로, 각 응답에 대해서, 애플리케이션 인터페이스들(220)은 통지 및 응답 시스템(100)의 내부에서의 응답 표현과 외부에서의 표현을 매핑시킨다.

도 11에 관련하여 후술하는 요청 관리자(1200)는 제출된 모든 요청들을 추적한다. 도 3에 관련하여 후술하는 바와 같이, 요청 관리자(1200)는 각 요청에 관한 정보를 포함하고 또한 미결, 취소, 혹은 완료 등 각 요청의 상태를 나타내는 요청 데이터베이스를 유지한다. 요청 데이터베이스(300)는 메모리에, 혹은 요청들 및 이들의 현 상태(응답들을 포함하여)가 저장될 수 있는 영속 데이터베이스에 유지될 수 있다. 이외 기능들 중에서, 요청 관리자(1200)는 수신자(120)가 수신할 요청과 응답할 요청을 식별하는데 사용될 수 있는 각 요청에 고유 식별자를 할당한다. 또한, 요청 관리자(1200)는, 필요하다면, 응답들이 다시 통지 및 응답 시스템(100)에 확실히 보내질 수 있게 요청들을 수정한다.

전술한 바와 같이, 애플리케이션들(110)은 소정의 요청의 파라미터들을 명시하기 위해서 통신 흐름 표현들을 사용한다. 요청 관리자(1200)는 수신자와의 각각의 매체에 특정한 통신을 수행할 때 통신 흐름 방향들을 따른다. 요청 관리자(1200)는 도 13에 관련하여 후술하는, 통신 흐름 관리자(1300)의 통신 흐름 표현 서비스들을 사용한다. 요청 관리자(1200)와 통신 흐름 관리자(1300) 간 상호작용을 도 11을 참조하여 기술한다.

일반적으로, 통신 흐름 관리자(1300)는 요청에 정의된 타겟 통신 흐름을, 보다 효율적인 트리 구조의 내(internal) 표현으로 번역한다. 또한, 통신 흐름 관리자(1300)는 트리 표현을 반복해서 거쳐나가, 처리에서 비-장치 수신자들을 확장하고 장치들을 구체화한다. 각 반복에서, 통신 흐름 관리자(1300)는 얻을 수 있게 된 어떤 성공 테스트 결과들을 입력하고 어떤 미결 연락들을 취소시킬 것인지 아니면 어떤 새로운 연락들을 취할 것인지를 판정한다. 이와 같이, 통신 흐름 관리자(1300)는 요청을 적합한 수신자들(120)에 어떻게 보낼 것인가를 결정하고 각 통신 시도의 성공 혹은 실패에 어떻게 응답할 것인가를 결정하기 위해서 통신 흐름 표현을 해석하여 실행한다.

디렉토리 인터페이스(250)는 통지 및 응답 시스템(100)에 의해 사용되는 역할, 사람들 및 장치들의 내 표현과 수신자 선호도 및 역할 데이터베이스(500)에서의 표현을 매핑한다. 또한, 디렉토리 인터페이스(250)는 탐색 및 이외 다른 요청들을 처리한다. 일반적으로, 통신 흐름 관리자(1300)에게는 역할들을 연락하는 통신 흐름과, 통지 및 응답 시스템(100)이 연락방법을 아는 장치들에 해명할 필요가 있는 수신자의 이름들이 제공된다. 디렉토리 스키마와 통지 및 응답 시스템(100)에서의 내 표현은 다른 유형들의 데이터베이스의 사용을 지원하고 사용 중의 특정한 디렉토리 스키마와는 관계없이 내 표현을 작성하기 위해서 단일 부류 내에서 매핑될 수 있다. 이러한 부류는 한 세트의 특정한 탐색 및 검색 방법들을 제공한다.

매체에 특정한 연락들(270)은 통보와, 경우에 따라서는 수집된 응답을 실제로 전달하는 것을 취급한다. 명시 가능한 시도 기간 혹은 횟수 후에도 특정 매체를 통해 연락이 될 수 없다면, 통보 실패 메시지가 요청 관리자(1200)에게로 리턴된다. 매체에 특정한 인터페이스들(270)에 대해서는 다음에 "매체에 특정한 인터페이스들" 제하의 단락에서 상술한다. 각각의 통보 메시지에 대해, 매체에 특정한 인터페이스들(270)은 통보 및 응답 시스템(100)의 내 요청 문서 표현과 외 표현을 매핑한다. 마찬가지로, 각 응답에 대해서, 매체에 특정한 인터페이스들(270)은 외 응답 표현과 통보 및 응답 시스템(100)의 내 표현을 매핑시킨다.

웹 포탈(280)은 다양한 매체들을 통해 수신자들(120)에 데이터를 서비스하고 응답들을 수집한다. 웹 포탈(280)은 수신자의 미결 통보, 완료된 통보 및 취소된 통보에 액세스를 제공하는 일단의 서블릿들이다. 이것은 통보를 표시하는 서블릿 및 응답을 수집하는 또 다른 서블릿뿐만 아니라, 수신자가 읽거나 들을 것을 선택할 수 있게 미결 통보 목록을 표시하는 서블릿을 포함한다. 웹 포탈(280)은 모든 통보들이 직접 통보 및 응답 시스템(100)에 의해 보내지게 하고 또한 모든 응답들이 통보 및 응답 시스템(100)에 의해 수집되도록 이러한 식으로 구성된다. 중앙집중으로 구현함으로써 통보 내용이 제어될 수 있고, 통보를 개인화할 수 있으며 통보에 이전 응답을 포함시킬 수 있게 된다. 수신자 선호도 및 역할 데이터베이스(500)로부터의 개인화 데이터는 적합한 서블릿을 가리키기 위해 폼 실행 태그들을 수정하는 동일한 재기입 메커니즘에 의해 취급된다.

통보 및 응답 시스템(100)은 통신 흐름 표현에 명시된 수신자들(120)에의 모든 요청들을 중재한다. 이것은 통보 및 응답 시스템(100)이 응답들을 기록하게 하고 이들 응답들을 통신 흐름 관리자(1300)에 전달하게 한다. 통신 흐름 관리자(1300)는 이들 응답들에 근거하여 통신 흐름에 의해 서로 상이한 경로들을 취한다. 예를 들면, 웹 애플리케이션 프로그램 인터페이스(API)에 있어서, 모든 요청들은 웹 페이지들로서 표현되고 응답들을 요하는 것들은 응답을 받아들이기 위한 폼들을 포함한다. 요청들은 주어진 URL에 응답들을 보내게 재기입되므로, 통보 및 응답 시스템(100)에 행해진 원 요청에 명시된 최종 목적지로 다른 경로를 통해 보내지기 전에 완료 상태가 기록될 수 있다. 통보 및 응답 시스템(100)의 발송 및 리턴 처리는 이를테면 통합 메시징 시스템 또는 XML-기반 API에서의 방법들과 같이, 요청들 및 응답들을 명시하는 여러 가지 방법들에 맞게 수정될 수 있다.

따라서 본 발명은 개인화된 메시지 배송(수신자들은 메시지들을 원할 때 및 원하는 방법으로 받는다)을 제공한다. 통보 및 응답 시스템(100)은 다수의 지원되는 사람의 언어들 및 이를테면 전자메일, 전화, 웹 페이지, 페이저 혹은 팩시밀리와 같은 매체 포맷들 중 어느 하나로 요청들을 배송하고 응답들을 수집할 수 있다. 또한, 통보 및 응답 시스템(100)은 요청들 및 수신자들에 대한 중앙 요청 관리, 응답 대조, 및 현존의 애플리케이션들로부터( 및 이들에의 응답들) 요청들의 명료한 발송을 제공한다.

요청들

애플리케이션(100)은 특정의 통보 메시지가 하나 이상의 수신자들에게 보내지게 하고 이 통보에 대한 응답을 수집하여 요청자에게 리턴하거나 다른 애플리케이션에 보낼 것을 청하는 요청을 통보 및 응답 시스템(100)에 보낸다. 여기서 사 용되는 요청은 (i) 통보 메시지, (ii) 요청 파라미터들, (iii) 통신 흐름, 및 (iv) 응답들로 구성된다.

통보 메시지

애플리케이션(110)은 서로 다른 매체들을 통해서 그리고 서로 상이한 사람 언어들로 배송을 지원하기 위해서 한 요청에 대한 하나 이상의 버전들을 생성할 수 있다. 즉, 애플리케이션(110)은 수신자가 수신에 선호하는 문서 유형으로 서블릿에 의해 변환될 데이터 파일들을 준비한 후 서블릿의 URL을 통보 및 응답 시스템(100)에 전달한다. 예를 들면, 회합 통보를 하나 이상의 수신자들에 보내기를 원하는 애플리케이션(110)은 메시지를 포함하는 HTML 문서를, 있을 수 있는 응답-만약 있다면-을 취급하는 폼과 더불어 생성할 수 있다. 이어서 이 HTML 문서는 웹 서버에 저장될 것이며 URL은 통보 및 응답 시스템(100)에 보내진다.

특정의 매체 포맷으로 메시지를 생성하기 위한 서블릿의 사용은 본 발명의 잇점들 중 하나를 예증한다. 메시지의 매체들은 배송시 수신자의 요구 및 선호도에 맞추어 만들어질 수 있고, 메시지의 내용은 가장 최신의 정보를 항시 포함하게 배송시 생성될 수 있다. 예를 들면, 본 발명에 의해 채용되는 다수의 매체 연락들은 초기에는 수신자에게 통보 메시지를 사용할 수 있다는 표시, 이를테면 통보 메시지 혹은 통보 메시지를 포함하는 웹 페이지에의 하이퍼링크를 포함하는 전자메일 메시지를 가져오기 위해서 수신자에게 지정된 전화번호로 전화를 해야 함을 나타내는 페이지를 제공한다. 그 후에 수신자는 통보 메시지에 액세스하고, 수신자에게는 액세스시 최신판의 통보 메시지가 제공된다. 따라서, 요청자는 수신자가 실제로 통보 메시지에 액세스할 때까지 통보 메시지를 갱신할 수 있다.

요청 파라미터들

요청은 한 세트의 연관된 파라미터들을 갖는다. 이들 파라미터들은 요청의 행동을 제어하거나 요청을 적합하게 포맷하기 위해서(혹은 둘 다를 행하기 위해서) 통보 및 응답 시스템(100)이 활용할 수 있어야 하는 정보를 명시한다. 전술한 바와 같이, 요청 관리자(1200)는 제출된 모든 통보 요청들을, 각 요청에 관한 정보를 포함함과 아울러 이를테면 미결, 취소 혹은 완료와 같은 각 요청의 현 상태를 나타내는 요청 데이터베이스(300)를 사용하여, 추적한다.

도 3은 요청 데이터베이스(300) 중 샘플 테이블이다. 도 3에 도시한 바와 같이, 요청 데이터베이스(300)는 각각이 서로 상이한 요청에 연관된 복수의 레코드들(305-315)을 포함한다. 필드(330)에서 식별되는 각각의 요청에 대해서, 요청 데이터베이스(300)에 기록된 파라미터들은 (i) 필드(335)의 요청자 식별자(즉, 사람의 이름 혹은 요청을 발생시킨 애플리케이션); (ii) 필드(340)의 응답 목적지(예를 들면, 응답들을 보낼 URL 혹은 응답 발송 방법을 나타내는 통신 흐름 표현, 및 대조한 응답들을 요청 끝에서 보내야 할 것인지 아니면 각 응답을 수신시 보내야 할 것인지에 대한 표시); (iii) 필드(345)의 요지(즉, 예를 들면 이메일 개요에 사용될 수 있는 요청의 간략한 서술); (iv) 필드(350)의 최대 수명(즉, 통보 및 응답 시스템(100)이 계속적으로 통보 배송을 시도하고 응답들을 수집하는 시간 길이, 이 시간 이후의 모든 미결 요청들은 취소되고 어떠한 수집된 응답들이든 이들의 최종 목적지로 보내져야 한다); (v) 필드(355)의 언어들(즉, 통보 메시지에 사용가능한 언어); (vi) 필드(360)의 이를테면 HTML, VXML 및 평문과 같이 메시지에 취해질 수 있는 내용 유형들; 필드(365)에는 통신 흐름 표현); (vii) 수신된 응답들을 다른 지정된 수신자들이 볼 수 있거나 사용할 수 있는지 여부를 나타내는 공중/사설 플래그; 및 (viii) 필드(375)의 요청의 현 상태를 포함한다.

주제 표제를 포함하여, 각 통보 메시지의 내용은 소정의 애플리케이션(110)에 의해서 하나 이상의 지원되는 사람의 언어로 제공되거나 혹은 원하는 지원되는 사람의 언어로 자동 번역될 수 있는 것에 유의한다. 다른 변형 예에서, 필드(355)의 언어 파라미터는 언어 번역을 어떤 방식으로 언제 얻어질 것인가를 명시하는 규칙으로 대치될 수 있고, 콘텐트 유형 파라미터는 콘텐트 유형들을 어떤 방식 및 언제 발생할 것인가를 명시하는 규칙으로 대치될 수 있다.

통신 흐름

후술하는 바와 같이, "통신 흐름들" 제하의 단락에서, 통보 및 응답 시스템(100)은 통신 주체, 방법, 시기 및 장소를 명시하기 위해 통신 흐름 표현을 채용한다. 통신 흐름 표현들은 요청에 대한 수신자들을 명시한다. 수신자는 역할(예를 들면, "고객 서비스"), 사람(예를 들면, "제리"), 장치(예를 들면, "800-555- 1234"), 소프트웨어 애플리케이션 혹은 에이전트(예를 들면, 월력 에이전트) 혹은 또 다른 통신 흐름 표현일 수 있다. 또한, 통신 흐름 표현은 수신자들이 요청을 수신할 방법, 시기 및 장소를 명시한다.

통신 흐름 표현들은 또한 특정의 수신자가 요청에 대해 성공적으로 응답하지 못하였을 때 어떤 조치를 취할 것인가를 명시한다. 통신 흐름 표현들은 애플리케이션의 요구와 수신자들의 선호도들을 취하여 합친다. 통신 흐름 표현들은 활성 수신자 리스트들이다. 수신자들은 수신자의 선호도들에 따라서 이들과 연락할 시기, 장소 및 방법에 관한 보다 상세한 것들로 통신 흐름 내 수신자들의 이름을 대치시키는 통신 흐름 규칙들을 제공하므로, 각 수신자는 활성이다. 이들 통신 흐름 규칙들에 의해서, 수신자들은 이들의 개인적인 통신 흐름을 요청에 대한 통신 흐름 표현에 합칠 수 있게 된다. 수신자들은 이들의 통신 선호도를 명시하고 이들의 통신 흐름을 송신자의 특성, 요청 토픽 혹은 이들의 스케쥴의 요구에 맞게 맞추기 위해서 규칙들을 사용한다.

응답들

후술하는 바와 같이, "통신 흐름들" 제하의 단락에서, 통보 및 응답 시스템(100)은 특정한 연락이 성공하였는지 여부를 판정하기 위해서 응답자에 의해 명시된 값들을 평가하기 위해 통신 흐름에서 성공 테스트들을 채용할 수 있다. 응답자는 요청을 받고 응답을 돌려준 사람이다. 응답들이 수신되었을 때, 통보 및 응답 시스템(100)은 각 개개의 응답의 속성 값 쌍들을 보내거나, 요청이 완료된 후에, 초기 요청에 명시된 최종 목적지에 대조된 결과들을 보낼 것이다. 예시된 구현에서, 통보 및 응답 시스템(100)은 어떤 결과들을 돌려보내기 전에 전체 통신 흐 름이 실행될 때까지 기다리는데, 그러나 수신시 각 응답을 돌려보내기 위한 수정은 사소한 것이다.

통신 흐름들

통신 흐름들은 통신 흐름 표현들, 성공 명세, 통신 흐름 규칙들 및 파라미터들로 특징지워진다. 통신 흐름 표현들은 애플리케이션들의 통신 요건을 사용자들의 통신 선호도와 합친다. 통신 흐름 표현들은 요청에 대해 수신자들을 명시한다(직접 이름에 의해서 혹은 정의된 수신자 리스트 혹은 역할에 의해서). 또한, 통신 흐름 표현은 수신자들이 요청을 수신할 방법, 시기 및 장소를 명시한다. 통신 흐름 표현들은 또한 특정의 수신자가 요청에 대해 성공적으로 응답하지 못하였을 때 어떤 조치를 취할 것인가를 명시한다.

통신 흐름 성공/실패 명세들

통신 흐름 성공 명세는 통신 흐름의 각 단계에서 응답 성공 및 실패에 대한 상태들을 기술한다. 예시된 구현에서, 통신 흐름 성공 명세는 특정의 통신 흐름에 대해 전 시스템에 걸친 내정된 성공 명세와 요청자가 정한 성공 명세 내정 모두 지원한다. 대안으로, 후술하는 테스트 응답 상태 프리미티브에 의해서, 요청자는 통신 흐름에서 각 수신자에 대해 성공 명세를 명시할 수 있다.

통신 흐름 실패는 두 가지 이유로 발생할 수 있다. 먼저, 단순히 수신자와 연락 실패일 수도 있고, 혹은 수신자는 통보 실패라 칭하는(그 반대는 통보 성공이 라 함) 것으로서 통보에 대해 결코 응답하지 않을 수도 있다. 두 번째로는, 수신자는 연락될 후에 이어서 요청을 거절하거나, 응답 실패(즉, "아니오") 혹은 응답 성공(즉 "예")라 하는, 응답에 부정적으로 응답할 수도 있다. "아니오" 및 "예"는 통신 흐름을 계속할 목적으로 요청에 대해 수신자가 용인하여 응답하였는지 여부(예를 들면, "예"라고 말함)를 판정할 수 있는 애플리케이션일 뿐이기 때문에, 의미론적 성분을 갖는다. 예를 들면, 응답 성공은 수신자가 문서를 검토하고 이를 수용하는 표시를 하였을 때 일어날 수 있다. 수신자는 "예, 검토를 마쳤다"라고 말하였으면 통신 흐름은 다음 검토자와 계속한다. 한편, 응답 실패는 수신자가 소프트웨어 수정에 대한 요청을 검토하고 이를 거절하였을 때 일어날 수 있다. 수신자는 "아니오, 이 소프트웨어 수정을 하지 않을 것이다"라고 말하였으면 통신 흐름은 종료하거나 에러 처리로 계속하다.

본 발명의 일 면에 따라서, 통신 흐름 표현들은 도 4에 도시한, 3값 논리 평가자(400)를 사용하여 평가된다. 논리의 3개의 가능한 값들은 단계 420에서 통보 실패(가능할 수도 있음), 단계 450에서 응답 실패(거짓), 및 단계 440에서 응답 성공(참)이다. 도 4에 도시한 바와 같이, 통보 성공은 응답 성공 혹은 응답 실패 전에 일어나는 단계 410에서 확인되는 일시적 상태이므로 직접 나타내어지지 않는다. 대다수의 장치들에 있어서, 수신자로부터의 응답이 수신되었을 때 통보가 수신되었다는 것을 아는 것이 가능할 뿐이다.

성공 표현은 수신자(120)로부터 수신된 응답에 포함될 수 있는 변수들에 대해 3값의 논리 표현을 명시한다. 즉, 일반적으로, 통보는 HTML 폼, VXML 다이얼로 그, 혹은 등가의 객체를 포함한다. 예를 들면 폼은 이름을 응답자가 명시된 값들에 연관시킨다. 성공 표현은 응답에서의 값들의 논리 조합들을 테스트하는데, 응답성공이 있다면 연락은 "참"으로 평가하고, 응답 실패가 있다면 연락은 "거짓"으로 평가하고, 아니면, 응답에 더 이상의 시간이 허용되지 않는다면, 통보 실패가 되고 연락은 "가능할 수도 있음"으로 평가된다.

예를 들면, 클릭되었을 때 버튼의 값을 "참"으로 설정하는, "제출"이라 명명된 단일 버튼을 가진 한 폼을 포함하는 통보를 포함한 HTML 페이지를 고찰한다. 이 페이지에 대한 성공 표현은 "제출=참"이 될 것이다. 주가 변동 통지는 "매입" 혹은 "매각" 값을 취할 수 있는 "액션"이라 명명한 한 쌍의 라디오 버튼들 및 수치값을 취할 수 있는 "물량"이라 명명한 또 다른 필드를 포함할 수도 있을 것이다. 이 페이지에 대한 성공 표현은 "액션=매입 & 물량 > 1000"일 수도 있을 것이다. 성공 테스트는 예를 들면 연락 A를 의미하는, "A ? Submit="true"?,"로서 명시될 수 있고, 응답이 수신되었을 때, 응답이 "참" 값을 파라미터 "제출"에 할당한다면 연락을 "참"인 것으로 정할 수 있다. "제출: 값이 참 이외의 다른 어떤 것이면, "연락은 "거짓"이고 응답 수신에 더 이상의 시간이 허용되지 않으면, 연락은 "maybe"로 평가된다.

2값 논리에 대해 통신 흐름 표현에서 사용되는 3값 논리의 잇점에 대한 예를 예시한다. 어떤 사람이 Joann와 연락하는 것이 성공되면 Tom과 연락하고 아니면 Joan와 contact이 실패되면 Priya와 연락하기를 원하는 것으로 한다. 통상의 2값 논리 프리미티브로서 '-이면' 및 '-아니면'을 사용하면, 이 관계를 다음과 같이 나 타낼 수도 있다.

(Joann 이면 Tom) or (Joann 아니면 Priya).

또한, Joann은 셀 전화를 통해 연락되기를 선호하고, 아니면 이를 실패하면 사무실 전화를 통해서 연락되기를 선호하고, 아니면 이를 실패한 경우 요청을 Jerry에 보내는 것을 선호하는 것을 명시하기 위하여 동일 논리를 사용하는 것으로 하면, 다음과 같다.

Cell 아니면 사무소 아니면 Jerry.

요청자는 의심의 여지없이 Joann로부터 실제 응답이 온 것에 근거하여 Tom 혹은 Priya와 연락하기를 원하고 Joann는 응답하지 못한 경우에 Jerry에 연락되기를 원할 뿐이기 때문에(즉, Joann가 "아니오"로 응답한 경우), 이러한 공식화엔 본연의 문제들이 있다. 통상의 2값 논리로부터의 모든 이들 결과들을 얻는 것은 불가능하다. 다음 단락에서 다루는 바와 같이, 본 발명의 3값 논리에서, Tom은 Joann가 "예"라고 하면 연락될 뿐이고, Priya는 Joann가 "예"로 응답하지 않은 경우 연락될 뿐이고, Jerry는 Joanna가 전혀 응답하지 못한 경우에만 연락된다.

통신 흐름 수신자들

전술한 바와 같이, 통신 흐름 표현들은 요청에 대해 수신자들을 명시하는 융통성 있는, 일반적인 기술 및 수신자들로부터 수신된 응답들에 응하여 통신을 지휘하는 방법을 제공한다. 예시된 구현에서, 도 5에 도시한, 수신자 선호도 및 역할 데이터베이스(500)는 예를 들면 여기 참고로 포함시키는, M. Wahl et al.,"Lightweight Directory Access Protocol (v3)," RFC 2251 (Dec. 1997)에 기술된 LDAP(Lightweight Directory Access Protocol) 디렉토리로서 구현될 수 있다. 수신자 선호도 및 역할 데이터베이스(500)는 통신 흐름 표현에 나타날 수 있는 수신자들을 기술하는 객체들을 보유한다. 도 5에 도시한 바와 같이, 예시한 수신자 선호도 및 역할 데이터베이스(500)는 각각이 서로 다른 수신자에 연관이 되어 있는 복수의 레코드들(505-520)을 포함한다.

필드(530)에서 식별되는 각각의 수신자에 대해서, 수신자 선호도 및 역할 데이터베이스(500)는 필드(540)에서 수신자 유형과 필드(550)에서 수신자에 대해 정의된 개인적인 통신 흐름을 식별한다. 필드(540)에 나타날 수 있는 수신자들의 유형들은 사람, 역할, 애플리케이션, 장치, 지정 통신 흐름 혹은 개개의 수신자에 연락하기 위한 방법이다. 사람, 역할 혹은 지정 통신 흐름 객체가 수신자들에 연락하기 위한 통신 흐름 표현을 명시할 수 있는 반면, 개개의 수신자 혹은 애플리케이션(혹은 매체 연락 객체)에 연락하는 방법은 수신자 이름들의 번역에서 단말 객체이다(즉, 객체는 디렉토리 내 더 이상 번역되지 않는다). 객체는 각각에 대한 에이전트로서 작용할 수 있는 개개의 혹은 애플리케이션에 도달하는데 중요한 속성들, 즉 주소, 프로토콜, 타임아웃 및 연락하기 위한 재시도 간격을 포함한다.

동적 통신 흐름 표현 대치라 칭한, 본 발명의 또 다른 면에 따라서, 수신자 선호도 및 역할 데이터베이스(500) 내 정보에 수신자 이름들을 결합하는 것은 연락 시간까지 지연된다. 따라서, 본 발명의 지체 결합 특징은 시스템(100)이 CEO에 통지하는 것을 시도하기 시작할 때까지 이를테면 회사의 CEO와 같은 역할로서 기술된 수신자가 변경될 수 있음을 의미한다. 또한, 이를테면 사무실 전화번호와 같은 수신자의 개인적 통신 흐름은 여행 중엔 다른 전화로 변경될 수 있고 여행 시작 전에 제출된 요청에 의해 여전히 성공적으로 사용될 수 있다.

수신자가 매체 연락에 의해 연락되었을 때 수신자는 자신의 통신 흐름 표현을 다른 통신 흐름 표현으로 바꿀 것을 요청할 수 있다. 이에 따라 수신자는 보다 많은 적합한 수신자들에게 동적으로 작업들을 넘길 수 있게 된다. 또한 이에 따라 수신자들은 통신 흐름에, 4시간 지난 후에 요청을 처리하라는 리마인더(reminder)를 발생하는 "+04:00 후 Joann에게"라는 지연 문구(clause)를 구비한 통신 흐름으로 대치시킴으로써 작업을 지연시킬 수도 있다.

도 5는 서로 상이한 유형들의 수신자들을 예시한 수신자 선호도 및 역할 데이터베이스(500) 내 다수의 객체들을 제공한다. 수신자 선호도 및 역할 데이터베이스(500)에 채용된 프리미티브들에 대해선 이하 "프리미티브" 제하의 단락에서 기술한다. 예를 들면, 레코드(505)에 나타낸 바와 같이, 수신자 "Joann"은 모든 요청들에 대한 개인적인 통신 흐름을 다음과 같은 표현으로 명시한다.

(cell races email) delegates Jerry

따라서, Joann에 연락할 때, Joann의 셀 전화에 전화를 걸어 이메일이 동시에 Joann에게 보내질 것이다. Joann이 응답하지 않는다면, Joann에 대해 요청을 취하기 위해서 Jerry에 연락되어야 한다(Jerry에 대한 개인적인 통신 흐름에 따라서). Joann이 요청에 응답한다면, Jerry에겐 결코 연락되지 않는다.

레코드(510)에 나타낸 예에서, 역할 SysAdmin은 현재의 시프트에 대해서 요 청들을 관리자에 발송하기 위한 개인적인 통신 흐름을 명시한다.

(Sam between 0:800-16:59 or Sue between 17:00-00:59 or Greg between 01:00-07:59) delegates SysAdmin

레코드(510)에서 역할은 오전 8시에 시작하는 근무일 동안의 특정 시간 동안 일하는 시스템 관리자에게 요청들을 보낸다. 요청 처리의 제1 작업 일 동안에 어떠한 관리자와도 연락될 수 없다면, 괄호 내 문구는 실패되고 재귀적인 SysAdmin 참조를 통해 다음 날 동안에 연락 시도가 반복된다.

수신자에의 재귀적 참조, 예를 들면 SysAdmin 역할에서의 참조는 다른 종료 조건이 존재하는 통신 흐름에서의 순차적인 프리미티브에 따르는 것만이 허용되는 것에 유의한다. SysAdmin 예에서, 응답이 수신되었을 땐 참 혹은 거짓으로 혹은 요청자가 설정한 타임아웃에 이르렀을 땐 통지 실패(가능할 수도 있음)로 끝나게 된다.

이러한 사전조치로도, 디렉토리 내 순환하는 이름 참조를 통해 루프가 되는 것이 가능하다. 예를 들면, Joann의 통신 흐름 표현은 "Tom"을 말할 수 있고 Tom의 통신 흐름 표현은 "Joann"을 말할 수 있다. 이 경우에도, 동시 재귀 참조와 순차 재귀 참조가 서로 구별되므로 제어되지 않은 자원 의존적 루프가 되는 것이 회피된다. 다른 종료 조건 없이 모든 동시 순환 참조와 순차적 순환 참조는 이름 번역 이력의 분석을 통해 방지된다. Joann 및 Tom에 관한 이전의 예는 에러가 될 것이지만, 다음의 상황은 수락가능할 것이다. 왜냐하면, Joann의 통신 흐름 표현은 이메일을 통해 연락을 시도하며 실패시 Tom에게 위임하고 Tom의 통신 흐름 표현은 단순히 Joann에게 다시 일임한다(Tom은 휴가 중에 있으므로). 빠르게 혹은 장기간 동안 동일 수신자들에게로 루프하는 요청들에 대한 최종의 사전조치로서, 통신 흐름 표현은 수신자에게 명시된 최대 수의 연락 시도를 초과하였을 때 에러가 리턴될 수 있다.

도 5에 예들을 계속하면, 레코드(415) 내 지정 통신 흐름 "검토자들"은 검토를 위해 동시에 연락되어야 하는 수신자 리스트를 명시한다.

Chris, Jerry, Benji, Jenny

검토자들에게의 요청은 모든 검토자들이 성공적으로 응답하였을 때 성공한다. "통신 흐름 프리미티브들" 제하의 단락에서 후술하는 바와 같이, 이 리스트에 대한 성공 기준을 변경하기 위해서 "votes" 프리미티브가 사용될 수 있다. 예를 들면,

reviewers votes 2

는 두 검토자들이 성공적으로 응답하였을 때 성공적으로 완료된다.

수신자 선호도 및 역할 데이터베이스(500) 내 매체 연락 객체들은 에이전트들일 수도 있는 것에 유의한다. 예를 들면, 월력 에이전트는 다음 통신 흐름에 조합된 3개의 매체 연락들을 공급할 수 있을 것이다.

HoldCal ten (Cell then ScheduleCal else CancelCal)

HoldCal이 요청된 사용가능한 데이터를 발견한다면, 회합 목적을 찬성하기 위해서 셀 전화를 통해 사용자에게 연락된다. 사용자가 회합 목적에 찬성한다면, 회합 시간을 예정하고, 그렇지 않으면 회합은 취소된다.

LDAP 디렉토리 트리

도 6은 다수의 수신자들의 개인 명명 콘텍스트를 나타내는 LDAP 디렉토리 트리(600) 부분을 예시한 것이다. LDAP 디렉토리 트리(600)는 수신자 선호도 및 역할 데이터베이스(500)에 기록된 사용자 산호도 정보의 표현이다. 예를 들면, 도 6에 도시한 LDAP 디렉토리 트리(600)는 수신자 Joann에 대한 개인 명명 콘텍스트(610), 및 수신자 Tom에 대한 개인 명명 콘텍스트(620)를 포함한다. 수신자 Joann에 대한 개인 명명 콘텍스트(610)는 규칙들, 통신 흐름 표현s 및 매체 연락들을 정의하고 있다. 수신자 Tom은 내정된 규칙들, 통신 흐름 표현 및 매체 연락들을 사용한다.

통신 흐름 규칙들 및 파라미터들

통신 흐름 규칙들은 수신자 이름을 특정한 개인 통신 흐름 표현으로 언제 번역할 것인가를 명시한다. 수신자들은 특정한 요청에 대해 어느 개인 통신 흐름 표현을 사용할 것인가를 제어하기 위해서, 이를테면 타이틀 및 요청자 파라미터들과 같은 요청의 파라미터들에 관한 조건을 명시할 수 있다. 예를 들면, 수신자들은 어떤 토픽들이 타이틀로 표현되었을 때 이들 토픽을 선택할 수 있고, 혹은 셀 전화를 통해 즉각적인 처리를 위해 요청자들을 선택할 수 있다. 이들은 나중에 처리하기 위해 이메일 혹은 웹을 통해 다른 유형들의 요청들을 선택할 수 있다.

다른 선호도에 기반을 둔 시스템들과는 달리, 통신 흐름 관리자(1300) 내 선호도 처리는 요청 배송 처리에 필수적인 일반적인 메커니즘이다. 수신자(120)의 규칙들 및 개인 통신 흐름 표현들은 이 수신자(120)에 대한 개인 명명 콘텍스트(610)를 수립한다. 수신자의 규칙들 혹은 통신 흐름 표현들에서 수신자의 이름과 이름들은 수신자의 콘텍스트에 대해 번역된다. 다른 콘텍스트 기반의 명명 시스템과는 달리, 이 규칙 기반의 선호도 처리는 이름들의 글로벌 의미를 모호하게 하지 않는다. 글로벌 이름들은 볼 수 있는 상태에 있고 모두가 사용할 수 있다. 이러한 이유로, 수신자들은 이들이 특정 유형들의 요청들을 다른 어떤 사람에게 위임하기 원한다는 것을 명시하기 위해 글로벌 이름들을 쉽게 사용할 수 있다. 개인 명명 콘텍스트(610)는 의미있는 글로벌 이름들을 지원하면서도 수신자의 콘텍스트에 의미있고 적합한 번역을 수행한다.

따라서, 도 6에 도시한 바와 같이, Joann에 대한 개인 명명 콘텍스트(610)는 3개의 통신 흐름 규칙들, 즉, 관리자 규칙(630), 패밀리 규칙(640) 및 사무처리 규칙(650)에 대응하는 노드들을 포함한다. 수신자 Joann에 대한 개인 명명 콘텍스트(610)와 같은 각각의 수신자의 개인 명명 콘텍스트는 LDAP 디렉토리 트리(600) 내 그들의 InetOrgPerson {RFC2798} 혹은 InetOrgRole 객체를 루트로 하는 서브-트리로서 수립된다. InetOrgPerson 객체는 사람들에 관한 연락 정보를 기술하기 위한 LDAP 표준 객체이며, InetOrgRole 객체는 LDAP 표준 객체 부류 OrgRole {RFC2256}의 서브-부류이다. 예를 들면, 도 6에서, Joann의 개인 명명 콘텍스트(610)은 InetOrgPerson 노드 라벨의 "UID=joann"을 루트로 한다.

각각의 개인 명명 콘텍스트(610)는 통신 흐름 규칙들, 지정 통신 흐름, 및 매체 연락 객체들로서, 통신 흐름 표현 처리에 관련된 3 유형들의 객체들을 구비할 수 있다. 도 6에서, 개인 명명 콘텍스트(610)에서 맨 위의 3개의 엔트리들(630,640,650)은 명칭들이 MgrRule, FamilyRule and PaperwrkR인 3개의 통신 흐름 규칙들을 나타낸다. 노드들(660,670,680)은 각각 웹, 셀 및 이메일의 명칭들을 가진 3개의 매체 연락 객체들에 대응한다. 노드들(690, 695)은 2개의 지정 통신 흐름 표현인 UrgentCF and RelaxedCF에 상응한다.

Joann에 의해 명시된 이를테면 관리자 규칙(630), 패밀리 규칙(640), 사무처리 규칙(650)과 같은 통신 흐름 규칙들은 수신자 선호도 및 역할 데이터베이스(500)에 정의될 것이다. 관리자 규칙(630), 패밀리 규칙(640), 사무처리 규칙(650)을 정의하는 수신자 선호도 및 역할 데이터베이스(500)로부터 대응하는 객체들을 도 7에 도시하였다. 구체적으로, 수신자 선호도 및 역할 데이터베이스(500)는 관리자 규칙(630)을 정의하는 레코드(710), 패밀리 규칙(640)을 정의하는 레코드(720), 및 사무처리 규칙(650)을 정의하는 레코드(730)를 포함한다.

도 7에 도시한 바와 같은 각각의 통신 흐름 규칙은 다음의 4개의 속성으로서, 활성, 순서, 조건, 및 통신 흐름 표현을 포함한다. 활성은 "예" 혹은 "아니오"로 설정된다. 비활성, 즉 "아니오"로 설정된 규칙들은 수신자의 이름을 개인 통신 흐름으로 번역할 때 고려되지 않는다. 순서 속성은 평가를 위해서 수신자의 명명 콘텍스트(610)의 모든 활성 규칙들에 순서를 정하는데 사용된다. 순서대로 각 규칙의 조건이 차례대로 테스트된다. 조건은 이를테면, 등식, 부등식, 범위, 및 정규 표현 매칭과 같이 속성 값 비교들로 구성된 논리적 표현이다. 일단 조건이 만족되면, 수신자의 이름은 요청을 배송할 목적으로 동반된 통신 흐름 표현으로 번역된다. MgrRule에 대한 조건은 사용자명 혹은 uid에 의해 특정의 요청자들에 대해 테스트한다. FamilyRule에 대한 조건은 "Family"로 시작하는 타이틀들에 대해 테스트한다. PaperwrkR에 대한 조건은 항시 만족된다. PaperwrkR은 다른 규칙 어느 것도 만족되지 않을 때 적용되는 내정된 규칙이다. 이러한 이유로, 이의 순번은 가장 높은 수이다.

도 7에 도시한 바와 같이, 레코드들(710, 720, 730)에서의 예시한 규칙들 각각은 적어도 한 지정 통신 흐름 표현(urgentCF(690) 혹은 relaxedCF(695))을 참조한다. rgentCF 혹은 relaxedCF 통신 흐름 표현은 다음과 같이 수신자 선호도 및 역할 데이터베이스(600)에 지정 통신 흐름 표현으로서 정의될 수 있다.

UrgentCF: cell races officephone races homephone

RelaxedCF: email races web.

그러므로, 지정 통신 흐름 표현에 의해서 수신자 Joann은 규칙에 명시된 조건들에 근거하여 연락되기 위한 각종의 규칙들을 수립할 수 있다.

규칙들을 구성할 때, 공통적인 연락방법들을 위한 지정 통신 흐름 표현을 생성하는 것이 유용하다. 그러므로, 수신자는 지정 통신 흐름 표현에서 특정한 선호도를 1회 갱신할 수 있고, 변경된 지정 통신 흐름 표현을 참조하는 모든 통신 흐름 규칙들은 자동으로 갱신된다. 그러면 규칙들은 간혹 다양한 목적을 위해, 명명된 동일 통신 흐름을 사용하여, 명명된 흐름들을 참조할 수 있다. 단순히, PaperwrkR 규칙은 지정 통신 흐름(relaxedCD(695))을 사용한다. MgrRule 규칙은 수신자에 긴급으로 연락을 취할 수 있을 때에 대한 시간적 제약을 두며, 항시 느슨한 연락 통 신 흐름을 사용한다. FamilyRule 규칙은 모든 사용가능한 매체 연락들을 사용한다.

통신 흐름 규칙들에 의해서 기업 고용인들은 에스컬레이션 긴급 응답을 제공할 수 있다. 예를 들면, 기업은 고객으로부터의 요청에 즉시 응답해야 하고, 요청은 "긴급 업무"라는 키워드를 포함하는 타이틀로 고객으로부터 수신된 것으로 가정한다. 또한 기업의 적어도 한 고용인은 다음과 같은 통신 흐름 규칙을 명시한 것으로 가정한다.

Title="*Urgent Business*";

Communication flow: (cellphone races pager) before +0: 05 delegates manager

"관리자"는 적격의 관리자를 찾기 위해서 수신자 디렉토리에서 관리자 링크를 사용하는 내정된 지정 통신 흐름이다. 에스컬레이션 규칙은 "긴급 업무"라는 키워드를 포함하는 타이틀로 요청이 수신되었을 때 작용될 것이다. 고용인이 자신의 셀 전화 혹은 페이저로 5분 이내에 응답하지 않는다면, 요청은 "관리자"로 올라간다.

통상, 에스컬레이션을 달성하는 통신흐름은 다음 레벨로 올라가기 전에 요청이 취소되는 위임 프리미티브를 채용한다. 다른 변형 예에서, 통신흐름은 체인에서 먼저 사람에게의 미결 요청들을 취소시키지 않고 에스컬레이션을 달성할 수 있다. 예를 들면, 다음 예의 통신 흐름은 체인에서 먼저 사람에게의 미결 요청들을 취소시키지 않고 에스컬레이션을 달성한다.

(Tom else Manager) races (Manager after +04: 00).

이 통신흐름은 초기에는 Tom에게만 연락할 것이며, 초기 응답이 실패하면 즉각, 정해진 관리자에 연락할 것이다. 또한, 요청은 4시간 후에 관리자에게 올라가게 될 것이며 Tom 혹은 관리자로부터의 첫 번째 응답만이 받아들여질 것이다. 통지 및 응답 시스템(100)은 소정의 요청이 왜 취소되었는지에 관한 정보를 선택적으로 유지할 수 있고 취소된 요청에 연관된 수신자에게 이러한 정보를 제공할 수 있는 것에 유의한다.

이러한 통신 흐름 표현에서, 수신자가 지명한 관리자가 통신 흐름에서 동시에 2회 활성으로 될 수 있다는 사실에도 불구하고 관리자에 1회 연락하도록 최적화가 사용된다. 수신자명의 각 예는 이를 요청에 사용한 엔터티, 즉 요청자에 의해서, 혹은 개인 통신 흐름을 제공한 사람 혹은 역할에 의해 소유된다. 수신자명들이 동일 객체/수신자를 확인하고 수신자명들의 소유자들이 동일하다면, 수신자는 이들 이름들에 대해 1회 연락될 뿐이다. 소유자들이 다르다면, 수신자는 소유자의 위임과는 다른 방식들로 행동하기를 원하는 것으로 가정되므로 수신자는 누가 수신자에게 요청을 위임하였는가에 관한 것을 갖고 1회 이상 연락된다.

수신자 선호도 및 역할 데이터베이스(500) 및 LDAP 디렉토리 트리(600)에 기록되고 도 5-7을 참조로 전술한 사용자 선호도들은 존재 및 가용성 정보에 의해 수정될 수 있다. 예를 들면, 수신자는 자신의 선호도들을 다음과 같이 명시할 수 있다.

(present (cell) then cell) delegates (present (email) then email)

본 기능은 셀 매체 연락에 사용할 수 있는 수신자 및 장치 정보로 현존의 서버에 연락하다. 현존의 서버가 셀 전화가 켜져 있음을 나타내면, 본 기능은 "참"을 리턴한다. 그렇지 않다면, "가능할 수도 있음"을 리턴한다. 유사하게, 수신자가 이메일 매체 연락을 위해 네트워크 상에 있다면, 본 기능은 "참"을 리턴한다. 그렇지 않다면, "가능할 수도 있음"을 리턴한다. 수신자가 셀 전화 상에 있다면, 수신자는 셀 전화로 연락된다. 수신자가 부재중이거나 연락할 수 없다면, 네트워크가 체크되고 이에 수신자가 있다면 이메일이 보내진다. 본 기능은 현존 서버에 의해 제공되는 특징에 따라 다소 복잡할 수 있다. 통신 흐름 규칙들에 의해서 수신자들은 이들에 현존의 서버를 통해 어느 요청자들 혹은 유형들의 요청에 액세스할 수 있는가를 제한시킬 수 있는 것에 유의한다.

존재 및 가용성 정보의 또 다른 응용에서, 매체 연락은 존재 정보가 실패할(예를 들면, 셀 전화가 끊어진 경우) 통신시도(예를 들면 전화 호)를 생략함으로써 행동을 최적화할 수 있다. 단순히 매체 연락은 시도된 전화 호가 실패한 것처럼 하여 계속할 수 있다.

사용자 선호들은 기업에 의해 결정될 수도 있다. 예를 들면, 기업은 고객의 지분 이력에 근거하여, 고객에게 침해도가 증가한다는 통보를 보낼 수 있다. 예를 들면, "위임" 프리미티브에 대해 후술하는 바와 같이, 지불 이력이 안 좋은 고객들은 자동 전화 호에 의해 1차 연체통보를 받을 수 있고 미수금 처리 대행 회사를 통해 2차 통보를 받을 수 있다. 평균적인 지불 이력을 가진 고객들은 우편 서비스로 1차 연체통보를 받을 수 있고 자동 전화 호로 2차 통보를 받고 미수금 처리 대행 회사를 통해 3차통보를 받을 수 있다.

디렉토리 내정들 및 발견적 방법들

도 13을 참조로 후술하는 통신 흐름 관리자(1300)는 빠른 설치와 용이한 사용을 위해서 LDAP 디렉토리 트리(600)(도 6)에 내정 디렉토리들을 채용한다. 통신 흐름 관리자(1300)는 디렉토리를 탐색할 때 발견적 방법(heuristics)을 채용함으로써 사용의 용이함을 향상시킨다. 통신 흐름 관리자(1300)가 먼저 기업에 설치되었을 때, 통신 흐름 관리자(1300)는 현존의 기업 LDAP 디렉토리(500)에서 동작할 것이다. 기업 LDAP 디렉토리(500)의 구성에 관한 정보 외에도, 통신 흐름 관리자(1300)는 이의 애플리케이션에 특정한 객체들(즉, 통신 흐름들, 통신 흐름 규칙들, 매체 연락, 향상된 역할 및 구성 객체들)을 위한 객체 부류들의 생성을 요한다.

통신 흐름 관리자(1300)는 이의 구성과 이의 다른 객체들의 내정된 것들을 저장할 수 있는 디렉토리 서브-트리(600)의 생성을 요한다. 내정 디렉토리들은 기업 디렉토리에 이미 존재하는 사람들 및 역할들에 통신 흐름 서비스들을 제공하는데 사용된다. 이들 사람들 및 역할들은 수신자들 및 이들의 기업 재량으로 개인화된 통신 흐름들 및 규칙들에 의해 향상될 수 있다.

매체 연락 객체들의 내정 인스탄스들은 사용자 자신의 매체 연락 객체들을 명시하는 이들 사용자들도 사용할 수 있는 대치기능을 사용한다. 매체 연락 객체에서 주소 필드는 의도된 수신인의 LDAP 디렉토리 엔트리에 속성명을 명시하기 위해서 꺽쇠 괄호를 사용할 수 있다. 이 속성의 값은 - 존재하다면- 객체 검색에서 꺽쇠 괄호로 묶은 속성명을 주소 필드에 대치시킨다. 예를 들면, <mobile>은 매체 연락 객체 주소 필드를, 의도된 수신자 Joann을 기술하는 inetOrgPerson 객체의 mobile 값으로 채운다. 보다 정교한 대치 기술들이 가능하며 이들 기술들은 본 발명의 범위 내에 있다.

매체 연락 객체들의 내정 인스탄스들과 더불어, 통신 흐름 관리자(1300)는 내정된 지정 통신 흐름 표현 및 내정 통신 흐름 규칙을 생성한다. 예시한 통지 및 응답 시스템(100)에서, 내정은 모든 요청을 수신자의 이메일 계좌 및 웹 포탈, 즉 이메일 race 웹에 보내는 것이다. 모든 내정들은 기업 요구에 맞게 기업에 의해 변경될 수 있고, 내정 객체들은 사용자 자신들의 개인 통신 흐름 표현 및 통신 흐름 규칙을 구성하고 있는 이들 사용자들이 사용할 수 있다.

엔트리들의 구별적 완전한 이름들은 성가시고 비직관적일 수 있다. 이에 따라, 통신 흐름 관리자(1300)는 필요로 하는 객체들을 찾기 위해서 짧은 이름들로 발견적 방법에 의한 탐색을 사용한다. 객체의 구별적 완전한 이름은 통신 흐름 표현에서 꺽쇠 괄호에 이 차별적 이름을 넣음으로써 명시되며, 예를 들면, 다음과 같다. <uid=joann, ou=people, o=research.avaya.com>. 짧은 이름들은 이들 예에서만 사용되었다.

이름에 접하게 되었을 때, 통신 흐름 관리자(1300)는 적합할 때, 사람들, 역할들, 지정 통신 흐름들 혹은 개인 명명 콘텍스트에 관한 정보를 저장하는데 사용되는 디렉토리 서브-트리(들), 예를 들면 610, 620을 탐색한다. 통신 흐름 관리자(1300)는 짧은 이름을, 서브-트리 내 엔트리들의 상대적 구별적 이름들과 비교함으로써 탐색한다. 일치되는 것이 없으면, 통신 흐름 관리자(1300)는 에러를 리턴하기 전에 이의 내정 디렉토리를 탐색한다.

기업 혹은 다른 기업들의 다른 부분들은 외부 기관이 통신 흐름 관리자를 설치하지 않았다 하더라도 기업내 통신 흐름 관리자(1300)를 통해 연락될 수 있다. 외부 기관이 LDAP 디렉토리(500)를 갖추고 있다면, 두 가지 방식으로 통신 흐름 관리자(300)의 이름란에 함께 넣어질 수 있다. 먼저, 응답들을 위해 외 디렉토리들에 결부시키는 "스마트 리퍼럴" 혹은 다른 메커니즘을 사용해 외 디렉토리를 내 디렉토리에 합친다. 이 경우, 외 디렉토리에서 내정 혹은 개인 통신 흐름 정보가 얻어질 수 없을 때는 언제든, 내 디렉토리에 대한 통신 흐름 내정들이 외 디렉토리에 적용된다. 두 번째로, 애드-서치(ad-search) 프리미티브에 의해, 외 디렉토리에 대한 연락 정보든 기술될 수 있고 이들이 요청자에 의해 사용될 수 있다. 내정들을 필요로 하는 모든 경우에, 외 디렉토리에 내정 및 통신 흐름 관리자(1300)에 대한 구성을 저장하는 디렉토리 서브-트리의 이름이 통신 흐름 관리자(1300)에 대해 제안된 약정과 일치하지 않는다면 로컬 내정들이 사용된다. 이러한 이유로, 통신 흐름 관리자(1300)에 대해 권고된 서브-트리 이름을 LDAP 디렉토리들이 지원할 것이 권고된다. 본 통지 및 응답 시스템(100)에서, 이 이름은 다음과 같다.

<ou=Xui Server, o=domain-name-of-server>

요청자들은 때때로 디렉토리에 없는 자와 연락하기를 원하는 개인들의 주소록을 갖고 있다. 종종, 요청자들은 이를테면 전화와 같은 특정의 매체 유형에 의 해 특정의 개인들에 연락하는 것을 상당히 선호한다. 이들 경우에, 요청자들은 디렉토리 내 요청자의 개인 명명 콘텍스트 내에 이들 개개인들 용의 개인 명명 콘텍스트들을 생성할 수 있다. 또 다른 사람용의 각각의 개인 명명 콘텍스트는 이 사람에 대한 inetOrgPerson, 이어서 이 inetOrgPerson 엔트리를 루트로 하는 서브-트리에 통신 흐름 규칙들, 매체 연락들, 및 지명 통신 흐름들을 포함한다. 그러면 요청자는 자신의 요청들에 대한 통신 흐름에서 이들 수신자들 각각에 대한 구별적 완전한 이름들을 명시한다.

통신 흐름 관리자(1300)는 수신자에 대해 요청자(100)가 명시한 통신 흐름들을 사용할 것이다. 시스템의 향상은 먼저 짧은 이름들을 요청자의 트리 내에서, 이어서 디렉토리의 사람들 및 역할s 서브-트리를 통해서, 마지막으로 디렉토리의 내정 서브-트리에서 찾기 위해 내정들을 탐색하는 알고리즘을 확장할 것이다. 이들 기술들은 선호도에 대한 수신자들의 명세와는 맞지 않으므로 이들은 디렉토리에 열거되어 있지 않는 수신자들 혹은 수신자의 선호도가 무관계하거나 이에 따를 필요가 없는 애플리케이션들에 대해서만 사용될 것이다.

통신 흐름 프리미티브들

전술한 바와 같이, 통신 흐름 표현은 요청을 수신할 수신자들, 및 수신자들이 요청을 받게 될 방법, 시기 및 장소를 명시한다. 통신 흐름 표현에 포함되는 프리미티브들은 수신자들에 동시에 혹은 순차적으로 연락할지 여부, 및 성공 테스트 결과들의 논리적 조합을 정의함으로써 서브-표현의 실행을 언제 종료할 것인지를 명시한다. 도 8은 한 세트의 예를 든 통신 흐름 표현 프리미티브들을 나타내는 샘플 표이다. 도 8a 내지 도 9e는 도 8에 나타낸 각종의 프리미티브들에 대한 진리표들을 예시한 것이다. 도 9a 내지 도 9e에서, "F"는 거짓 응답을 나타내며, "T"는 참 응답을 나타내고, "X"는 maybe 응답을 나타낸다. 도 9a 내지 도 9e 각각에서 좌측열은 응답하는 제1 오퍼랜드를 나타내고 맨 위의 행은 응답하는 제2 오퍼랜드를 나타낸다("프리미티브"가 아닌 단일 오퍼랜드 외의 모든 프리미티브에 대해서). T, X 혹은 F의 "b" 아래첨자는 나타낸 값을 얻기 위해 양 오퍼랜드들이 평가되어야 함을 나타낸다. 프리미티브들은 수신자들에게의 요청들의 흐름을 지휘한다. 즉, 프리미티브들은 동시 혹은 순차 통신에 대한 지시를, 수신자와의 통신 상태가 통신 흐름에 어떻게 영향을 미치는지에 대한 평가에 결합한다. 다른 프리미티브들은 연락 시기 혹은 디렉토리 내 객체들의 리스트들로부터 통신 흐름을 구성하는 방법을 제어한다.

프리미티브들은 and/then, or/else, races/delegates, and votes/polls과 같이, 동시/순차 쌍들로 그룹으로 묶을 수 있다. 동시 및 순차 프리미티브들은 오퍼랜드들이 어떻게 평가되는가 하는 점에서 다르다. 동시 프리미티브들에서, 각각의 수신자는 동시에 연락된다. 미결 요청들은 이들이 프리미티브의 참 값을 결정하는데 더 이상 필요하지 않을 땐 취소된다. 순차 프리미티브들에서, 요청들이 나타낸 순서대로 각 수신자에게 요청들이 행해진다. 수신자가 응답할 때, 요청은, 필요하다면, 프리미티브의 참 값을 결정하기 위해서 다음 수신자에게 보내진다. 각각의 프리미티브는 수신자들과의 통신의 성공에 따라 참, 거짓 혹은 maybe로 평가된다.

And/Then

"and" 프리미티브는 두 수신자들이 동시에 연락되고 양 수신자들이 성공적으로 응답하였을 때 통신 흐름이 성공적임(참으로 평가됨)을 명시한다. 수신자들 중 한 수신자에게의 요청이 실패하면, "and" 프리미티브는 거짓으로 평가되고 다른 수신자에게의 요청은 가능하다면 취소된다. 이외 모든 다른 경우에, "and" 프리미티브는 maybe로 평가된다. "and"에 대한 진리표를 도 9a에 나타내었고, 여기서 응답하는 제1 오퍼랜드에 대한 값들은 각 행에 대해 좌측을 따라 있고 응답하는 제2 오퍼랜드에 대한 값들은 각 열에 대해 상단을 따라 있다.

"then" 프리미티브는 "and'에 이어 나타나는 형태이다. 즉, 수신자들은 이들이 나타난 순서대로 한번에 하나씩 연락되고 제2 수신자는 제1 수신자가 성공으로 응답한 경우에만 연락된다. 도 9b에 도시한 "then" 프리미티브에 대한 진리표는 제1 오퍼랜드가 maybe"를 리턴하고 제2 오퍼랜드가 거짓을 리턴할 때 "and" 프리미티브에 대한 진리표와 다르다. 제2 오퍼랜드는 "then" 프리미티브의 경우엔 평가되지 않으며 "then" 프리미티브의 참 값은 maybe로 남아 있는 반면, "and" 프리미티브의 경우, 제2 오퍼랜드가 평가되고 프리미티브는 거짓을 리턴한다. "then" 프리미티브가 보다 자연적인 의미론적 설명을 제공하기 위해서 이러한 선택이 행해졌다.

Or/Else

"or" 프리미티브는 두 수신자들이 동시에 연락되고 적어도 한 수신자가 성공으로 응답한 경우 통신 흐름이 성공임(참으로 평가됨)을 명시한다. 양 수신자들이 부정 응답한 경우, 프리미티브는 거짓으로 평가된다. 모든 다른 경우에, 프리미티브는 maybe로 평가된다. "or" 프리미티브에 대한 진리표를 도 9c에 나타내었다.

"else" 프리미티브는 "or" 프리미티브에 연이어 나타나는 형태이므로, 제2 수신자는 제1 응답이 성공적이지 않은 경우에만 연락된다. "else" 프리미티브에 대한 진리표는 도 9c에 도시한 "or" 프리미티브에 대한 것과 동일하다. "else" 프리미티브의 경우에, 제2 오퍼랜드는 제1 오퍼랜드가 maybe 혹은 거짓으로 평가된 경우에 평가될 뿐이다. "else" 연산자는 제1 수신자가 "아니오"라고 하거나 응답하지 못한 경우에만(maybe) 제2 수신자에 연락되는 시나리오를 해결하기 위해 제공된다.

Races/Delegates

"and/then", "or/else" 프리미티브들은 통신 흐름 표현의 성공 혹은 실패를 판정하기 위해 충분한 수신자들에 연락하는 것에 모두 초점이 맞추어진다. 간혹, 많은 가능한 응답들 중 첫 번째 것을 받아들이는 것이 유용하다. 기존의 프리미티브들은 성공이 달성되거나 불가능하게 되기까지 vote들을 카운트하기 때문에, 상기한 바는 기존의 프리미티브들로는 가능하지 않다. 동시 프리미티브 "race"는 반응하는 오퍼랜드들 중 첫 번째 것의 상태에 따라 성공 혹은 실패한다. 제1 응답자가 성공한다면, "race" 프리미티브는 성공이다. 제1 응답자가 실패한다면, "race" 프리미티브는 실패이다. 제2 응답자에의 요청은 가능하다면 취소된다. 예를 들면,

Cell races Office races Email races Web

은 셀 전화, 사무실 전화, 이메일 혹은 웹 포탈의 매체 연락들 중 어느 하나를 통해 수신자로부터 수신된 제1 응답에 따라 성공 혹은 실패한다.

여기서 다루어지는 다른 프리미티브들과는 달리, "races" 프리미티브는 한 오퍼랜드로부터 성공 혹은 실패 응답에 동일한 가중치를 제공한다. "and/then" 프리미티브들은 오퍼랜드의 실패에 즉각 응답하지만 성공을 리턴하기 전에 양 오퍼랜드들로부터의 결과들을 기다린다. "or/else" 프리미티브들은 오퍼랜드의 성공에 즉각 응답하나, 실패를 리턴하기 전에 양 오퍼랜드들을 기다린다. "races" 프리미티브는 오퍼랜드로부터 제1 응답에 즉각 응답하며 이 오퍼랜드의 결과를 리턴한다. 위의 예에 보인 바와 같이 복수의 장치들을 통해 개개인과 연락하고 개개인으로 하여금 이들 장치들 중 단지 하나를 통해 성공 혹은 실패로 요청에 응답하게 하는 것이 특히 유용하다. "races" 프리미티브는 다른 프리미티브들에 의해 명시될 수 없다. "RACES"에 대한 진리표를 도 9d에 나타내었다.

"delegates" 프리미티브는 "races" 프리미티브에 이어 나타내는 형태이다. "delegates" 프리미티브에 대한 진리표는 "races" 프리미티브에 대한 것과 동일하다. "delegates" 프리미티브는 좌측의 오퍼랜드가 실패 통지(maybe)를 리턴한다면 우측 오퍼랜드를 평가할 뿐이다. "races" 프리미티브처럼, "delegates" 프리미티브는 다른 프리미티브들에 의해 명시될 수 없다.

전술한 예로 돌아가서, Joann은 자신의 선호도들을 다음과 같이 명시할 수 있다.

cell delegates office delegates Jerry

while the generator of the request specifies:

(Joann then Tom) or (Joann else Priya)

Jerry는 Joann이 응답하지 못하면 응답할 뿐이다. Joann가 부재중에 Joann 혹은 Jerry가 "예"라고 말하면 Tom에 연락될 뿐이다. Joann이나 Jerry 어느 누구도 응답하지 않거나, 이들 모두가 "아니오"라고 한다면, Priya에 연락된다.

"races" 프리미티브는 복수의 동시적 장치들을 통해 한 사람에게 연락할 필요성에 의해 촉발되었다. 예를 들면, 수신자는 자신의 셀 전화와 사무실 전화 모두에게로 통지가 보내질 것을 명시할 수도 있을 것이다. 수신자 자신의 사무소 전화를 통해 이 수신자가 응답하였다면 이 응답이 성공이든 실패인지를 명시할 수 있기 위해서 셀 전화에 현안의 연락을 취해야 할 것이다. "and" 및 "or" 프리미티브들은 이러한 요건을 만족시키지 않았다. "delegate" 프리미티브는, 예를 들면, 제1 수신자가 응답하지 않거나 수신자에 연락이 될 때까지 일련의 장치들이 순차적으로 탐색될 경우에만 제2 수신자에 연락하는 시나리오를 해결한다.

전술한 바와 같이, "delegates" 프리미티브에 의해서 기업은 에스컬레이션으로 개인화된 요청 배송을 제공할 수 있게 된다. 예를 들면, 추심후 지급(bill collection)에 연루된 기업은 다음과 같이, 고객과의 관계 이력에 근거하여 각 고객에 대한 개인적 통신 흐름들을 제공할 수 있다.

good credit customers: web delegates email delegates sms delegates homephone

poor credit customers: homephone delegates officephone delegates cell

따라서, 고객이 각 요청에 응답하지 못할 때, 요청은 다음 연락 방법으로 에스컬레이트된다.

Votes/Polls

수신자들의 리스트들에 대한 순차적이고 동시적 통신 흐름 프리미티브들을 일반화하는 것이 가능하다. "and/or" 프리미티브들의 동시 및 순차적 형태들은 한 리스트의 수신자들에 의한 vote가 동시에 혹은 순차적으로 될 수 있게 하는 2 이상의 일반적인 프리미티브들의 특별한 경우들이다. 예를 들면, 성공적인 "and" 프리미티브들은 100%가 예로 vote한 두 수신자들에 의한 vote들이며, 성공적인 "or" 프리미티브들은 적어도 50%가 예로 vote하는 두 수신자들에 의한 vote들이다.

"vote" 프리미티브는 한 리스트의 수신자들의 수 c를 동시에 연락하고 성공 응답들의 카운트 값 m 혹은 백분율 n%에 도달한 경우 성공(참)을 리턴한다. 이에 따라, c-m+1 거짓 응답들이 있다면 실패가 발생한다. 각 수신자는 통신 흐름 표현이 될 수 있고, 카운트값 혹은 백분율은 성공한 "votes" 프리미티브에 대해 수신되어야 하는 성공 수를 나타낸다. 예를 들면,

{TOM, Joann, Jerry} votes 50%

는 Tom, Joann 및 Jerry에 동시에 연락을 취한다. 적어도 둘이 성공 응답한 경우, "votes" 프리미티브는 성공으로 된다. "votes" 프리미티브는 명시된 카운트값 혹은 백분율에 이르는 못하게 충분한 수의 수신자들이 거짓 응답들을 리턴하였을 땐 실패이다(거짓을 리턴한다). 다른 경우에, 성공에 도달될 수 없는 경우, "votes" 프리미티브는 maybe로 된다. 위의 예에서, Tom, Joann 및 Jerry 중 적어도 둘이 실패로 응답하면, "votes" 프리미티브는 실패로 된다. 한편, 참, 거짓 및 maybe는 maybe의 참 값으로 된다.

프리미티브에서 카운트값 혹은 백분율로부터 직접 참을 리턴시키는데 필요한 참 vote의 수를 산출하는 것이 가능한 것에 유의한다. 이로부터, 거짓을 리턴하는데 필요한 거짓 vote들의 수(총 카운트값 +1- 참 수), 및 maybe를 리턴하기 위한 비-참 vote들(적어도 하나가 maybe인 거짓 혹은 maybe)의 수(총 카운트 수 + 1-참 수)을 산출하는 것은 간단한 일이다. "polls" 프리미티브는 "votes" 프리미티브에 이어지는 형태이다.

votes 프리미티브는 예를 들면 한정된 수의 아이템들을 판매하거나 분배시키는데 효과적으로 사용될 수 있다. 예를 들면, 500 단위의 소정의 아이템과 5000명의 잠재 고객들을 갖고 있는 회사는 다음과 같은 통신 흐름을 명시할 수 있다.

{customer1, customer2,..., customer5000} votes 500

이 요청은 고객들이 500 단위들(각 고객이 단지 한 유닛만을 주문한다고 할 때)을 주문하였을 때 완료될 것이다. 각 고객이 한 단위 이상을 주문할 수 있는 예을 다룸에 있어, 테스트 응답 상태 프리미티브들에 대해 이하를 참조한다.

poll 프리미티브는 긴급 인원 수급을 채우는데 효과적으로 사용될 수 있다. 예를 들면, 내일 아침까지 지시된 리스트로부터 5명의 보결 선생을 찾는 학교는 다음과 같이 통신 흐름을 명시할 수 있다.

{teacher1, teacher2,..., teacherN} polls 5

전술한 바와 같이, 이 요청은 5명의 보결 선생이 가르치는 것에 동의하였을 때 완료될 것이다.

통신 흐름 표현은 리스트들이 아니기 때문에, 표현을 "votes" 및 "polls" 프리미티브들이 요하는 리스트들로 변환하는 것이 유용하다. 특히, 수신자 선호도 및 역할 데이터베이스(500) 내 지명 통신 흐름들은 흔히 자연적으로 리스트 구조를 갖는다. 괄호 내 리스트들이 아닌 통신 흐름 표현이 "votes" 및 "polls" 프리미티브들의 제1 오퍼랜드들로서 나타날 때 이들 프리미티브들에 대한 자동 변환이 지원된다. 판독가능이나 분리만을 포함하는 통신 흐름 표현의 경우 자동변환이 행해진다. 표현이 "and" 및 "then" 프리미티브들만을 포함한다면, 판독가능들의 리스트로 변환된다. 표현이 "or" 및 "else" 프리미티브들만을 포함한다면, 표현은 분리들의 리스트로 변환된다. 위에 주어진 예로 다시 가서,

Reviewers votes 2

은 실제적으로는

(Chris and Jerry and Benji and Jenny) votes 2

인 표현이다.

판독가능은 자동으로 리스트 {Chris, Jerry, Benji, Jenny}로 변환된다. 어떤 표현을 리스트로 변환하는 상세를 명시하는 것이 가능한 반면, 이러한 변환들이 필요하거나, 명료하거나 바람직하다라는 것은 명료하지 않다. 후술하는 탐색 프리미티브는 리스트들을 표현으로 변환한다.

"races" 및 "delegates" 프리미티브들의 일반화

수신자 리스트들에 대한 "race" 및 "delegate" 프리미티브들을 일반화하는 것이 가능하다. 일반화 "race"라 하는, "race"의 일반화는 한 리스트의 수신자들, 수집할 응답들의 수 및 수신된 응답들로부터 프리미티브의 성공 혹은 실패를 판정하는 결정 알고리즘을 받아들인다. 예를 들면, 일반화 "race"의 한 사용은 수신된 N번째의 값을 받아들이는 것이다. 이것은 100번째 통화자로부터의 응답을 받아들이는 라디오 토크 쇼 모델에 상응한다. 또 다른 예에서, 일반화 race는 5 응답들 중 셋을 모으고 3의 다수 응답을 리턴한다. 이 결과는 2 성공을 기다리는,

{A, B, C, D, E} votes 2

과는 다른 것에 유의한다. 일반화 delegate는 delegate 프리미티브의 일반화이다. 일반화 delegate는 프리미티브가 만족될 때까지 순차적으로 수신자들에 연락하는 것을 제외하곤 일반화 race와 유사하다.

순차/동시 프라미티브들의 구현

순차 및 동시 프라미티브들은 단순한 카운팅 알고리즘에 의해 본 실시예에서 구현된다. 각각의 프리미티브는 참을 리턴하는데 필요한 참 응답들의 수와 거짓을 리턴하는데 필요한 거짓 응답들의 수에 의해 기술된다. 또한 maybe를 리턴하는데 필요한 최소 수의 maybe 응답들 및 maybe가 리턴되기 전에 수신되어야 하는 총 응답 수에 의해 또한 기술된다. 도 10은 각 프리미티브에 대한 카운트값들을 요약한 것으로 C는 votes/polls에 리스트된 모든 수신자들의 카운트값이고 X는 votes/poll 백분율 혹은 카운트값에 의해 요구되는 참 응답들의 수이다. 동시 및 순차 프리미티브들은 각 부류에서 수신된 응답들의 수를 카운트한다. 상태 리턴들 중 하나에 대한 요건에 이르렀을 땐 항시, 프리미티브들은 현안의 요청들을 취소시키고 적합한 상태를 리턴한다.

상태 해석 및 시간 프리미티브들

도 4에 관련하여 전술한 바와 같이, 수신자(120)에게의 요청에 대한 성공은 통지 성공 및 응답 성공을 포함한다. 통지 성공은 수신자에 성공적으로 연락되었을 때 일어난다. 내정에 의해서 응답 성공은 요청 및 응답 시스템 API에서의 성공의 정의를 만족시키도록 수신자가 응답하였을 때 일어난다. 통지 및 응답 시스템(100)의 웹 API에 있어서, 응답 성공에 대한 내정은 제출 버튼에 "거짓" 혹은 "아니오" 값을 포함시키지 않은 웹 폼에 응답하는 것이다. 제출 버튼의 "거짓" 혹은 "아니오"는 응답 실패에 대해 내정된 응답이다.

일부 애플리케이션들은 응답 성공에 대해 애플리케이션에 특정한 정의를 요할 수도 있다. 예를 들면, 지출 레포트가 차례로 몇 개의 관리자들에 의해 승인된다면, 성공은 report_status="approved"으로 요청에 응답하는 것으로서 정의될 수 있다.

테스트 응답 상태 프리미티브에 의해서 애플리케이션들은 응답 성공 명세를, 응답으로부터의 속성값 쌍들을 비교한 것을 논리적으로 표현한 것으로서 제공할 수 있다. 논리적 표현은 응답이 테스트될 수신자 다음의 물음표들 사이에 명시된다. 비교들은 등식, 부등식, 범위 및 정규 표현 매칭을 포함할 수 있다. 성공 명세가 통신 흐름에서 모든 수신자들에 대해 동일하나 시스템에 내정된 것과는 다른 경우, 전 요청에 걸쳐 내정된 것이 공급될 수 있다.

다음의 예는 내정된 기능을 사용함이 없이 응답 성공 상태를 명시한다.

DepartmentHead? report_status="approved"? then Director? report_status="approved"? then VP? report status ="approved"?

테스트 응답 상태 프리미티브가 복수의 수신자들을 포함하는 표현에 적용될 때, 보다 복잡한 표현으로 각 수신자에 적용된다. 예를 들면, 앞의 표현은

(DepartmentHead then Director then VP)? report status ="approved" ?

로서도 기재될 수 있다. 성공 명세는 지금까지의 모든 응답들에 대해 응답의 속성들에 관한 집성 및 이외 다른 진보된 처리를 수행한 후 성공 혹은 실패에 대해서 결과들을 테스트할 수 있다.

전술한 바와 같이, vote 프리미티브는 한정된 수의 아이템들을 판매하거나 분배하는데 사용될 수 있으나, 각 고객은 정확히 한 단위를 구입하는 것으로 가정한다. 다음과 같은 성공 표현에 의해서 각 고객은 하나 이상의 단위를 주문하고 적어도 100 단위들이 판매되었을 때 통지들을 종료시킬 수 있다.

(Sue or Fred or... or Sam)? sum [(number_sold) ≥ 100?

100 단위가 판매된 후에, 다른 수신자들에게의 미결 요청들은 취소된다. 통지 신청이 통지 및 응답 시스템이 사용할 수 있는 데이터에 의해 개인화되었을 때, 이전 응답들의 결과들은 여전히 판매가능한 이들 아이템들(100-sum (number_sold)) 을 수신자들에게 내놓는데 사용될 수 있다. 두 수신자들이 남아 있는 아이템들을 구입하려 한다면, 제1 수신자는 성공할 것이고 제2 수신자는 다른 자에 의해 완료되었기 때문에 요청이 취소되었음(즉, 신청 철회)을 듣게 될 것이다.

Between/Before/After

응답 상태를 테스트하는 프리미티브 외에도, "between", "before", 및"after" 프리미티브들은 통지를 보내고 수신자로부터 응답을 수집하는 시간 제약을 명시한다. 시간 제약은 "after" 프리미티브에서처럼 시작 시간을, "before" 프리미티브에서처럼 종료시간을, 혹은 "between" 프리미티브"에서처럼 양자 모두를 명시할 수 있다. "Between x-y"는 "after x before y"로서 나타낼 수 있다. 동일 수신자에게 복수의 시간제약이 적용될 때, 시간제약은 좌측에서 우측으로 평가된다. 제1 시간제약은 유효 시작 및 종료시간을 확정한다. 연이은 시간제약들은 이들 시간들을 구체화할 수도 있다. 상대적인 시간제약은 순방향 혹은 역방향으로 시간들을 조정할 수 있다. 이외의 제약들, 예를 들면 간격의 시작 혹은 끝을 찾는 것을 포함하는 것들은 시작시간을 앞으로 종료시간을 뒤로 이동시킬 수 있다. 즉, 복수의 프리미티브들이 상충되는 절대 시작시간들 혹은 상충되는 절대 종료 시간들을 수립한다면, 시작시간을 늦추고 종료시간을 앞당기는 것을 사용하여 효과적으로 제약 간격들을 교차시킨다. 시간적 제약 프리미티브가 복수의 수신자들을 포함하는 표현에 적용될 때, 보다 복잡한 표현으로 각 수신자에 적용된다.

시간 제약들은 시간 표현 및 시간 영역 표현을 사용하여 명시된다. 시간 표 현은 시간의 특정 시각을 나타내며, 시간 영역 표현은 시간 영역을 나타낸다. 시간 영역 표현들은 시간 표현을 기재할 때 사용되므로 먼저 시간 영역 표현을 정의한다. 시간영역은 (시작시간, 종료시간)으로서 명시된 하나 이상의 시간적인 간격들이고, 여기서 시작시간은 간격 내에 있으며 종료 시간은 그렇지 않다. 기본 시간 영역은 개념상 시작(생성)부터 시간의 종료(아마게돈)까지의 한 구간이다. 생성은 임의의 시작시간(이를테면 1970년 1월 1일에 00:00.00 UTC, 유닉스에서 에포크와 같은)으로서 취해지고, 아마게돈도 유사하게 취급된다. 현재, 시간은 생성 이후 초의 분해능으로 명시된다. 모든 다른 시간 영역은 구간의 시작은 닫히고 구간의 종료는 열린 한 세트의 해체 시간 구간들(시작, 종료)이다.

시간 영역들은 합집합, 교집합, 및 여집합 하에선 닫힌 영역이고, 이것은 영역들에 대한 이들 연산들이 또 다른 유효한 영역을 생성함을 의미한다. 시간 영역 표현은 프리미티브 시간 영역(이하에 정의됨), 및 합집합, 교집합, 여집합의 연산들로부터 형성된다. 통신 흐름 표현이 지명되어 다른 통신 흐름 표현에서 사용될 수 있는 것처럼, 시간 영역 표현도 지명되어 다른 시간 영역 표현에서 사용될 수 있다.

프리미티브 시간 영역들은 다음을 포함한다.

이를테면 2002년 5월 13일, 9:00.00부터 2002년 5월 13일, 17:00.00까지와 같이, 명시된 시작 및 종료 시간을 가진 구간.

2002년 5월 13일과 같이, 어떤 소정의 날

이를테면 2002년 5월 12일 일요일부터 2002년 5월 18일 토요일과 같이 어떤 소정의 일 주일.

이를테면 2002년 5월과 같이, 어떤 소정의 월.

2002년과 같이, 어떤 소정의 해.

이를테면 월요일과 같이(주중의 어떤 소정의 날)(생성과 아마게돈 사이의 모든 월요일들의 합집합을 의미)

5월과 같이, 어떤 소정의 월(생성부터 아마게돈까지의 모든 5월들의 합집합의 의미)

7월 4일과 같이, 한 해의 어떤 소정의 날(생성부터 아마게돈까지 모든 7월 4일의 합집합을 의미).

이를테면 9:00-17:00.00과 같이, 어떤 소정의 시간 범위(생성부터 아마게돈까지의 모든 날들 상의 모든 이러한 구간들의 합집합을 의미).

예를 들면, 소정의 날들로서 월요일, 화요일, 수요일, 목요일, 및 금요일의 합집합으로서 평일을 정의할 수도 있을 것이다. 1월 1일, 7월 4일 및 12월 25일의 합집합으로서 휴일들을 정의할 수도 있을 것이다. 업무시간들을 평일과 시간 범위 9:00.00-17:00.00의 교집합인 것으로 정의할 수도 있을 것이다. 또한 이를 휴일들의 여집합과의 교집합을 취함으로써 업무시간들을 정할 수도 있을 것이다.

시간 표현들은 절대시간을 명시할 수도 있고, 혹은 시작시간(이를테면 지금부터 4시간)에 관하여 계산되는 시간을 명시할 수도 있고, 혹은 시간영역 및 시작시간(이를테면, 다음 업무일의 시작; 혹은 지금부터 업무 4시간으로, 업무시간의 시간영역 내에서만 카운트하여 지금부터 4시간을 의미)으로부터 계산되는 시간을 명시할 수도 있다.

시간 표현은 다음 형태들 중 하나를 취할 수도 있다.

이를테면 2002년 5월 13일 17:00.00과 같은, 어떤 절대 시간.

현 시간 후 4시간을 의미하는, 이를테면 +4:00.00과 같은 상대적 시간, 혹은 현 시간 전 3시간을 의미하는, -3:00.00.

시간영역 내 다음 구간의 시작 혹은 종료, 예를 들면, 다음 업무 마감은 현재 시간 이후 업무시간들 내 한 구간의 다음 종료로서 명시될 수 있다. 보다 일반적으로, 시작들 혹은 종료들, 예를 들면 업무의 두 번째 마감을 카운트할 수 있다.

소정의 시간영역 내에서 경과된 시간, 예를 들면 지금이 2002년 5월 13일 16:00.00일 경우 업무 4시간 경과는 2002년 5월 14일 12:00.00가 된다. 현재 시간부터 뒤로 이동시킬 수도 있는데, 이것은 앞으로 이동시킨 후에 특히 유용하다. 예를 들면 다음 휴가를 위해 시간영역을 정할 수 있고, 그러면 다음 휴가 시작 전 업무 4시간을 참조할 수 있다.

이들에 관하여 보다 복잡한 시간표현들을 정할 수 있다.

예를 들면, 매일 12:00.00부터 12:00.00까지 지속되는 (공) 시간구간을 정할 수 있다. 이러한 구간의 다음 시작(혹은 종료)을 취할 경우 다음 날 정오로 된다. 평일의 교집합을 사용하여 유사하게 다음 업무일의 정오를 계산할 수도 있을 것이다. 이것을 구간들의 종료들을 카운트하는 연산자와 결합함으로써 다음 업무일의 정오 이후 업무 2일의 마감을 계산할 수 있다.

또 다른 예로서, 스페인에서의 업무시간들을, 9:00.00-12:00.00과 14:00.00- 19:00.00과의 합집합으로서 명시할 수도 있을 것이다. 당일의 업무 마감을 알기 위해서, 스페인의 업무시간들과 당일과의 교집합을 취한 후 결과로 나온 시간영역 내에서 구간의 마지막 종료를 찾는다.

기업은 통신 흐름 관리자용으로 내정한 시간영역 객체들을 정의할 수 있고 혹은 각 수신자는 그들 자신의 개인적인 시간영역 객체들을 정의할 수 있다. 이러한 객체들의 한 사용 예는 기업에 대해 업무시간들을 정의하는 것이다. 객체는,

Common name (cn) of the time domain object: business

(시간영역의 공통명(cn)): 업무)

을 포함한다.

디렉토리는 어느 수신자들이 영역을 사용할 것인가를 필터링한다. 이것은 이 업무 시간 영역을 특정 회사나, 시간대, 혹은 지리적 영역 내 사람들에 연관시키는데 사용될 수 있다.

유효 시간들을 산출하는데 사용하는 시간대.

영역 내 구간들에 대한 시간영역 표현. 이 시간영역 표현은 다른 기본적인 혹은 지정된 시간영역들을 참조할 수 있다.

시간영역에 시간적 표현 연산자들로서 "-의 종료", "-의 시작", "-의 n 종료", "-의 n 시작, 여기서 n은 카운트값 혹은 마지막 키워드이고, 영역 내 상대적 시간 "+", "-전", "-후", 및 "사이" 프리미티브들에서 영역 내 상대적 시간인 "-"가 사용되고, 예는 다음과 같다.

AFTER end of business

BEFORE 2 start of business

BETWEEN start of business-end of business

BEFORE business + 4: 00.00

AFTER end of business AFTER business-01: 00.00

AFTER last end of (SpanishBusinessHours intersect Today)

신택스를 보다 자연스럽게 되게 하기 위해서 여러 가지 단순화가 행해질 수 있다. 예를 들면, 시간영역 명이 after 다음에 온다면, 이 시간영역 내 구간의 다음 종료를 지정된 시간이 되게 취할 수도 있을 것이다. 유사하게, before에 대해서, 시간영역 내 구간의 다음 시작을 지정된 시간으로 취할 수 있다. 이것은 "AFTER end of business"를 "AFTER BUSINESS"로 단순화시키며, "BEFORE start of Monday"는 "BEFORE Monday"가 되게 단순화시킨다. 이것은 또한 "BETWEEN end of 08: 00.00-start of 17: 00.00"를 "BETWEEN 08: 00.00- 17: 00.00"가 되게 단순화시킨다. 현존의 시간영역들에 관해 합집합, 교집합 및 여집합을 사용하는 전 시간영역 표현은 시간영역 명이 사용되는 곳에서도 사용될 수 있다.

통신흐름 관리자의 표준 내정된 처리는, 시간영역 객체의 공통적인 명칭은 통신흐름에 명시된 명칭으로 시작하는데 business$west-coast와 같이 달러문자 "$" 다음에 다른 조건을 포함할 수도 있다는 것과, 수신자는 시간영역 객체 내 필터와 매칭시켜야 한다는, 2가지를 조건부로 하여 시간영역 명을 결정하는데 적용된다. 몇 개의 일치하는 객체들이 발견된다면, 객체들 중 하나가 선택되는데, 가능하다면 논리적으로 가장 특정한 필터(모든 다른 매칭 필터들을 포함하는 필터)를 가진 객 체이고, 가능하지 않다면, 일치하는 객체들 중 임의의 선택된 하나이다. 먼저 통신 흐름 관리자는 inetOrgPerson 혹은 inetRole 객체의 콘텍스트에서 매칭 필터로 소정의 명칭의 시간영역을 찾는다. 어느 것도 발견되지 않는다면, 통신 흐름 관리자는 이의 내정된 디렉토리에서 영역을 찾는다.

Short Names and Directory Search Primitives

여기서 다루어지는 예들은 요청자들(110)이 짧은 명칭들을 사용하여 수신자들(120)을 명시할 수 있음을 보이고 있다. "디렉토리 내정 및 발견적 방법" 제하의 단락에서 후술하는 바와 같이, 이들 짧은 명칭들은 수신자 선호도 및 역할 데이터베이스(500)의 발견적 방법에 의한 탐색에 의해 번역된다. 요청자들(110)은 꺽쇠 괄호에 수신자(120)의 구별적인 전체 이름, 예를 들면 <uid=Joann, ou=people, o=research.avaya.com>을 명시할 수도 있다. 수신자들(120)에 대해 구별적인 명칭들을 명시하는 것은 사용자들이 LDAP 명칭 트리(도 6)의 구조를 알 것을 요하기 때문에 사용자들에겐 어려울 수 있다. 통신 흐름 표현은 탐색 동작들을 또한 지원하므로, 사용자들은 수신자 선호도 및 역할 데이터베이스(500) 내 하나 이상의 수신자 객체들의 속성들을 기술할 수 있다. 사용자들이 탐색 동작들을 채용할 때, 이들은 디렉토리 객체들의 구별되는 명칭들을 알 필요가 없다. 이를테면 "search (filter, pattern, op),"와 같은 포맷을 갖는 탐색 프리미티브는 명시된 필터와 일치하는 사람, 역할 혹은 지정 통신 흐름 객체들에 대해 수신자 선호도 및 역할 데이터베이스(500)를 탐색한다. 진보된 탐색 프리미티브는 "adv_search (directory-server, directory-port, base, scope, filter, pattern, op)"와 같은 포맷을 갖는다. 진보된 탐색 프리미티브의 필터, 패턴 및 op 파라미터들의 동작은 탐색 프리미티브와 동일하다. 디렉토리-서버 파라미터는 탐색하기 위해 수신자 선호도 및 역할 데이터베이스(500)의 호스트의 도메인명을 명시하고, 디레고리-포트 파라미터는 이 호스트 상의 수신자 선호도 및 역할 데이터베이스(500) 서버의 포트 번호를 명시한다. 베이스에 구별적 명칭을 루트로 하는 디렉토리 트리가 서버에서 탐색된다. 탐색 범위는 베이스이거나(단지 베이스만에 의해 식별되는 객체의 경우), 1-레벨이거나(베이스에 의해 식별되는 객체의 자식만을 탐색할 경우), 서브-트리(베이스에 의해 식별되는 객체의 전체 서브트리를 탐색할 경우)이다. 디렉토리-서버, 디렉토리-포트, 베이스 혹은 범위는 널(NULL) 일 수 있고, 이 경우 내정값들이 적용된다.

일반적으로, 통신 흐름 표현을 위한 탐색 프리미티브들은 탐색 결과들을 처리하기 위한 매크로 기능을 포함한다. 리턴된 각각의 객체는, 토큰 "<dn>"의 경우, 탐색 프리미티브들의 패턴 파라미터에 주어진, 패턴으로 대치된다. 이어서 이 객체에 대한 결과 스트림은, 예를 들면 "and" 혹은 "race"인 탐색 프리미티브들의 op 파라미터에 주어진, 사용자가 명시한 프리미티브를 가진 다른 객체들에 대한 결과 스트림에 판독가능된다. 예를 들면, 패턴은,

(<dn> between 5/01/01-05/08/01) delegates (<dn> between 5/08/01- 05/10/01)

은 2001년 5월 1일 후 1회에 요청을 각 수신자에 통지하고 아무 응답도 수신 되지 않으면 2001년 5월 8일 후에 다시 통지하는 스트링을 생성한다. 요청 완료 전에 모든 수신자로부터의 응답이 필요하면, 결과 스트링들은 통신 흐름 표현을 생성하도록 "and" 프리미티브로 연결될 것이다. 사용자는 또한 이 기술에 숙련된 자에게 명백한 바와 같이, 단지 한 수신자에 리턴하는 것으로 탐색을 제약시킬 수 있다. 탐색에 복수의 일치들을 취급하는 방법을 명시함으로써 사용자들은 이들이 신중을 요하는 요청을 한 개인에 보내고자 할뿐일 때 큰 무리들에 이 요청을 부주의하게 보내는 것이 방지된다.

탐색 프리미티브들은 예를 들면 전문가 도움을 얻기 위해 사용될 수 있다. 예를 들면, 요청자가 이를테면 J2EE와 같은 소정의 토픽에 관해 전문가로서 정보를 필요로 한다면, 요청자는 다음과 같은 통신 흐름을 명시할 수 있다.

search ("& ((objectclass=inetOrgPerson) (expertise=J2EE))", "<dn>", OR)

대안으로, 통신흐름은 다음과 같이 명시될 수 있다.

expertl or expert2... or expertN

다른 예에서, 네트워크 알람이 발생되고 이는 전문가에 의해 해결되어야 한다. 요청자는 다음과 같은 통신흐름을 명시할 수 있다.

search ("& ((objectclass=inetOrgPerson)(expertise=netmgr))", "<dn>", OR)

이들 요청들은 한 전문가가 요청을 충분히 만족시킬 때 완료될 것이다.

다음 표는 연산자들의 우선도(연산 순서)를 높은 순에서 낮은 순으로 열거한 것이다. 동일 레벨의 연산자들은 좌측에서 우측으로 연합된다. 일반적으로 괄호 들은 우선 순서를 변경시키는데 사용될 수 있다.

연산자

AND, THEN

OR, ELSE

RACES, DELEGATES

NOT

VOTES, POLLS

AFTER, BEFORE, BETWEEN

?

SEARCH 및 이외 다른 기능들

요청 관리자(1200) 및 통신 흐름 관리자(1300) 상호작용

도 11 내지 도 13은 요청 관리자(1200)와 통신 흐름 관리자(1300) 간 상호작용을 예시한 것이다. 도 11은 요청에 연관된 각종의 엔터티들 간에 정보의 흐름을 예시한 개략적인 블록도이다. 도 12a와 도 12b는 도 11의 요청 관리자의 동작을 보다 상세히 예시한 흐름도이다. 도 13은 도 11의 통신 흐름 관리자의 동작을 보다 상세히 예시한 흐름도이다. 본 실시예에서, 요청 관리자 처리(1200) 및 통신 흐름 관리자 처리(1300)는 단계 1205(도 12) 및 단계 1305(도 13), 각각에서 검출되는 여러 기선정된 비동기 이벤트들을 처리한다.

도 12a에 도시한 바와 같이, 요청 관리자(1200)는 단계 1210에서 애플리케이션 인터페이스(220)를 통해 애플리케이션(110)으로부터 수신된 새로운 요청을 검출한다. 요청 관리자(1200)는 단계 1215에서 요청 데이터베이스(300)(도 3)에 요청에 대한 엔트리를 생성하고, 요청 식별자와 더불어, 요청에 대한 통신 흐름 표현 부분을, 단계 1220에서 파싱(parsing)하는 통신 흐름 관리자(1300)에 제공한다.

도 13에 도시한 바와 같이, 통신 흐름 관리자(1300)는 단계 1310에서 처리할 새로운 통신 흐름 표현을 검출한다. 통신 흐름 관리자(1300)는, 필요하다면, 단계 1315에서 통신 흐름 표현을 처리하고, 소정의 수신자용으로 채용할 매체 연락 객체들을 나타내는, 트리(600) 내 한 세트의 실행가능한 단말 노드들에 도달할 때까지, 수신자 선호도 및 역할 데이터베이스(500)를 사용하여 통신 흐름 표현 내 각 명칭을 계속 분석한다. 수신자들(120)은 통신 흐름 관리 GUI(1110)을 사용하여 수신자 선호도 및 역할 데이터베이스(500)에 이들의 선호도들을 입력하고 갱신할 수 있는 것에 유의한다.

통신 흐름 관리자(1300)는 연락할 장치 리스트를 생성하고 단계 1324에서, 이 리스트를 연락 스케쥴링 정보의 일부로서 요청 관리자(1200)에 보낸다. 일반적으로, 연락 스케쥴링 정보는 요청 관리자(1200)에 의해 즉각 스케쥴할 수 있는 연락들만을 포함한다. 예를 들면, 소정의 수신자의 선호도에, 오전 8시에서 오후 5시 사이에 전화에 의해 연락될 수 있을 뿐임이 나타나 있다면, 통신 흐름 관리자(1300)는 이 시간 범위가 유효하게 될 때까지 전화 매체 연락을 스케쥴하지 않을 것이다.

구체적으로, 통신 흐름 관리자(1300)는 수신한 통신 흐름 표현을 트리로 파싱을 행하고, 단말 노드에 도달할 때까지, 예를 들면, DFS(depth-first search) 방식을 사용하여 트리를 거침으로써, 트리 내 노드들을 반복하여 처리를 시작한다. 트리에서 단말(리프(leaf)) 노드에 접하게 될 때마다, 이에 저장된 매체 연락이 처리된다. 소정의 노드가 동시 프리미티브를 포함한다면, 동시 프리미티브의 오퍼랜드들에 연관된 모든 노드들이 처리된다. 소정의 노드가 순차 프리미티브를 포함한 다면, 좌측 오퍼랜드가 완료될 때까지 우측 오퍼랜드는 처리되지 않는다.

또한, 매체 연락을 요청 관리자(1200)에 리턴시키기 전에, 통신 흐름 관리자(1300)는 매체 연락(단말 노드)에 연관된 시간제약에 만족하는지 판정한다. 예를 들면, 통신 흐름 관리자(1300)는 시작 시간에 도달하였는지 판정한다. 모든 시간제약이 만족되면, 매체 연락은 요청 관리자(1200)에게로 리턴된 리스트에 포함된다. 모든 시간 제약이 만족되지 않으면, 매체 연락은 요청 관리자(1200)에 리턴된 리스트에 아직 포함되지 않으며 통신 흐름 관리자(1300)는 타이머를 설정하므로 매체 연락은 적합한 시간에 통신 흐름 관리자(1300)에 의해 리스트에 부가될 수 있다. 매체 연락 객체는 모든 시간제약이 만족될 때까지는 검색되지 않는 것에 유의한다.

통신 흐름 표현의 트리 표현은 관련 시간제약 확인을 용이하게 하기 위해서 기지의 방법으로 루트 노드에의 역 포인터들을 포함할 수 있는 것에 유의한다. 트리에서 사람 혹은 역할에 대해 지명된 노드에 접하였다면, 이 명칭이 동일 소유자(동일 명시된 통신 흐름)와 이전에 연락되었던 것인지 여부를 판정한다. 이 명칭이 동일 소유자와 이전에 연락된 바가 있었다면, 두 번째 연락 시도는 행해지지 않는다. 그보다는, 상태정보가 이전 연락으로부터 전파된다.

도 12a에 도시한 바와 같이, 요청 관리자(1200)는 단계 1225에서 수신된 연락 스케쥴링 정보를 검출하고, "매체에 특정한 인터페이스들" 제하의 단락에서 후술하는 바와 같이, 단계 1230에서 지시된 매체 연락 유형(들)을 사용하여 연락 스케쥴링 정보에 지시된 각 수신자에게 연락을 시도한다.

요청 관리자(1200)가 단계 1240(도 12b)에서 하나 이상의 응답들 혹은 메시지 만료 이벤트들을 검출하였다면, 대응하는 요청 식별자로 응답들 혹은 만료의 레코드가, 예를 들면, 보관 혹은 기록 유지 목적으로 단계 1245에서, 응답 데이터베이스(1150)에서 선택적으로 생성된다. 각 개개의 응답이 요청 애플리케이션(110)에 제공되는 실시예에서, 수신된 응답은 단계 1248에서 대응하는 애플리케이션(110)에 보내진다. 응답들 혹은 만료 상태는 단계 1250에서 다른 처리를 위해 통신 흐름 관리자(1300)에 보내진다.

통신 흐름 관리자(1300)는 단계 1330에서 요청 식별자로, 수신된 응답 혹은 만료 상태를 검출하고, 단계 1335에서 적합한 통신 흐름 표현을 불러들이기 위해서 요청 식별자를 사용한다. 단계 1330에서 응답 혹은 만료 상태가 검출되었을 때, 통신 흐름 관리자는 매체 연락의 상태를 반영하기 위해서 단계 1335에서 통신 흐름 표현의 트리 표현을 갱신한다. 이어서 통신 흐름 관리자(1300)는 현재 결정된 어떤 상급의 오퍼랜드의 상태를 결정함으로써 트리의 루트로 올라가므로 오퍼랜드는 매체 연락의 상태의 결과로서 이제 완료된다. 오펀랜드가 완료되었을 때, 이 오퍼랜드에 대한 현안의 매체 연락들은 취소시킬 연락 리스트에 넣어진다. 이 리스트는 적합할 때 단계 1350 혹은 단계 1320 후에 요청 관리자(1200)로 리턴된다. 상태의 전파로 통신 흐름 전체가 완료되지 않았으면, 이것은 트리 내 최상의 연산자의 완료 상태가 설정되었을 때 일어나는 것으로, 처리는 단계 1315으로 계속된다. 통신 흐름 전체가 완료되었으면 처리는 단계 1350으로 계속된다.

통신 흐름 표현을 사용하여, 통신 흐름 관리자(1300)는 어떤 추가 통신들이 필요한지 아니면 통신이 완료되었는지 판정한다. 단계 1340에서 추가 통신들이 필요한 것으로 판정되면, 프로그램 제어는 단계 1314로 가서 연락 스케쥴링 정보를 생성하고 이 연락 스케쥴링 정보를 요청 관리자(200)에 제공한다. 그러나, 단계 1340에서 통신 흐름 표현이 완료된 것으로 판정되면, 통신 흐름 관리자(1300)는 단계 1350에서 요청 관리자(1200)에 완료 상태 표시를 보낸다.

대조된 응답들이 요청 애플리케이션(110)에 제공되는 실시예에서, 단계 1260에서 요청 관리자(1200)가 통신 흐름 관리자(1300)로부터 완료 상태 표시를 일단 받았으면, 요청 관리자(1200)는 응답들을 대조하고 단계1265에서 요청 애플리케이션(110)에 의해 지시된 최종 목적지 주소로 되돌려 보낸다. 완료 상태 메시지는 단계 1270에서 대응하는 애플리케이션에 보내진다.

매체에 특정한 인터페이스들

본 실시예에서, 매체에 특정한 인터페이스들은, 이들 모두는, 연락을 개시하는 한 방법과 이를 취소시키는 또 다른 방법인 두 방법을 각 서브-부류가 구현할 것을 요하는 단일 앱스트랙트 MediaContact 분류의 서브-부류이다. 그러나, 단지 두 방법들만이 필요로 한다고 해도, 어느정도는 서브-부류들은 통지 및 응답 시스템(100)과 엔드포인트들 간에 인텔리전스 분배에 따라, 매우 단순한 것부터 매우 복잡한 것까지의 범위에 걸쳐 있다. 일반적으로, 각각의 매체 연락에 대해서, 요청은 후술하는 매체에 특정한 트랜스코더들 중 하나에 의해 트랜스코딩됨으로써, 시도될 특정 연락에 적합한 엔코딩을 만들어낸다. 프로토콜에 특정한 통신 인터페 이스는 엔코딩된 요청들을 각각의 수신자에 실제로 보내는 것을 처리한다.

이러한 일군의 부류들은 DAL(device abstraction layer)로서 간주될 수 있다. 이러한 DAL은 다른 통지 및 응답 시스템(100) 부류들에게 각종의 장치들의 모든 복잡성을 은폐시키고, 모든 장치들에 걸쳐 균일한 어떤 파라미터 설정 및 획득 방법들만이 아니라 통지를 구체화하고, 초기화하고 취소시키기 위해 단지 소수의 간단한 방법들만을 드러낸다. 다음에, 다수의 MediaContact 서브-부류들에 대해 기술한다.

WebContact

WebContact 부류는 미결 요청, 완료된 요청 및 취소된 요청들의 리스트들을 보기 위해서 수신자가 웹 포탈에 접속할 수 있게 한다. WebContact 부류는 미결 리스트에, 요청자 이름, 요청한 시간, 요지와 요청 URL에의 하이퍼링크를 포함하는 아이템을 삽입시킨다. 취소는 단지 아이템을 미결에서 취소 리스트로 옮긴다. "수신자"는 원하는 통지에 클릭한 후 표시되는 형태를 완성시킴으로써 응답한다.

PhoneContact

PhoneContact 부류는 수신자들이 전화를 걸거나 연락할 때까지 기다리는 것이 아니라 전화 호를 개시해야 한다. 또한, PhoneContact 부류는 VXML 스트립트(혹은 또 다른 텍스트로 된 표현)를 오디오로 바꾸어주는 VoiceXML(Voice eXtensible Markup Language) 시스템을 채용할 수 있다. PhoneContact 부류는 TCP 를 통해 자동전화 다이얼러에, 요청 식별자, 매체 연락 식별자, 전화를 걸 전화번호, 및 타겟 수신자에 VXML 스트립트를 보낼 서블릿의 URL을 명시하는 메시지를 보낸다. 취소의 경우, 단순히 PhoneContact은 아직 전화하지 않았다면 전화 호를 취소시킬 것을 지시하는 메시지를 보낸다.

자동 전화 다이얼러의 제어 프로그램은 전화 호들에 대한 요청들을 큐하고, 자원들을 사용할 수 있게 되는 즉시로 FIFO 순으로 이들을 실행한다.

EmailContact

본 통지 및 응답 시스템(100)은 3개의 서로 다른 유형들의 이메일로서 평문, HTML 및 내장 동적 HTML을 가능하게 한다. 첫 번째의 경우, 간혹 많은 수신자들은 텍스트로만으로 된 이메일 클라이언트들을 사용한다. 이것은 텍스트 에디터인 이맥스 및 어떤 웹 기반의 클라이언트들을 포함할 뿐만 아니라, Blacberry(등록상표) 및 Palm으로부터 구입할 수 있는 것들과 같은 무선 이메일 클라이언트들을 포함한다. 디렉토리에 이메일은 텍스트이어야만 한다는 것을 나타냄으로써 제공되어야 하는 이 경우, 통지 및 응답 시스템(100)은 대개는 요청자의 이름, 요청 요지 및 통지 메시지를 가리키는 URL을 포함하는 단순한 이메일 메시지를 구성한다. 본 구현에서, 요청 애플리케이션은 텍스트 메시지 자체를 생성하였으며 또한 오디오 액세스가 요청될 수 있을 음성 포탈의 전화번호를 삽입시켰다.

삽입된 프레임들 혹은 층들은 처리할 수 없으나 HMTL이 가능한 이메일 클라이언트의 경우, EmailContact는 다시 통지를 기술하지만 이 번엔 통지 메시지에의 하이퍼링크를 포함하는 HTML 페이지를 구성한다. 삽입된 프레임들 및 층들을 취급할 수 있는 이메일 클라이언트의 경우, EmailContact는 클라이언트가 메시지를 렌더링할 때 콘텐트들이 포함되게 통지를 삽입하는 메시지를 구성한다.

EmailContact에 있어 한 궁극적인 복잡화는 배송될 수 없는 이메일 메시지들을 해석할 필요성이었다. 이것은 이번에는 통지 및 응답 시스템(100)에 보내지는 어떠한 메시지들이든 취급하는 프로그램으로서 명시되는 주 방법을 제공함으로써 구현된다. 이 방법은 배송 시도가 실패하였다는 것 혹은 다른 어떤 것을 나타내고 있는지 여부를 알기 위해서, 리턴된 메일의 해석을 시도한다. 그러하다면, 통지 및 응답 시스템(100)에, 연락이 실패되었다는 것을 알린다. 통지 및 응답 시스템(100)은 선택적으로 수신 요청들을 읽고 이들을 해석할 수 있다. 이것은 아무 응답도 보내지지 않았어도 통지가 성공되었음을 판정하는 것을 가능하게 할 것이며 어떤 애플리케이션에 있어선 필요한 기능이 될 수도 있다.

SMSContact

SMSContact은 Sprint(등록상표), Verizon(등록상표) 및 AT&T(등록상표)를 포함하는 많은 셀 전화 제공업자들로부터 구입될 수 있는 단문 메시지 발송 서비스를 통해 통지들을 취급한다. SMSContact 객체는 메시지를 보내기 위해서 웹 사이트에의 제공업자 특정의 HTTP POST 혹은 GET을 행한다. 이메일을 서비스 제공업자에게 보냄으로써 이와 같은 것을 개략적으로 행하는 것이 가능할지라도, POST는 조금 더 제어를 제공한다. POST는 제공업자의 웹 인터페이스가 진화될 때 소프트웨어 변경 비용을 수반한다. 통지 및 응답 시스템(100)은 일단 메시지가 배송되었으면 대부분의 서비스 제공업자들이 내보내는 확인 이메일을 선택적으로 해석할 수 있다. SMS 메시지가 언제 성공적으로 보내졌는가를 확인하는 것 외에도, 이 이메일은 서비스 제공업자의 웹 인터페이스가 변경되었는지 여부를 알 수 있게 하므로 시스템은 SMSContact 소프트웨어가 갱신될 때까지 이메일 SMS 배송을 사용하는 것에 의존할 수 있다.

FaxContact

통지 및 응답 시스템(100)은 예를 들면 Avaya의 AUDIX 시스템의 패스기능을 사용하여, 팩스기에 통지를 보내는 부류를 제공할 수 있다. 이 부류는 HTML 혹은 텍스트 페이지를 TIFF 이미지 파일로 변환한 후 팩스를 통해 목적지에 이미지를 보내기 위해 요청을 발생한다. 이 부류는 또한 미결 팩스들에 관한 정보 및 이들의 어떤 제어를 제공하는 단순 상태 및 관리 서블릿을 포함한다.

AudixVoiceContact

AudixVoiceContact 객체는 통지의 텍스트판을 수신자의 음성 메일박스에 보내도록 설계되어 있다. 본 구현은 메시지를 오디오 파일로 바꾼 후 FaxContact과 동일한 메카니즘을 사용하여 AUDIX 서버에 보내지도록 IBM 사로부터의 ViaVoice(등록상표) 제품을 사용하여 구현된다.

SIPContact

SIPContact 부류는 통지 및 응답 시스템(100)을, SIP(Session Initiation Protocol)이 가능한 엔드포인트들에 접속한다. SIP는 예를 들면, 1999년 3월, M. Handley 등의, "SIP: Session Initiation Protocol,"RFC 2543에 기재되어 있다. SIP는 다양한 통신 세션들을 셋업하고 제어하는 IETF(Internet Engineering Taskforce)에 의해 정의된 비교적 새로운 프로토콜이다.

이를 행하기 위해서, SIPContact 부류는 통지 및 응답 시스템(100)으로부터 메시지를 수신하는 SEE(SIP Execution Environment)이라 하는 성분에 의존한다. 메시지는 수신자에 대한 SIP 주소; 매체 연락 식별자; 요청 식별자; 및 이 요청에 사용할 사용가능 매체 유형들 및 사람의 언어들의 리스트를 포함한다. SEE는 SIP 주소를 취하고, 수신자와의 연락이 수립되게 SIP 프로토콜에 따라 주소로 "초대"를 수행한다. 이어서 SEE는 수신자가 선호하는 매체 및 사람 언어를 나타내는 OK 메시지를 수신자 장치로부터 수신한다. SEE는 후술하는 XFS 요청을 실행하여, 사용가능한 것들로부터 이전에 공급된 리스트로부터, 매체 연락 식별자; 요청 식별자; 및 이 요청에 사용할 선호하는 매체 유형 및 사람 언어를 공급한다. XFS 요청은 수신자의 SIP 선호도에 따라 수신자에 통지하기 위해 적합하게 포맷된 콘텐트를 리턴한다. 이 기술은 원하는 포맷들 각각에 대해서 XFS를 1회에 SEE로 하여금 사용할 수 있게 함으로써 다수의 포맷들을 수신하기를 선호하는 장치들(일부 장치들은 화면들과 오디오를 구비하고 있다)을 지원한다.

본 구현에서, SEE는 Microsoft XP(등록상표)의 소프트폰에 인스탄트 메시지 혹은 호를 보낼 수 있으며; 호 제어 프로토콜을 SIP로 변경시킨(H. 323 대신에) SIP 가능 Avaya 4624(등록상표) IP phones, 디지털 및 아날로그 전화들로 (SIP 프로토콜 지원으로 향상된 MultiVantage(등록상표) 호 처리 소프트웨어 버전을 통해) 전화를 걸 수 있고; 적외선 기능을 갖추고 있고 호 제어 프로토콜을 SIP로 변경시킨(H. 323 대신에) SIP 가능 Avaya 4624(등록상표) IP 전화들에 인스탄트 텍스트 메시지들을 보낼 수 있고; 호 제어 프로토콜을 SIP로 대치시킨(H.323 대신으로) 실험용 SIP 가능 Avaya 4630(등록상표) IP 스크린 전화에 웹 페이지가 나타나게 할 수 있다.

SIP는 많은 방법으로 본 발명의 통지 및 응답 시스템(100)을 보완한다. 특히, SIP는 수신자의 선호도들이 이 수신자에 연락을 취하는 자에 적용하도록 한 서버에 연락 선호도들을 수신자가 셋업할 수 있게 하는 메카니즘을 제공한다. SIP가 가능한 수신자들이 SIP를 통해 이들의 선호도들을 표현할 수 있는 반면, 통상의 수신자들은 여전히 통지 및 응답 시스템(100) 내에서 개개의 통신 흐름들을 정의할 수 있다. SIP 메카니즘은 통지들을 어떻게 언제 수신할 것인가를 제어하기 위해 수신자들에 의해 사용될 것인 반면 통지 및 응답 시스템(100) 내 통신 흐름들은 비-SIP 엔드포인트들 및 SIP에 명시된 선호 엔드포인트들에 통지들을 어떻게 언제 보낼 것인가를 결정할 것으로 예상된다. 즉, SIP 및 통합 메시징이 메시지들을 수신하는 방법에 관해 제어할 수 있게 하는 바와 같이, 통지 및 응답 시스템(100)은 기업이 어떻게 이들 메시지들을 내보내는가에 대해 제어할 수 있게 할 것이다. 메시지들을 수신하는 방법에 대한 SIP 제어는 여기 개시된 바에 따라, 통신 흐름 표 현 및 통신 흐름 규칙 기능성에 의해 향상될 수 있는 것에 유의한다.

SIPContact 부류는 통지 및 응답 시스템(100)의 구조의 잇점들 중 일부를 시사한다. 특히, 통지 및 응답 시스템(100)에서 통지 메시지의 콘텐트는, 요청과 연락된 수신지 및 장치를 확인한 두 인자들에 의해 XFS라 하는 폼(form) 서블릿을 불러냄으로써 웹 혹은 전화 브라우저 혹은 MediaContact에 의해 불러들여질 수 있다.

http://xui/XFS ? Rid=xui-1234-1&Cid=1

여기서 Rid는 요청 id이고 Cid는 매체 연락 id이다. 이 둘은 함께하여 수신자를 식별하는데 충분하다. XFS는 단순히 요청 관리자(1200)를 사용해 적합한 요청을 검색하고, 이어서 통지 메시지의 URL를 얻는데 사용되었다. 이어서 이 메시지를 불러들여, 이에 응답 수신자를 변경하고 메시지를 개인화하도록 재기입된 후 브라우저 혹은 다른 목적지로 보내졌다.

복수의 언어 및 매체 유형들을 지원하기 위해서, XFS 서블릿은 원하는 언어 및 MIME 유형을 명시하기 위해 두 개의 추가 파라미터들을 받아들이도록 수정될 수 있다. 예를 들면, 보다 일반적인 XFS 버전은 다음과 같이 특정 언어 및 포맷 유형들의 검색을 가능케 한다.

http://xui/XFS?Rid=Xui-1234-I&Cid=1&Ctype=text/plain&Language=ENU

이것은 "xui-1234-1"의 영어, 평문판이 필요로 하는 것을 명시한다.

본 통지 및 응답 시스템(100)은 전화를 통한 음성 및 화면상에 웹 페이지 팝으로서 두 가지 방법으로 동시에 SIP 가능 Avaya 스크린 전화에 통지를 전한다. 이것은 스크린 전화를, 웹 팝 및 오디오 접속 모두를 취급할 수 있음을 SEE에 명시 하게 함으로써 행해졌다. 그러면 SEE는 XFS에 두 번의 호, 첫 번째는 HTML 페이지를 불러들이고 두 번째는 VXML 페이지를 불러들이도록 전화를 건다.

http://xui/XFS?Rid=xui-1234-1&Cid=1&Ctype=text/html&Language=ENU;

http://xui/XFS?Rid=xui-1234-1&Cid=1&Ctype=text/vxml&Language=ENU.

실시예들

전술한 바와 같이, 통지 및 응답 시스템(100)은 애플리케이션(110)(요청자)가 질의할 수 있게 하고, 원하는 응답 유형들을 명시할 수 있게 하며, 이메일을 통해 수신자들로부터 대조된 한 세트의 응답들을 수신할 수 있게 한다. 도 14는 팀 회합에 대한 요청의 파라미터들을 애플리케이션(110)이 명시하게 하는 웹 폼(1400)을 예시한 것이다. 도 14의 예에서, Joann은 회합을 스케쥴하는 요청을 "YangQian" 및 "Petsche"에 보내고 있다. 이들 수신자들이 회합 시간 및 장소에 동의하면, 참석할 수 있는지 알기 위해서 이들의 관리자(cmk)에 요청이 보내진다. 생성된 요청은 적합할 때, 다른 매체 연락들을 통해 지시된 수신자들에 보내진다. 요청은 요청을 답하기 위한 예 버튼과 아니오 버튼을 포함한다. 도 15는 요청의 컴파일된 결과를 도시한 것이다. 도 15에 나타낸 바와 같이, Petsche는 회합에 참석할 수도 있을 것이나 YangQian은 회합을 참석하지 못할 수도 있으므로 이들의 관리자에 연락되지 않았다.

도 16에 도시한 또 다른 예에서, 요청자는 4시간 동안에 선호하는 고객들에 새로운 회사의 IPO에서 일부의 주식 할당을 제공한다. 시간적 제약이 지정 통신 흐름인 PreferredCustomers에 적용된다. PreferredCustomers는 수신자들의 병렬 결합으로 번역하다. 요청자는 이의 최상의 고객들에의 요청에서 일련의 옵션을 제공한다. 이메일 선호도를 명시한 지정 통신 흐름인 PreferredCustomers에 의해 정의된 각 수신자에 의해 수신되는, 요청의 이메일 버전을 도 17에 도시하였다. 대조된 응답들은 모든 수신자들의 응답 혹은 제공의 4시간이 만기되는 즉시로 리턴된다. 수신자가 4시간 안에 응답하지 못하고 후에 관망하려 하거나 요청에 응답하려 한다면, 적합한 메시지가 표시되고 대답은 간청되지도 받아들여지지도 않는다.

"리버스 911"이라고 칭한, 본 발명의 또 다른 실시예는 통지 및 응답 시스템(100)이 긴급 911 응답을 제공할 수 있게 하여준다. 예를 들면, 통신 흐름 표현 및 규칙들은 학교에서 긴급한 문제가 있을 때 부모에 통지하도록 정의될 수 있다. 이러한 경우에, 학교에서는 교내 각 학생의 부모나 보호자에 연락해야 할 비상시 필요한 자원들을 비치하는 것은 어렵다. 본 발명의 리버스 911 시스템은 부모에 연락하기 위한 자동화된 기술을 제공하며, 부적절한 혹은 부정 사용을 방지하고 허위 알람을 최소화하기 위해 상당한 안전장치를 제공한다. 리버스 911 시스템은 비상시 연락 받을 선호도를 서비스 제공자에 부모가 등록할 것을 요한다. 일단 활성화되었으면, 학교들은 모든 부모들과 동시에 연락이 개시되게 웹 인터페이스 혹은 전자 메일을 사용할 수 있다. 통지는 선택적으로 메시지 수신 확인을 위해 부모용의 버튼을 포함할 수 있다. 또한, 학교는 통지가 부모에게 보내지기 전에 만족되어야 하는 여기 기술된 기술들을 사용한 승인 처리 요청자를 명시할 수 있고, 이러한 안전을 다른 안전 특징으로 강화시킬 수 있다(예를 들면, 요청자를 인증하기 위한 보인 로그인 및 액세스 제어). 따라서, 본 발명은 "루프 내 사람" 안전을 제공할 수 있다.

동일한 리버스 911 시스템은, 여기 개시된 바에 근거하여, 이 기술에 숙련된 자에게 명백하게 되는 바와 같이, 예를 들면 위급시 헌혈자를 찾아 스케쥴하기 위해서 적십자나 정부기관을 돕거나, 화학물 유출과 같은 특히 위험한 상황에 관하여 이웃의 주민들에 연락하는 다른 변형 예들에 채용될 수 있다.

"적응형 스케쥴링"이라 칭한, 본 발명의 또 다른 실시예에서, 통지 및 응답 시스템(100)은 스케쥴 변경의 지정된 수신자들에 통지할 수 있다. 예를 들면, 회의하러 가는 중에 기차나 항공기 비행과 같은 대량 수송 모드가 지체되거나 컴퓨터가 트래픽에 접하게 되면, 통지 및 응답 시스템(100)은 당사자들에게 스케쥴 변경을 통지하고 참가자들의 스케쥴들에 대한 적합한 수정을 조정하도록 구성될 수 있다. 예를 들면, 여기 기술된 월력 에이전트는 이러한 스케쥴 수정이 자동으로 수행되게 한다. 탑승객은 예를 들면 타이틀="비행 정보*"의 전자메일 메시지를 수신한 경우 개시되는 통신 흐름 규칙을 명시할 수 있다. 통신 흐름 규칙은 지체된 경우, 이를테면 리무진 서비스, 동료 혹은 배우자 등, 누구에게 연락할 것인가에 관한 정보를 제공할 수 있다. 통지는 영향을 받은 수신자에 특정한 정보를 제공할 수 있다. 예를 들면, 리무진 서비스에의 통지는 택일적 픽업 시간을 요청할 수 있고, 동료에의 통지는 회의 스케쥴을 다시 짤 것과(예를 들면 월력 에이전트를 사용하여) 혹은 지체된 승객이 없을 때 동료가 회의에 참석할 것을 요청할 수 있다(delegate 특징을 사용하여).

이 기술에 알려져 있는 바와 같이, 여기서 다룬 방법들 및 장치는 컴퓨터가 읽을 수 있는 코드 수단이 구현된 컴퓨터 독출가능 매체를 자체에 포함하는 제조자 물품으로서 배포될 수 있다. 컴퓨터가 읽을 수 있는 프로그램 코드 수단은 컴퓨터 시스템과 함께, 방법들을 수행하는 단계들 전부 혹은 일부를 수행하거나 여기 다루어진 장치들을 생성하도록 동작할 수 있다. 컴퓨터가 읽을 수 있는 매체는 기록 가능한 매체(예를 들면, 플로피 디스크, 하드 드라이브들, 컴팩트 디스크들, 혹은 메모리 카드들)일 수도 있고 혹은 전송매체(예를 들면, 광섬유를 포함하는 네트워크, WWW(world-wide web), 케이블들, 혹은 시분할 다중 접속, 부호분할 다중접속, 혹은 이외 라디오 주파수 채널을 사용하는 무선 채널)일 수도 있다. 컴퓨터 시스템에 사용에 적합한 정보를 저장할 수 있는 어떤 알려져 있는 혹은 개발된 매체가 사용될 수 있다. 컴퓨터가 읽을 수 있는 코드 수단은 이를테면 자기매체 상의 자기변화 혹은 컴팩트 디스크 표면에서의 높이 변화 등, 컴퓨터가 명령들 및 데이터를 읽을 수 있게 하는 어떤 메카니즘이다.

여기 기술된 컴퓨터 시스템들 및 서버들 각각은 연관된 프로세서들을 여기 개시된 방법들, 단계들, 및 기능들을 구현하도록 구성할 메모리를 포함한다. 메모리들은 분산 혹은 로컬일 수도 있고 프로세서들은 분산 혹은 단일체일 수도 있을 것이다. 메모리들은 전기, 자기 혹은 광학 메모리, 혹은 이들의 어떤 조합 혹은 다른 유형들의 기억장치들로서 구현될 수도 있을 것이다. 또한, "메모리"라는 용어는 연관된 프로세서에 의해 액세스되는 주소지정 가능한 공간 내 주소로부터 읽거나 이에 기입할 수 있는 어떠한 정보든 이를 충분히 포괄하도록 넓게 해석되어야 할 것이다. 이러한 정의에 의해서, 네트워크 상의 정보는 연관된 프로세서가 네트워크로부터의 정보를 불러들일 수 있기 때문에 여전히 메모리 내에 있다.

여기 도시 및 기술된 실시예들 및 변형 예들은 이 발명의 원리를 단지 예시한 것이고 여러 가지 수정들이 발명의 범위 및 정신으로부터 일탈함이 없이 이 기술에 숙련된 자들에 의해 구현될 수 있음을 알 것이다.

Claims

송신자에 의해 지정된 통신 흐름에 따라 상기 송신자로부터 적어도 하나의 수신자에게 메시지를 제공하는 컴퓨터로 구현되는 방법에 있어서,

상기 메시지를 상기 통신 흐름내의 제 1 수신자에게 전송하는 단계;

상기 제 1 수신자로부터 상기 메시지에 대한 제 1 응답을 수신하는 단계;

상기 제 1 응답과 연관된 내용에 기초하여 상기 통신 흐름내의 제 2 수신자를 선택하는 단계;

상기 메시지를 상기 제 2 수신자에게 전송하는 단계; 및

상기 통신 흐름의 파라미터에 기초하여 (1) 상기 제 1 수신자로부터의 상기 제 1 응답과 (2) 상기 제 2 수신자로부터의 제 2 응답을 대조하는 단계를 포함하고, 상기 통신 흐름의 실행이 완료된 후 상기 대조된 응답들은 상기 메시지에 지정된 어드레스로 전송되는, 송신자로부터 적어도 하나의 수신자에게 메시지를 제공하는 컴퓨터로 구현되는 방법.
삭제
삭제
삭제
삭제
삭제
삭제
삭제
제 1 항에 있어서, 상기 메시지는,

i. 상기 제 1 수신자 및 상기 제 2 수신자에 의해 지정된 선호도 정보(preference information), 및

ii. 서버를 통해 얻어진 존재 정보(presence information)

에 따라 상기 제 1 수신자 및 상기 수신자에게 제공되는, 송신자로부터 적어도 하나의 수신자에게 메시지를 제공하는 컴퓨터로 구현되는 방법.
삭제
삭제
제 1 항에 있어서, 상기 통신 흐름은 상기 제 1 수신자 및 상기 제 2 수신자와 연관된 기업(enterprise)에 의해 지정된 상기 제 1 수신자 및 상기 제 2 수신자의 적어도 하나의 선호도를 참조하는, 송신자로부터 적어도 하나의 수신자에게 메시지를 제공하는 컴퓨터로 구현되는 방법.
삭제
삭제
삭제
삭제
삭제
삭제
삭제
송신자에 의해 지정된 통신 흐름에 따라 상기 송신자로부터 적어도 하나의 수신자에게 제 1 메시지 및 제 2 메시지를 제공하는 컴퓨터로 구현되는 방법에 있어서,

상기 송신자로부터 상기 상기 제 1 메시지 및 상기 제 2 메시지를 수신하는 단계;

상기 통신 흐름을 평가하는 단계로서, 상기 통신 흐름은 상기 제 1 메시지 및 상기 제 2 메시지를 전달하는 상기 송신자의 적어도 하나의 선호도를 지정하고, 상기 제 1 메시지 및 상기 제 2 메시지는 상기 송신자에 의해 상이한 시간에 상기 적어도 하나의 수신자에게 전송되는, 상기 통신 흐름을 평가하는 단계; 및

상기 송신자의 상기 선호도들에 기초하여 상기 제 1 메시지 및 상기 제 2 메시지를 처리하는 단계로서, 상기 제 1 메시지 및 상기 제 2 메시지를 처리하는 단계는 상기 통신 흐름의 파라미터에 기초하여 상기 제 1 메시지 및 상기 제 2 메시지에 대한 응답들을 대조하는 단계를 포함하는, 상기 제 1 메시지 및 상기 제 2 메시지를 처리하는 단계를 포함하고,

상기 통신 흐름의 실행이 완료된 후 상기 대조된 응답들은 상기 제 1 메시지 및 상기 제 2 메시지에 지정된 어드레스로 전송되는, 송신자로부터 적어도 하나의 수신자에게 제 1 메시지 및 제 2 메시지를 제공하는 컴퓨터로 구현되는 방법.
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
송신자에 의해 지정된 통신 흐름에 따라 상기 송신자로부터 적어도 하나의 수신자에게 메시지를 제공하는 시스템에 있어서,

컴퓨터-판독가능 코드를 저장하는 메모리; 및

상기 메모리에 동작 가능하게 결합되는 프로세서를 포함하고, 상기 프로세서는 상기 컴퓨터-판독가능 코드를 구현하도록 구성되며,

상기 컴퓨터-판독가능 코드는,

상기 메시지를 상기 통신 흐름내의 제 1 수신자에게 전송하고;

상기 제 1 수신자로부터 상기 메시지에 대한 제 1 응답을 수신하고;

상기 제 1 응답과 연관된 내용에 기초하여 상기 통신 흐름내의 제 2 수신자를 선택하고;

상기 메시지를 상기 제 2 수신자에게 전송하고;

상기 통신 흐름의 파라미터에 기초하여 (1) 상기 제 1 수신자로부터의 상기 제 1 응답과 (2) 상기 제 2 수신자로부터의 제 2 응답을 대조하도록 구성되고,

상기 통신 흐름의 실행이 완료된 후 상기 대조된 응답들은 상기 메시지에 지정된 어드레스로 전송되는, 송신자로부터 적어도 하나의 수신자에게 메시지를 제공하는 시스템.
송신자에 의해 지정된 통신 흐름에 따라 상기 송신자로부터 적어도 하나의 수신자에게 제 1 메시지 및 제 2 메시지를 제공하는 시스템에 있어서,

컴퓨터-판독가능 코드를 저장하는 메모리; 및

상기 메모리에 동작 가능하게 결합되는 프로세서를 포함하고, 상기 프로세서는 상기 컴퓨터-판독가능 코드를 구현하도록 구성되며,

상기 컴퓨터-판독가능 코드는,

상기 송신자로부터 상기 제 1 메시지 및 상기 제 2 메시지를 수신하고;

상기 통신 흐름을 평가하고, 상기 통신 흐름은 상기 제 1 메시지 및 상기 제 2 메시지를 전달하는 상기 송신자의 적어도 하나의 선호도를 지정하고, 상기 제 1 메시지 및 상기 제 2 메시지는 상기 송신자에 의해 상이한 시간에 상기 적어도 하나의 수신자에게 전송되고;

상기 송신자의 상기 선호도들에 기초하여 상기 제 1 메시지 및 상기 제 2 메시지를 처리하도록 구성되고, 상기 제 1 메시지 및 상기 제 2 메시지를 처리하는 것은 상기 통신 흐름의 파라미터에 기초하여 상기 제 1 메시지 및 상기 제 2 메시지에 대한 응답을 대조하는 것을 포함하고;

상기 통신 흐름의 실행이 완료된 후 상기 대조된 응답들은 상기 제 1 메시지 및 상기 제 2 메시지에 지정된 어드레스로 전송되는, 송신자로부터 적어도 하나의 수신자에게 제 1 메시지 및 제 2 메시지를 제공하는 시스템.
삭제
삭제
삭제
송신자에 의해 지정된 통신 흐름에 따라 상기 송신자로부터 적어도 하나의 수신자에게 메시지를 제공하는 시스템에 있어서,

상기 통신 흐름내의 제 1 수신자에게 상기 메시지를 전송하는 수단;

상기 제 1 수신자로부터 상기 메시지에 대한 제 1 응답을 수신하는 수단;

상기 제 1 응답과 연관된 내용에 기초하여 상기 통신 흐름내의 제 2 수신자를 선택하는 수단;

상기 메시지를 상기 제 2 수신자에게 전송하는 수단; 및

상기 통신 흐름의 파라미터에 기초하여 (1) 상기 제 1 수신자로부터의 상기 제 1 응답과 (2) 상기 제 2 수신자로부터의 제 2 응답을 대조하는 수단을 포함하고,

상기 통신 흐름의 실행이 완료된 후 상기 대조된 응답들은 상기 메시지에 지정된 어드레스로 전송되는, 송신자로부터 적어도 하나의 수신자에게 메시지를 제공하는 시스템.
삭제
삭제
삭제