KR101481900B1 - 다운로드가능한 플러그가능 서비스 - Google Patents

Abstract

다운로드가능한 플러그가능 서비스들 및 그 서비스들을 분배하는 방법이 기술된다. 다운로드가능한 플러그가능 서비스는 통신 시스템을 업그레이드하기 위해 다운로드될 수 있는 통신 서비스에 해당할 수 있다. 다운로드가능한 플러그가능 서비스는 다운로드된 서비스를 제공하기 위하여 통신 시스템 내 각각의 서버에게 지시하는 컴포넌트 부분들을 조화된 방식으로 동작할 수 있도록 해주는 명령과 함께 업그레이드되는, 통신 시스템 내 각종 서버들 사이에 분배될 수 있는 다수의 컴포넌트 부분들을 포함할 수 있다.

Description

다운로드가능한 플러그가능 서비스{DOWNLOADABLE PLUGGABLE SERVICES}

본 개시물은 전반적으로 통신에 관한 것이며 더 구체적으로는 통신 시스템 및 방법에 관한 것이다.

통신 시스템은 정상적인 호 시그널링의 일부처럼 차례대로 나열되거나 이름이 붙여진 모듈라 애플리케이션을 전달하기 위해 개발되었다. 이러한 시스템에 대한 전망은 많은 애플리케이션들이 각종 해결 공간(solution space)을 위해 작성될 수 있다는 것이다. 지금까지, 애플리케이션 서버는 기껏해야 반년 단위로 하나의 정교한 애플리케이션을 공개할 수 있을 뿐이었다.

대부분의 통신 시스템에서, 현재 호 처리 특징은 단일의 모노리식 특징 서버(monolithic feature server)에 의해 제공되고 있다. 서버에서 새로운 것을 추가하거나 또는 기존의 호 처리 특징을 업데이트하려면 신규 버전의 소프트웨어가 필요하며 고객은 서버 전체를 업그레이드하여야 한다. 이러한 업그레이드는 동작 정지 시간을 유발할 수 있으며 신규/업그레이드된 특징의 사용자에게 제한되지 않는 영향을 미칠 수 있다. 다시 말해서, 현재의 통신 시스템은 편리한 시스템 업그레이드를 해주지 못하고 사용자마다 간단한 업그레이드를 해주지 못한다.

개발을 더욱 신속하게 하기 위하여, 애플리케이션을 독립적으로 개발하고 배치하게 해주는 에코 시스템이 필요하다.

전술한 문제 및 다른 문제에 대하여 본 명세서에서 제시된 실시예가 고찰되었다. 특히 본 개시내용의 실시예는 다른 것들 중에서 동일한 통신 시스템의 다양한 사용자들이 자기들에게 이용가능하게 만들어진 다양한 서비스들 및 동일 서비스의 다양한 버전들을 갖게 해주는 능력을 제안한다. 특히 사용자들의 다양한 서브집합의 사용자들은 이들에게 이용가능하게 만들어진 다양한 서비스들 및/또는 서비스 버전들을 가질 수 있다. 여기서 서비스들은, 예를 들면, 호 처리 부분, 사용자 인터페이스 부분 및 관리 부분을 포함한다.

일부 실시예에서, 이것은 통신 시스템 관리자가 신규 서비스 또는 기존 서비스의 신규 버전을 다운로드할 수 있으며 그 서비스 또는 버전의 필요한 부분은 통신 시스템 내 적절한 기기들에 설치될 수 있다는 사실로 인해 가능해진다. 그런 다음 관리자는 신규 서비스 또는 서비스 버전을 특정 사용자들 또는 사용자들의 그룹들에 할당하되, 다른 사용자들 또는 사용자들의 그룹들을 제외하고 할당할 수 있다.

본 개시내용의 한가지 장점은 현재 필요한 일이지만 서비스의 신규 버전이 서비스 시스템 전반의 신규 버전을 테스트하는 것보다 단일 사용자에게 테스트될 수 있다는 것이다. 서비스의 신규 버전은 서서히 롤 아웃(rolled out)(예를 들면, 단일 사용자마다 따로 따로) 될 수 있기 때문에, 서비스 업그레이드와 연관된 충격은 훨씬 적다. 또한, 시스템의 모든 사용자들을 업그레이드하기 전에 사용자들의 소수 그룹마다 버그를 찾아낼 수 있다.

본 개시내용의 다른 양태는 신규 서비스 버전 또는 완전히 새로운 서비스의 (업그레이드 동안 동작 정지시간 없는) 빈틈없는 배치를 갖는 능력을 제공하는 것이다.

서비스의 빈틈없는 배치의 일 예로서, 업그레이드를 받는 사용자는 통화 중에 자기들에게 할당된 업그레이드를 받을 수 있으며, 이 업그레이드는 통화 중에 이면에서 완료되어 사용자가 일단 통화가 끝나면 신규 서비스가 용이하게 이용가능해질 것이다. 특히, 업그레이드 프로세스는 신규 서비스의 각 컴포넌트가 동일 서비스의 이전 버전을 교체하지 않고도 적절한 컴포넌트에 분배되고 설치되게 할 수 있다. 그러므로, 영향받는 사용자가 통화 도중에 있는 동안 서비스가 배치될 일이 발생하면, 영향받는 사용자는 구 서비스 버전을 이용하여 통화를 계속할 것이다. 나중에, 사용자가 통화를 끝마친 후, 사용자는 서비스의 신규 버전으로 액세스할 것이다.

또한, 서비스는 소수 사용자 집합에 할당될 수 있다. 서비스를 더 많은 사용자들의 그룹으로 옮기기를 원할 때, 필요한 것은 새로이 할당된 개개인들에 대한 허가를 변경하는 것이다. 추가로 어느 소프트웨어를 모든 사용자의 기기에 배치할 필요가 없고, 다시 말해서, 이 일은 작동 중에 이루어질 수 있다.

알 수 있는 바와 같이, 신규 서비스는 기존의 전체 총 기능들의 업그레이드를 고려할 것이다. 그러므로, 본 개시내용의 실시예들은 기존 서비스 뿐아니라 신규 서비스들 둘다의 업그레이드를 포괄한다.

일부 실시예에서, 플러그가능 서비스는 호-처리 컴포넌트, 사용자 컴포넌트, 관리 컴포넌트 및 템플레이트 컴포넌트(template component)를 포함한다. 일부 실시예에서, "템플레이트 컴포넌트"는 신규 서비스/버전에 입각하여 기존 템플레이트에 무언가를 추가하고/플러그하는 것이다. 본 명세서에서 사용된 바와 같이, 템플레이트는 다수의 템플레이트 컴포넌트를 포함할 수 있으며, 여기서 각각의 템플레이트 컴포넌트는 배치된 상이한 서비스 또는 서비스 버전에 해당한다. 관리자는 특정 서비스들을 가능하게 주는 하나 이상의 템플레이트 및 이들 서비스들에 대한 특정 구성 설정을 생성한다. 이러한 템플레이트를 생성하고 이를 하나 이상의 사용자들에게 할당함으로써, 관리자는 각 사용자가 무슨 서비스 및 설정을 받아야하는지를 정확하게 관리할 수 있다. 그러므로, 관리자는 사용자를 대신하여 서비스 버전 또는 서비스 버전들의 그룹을 선택하게 된다.

만일 관리자가 템플레이트를 통하여 사용자가 다수의 상이한 서비스 버전들 중 하나를 가질 수 있게 규정한다면, 사용자는 자기가 사용하는 어느 서비스 버전을 선택할 수 있게 될 수 있다. 이 예에서, 템플레이트는 시스템 관리자가 사용자가 사용할 수 있게 한 버전을 규정하게 되며 그러면 사용자는 자기들이 실제로 사용하는 서비스의 어느 특정 버전을 사용자 인터페이스 컴포넌트를 통하여 선택할 수 있다.

일부 실시예에서, 플러그가능한 서비스는 JAR 또는 WAR 파일과 같은 특정 파일 포맷으로 패키지된 그의 다양한 컴포넌트들을 가질 수 있다. 예를 들면, 동적 기기 페이링(Dynamic Device Pairing (DDP)) '서비스' 단지(jar)는 호 처리 부분, 서비스 룰 부분, 사용자 포털/인터페이스 부분, 시스템 매니저 또는 관리자의 부분, 및 아마도 다른 컴포넌트(예를 들면, 국가별 컴포넌트, 언어 컴포넌트 등)을 포함할 수 있다. 가능한 모든 서브-컴포넌트들(예를 들면 모든 스킨, 모든 언어)를 전체 서비스 단지에 포함시키는 대신, 사용자는 자기들이 원하는 것을 고르고 선택할 수 있고, 그 결과 서비스가 매우 전문화되는 결과를 가져온다. 예를 들면, 사용자가 자기들의 사용자 포털에 스웨덴식 룩(swedish look)과 느낌을 원하는 경우, 사용자는 전체 서비스를 주문할 때 이것을 명시할 수 있으며, 이 서비스를 분배하는 엔티티는 그 스킨만으로 그 서비스를 구축할 것이다. 다른 부분들도, 예를 들면, 서비스 룰도 역시 변경될 수 있다. 동적 고객화(dynamic customization)는 서비스로 하여금 개개의 고객에 맞출 수 있는 다수의 퍼스널리티(personalities)를 갖게 해준다. 고객 역시 그 동작에 영향을 받기를 원할 수도 있다.

본 개시내용의 다른 양태는 다운로드하는 고객을 위해 국부적 패키지를 개발하는 독립적 당사자의 능력뿐아니라 플러그가능 라이센싱의 개념을 포함한다.

여기서 고객 또는 시스템 관리자는 주문 시에 플러그가능 서비스의 고객화를 명시할 수 있을 것이다(예를 들면, 얼마나 많은 사용자들이 서비스를 사용할 수 있고, 어느 사용자들이 그 서비스를 사용할 것인지 등). 또한, 서비스(또는 서비스의 각종 서브-컴포넌트들)에 라이센스를 포함시키고 주문 시에 동적으로 적절한 꾸러미를 생성하는 것이 가능할 수 있다.

본 개시내용의 다른 양태는 서비스에 의해 또는 서비스를 위하여 규정된 데이터 속성이 있을 수 있다는 것이다. 일부 실시예에서, 각각의 속성은 계층에서 열거된 레벨을 가지며 출고 디폴트(factory default)가 사용될 수 있다. 관리자 및 사용자는 이와 동일한 데이터를 구성하도록 허락된다. 일반적으로, 사용자가 구성한 값은 관리자 값보다 더 중요할 것이지만, 관리자는 데이터의 소정 부분을 사용자가 구성할 수 없다거나 기설정된 범위 내에서만 사용자가 구성할 수 있다는 것을 명시할 수 있다.

본 개시내용의 또 다른 양태는 상당량의 html 코드를 사용할 필요를 없애서 서비스를 제공하는 것과 관련하여 사용자의 스크린을 색칠하거나 렌더링하는 것이다. 특히, 확장가능 마크업 랭귀지(eXtensible Markup Language (XML))가 시스템 관리자 또는 사용자에 의해 조작될 데이터를 규정하는데 사용될 수 있다. html 코드는 통신 시스템의 시스템 관리자에 미리 저장될 수 있다. 플러그가능 서비스에 의해 제공된 업데이트는 html 코드가 검토하는데 무슨 데이터를 필요로 하는지를 추상적 언어로 규정하여야 하며 그런 다음 html 코드는 규정된 기능을 수행하기 위하여 그 추상적 언어를 검토하는데 사용된다.

무엇을 디스플레이할 것인지를 기술하는 속성 규정은 html 코드 자체보다 적은 코드 공간을 필요로 하기 때문에, 플러그가능 서비스는 최소 크기로 유지될 수 있다. 또다른 장점은 새로운 서비스의 개발의 용이함이다. 예를 들면, html 코드를 개발하고, 테스트하고, 전달하기 보다는 단지 데이터 요소만이 규정되는 것이 필요하다.

본 개시 내용의 적어도 일부 실시예에 따르면, 방법이 제공되며, 이 방법은 개략적으로,

고객의 통신 시스템에 대한 다운로드가능한 플러그가능 서비스를 획득하기 위한 요청을 고객으로부터 수신하는 단계와,

상기 요청을 수신한 것에 응답하여, 상기 다운로드가능한 플러그가능 서비스를 준비하는 단계 - 상기 다운로드가능한 플러그가능 서비스를 준비하는 단계는 단일의 객체로 패키지된 제1 서브-컴포넌트 및 제2 서브-컴포넌트를 획득하는 단계를 포함하며, 상기 제1 서브-컴포넌트는 고객의 통신 시스템의 제1 서버를 동작시키는 명령을 포함하며, 상기 제2 서브-컴포넌트는 상기 고객의 통신 시스템의 제2 서버를 동작시키는 명령을 포함함 - 와,

상기 단일의 객체를 상기 고객에게 전송하는 단계를 포함한다.

본 개시 내용의 적어도 일부 실시예에 따르면, 방법이 제공되며, 이 방법은 개략적으로,

통신 시스템을 다수의 사용자들에게 제공하는 단계와,

다수의 사용자들 중에서 제1 사용자 또는 사용자들의 그룹 마다, 상기 제1 사용자 또는 사용자들의 그룹이 상기 통신 시스템으로부터 액세스받게 허락받는 인에이블된 서비스들의 제1 집합을 규정하는 단계와,

다수의 사용자들 중에서 제2 사용자 또는 사용자들의 그룹 마다, 상기 제2 사용자 또는 사용자들의 그룹이 상기 통신 시스템으로부터 액세스받게 허락받는 인에이블된 서비스들의 제2 집합을 규정하는 단계 - 상기 인에이블된 서비스들의 제1 집합은 상기 인에이블된 서비스들의 제2 집합과 적어도 한가지 서비스 만큼 다름 - 와,

상기 제1 및 제2 사용자들 또는 상기 사용자들의 그룹의 상기 인에이블된 서비스들의 제1 및 제2 집합이 상기 통신 시스템을 사용하도록 하는 단계를 포함한다.

본 개시내용의 적어도 일부 실시예에 따르면, 방법이 제공되며, 이 방법은 개략적으로,

제1 사용자에 필요한 서비스를 수신하는 단계와,

상기 제1 사용자에게 통신 세션을 로그 오프 또는 단절할 것을 요구하지 않고 상기 제1 사용자에 필요한 서비스를 하나 이상의 서버들에게 로딩하는 단계를 포함한다.

비록 본 개시 내용의 실시예들이 기본적으로 통신 서비스 또는 통신 시스템과 관련하여 기술될 지라도, 본 명세서에서 사용된 바와 같은 '서비스'는 단일 기업 또는 다수의 기업들 내 사용자 또는 사용자들의 그룹에 이용가능하게 만들어진 모든 형태의 특징 또는 특징 집합을 포함할 수 있다는 것을 인식하여야 한다. 서비스의 비제한적인 예는 통신 서비스(예를 들면, 호 라우팅 서비스, 통화 향상 특징(call-enhancing features), 회의 서비스, 보안/암호화 서비스, 방화벽 서비스, 멀티미디어 통신 서비스, 협업 서비스 등), http-형 서비스(예를 들면, 웹-브라우징 서비스, 웹-협업 서비스 등), 미디어 서비스, 데이터 저장 서비스, 및 사용자들 또는 기기들에게 클라이언트 기기 또는 클라이언트 기기에 노출된 시스템의 동작을 향상시키는 콘텐트 또는 특징을 갖게 하는 서버 또는 서버들의 집합에 의해 지원 또는 제공될 수 있는 다른 모든 서비스를 포함한다.

또한, 본 명세서에서 사용된 용어 "서버"는 어느 서버, 서버들의 집합, 서버 내 프로세서, 서버 내 블레이드, 서버에 의해 실행되는 하나 이상의 가상 머신, 서버에 의해 실행되는 컨테이너 또는 프로세서 등을 포함하는 것으로 이해하여야 한다. 다시 말해서, "서버"는 반드시 전용 프로세서 및 메모리를 갖춘 개별 하드웨어 컴포넌트들로 제한되는 것은 아니다. 또한 "서버"는 J2EE 서버 또는 Java EE 서버의 다른 모든 버전과 같은 서버에 의해 실행된 특별한 형태의 컨테이너로 제한되지 않는다. 서버에 의해 실행될 수 있거나 서버를 구성할 수 있는 컨테이너의 비제한적인 예는 애플리케이션 컨테이너 (예를 들면, 자바 가상 머신(Java Virtual Machines), 애플릿 컨테이너(applet containers) (예를 들면, 웹 브라우저 또는 애플릿 뷰어(applet viewers)), 엔터프라이즈 자바빈(Enterprise JavaBeans (EJB)) 컨테이너, 웹 컨테이너, 및 애플리케이션 프로그래밍 인터페이스(Application Programming Interfaces (APIs)) 등을 포함한다.

"적어도 하나", "하나 이상", 및 "및/또는"이라는 관용구는 동작에 있어서 결합적이고 분리적인 두 가지를 가진 개방형 표현이다. 예를 들면, "A, B 및 C 중 적어도 하나", "A, B 또는 C 중 적어도 하나", "A, B 및 C 중 하나 이상, "A, B 또는 C 중 하나 이상" 및 "A, B 및/또는 C"는 A 단독, B 단독, C 단독, A 및 B 함께, A 및 C 함께, B 및 C 함께, 또는 A, B 및 C 함께를 의미한다.

용어 "하나" 또는 "한개"의 엔티티는 그 엔티티의 하나 이상을 언급한다. 이와 같이, 용어 "하나"(또는 "한개"), "하나 이상" 및 "적어도 하나"는 본 명세서에서 상호교체가능하게 사용될 수 있다. 또한, "포함하는", "구비하는" 및 "갖는"이라는 용어 역시 상호교체가능하게 사용될 수 있다고 알아야 한다.

본 발명에서 사용된 바와 같이, "자동"이라는 용어 및 그의 변형어는 프로세스 또는 동작이 수행될 때 물질적인 사람의 입력없이 이루어진 모든 프로세스 또는 동작을 지칭한다. 그러나, 프로세스 또는 동작의 수행이 물질적 또는 비물질적 인간 입력을 사용할지라도 그 입력이 프로세스 또는 동작의 수행 이전에 받은 것이면, 프로세스 또는 동작은 자동적일 수 있다. 사람의 입력은 그러한 입력이 프로세스 또는 동작이 수행될 방법에 영향을 미친다면 물질인 것으로 간주된다. 프로세스 또는 동작의 수행을 허락하는 사람의 입력은 "물질"로 간주되지 않는다.

본 명세서에서 사용된 "컴퓨터-판독가능 매체"라는 용어는 실행을 위해 명령을 프로세서에 제공할 때 동참하는 모든 유형의 스토리지(tangible storage)를 지칭한다. 이러한 매체는 이것으로 제한하지 않지만, 비휘발성 매체, 휘발성 매체 및 전송 미디어를 포함하여 많은 형태를 취할 수 있다. 비휘발성 매체는, 예를 들면, NVRAM 또는 자기 또는 광학 디스크를 포함한다. 휘발성 매체는 메인 메모리와 같은 다이나믹 메모리를 포함한다. 컴퓨터 판독가능 매체의 공통적인 형태는, 예를 들면, 플로피 디스크, 플렉시블 디스크, 하드 디스크, 자기 테이프, 또는 다른 모든 자기 매체, 자기-광학 매체, CD-ROM, 및 다른 모든 광학 매체, 펀치 카드, 종이 테이프, 구멍의 패턴을 갖는 다른 모든 물리적 매체, ROM, PROM 및 EPROM, FLASH-EPROM, 메모리 카드와 같은 고상 매체, 다른 모든 메모리 칩 또는 카트리지, 또는 컴퓨터가 판독할 수 있는 다른 모든 매체를 포함한다. 컴퓨터-판독가능 매체가 데이터베이스로서 구성될 때, 이 데이터베이스는 관계형, 계층형, 객체지향형 및/또는 기타와 같은 모든 형태일 수 있음은 당연하다. 따라서, 본 개시내용은 본 개시 내용의 소프트웨어적 구현물이 저장된 유형의 스토리지 매체 및 종래 기술에서 인식된 등가물 및 후속 매체를 포함하는 것으로 간주된다.

본 명세서에서 사용된 바와 같은 용어 "결정", "산출" 및 "계산" 및 이들의 변형어는 상호교환가능하게 사용되며 모든 형태의 방법론, 프로세스, 기계적 동작 또는 기술을 포함한다.

본 명세서에서 사용된 바와 같은 용어 "모듈"은 그 요소와 연관된 기능을 수행할 수 있는 모든 공지의 또는 나중에 개발되는 하드웨어, 소프트웨어, 펌웨어, 인공지능, 퍼지 로직, 또는 하드웨어 및 소프트웨어의 조합을 지칭한다. 또한, 본 개시내용은 예시적인 실시예에 관하여 기술되지만, 본 개시내용의 개개의 양태는 개별적으로 청구될 수 있음을 인식하여야 한다.

본 개시내용은 첨부의 도면과 함께 기술된다.
도 1은 본 개시내용의 실시예에 따른 제1 통신 시스템의 블록도이다.
도 2는 본 개시내용의 실시예에 따른 서비스 웨어하우스의 블록도이다.
도 3은 본 개시내용의 실시예에 따른 제2 통신 시스템의 블록도이다.
도 4는 본 개시내용의 실시예에 따른 제3 통신 시스템의 블록도이다.
도 5는 본 개시내용의 실시예에 따른 제4 통신 시스템의 블록도이다.
도 6은 본 개시내용의 실시예에 따른 배치가능 객체의 블록도이다.
도 7은 본 개시내용의 실시예에 따른 서비스 템플레이트의 블록도이다.
도 8은 본 개시내용의 실시예에 따른 관리 서비스와 관련하여 사용된 데이터 구조를 도시하는 블록도이다.
도 9는 본 개시내용의 실시예에 따른 다운로드가능한 객체를 전달하는 방법을 도시하는 흐름도이다.
도 10은 본 개시내용의 실시예에 따른 다운로드가능 객체를 배치하고 설치하는 방법을 도시하는 흐름도이다.
도 11은 본 개시내용의 실시예에 따른 다운로드가능 객체를 고객화하는 방법을 도시하는 흐름도이다.
도 12는 본 개시내용의 실시예에 따른 시스템의 가동시간 중에 서비스를 배치하는 방법을 도시하는 흐름도이다.
도 13은 본 개시내용의 실시예에 따른 서비스를 업그레이드하는 방법을 도시하는 흐름도이다.
도 14는 본 개시내용의 실시예에 따른 서비스를 위한 속성을 계층적으로 구성하는 방법을 도시하는 흐름도이다.

다음의 설명은 실시예만을 제공하며, 특허청구범위의 범주, 적용범위 또는 구성을 제한하려는 것은 아니다. 그 보다, 다음의 설명은 본 기술에서 통상의 지식을 가진자들에게 실시예를 구현할 수 있게 해주는 설명을 제공할 것이다. 첨부의 특허청구범위의 정신과 범주를 일탈하지 않고 구성요소들의 기능 및 배열에서 다양한 변경이 이루어질 수 있음은 물론이다.

도 1은 본 개시내용의 적어도 일부의 실시예에 따른 통신 시스템(100)의 예시적인 실시예를 도시한다. 통신 시스템(100)은 분산 시스템일 수 있으며, 일부 실시예에서는 서비스 웨어하우스(108)와 하나 이상의 고객 또는 고객 사이트(112a-N) 사이에서 통신의 편의를 도모해주는 하나 이상의 통신 네트워크(104)를 포함한다.

통신 네트워크(104)는 패킷 교환 네트워크 및/또는 회선 교환 네트워크일 수 있다. 예시적인 통신 네트워크(104)는 인터넷과 같은 광대역 네트워크(Wide Area Network (WAN)), 로컬 에리어 네트워크(Local Area Network (LAN)), 퍼스널 에리어 네트워크(Personal Area Network (PAN)), 공중 교환 전화 네트워크(Public Switched Telephone Network (PSTN)), 재래 전화 서비스(Plain Old Telephone Service (POTS)) 네트워크, 셀룰러 통신 네트워크(cellular communications network), IP 멀티미디어 서브시스템(IP Multimedia Subsystem (IMS)) 네트워크, SIP 네트워크, 보이스 오버 IP(Voice over IP (VoIP)) 네트워크 또는 이들의 조합을 포함하며, 이것으로 제한되지 않는다. 한가지 구성에 있어서, 통신 네트워크(104)는 한벌의 TCP/IP 프로토콜을 지원하는 공중 네트워크이다. 통신 네트워크(104)에 의해 지원되는 통신은 실시간, 근실시간(near-real-time), 비실시간(non-real-time) 통신을 포함한다. 예를 들면, 통신 네트워크(104)는 보이스, 비디오, 텍스트, 웹 회의, 또는 미디어의 모든 조합을 지원할 수 있다.

서비스 웨어하우스(108)는 고객(112a-N)이 서비스를 보고 궁국적으로 서비스를 구매할 수 있는 장소를 제공할 수 있다. 서비스 웨어하우스(108)에 의해 제공될 수 있는 서비스의 일예는 통신 서비스, 미디어 서비스, 관리 서비스, 데이터 저장 서비스, 프로세싱 서비스, 이들의 조합, 및 다른 모든 자동화된 또는 컴퓨터 구현된 서비스를 포함한다. 일부 실시예에서, 서비스 웨어하우스(108)는 웹 서버 또는 웹 서버들의 그룹에 의해 서비스되는 하나 이상의 웹 페이지를 매개로 그의 서비스로의 액세스를 제공할 수 있다. 서비스 웨어하우스(108)는 고객(112a-N)에게 서비스 웨어하우스(108)에 의해 제공된 각종 서비스를 공지의 웹-기반 통신 프로토콜(예컨대, http, secure http 등)을 통해 볼 수 있는 능력을 제공할 수 있다. 고객(112a-N)은 사용자 또는 시스템 관리자가 고객 사이트에서 서비스 웨어하우스(108)로부터의 서비스를 보고 구매하게 해주는 웹-브라우저 애플리케이션이 실행되는 하나 이상의 클라이언트 기기를 포함할 수 있다.

본 명세서에서 더 상세히 설명되는 바와 같이, 서비스 웨어하우스(108)는 고객(112a-N)으로부터 하나 이상의 서비스 주문을 수신하는 기능, 자동으로 하나 이상의 다운로드가능하고 플로그가능한 서비스를 준비하는 기능, 및 다운로드가능하고 플러그가능한 서비스를 주문한 고객(112a-N)에게 통신 네트워크(104)를 통해 송신하는 기능을 포함할 수 있다. 일부 실시예에서, 서비스 웨어하우스(108)는 주문받은 서비스(들)를 그 서비스(들)을 주문한 고객(112a-N)이 사용한 동일 또는 유사한 프로토콜을 통해 고객(112a-N)에게 제공할 수 있다. 또한 서비스 웨어하우스(108)는 주문받은 서비스(들)를 그 주문을 수신한 동안의 동일한 통신 세션에서 고객(112a-N)에게 제공하는 것도 가능하다. 다시 말해서, 서비스 웨어하우스(108)는 같은 주문받은 서비스(들)를 그 서비스(들)을 주문하는데 사용했던 웹-기반 통신 세션 동안에 수행된 동일 포트를 통해 전달할 수 있다. 이것은 서비스 웨어하우스(108)로부터 고객(112a-N)에게 서비스를 전달하는 간단하고 효율적인 방법을 제공한다.

서비스 웨어하우스(108)는 분산될 수 있음을 인식하여야 한다. 비록 본 발명의 실시예는 서비스가 고객(112a-N)에게 전달되는 메커니즘으로서 단일의 서비스 웨어하우스(108)를 언급하고 있을 지라도, 본 발명에서 청구한 실시예는 이것으로 제한되지 않음을 인식하여야 한다. 예를 들면, 다수의 서비스 웨어하우스(108)가 자주적인 방식 또는 조화된 방식으로 다수의 상이한 서버에서 실행될 수 있다. 하나의 고객은 서비스 웨어하우스(108)의 하나의 인스턴스와 통신할 수 있고, 반면에 다른 고객(112a-N)은 서비스 웨어하우스(108)의 다른 인스턴스와 통신할 수 있다.

이제 도 2를 참조하면, 본 개시내용에 따라서 서비스 웨어하우스(108)가 추가적으로 상세히 설명될 것이다. 서비스 웨어하우스(108)는 고객 포털(208), 객체 전달 인터페이스(212), 객체 생성기(216), 및 객체 서브-컴포넌트 라이브러리 및 레포지토리(220)를 포함한다. 비록 고객 포털(208) 및 객체 전달 인터페이스(212)는 그러하듯이 개별적이고 구별적인 컴포넌트인 것으로 도시되어 있지만, 서비스 웨어하우스(108)의 일부 인스턴스는 고객 포털(208) 및 객체 전달 인터페이스(212)의 양쪽으로서 작용하는 단일의 컴포넌트를 포함할 수도 있다.

고객 포털(208)은 고객(112a-N)에게 이용가능한 서비스를 노출시켜줄 뿐만 아니라 고객(112a-N)으로부터 서비스의 주문을 수신하는 능력을 서비스 웨어하우스(108)에게 제공한다. 일부 실시예에서, 고객 포털(208)은 웹 인터페이스(예를 들면, 고객(112a-N)에게, 예컨대, 마크업 랭귀지를 매개로 제공하도록 구성된 하나 이상의 웹 페이지들), 웹 서버, 웹 서버들의 그룹, 통신 포트, 통신 소켓, 또는 고객(112a-N)으로 하여금 원격으로 서비스 웨어하우스(108)의 콘텐츠를 볼 수 있게 해주는 하드웨어 및/또는 소프트웨어 컴포넌트들의 다른 모든 조합을 포함할 수 있다.

상세히 말해서, 고객 포털(208)은 고객(112a-N)에게 객체 서브-컴포넌트 라이브러리 및 레포지토리(220)의 콘텐츠를 볼 수 있게 해주거나 또는 서브-컴포넌트 라이브러리(224)에 열거되어 있으면서 객체 서브-컴포넌트 라이브러리 및 레포지토리(220)에 저장되어 있는 서브-컴포넌트(228)를 매개로 하여 고객(112a-N)에게 제공될 수 있는 서비스들의 리스트를 보게 해줄 수 있다. 고객 포털(208)을 통하여 고객(112a-N)에게 디스플레이되고, 그래서 고객에 의해 주문받을 수 있는 서비스의 비제한적 일부의 일예는 보이스메일 서비스, 착신호 전환 서비스, 다이나믹 디바이스 페이링 서비스(dynamic device pairing service), 호 라우팅 서비스, 셀룰러 확장 서비스(extension to cellular service), 음성-텍스트 서비스, 텍스트-음성 서비스, 통화 녹음 서비스, 미디어 라이브러리, 대화식 음성 응답 서비스(Interactive Voice Response (IVR) service), 또는 회의 서비스 등과 같은 하나 이상의 통신 서비스를 포함한다.

고객 포털(208)은 고객(112a-N)에게 서비스를 보게 하고 주문할 수 있게 해주지만, 객체 생성기(216)는 서비스 주문을 이행하는 역할을 담당한다. 상세히 말해서, 만일 고객(112a-N)이 특정 서비스 또는 일련의 서비스를 주문하면, 객체 생성기(216)가 작동되어 객체 서브-컴포넌트 라이브러리 및 레포지토리(220)로부터 필요한 서브-컴포넌트들(228)을 모으고 서브-컴포넌트들(228)을 통신 네트워크(104)를 통해 고객(112a-N)에게 바로 전달가능한 객체로 꾸린다. 더 상세히 말해서, 객체 생성기(216)가 서비스의 주문을 수신할 때, 객체 생성기(216)는 주문된 서비스의 형태를 결정하며 또한 그 주문받은 서비스를 주문한 고객에게 제공하기 위해 궁극적으로 어느 서브-컴포넌트(228)가 필요한지 결정하도록 구성된다. 특정 서비스를 특정 고객에게 제공하는데 필요한 서브-컴포넌트(228)의 개수 및 형태는 고객에 의해 사용되는 장비의 형태, 주문받은 서비스의 성질, 주문받은 서비스의 라이센스들의 개수 (예컨대, 고객 사이트에서 얼마나 많은 사용자들이 그 서비스를 사용할 것인지), 및 다수의 다른 요인들에 달려 있을 수 있다.

일부 실시예에서, 객체는 서비스에 대해 하나 이상의 고객별 요청을 수용하기 위해 객체 생성기(216)에 의해 구축된 규칙일 수 있다. 비제한적인 일예로서, 고객이 사용자 포털 서브-컴포넌트, 호-처리 서브-컴포넌트, 관리 또는 시스템 관리 서브-컴포넌트, 및 사용자 인터페이스 서브-컴포넌트와 같은 다수의 서브-컴포넌트를 가질 신규 통신 서비스를 지금 막 주문했다고 가정한다. 이러한 하나 이상의 서브-컴포넌트들은 객체 생성기(216)에 의해 고객화되어 궁국적으로는 각각의 서브-컴포넌트를 실행하고 뿐만 아니라 주문한 고객에 의해 요청된 어느 특별한 요청(예컨대, 언어 요청, 룩-앤-필 요청(look-and-feel requests), 디폴트 룰/선호도 등)을 수용할 특정 버전의 서버들(또는 프로세서들)을 수용할 수 있다. 객체 생성기(216)는 서브-컴포넌트 라이브러리(224)를 조회함으로써 적절한 서브-컴포넌트(228)를 검색할 수 있고, 그 서브-컴포넌트 라이브러리(224)로부터 어느 서브-컴포넌트가 고객에 의해 주문받은 서비스를 적절하게 제공할 것인지 결정할 수 있다.

객체 생성기(216)에 의해 생성될 수 있는 객체(604)의 비제한적인 일예는 도 6에 도시된다. 전술한 바와 같이, 객체 생성기(216)에 의해 생성된 객체(604)는 고객의 장비(customer's premises)에서 각종 상이한 서버들이 주문받은 서비스를 조화된 방식으로 제공하도록 해주는 하나 이상의 서브-컴포넌트들을 포함할 수 있다. 통신 서비스를 전달하는데 사용되는 객체(604)에 포함될 수 있는 서브-컴포넌트의 몇가지 일예는 이것으로 제한하지 않지만, 사용자 포털 서브-컴포넌트(608), 호-처리 서브-컴포넌트(616), 및 시스템 매니저 서브-컴포넌트(620)를 포함한다. 비록 도시되지는 않았지만, 객체(604)는 또한 서비스를 이용하는 고객의 자격(예를 들면, 서비스를 할당받을 수 있는 사용자 수)을 규정하는 라이센스 서브-컴포넌트를 포함할 수 있다. 객체 생성기(216)에 의해 생성된 객체(604)는 또한 따라 왔을 때 서브-컴포넌트를 적절한 장소/서버에 분배함으로써 고객의 장비에서 객체(604)의 성공적인 배치를 가능하게 해주는 배치 명령(612)을 포함할 수 있다.

서브-컴포넌트(228)는 서비스 웨어하우스(108)의 메모리 내에 파일 또는 실행 파일 등으로서 저장될 수 있으며 서브-컴포넌트 라이브러리(224)는 단순히 메모리에 저장된 각종 서브-컴포넌트(228)의 리스트 또는 테이블에 해당할 수 있다. 서브-컴포넌트 라이브러리(224)는 또한 객체 생성기(216)에 의해 사용될 수 있는 링크 또는 어드레스를 제공하여 메모리로부터 해당하는 서브-컴포넌트(228)를 찾고 검색하도록 할 수 있다. 다시 말해서, 서브-컴포넌트 라이브러리(224)는 서브-컴포넌트(228)의 리스트를 포함할 뿐아니라 스토리지 내 서브-컴포넌트의 위치를 찾는데 사용된 인덱싱 메커니즘을 포함할 수 있다.

서비스 웨어하우스(108)의 객체 전달 인터페이스(212)는 객체 생성기(216)에게 통신 네트워크(104)를 통하여 고객에게 객체(604)를 전달하는 기능을 제공한다. 일부 실시예에서, 객체 전달 인터페이스(212)는 고객 포털(208)과 동일한 하드웨어 컴포넌트(예를 들면, 소켓, 포트, 네트워크 인터페이스 카드 등)을 사용할 수 있다. 일부 실시예에서, 객체 전달 인터페이스(212)는 고객 포털(208)과 다르다. 둘 중 어느 한 구현예에서, 객체 전달 인터페이스(212)는 객체 생성기(216)에 의해 생성된 객체(604)를 통신 네트워크(104)를 통해 전달가능한 하나 이상의 통신 패킷 또는 파일로 패키지화 또는 캡슐화하도록 구성될 수 있다. 객체 전달 인터페이스(212)는 또한 객체(604)를 찾아 주문한 고객에게 전송하는 기능을 포함할 수 있다.

이제 도 3을 참조하면, 본 개시내용의 실시예에 따른 예시적인 고객 장비(304)의 추가적인 세부사항이 설명될 것이다. 일부 실시예에서, 고객 장비(304)는 단일의 고객(112)에 의해 소유되고 동작되는 기업 네트워크에 해당할 수 있다. 다시 말해서, 단일의 고객(112)은 소유, 임대 또는 그와 달리 고객 장비(304)의 범주 내에 속하는 통신 기기들의 동작 및/또는 유지보수를 단독으로 관리할 수 있다. 이러한 고객 장비(304)는 보통 기업 네트워크(enterprise network)라고 지칭된다. 기업 네트워크는 분산형(예를 들면, WAN)일 수 있거나 또는 단일의 장소(예를 들면, LAN)로 국한 될 수도 있다. 다른 실시예에서, 다수의 고객(112a-N)이 고객 장비(304)의 일부 또는 모든 컴포넌트를 공유한다.

장비(304)는 기업 네트워크에 해당할 수 있으며, 일부 실시예에서는 서버 테이블(312), 통신 서버(316), 하나 또는 다수의 서비스를 사용자에게 제공할 수 있는 하나 이상의 서버(336) (예를 들면, 애플리케이션 서버, 특징 서버 등), 하나 이상의 내부 통신 기기(348), 데이터 스토어(352), 하나 이상의 사용자 포털 서버(356), 하나 이상의 시스템 매니저 서버(364), 및 하나 또는 다수의 다른 서버(372)를 포함한다. 장비(304)의 일부 또는 모든 컴포넌트는 (신뢰된 또는 안전한 또는 사설) 로컬 에리어 네트워크(LAN)(344)에 의해 상호연결될 수 있다. 도 3에 도시된 일부 또는 모든 기능은 단일 서버에 공통으로 관리 및/또는 공통으로 상주될 수 있다. 도 3에서 컴포넌트들의 묘사 및 본 명세서에서 제공된 다른 도면들은 일반적으로 시스템의 컴포넌트들을 논리적으로 묘사하고자 하는 것이다. 기업 네트워크 또는 다수의 기업 네트워크는 통신 네트워크(104)와 같은 WAN에 연결된 다수의 LAN(344)을 포함할 수 있음을 인식하여야 한다. 단일의 기업 통신 네트워크(304)가 본 명세서에서 쉬운 이해와 간략성을 기하기 위해 도 3에 도시되고 기술되며 어느 방식으로든 본 발명의 실시예를 단일의 통신 네트워크(304)로 제한하려는 것은 아니다.

LAN(344)은 LAN(344)과 통신 네트워크(104) 사이에 배치된 게이트웨이 및/또는 방화벽을 통해 신뢰할 수 없는 상대방에 의한 침입으로부터 보호될 수 있다. 일부 실시예에서, 바운더리 디바이스(308)는 게이트웨이 및/또는 방화벽의 기능을 포함할 수 있다. 일부 실시예에서, 바운더리 디바이스(308)와 통신 네트워크(104) 사이에는 별개의 게이트웨이 또는 방화벽이 제공될 수 있다.

비록 도 3에는 각 서버(예를 들면, 단일의 통신 서버(316), 단일의 애플리케이션 서버(336), 단일의 사용자 포털(356), 및 단일의 시스템 매니저(364)) 마다 단일의 인스턴스만이 도시되어 있을 지라도, 모든 서버 형태의 둘 이상의 인스턴스는 단일의 기업 네트워크(304) 또는 단일 기업에 의해 소유되고 동작되되, 통신 네트워크(104)와는 별개인 다수의 개별 LAN(344) 전체에 제공될 수 있다. 기업 또는 기업 네트워크(304)가 단일 형태의 둘 이상의 서버들(예를 들면, 다수의 통신 서버들)을 포함하는 구성에서, 각각의 서버는 유사한 기능을 포함할 수 있지만, 모든 기업 사용자들 중 일부에만 그의 특징을 제공하기 위해 프로비저닝될 수 있다. 특히, 비제한적인 일예로서, 제1 통신 서버(316)는 기업 사용자들의 제1 부분집합에 대해 권한을 맡고 이들에게 서비스할 수 있는 반면, 제2 통신 서버(316)는 기업 사용자의 제2 부분집합에 대해 권한을 맡고 이들에게 서비스할 수 있으며, 여기서 제1 및 제2 사용자들의 서브집합은 일반적으로 공통 사용자를 배제한다. 이것은 네트워크 바운더리 디바이스(308)가 서버 테이블(312)을 갖고 있을 수 있는 한가지 이유이며, 서버 테이블(312)은 사용자를 이들의 권한을 맡은 통신 서버(316)와 맵핑하는 정보를 포함할 수 있다.

부가적으로, 다수의 서버는 공통 사용자 커뮤니티를 지원할 수 있다. 예를 들면, 사용자들이 반드시 단일의 애플리케이션 서버에 속할 필요없는 지역 중복(geo-redundant) 애플리케이션 또는 기타 애플리케이션에서, 사용자가 클러스터 내 어떤 서버에 의해 서비스받을 수 있는 동등한 서버들의 클러스터일 수 있다.

통신 서버(316)는 사설 구내 교환기(Private Branch eXchange (PBX)), 기업 교환기(enterprise switch), 기업 서버, 서버 내에서 실행된 컴포넌트 또는 애플리케이션, 서버에 의해 제공된 가상 머신, 이들의 조합, 또는 다른 형태의 통신 시스템 스위치 또는 서버를 포함할 수 있다. 일부 실시예에서, 통신 서버(316)는 Avaya라는 회사의 Avaya AuraTM 플랫폼을 통하여 이용가능하게 만들어진, Communication ManagerTM, Avaya Aura Communication ManagerTM, Avaya IP OfficeTM, Communication Manager BranchTM, Session ManagerTM, MultiVantageExpressTM, 및 이들의 조합을 포함하는 한벌의 애플리케이션 및 서비스와 같은 원격통신 기능을 실행할 수 있도록 구성된다.

본 개시내용의 적어도 일부의 실시예에 따르면, 통신 요청 내의 사용자 아이덴티티를 맵핑하는 것은 반드시 네트워크 바운더리 디바이스(308)에서 이루어져야 하는 것은 아니다. 예를 들면, 권한 있는 통신 서버(316)와 사용자 간의 맵핑은 기업 네트워크(304) 내 네트워크 바운더리 디바이스(308)를 "벗어나" 이루어질 수도 있다. 일부 실시예에서, 네트워크 바운더리 디바이스(308)는 SBC(Session Border Controller), 방화벽, 게이트웨이, 또는 보안 및/또는 번역 성능(translation capabilities)을 제공하는 다른 모든 장치와 유사한 기능을 포함할 수 있다.

일부 실시예에서, 네트워크 바운더리 디바이스(308)는 초기에 기업 네트워크(304) 내의 통신물을 통신 세션에 관계된 특정 사용자에게 서비스하는 일을 담당하는 통신 서버(316)에 라우팅하는 일을 담당한다. 예를 들면, 만일 제1 기업 사용자가 외부의 통신 장치에 의해 호출되고 있다면, 네트워크 바운더리 디바이스(308)는 초기에 착신 호(inbound call)를 수신하고, 그 호가 제1 기업 사용자를 향해 전달될지를 결정하고, 서버 테이블(312)을 조회하여 제1 기업 사용자에 대한 권한을 맡은 통신 서버(316)를 식별하고, 착신 호를 권한을 맡은 통신 서버(316)에게 라우트할 수 있다. 마찬가지로, 먼저 내부의 기업 사용자(예를 들면, 내부 통신 기기들(348))는 통신 셋업의 발신 단계 동안 발신 사용자의 권한을 맡은 통신 서버(316)에 의해 서비스받을 수 있다. 발신 단계가 완료된 후, 착신(또는 호출받은) 사용자의 권한을 맡은 통신 서버(316)는 통신 셋업의 착신 단계를 완료하기 위해 작동될 수 있다. 일부의 실시예에서, 발신 및 착신 사용자의 통신 서버(316)는 동일할 수 있지만, 반드시 그럴 필요는 없다. 둘 보다 많은 기업 사용자들이 한 통신 세션에 관계되어 있는 상황에서, 관계된 사용자들 각각의 권한을 맡은 통신 서버(316)는 본 발명의 범주를 일탈함이 없이 사용될 수 있다. 부가적으로, 각각의 사용자에 대한 권한을 맡은 통신 서버(316)는 동일한 기업 네트워크(304) 내에 존재할 수 있거나, 또는 기업에 의해 공통으로 소유되어 있지만 통신 네트워크(104)에 의해 분리되어 있는 상이한 기업 네트워크(304) 내에 존재할 수 있다.

각각의 통신 서버(316)는 서비스 선택기(320), 사용자 선호도(324), 객체 언패커(object unpacker)(328), 및 객체 분배기(332)를 포함할 수 있다. 인식될 수 있는 바와 같이, 통신 서버(316)의 각종 모듈들은 반드시 동일 서버에서 구현될 필요는 없다. 그 대신, 통신 서버(316)의 모듈들은 하나 이상의 상이한 서버들 또는 동일 서버 내 상이한 프로세서들에서 구현될 수 있다.

서비스 선택기(320)는 사용자 요청을 네트워크(304) 내 적절한 서버들(336, 356, 364, 372)에 라우트하는 능력을 통신 서버(316)에게 제공한다. 상세히 말해서, 서비스 선택기(320)는 통신 세션을 개시하라는 요청(예를 들면, SIP 환경에서 INVITE 메시지, HTTP GET 요청, 착신 또는 발신 전화 호, 이메일 메시지, 단문 메시지 서비스(SMS) 메시지 등) 또는 다른 어떤 형태의 정보에 대한 요청(예를 들면, 이를 테면, SUBSCRIBE 메시지를 통한 존재 정보의 요청, 데이터베이스 쿼리 등)을 수신한 것에 응답하여 작동될 수 있다. 일단 작동되면, 서비스 선택기(320)는 사용자 선호도(324)를 조회하여 어느 서버가 다음으로 작동될지를 결정하도록 구성될 수 있다. 예를 들면, 통신 서버(316)는 SIP 메시지를 수신할 수 있고 서비스 선택기(320)는 사용자 선호도(324)를 조회하여 어느 서버(336, 356, 364, 372)가 다음으로 그 SIP 메시지를 수신할지 결정하도록 구성될 수 있다. 보다 상세히 설명하면, 통신 서버(316)는 전체 애플리케이션 시퀀스가 구축될 때 까지 각각의 백-투-백 유저 에이전트(back-to-Back User Agents (B2BUAs))를 애플리케이션 시퀀스에 일대일로 차례로 배열함으로써 통신 세션의 데이터 경로와 미디어 경로 중 적어도 하나의 경로에다 B2BUA 들의 체인을 설정하도록 구성될 수 있다.

통신 서버(316)의 사용자 선호도(324)는 서버가 권한을 맡긴 사용자별 서비스 선호도를 가지고 있다. 통신 서비스의 일예에서, 사용자 선호도(324)는 애플리케이션 서버(336)로부터의 어느 애플리케이션을 특정 사용자의 애플리케이션 시퀀스에 맞추어 작동시켜어야 하는지 규정할 수 있다. 사용자 선호도(324)의 다른 형태는 사용자 인터페이스 선호도, 데이터 검색 선호도, 존재 정보 및 비밀 우선(presence information and privacy preferences) 등을 포함할 수 있다. 일부의 실시예에서, 사용자 선호도(324)는 테이블 형태일 수 있으며 사용자들 및/또는 관리자에 의해 프로비저닝될 수 있다. 특정 사용자의 사용자 선호도(324)는 서비스 선택기(320)에 의해 조회되어, 만약 있다면, 어느 서비스 및 그 서비스의 무슨 컴포넌트(예를 들면, 서브-컴포넌트(340, 360, 368, 376)가 사용자를 위해 작동되어야 하는지 결정한다. 다시 통신 형태의 서비스를 참조하면, 서비스 선택기(320)는 통신 기능을 직접 통신 세션에 제공하거나 셋업 동안 작동되고 통신 세션 동안 사용되는 애플리케이션 시퀀스를 결정하도록 구성될 수 있다.

객체 언패커(328) 및 객체 분배기(332)는 서비스 웨어하우스(108)로부터 수신된 객체들을 처리하는 통신 서버(316)에 의해 사용될 수 있다. 객체 언패커(328) 및 객체 분배기(332)는 반드시 동일한 서버, 이를 테면 통신 서버(316)에 상주할 필요는 없다. 예를 들어, 객체 언패커(328) 및 객체 분배기(332)는 둘 다 시스템 매니저 서버(364)에 상주될 수 있다. 다른 예로서, 객체 분배기(332)는 시스템 매니저 서버(364) 내에 제공될 수 있고, 서브-컴포넌트(예를 들면, 336, 356, 372)를 수신하는 각각의 서버는 자체의 객체 언패커(328)를 가질 수 있다.

일부의 실시예에서, 서비스 웨어하우스(108)가 객체를 발생하여 기업 네트워크(304)에 전송할 때, 바운더리 디바이스(308)는 그 객체를 담고 있는 메시지(들)을 통신 서버(316)에 라우트할 수 있다. 도 6에서 볼 수 있는 것처럼, 객체(604)는 사용자 포털 서브-컴포넌트(608), 한 셋의 배치 명령(612), 호-처리 서브-컴포넌트(616), 및 시스템 매니저 서브-컴포넌트(620)와 같은 구성 요소를 포함할 수 있다. 이들 서브-컴포넌트들은 각기 상이한 서버에 전송되어 실행되도록 특별하게 설계될 수 있다.

따라서, 일단 통신 서버(316)에서 수신되면, 객체 언패커(328)는 객체(604)의 각종 구성요소를 식별하고 객체(604)로부터 이것들을 추출한다. 일부의 실시예에서, 객체(604)의 각각의 서브-컴포넌트는 상이한 파일, 실행 파일(예를 들면, 명령 집합), 파일들의 집합, 또는 실행파일들의 집합에 해당할 수 있다. 객체(604)를 언패킹하는 것은 각각의 서브-컴포넌트에 대응하는 각각의 파일/실행파일을 추출하고 추출된 파일/실행파일을 통신 서버(316) 내 메모리에 일시 저장하는 객체 언패커(328)에 완전히 대응할 수 있다.

객체 언패커(328)는 객체 분배기(332)를 작동시켜서 객체(604)에 포함된 배치 명령(612)에 따라서 각종 서브-컴포넌트들을 적절한 서버들(336, 356, 364, 372)에 분배하도록 할 수 있다. 상세히 말해서, 객체 분배기(332)는 배치 명령(612)를 조회하고 호-처리 서브-컴포넌트(616)를 (예를 들면, 애플리케이션 서브-컴포넌트(340)로서) 애플리케이션 서버(336)에 또는 통신 서버(316)의 다른 부분에 배치되게 할 수 있다. 사용자 포털 서브-컴포넌트(608)는 (예를 들면, 사용자-포털 서브-컴포넌트(360)로서) 사용자 포털(356)에 배치될 수 있다. 시스템 매니저 서브-컴포넌트(620)는 시스템 매니저 서버(364)에 (예를 들면, 시스템 매니저 서브-컴포넌트(368)로서) 배치될 수 있다. 일단 객체 분배기(332)에 의해 배치되면, 지금 배치된 객체(604)의 각각의 서브-컴포넌트는 그의 대응하는 서버에 의해 실행될 수 있다. 일부의 실시예에서, 배치된 서브-컴포넌트들은 서로 협력 작업하여 서비스의 완전한 기능을 제공할 수 있다.

비제한적인 일예로서, 만일 다운로드된 객체(604)가 신규 통신 애플리케이션(예를 들면, 통화 녹음 서비스, 다이나믹 디바이스 페어링 서비스, 착신호 전환 서비스, 보이스메일 서비스, 통화 기록 서비스(call log service), 발신자 표시 서비스(caller identification service), 및 암호화 서비스 등)에 해당하는 경우, 사용자가 통신 세션 중에 그러한 서비스를 필요로 할 때, 사용자는 각각의 서버(316, 336, 356, 364, 372)의 각각의 서브-컴포넌트를 조합하여 실행함으로써 서비스를 제공받을 수 있다. 보다 상세히 말해서, 애플리케이션 서버(336)에 저장되고 애플리케이션 서버에 의해 실행되는 호-처리 컴포넌트(340)는 B2BUA로서 통신 세션으로 차례로 배열되는 서브-컴포넌트일 수 있다. 사용자 포털 서브-컴포넌트(360)는 사용자가 특정 서비스 및 그 서비스에 대한 사용자의 선호도를 검토 및/또는 구성하게 해주고 그 서비스와 관련한 다른 기능들을 (예를 들면, 웹-기반 사용자 인터페이스를 통해) 실행하게 해줄 수 있다. 시스템 매니저 서브-컴포넌트(368)는 사용자 및/또는 시스템 관리자(예를 들면, 네트워크(304)의 관리자)가 그 서비스로의 허가 및/또는 사용자 액세스를 관리하도록 할 수 있다. 사용자-포털 서브-컴포넌트(360)와 마찬가지로, 시스템 매니저 서브-컴포넌트(368)도 역시 웹-기반 사용자 인터페이스 등을 통해 이용가능하게 만들어 질 수 있다.

본 명세서에서 더욱 상세히 기술되는 바와 같이, 비록 객체(604)가 네트워크(304)의 도처(예를 들면, 고객(112))에 배치될 지라도, 어느 사용자가 그 서비스 또는 서비스 버전에 액세스하여 사용하게 허락받는 것을 제한하는 것이 가능할 수 있다. 다시 말해서, 네트워크(304)의 사용자들은 반드시 네트워크(304)에 배치된 모든 서비스를 액세스할 필요는 없으며 일부의 사용자들은 다른 사용자들과 상이한 서비스 또는 서비스 버전에 액세스할 수 있다.

비록 하나의 통신 서버(316), 두개의 애플리케이션 서버(336), 하나의 사용자 포털 서버(356), 및 하나의 시스템 매니저 서버(364) 만이 도시되어 있을 지라도, 본 기술에서 통상의 지식을 가진자들은 한개, 두개, 세개 또는 그 이상의 어느 형태의 서버라도 제공될 수 있음을 인식할 것이며 각각의 서버는 본 명세서에서 기술된 한가지 이상의 기능을 제공하도록 구성될 수 있다.

(예를 들면, 통신 서버(316) 및 애플리케이션 서버(336)를 통하여) 특정한 애플리케이션 시퀀스에 포함될 수 있는 애플리케이션들은 대체로 사용자의 선호도(324)를 수용하고 그에 따라서 통신 서비스를 제공하도록 포함되는 것이 일반적이다. 그러나, 일부의 실시예에서, 사용자 선호도는 시스템 관리자에 의해 사용자를 위해 부여된 서비스들의 범위 내에서만 존재한다는 것을 인식하여야 한다. 또한, 관리자에 의해 할당된 일부 서비스는 사용자 선호도에 의거하여 사용자에 의해 기능이 억제되지 않을 수 있다(예를 들면, 관리자에 의해 사용자에게 할당된 강제 통화 녹음 서비스(mandatory call recording services)는 기능이 억제되지 않을 수 있다).

애플리케이션은 미디어 유형 및 기능 등에 따라 변할 수 있다. 서브-컴포넌트(340)를 매개로 제공될 수 있는 애플리케이션의 예시적인 형태는, 이것으로 제한되지 않지만, EC-500 애플리케이션(EC-500 application), 호 셋업 애플리케이션(call set-up application), 보이스메일 애플리케이션, 이메일 애플리케이션, 보이스 애플리케이션, 비디오 애플리케이션, 텍스트 애플리케이션, 회의 애플리케이션, 통화 녹음 애플리케이션, 통신 기록 서비스, 보안 애플리케이션, 암호화 애플리케이션, 협업 애플리케이션, 화이트보드 애플리케이션(whiteboard application), 모빌리티 애플리케이션(mobility applications), 존재 애플리케이션(presence applications), 미디어 애플리케이션, 메시징 애플리케이션, 브릿징 애플리케이션, 및 통신을 보완해주거나 향상시킬 수 있는 다른 모든 형태의 애플리케이션을 포함할 수 있다. 부가하여, 하나, 둘, 셋 또는 그 이상의 소정 형태의 애플리케이션들은 본 발명의 범주를 일탈함이 없이 단일의 애플리케이션 시퀀스에 포함될 수 있다.

통신 서버(316), 애플리케이션 서버(336), 사용자 포털 서버(356), 및 시스템 매니저 서버(364)는 네트워크(304)에 배치될 수 있는 몇가지 형태의 서버들에만 대응할 수 있다. 다른 서브-컴포넌트 형태들(376)을 포함하는 다른 서버들(372)이 제공될 수 있다. 그러한 서버들(372) 및/또는 서브-컴포넌트 형태(376)의 적절한 일예는, 이것으로 제한하지 않지만, 관리 서버/에이전트, 사용자-프로비저닝된 데이터 스토어(user-provisioned data stores), 서비스 가용성 서버/에이전트(serviceability servers/agents), 미디어 프로세싱 서버/에이전트(media processing servers/agents), 음성 확장성 마크업 랭귀지 스토어(Voice eXtensible Markup Language (VXML) stores), 콘텐트 스토어(content stores), 이메일 서버(email servers), 보이스메일 서버(voicemail servers), 캘린더링 서버(calendaring servers), 회의 서버(conferencing servers), 존재 서버(presence servers), 및 특정 서비스를 클라이언트 기기에 제공하는 것으로 알려진 다른 형태의 서버들을 포함한다. 일부 실시예에서, 다른 서버들(372)도 역시 통신 세션에서 사용하기 위한 하나 이상의 애플리케이션을 제공하는 애플리케이션 서버들(336)이라고 간주될 수 있다.

내부 통신 기기(348)는 내부 통신 기기(348)가 네트워크(304)를 관리하는 기업에 의해 프로비저닝되고 대개의 경우 기업에 소유된다는 것을 제외하고는 네트워크(304) 바깥의 통신 기기들과 유사 또는 동일할 수 있다. 통신 기기들의 예시적인 형태는 이것으로 제한하지 않지만 셀룰러 폰, 스마트폰, 랩톱, 퍼스널 컴퓨터(PCs), 개인 휴대 단말(PDAs), 디지털 폰, 아날로그 폰, 및/또는 다른 모든 형태의 겸용 폰(capable phone), 소프트폰 또는 디지털 텔레폰을 포함한다. 적합한 텔레폰의 일예는 1600 TM, 2400 TM, 4600 TM, 5400 TM, 5600TM, 9600TM, 9620TM, 9630TM, 9640TM, 9640GTM, 9650TM, 9608TM, 9611TM, 9621TM, 9641TM, 및 Quick EditionTM 텔레폰, IP 무선 텔레폰(IP wireless telephones) (이를 테면, Avaya라는 회사의 IP DECT TM 폰), 비디오 폰(이를 테면, Avaya라는 회사의 VideophoneTM), 및 Avaya FlareTM와 같은 소프트폰을 포함한다.

데이터 스토어(352)는 이름, 직위, 전자주소 정보(예를 들면, 전화번호, 이메일 주소, 인스턴트 메시징 핸들(instant messaging handle), 및 내선 직접 통화(direct dial extension) 등), 가입자 교신 리스트(subscriber contact lists) (예를 들면, 교신자 이름 및 전자 주소 정보), 기타 고용인 기록(other employee records), 및 사용자 선호도(324) 등을 포함하도록 구성될 수 있다. 데이터 스토어(352)에 저장된 정보는 다양한 형태의 데이터베이스, 서버 등을 통하여 하나 이상의 서버들(316, 336, 356, 364, 372)에게 이용가능하게 만들어질 수 있다.

도 3에 도시된 각종 서버들 및 컴포넌트들은 개별적으로 (즉, 상이한 서버들에서) 또는 다함께 (즉, 단일의 서버에서) 구현될 수 있다. 특히, 두개 이상으로 도시된 컴포넌트들(예를 들면, 통신 서버(316) 및 애플리케이션 서버(336))는 본 발명의 범주를 일탈함이 없이 단일의 서버에서 구현될 수있다. 그래서, 단일의 기기가 도 3에 개별적으로 도시된 여러 컴포넌트들의 기능을 제공할 수 있다. 다른 예로서, 바운더리 디바이스(308) 및 통신 서버(316)는 단일의 디바이스에서 구현될 수 있다.

도 4에서 보는 바와 같이, 서버에 배치된 특정 서브-컴포넌트(예를 들면, 시스템 매니저 서버(364)에 배치된 시스템 매니저 서브-컴포넌트(368))는 특정 서비스 유형 및 그 서비스 유형의 버전에 해당할 수 있다. 여러 다양한 서비스 형태 또는 해당 서비스 형태의 다양한 버전은 본 개시내용을 일탈함이 없이 단일 서버에 배치될 수 있다. 서비스 형태는 폭넓게 규정(예를 들면, 통신 서비스, 웹 서비스, 미디어 서비스 등)되거나 특정 회사에서 내놓은 특정 제품(예를 들면, Avaya one-X® Communicator, Avaya one-X®Mobile, Avaya IP Office, AvayaLiveTM Connect, Avaya Aura® Conferencing, 연합 메시징(Unified Messaging), Avaya FlareTM Experience, WebExTM 협업 서비스(Collaboration Services), AurixTM 에 의해 제공되는 것과 같은 음성 분석(speech analytics) 또는 데이터 마이닝 서비스(data mining service) 등) 처럼 좁게 규정될 수 있다. 만일 공용 서비스 형태 및 그 서비스 형태의 버전의 서브-컴포넌트들이 다수의 상이한 서버들을 통해 제공되는 경우, 이들 서브-컴포넌트들은 공용 서비스 형태 및 그 서비스 형태의 버전을 끊임없이 제공하는 방식으로 상이한 서버들을 서로 협력하게 할 수 있다. 비록 도시되지 않았지만, 템플레이트(도 7 참조)는 시스템 매니저(364)를 통해 관리될 수 있고 사용자에게 할당될 수 있음을 인식하여야 한다. 이렇게 관리된 템플레이트들은 소정 사용자에게 이용가능한 서비스/버전을 결정하도록 다른 서버들에 의해 액세스될 수 있다.

전술한 바와 같이, 비록 라이센싱 서브-컴포넌트가 도시되지 않았지만, 라이센싱 서브-컴포넌트 역시 아마도 라이센싱 서버에 배치될 수 있다. 그러면 다른 서버(예를 들면, 시스템 매니저(364))는 적절한 라이센스가 확실히 그 서비스의 사용자를 허락하는지 라이센싱 서버를 체크할 수 있다. 이러한 라이센스 정보는 서비스를 템플레이트에 할당할 수 있는 사용자들의 수를 포함할 수도 있으며 시스템 매니저(364)는 라이센싱 서브-컴포넌트에 의해 허용된 것 보다 많은 사용자가 서비스에 할당되지 않게 할 것이다.

도 5는 본 개시내용의 적어도 일부의 실시예에 따른 통신 시스템(500)을 도시한다. 통신 시스템(500)은 다수의 상이한 고객들(508a-N)에게 이용가능하게 만들어진 공유 통신 서비스(shared communication service)(512)를 포함한다. 고객들 중 한 고객(예를 들면, 제3 고객(508c))은 도 3 및 도 4에 도시된 바와 같이 다수의 물리적 서버들이 고객의 장비에 갖추어진 네트워크(304)를 포함할 수 있다. 서버들은 객체(604)로부터 배치된 서브-컴포넌트 형태의 각종 통신 서비스(512)를 포함할 수 있다. 하나 이상의 통신 서비스(512)(또는 다른 모든 형태의 서비스)는 본 발명의 실시예에 따라서 다른 고객들(508a, 508b, 508N)과 공유될 수 있다. 공유 통신 서비스(512)로의 액세스는 고객의 장비에서 단일 기업 또는 고객이 사용자당 서비스로의 액세스를 관리하는 방식으로 허가 템플레이트(도 7 참조)를 사용하여 관리될 수 있다.

도 5는 또한 공유 통신 서비스(512)가 통신 네트워크(504) 내에 (예를 들면, 클라우드 기반 통신 서비스(512)로서) 상주할 수 있음을 도시하고 있다. 클라우드 기반 통신 서비스(512)는 하나의 고객으로부터의 데이터가 부주의하게 다른 고객과 공유되지 않음을 뜻하는 안전한 방식으로 둘 이상의 고객(508)들 사이에서 공유될 수 있다. 이러한 보안은 안전한 또는 기밀을 요하는 데이터를 국부적으로 고객의 장비에서 또는 만일 그 데이터가 공유 서버 또는 데이터 스토어(352)에서 간직된다면 암호화된 형태로 간직함으로써 성취될 수 있다.

다시 도 6을 참조하면, 객체(604)가 다수의 서브-컴포넌트들(608, 616, 620), 및 함께 딸려 왔을 때 또는 객체 분배기(332)에 의해 실행될 때 각종 서브-컴포넌트들(608, 616, 620)이 네트워크(304) 내 상이한 서버들에게 분배되게 하는 일련의 배치 명령(612)을 포함할 수 있는 방법이 이미 설명되었다. 일부 실시예에서, 배치 명령(612)은 고객(112a-N)에 의해 일단 다운로드되면 객체(604)를 배치하는 명령을 포함하는 것 이외에도 객체(604)를 기술한 다른 정보를 포함할 수 있다. 보다 상세히 말해서, 배치 명령(612)은 제품 설명서(product documentation), 사용자 매뉴얼, 관리 매뉴얼, 구성 가이드라인, 및 그 객체를 기술하는 다른 모든 형태의 데이터를 포함할 수 있다. 일부 실시예에서, 배치 명령(612)은 하나 이상의 엔터프라이즈 아카이브(Enterprise Archive (EAR)) 파일 및/또는 웹 애플리케이션 아카이브(Web application Archive (WAR)) 파일의 형태로 제공될 수 있다. 마찬가지로, 서브-컴포넌트들(608, 616, 620)은 또한 하나 이상의 EAR 및/또는 WAR 파일로서 객체(604) 내에 패키지될 수도 있다.

EAR 파일은 단일 서버를 통해 단일 아카이브의 여러 부분들이 배치가 동시에 일관성 있게 배치될 수 있도록 하나 이상의 모듈을 단일의 아카이브로 패키지하기 위한 자바 EE에 의해 사용된 파일 포맷이다. 그래서, 일단 특정 서브-컴포넌트의 EAR 파일이 특정 서버로 향하게 되면(예를 들면, 사용자-포털 서브-컴포넌트(360)가 배치 명령(612)에 따라서 사용자 포털 서버(356)에 배치되면), EAR 파일의 고유 특성은 그 특정 서브-컴포넌트가 끊김없이 특정 서버에 배치되게 해줄 것이다. EAR 파일과 유사하게, WAR 파일은 JavaServer Pages, Java Servlets, Java 클래스(classes), XML 파일, 태그 라이브러리(tag libraries), 정적 웹 페이지(static web pages) (HTML 및 관련 파일들) 및 웹 애플리케이션을 함께 구성하는 다른 소스들의 모음을 분배하는데 사용된 자바 아카이브(Java Archive (JAR)) 파일이다. WAR 파일에 의해 사용된 JAR 파일 포맷은 많은 자바 클래스 파일들 및 연관된 메타데이터 및 자원들을 하나의 파일로 모아서 자바 플랫폼에서 애플리케이션 소트프웨어 또는 라이브러리를 쉽게 분배하도록 하는데 사용된 아카이브 파일 포맷이다.

일부 실시예에서, 객체(604)의 서브-컴포넌트들의 일부는 EAR 파일로서 패키지될 수 있는 반면에 객체(604)의 다른 서브-컴포넌트들은 WAR 파일로서 패키지될 수 있다. 서브-컴포넌트용으로 사용된 파일의 형태는 서브-컴포넌트의 특성 및 궁극적으로 서브-컴포넌트를 수신하여 배치하는 서버의 역량에 따를 것이다. 비제한적인 일예로서, 호-처리 서브-컴포넌트(616) 및 배치 명령은 EAR 파일로서 제공될 수 있는 반면 시스템 매니저 서브-컴포넌트(620) 및 사용자 포털 서브-컴포넌트(608)는 WAR 파일로서 제공될 수 있다.

이제 도 7을 참조하면, 사용자당 서비스로의 액세스 또는 고객당 공유 서비스(512)로의 액세스를 제어하는데 사용될 수 있는 템플레이트(700)가 본 개시내용의 적어도 일부 실시예에 따라서 부가적으로 상세히 기술될 것이다. 비록 템플레이트(700)의 많은 세부사항이 사용자당 서비스로의 액세스를 관리하는 것과 관련하여 기술될 지라도, 사용자당 액세스에 관한 가르침은 고객당 공유 서비스(512)로의 액세스에 용이하게 적용될 수 있다는 것을 인식하여야 한다. 또한, 비록 템플레이트(700)가 특정 구조(예를 들면, 테이블 구조)에 대하여 기술될지라도, 본 개시내용의 실시예는 그것으로 제한되지 않는다는 것을 인식하여야 한다. 보다 상세히 말해서, 어느 형태의 데이터 구조나 데이터 구조의 집합이라도 본 개시내용에서 기술된 템플레이트(700)의 특징을 제공하는데 사용될 수 있다.

템플레이트(700)는 서비스의 최종 사용자 및/또는 시스템 관리자에 의해 프로비저닝될 수 있는 다수의 데이터 필드를 포함할 수 있다. 템플레이트(700)에 포함될 수 있는 데이터 필드의 형태는 이것으로 제한하는 것은 아니지만 사용자 식별자 필드(704) 및 다수의 서비스 식별자 필드(708, 712, 716)를 포함한다.

사용자 식별자 필드(704)는 기업 네트워크 내 특정 사용자를 식별할 수 있다. 예를 들면, 사용자 식별자 필드(704)는 고객(112a-N)의 고용인, 사업의 고객, 사업의 관리자, 고용인들의 그룹, 고객들의 그룹 등을 식별할 수 있다. 사용자 식별자 필드(704)는, 통신 서비스(512)가 다수의 상이한 고객들 사이에서 공유되는 경우, 고객들의 식별자로서 사용될 수 있다. 어떤 길이의 숫자, 문자, 기호, 또는 비트 등이라도 사용자 식별자 필드(704)에 있는 사용자 또는 고객을 특유하게 식별하는데 사용될 수 있다. 사용자를 식별하는데 사용될 수 있는 데이터의 예는 이것으로 제한하지 않지만 이름, 주소, 사회 보장 번호, 사원번호, 직위, 별칭(예를 들면, 어드레스 오브 레코드(Address of Record (AoR)) 등을 포함한다. 고객을 식별하는데 사용될 수 있는 데이터의 예는 이것으로 제한하지 않지만 회사명, 회사 축약어, 상표, 회사 번호 등을 포함한다.

각각의 서비스 식별자 필드(708, 712, 716)는 대응하는 객체(604)가 네트워크(304)에서 다운로드되었고 필요한 서브-컴포넌트들(608, 616, 620)이 네트워크(304) 내 적절한 서버들에게 분배되었다는 사실에 의하여 사용자에게 이용가능해진 상이한 서비스에 해당할 수 있다. 일단 객체(604)가 네트워크(304)에서 다운로드되고 배치되면, 객체(604)에 의해 제공된 서비스를 식별하는 신규 필드가 템플레이트(700)에 추가될 수 있다.

서비스로의 사용자 액세스에 대한 디폴트 설정은 (예를 들면, 배치 명령(612)을 통하여) 다운로드된 객체(604) 내에 규정될 수 있으며/있거나 디폴트 설정은 네트워크(304)의 시스템 관리자에 의해 생성된 룰에 의해 규정될 수 있다. 일예로서, 사용자 액세스에 대한 디폴트 설정은 아무 사용자도 해당 서비스에 액세스를 허락받지 않았다고 규정할 수 있다. 이러한 허가 또는 허가 없음의 표시는 사용자 3에 관한 제1 서비스 식별자 필드(708)에서 식별된 제1 통신 서비스에 대하여 표시된다.

다른 예로서, 서비스 웨어하우스(108)로부터 서비스의 구매자(예를 들면, 네트워크(304)의 관리자)는 초기에 구매 시점에서 사용자가 그 서비스를 사용하도록 허락받을 것을 규정할 수 있다. 서비스 웨어하우스(108)에서 객체 생성기(216)는 구매자의 요청에 따라서 객체(604)를 구축할 수 있다. 특히, 배치 명령(612)은 새로이 생성된 필드가 템플레이트(700)에서 생성될 때, 구매자에 의해 식별된 사용자들만이 서비스에 액세스할 것이다. 다른 사용자들은 모두 그 서비스에 액세스를 허락받지 못할 것이다.

도시된 테이블 구조에서, 사용자의 행과 서비스 형태의 열 간의 교차지점은 사용자가 그 서비스에 대하여 무슨 액세스 허가를 허락받는지를 규정하는데 사용될 수 있다. 이러한 허가는 서비스 형태의 특정 버전에 대해 정적으로 규정될 수 있다. 대안으로, 허가는 사용자가 해당 서비스 형태의 다양한 버전(예를 들면, 버전 X보다 이른 어느 버전)을 액세스하도록 허락받은 것을 규정하는 와일드카드 값을 포함할 수 있다. 대안으로, 허가는 사용자가 특정 서비스의 어느 버전 또는 가장 최근 버전을 액세스하도록 허락하는 값을 포함할 수 있다.

템플레이트(700)를 사용하는 장점은 동일한 기업 및 동일한 네트워크(304) 내 상이한 사용자들이 서비스에 대해 상이한 액세스 허가를 가질 수 있다는 것이다. 도 7의 예에서 볼 수 있는 바와 같이, 사용자 1은 필드(712)에서 식별된 통신 서비스 2의 버전 1.0 으로의 액세스를 허락 받은 반면, 사용자 2는 동일한 통신 서비스의 버전 1.1으로의 액세스를 허락 받는다. 필드(712)에는 또한 사용자들의 그룹 A가 통신 서비스 2로의 어느 액세스도 허락받지 못하지만, 그룹 B는 동일한 통신 서비스의 버전 3.1로의 액세스를 허락받는다. 만일 사용자마다 개별적으로 규정된 허가와 동일 사용자(예를 들면, 사용자 1은 그룹 A의 일원임)에 대해 그룹별로 규정된 허가 사이에서 충돌이 있다면, 허가는 사용자의 개별적으로 규정된 허가에 의해 관리될 수 있다. 그러나, 소정의 충돌을 개별적 허가보다는 그룹 허가에 의해 관리되게 하는 것이 유리할 수 있다.

일부 실시예에서, 템플레이트(700)는 사용자 선호도(324)에 포함될 수 있으며 사용자가 어느 서비스 형태 및 그 서비스 형태의 버전을 액세스하도록 허락받는지 결정할 때 서비스 선택기(320)에 의해 조회될 수 있다. 템플레이트(700)는 사용자 선호도(324)의 일부로서 제공될 수 있지만, 사용자가 템플레이트(700)의 일부 또는 모두에 대해 날짜를 바꾸거나, 편집하거나, 기입하는 것을 제한하는 것이 가능할 수 있다. 다시 말해서, 템플레이트(700)은 사용자 선호도(324)에 포함된다는 바로 그 이유 때문에 전체 템플레이트(700)를 사용자가 편집할 수 있게 만들어주는 것이 반드시 필요한 것은 아니다. 그러나, 사용자로 하여금 네트워크(304) 관리자 또는 서비스의 제공자(예를 들면, 서비스 웨어하우스(108)의 운영자)에 의해 규정된 소정 파라미터 내에서 템플레이트(700)의 일부분을 편집하게 허락하는 것은 가능할 수 있다.

이제 도 8을 참조하면, 본 개시내용의 적어도 일부 실시예에 따라서 서비스에 대해 룰의 계층적 규정 및 변경을 허용하는데 사용된 데이터 구조(800)가 기술될 것이다. 데이터 구조(800)는 템플레이트(700)에 통합될 수 있고 또는 템플레이트(700)와 분리될 수 있다. 예로서, 만일 사용자 1이 데이터 구조(800) 내에 통신 서비스 1에 대한 소정의 룰을 규정하면, 이렇게 사용자-규정된 룰은 사용자 1의 행과 필드(708)의 교차지점에 복사될 수 있다. 대안으로, 사용자 1의 행과 필드(708)의 교차지점으로부터 나온 포인터는 데이터 구조(800)에 있는 대응하는 지점을 가리킬 수 있다. 데이터 구조(800)는 사용자 선호도(324)에 포함될 수 있거나 또는 원격에서 서비스 선택기(320)에 이용가능하게 만들어질 수 있다.

일부 실시예에서, 데이터 구조(800)는 이것이 서비스의 제공자 및 네트워크(304)의 관리자에 의해 계층적으로 규정된 룰의 허가가능 집합 내에 속하는 한 사용자로 하여금 특정 서비스에 대하여 어느 형태의 동작 파라미터, 룰 또는 허가를 규정하게 해주는 계층적으로 구조화된 룰을 포함한다. 상세히 말해서, 데이터 구조(800)는 네트워크(304) 내에서 이용가능한 서비스에 대한 제1 계층의 룰(804), 제2 계층의 룰(808), 제3 계층의 룰(812), 제4 계층의 룰(824) 등을 포함할 수 있다. 일부 실시예에서, 제1 계층의 룰(804)은 특정 서비스에 대한 제공자-규정 룰을 포함하고, 제2 계층의 룰(808)은 그 서비스에 대한 관리자-규정 룰을 포함하고, 제3 계층의 룰(812)은 그 서비스에 대한 사용자-규정 룰(816), 그룹-규정 룰(820), 또는 디폴트 룰(828)을 포함하며, 제4 계층의 룰(824)은 그룹-규정 룰(820) 내의 사용자-규정 룰을 포함한다.

제1 계층의 룰(804)은 하위 계층의 룰에 이용가능한 옵션을 제어할 수 있다. 예로서, 만일 제공자가 특정 서비스가 세가지 형태의 사용자 인터페이스(예를 들면, 웹 인터페이스에 대해 세가지 다른 스킨들) 중 한가지를 가질 수 있다고 규정하면, 관리자, 사용자 및 그룹은 특정 사용자가 그 서비스를 액세스할 때 특정 사용자가 사용할 세가지 인터페이스들 중 어느 것을 고르게 할 수 있다.

제2 계층의 룰(808)은 제1 계층의 룰을 더 세밀히 구분하지만, 제1 계층의 룰(804)보다 넓거나 이를 벗어나 확장될 수 없다. 전술한 예를 계속 적용하면, 관리자는 특정 서비스에 대해 단지 제1 및 제2 형태의 사용자 인터페이스만이 특정 서비스를 위해 사용자에게 이용가능할 것이라고 관리자 룰 내에서 규정할 수 있다. 관리자는 제공자에 의해 규정된 인터페이스 형태를 벗어난 제4 인터페이스 형태를 규정하도록 허용되지 않는다.

제2 계층의 룰(808)과 유사하게, 제3 계층의 룰(812)은 제2 계층의 룰(808) 및 제1 계층의 룰(804)을 더욱 세분화할 수 있지만, 제1 및 제2 계층의 룰(804, 808)보다 확장되거나 이를 벗어나 확장할 수 없다. 인터페이스의 예를 계속 적용하면, 사용자는 특정 서비스를 위해 제1 및 제2 형태의 사용자 인터페이스 사이에서 선택하도록 허락받을 수 있다. 사용자는 이것이 관리자에 의해 제한되었기 때문에 제3 인터페이스를 선택하도록 허락받지 못하며 또한 제공자에 의해 가능하지 못했기 때문에 제4 인터페이스를 선택하도록 허락받지 못한다. 사용자 룰(816)은 서비스를 위해 사용자의 선택을 특별하게 규정할 수 있거나 또는 만일 사용자가 자기의 선택을 규정하지 않았을 경우에는 디폴트 룰(828)을 조회할 수 있다.

사용자 룰(816)과 마찬가지로, 그룹 룰(820) 및 사용자 룰(824)은 사용자 또는 사용자들의 그룹에 의해 사용되어 서비스의 선호도 또는 서비스의 양태를 더 세분화할 수 있다. 데이터 구조(800) 내에서 규정된 룰은 사용자가 어느 인터페이스를 사용하여 서비스를 액세스하는지 규정하는 것으로 제한되지 않는 것을 인식하여야 한다. 데이터 구조(800)의 다른 사용 사례를 제공하기 위하여, 제공자(804)는 다운로드가능한 객체(604)를 통하여 서비스를 고객(112)에게 제공할 수 있다. 서비스는 특정 통신 서비스 형태(예를 들면, 다이나믹 디바이스 페이링(dynamic device pairing), 라우팅 룰, EC500 등)에 해당할 수 있다.

예를 들면, 특정한 통신 서비스 형태가 제1 통신 서비스이고 제1 통신 서비스가 10가지 다른 버전을 가지고 있다고 고려해 본다. 가장 최근의 버전(예를 들면, 버전 9 및 10)은 서비스 제공자에 의해 지원되며 가장 최초의 버전(예를 들면, 버전 1 및 2)은 더이상 서비스 제공자에 의해 지원되지 않는다. 이러한 시나리오에서, 제공자는 서비스의 버전들 3-10만이 이용가능함을 제1 계층의 룰(804) 내에 규정할 수 있다. 이 시나리오를 이어 나가면, 관리자는 모든 사용자들을 위해 버전들 7-9의 구매한 라이센스를 가지고 있을 뿐이며 사용자 1(예를 들면, 테스트 사용자)을 위해서 버전 10의 라이센스를 구매했을 뿐이다. 관리자는 버전 7-9는 네트워크(304)의 모든 사용자에게 이용가능하지만 버전 10은 사용자 1에게만 이용가능하다는 룰(808)의 제 2 계층 내에서 규정할 수 있다. 관리자는 또한 만일 사용자가 자기들의 사용을 위해 (예를 들면, 디폴트 룰(828)을 통해) 서비스 버전을 선택하는 경우에 사용될 서비스의 버전을 규정할 수 있다. 그러면 어느 사용자 또는 사용자 그룹이라도 버전들 7-9 중에서 서비스의 특정 버전을 선택하도록 허락받을 반면 사용자 1은 버전들 7-10 중에서 서비스의 특정 버전을 선택하도록 허락받을 것이다. 이것은 시스템 관리자로 하여금 네트워크(304) 내 모든 사용자를 위한 라이센스를 구매하지 않고도 서비스의 신규 버전을 테스트할 수 있게 한다. 이것은 또한 각각의 사용자가 자기들이 사용하는 서비스의 버전을 선택할 때 약간의 자유를 갖게 된다. 그래서, 얼리 어답터(early adopter) 유형의 사용자는 서비스의 더 새로운 버전을 선택하게 허락받는 반면 레이트 어답터(late adopter) 유형의 사용자는 이들이 익숙해져버린 구 버전을 계속 사용하게 된다.

이제 도 9를 참조하면, 본 개시내용의 적어도 일부 실시예에 따라서 통신 서비스와 같은 서비스에 대해 주문을 수신하고 이행하는 방법이 기술될 것이다. 본 방법은 서비스의 주문이 서비스 웨어하우스(108)에서 수신될 때 시작한다(단계 904). 일부 실시예에서, 서비스의 주문은 고객 포털(208)을 통하여 (예를 들면, 웹-기반 요청으로서) 수신될 수 있다.

그 다음, 객체 생성기(216)는 주문을 분석하여 요청된 서비스의 파라미터를 결정한다(단계 908). 상세히 말해서, 객체 생성기(216)는 무슨 서비스가 요청되었는지, 그 서비스의 어느 버전이 요청되었는지, 그 서비스의 특정 버전을 구축하는데 무슨 서브-컴포넌트들(228)이 필요한지, 구매자의 장비에서 서브-컴포넌트들을 적절하게 분배하는데 무슨 배치 명령(612)이 필요할 것인지, 그 서비스에 대해 얼마나 많은 라이센스들이 구매되었는지, 초기에 어느 사용자가 그 서비스로의 액세스를 허가받을지, 초기에 어느 사용자가 그 서비스로의 액세스를 거절당할지, 그 서비스에 대한 제공자 룰, 및/또는 구매자가 자기들의 장비에서 그 서비스를 지원하는데 무슨 형태의 서버를 가지고 있는지 그 요청의 파라미터로부터 결정할 수 있다. 부가적으로, 일부 실시예에서, 주문은 현재 서비스 및/또는 희망하는 서비스의 하나 이상의 양태를 기술하는 메타데이터를 포함할 수 있다. 예를 들면, 주문은 특정한 기존의 서비스 또는 그 서비스의 컴포넌트들이 소정의 역량, 이를 테면, 높은 가용성(High Availability (HA)) 역량을 가지고 있는지 여부를 기술하는 메타데이터를 포함할 수 있다. 주문에 포함된 메타데이터는 그 서비스를 성공적으로 업데이트하기 위해 어느 형태의 업데이트가 이용가능한지 또는 고객에 의해 요구된 것인지 규정하는데 도움을 줄 수 있다.

주문의 분석에 따라, 객체 생성기(216)는 그 요청의 파라미터에 따라서 다운로드가능한 객체(604)를 준비한다(단계 912). 상세히 말해서, 객체 생성기(216)는 필요한 서브-컴포넌트들(228)을 검색하고 객체(604)를 구축한다. 서브-컴포넌트들(228)은 객체(604) 내에 하나 이상의 EAR 파일 및 WAR 파일로서 패키지될 수 있다. 또한, 배치 명령(612)은 실행 파일, EAR 파일, WAR 파일, 또는 텍스트 파일 등으로서 패키지될 수 있다.

그런 다음 검색된 서브-컴포넌트들은 객체(604) 내에 패키지되고 통신 네트워크(104)를 통하여 구매자/고객(112)에게 전송하기 위해 준비될 수 있다(단계 916). 이 단계에서, 객체 생성기(216)는 객체(604)를 서비스 웨어하우스(108)와 고객(112)과의 사이에서 통신 네트워크(104)에 설정된 통신 채널을 통하여 하나 이상의 패킷으로서 전송되도록 준비할 수 있다. 이것은 객체(604)를 하나 이상의 전자 메시지(예를 들면, 이메일 메시지 또는 SMA 메시지 등)에 첨부하는 것, 또는 객체(604)를 통신 네트워크(104)를 통해 전송할 수 있는 하나 이상의 패킷으로 패킷화하는 것 등을 포함할 수 있다. 객체 생성기(216) 및/또는 객체 전달 인터페이스(212)는 이러한 패키징 단계를 수행할 수 있다.

이후, 다운로드가능한 객체(604)는 객체 전달 인터페이스(212)로부터 통신 네트워크(104)를 통하여 구매자에게 전달된다(단계 920). 전술한 바와 같이, 이러한 전송 단계는 객체(604)의 일부 또는 전부를 포함하는 하나 이상의 전자 메시지 또는 패킷을 전송하는 것을 포함한다.

이제 도 10을 참조하면, 본 개시내용의 실시예에 따라서 다운로드가능한 객체(604)를 배치하고 설치하는 방법이 설명될 것이다. 본 방법은 고객(112)(예를 들면, 하나 이상의 네트워크(104)의 시스템 관리자)이 통신 서비스와 같은 서비스를 받기위해 주문할 때 시작된다(단계 1004). 서비스를 받기 위한 주문 이후, 도 9의 단계들이 수행되며 고객(112)은 다운로드가능한 객체(604)가 네트워크(304)에서 수신될 때 까지 대기한다. 다운로드가능한 객체(604)는 초기에는 바운더리 디바이스(308)에서 수신될 수 있으며 나중에는 초기에 다운로드된 (예를 들면, 통신 서버(316) 또는 어느 다른 서버(372)의 메모리에 영구적으로 또는 일시적으로 저장된) 통신 서버(316)로 라우트될 수 있다(단계 1008).

다음 단계는 객체 언패커(328) 및 객체 분배기(332)가 배치 명령(612)을 분석하여 객체(604)의 내용 및 각각의 서브-컴포넌트가 네트워크(304) 내에서 지향될 곳을 결정한다(단계 1012). 배치 명령(612)에 따라서, 객체(604)의 각종 서브-컴포넌트들(608, 616, 620)이 네트워크(304) 내 이들의 대응하는 서버들(316, 336, 356, 364, 372)에 배치된다(단계 1016). 서브-컴포넌트를 수신하면, 이를 수신한 서버는 서브-컴포넌트를 언팩(예를 들면, EAR 또는 WAR 파일을 언팩)하고 이를 서브-컴포넌트 내에 포함된 명령에 따라서 서버 내에 설치할 것이다(단계 1020). 비제한적인 예로서, 사용자 포털 서브-컴포넌트(608)는 사용자 포털 서버(356)에 배치되어 서브-컴포넌트(360)로서 저장될 수 있고, 호-처리 서브-컴포넌트(616)는 애플리케이션 서버(336)에 배치되어 서브-컴포넌트(340)로서 저장되며, 시스템 매니저 서브-컴포넌트(620)는 시스템 매니저 서버(364)에 배치되어 서브-컴포넌트(368)로서 저장될 것이다.

이제 도 11을 참조하면, 본 개시내용의 실시예에 따라서 다운로드가능한 객체(604)를 고객화하는 방법이 기술될 것이다. 본 방법은 도 10의 방법과 유사하게 고객(112)이 통신 서비스와 같은 서비스를 받기위해 주문하는 것으로 시작한다(단계 1104). 그 다음, 객체 생성기(216)는 통신 서비스에 포함될 디폴트 특징들과 함께 그 서비스를 디폴트 특징들에 따라서 작동시키는 디폴트 룰(828)에 관한 정보를 수신한다(단계 1108). 일부 실시예에서, 디폴트 특징은 한 셋의 기본 룰 및/또는 허용가능한 또는 허용불가능한 사용을 규정하는 일련의 룰을 포함할 수 있다. 또한, 디폴트 특징은 전문화된 서브-컴포넌트가 요청 또는 주문되지 않는 한 어느 서브-컴포넌트들이 서비스 제공을 위해 준비되어 있어야 하는지 규정할 수 있다.

그런 다음, 객체 생성기(216)는 단계(1108)에서 결정된 바와 같은 서비스의 디폴트 특징들을 단계(1104)에서 구매자에 의해 규정된 특징들과 비교하여 이 주문을 위해 고객화된 서비스를 특별하게 생성할지 결정한다(단계 1112). 일부 실시예에서, 구매자는 그 서비스에 대해 어느 특정한 특징들을 규정할 수 없으며, 이러한 경우 디폴트 특징들 및 디폴트 룰들은 객체(604)를 생성하기 위해 사용될 수 있다(단계 1120). 일부 실시예에서, 구매자는 그 서비스의 디폴트 특징들과 다른 그 서비스의 하나 이상의 고객화된 양태를 규정할 수 있고, 또는 구매자는 소정 사용자들이 그 서비스의 디폴트 특징들을 받고 다른 사용자들은 고객화된 특징들을 받는 것을 규정할 수 있다(단계 1116).

구매한 서비스가 하나 이상의 고객화된 특징을 포함하고 있을 때, 객체 생성기(216)는 필요한 서브-컴포넌트들을 검색하고 그 서브-컴포넌트들 자체, 객체(604)의 배치 명령(612), 제공자 룰(804), 및/또는 그 서비스의 디폴트 룰(828)을 변경할 수 있다. 요구한 특징들 및 룰이 선택된 후, 객체 생성기(216)는 선택된 특징들에 따라서 다운로드가능한 객체(604)를 구축할 수 있다(단계 1124).

이제 도 12를 참조하면, 본 개시내용의 실시예에 따라서 시스템 실행 시간 동안 서비스를 배치하는 방법이 기술될 것이다. 비록 본 방법이 통신 서비스와 관련하여 기술될지라도, 본 개시내용의 실시예는 통신 서비스로 제한되지 않으며 웹-기반 서비스, 미디어 서비스, 존재 서비스 등과 같은 모든 형태의 서비스를 실행시간 중에 배치하여 이용될 수 있음을 인식하여야 한다.

본 방법은 신규 서비스가 구매자의 장비(예를 들면, 네트워크(304)의 일부 컴포넌트)에서 수신될 때 시작된다(단계 1204). 객체 언패커(328) 및/또는 객체 분배기(332)는 네트워크(304) 내 어느 엔티티(예를 들면, 사용자)가 그 서비스를 받는지 또는 일단 설치되면 그 서비스로의 액세스를 허락되는지 식별하도록 구성될 수 있다(단계 1208). 서비스의 각종 서브-컴포넌트를 설치하기 전에, 객체 분배기(322)는 어느 식별된 엔티티가 방금 수신한 서비스의 구 버전을 현재 사용하고 있는지 추가적으로 판단할 수 있다(단계 1212). 상세히 말해서, 만일 서비스가 새로이 다운로드된 서비스에 의해 갱신 또는 대체되었다면, 객체 분배기(332)는 그 서비스를 수신하는 것으로 식별되어 정해진 어느 사용자가 현재 그 서비스의 구 버전을 사용하고 있는지 결정할 수 있다.

만일 단계(1212)의 질의의 답변이 아니오라고 결정되면, 본 방법은 객체 분배기(332)가 통상의 방식으로 객체(604)의 서브-컴포넌트들을 분배하도록 진행하며 서브-컴포넌트를 수신한 각각의 서버는 대응하는 서브-컴포넌트를 곧바로 설치하고 설치된 서브-컴포넌트를 요청한 어느 사용자에게 이용가능하게 만들어 준다(단계 1228).

그러나, 단계(1212)의 질의의 답변이 아니오라고 결정되면, 본 방법은 객체 분배기(332)가 서브-컴포넌트들을 적절한 서버에 분배하도록 하는 것을 지속하지만, 추가적인 메커니즘이 작동되어 현재 서비스의 구 버전을 사용하는 사용자(들)가 확실하게 중단되지 않도록 해준다. 상세히 말해서, 객체 분배기(332)는 객체(604)의 각종 서브-컴포넌트들을 서버들에게 분배할 수 있으며 서버들은 신규 서브-컴포넌트들을 설치할 수 있다. 동시에, 현재 구 서비스 버전을 사용하는 사용자들은 이들이 사용을 완료할 때까지 계속하여 서비스를 이용하게 해준다(단계 1216). 이것은 여러 방식으로 성취될 수 있다. 예를 들면, 객체 분배기(332)는 서브-컴포넌트를 수신하는 서버에게 서브-컴포넌트를 다운로드하고 설치하되 그 서비스를 받기 위한 새로운 요청을 위한 서브-컴포넌트만을 사용할 것을 지시할 수 있다(단계 1220). 다시 말해서, 서버가 서브-컴포넌트를 수신하기 전에 수신한 서비스의 요청은 그 서비스의 구 버전(예를 들면, 구 서브-컴포넌트)으로 계속하여 처리될 수 있다.

이것은 또한 구 통신 세션(예를 들면, 객체(604)를 수신하고 다운로드 받기 전에 설정된 세션)과 관련하여 수신한 메시지 및 그 통신 세션을 위해 초기에 작동된 서브-컴포넌트들이 계속하여 서버들에게 라우트되어야 한다는 것을 서비스 선택기(320)에 알려줌으로써 성취될 수 있다. 서비스 선택기는 다만 신규 서비스를 위한 서브-컴포넌트들을 설치한 후에 설정된 통신 세션 동안 신규 서브-컴포넌트들을 작동하도록만 지시받을 수 있다. 이것은 신규 서비스의 서브-컴포넌트들의 다운로드 및 설치 중에 구 서비스 버전이 사용 중이었을 지라도, 구 서비스를 이용하여 완료된 후 사용자들에 의해 신규 서비스가 사용되게 해준다(단계 1224).

더욱 구체적이지만 비제한적인 일예를 제공하기 위하여, 신규 보이스 메일 시스템이 통신 서버(316)에서 수신되며 그 신규 보이스메일 시스템이 구 보이스메일 시스템을 대체하는 것을 고려해 본다. 만일 신규 보이스메일 시스템의 서브-컴포넌트들을 포함하는 객체(604)가 수신되지만 제1 사용자는 현재 구 보이스메일 시스템을 사용하고 있다면, 객체 분배기(332)는 필요한 서브-컴포넌트들이 여전히 해당 서버들에 분배되게 하여 이들 서버에서 설치되게 할 수 있다. 이러한 분배 및 설치는 제1 사용자가 현재 구 보이스메일 시스템을 사용하고 있는 동안 발생할 수 있다. 제2 사용자는 보이스메일 시스템에 접속하려고 하는 한편 제1 사용자는 여전히 구 보이스메일 시스템을 이용하고 있고 서비스 선택기(320)는 제1 사용자가 여전히 구 보이스메일 시스템을 사용하고 있을지라도 제2 사용자를 신규 보이스메일 시스템과 연결시킬 수 있다. 이러한 라우팅은 사용자 선호도(324)를 조회하는 서비스 선택기(320) 및 템플레이트(700)에서 제공된 버전 규정에 기인하여 발생할 수 있다. 이것은 또한 신규 보이스메일 시스템이 설치되고 있던 중에 구 보이스메일 시스템을 사용하지 않은 다른 사용자에게도 발생할 수 있다. 일단 제1 사용자가 구 보이스메일 시스템을 이용한 자신의 세션을 완료하면, 제1 사용자로부터 보이스메일 시스템과 접속하려는 모든 신규 요청은 서비스 선택기(320)에 의해 신규 보이스메일 시스템을 제공하는 서브-컴포넌트들에게 라우트될 것이다. 따라서, 제1 사용자는 신규 보이스메일 시스템의 설치 중에 중단되지 않으며 다른 사용자들은 일단 설치된 이후에는 곧바로 신규 보이스메일 시스템에 액세스하는 것이 가능해진다.

다른 예의 시나리오는 사용자가 서비스의 더 새로운 버전이 설치된 이후에도 동일한 서비스의 구 버전을 계속하여 사용함으로써 발생할 수 있다. 상세히 말해서, 사용자가 더 새로운 버전보다는 구버전을 사용하도록 할당되어 있는 한, 그 사용자는 더 새로운 버전 대신에 구버전을 계속하여 사용할 수 있다.

이제 도 13을 참조하면, 본 개시내용의 실시예에 따라서 서비스를 업그레이드하는 방법이 기술될 것이다. 본 방법은 신규 서비스가 고객의 장비에서 수신될 때 시작한다(단계 1304). 본 방법은 그 다음으로 계속하여, 객체 언패커(328) 및/또는 객체 분배기(332)는 신규 서비스를 수신하는 엔티티를 식별한다(단계 1308). 이 정보는 (예를 들면, 배치 명령(612)을 매개로 하여) 객체(604) 내에 규정될 수 있고 또는 어느 다른 장소에서 (예를 들면, 시스템 매니저 서브-컴포넌트(620) 내에서) 규정될 수 있다. 단계(1308)에서 획득한 정보에 근거하여, 객체 분배기(332)는 템플레이트(700)에 네트워크(304) 내 각종 엔티티들 중에서 신규 서비스를 받기 위한 허가가 규정되도록 템플레이트(700)을 구축하거나 또는 필드를 기존 템플레이트(700)에 추가한다(단계 1312).

템플레이트(700)가 구축 또는 갱신된 후, 객체 분배기(332)는 신규 서비스가 적절한 서버들에게 분배되고 이들 서버들에서 설치되어 신규 서비스가 네트워크(304) 내에서 이용가능하게 만들어지도록 한다(단계 1316). 일단 설치되면, 서비스 선택기(320)는 템플레이트(700) 내에서 규정된 룰 뿐만 아니라 그 서비스를 받기 위한 모든 요청에 대해 사용자 허가를 규정하는 다른 모든 데이터 구조 등에 포함된 룰을 적용/강화할 수 있다(단계 1320). 일예로서, 신규 서비스가 설치된 이후에 그리고 신규 서비스가 통화 기록 서비스, 음성-텍스트 서비스, 대화 분석 서비스 등에 해당할 때 만일 사용자가 외부 통화(outgoing phone call)를 하려고 하면, 서비스 선택기(320)는 그 통화를 개시하는 메시지의 수신 즉시 그 메시지를 하나 이상의 서브-컴포넌트들(340, 360, 376)을 통해 라우트하여 서비스의 신규 버전이 사용자의 외부 통화용으로 사용되게 한다.

시간이 지나면서, 템플레이트(700)는 사용자를 신규 서비스에 추가하고, 사용자를 신규 서비스에서 삭제하고, 그룹을 신규 서비스에 추가하고, 그룹을 신규 서비스에서 삭제하는 등 갱신될 수 있다. 템플레이트(700)에 대한 변경은 시스템 매니저 서브-컴포넌트(368), 사용자 포털 서브-컴포넌트(360), 또는 템플레이트(700)의 검토 및 편집을 가능하게 해주는 네트워크(304) 내 어느 다른 모듈과 상호작용하는 사용자에 의해 시작될 수 있다. 만일 템플레이트(700)에 대한 변경이 요구된다고 결정되면(단계 1324), 시스템 매니저 서브-컴포넌트(368) 및/또는 사용자 포털 서브-컴포넌트(360)는 만일 템플레이트(700)가 통신 서버(316)에서 유지되고 있다면 통신 서버(316)에게 템플레이트(700) 내 해당 필드들을 갱신하라고 지시할 수 있다. 어느 이벤트에서라도, 템플레이트(700)의 관리를 담당하는 서버는 템플레이트를 갱신하여 변경을 반형하도록 지시받을 것이다(단계 1328). 이후, 본 방법은 단계(1324)로 리턴한다.

일부 실시예에서, 바로 단계(1324)로 리턴하기 보다, 삭제(removing)/제거(uninstalling)라는 추가 단계가 수행될 수 있다. 상세히 말해서, 통신 시스템의 모든 사용자가 구 서비스 버전을 바꾼 이후, 구 서비스 버전 및 관계된 모든 서브-컴포넌트들은 이들에 대응하는 서버들로부터 삭제될 수 있다.

일부 실시예에서, 개개의 컴포넌트들은 서비스의 컴포넌트 마다 업그레이드하기 보다 서비스 업그레이드 동안 업그레이드될 수 있다. 상세히 말해서, 만일 오리지널 서비스가 제1 호-처리 컴포넌트, 제1 사용자 포털 컴포넌트 및 제1 라이센싱 컴포넌트(예를 들면, 10 사용자용)를 가지고 있다면, 오리지널 서비스는 오리지널 서비스의 컴포넌트들 중 하나 이상의 컴포넌트들을 완전히 갱신함으로써 업그레이드된 서비스로 업그레이드될 수 있다. 예로써, 만일 사용자가 단지 이들 서비스의 라이센스 부분을 업그레이드하려고 하면, 그 서비스의 어느 다른 컴포넌트를 갱신하지 않고 그 서비스의 라이센싱 컴포넌트를 제2 라이센싱 컴포넌트(예를 들면, 20 사용자용)로 갱신하는 것만이 필요할 수 있다. 서비스의 어느 컴포넌트가 갱신되는지에 따라서, 그 서비스와 연관된 비용을 조절하는 것이 필요할 수 있다.

이제 도 14를 참조하면, 본 개시내용의 실시예에 따라서 계층적으로 서비스의 속성 또는 룰을 구성하는 방법이 기술될 것이다. 일부 실시예에서, 서비스 및 그 서비스를 나타내는 객체(604)가 구축되고 제1 레벨의 속성 허가(804)를 갖는 고객에게 전달된다(단계 1404). 이러한 제1 레벨의 속성 허가(804)는 제공자 룰에 해당할 수 있으며 디폴트 룰 또는 일련의 룰들일 수 있다. 일부 실시예에서, 구매자는 주문 프로세스 동안 제2 레벨의 속성 허가(808)가 객체(604)에 포함되어야 한다는 것을 규정할 수 있다(단계 1408). 대안으로, 또는 그 밖에, 구매자는 객체(604)가 네트워크(304)에서 수신된 후 제2 레벨의 속성 허가(808)를 규정할 수 있다. 제2 레벨의 속성 허가(808)가 규정되는 시가와 무관하게, 제2 레벨의 속성 허가(808)는 데이터 구조(800) 내에서 생성되어 제1 레벨의 속성 허가(804)를 더 세분화 또는 제한한다.

그 다음, 본 방법은 제2 레벨의 속성 허가(808)를 더 제한하기 위하여 더 많은 레벨의 속성 허가가 데이터 구조(800)에 포함될지를 판단한다(단계 1412). 만일 이 질의의 답변이 예라면, 서비스에 대한 다음 레벨의 속성 허가가 규정된다(단계 1416). 단계(1412 및 1416)은 원하는 회수의 계층 레벨이 생성될 때까지 필요한 만큼 반복될 수 있다. 일단 원하는 모든 레벨의 속성 허가가 생성되면, 본 방법은 규정된 레벨에 근거하여 속성들을 계층적으로 주문하는 데이터 구조(800)를 구성한다(단계 1420). 그래서, 제1 레벨의 속성 허가는 속성 허가의 가장 넓은 범위를 (예를 들면, 다양한 허가가능한 속성들 또는 허가가능한 속성들의 리스트로서) 규정하며 그보다 낮은 레벨의 속성 허가는 더 높은 모든 레벨의 속성 허가의 범위 내에서 속성들 또는 룰들을 더 규정한다.

전술한 설명에서, 예시적인 목적을 위하여, 방법들이 특정한 순서로 기술되었다. 대안의 실시예에서, 이 방법들은 기술된 방법과 다른 순서로 수행될 수 있음을 인식하여야 한다. 또한 전술한 발명은 하드웨어 컴포넌트로 수행될 수 있거나 또는 범용 또는 특별 목적 프로세서(GPU 또는 CPU) 또는 명령에 따라 프로그램된 로직 회로(FPGA)와 같은 머신으로 하여금 이 방법들을 수행하도록 하는 일련의 머신-실행가능한 명령으로 구현될 수 있음을 인식하여야 한다. 이러한 머신-실행가능한 명령은 하나 이상의 머신 판독가능 매체, 이를 테면, CD-ROM 또는 다른 형태의 광학 디스크, 플로피 디스켓, ROM, RAM, EPROM, EEPROM, 자기 또는 광학 카드, 플래시 메모리, 또는 전자 명령을 저장하는데 적합한 다른 형태의 머신-판독가능한 매체에 저장될 수 있다. 대안으로, 본 방법들은 하드웨어 및 소프트웨어의 조합에 의해 수행될 수 있다.

실시예의 충분한 이해를 제공하고자 상세한 설명에서 특정한 세부사항이 제시되었다. 그러나, 본 기술에서 통상의 지식을 가진자들이라면 실시예는 그러한 특정 세부사항이 없이도 실시될 수 있음을 이해할 것이다. 예를 들면, 필요없는 세부 사항으로 실시예를 불명료하지 않도록 하기 위하여 블록도에서 회로들이 도시될 수 있다. 다른 예에서, 공지의 회로, 프로세스, 알고리즘, 구조 및 기술이 실시예를 애매하지 않도록 하기 위해 필요없는 세부사항 없이 도시될 수 있다.

또한, 실시예는 플로우차트, 흐름도, 데이터 흐름도, 구조도, 또는 블록도로서 도시된 프로세스로서 기술되었음이 주목된다. 비록 플로우차트가 순서적인 프로세스로서 동작을 기술할 수 있을지라도, 많은 동작이 병행하여 또는 동시적으로 수행될 수 있다. 또한, 동작들의 순서는 재배열될 수 있다. 프로세스는 그의 동작이 완료될 때 종료되지만, 도면에 포함되지 않은 부가적인 단계를 가질 수 있다. 프로세스는 방법, 기능, 절차, 서브루틴, 서브프로그램 등에 해당할 수 있다. 프로세스가 기능에 해당할 때, 프로세스의 끝은 그 기능을 호출 기능 또는 주 기능으로 리턴하는 것에 해당한다.

또한, 실시예들은 하드웨어, 소프트웨어, 팜웨어, 미들웨어, 마이크로코드, 하드웨어 기술 언어, 또는 이들의 모든 조합으로 구현될 수 있다. 소프트웨어, 팜웨어, 미들웨어 또는 마이크로코드로 구현될 때, 필요한 작업을 수행하는 프로그램 코드 또는 코드 세그먼트는 저장 매체와 같은 머신 판독가능 매체에 저장될 수 있다. 프로세서(들)은 필요한 작업을 수행할 수 있다. 코드 세그먼트는 절차, 기능, 서브프로그램, 프로그램, 루틴, 서브루틴, 모듈, 소프트웨어 패키지, 클래스, 또는 명령, 데이터 구조나 프로그램 스테이트먼트의 모든 조합을 나타낼 수 있다. 코드 세그먼트는 정보, 데이터, 아규먼트(arguments), 파라미터, 또는 메모리 내용을 전달 및/또는 수신함으로써 다른 코드 세그먼트 또는 하드웨어 회로와 결합될 수 있다. 정보, 아규먼트, 파라미터, 데이터 등은 메모리 쉐어링, 메시지 전달, 토큰 전달, 네트워크 전송 등을 포함하는 모든 적합한 수단을 매개로 하여 전달, 배달 또는 전송될 수 있다.

본 개시내용의 예시적인 실시예가 본 명세서에서 상세히 기술되었지만, 본 발명의 개념은 다양하게 구체화되고 이용될 수 있으며, 첨부의 특허청구범위는 종래 기술에 의해 제한된 것을 제외하고 그러한 변형을 포함하는 것으로 해석되도록 의도하려는 것은 물론이다.

Claims (10)

1. 다운로드가능한 플러그가능 서비스를 제공하기 위한 방법으로서,
   고객의 통신 시스템에 대한 다운로드가능한 플러그가능 서비스를 획득하기 위한 요청을 상기 고객으로부터 수신하는 단계와,
   상기 요청을 수신한 것에 응답하여, 상기 다운로드가능한 플러그가능 서비스를 준비하는 단계 - 상기 다운로드가능한 플러그가능 서비스를 준비하는 단계는 단일의 객체로 패키지된 제1 서브-컴포넌트 및 제2 서브-컴포넌트를 획득하는 단계를 포함하며, 상기 제1 서브-컴포넌트는 상기 고객의 통신 시스템의 제1 서버를 동작시키는 명령을 포함하며, 상기 제2 서브-컴포넌트는 상기 고객의 통신 시스템의 제2 서버를 동작시키는 명령을 포함함 - 와,
   상기 단일의 객체를 상기 고객에게 전송하는 단계를 포함하는
   다운로드가능한 플러그가능 서비스 제공 방법.
   
2. 제 1 항에 있어서,
   상기 다운로드가능한 플러그가능 서비스는 상기 제1 서브-컴포넌트 및 상기 제2 서브-컴포넌트를 각기 상기 고객의 통신 시스템의 상기 제1 서버 및 상기 제2 서버들에 설치하기 위한 명령을 제공하는 배치 명령(deployment instructions)을 더 포함하는
   다운로드가능한 플러그가능 서비스 제공 방법.
   
3. 제 1 항에 있어서,
   상기 다운로드가능한 플러그가능 서비스를 준비하는 단계는 상기 고객의 통신 시스템에서 상기 다운로드가능한 플러그가능 서비스의 사용을 식별하는 라이센스를 준비하는 단계를 더 포함하며,
   상기 라이센스는 상기 고객의 통신 시스템의 제1 사용자가 상기 다운로드가능한 플러그가능 서비스를 사용하도록 허락받은 것을 표시하며 상기 라이센스는 상기 고객의 통신 시스템의 제2 사용자가 상기 다운로드가능한 플러그가능 서비스를 사용하도록 허락받은 것을 표시하지 않으며, 상기 라이센스는 상기 단일의 객체 내에서 파일로서 상기 다운로드가능한 플러그가능 서비스내에 패키지된 라이센스 파일에 포함되는
   다운로드가능한 플러그가능 서비스 제공 방법.
   
4. 제 1 항에 있어서,
   상기 제1 서브-컴포넌트 및 상기 제2 서브-컴포넌트는 서비스 웨어하우스로부터 검색되며, 상기 서비스 웨어하우스는 상기 고객이 다수의 다운로드가능한 플러그가능 서비스 및 그의 잠재적 서브-컴포넌트들을 브라우저할 수 있게 해주는
   다운로드가능한 플러그가능 서비스 제공 방법.
   
5. 제 1 항에 있어서,
   상기 제1 서버는 애플리케이션 서버에 해당하며 상기 제2 서버는 사용자 포털 서버 및 시스템 매니저 서버 중 적어도 하나에 해당하며, 상기 제1 서버 및 상기 제2 서버는 각기 애플리케이션 컨테이너, 애플릿 컨테이너, 웹 컨테이너, 및 애플리케이션 프로그래밍 인터페이스(Application Programming Interface (API)) 중 적어도 하나를 포함하는
   다운로드가능한 플러그가능 서비스 제공 방법.
   
6. 제 1 항에 있어서,
   상기 제1 서브-컴포넌트 및 상기 제2 서브-컴포넌트는 상기 객체 내에 EAR 파일 또는 WAR 파일 중 적어도 하나로서 패키지되는
   다운로드가능한 플러그가능 서비스 제공 방법.
   
7. 제 1 항에 있어서,
   상기 다운로드가능한 플러그가능 서비스는 실행 파일, EAR 파일 및 WAR 파일 중 적어도 한가지 형태의 배치 명령을 더 포함하며,
   상기 배치 명령은 객체 분배기에 의해 실행될 때, 제1 서브-컴포넌트를 상기 제1 서버에 배치하여 설치되게 하고,
   상기 배치 명령은 상기 객체 분배기에 의해 실행될 때, 상기 제2 서브-컴포넌트를 상기 제2 서버에 배치하여 설치되게 하는
   다운로드가능한 플러그가능 서비스 제공 방법.
   
8. 프로세서-실행가능 명령을 포함하는 비-일시적 컴퓨터-판독가능 매체로서,
   상기 명령은,
   고객의 통신 시스템에 대한 다운로드가능한 플러그가능 서비스를 획득하기 위한 요청을 상기 고객으로부터 수신하고, 상기 요청을 수신한 것에 응답하여, 상기 다운로드가능한 플러그가능 서비스를 준비하도록 구성된 객체 생성기 - 상기 다운로드가능한 플러그가능 서비스를 준비하는 단계는 단일의 객체로 패키지된 제1 서브-컴포넌트 및 제2 서브-컴포넌트를 획득하는 단계를 포함하고, 상기 제1 서브-컴포넌트는 상기 다운로드가능한 플러그가능 서비스가 수행되도록 상기 고객의 통신 시스템의 제1 서버를 동작시키는 명령을 포함하고, 상기 제2 서브-컴포넌트는 상기 다운로드가능한 플러그가능 서비스가 수행되도록 상기 고객의 통신 시스템의 제2 서버를 동작시키는 명령을 포함함 - 와,
   상기 단일의 객체를 통신 네트워크를 통하여 상기 고객에게 전송하도록 구성된 객체 전달 인터페이스를 포함하는
   비-일시적 컴퓨터-판독가능 매체.
   
9. 다운로드가능한 플러그가능 서비스를 제공하기 위한 통신 시스템으로서,
   프로세서 및 메모리 - 상기 메모리는 상기 프로세서에 의해 실행되도록 구성된 명령을 포함함 - 를 포함하는 통신 서버를 포함하며,
   상기 명령은,
   서비스 웨어하우스로부터 단일의 객체를 수신하도록 구성된 객체 언패커 - 상기 단일의 객체는, 상기 통신 시스템 내 서버들 사이에서 분배될 때, 상기 통신 시스템으로 하여금 서비스를 상기 통신 시스템의 사용자들에게 제공하도록 하는 다수의 서브-컴포넌트들을 포함하며, 상기 다수의 서브-컴포넌트들은 상기 단일 객체로 패키지된 제1 서브-컴포넌트 및 제2 서브-컴포넌트를 포함함 - 와,
   상기 단일 객체에 포함된 배치 명령에 따라서 상기 제1 서브-컴포넌트 및 상기 제2 서브-컴포넌트를 상기 통신 시스템 내 상이한 서버들에 분배하도록 구성된 객체 분배기를 포함하는
   다운로드가능한 플러그가능 서비스 제공 통신 시스템.
   
10. 제 9 항에 있어서,
    상기 제1 서브-컴포넌트 및 상기 제2 서브-컴포넌트는 상기 단일 객체 내에 EAR 파일 및 WAR 파일 중 적어도 하나로서 패키지되는
    다운로드가능한 플러그가능 서비스 제공 통신 시스템.

Images