KR19990067327A

KR19990067327A - 통신 네트워크용 서비스 창조 장치

Info

Publication number: KR19990067327A
Application number: KR1019980703327A
Authority: KR
Inventors: 도널드 조지 폴 워터스; 제르미 패비어; 그레험 데이비드 터너; 리차드 데위트 콕스; 앤드류 티모시 헌터; 제프리 케빈 랜드; 니콜라스 던켄 바커 스미스
Original assignee: 내쉬 로저 윌리엄; 브리티쉬 텔리커뮤니케이션즈 파블릭 리미티드 캄퍼니
Priority date: 1995-11-02
Filing date: 1996-11-04
Publication date: 1999-08-16
Also published as: NO981969L; WO1997016929A1; AU721341B2; NO981969D0; EP0858710A1; EP0858710B1; JP2000501252A; NZ320501A; US6338088B1; DE69626127D1; AU7324096A; DE69626127T2; CA2236320A1; CN1214840A

Abstract

본 발명은 통신 네트워크용 서비스 창조 장치에 관한 것으로, 서비스 창조 액티비티가 수행될 수 있는 SCE1, SCE2 및 SCE3 의 3 가지 다른 레벨을 가지는 지능망 타입의 통신망용 서비스 창조 시스템 분리 레벨의 사용은 네트워크내의 여러관심사를 가지고 있는 사용자를 위해 기능적 분리를 유지할 서비스 창조 시스템으로의 액세스를 허용하여 사용할 것으로 선택된 서비스용 네트워크 성분 레벨에서 설치될 특성이 SCE1 내에 만들어질 수 있고, 상기 특성의 지원 및 관리 설명과 함께 통화 처리 로직을 엔캡슐레이트하는 특성의 관점을 주는 시장성있는 서비스 특성은 SCE2 내에서 만들어지고, 서비스 특정 지원 및 관리 정보와 함께 서비스의 요구를 충족시키 시장성있는 서비스의 조합을 허용하는 서비스 패키지는 SCE2 또는 SCE3 중 한 곳에서 만들어질 수 있고, SCE2 에서의 서비스 공급자는 시장성있는 서비스 특성의 주문된 시퀀스를 구비하는 편집 그래프를 창조 및 테스트 하고, 그러면 SCE3 에서 고객이 사용할 수 있게 만들어지고, 사용자를 위한 서비스에 관련된 특성을 목록화 하고 각 특성에 필요한 데이터용 데이터 슬롯을 제공하는 프로파일은 편집 그래프로부터 실행 그래프의 창조에 의해 SCE3 내에서 제공 및 수정될 수 있고, 시장성있는 서비스 특성에 추가하여, 미터특성이 편집 그래프가 있을 수 있는데 이것은 시장성있는 서비스 특성과는 유사하지만 관련된 스크린 정보는 가지고있지 않으며, 이것은 사용자가 흑색 스크린으로 나타나는 것으로부터 실행 그래프를 발생할 수 있게 하지만 실제적으로 상기 미터 특성에 의해 강제적으로 있게되어서 상기 실행 그래프가 테스트된 강제 내부에 있는 것을 보증하는 것을 특징으로 한다.

Description

통신 네트워크용 서비스 창조 장치

본 발명은 통신 네트워크용 서비스 창조 장치에 관한 것으로, 특히 지능망에서 특정 애플리케이션을 찾는 것에 관한 것이다.

통신네트워크가 발달함에 따라, 네트워크 운용자가 전개시킬 수 있는 서비스의 수 및 종류가 크게 증가하고 있다. 네트워크 운용자가 새로운 서비스를 빠르고 효과적으로 만들고 전개시키는 것은 중요한 상업적 이슈이다. 과거에는 이러한 경우에 스위치 또는 교환기에서보다는 통신망에 관련된 또는 통신망 내의 다양성을 공급해온 아키텍쳐의 지능망 형태가 적어도 부분적으로 발전되어 와서 네트워크 운용자에게 빠르고 유연한 새로운 서비스를 공급할 수 있는 능력을 부여하고 있다.

지능망(IN)에서의 주 원칙은 스위치 경로를 설정하는 등의 기본적 스위치 기능을 제어하는 소프트웨어와 통화를 제어하는 소프트웨어를 구분하는 것이다. 도 23을 참고하면, 이러한 것은 네트워크 교환기(230)가 수정된 통화를 요구하는 통화를 인식하고 보통의 통화를 정지시킬 수 있게 하는 것으로 공지된 IN 내에서 얻어왔다. 통화를 정지시키는 결정은 미리 지정된 트리거 기준, 예를들어 다이얼링 디지트, 라인 상태 또는 하루중의 시간, 통화 동안의 어는 지점 등에 기초하여 이루어진다. 이것은 네트워크 교환기(230)에 제공되는 "서비스 스위칭 지점(SSP)" 기능으로 설명될 수 있다.

IN-기반 서비스가 요구되는 통화를 인식하고 나면, 상기 SSP 기능은 서비스 제어 지점(SCP)(231)을 언급하고 그 이후의 통화 진행은 기본 네트워크 교환기(230) 밖의 지능에 의해 제어되어 상기 통화기 요구하는 어떤 서비스도 제공한다.

서비스의 제공 및 수정에 특히 관련되는 지능망 아키텍쳐의 측면은 서비스 창조 및 전개 시스템이다. 그 속성은 어느 IN 내에 특히 관심을 두고 새로운 서비스의 창조를 가속하는 것인데 :

ⅰ 기능적 분리 - 이것은 고객과 서비스 특정 측면으로부터 실시간 통화 교환의 기본 중심 기능의 분리로서, 앞서 언급한 후자가 더 쉽게 변동될 수 있게 하는 것이다.

ⅱ 포터블 소프트웨어 환경 - 서비스가 발전될 수 있게 하여 다른 공급자들이 제공하는 CSP(231) 상에서 동작되게 함

ⅲ 일반적인 빌딩 블럭 - 통상의 모듈로부터의 빌딩 서비스는 상당한 재활용을 허용하여 발전 속도가 있게 된다.

ⅳ 서비스 로직 프로그램(SLP) - 빌딩 블럭 간의 링크를 특정하는 간단한 언어. SLP 는 보통 서비스 창조 툴에 의해 만들어진다.

ⅴ 그래픽 서비스 창조 툴 - 이 툴은 상기 일반적인 빌딩 블럭을 나타내는 아이콘의 '스크린상'의 조작에 의해 서비스가 빠르게 만들어지게 한다.

ⅵ 서비스 및 네트워크 시뮬레이터 - 서비스가 만들어지면, 기능성, 실행성, 가격 등의 검사를 위해 시뮬레이트 될 수 있다.

ⅶ 온-라인 전개 - 서비스가 전개 준비가 되면 상기 서비스 창조 툴로부터 네트워크 및 적절한 관리 시스템으로 전기적으로 전송될 수 있다.

서비스는 일반적인 서비스 블럭을 특정하는 것으로 상기 빌딩 블럭 및 상기 블럭간 어느 상태 링크로부터 서비스 창조 환경(232)의 알려진 타입으로 만들어진다. 이 특정은 보통 스크립트 또는 서비스 로직 프로그램(Service Logic Program : SLP)로 알려져 있으며 일반적으로 서비스 창조 툴에 의해 발생된다. 이 SLP 가 네트워크로 전개되면 '실행'될 필요가 있다. 이것은 보통 상기 SCP(231)내에 놓이는 서비스 로직 실행 환경(Service Logic Execution Environment : SLEE)내에서 행해진다. 이 실행 자체를 행하는 모듈은 보통 서비스 로직 해석기(Service Logic Interpreter : SLI)로 불리는데, 그 이유는 많은 IN 이행이 그들의 SLP 용으로 해석된 언어를 사용하기 때문이다. 이것은 해석기가 있어야 하는 것은 아니지만 예를들어 일반적으로는 서비스 엔진(Service Engine)으로 더 불릴 수 있다. 이것은 해석된 또는 컴파일된, 그리고 SLP 의 다른 형태도 제공하기도 한다.

상기 서비스 창조 툴과 함께, 재사용이 가능한 일반적인 빌딩 블럭의 사용은 서비스 창조에 중요하다. 컴퓨팅의 일반적 세계에서는, 이익이 남기 때문에 우수한 소프트웨어를 구하고자 하는 많은 노력이 계속되어 오고 있다. 예를들어, 프로그램을 세 번 재사용하는 것은 효과적인 세 번의 생산인 것이고 더욱이 두번째 및 그 다음번에 사용되고, 리드 시간(lead time)은 이상적으로는 제로가 될 수 있다.

이러한 이익에도 불구하고, 일반적인 소프트웨어의 재사용은 이상화가 어렵기 때문에 여전히 매우 드물다. 그러나, 상기 SCP 의 상당히 폐쇄된 도메인 내부에는, 기반 네트워크의 분리 동작은 잘 이해되는 것이며, 이러한 기반 동작을 구동하기 위한 소프트웨어의 일반적인 부분들을 세우는 것이 가능하다. 이것들은 IN 서비스의 다양한 범위를 제공하기 위해 많은 다른 시퀀스들내에서 호출될 수 있는 빌딩 블럭이다.

일반적인 빌딩 블럭은 "하루 경로의 시간"일 수 있다. 이 빌딩 블럭은 오후 6시 이후의 특정 번호에 대한 통화가 야간-감시원에게 인식되는 것을 언급하기도 하는 사용자 프로파일 내의 데이터를 검사할 수 있다. 그러면 상기 "하루 경로의 시간" 빌딩 블럭은 현지 시간을 검사하여 상기 통화에게 적절한 경로설정을 해준다.

SLP 는 서비스 관리 시스템(Service Management System : SMS)(233)을 통해 상기 SLEE 로 전달될 수 있다. 이것은 보통 서비스 관리, 전개 및 사용자의 설비 그리고 상기 SCP 및 서비스 데이터 지점(Service Data Point : SDP)(234)상에 유지되는 사용자 특정 데이터를 업데이트하는 책임이 있다.

서비스 창조는 네트워크 서비스 공급자 뿐만아니라 가입자 또는 사용자 자신들에 의해서도 수행될 수 있는 것이 좋다. 여러 엔티티에게 서비스를 개발 또는 수정할 수 있게 하는 서비스 창조 테크놀러지는 엠 제이 모르간(M J Morgan) 등이 미국 뉴욕 AT&T Technical Journal 1991년 여름 70권 3/4호로 출판된 "Service Creation Technologies for the Intelligent Network" 에 기재되어 있다.

본 발명의 실시예에서는, 통신 서비스가 코드의 유닛의 주문된 시퀀스의 스크린-기반 조작에 의해 만들어지거나 또는 수정될 수 있는 통신 네트워크용 서비스 창조 및 제공 시스템을 공급하는데, 상기 시스템은 실행 그래프에 따라 코드의 유닛의 주문된 시퀀스 등을 실행시킴으로서 서비스를 제공하며, 상기 시스템은 :

ⅰ) 코드의 저장된 유닛으로의 인터페이스;

ⅱ) 상기 저장으로부터 코드의 유닛의 설정을 선택하는 수단;

ⅲ) 편집 그래프를 창조 또는 수정하는 수단, 상기 편집 그래프는 통신 서비스 공급용 코드의 유닛의 설정에 관련된 주문된 시퀀스를 적어도 부분적으로 결정하고;

ⅳ) 편집 그래프를 상기 편집 그래프를 편집 또는 수정하는 그래픽 유저 인터페이스 상의 사용자에 의해 사용하는데 시각적인 정보에 관련되게 하는 수단, 및 상기 시각적 정보와 함께 상기 편집 그래프를 그래픽 유저 인터페이스에 공급하는 수단을 구비하고,

상기 시각적 정보와 함께 상기 편집 그래프를 공급하는 수단은 상기 편집 그래프가 사용자에게 보이지 않거나 또는 단지 부분적으로만 보이지 않은 것 없이 그래프 실행이 상기 편집 그래프로부터 만들어질 수 있도록 시각적 정보 없이 적어도 하나의 그래프를 공급하는데 적합한 것을 특징으로 한다.

그러면 실행 그래프는 서비스 공급내의 서비스 로직 프로그램을 가동시켜 시스템의 서비스 엔진에 의해 사용된다.

본 발명의 실시예는 세 레벨 서비스 창조 환경의 공지된 타입 등의 다중-레벨 서비스 창조 환경에 특히 유용하다. 각 레벨은 다른 기능 및 사용자의 여러 설정의 사용에 맞게 제공하는데, 예를들어 네트워크로 코드의 설치 유닛을 위한 네트워크 공급자용, 그리고 그들의 사용자를 위한 실제 서비스의 창조, 수정 또는 설명을 하기 위한 사용자용 등이다.

이 레벨들은 SCE1, SCE2 및 SCE3 등으로 고안되기도 한다. 상기 분리 레벨의 사용은 상기 서비스 창조 시스템으로의 액세스가 네트워크 내의 다양한 흥미를 가지는 사용자를 위한 기능적 분리를 유지하게 한다. 따라서, 선택된 서비스에 맞는 네트워크 성분 레벨에서 설채되어야 할 특성은 SCE1 내에 만들어지는 것이 이용가능하다. 특성의 공급 및 관리 기재사항과 함께 통화 처리 로직을 엔캡슐레이트 하는 특성의 관점을 주는 시장성있는 서비스 특성은 SCE2 내에 만들어질 수 있다. 서비스-특정 공급 및 관리 정보와 함께 시장성있는 서비스 특성의 수집이 서비스의 요구를 충족하게 하는 서비스 패키지들은 SCE2 또는 SCE3 중 하나에 만들어질 수 있다. 사용자를 위한 서비스에 관한 특성을 목록으로 하고 및 각 특성에 필요한 데이터를 위한 데이터를 공급하는 프로파일은 SCE3 내에서 제공 및 수정될 수 있다.

따라서, 본 발명의 적절한 실시예에서, 상기 레벨 각 각에는 소프트웨어 엔티티의 각 각의 다른 타입을 발생시키는 수단이 있는데, 서비스 분배 시스템에 의해 네트워크의 성분내에 전개될 수 있는 코드 대상을 구비하는 서비스 애플리케이션 특성을 발생시키는 수단을 가지고 있는 제1 레벨, 및 그 특성을 위한 공급 및 관리 세부사항으로 캡슐레이티드 된 서비스 애플리케이션 특성의 통화-처리 로직을 구비하는 시장성있는 서비스 특성을 발생시키는 수단이 있는 제2 레벨이 있다.

상기 제2 레벨은 서비스 패키지를 저장 및 출력하는 수단을 가지는 것이 유리할 수 있는데, 이것은 시장성있는 서비스를 통신망에 의해 사용가능한 특정 서비스에 인식하고 관련시키는 관련 기능을 가지는 소프트웨어 엔티티이다.

제3 레벨에는 또한 서비스 패키지를 발생하는 수단도 있고 그리고 프로파일을 발생 또는 수정하는 수단도 있는데 이 프로파일은 사용자가 네트워크의 서비스를 선택하는 필요의 하나 이상의 특성의 리스트로 구성되어 있고, 그리고 상기 특성은 선택된 서비스의 내용을 충분히 운용할 수 있도록 각 특성에 관련되는 데이터를 저장하는 수단이 있다.

이러한 타입의 다중-레벨의 더 다른 장점은 제어 메카니즘의 변동이 제공될 수 있다는 것이다. 예를들어, 설비의 SCE2 에서 제어가 실행될 수 있고, 메카니즘 또는 유사한 것이 SCE3 에서 사용자의 운용에 사용될 수 있다. 이것은 본 발명의 실시예에서 편집 그래프가 SCE2 에서 만들어지거나 수정될 수 있고 실행 그래프를 발생시키는 고객에 의한 사용을 위해 SCE3 로 공급될 수 있는 특정 애플리케이션이 있는 곳이다. 심지어 편집 그래프의 선택된 측면을 숨기는 경우에도, 고객에게 발생을 막는 숨겨진 또는 부분적으로 숨겨진 편집 그래프의 사용으로 인해 구성이 있게되어 통신 서비스의 시험되지 않은 버전을 동작시키게 되는 광범위한 재량을 줄 수 도 있다.

본 발명의 한 실시예에 따른 서비스 창조 시스템을 첨부한 도면을 참고하여 단지 예의 방법으로 설명하도록 하겠다.

도 1은 본 서비스 창조 아키텍쳐의 개략도;

도 2는 도 1의 아키텍쳐에 관련되는 서비스 창조 도메인 및 프로세스 관계를 보여주는 도;

도 3은 서비스 운반 기반구조 및 일반적인 지능망 성분상의 다른 플랫폼과의 관계를 보여주는 도;

도 4는 도 1의 아키텍쳐내에서 사용을 위한 개략적인 서비스 창조 데이터 아키텍쳐를 보여주는 도;

도 5는 시스템-광역 성분으로부터 대상의 타입, 시장성있는 서비스 특성의 구조를 개략적으로 보여주는 도;

도 6은 여러 프로파일 타입을 보여주는 도로서, 프로파일은 특정 서비스를 위해 사용자가 가지고 있는 특성의 사용자-관련 리스트이고;

도 7 내지 도 18은 작업스트링 및 이와 관련된 아키텍쳐 액티비티의 예를 보여주는 도;

도 19 내지 도 22는 도 1의 서비스 창조 아키텍쳐가 공급하게되는 특정 데이터 분배 시나리오를 보여주는 도;

도 23은 IN 아키텍쳐의 알려진 타입의 개략적 다이어그램;

도 24는 특정 서비스를 구성하는데 사용을 위한 편집 그래프의 예;

도 25는 도 24의 편집 그래프와 관련된 실행 그래프의 예;

도 26은 도 24의 편집 그래프내의 유연성있는 포인트(248)의 결과로서 실행 그래프내에서 일어나는 결정 포인트를 보여주는 도;

도 27은 관련된 편집 그래프의 유연성있는 포인트에 관련하여 실행 그래프를위한 옳은 그리고 올바르지 못한 결정 포인트를 보여주는 도;

도 28은 편집 그래프의 사용자의 논리적 뷰(logical view)을 보여주는 도;

도 29는 도 28의 논리적 뷰에 관련된 사용자의 스크린을 보여주는 도; 및

도 30은 편집 그래프로부터 실행 그래프의 발생동안 사용자가 볼 수 있는 스크린 실행을 보여주는 도이다.

아래의 설명에서는, 많은 약어가 성분, 프로세스 및 이에 유사한 모든 제목에 관련하여 사용되고 있다. 이 약어들은 아래의 용어해설로 번역될 수 있다:

용어해설

API 애플리케이션 프로그래밍 인터페이스

CM 구성 관리

CPE 고객 댁내 장비

Foo 컴퓨팅 기술에서 컴퓨팅 기능의 일반적인 표현으로 알려진 용어

GSC 일반적인 서비스 성분

IN 지능망

IVRU 상호 음성 응답 유닛

KTN 네트워크로의 키

MSF 시장성있는 서비스 특성

SAF 서비스 애플리케이션 특성

SAP 음성 애플리케이션 플랫폼

SCE 서비스 창조 환경

SCP 서비스 제어 포인트

SDS 서비스 분배 시스템

SLA 서비스 레벨 동의

SLEE 서비스 로직 실행 환경

SM 서비스 관리

SN 서비스 노드

SP 서비스 패키지

1. 개 요

1.1 스코프(Scope)

아래 설명의 스코프는 서비스 창조 요구가 지능망상에서 운반될 수 있는 논리적 아키텍쳐를 정의하는 서비스 창조의 영역을 어드레스 한다.

실제 사용을 위해 구성된 어느 서비스 관리 시스템은 본 명세서에 기술된 것보다 훨씬 큰 스코프 및 부담을 가질 수 있게 된다는 것을 주목하라. 그러나, 서비스 관리 시스템은 본 발명의 목적을 위해 알려져 있는 것이고 단지 설명된 서비스 창조 아키텍쳐와의 호환이 필요할 뿐이다. 따라서 모든 서비스 관리 시스템을 완전하고 정화갛게 설명하는 것이 본 명세서의 목적이 아니다.

이 서비스 창조 아키텍쳐를 뒷받침하는 데이터 아키텍쳐는 제 5 절에서 설명한다. 그러나, 이 데이터 아키텍쳐의 전개 및 아이디어는 데이터 분배의 수행에 관한 특정 인터페이스(3.1) 상승 이슈에 숨겨져 있다. 이 이슈의 논의는 제 7 절에서 다룬다.

1.2 터미놀로지(Terminology)

본 설명을 위해 고객이라는 용어는 서비스 능력의 구입에 관련된 구매자를 언급하는 것이다. 사용자라는 용어는 상기 고객에 의해 제공된 서비스 능력을 가지는 고객의 개개의 고용인을 의미하는 것이다. 따라서 사용자는 고객에 속한다.

본 설명을 위해서SCE1,SCE2및SCE3라는 용어는 이후 설명될 것이다. 이들은 여러 아키텍쳐 레벨에서 서비스 창조 능력을 제공하는 집적 소프트웨어 툴세트를 설명하는데 사용된다.

IN 성분이라는 용어는 서비스 제어 포인트(SCP), 서비스 노드(SN) 및 지능 주변장치(IP) 등의 플랫폼을 컴퓨팅하는 지능망을 언급하는 논리적 그룹으로 사용된다. IN 아키텍쳐의 여러 타입내에 사용된 플랫폼을 컴퓨팅한다는 것을 이해해야 하는데, 예를들어 분배된 프로세싱 플랫폼을 포함하여 SCP 에 기초한 IN 내에서보다 덜 중심화되는 지능이 "IN 성분" 용어로도 포함된다.

1.3 목적

본 설명의 목적은 다음과 같다:

· 서비스 창조 아키텍쳐의 전범위 정의

· 물리적 시스템에 의해 충분히 공급되는 논리적 시스템 디자인의 고-레벨 뷰의 특성

· 서비스 창조 엔티티(예를들어 시장가능성 있는 서비스 특성, 일반적인 서비스 성분 등)의 식별 및 설명

· 인터페이스 식별

· 작업 패키지 및 애플리케이션 엔티티 식별

· 서비스 창조를 대형 스케일의 공중망으로 이동시키는 서비스 창조용 기초선 아키텍쳐의 정의.

2. 서비스 창조 아키텍쳐 개요

2.1 개요 설명

서비스 창조 아키텍쳐의 개요는 자동적 처리 및 인터페이스를 사용하여 새로운 서비스 및 특성이 빠르게 전개되고 공급되기도 하도록 현존하는 또는 제안된 엔티티 사이에 존재를 이해하는 관계에 의해 정의된다. 이 관계를 설명하기 위해 도 1을 참고하여 서비스 창조 절차를 설명할 필요가 있다.

서비스 애플리케이션 및 재사용가능한 특성들은 검사된 코드로서 SCE1(265a)에서 발전된다. 이 코드는 타겟이 된 IN 성분들(102)(SCP(231), SN, IP(235) 등)상으로 (인터페이스 I5 를 통해) 상기 코드를 저장하고 전개시키는 저장소로서 서비스 분배 시스템(SDS)(100)으로 (인터페이스 I1 을 통해) 운반된다.

SCE2(265b)는 상기 SDS 저장소(100)를 사용하여 (인터페이스 I2 를 통해) 시장성있는 서비스 특성(§5.2 참조) 및 서비스 패키지(§5.3 참조)를 세운다.

서비스 패키지는 상기 서비스 관리 도메인(270) 내의 (인터페이스 I6 을 통해) 상기 SDS 저장소(100)로부터 서비스 관리 기능(SM)(103)로 운반되고 공급을 위해 (인터페이스 I4 를 통해) SCE3(256c)로 운반된다.

서비스 패키지 또는 그의 일부는 (인터페이스 I7 을 통해) 지원 시스템(Support System) 으로 운반되어 새로운 서비스를 위해 구성된다.

인증을 위해 (인터페이스 I3 를 통해) SM(103)으로 운반된 프로파일(§5.4 참조)를 만드는데 SCE3(256c)가 사용된다.

인증된 프로파일은 (인터페이스 I6 을 통해) SDS(100)을 지나고 (인터페이스 I5 를 통해) 관련되는 IN 성분(102)으로 분배된다.

인증된 프로파일 업데이트를 지원하기위해 인터페이스(I4)도 필요하다. 이것은 네트워크-측 업데이트로 더 알려져 있다. 그러나, 이러한 아키텍쳐하에서는 프로파일 업데이트의 모든 형태가 SCE(265c)로부터 나온다는 것이 강조되어야 한다. 따라서 IN 성분(102) 또는 고객 댁내 장치(CPE) 내부의 서비스 내에 존재하는 어떠한 업데이트 능력은 SCE3 능력(아래 "2.2 b 강제" 참조)으로 인식된다.

2.2 강제(Constraints)

a) 네트워크 운용자의 서비스 관리 시스템(270)은 별개의 플랫폼으로서 또는 플랫폼의 범위를 넘어 분배하는 것 중 어느 하나로 존재하게 된다.

b) SCE3(256c)는 서비스 관리 시스템(270)의 일부로서 조합된 서비스 관리 시스템(270)과 직접 인터페이스되는 별개의 물리적 시스템으로서 또는 네트워크-측 업데이트를 지원하는 네크워크 성분 내부의 능력 중 하나로 능력을 제공한다. 대형 네크워트에는 이러한 모든 것을 위해 SCE3(256c)필요할지도 모른다. SCE3 사용자들은 보통 네트워크 운용자의 지원자, 고객 및 사용자로 이루어지게 될 것이다.

c) SDS(100)(§4.4.2 참조)는 서비스 관리 시스템(270)의 부분인 또는 분리 플랫폼을 필요로하는 저장소 및 분배 시스템, 분배 가능성 있는 시스템을 나타낸다. 이것은 타켓 네트워크의 크기 및 수행능력 및 그 네트워크 실행에 관련되어 요구되는 비용에 따라 달라지는 것이다.

d) IN 성분(102)은 서비스 제어 포인트(SCP)(231), 서비스 노드(SN)(도시하지 않음) 및 서비스 애플래케이션 및 관련된 고객 데이터저장을 지원할 수 있는 지능 주변장치(IP)(235) 등의 네트워크-기반 컴퓨팅 설비들로 이루어진다.

e) 인터페이스 및 관리 시스템은 완전히 자동적인 서비스 전개 및 일반적인 시스템 이상의 예비를 공급하게 된다.

3. 서비스 창조 아키텍쳐

도 2는 상기 서비스 창조 아키텍쳐의 보다 자세한 표현을 보여주고 있다. 이 다이어그램은 음성-기반 서비스의 발전에 관련된 주 서브시스템의 주 기능 영역과 주 서브 시스템의 위치간의 관계를 설명하고 있다. 진행 화살표가 있는 인터페이스는 도 1에 도시된 인터페이스 및 §3.1 내의 리스트된 인터페이스(인터페이스 I7 제외)에 해당한다. 도메인 내부의 처리 사이의 라인을 연결하는 것은 소프트웨어 엔티티간의 어떠한 집적 형태를 나타낸다. 이것은 인터페이스의 형태, 파일 전송, 내부처리 통신 또는 애플리케이션 집적(내부 데이터 공유)이 될 수 있다.

이 아키텍쳐는 도메인의 형태로 표현되고 시스템 이상을 처리한다. 비록 서비스 창조 도메인(260)이 세 개의 SCE 도메인(265), 서비스 관리 도메인(270) 및 IN 성분 도메인(200)의 다섯개로 나뉘어 있지만, 이들 도메인 내부에 있는 상기 처리는 플랫폼 및 환경의 범위에서 운용된다.

세 개의 SCE 도메인(265a,265b,265c)은 만족되어야 하는 여러 요구사항과 사용 및 사용자 타입 사이를 구분하기 위해 논리적으로 분리되어 있다. 이것은 다음으로 분류될 수 있다:

도메인	사용자	이 용
SCE1 265a	서비스 공급자 개발자	IN 성분(102)내의 전개를 위한 코 드 레벨에서 애플리케이션 및 특 성의 개발
SCE2 265b	서비스 공급자 개발자 서비스 공급자 마케팅 서비스 공급자 검사	마케팅 요구를 충족시키기 위한 재사용가능한 성분들로부터 생산 및 서비스 개발. 프로토타입 서비스의 시뮬레이션 및 분석. 서비스 운반 전에 고객 특정 변 경.
SCE3 265c	서비스 공급자 개발자 서비스 공급자 지원 운용자 서비스 고객 사용자

3.1 인터페이스

인터페이스 번호(도 1 및 2 참조)	인터페이스 이름	인터페이스 설명
I1	SCE1-SDS I/F(코드)	SCE1(265a)에서부터 SDS(100)까지 애플리케이션, 서비스 애플리케이션 특성 및 일반적인 서비스 성분의 전개를 가능하게 하고 IN 성분(102)으로 진행하는 SDS (100) 와 SCE1(265a)사이의 데이터 인터페이스
I2	SCE2-SDS I/F(시장성있는 서비스 특성/서비스 패키지)	SDS(100) 와 SCE2(265b) 간의 양방향 데이터 인터페이스. SCE2가 SDS 저장소(100)으로부터 SAF /GSC 능력을 픽업하고 이 정보에 기초하여 MSFs,MFs 및 SPs 를 개발함. MSFs 및 MFs 는 SCE2 (265b)로부터 SDS(100)상에 저장된다. 서비스 패키지들은 그들이 저장되고 적절한 IN 성분(102)상에서 전개된 SCE2(265b)로부터 SDS(100)로 운반됨.
I3	SCE3-SM I/F(프로파일)	네트워크-기반 서비스의 운영에 필요한 사용자/고객 데이터의 예비 및 변경이 가능하도록 하는 SCE3(265c) 와 SM(103)사이의 데이터 인터페이스. 또한 고객이 SM 예비 스크린을 구동할 수 있게하는 그래픽적인 단말 에뮬레이션도 포함될 수 있음. 데이터는 프로파일 또는 프로파일 업데이트 형식내에서 통과되는데 분포되기 전에 SM(103)에 의해 타당성 검사가 있어야 함.

I4	SDS-SCE3 I/F(서비스 패키지/프로파일)	새로운 서비스를 설명하기 위해 SCE3(265c)로 서비스 패키지를 운반하고 SCE3 (265c)로부터 프로파일 업데이트(SM 타당성검사 불필요)를 받는 양-방향 데이터 인터페이스. 추가로, 새로운 SAFs 가 이 인터페이스를 통해 SCE3(265c)로 운반되어 예비 타당성 검사 및 SCE3 시뮬레이션 능력을 지원하게 됨.
I5	SDS-IN 성분 I/F(프로파일/코드)	애플리케이션 및 특성의 전개 및 분포가 가능하도록 하고 예비 데이터를 업데이트 하는 SDS(100) 과 IN 성분(102) 사이의 양방향 데이터 인터페이스. 서비스 데이터는 프로파일 및 프로파일 업데이트의 형태로 지나감. 전개는 서비스 패키지의 분포에 의해 얻어짐.
I6	SM-SDS I/F(프로파일/서비스 패키지)	IN 성분(102)로 분산을 위해 예비이고 업데이트된 고객 데이터를 운반하기 위한 SM(103) 에서 SDS(100) 까지의 양-방향 데이터 인터페이스. 데이터는 프로파일 및 프로파일 업데이트 형태로 지나감. SM(103)은 SDS(100)로부터 전개가 있으면 서비스 패키지의 수신도 함.
I7	SDS-지원 시스템	서비스 분포 시스템(10)과 요금청구, 폴트제어 같은 하나 이상의 지원 시스템간의 논리적 그룹핑 인터페이스. 이 인터페이스는 특정 디자인에 의해 결정된 인터페이스의 범위에 의해 실현될 수 있음. 이 인터페이스를 지나가는 데이터는 유연성, 구성가능성 및 이러한 지원 시스템(101)의 "서비스 창출성"에 의해 결정될 것임. 이 인터페이스의 제어 및 특정은 상기 서비스 창출 도메인(260) 내부에 있지 않음.

4. 도메인 설명

다양한 도메인인 도 2에 도시되어 있고 도 3 및 도 4 뿐만 아니라 이를 참고하여 제 4 절을 읽어야 한다.

4.1. SCE1 도메인 265a

SCE1 은 서비스 창출 액티비티의 기본 계층(fundamental layer)을 나타낸다. SCE1 개발자들은 IN 성분(102) 상의 서비스 애플리케이션의 개발의 책임이 있고 이 애플리케이션으로의 서비스 운반 기반구조(300)가 전개되는 것이다. 서비스 애플리케이션은 재사용가능한 서비스 애플리케이션 특성(401)의 형태로 운반된다. 이것은 완전히 개발되고 검사된 코드로 구성되어 있다.

4.1.1 상업적 소프트웨어 개발 환경 280

이 시스템은 개발 라이프사이클을 지원하기 위한 소프트웨어 툴의 집적화된 조합을 나타낸다. 이 툴들은 주로 상업적으로 사용가능한 편집기, 컴파일러, 구성 관리 시스템, 분석, 디자인, 테스트 및 문서화 툴이 된다. 이것들은 일반적으로 종래의 컴퓨터-보조 소프트웨어 엔지니어링(CASE) 툴에 기초한다. 이러한 개발 환경중 일부는 특정 IN 성분(102)상에서의 개발을 지원하기 위해 벤더(vendor)들에 의해 지원된다. 반드시 SCE1(265a)는 다이내믹 전기를 지원하기 위한 전개/테스팅 툴의 집적을 제공해야 한다.

객체 시스템으로의 다운-로딩(down-loading) 실제 빌딩블럭에 추가하여, SCE1 툴은 상기 빌딩블럭의 표현을 SCE2 도메인(265b)로 통과시키기도 할 것이다. 이 표현은 다음을 포함한다:

· 정보 목적을 위해 그리고 도움말 텍스트로서 상기 블럭의 문자적인 설명

· 스크린상의 표현, 즉 상기 기능을 개략적으로 표현하는 아이콘

· 다른 빌딩블럭과의 인터렉션의 규칙 통제

· 상기 빌딩블럭과 관련된 데이터. 이것은 특정 고객용으로 제공될 필요가 있는 것이다.

4.1.2 음성 애플리케이션 툴세트 281

음성-기반 대화 특성 및 서비스의 구성을 지원하는 소프트웨어 개발 툴. 이 툴들은 보통 IN 성분(102)로 기대되는 객체 플랫폼으로 특정되고 상기 플랫폼으로 구입되기도 하며 특정 플랫폼을 지원하기 위해 내부적으로 개발되기도 한다.

4.1.3 멀티미디어 툴 282

분명히, 멀티미디어 서비스의 제공을 지원하기 위해서는, 이미지, 영상 및 특성 팩스 능력의 지원이 필요하고 또한 적절한 서비스 창조 툴 및 유틸리티들이 이들을 지원하는데 필요하다.

4.2 SCE2 도메인 265b

SCE2(265b)는 마케팅(Marketing), 테스팅(Testing) 및 패키징(Packaging) 액티비티로 정의될 수 있다. SCE2(265b) 내부에 있는 이 특정 스코프 및 액티비티의 범위는 수정될 수 있긴 하지만 상기 서비스 창조 절차를 지원할 필요가 있다는 것은 분명하다.

SCE2(265b) 에서의 툴(284,285,286,287)이 생산라인 개발자 또는 그들의 의뢰인에 의해 사용될 것이고 다음의 전 기능을 필요로 할 것이다:

· 스크린상으로 아이콘을 드래그 앤드 드롭 하고 이들을 링크시키는 것에 의한 기본적 서비스 어셈블.

· 얼마나 많은 서비스 흐름이 SCE 레벨 3, 즉 고객에 의해서 변경될 수 있는지를 정의함. 그러면 이 서비스의 나머지는 모든 고객을 위해 효과적으로 고정된다.

· 디폴트 값으로 상기 서비스에 관련된 데이터의 일부를 사전-설정하고 여기서 고객이 엔캡슐레이트가 허용되는 지를 다시 정의함.

4.2.1 요구 지원 툴세트 285

이것은 마케팅 요구 획득을 자동적으로 하고 이들은 서비스 정의로 맵(map)하는 것이 요구된다. 이것은 상기 개발 라이프사이클 전체를 통한 보다 효과적인 재사용을 할 수 있게 한다. SCE2(265b)는 이러한 요구 획득 액티비티를 지원하기 위해 자동화 툴을 사용한다.

4.2.2 패키징 및 시각화 툴 286

서비스 애플리케이션 특성(401)은 라이브 네트워크(live network)내의 특성의 예비 및 사용을 지원하는데 필요한 서비스 관리, 네트워크 관리, SDS 및 요금청구 성분(407)을 포함하는 시장성있는 서비스 특성(403)(§5.2 참조)에 관련되는 것은 SCE2(265b)에 있다. SCE2(265b)에서 MSFs(403) 및 MFs(406)이 만들어진다. 시장성있는 서비스 특성(403) 및 미터특성(406)도 서비스 패키지(404)로 패키지 된다. SCE2(265b)는 서비스 패키지(404) 내부에 엔캡슐레이트된 MSFs(403)상에서의 SM(103) 또는 SCE3 를 위한 예비 스크린을 창조 또는 수정할 수 있고, 서비스 패키지(404) 내부에 엔캡슐레이트된 MSFs(403) 및 MFs(406) 상에서의 사용을 위한 예비 스크린을 창조 또는 정의할 수 있고, 서비스 레벨 동의에 의해 특정된 이용/과금 특징들을 식별하며 특성 인터랙션을 해결하는 SCE3 용 특성 편집기 규칙을 제공한다. 이 측면에서는 SCE2 에서의 상기 서비스 패키지(404)는 그들을 사용하는 SCE3 절차의 구성을 제어하게 됨을 주목해야 한다.

4.2.3 시뮬레이션 및 분석 284

SCE2(265b)에서 만들어진 서비스 패키지(404)는 행동 특성, 트래픽 로딩, 수행능력 및 수입 예상이 만들어져서 이 레벨에서 만들어진 서비스의 고객 획득, 네트워크 임팩트 및 경제적 생존성을 결정할 수 있도록 시뮬레이트 될 수 있을 것이 요구된다.

4.2.4 대화 구성기 287

SCE 사용자는 서비스 패키지(404)내에 포함되는 서비스 또는 고객-특정 대화 및 발표를 구성할 수 있어야 한다. 이것은 MSFs(403) 내부의 재사용가능한 발표/대화의 서비스-레벨 예비에 의해 구성될 것이다. 이 대화 구성 툴들은 입력 메카니즘(아날로그 및 디지털)의 범위 및 저장기 포멧(IN 성분)의 다양성을 지원할 수 있어야 한다. 이 툴들에는 재사용가능한 단편들로부터 음성 발표의 구성을 위한 복잡한 편집 및 신호 처리 기능을 지원하는 것이 필요하기도 하다.

4.2.5 SCE2 데이터저장기 288

작업을 유지하는 국부적 데이터저장기가 진행된다. SAFs(401), MSFs(403), MFs(406) 및 서비스 패키지(404)에 관련된 모든 마스터 데이터(master data)는 SDS 데이터저장기(296) 내에 유지되고 SCE2 사용자에 의해 검색된다.

4.3 SCE3 도메인 265c

SCE3 액티비티는 예비 및 변경에 직접 연관이 있다. SCE3 에 두 개의 별개의 예비 타입을 볼 수 있는데: 행동 및 데이터 예비가 그것이다. 행동 예비는 서비스의 논리적 운용내의 변경을 효과적으로 하게되는 방법인 상기 서비스 데이터의 조작이다. 데이터 예비는 예비의 고전적 인식 타입으로 보통 서비스 관리 시스템에 의해 취해져서 특정 특성 및 사용자에 관련된 데이터가 바로 변경될 수 있고 네트워크는 적절히 업데이트된다.

그러므로 SCE3 에서의 툴들은 고객(또는 사용자)이 직접 사용하게 되고, 특정 고객을 대신하여 행동하는 네트워크 운용자가 사용하거나 또는 고객 또는 사용자의 그룹을 대신하여 행동은 마케팅 사람들이 사용하게 된다. 이러한 다양한 시나리오를 지원하기 위해, SCE3 기능은 개인용 컴퓨터(PC)에서부터 복잡한 Unix 워크스테이션에 이르기까지의 하드웨어 범위에서 제공될 수 있다.

SCE3 도메인(265c)를 통해 지원되는 일반적인 기능들은 다음과 같다:

· 서비스 변경 - SCE2 에서의 구성 세트 내부에서, 고객 또는 사용자는 서비스의 그들의 특정 레벨의 흐름 또는 구성을 변경할 수 있게 된다.

· 고객 특정 값을 가지고 서비스 데이터의 일부를 제공함

4.3.1 프로파일링 편집기 290

고객은 제공되면 완전하고 전체적이 특성의 서비스의 동작을 보장받는 최소 프로파일을 나타내는 서비스 탬플릿(405)를 참조하는 서비스 패키지(404)를 가지게 된다. 고객은 그들의 사용자의 필요에 따라 이 마스터 템플릿으로부터 서브-템플릿의 체계를 창조할 수 있다. 제공된 툴은 SCE2(265b)에서 특정된 상기 특성 편집기 규칙(앞 참조)에 의해 설정된 구성 내부에서 액세스되는 특성 및 이 특성들의 상호작용 방법을 가지는 사용자 그룹을 고객이 특정하는 것을 허용한다. 상기 프로파일링 편집기는 앞서 설명한 구성하에서, SCE3 사용자가 서비스 내부의 그들의 특성의 논리적 주문을 볼 수 있게 하고 그 시퀀스를 그래픽적으로 수정할 수 있게 한다. 고객은 특정 프로파일을 창조 및 할당할 수 있어서 특성을 개개의 사용자에게 설정할 수 있다.

4.3.2 시뮬레이터 291

프로파일 편집기(290)를 지원하는 것은 고객에게 그들의 서비스의 흐름을 보게하고 그들의 행동을 검증하게 하는 시뮬레이션 툴세트(291)이다. 고객은 자신들이 요구한 서비스가 논리적으로 옳은 서비스인지를 평가할 수 있는 통화 시나리오 범위를 그래픽적으로 시뮬레이트할 기회를 가지게 된다.

4.3.3 예비 툴 293

고객은 개발되어온 템플릿에 기초하여 각 사용자 개인용 예비 프로파일을 가질 수 있다. 사용자 레벨에서, 각 사용자는 그들 자신의 프로파일로 직접 또는 고객에 제공한 원격 지원 형태를 통해 액세스하게 된다. 이것은 프로파일을 업데이트하게 하는 적절한 예비 스크린이 있는 자신들의 특성 조합상의 뷰(view)인데, 단지 액세스 혀용 및 서비스 제공자(네트워크 보호 이슈용) 또는 고객(이들이 무엇을 선택하느냐에 따라) 중 하나에 의해서 구성된다.

4.3.4 발표 변경 292

예비 툴(293)과 협동하는 발표 변경 툴(292)이 사용되어 이를 지원하는 특성 또는 서비스의 국부적으로 개인화하는 일부 레벨을 공급하는데 사용되기도 한다. 그러한 예로서 음성 메뉴 특성용으로 협력 또는 부분적 발표 또는 개인 통화 완성 서비스(음성 메일 등)용의 목적에 맞는 메시지의 선택이다. 이러한 툴들은 미리한정된 메시지의 설정을 위한 선택 시스템으로 동작하기도 하고 심지어 대화식 목소리 및 음성 애플리케이션 플랫폼 등의 특정화된 네트워크 플랫폼내의 전개용 음성의 국부적 기록도 가능하다.

4.3.5 SCE3 데이터저장기 294

국부적 안정된 저장기. 서비스 패키지(404)의 수신으로 SCE3(265c) 를 받아들이고 구성한다. 템플릿 체계 및 불완전 프로파일의 국부적 저장을 위해 사용된다. 현재 고객의 프로파일의 국부적 저장(제 7 절 참조)을 하는데 사용되기도 한다.

4.4 서비스 관리 도메인 270

4.4.1 서비스 관리 시스템 103

이 아키텍쳐에서는 프로파일의 예비 및 변경보다 영역 내의 고객 서비스를 관리하고 지원하는데 서비스 관리 시스템(103)이 요구된다. 이 서비스 관리 시스템은 주문 처리, 서비스 레벨 동의 시행 및 서비스 제어(서비스를 가능하게하고, 지속시키고 그리고 철회함)를 책임진다. 또한, 지원 시스템(101)으로의 논리적 인터페이스는 폴트 관리, 요금부과, 가격책정, 네트워크 관리, 성분 관리 및 데이터 분배 등이 이 시스템을 통해 시각적이 되고, 구성되며 제어되도록 상기 서비스 관리 시스템(103)을 통해 잘 처리되어진다.

4.4.2 서비스 분배 시스템 100

서비스 분배 시스템(SDS)(100)은 서비스 창조 저장소처럼 동작한다. 이것은 SCE1 이 운반한 모든 코드를 저장하고 관리하고 설치 및 전개를 위해 적절한 IN 성분(102)로 이를 분배한다. 이 시스템은 시장성있는 서비스 특성(MSFs)(403) 및 MFs(406)이 이것들 및 다른 빌딩 블럭으로부터 개발될 수 있도록 (SAFs/GSCs의 현태 내의) 네트워크 능력 정보를 SCE2 로 사용가능하게 만든다. SDS 는 또한 이러한 MSFs(403) 및 MFs(406) 그리고 그들로부터 구성되는 서비스 패키지를 위한 저장소로서 동작하기도 한다. 이것은 SCE2(265b)의 여러 예들이 앞서 개발된 성분에 대해 최대의 재사용성을 갖게 하여 확실한 개발 시간의 단축이 있게한다.

데이터 분배기(SDS)(100)가 네트워크 토폴로지에 따라 IN 성분(102)로 프로파일을 운반함에 따라 고객 분배 구성은 서비스 또는 네트워크 관리 등의 운용 시스템으로 전용된다. 상기 SDS(100)에서 사용가능한 상기 구성 데이터는 물리적 네트워크와 상기 논리적 서비스 네트워크(306)를 나눈다. 이 방법에서 추가의 네트워크 스위칭 또는 제어 능력이 서비스 관리 시스템상의 전체 업데이트 및 재예비를 필요하지 않으면서 안내될 수 있다.

SDS(100)는 네트워크-측 업데이트를 서비스하는데 중요 역할을 수행하는데, SCE3 시스템은 데이터 분배를 위해 IN 성분(102)로 레지스터될 수 있다. 그리고 네트워크-측 업데이트는 어느 IN 성분(102)에도 적용될 수 있고 SDS(100)는 모든 종속 시스템이 프로파일 업데이트를 수신하는 것을 보장한다. 이것은 개발자들이 현재의 데이터를 네트워크를 통해 공통 인터페이스로 존재하게 한다. 이러한 아키텍쳐 결정의 결과로 SCE3 고객은 프로파일을 업데이트 할 수 있고 네트워크로부터 업데이트된 잔류 프로파일 데이터를 가지고 있게된다. 이것은 서비스 애플리케이션이 CPE(고객 댁내 장치)로부터 네트워크-측 업데이트 기능을 필요로 하는 곳마다 SCE3 능력을 가지는 IN 성분(102)으로서 해석된다.

SDS(100)는 IN 성분을 위한 통계학적 마스터 저장소(296)을 유지하게 지원한다. 이 데이터저장소(296)는 모든 프로파일이 다시세워질 수 있고 IN 성분(102) 내부의 데이터 중단 또는 손실이 있는경우 다시 준비될 수 있도록 충분한 데이터를 포함하게 된다.

4.4.3 SDS 데이터저장기 296

이 SDS 데이터저장기는 상기 네트워크 마스터 프로파일 저장기를 포함하는 영구적 저장장치 애플리케이션이다. 또한, 이 저장기는 IN 성분(102)에 관련된 네트워크 구성 및 데이터 그리고 이 IN 성분(102)상의 고객 분배를 포함하고 있다. 모든 프로파일 데이터 업데이트는 이곳에서 이루어지고 SDS(100)는 IN 성분(102)으로는 하향 분배하고 종속 SCE3 데이터저장기(294)로는 상향 분배한다. 서비스 창조 저장소와 같이 상기 SDS 데이터저장기(296)가 SCE1 에의해 전개된 모든 코드를 포함함으로서 SCE2(265b)로부터의 모든 MSFs, MFs 및 SPs 는 구성 관리 제어하에서 SCE2 의 예로부터 액세스 가능하게 되어 신속한 서비스 창조 및 구성 재사용 능력을 제공하게 된다. 이러한 배열로 자연적으로 데이터저장기 애플리케이션 및 SDS(100)가 있는 플랫폼 모두에서 수행능력 및 디멘존 연관이 있게된다.

4.4.4 구성 관리 297

구성 관리 시스템(297)은 상기 SDS 데이터저장기(296)의 저장 기능을 관리하는데 필요하다. 모든 네트워크-전개된 코드를 위한 중앙 저장소와 같이, 시장성있는 서비스 특성(403), 미터특성(406) 및 서비스 패키지(404)는 네트워크 운용 사람들 뿐만아니라 SCE1 및 SCE2 에서의 서비스 창조자들이 되돌림 보안만을 위해서 전개된 서비스 및 특성의 모든 버젼을 액세스하는 것이 필수적이다. 이것은 서비스 및 특성들이 여러 소스로부터 다이내믹하게 개발될 경우 특히 중요하며, 잘 알려진 소프트웨어 개발의 최선책인 것이다.

구성 관리 시스템이 SCE 도메인(265)(특히 SCE1 및 SCE2) 내부에 있기도 하여 국부적 "진행 작업"의 관리 제어를 유지하고 관리를 세우고 버리는 일을 하는 것이 인식되어진다. 그러나 이러한 시스템은 네트워크 CM 제어를 유지하는 부담을 수행하는 것을 기대할 수 는 없다. 일단 코드, 애플리케이션, 서비스 및 특성들이 라이브 네트워크상으로 전개되고 나면, 이들은 운용 도메인상으로 이동하고 논리적으로는 제어의 분리 시스템하에서 나와야 한다.

고객 데이터가 SCE3 및 서비스 관리 시스템으로부터 되돌아올 수 있도록 프로파일의 버젼 관리 제어를 유지시키는 SDS 구성 관리 시스템(297)의 능력은 선택사항이다. 서비스 관리 시스템이 이 능력을 제공하는 것이 한 대안이다.

4.5 IN 성분 도메인 200

4.5.1 서비스 운반 기반구조 300

본 명세서에서 기술된 그 IN 성분(102) 강제하에서 디자인되어온 상기 서비스 창조 아키텍쳐는 빠른 서비스 창조 및 전개 액티비티, 즉 다이내믹 특성 전개용 옳바른 능력, 플랫폼 종속 및 IN 성분(102)상에 존재하는 특성 상호작용을 공급하는 것을 지원하는 내부 수행이 있다. 서비스 운반 기반구조(SDI)(300)는 이러한 사항들 및 빠른 서비스 창조를 위해 보다 상세한 요구를 충족시키는 수행을 위한 디자인이다. 이것이 정보를 위해 본 명세서에서 언급되면서, 아키텍쳐적으로 종속 엔티티로 언급하지는 않았다. 특정 지능 주변장치들 같은 네트워크 엔티티들은 호스트 SDI 는 아니지만 이 아키텍쳐의 내용 내부의 서비스 창조 액티비티를 여전히 지원해야 한다.

SDI(300)는 서비스 애플리케이션(271)의 네트워크 및 벤더-특정 상호작용을 엔캡슐레이트하고 빼내기 위해 디자인 되어왔다. 이것은 서비스 애플리케이션(271) 및 특성들이 전개되는 목적-발신 구조를 제공한다. 서비스 관리, 네트워크 관리, 요금부과, 폴트 관리 및 통화 모델 등의 인터페이스들은 서비스를 지원하기위해 존재하는 어느 전송 및 관리 시스템으로부터의 애플리케이션을 분리하면서 목적 내부에서 엔캡슐레이트 된다. SDI(300)의 목적은

* 기초 물리적 네트워크

* 분산 서비스 네트워크

* 특정 서비스 네트워크로 구성될 사용가능한 서비스, 및

* 특성 서비스를 세우는데 사용가능한 특성 및 일반적 능력간의 분리를 명확히 하는 것이다.

기반구조로부터 서비스를 분리하는 주 목적은 다이내믹하게 확장가능한 환경을 제공하고 특성이 풍부한 서비스가 상기 환경의 다른 서비스 또는 부분상에 손상 없이 매우 짧은 시간 프레임내에 안내될 수 있게 하는 것이다.

앞서 기술된 SDI 는 본 출원과 동시 계류중인 브리티쉬 텔레커뮤니테이션즈 피엘시 명의의 국제특허출원 GB95/00420 및 GB95/00421 의 주제이고, 이 특허출원에 개시된 내용은 본 출원에서 사용되기도 하는 서비스 운반 기반구조의 예로서 참고된다.

도 3은 SDI(300)의 형태 및 전형적인 IN 성분(102)상의 다른 플랫폼 성분간의 관계를 나타내고 있다. SLEE 애플리케이션 프로그래밍 인터페이스(API)상의 기능 호출에 의해 종래로 동작된 외부 시스템으로의 인터페이스는 이 시스템의 목적 표현(301-305)내에 엔캡슐레이트된다.

서비스는 보통 고객당 하나기 되는 서비스 네트워크(306)의 내용 내로 운반된다. 각 서비스 네트워크(306)에는 서비스 및 가상 네트워크 번호의 고객의 다이얼링 계획을 나타내는 번호 디렉토리(308) 사이를 분별하는 서비스 디렉토리(307)가 있다. 각 서비스 네트워크(306)는 서비스 애플리케이션 특성(401) 및 일반적인 서비스 성분(402)으로부터 구성된 서비스의 범위를 지원할 수 있다.

4.5.2 음성 응답 애플리케이션 299

많은 발표, 대화 및 메시징 서비스가 특별한 플랫폼에의해 제공될 것이라는 것이 예견된다. 이러한 플랫폼들은 지능 주변장치처럼 주 통화 제어 프로세서와 상호작용을 한다. SDI(300) 내부의 애플리케이션(299)은 이러한 IP 설비를 사용할 수 있어서 복잡한 음성-기반 서비스를 제공한다. 이러한 설비를 제공하는 애플리케이션은 SDI(300)으로부터의 요구를 서비스하기 위해 개발될 것이다. 이러한 애플리케이션들은 앞서 설명된 모든 레벨에서의 서비스 창조 및 예비를 허용하도록 디자인될 것이다. 이러한 음성 응답 애플리케이션(299)이 모든 통화 제어 기능을 책임져야할 필요는 없다.

5. 서비스 창조 데이터 아키텍쳐

도 4를 참고하면, 서비스 창조 아키텍쳐 하부의 상기 데이터 아키텍쳐는 세 개의 SCE 도메인(265)를 반영한다. 이것은 매우 복잡한 정보을 엔캡슐레이트하기위해 사용되는 객체 및 전개진행으로의 서비스 개발 절차로서의 로직의 체계를 제공한다.

최하위 계층(400)은 서비스 애플리케이션 특성(401) 및 일반적인 서비스 성분(402)이다. 이것들은 서비스 요구를 충족시키고 일반적인 서비스 능력을 사용할 수 있도록 개발되는 코드 객체이다. 이것들은 SCE1 에서 개발된다. 일단 개발이 되면, 이 객체들은 시장성있는 서비스 특성(403) 또는 SCE2 에서 만들어진 미터특성(406)에 의해 언급될 수 있다.

MSF(403)은 특성의 통화-처리 로직과 그 특성의 필요한 지원 및 관리 설명(407) 모두를 엔캡슐레이트한다. 특히 본 발명의 목적을 위해, MSF(403)은 스크린 아이콘 정보(408) 및 사용자가 SCE3 에서 사용하는 형태 정보(409) 그리고 예비 MSF(403)를 포함하고 있다. 미터특성(406)은 MSF(406)과 비슷하지만 SCE3(265c)에서 예비로 될 수 있는 스크린 선명도(408) 또는 애스펙트(409)는 없다.

SCE2 에서 다시 구성된 서비스 패키지(404)는 MSF(403) 및/또는 특정 서비스의요구를 모두 만족시키는 미터특성(406)의 세트의 집합을 허용한다. 또한 서비스 패키지(404)는 어느 서비스-특정 지원 및 관리 정보(410)을 포함하게 된다. 마지막으로, 서비스 패키지(404)는 적어도 하나의 서비스 템플릿(405)를 포함하게 되는데, 상기 서비스의 운용을 설명하고 일어나는 서비스 운용의 수정의 구성을 정의한다. 이러한 모든 객체들은 아래에 자세히 설명되어 있다.

5.1 서비스 애플리케이션 특성(SAF) 401

서비스 애플리케이션 특성(SAF)(401)과 일반적인 서비스 성분(GSC)(402)간의 관계는 다음과 같이 설명될 수 있다. SAF(401)는 네크워트내에서 특성으로 전개된 어느 능력을 위한 일반적 이름이다. 이것은 보통 SAF 가 GSC 또는 GCS 의 성분중 하나로 된다는 것을 의미한다. 그러나 일부 서비스는 일반적이 될 수 없는 특별한 능력을 요구하기도 한다. SFA 및 GSC 모두 재사용이 가능하지만, 모든 SAF 는 일반적인 것이 아니다.

서비스 애플리케이션 특성(SAF)(401)은 IN 성분(102)상에서 전개된 재사용가능한 코드 객체이다. 서비스 창조자의 관점에서 보면, 이것은 서비스 창조 레벨 1(SCE1) 밖에서 식별가능한 척도의 최하위 레벨이다. 이러한 객체들은 SCE1 에서 디자인되고, 개발되고 테스트된다. 이 객체들은 서비스의 근본 성분을 나타내며 여러 서비스에서 재사용가능하도록 디자인된다. 예를들어, 통화 전환 등의 번호 이동 특성은 음성 및 데이터(즉 GSC 와 SAF 모두가 될 수 있음)로 재사용이 가능할 것이다.

SFA(401)은 특정 서비스 애플리케이션 수행에 독립되게 개발되고 어느 네트워크 아키텍쳐, 특정 플랫폼, 서비스 관리, 네트워크 관리 또는 요금청구 엔티티의 본래 지식은 가지고 있지않다. 그러한 SAF(401)가 IN 성분상에서 전개될 수 있느 특성을 나타내어 통화-처리 능력을 제공하지만, 특정 서비스와 관련된 사용자 상태 정보로 실증이될 때 까지 어떠한 값도 가지지 않는다. 본 명세서에 기재된 본 발명의 실시예에서, 이것은 서비스 네트워크의 내용의 내부에 있는것이다.

5.2 시장성있는 서비스 특성(MSF) 403

도 4 및 도 5를 참고하면, 시장성있는 서비스 특성(MSF)(403)이 하나 이상의 기초 SAF(401)를 내려다보는 도를 나타내고 있다. MSF는 SAF를 포함하고 있지는 않고 단지 그들을 언급하기만 한다. MSF는 SCE2 내부에서 만들어져서 SAF 들이 서비스 패키지의 일부분으로서 팔릴수 있도록(아래 5.3 참조) SAF(401)으로 값을 추가한다. SAF 가 시장성이 있기 위해서는 적절한 요금청구 및 네트워크 관리 기준(407)과 연관이 있어야 한다. 가장 중요한 것은, 상기 특성의 서비스 관리 측면은 어드레스되어야 한다는 것이다.

따라서 MSF(403)는 상기 특성의 예비가 될 수 있는 측면을 입력 및 업데이트하는데 필요한 스크린의 정의(408,409)와 함께 SAF(401)로의 기준을 포함한다. 이 예비가능한 측면들은 상기 특성이 올바르게 동작되는데 필요한 정보를 포함하고 있다. 그러나, MSF(403)의 예비가능한 측면은 언급되는 SAF(401)이 요구한것들 이상으로 확대될 수 도 있다. 특히 네트워크 관리 및 요금청구 측면은 특정 특성을 위해 예비가 될 수도 있다.

여러 MSF(403)은 동일한 기초 SAF(401)을 언급하기도 한다. 예를들어 바로 스케쥴된 번호 이동 특성은 시간, 날짜, 년도 또는 특정 일 경로, 야간 서비스 또는 서비스으 마케팅 요구 또는 고객의 요구에 따른 개방 시간 등으로 판매될 수 있다. 이들은 심지어 같은 서비스 내부에 있으면서 외관만 다르게 판매되기도 한다. 이러한 모든 MSF(403)들은 여러 예비 및 과금 특성을 가지고 있으나 기초 네트워크 수행은 그들 모두에 공통이다.

MSF 개념의 장기간 목적은 요금청구, 서비스 관리, 네트워크 관리, 폴트 관리 등의 성분들이 MSF(403) 및 SP(404) 가 최소한의 추가 코드 개발로 서비스의 대부분을 위해 SDS 저장소로부터 구성될 수 있도록 그들의 객체 시스템상으로 재사용가능한 빌딩블럭(SAF/GSC 같은)으로서 사용가능할 것이라고 가정하는 것이다. 그러한 빌딩블럭의 구조는 SCE1 액티비티의 어느 양이 그러한 관리 시스템이 SCE2 를 지원하도록 디자이너들 사이에서 발생함을 의미한다. 이러한 가정의 결과는 SCE2 에서의 서비스 창조자가 IN 성분 및 지원 관리 시스템 모두의 완전한 능력을 액세스 하게되고 대형 고객 및 각 개인을 위해, 일반적인 지능망으로의 즉각적인 전개를 위해 완전한 서비스를 구성한다.

5.2.1 미터 특성(MF) 406

MF(406)는 MSF(403)과 충분히 동일하긴 하지만 SCE3 의 목적을 위한 예비가 될 수 있는 측면은 없다. 따라서 MF(406)은 SAF 그래프의 형태 등에서 SAF(401)로의 기준을 다시 포함하지만 SCE3 레벨용 스크린 정보(408)은 포함하고 있지 않다.

MF(408)은 내부 데이터 구조의 초기화, 자원의 예약 및 특정 사용자가 결정되기 전의 인증 등의 기능을 제공하는데 사용된다. 예를들면, MSF(403)은 사용자에게 계산 코드의 세부사항 및 개인 식별 번호(PIN)을 입력하는 것을 허용하기도 하지만 MF 는 관련된 인증, 즉 필수사항 및 사용자가 수정할 수 없는 것을 수행한다.

5.3 서비스 패키지(SP) 404

서비스 패키지(SP)(404)는 서비스 제공자에 의해 시장성있는 것으로 간주되는 특정 서비스와 MSF(403)와 MF(406)를 연관시키는데 사용되는 엔티티이다. 따라서 SP(404)는 예를 들어 서비스/네트워크 관리 및 요금 청구와 관련된 서비스 특정 정보(410) 뿐만 아니라 MSF(403) 및/또는 MF(406)를 포함할 것이다.

서비스 패키지의 한 예는 서비스 패키지의 텍스트 파일 버전에 대한 설명과 예시를 제공하는 "부록 A"로서 본 명세서에 첨부되어 있다.

실제 SP(404)는 "IDENT" 부분(성명, 신원, 버전), "SCREEN DEFN REF"(화면의 표시 방법을 데이터로 정의하는 URL 파일에 대한 레퍼런스) 및 "RULES"를 포함할 수 있다.

보다 상세히 말하면, 이 규칙들은 서비스를 제공하는데 있어서 어느 단계에서 MSF(403)와 MF(406)가 필요한지를 판단하고, 본 명세서에서는 "편집 그래프"(아래의 5.3.2절 참조)라 하는 소정의 순서 및 조합으로 MSF 및/또는 MF를 함께 배열하는 포맷의 흐름도 형태로 표현될 수 있다. 이때 각각의 MSF(403)는 MSF(303)를 조작하는데 있어서 SCE3 레벨에서 사용자가 사용하도록 화면상에 나타나는 관련 아이콘을 결정하기 위한 아이콘 정보(408), 사용자가 그래프로부터 MSF 상자를 선택할 때 스크린에 나타나는 형태를 제어하기 위한 스크린 정의 레퍼런스(409) 및 SAF(401) 리스트를 포함한다.

그러나, MF(406)는 SCE3 레벨에 대한 아이콘 정보(408)와 스크린 정의 레퍼런스(409)는 제외하고, 따라서 SCE3 레벨에서 사용자는 이런 정보를 결코 볼 수 없다.

5.3.1 서비스 템플릿(405)

서비스 패키지(404)는 또한 프로파일 예시를 나타내는 하나 이상의 서비스 템플릿(405)을 참조하고, 이에 기초하여 SCE3 고객들은 자신들의 사용자 프로파일에 대한 근거를 마련할 수 있다. 서비스 템플릿(405)은 서비스 제공자가 모든 사용자에게 공통되는 형태로 완전히 갖춰질 때만 작업을 위해 제공하는 서비스 동작에 대한 검사 표현을 나타낸다. 다시 말하면, 서비스 템플릿(405)은 지정 서비스 상태 세트를 가질 것이다. 그것은 지정 서비스 상태 세트를 갖는 실행 그래프(아래의 6.2절 참조)를 포함한다. 따라서, 어떤 사용자가 잠재적으로 1 내지 9의 범위에서 재시도 횟수를 얻을 수 있는 서비스가 제공되면, 지정 서비스 상태는 3이 될 수도 있다. 이때 특정 사용자는 재시도 횟수를 5로 세트하기 위해 지정 서비스 상태를 변경함으로써 사용자 프로파일을 작성하는데 서비스 템플릿(405)을 사용할 수 있다.

SP(404)는 SCE2로부터 제공된 상기 규칙들을 요약하고, 그 결과 서비스 동작과 논리를 편집하거나 수정하려는 후속적인 시도는 동작적으로 수용가능한 범위내로 제한된다. 이런 방식에서 SCE3 프로파일링 도구의 구성은 기본적인 기능 상호작용과 종속성 규칙들이 특정 고객 그룹에 대한 프로파일을 조정할 때 고객에 의해 위반될 수 없도록 서비스 제공자에 의해 제어된다. 서비스 템플릿(405)은 특정 조정이 인도 이전에 발생하도록 서비스 또는 고객 레벨에서의 부분적인 준비에 대한 매커니즘을 제공한다.

5.3.2 편집 그래프

도 24는 편집 그래프를 보여준다.이들은 SCE3(265c)에서의 서비스 설계 용량을 제한함으로써 바라지 않은 기능 상호작용을 방지하는 SP(404)의 규칙들을 구현한다. 이들은 URL 파일에 대한 레퍼런스로 서비스 패키지(404)에 의해 한정되고, 사용자가 실행 그래프를 작성하기 위해 서비스에 대한 편집 그래프를 사용하는 경우 URL 파일과 함께 SCE3(265c)로 전송된다. (여기서 XVT는 UNIX와 호환되고, 비교적 플랫폼과 독립적인 URL 파일을 발생하기 때문에 도구로서 선택되었지만, 몰론 다른 형태의 도구로 대체할 수 있다는 것에 주의해야 할지도 모른다.)

서비스 패키지의 한 서비스에 대한 설명과 서비스 인도 하부구조(300)로 갈 필요가 있는 것 사이의 링크를 제공하는 서비스 프로파일을 구성하기 위해 SCE3 사용자는 "IDENT" 부분을 발생하고, "DATA" 부분을 연상할 필요가 있다. "IDENT" 부분은 "발신", "폼(form)" 및 "종단" 실행 그래프와 같은 서비스를 실행하는 것에 대한 여러 가지 상황에 대한 실행 그래프를 포함한다. "DATA" 부분은 관련 SAF를 참조한다. (폼은 실제 프로파일에 대한 일련의 속성을 수용하는 필드를 갖는 객체를 나타낸다.) 실행 그래프는 SCE2로부터 수신된 관련된 편집 그래프에 의해 적용된 제한내에서만 개별화를 제공할 수 있다.

도 24, 도 25 및 도 26를 참조하면, 도 24에 도시된 편집 그래프는 링크(249)에 의해 연결된 일련의 순서가 붙여진 MSF(403) 및 MF(406)를 포함하고, 이들 MSF(403) 및 MF(406) 중 일부는 유연성 위치(248)와 연관된다. 유연성 위치는 사용자에게 적용 가능한 다중 선택을 나타내기 위해 사용자 인터페이스의 매커니즘을 제공한다. 각각의 유연성 위치(248)에서, 추종하는 MSF와 MF에 대한 하나의 선택이 존재한다. 각각의 MSF(403) 및 MF(406)는 (도 24의 각괄호로 도시된) 연관된 인용부호를 갖는다. 유연성 위치(248)에서의 MSF와 MF의 선택은 이런 인용부호 리스트에 의해 도시된다.

편집 그래프를 작업하여 실행 그래프를 작성하기 위해, 사용자는 하나의 선택을 선택함으로써 개별화할 수 있다. 도 25a와 도 25b는 유연성 위치(248')에서 서로 다른 선택을 함으로써 한 편집 그래프로부터 구성될 수 있는 2개의 서로 다른 실행 그래프를 보여준다. 그러나, 각각의 선택은 또한 다른 규정에 따라 (실제 서비스를 실행하기 위해) 실행되는 한 세트의 대안을 포함할 수 있다. 본 실시예에서, 도 24에 도시된 바와 같이, 한 예로서 SCE3에서 사용자가 결과적으로 발생하는 실행 그래프가 MSF 또는 MF에 대한 대안 세트 중 선택된 하나로 가도록 선택할 수 있다. 편집 그래프로부터 사용자가 행한 결정은 그런 세트 중 하나를 선택할 것이다.

일단 실행 그래프가 사용자 또는 고객에 의해 구성되면, 사용자 "상태" 데이터, 즉 사용자 프로파일(아래에서 더 기술됨)와 연관되고, 서비스 노드 또는 SCP(231)과 같은 서비스 인도 시스템에 의해 요구될 때 로드될 것이다. 예를 들어 서비스 엔진에 의해 후속적으로 실행되는 실행 그래프는 항상 그 위치에서 MSF 또는 MF의 선택된 세트(251)로 갈 것이다. 도 25와 도 26을 참조하면, 이것은 상기한 다른 규정에서 실행 그래프의 결정 위치(250)를 형성한다. 결정 위치에서 여전히 실행 그래프의 단일 위치에서 실행되는 한 세트의 MSF(403) 및/또는 MF(406)가 존재한다. MSF 및/또는 MF 세트(251)는 규정에 따라 예를 들어 실행 그래프의 우측에서 좌측으로 지정된 순서로 번갈아 취해지고, 각각은 정확한 뷰에 대해 검사된다. 에를 들어 도 26에 도시된 세트의 첫 번째에서 정확한 뷰가 발견되면, MSF 또는 MF가 실행된다. (정확한 뷰는 조금도 틀림없는 뷰이다. 그것은 "신(scene)" 또는 논리적 표현일 수 있다. 예를 들어 SAF(401)는 입력 출력 신(scene)을 가질 것이다.)

실행 그래프가 MF 뿐만 아니라 MSF를 포함하고, 이들이 SCE3에서 연관된 가시 화면을 갖지 않기 때문에, SCE3에서 사용자는 공백 화면으로부터 서비스를 분명히 작성할 수 있다. 그러나, 실제 사용자는 항상 편집 그래프로 작업해야 한다. 심지어 공백 화면을 제공하는 편집 그래프도 사실 MF를 포함하고, 그런 편집 그래프는 사용자가 실행 그래프를 발생할 때 이를 계속 한정할 것이다.

SCE3(265c)에서 제공하기 위한 공백 화면을 제공할 위치가 존재하지 않기 때문에 서비스 제공자는 실제 사용자 적어도 하나의 서비스 형태를 선택하도록 요구할 수 있고, 이 경우에 관련되는 MSF(403)의 수는 제한되고, 스크린상에 나타나거나 사용자가 실행 그래프를 작성하기 위해 끌어들일 수 있는 MSF 아이콘에 대한 팔레트를 스크린이 제공할 수 있다.

도 24에 "사건 처리기" MF(241)를 포함하는 간단한 부가적인 그래프가 도시되어 있다. 이 그래프는 실제 메인 편집 그래프의 일부이다. 이것은 SCE3 사용자가 볼 수 없는 편집 그래프이고, 사건 처리기에 의해 호출된다. 기본적으로 통화자가 수화기를 내려놓을 때 다른 노드 중 하나가 처리되고 있으면, 사건 처리기는 통화를 클리어하기 위해 이 루틴을 호출할 것이다. 이에 따라 서로 다른 통화 처리가 서로 다른 사건에 대해 적용될 수 있고, 따라서 정지 노드로 향하는 2개의 경로가 존재한다.

(미터(meta) 기능이 유효한 편집 그래프를 형성하는데 있어서 SCE2(265b) 사용자가 사용하기 위한 자신들과 연관된 스크린 정보를 필요로 할 거라는 걸 알 수 있을 것이다. 이 스크린 정보는 그러나 SCE3(265c)에서 이용할 수 없다.)

5.4 프로파일 600

도 6을 참조하면, 프로파일은 서비스 템플릿(405)으로부터 도출된다. 서비스 템플릿은 변경되었거나 SCE3 사용자에 의해 부분적 또는 전체적으로 제공되었을지도 모른다. 그러나, 서비스 템플릿은 특정 예시가 서비스의 특정 사용자와 연관될 때까지 프로파일이 되지 못한다. 프로파일은 사용자가 특정 서비스에 대해 갖는 하나 이상의 기능 리스트를 포함하고, 각각의 기능은 특정 서비스의 정황내에서 성공적으로 동작하기 위해 그 기능에 대한 충분한 데이터를 갖출 필요가 있다.

불완전하고 부분적인 프로파일(601,602)은 구별되어야 한다. 불완전한 프로파일(601)은 완전히 또는 정확히 제공되지 않는 기능에 대한 레퍼런스를 포함할 수 있는 것이다. 정확히 제공된 기능은 성공적으로 동작하도록 그 기능에 대해 필요한 모든 데이터를 포함하거나 디스에이블되는 기능으로 정의되어야 한다. 그런 프로파일은 필요한 제공 데이터를 모두 포함하는 것으로 확인되고 검사될 때까지 SCE3(265c)로부터 발생해서는 안될 필요가 있다. SCE3는 불완전한 프로파일(601)이 구성 중일 때 이들에 대한 부분적인 저장을 허용한다. 부분적인 프로파일(602)은 완전한 서비스를 나타내는데 필요한 모든 기능을 포함하지 않는 것들이지만, 부분적인 프로파일이 포함하지 않는 기능들은 모두 정확히 제공된다. 부분적인 프로파일은 유효할 것이고, 서비스 관리(103), SCE3(265c), SDS(100) 및 IN 구성요소(102) 사이에 프로파일 갱신 정보로서 전송된다.

6. 예시 작업줄(Example Workstring)

도 7 내지 도 18은 가상적인 자기 해석이다. 이들은 쌍으로 판독되고, 각 쌍의 첫 번째는 예시 작업줄을 나타내고, 각 쌍의 두 번째는 연관된 체계적인 활동을 나타낸다. 이런 작업줄의 목적은 체계적인 설계를 실연하기 위해 몇가지 시나리오를 실행하는데 있다. 이와 같이 함으로써 도시된 바와 같이 이런 구조가 공통적인 활동을 지원하고, 이에 의해 총칭 지능형 네트워크의 서비스를 전개 및 준비/조정하기 위해 서비스 제작자에 대한 요구가 충족된다. 각각의 작업줄은 특정 시나리오 동안 활성 구성요소와 인터페이스를 밝게 표시하는 메시지 절차도와 개요도(도 2에서 도출됨)의 형태로 제시되어 있다.

도 7과 도 8은 SCE1(265a)로부터의 새로운 SAF/GSC(401, 402)의 전개에 관한 것이다.

도 9와 도 19는 새로운 서비스의 전개에 관한 것이다.

도 11과 도 12는 새로운 서비스에 순서 지정에 관한 것이다.

도 13과 도 14는 SCE3(265c)로부터의 프로파일의 업데이트에 관한 것이다.

도 15와 도 16은 서비스 관리 도메인(270)으로부터 업데이트하는 프로파일에 관한 것이다.

도 17과 도 18은 SCE3(265c)를 통한 네트워크-측 업데이트에 관한 것이다.

7. 데이터 분배-시나리오 구현

다음은 도 19 내지 도 22에 관한 것이고, 상기한 바와 같이 서비스 제작 시스템에 사용하기 위한 예시적인 데이터 분배를 제시한다.

이는 마스터 데이터의 기억장소, 프로파일(SM 또는 고객)을 소유하는 사람 및 서비스 레벨 동의(SLA)(대개 SM의 범위내로 간주됨)의 시행을 정렬하는 것이 중요하다. 여기에 제시된 데이터 분배의 전략은 실시 제한, 서비스 관리 요구, 네트워크 운영자 정책 및 고객 요구에 따라 유연하게 구성될 수 있는 데이터 저장 체계를 제공한다.

예시 1에서, SCE3(265c)는 특정한 영구 기억장치 또는 데이터베이스 제품에 직접 연결되지는 않을 것이다. 이런 성능은 이것을 외부 시스템 모듈로서 처리하는기억장치에 대한 검색, 저장 및 전송 동작을 허용하는 정의된 인터페이스를 통해 추출된다. 이런 체계는 애플리케이션이 필요와 정당성에 따라 선택되거나 업그레이드될 수 있도록 프로파일 저장소에 대한 동작을 밀폐함으로써 벤더 독립을 유지한다. 이런 시스템은 SM 정책과 처리 성능에 따라 서로 다른 프로파일 저장 시나리오의 구성을 허용한다. 서비스 제작 체계는 필요에 따라 조합 범위내의 모든 것을 지원할 것이다. 이런 체계에 의해 사용가능하게되는 시나리오가 도 19 내지 도 22에 도시되어 있다.

7.1 시나리오 1

도 19를 참조하면, 프로파일 저장기(190)는 서비스 생성 도메인내에 존재한다. 저장 및 검색 연산은 국부적으로 발생하고, 전송 연산은 준비된 프로파일이 SM으로 전송되도록 한다.

구현

· 고객은 SM으로 전송될 때까지 그 자신의 프로파일 데이터를 소유하고, 관리하며, 책임진다.

· 프로파일은 전체 네트워크 서비스 데이터를 통해 수위(首位)를 유지하는 SDS 데이터로부터 재구성된다.

· SCE3 고객은 응용이 준비되어 있고, 프로파일 데이터 관리를 지원해야 한다.

7.2 시나리오 2

도 20을 참조하면, 모든 데이터는 SM에서 마스터된다. 프로파일은 SM 시스템상에서 SCE3로부터 프로파일 저장기(200)로 전달된다. 검색할 때, 서비스 관리 데이터는 프로파일 저장기(200)내 업데이트된 프로파일로 변환되고, SCE3에서 질의 프로세스로 반환된다.

구현

· SM은 사용자 프로파일을 포함하는 모든 데이터의 마스터 및 호스트가 된다.

7.3 시나리오 3

도 21을 참조하면, 분배 프로파일 저장기(210)는 시나리오 1 및 시나리오 2가 고객 기본마다의 요구, 정책, 및 성능에 따라 구성되도록 한다.

구현

· 두 도메인간의 데이터 인터페이스는 선택된 기억장치 구현에 존재하는 어떠한 독점 구조에 의해 관리될 것이다.

· 선택된 저장 응용은 분배 구성을 지원해야 한다.

7.4 시나리오 4

도 22를 참조하면, SCE3는 SM 도메인내에 함께 존재한다. 이것은 그 서비스 패키지 및 사용자 프로파일에 직접적으로 고객 지원을 제공하는 서비스 관리 시스템상에서 네트워크 오퍼레이터 사람들에 의한 SCE3 사용을 위해 제공된다.

구현

· 고객 및 네트워크 오퍼레이터의 지원자 양쪽 모두 동일한 툴세트 및 예비 스크린을 통해 프로파일을 준비하고 업데이트할 것이며,

· 어떤 고객은 그래프식 워크스테이션 또는 클라이언트 응용(예를 들어 초과)의 일부 형태를 통해 SCE3 툴세트로 원격 액세스를 요구할 수 있고,

· 서비스 관리 플랫폼은 SCE3 응용을 지원해야 한다.

8. KTN(Key to the Network) 서비스

다음은 본 발명의 실시예에 의해 유효해지고 주문 생산될 수 있는 서비스를 나타낸다.

KTN 서비스는 하나의 인증 및 권한 부여 프로시져를 갖는 단일 단축코드 액세스 번호에 의해 서비스의 범위로 네트워크 액세스를 제공하는 서비스이다. 사용자는 그들을 식별하기 위해 KTN 서비스에 사용되는 하나의 개인 식별번호(PIN) 및 하나의 어카운트 번호를 갖는다. 일단 인증되면, 사용자는 예를 들어 대화식 음성 또는 "듀얼 톤 다중 주파수"(DTMF) 메뉴에 의해 서비스를 선택할 수 있다. 그러면 KTN 서비스는 KTN 서비스내에 국부적으로 포함된 데이터로부터 통화자와의 음성/DTMF 상호작용에 의해 선택된 서비스를 액세스하기 위해 요구된 정보를 검색한다. 검색된 정보는 선택된 서비스를 액세스하기 위해 요구된 PINs 및 어떤 연속적인 권한 부여 코드를 포함할 것이다.

KTN은 사용자를 대신해 선택된 서비스를 액세스하고, 이것은 사용자를 통해서가 KTN을 통한 액세스인 것을 서비스가 인식하지 못하도록 서비스로의 다이얼 호출 액세스 및 사용자의 대행을 요구할 수 있다. 일단 KTN이 서비스 액세스를 얻으면, 업데이트할 수 있거나, 서비스에 의해 업데이트될 수 있거나, 또는 서비스의 제어를 통해 통화자를 인도할 수 있다. 서비스와의 상호작용이 완료되면, 제어는 KTN으로 반환되고, 통화자는 또다른 서비스를 선택하기 위한 기회를 제공받는다. 만일 어떠한 다른 서비스도 요구되지 않는 경우, 사용자는 전화를 끊고 KTN 세션을 종료할 것이다.

KTN 서비스는 서비스 전달 구조에 존재하는 가상 네트워크내에서 실행될 수 있는 IN 서비스로서 존재한다. 서비스 생성 환경(265)내에서, 서비스는 서비스 패키지(404)로서 존재한다. 다음의 섹션은 서비스 패키지 의미론을 사용하는 서비스 지정 해결 모델을 나타낸다.

8.1 KTN 서비스 구조

KTN 서비스는 SCE2에서 구성되고, KTN 서비스 패키지로서 SCE3로 배치된다. KTN 서비스 패키지는 시장성있는 서비스 특성(MSFs), 미터 특성 및 편집 그래프와 같이 표현된 관련된 구성 규칙의 집합으로 구성된다. MSFs(403) 및 미터 특성(406)은 실행가능한 서비스 응용 특징(SAFs)(400) 및 관련된 준비가능한 데이터 아이템으로 구성된다.

KTN 서비스 패키지는 부록 A에 설계되어 있다. 그것은 종료 편집 그래프를 포함한다. 편집 그래프는 실행 순서 규칙 및 MSFs(403) 및 미터 특성(406)을 위한 예비 규칙을 포함한다. 규칙은 선행자 관계, 결정 포인트, 및 유연성 포인트에 의해 지정된다.

유연성 포인트(248)는 SCE3 준비를 위한 예약 옵션을 전달한다. 유연성 포인트(248)는 실행 그래프를 구성하기위해 사용된 선택적인 MSFs(403)를 갖는 SCE3(265c)에서 오퍼레이터를 제공한다. 서비스 패키지(404)는 편집 그래프의 규칙에 따라 SCE2(265b)에서 구성된 준비되지 않은 실행 그래프인 템플릿(405)을 포함한다. 그러면, 이러한 템플릿 그래프는 SCE3에서 사용자를 위해 준비될 수 있고, 사용자의 서비스 프로파일과 같이 네트워크에 배치될 수 있다. 서비스 프로파일은 싱글 종료 실행 그래프를 포함할 것이다.

선행자 관계 및 결정 포인트는 네트워크에서의 통화 처리동안 실제 실행 순서매김을 위해 실행 식별 세부사항을 표현한다.

8.2 KTN 서비스 종료 편집 그래프

DTN 서비스가 발생되는 경우, KTN 액세스 번호로 걸려온 통화의 결과로서, 편집 그래프로부터 얻어진 종료 실행 그래프는 서비스 실행을 위해 사용된다. 도 24는 KTN 서비스 종료 편집 그래프의 상세한 설명을 제공한다. 그러면, 얻어진 실행 그래프(상세히 도시되지는 않았지만 도 26 및 도 27을 참조로 상기되고 도 25에 도시된 타입중의 하나)는 MSFs(403) 및 미터 특성(406)의 실행순서를 나타내고, 결정 포인트(250)에서 그래프 노드간의 링크상에서 주석된 뷰(247)에 의해 계승자의 트리거링을 전달한다(뷰를 가리키지 않는 계승자는 항상 트리거된다).

실행 그래프가 서비스 엔진에 의해 실행되는 경우, 그래프내 제 1 노드는 MSFs(403) 및 MFs(406)를 위해 검사된다. 만일 다중 MSFs(403) 및/또는 MFs(406)가 그래프 노드에 존재하는 경우, 이것은 결정 포인트(250)를 구성한다. 그래프의 왼쪽에 도시된 제 1 의 연속적인 MF 또는 MSF를 위한 뷰가 실행되는 것이 규칙이다. 만일 뷰(247)가 실패인 것으로 발견되면, 오른쪽으로 다음 MF(또는 MSF)의 뷰(247)는 뷰(247)가 참으로 평가될 때까지 검토된다.

편집 그래프내 유연성 포인트(248)는 유연성 노드에서 표현으로서 주석된다. 표현의 형태는 :-

Flex {a,b},{c,d}

여기서 "a,b,c,d"는 MSFs(403) 및 MFs(406)을 식별하는 기준이 된다.

이것은 유연성이 편집 그래프에서 표현되는 경우, 노드(x)라고 하면, 노드가 실행 그래프를 위해 도 27에 의해 증명된 바와 같이 2 결정 포인트중의 하나를 선택하는 유연성을 갖는다. 그러면, 유연성 포인트로부터 구성되는 실행 그래프는 2 결정 포인트중의 하나만을 갖는다.

(만일 유연성 포인트가 MSFs의 세트, 예를 들어 "Flex{a},{b}" 사이 대신, 두 개 싱글 MSFs 사이의 간단한 선택을 나타내는 경우, 물론 잇따른 실행 그래프는 필연의 결정 포인트를 나타내지 않을 것이다.)

9. SCE3(265c)에서 사용자에 의한 본 발명의 실시예의 사용

논리적으로, 사용자가 SCE3(265c)에서 보게되는 것은 오직 MSFs(403) 뿐이다 - 이 MFs(406)은 볼 수 없고, SCE3 사용자가 관여되는한, 또한 존재하지 않을 수 있다. 도 28을 참조하면, 도 24의 편집 그래프에서 사용자는 비교적 짧은 MSFs(403)의 세트를 보게 된다.

물리적으로, 스크린 표시는 도 29에 나타난 바와 같이 사용자에게 좀더 친근하게 느껴진다. 오른쪽의 윈도우(280)는 특징 팔레트이다. 그것은 "KTN" 서비스의 환경에서 사용자에게 유효한 모든 MSF 아이콘(281)을 포함한다. 툴은 전체적으로 사용자가 유효한 실행 그래프 생성에만 구속된다는 것 - 툴이 그들에게 옵션을 주지않기 때문에 그들이 무효한 그래프를 생성하는 것은 불가능하다 - 을 의미하는 "구속 기본 편집"이라고 칭해지는 것을 사용한다. 이것으로의 키는 특징 팔레트가 된다. 만일 사용자가 특정 노드(281)(즉, "Foo"로 표시된 것)를 삽입하기를 원한다면, 사용자는 예를 들어 알려진 타입의 마우스를 이용하여 그 아이콘(281)을 선택하고, 메뉴로부터 아이콘을 삽입하기 위한 옵션을 선택한다. 이것은 예를 들어 도 29에 도시된 툴바(282)에서의 "편집" 메뉴로부터 있을 수 있다.

그러면, 툴은 선택된 노드(281)를 추가하는 함의가 되는 것을 해결한다. 그것은 선택된 노드(281)가 추가되도록 하기 위해 어떤 노드가 현존하는 편집 그래프내에서 변경될 필요가 있는가를 결정하기 위해 적절한 서비스 패키지(404)내 전체 편집 그래프를 사용한다. 그러면 변경의 함의를 표시하는 윈도우가 표시되고, 그것을 실행하기전에 사용자에게 그들의 행위를 확인하도록 요청한다.

예를 들어, 도 30을 참조하면, "Foo" 및 "CM" 노드는 서로 양립할 수 없었고, (도 28의) MsgNotifyMSF 노드만이 CM 노드와 이해되었다. Foo 노드 삽입을 요청하는 것은 예를 들어 도시된 바와 같은 함의 윈도우(290)의 결과를 낳는다.

"OK" 버튼(290)을 선택하면 변경을 수행할 것이다. 유사한 구조가 삭제시에 발생된다-사용자가 삭제될 노드를 선택하고, 툴이 함의를 해결하며 표시하고, 사용자가 함의를 수용하며, 서비스가 변경된다.

가능한 실행 그래프는 (먼저 설명된 바와 같은 전체 편집 그래프에서) 편집 그래프에 따르는 규칙에 종속적으로 변화될 것이다. 앞서서의 예를 사용하면, 가능한 실행 그래프가 도 25a 및 도 25b에 도시된 바와 같이될 수 있다. 중요한 점은 SCE3 사용자가 갖는 유연성만이 그들 그래프에서 MSFs(403)를 변경하는 것이다 - MF(s)(406)은 만일 그/그들전에 MSF(403)이 그래프에 나타나는 경우 실행 그래프에 항상 나타난다.

사용자는 만일 그것이 서비스 패키지(404)내 그 편집 그래프내 규칙에 의해 서비스를 위한 유효한 상태에 있는 것으로 정의되는 경우, 블랭크 스크린으로부터 작업할 수 있다. 이것이 구속 기본 편집의 결과가 된다. 서비스 제공자가 템플릿 서비스와 같이 디폴트, 유효한 서비스 구성을 생성하는 것이 가장 가능성 있다(정확하게는 MS-워드내 문서 템플릿과 동일한 방법으로 행해진다). 사용자는 "New" 를 선택하고, 그로부터 선택할 템플릿의 리스트와 함께 있게 된다. 예를 들어, "CM이 있는 KTN" 또는 "Foo가 있는 KTN"은 도 30에 도시된 앞서의 예를 사용한다. 템플릿은 그 서비스가 그 서비스에 특별한 명백한 고객 정보를 제외하고 실행되기 위해 필요한 모든 것을 포함한다(예를 들어, 그들의 전화번호, 통화가 전환되기는 바라는 위치, 등). 이것은 사용자가 그들의 세부사항을 입력하도록 허용하는 형태를 가져오는 아이콘(281)상에서 더블클릭함으로써 입력된다.

본 발명의 실시예는 다중 타입의 여러 사용자들에게 유용한 설비를 제공하는 서비스 창조 시스템을 제공한다. 예를 들어, 사용자가 서비스 특징들로부터 완벽한 서비스 패키지를 설계하도록 하거나, 또는 여러 마켓을 위해 현존하는 서비스 패키지를 수정하도록 허용한다. 시스템은 서비스 패키지의 논리적 흐름을 생산하기 위한 다수의 방법으로 결합될 수 있는 시장성 높은 서비스 특징들의 팔레트를 제공한다. 모든 특징은 고려되어야 하는 보안, 특성 상호작용 회피, 요금청구 및 예비의 측면이 있을 수 있다. 시스템은 전개될 서비스 패키지를 위해 필요한 모든 정보, 템플릿, 요금청구 기록, 및 예비 스크린의 설계를 자동화할 수 있다. 이것은 서비스 패키지를 지능 네트워크의 노드로 전송하는 분배 서비스, 서비스를 실행할 여러 관리 시스템 및 고객에게 유효하게 될 수 있다.

사용에 있어서, 회사는 네트워크 운용자(예를 들어 BT)의 새로운 서비스 제공을 듣고 서비스를 요청할 수 있다. 초기 준비 정보는 네트워크의 서비스 관리 시스템으로 로드되고, 이제 고객은 서비스를 갖는다. 그러면 고객은 터미널, 아마도 그들이 네트워크 운용자의 운용자를 사용하기보다는 그들 자신의 서비스 데이터를 준비하고 변경할 수 있는 개인용 컴퓨터를 가질 수 있다. 그들은 적당한 레벨의 서비스로의 액세스를 제공할 여러 사용자 그룹을 위한 템플릿을 창조할 수 있다. 그들은 또한 메뉴상에서의 옵션의 순서와 같거나 서비스가 우선하는 서비스 논리를 변경할 수 있다. 서비스 창조 시스템은 고객이 필요성을 느끼는 만큼 많이 또는 적게 서비스의 제어 또는 서비스내 제어를 가질 수 있도록 충분히 플렉시블할 수 있다.

3 레벨 서비스 창조 환경을 설명했지만, 이것이 본 발명의 실시예의 필수적인 것은 아니다. 본 발명의 주 개념은 실제로 사용자가 전체적으로 테스트되어 사용가능한 구성으로 서비스를 창조 또는 개발하도록 구속하는 편집 그래프 전체 또는 편집 그래프가 보이지 않는 경우, 그래픽적인 사용자 인터페이스를 가능하게 하는데에 있다. 또다른 타입의 서비스 창조 환경은 편집 그래프의 개발자, 대개 서비스 제공자를 위한 하나, 및 고객 및/또는 사용자를 위한 하나의 두 개만의 다른 액세스 포인트를 가질 수 있다. 그러한 경우, 네트워크 성분을 위한 코드는 일부 다른 방법, 예를 들어 분배 컴퓨터 환경으로부터 또는 상기 컴퓨터 환경에 의해, 다수의 서비스 제공자를 지원하는 네트워크 제공자의 도메인으로부터와 같이 일부 원격 소스로부터 일부 다른 방법으로 제공될 수 있다.

상기한 설명에서 "엔캡슐레이션(encapsulation)" 및 "객체(objects)"와 같은 전문용어가 사용된다는 것을 주의해야 한다. 이러한 타입의 용어는 단순히 객체 중심 소프트웨어 엔지니어링 및 프로그래밍의 언어와 같이 인식되고, 관련된 기술에서 통상의 지식을 가진 자에 의해 이해되는 것과 동일한 의미를 갖는다.

앞서 설명한 바와 같이, 여러 서비스 창조 레벨(SCE1,SCE2,SCE3)(265)은 각각의 환경에 있지만, 레벨들 중 적어도 두 개는 논리적으로만 분리되어 있는 경우도 있을 수 있다. 예를 들어 여러 액세스 권리의 형태에서의 논리적 분리로 고객/사용자를 위한 서비스 창조 레벨(265c)과 서비스 제공자를 위한 서비스 창조 레벨(265b)를 구별할 수 있다. 이러한 경우, MFs(406)는 SCE2(265b)에 적합할 수 있는 액세스 권리를 갖는 서비스 제공자에게는 가시적이지만 SCE3(265c)에 적합할 수 있는 액세스 권리를 갖는 고객에게는 보이지 않는 관련 스크린 정보를 실제적으로 갖게 될 수 있다. 이러한 경우, MFs(406)는 고객 또는 사용자가 관련되는 한 스크린 정보없이 효과적으로 된다.

16. 부록 A : 패키지 문서 화일 포멧

16.1 배경

본 부록에는 서비스 패키지의 문서 파일 버젼의 설명 및 예가 포함되어 있다. 이를 설명하는 패키지의 정의는 데이터 사전 제어 도큐먼트[7] 내에 기록되어 있다. 이 문서 파일은 SCE2 가 운반한 패키지의 ASN.1 부호화된 버젼을 대신하고자 한다거나 또는 제외하고자 하고자 함이 아님을 강조하고자 한다. 대신, 이를 보충하고자 ASN.1 의 오버헤드 없이 테스트 패키지의 간단하지만 아직은 강력안 수단을 제공한다. 이것은 패키지의 설치가 ASN.1 패키가 SCE2 로부터 사용가능하기 전에 테스트될 수 있게 한다. 또한, 몇 몇 이유에서, 상기 패키지의 ASN.1 버젼이 나타나지 않는 경우 폴-백(fall-back) 솔류션을 제공한다.

간단한 파서(parser)가 상기 패키지 파일을 판독하고 모델 객체를 구성하기 위해 1ex 및 yacc 를 사용하여 구성되어 왔으며, 6.3.2.1절 및 6.2.2.5절에 설명되어 있다.

16.1 BNF 설명

(BNF 는 문법을 설명하는 의미인 "Backus Naum Form" 을 뜻한다)

16.2.1 주 생산물

<Service Package> ::= ServicePackage: <CMTag> <ObjectID> <FOTag>

<MetaFeature> ::= MetaFeature: <CMTag> <SAFGraph>

<ServiceProfile> ::= ServiceProfile: <ObjectID> <Control>

<UserPackage> ::= UserPackage: <CMTag> <ObjectID> <PackageID>

<UserProfile> ::= UserProfile: <ObjectID> <Control> <PackageID>

16.2.2 어휘 목록

<Attribute> ::= Attribute: <string> Value: <string>

<BillAgentID> ::= BillingAgentID: <oid>

<CMTag> ::= CM Tag: <Name> Version: <string> DateTime:

<ChargeID> ::= ChargeID: <integer>

<Control> ::= Control: <ControlID>

<ControlID> ::= Disable ｜ Enabled

<DecisionPoint> ::= DecisionPoint: <NodeRefList>

<EdNode> ::= EditNode: <NodeID> <View> <FlexPoint>

<ExNode> ::= ExexNode: <NodeID> <View> <DecisionPoint>

<FOTag> ::= Associationind: <boolean>

<FPID> ::= FPInstanceID: <integer>

<FPIList> ::= FPIList: <FPICollection>

<FPInstance> ::= FeatureProfileInstance: <FPID> <FProfile>

<FProfile> ::= FeatureProfile: <SAFID> <SAFState>

<FlexPoint> ::= FlexPoint: <DPList>

<Height> ::= Height: <integer>

<HelpInfoID> ::= HelpinfoID: <filename>

<iconID> ::= IconID: <filename>

<MetaSP> ::= MetaServiceProfile: <MetaSPBody> ｜ <null>

<MFInv> ::= MFInventory: <MFList> ｜ <null>

<MSFinv> ::= MSInventory: <MSFList> ｜ <null>

<NodeID> ::= GraphNode: <NodeRef> <NodeType>

<NodeRef> ::= NodeRef: <integer> ｜ <endMarker>

<NumSucc> ::= NumSucc: <integer>

<NodeType> ::= NodeType: <NodeTypeID>

<NodeTypeID> ::= MSF ｜ MF ｜ SAF

<OpName> ::= OperationID: <string>

<OrigEditGraph> ::= OrigEditGraph: <EditGraph>

<OrigExecGraph> ::= OrigExecGraph: <ExecGraph>

<PackageID> ::= PackageID: <old> ｜ <null>

<Param> ::= Param: <SceneTag>

<Profile> ::= <ServiceProfile> ｜ <UserProfile> ｜

<ProfileFileName> ::= FileName: <filename>

<ProfileRef> ::= ProfileRef: <DN> <ObjectID> <PackageID>

ProfileRefList> ::= <ProfileRef> ｜ <ProfileRefList> <ProfileRef>

<ProvScreen> ::= ProvScreen: <filename>

<Resources> ::= ServiceResources: MaxUsers: <integer>

MaxSimCalls: <integer>

<Return> ::= Return: <SceneTag>

<SAFGraph> ::= SAFGraph: <ExecGraph>

<SAFID> ::= SAFID: <string>

<SAFInventory> ::= SAFInventory: <SAFNodes>

<SAFNodes> ::= SAFNode: <SAFID> <FPID> <OpName>

<SAFNodeIndex> ::= SAFNodeIndex: <integers>

<SAFState> ::= SAFState: <AttriList>

<Scope> ::= Scope: <ScopeID>

<ScopeID> ::= User ｜ Service ｜ VN ｜ BT ｜ Call ｜ NoScope

<Template> ::= Template: <Name> <ProFileName> <Profile>

<TemplateInv> ::= TemplateInventory: <TemplateList> ｜ <null>

<TermEditGraph> ::= TermEditGraph: <EditGraph>

<TermExecGraph> ::= TermExecGraph: <ExecGraph>

<Width> ::= Width: <integer>

<WinPos> ::= WindowsPos: <Position> ｜ <null>

<boolean> ::= True ｜ False

<alphaNum> ::= 'a'-'z' ｜ 'A'-'Z' ｜ '0'-'9'

<digit> ::= '0'='9'

<endMarker> ::= END

<null> ::= ' '｜＼n

<nullMarker> ::= NULL

<quote> ::= //This is a single quote!

<whitespace> ::= <null>｜＼t

16.3 서비스 패키지 예시

선택된 예시 서비스는 매우 간단한 것이다. 사실, 이것이 행하는 것은 동보 메시지(모든 서비스 사용자에게 동일한)를 보내고, 선택적으로 환영 메시지를 보내며, 다른 서비스를 호출하는 것이 전부이다. 환영 메시지가 보내지면, 사용자는 권한 부여를 요청한다. 권한 부여 기능은 이 예에서 메타 기능이라는 것을 유념하라.

완전한 편집 그래프는 다음과 같을 것이다.

이 그래프의 SCE3에서, 메타 기능은 볼 수 없을 것이다. 서비스 패키지가 2개의 템플릿 서비스 프로파일을 포함한다고 가정되고, 이중 하나는 각각의 가능한 편집 그래프에 대한 것이다. 이들은 다음과 같이 나타날 것이다.

// @ (∥) servPack.ex1.13 9/15/94

ServicePackage:

CHTag:

Name: 'test service package'

Version: '1.13'

DateTime: '9/15/94'

OID: 0.1.2.3.4.5.6

AssociationInd: False

IconID: 'testpackage.xbm'

ProvScreen: 'testpackage.url'

HelpInfoID: 'testpackate.hlp'

Control: Enabled

ChargeID: 3

BillingAgentID: 0.5.0.0.1

ServiceResources:

MaxUsers: 999

MaxSimCalls: 999

(다음은 단일 SAF를 포함하는 MSF에 대한 정의이다:)

MSFInventory:

MSF:

CMTag:

Name: 'welcomeMSF'

Version: '1.0'

DateTime: '17 June1994 10:40 GMT'

SAFGraph:

ExecNode:

GraphNode:

NodeRef: 1

NodeType: SAF

SAFNodeIndex: 0

View: 'this is where a view would go'

DecisionPoint:

NodeRef:

SAFInventory:

SAFNode:

SAFID: 'playMessage'

FPInstanceID: 2

OperationID: 'play'

Param: 1

Return: 2

Scope: User

IconID: 'myMSF.xbm'

ProvScreen: 'myMSF.url'

HelpInfoID: 'myMSF.hlp'

ChargeID: 3

Control: Enabled

PackageID:

MSF:

CMTag:

Name: 'followOnMSF'

Version: '1.0'

DateTime: '17 June 1994 10.40 GMT'

SAFGraph:

ExecNode:

GraphNode:

NodeRef: 1

NodeType: SAF

SAFNodeIndex: 0

View: 'a view'

DecisionPoint:

NodeRef:

SAFInventory:

SAFNode:

SAFID: 'followOn'

FPInstanceID: 3

OperationID: 'next'

Param:

Return:

Scope: User

IconID: 'followonMSF.xbm'

ProvScreen: 'followonMSF.url'

HelpInfoID: 'followonMSF.hlp'

ChargeID: 2

Control: Enabled

PackageID: 0.1.2.3.4.5.6

MSF:

CMTag:

Name: 'broadcaseMSF'

Version: '1.0'

DateTime: '17 June 1994 10:40 GMT'

SAFGraph:

ExecNode:

GraphNode:

NodeRef: 1

NodeType: SAF

SAFNodeIndex: 0

View: 'a view'

DecisionPoint:

NodeRef: END

SAFInventory:

SAFNode:

SAFID: 'broadcast'

FPInstanceID: 5

OperationID: 'set'

Param:

Return:

Scope: Service

IconID: 'broadcastMSF.xbm'

ProvScreen: 'broadcastMSF.url'

HelpInfoID: 'broadcastMSF.hlp'

ChargeID: 0

Control: Enabled

PackageID:

MFInventory:

(다음은 단일 SAF를 포함하는 MF에 대한 정의이다:)

MetaFeature:

CMTag:

Name: 'authorisMF'

Version: '1.0'

DateTime: '21 June 1994 11:55 GMT'

SAFGraph:

ExecNode:

GraphNode:

NodeRef: 1

NodeType: SAF

SAFNodeIndex: 0

View: 'a view'

DecisionPoint:

NodeRef: END

SAFInventory:

SAFNode;

SAFID: 'sentinal'

FPInstanceID: 1

OperationID: 'authorise'

Param:

Return:

Scope: User

OrigEditGraph:

EditNode:

GraphNode:

// Broadcast MSF

NodeRef: 1

NodeType: MSF

MSFID: 'broadcastMSF'

WindowPos:

topX: 0

topY: 0

Height: 60

Width: 60

View: 'TRUE'

FlexPoint:

DecisionPoint:

NodeRef: 2

DecisionPoint:

NodeRef: 4

EditNode:

GraphNode:

// welcome MSF

NodeRef: 2

NodeType: MSF

MSFID: 'welcomeMSF;

WindowPos:

topX: 0

topY: 100

Height: 60

Width: 60

View: 'TRUE'

FlexPoint:

DecisionPoint:

NodeRef: 3

EditNode:

GraphNode:

// authorise MF

NodeRef: 3

NodeType: MF

MFID: 'authoriseMF'

View: 'TRUE'

FlexPoint:

DecisionPoint:

NodeRef: 4

EditNode:

GraphNode:

//follow-on MSF

NodeRef: 4

NodeType: MSF

MSFID: 'followOnMSF'

WindowPos:

topX: 0

topY: 200

Height: 60

Width: 60

View: 'TRUE'

FlexPoint:

DecisionPoint:

NodeRef: END

TermEditGraph:

Templatelnventory:

Template:

Name: 'With welcome message'

FileName: 'welcome.tmp'

ServiceProfile:

OID:

Control: Enabled

PackageID: 0.1.2.3.4.5.6

IconID: 'profile1.xbm'

origExecGraph:

ExecNode:

GraphNode:

// Broadcast MSF

NodeRef: 1

NodeType: MSF

MSFID: 'broadcastMSF:

WindowPos:

topX: 0

topY: 0

Height: 60

Width: 60

View: ' '

DecisionPoint:

NodeRef: 2

ExecNode:

GraphNode:

//welcome MSF

NodeRed: 2

NodeType: MSF

MSFID: 'welcomeMSF'

WindowPos:

topX: 0

topY: 100

Height: 60

Width: 60

View: ' '

DecisionPoint:

NodeRef: 3

ExecNode:

GraphNode:

// authorise MF

NodeRef: 3

NodeType: MF

MFID: 'authoriseMF'

View: ' '

DecisionPoint:

NodeRef: 4

ExecNode:

GraphNode:

// follow-on MSF

NodeRef: 4

NodeType: MSF

MSFID: 'followOnMSF'

WindowPos:

topX: 0

topY: 200

Height: 60

width: 60

View: ' '

DecisionPoint:

NodeRef: END

TermExecGraph:- Null

FPIList:

FeatureProfileInstance:

FPInstanceID: 2

FeatureProfile:

SAFID: 'playMessage'

SAFState:

Attribute: 'messageFile'Value:

'welcome.audio'

FeatureProfileInstance:

FPInstanceID: 3

FeatureProfile:

SAFID: 'followOn'

SAFState:

Attribute: 'followOnService' Value:

'0.1.0.2.1'

Template:

Name: 'Without welcome message'

FileName: 'noWelcome.tmp'

ServiceProfile:

OID:

Control: Enabled

PackageID: 0.1.2.3.4.5.6.6

IconID: 'profile2.xbm'

OrigExecGraph:

ExecNode:

GraphNode:

//Broadcast MSF

NodeRef: 1

NodeType: MSF

MSFID: 'broadcastMSF'

WindowPos:

topX: 0

topY: 0

Height: 60

Width: 60

View: ' '

DecisionPoint:

NodeRef: 4

ExecNode:

GraphNode:

//follow-on MSF

NodeRef: 4

NodeType: MSF

MSFID: 'followonMSF'

WindowPos:

topX: NULL

topY: 200

Height: 60

Width: 60

View: ' '

DecisionPoint:

NodeRef: END

TermExecGraph:

FPList:

FeatureProfileInstance:

FPInstanceID: 3

FeatureProfile:

SAFID: 'followon'

SAFState:

Attribute: 'followOnService' Value:

'0.1.0.2.1'

TemplateInventory:

Template:

Name: 'Service-scoped data'

FileName: 'metaSP.tmp'

MetaServiceProfile:

OID: 0.1.2.3.4.5.6.7

PackageID: 0.1.2.3.4.5.6

FPList:

FeatureProfileInstance:

FPInstanceID: 1

FeatureProfile:

SAFID: 'authorise'

SAFState: 'authorise'

Attribute: 'minPINLength' Value: '2'

Attribute: 'maxPINLength' Value: '4'

FeatureProfileInstance:

FPInstanceID: 5

FeatureProfile:

SAFID: 'broadcast'

SAFState:

Attribute: 'message' Value: 'broadcast.audio'

Attribute: 'status' Value: 'active'

Claims

통신 서비스가 코드의 유닛의 주문된 시퀀스의 스크린-기반 조작에 의해 창조되거나 수정될 수 있는 통신망용 서비스 창조 및 제공 시스템에 있어서, 상기시스템은 실행 그래프에 따라 코드의 유닛의 주문된 시퀀스을 가동시켜 서비스를 제공하고 :

ⅰ) 코드의 저장된 유닛을 액세스 하는데 사용되는 인터페이스;

ⅱ) 상기 저장으로부터 코드의 유닛 세트를 선택하는 수단;

ⅲ) 통신 서비스의 제공을 위해 코드의 유닛 세트에 관련된 상기 주문된 시퀀스의 적어도 일부에서 결정되는 편집 그래프을 창조 또는 수정하는 수단;

ⅳ) 실행 그래프를 만들기 위해 상기 편집 그래프를 창조 또는 수정하는데 그래픽 사용자 인터페이스 상에서 사용자가 사용을 위해 편집 그래프를 시각적 정보와 연관시키는 수단; 및

ⅴ) 상기 그래픽 사용자 인터페이스로 상기 시각적 정보와 함께 상기 편집 그래프를 지원하는 수단을 구비하고 있으며,

상기 시각 정보와 함께 상기 편집 그래프를 지원하는 수단은 시각적 정보 없이 적어도 하나의 편집 그래프를 지원하기에 적합하여 실행 그래프가 상기 펀집 그래프가 시각적이 아니어도 또는 단지 사용자에게 부분적으로 시각적이어서 상기 편집 그래프로부터 만들어 질 수 있는 것을 특징으로 하는 서비스 창조 및 제공 시스템.
네트워크의 사용자에게 사용가능한 서비스를 창조 및/또는 수정하는데 사용되는 소프트웨어 툴의 세트를 구비하고, 하나 이상의 서비스 창조 환경의 한 레벨로 구성되고, 이 레벨은 서비스 창조 시스템이 제공하는 운영의 선택된 설정이 여러 레벨에서 사용가능할 수 있게 되도록 서로 관련된 다양한 툴세트를 가지고 있고, 상기 레벨중 적어도 두 개에는 각 각 소프트웨어 엔티티의 여러 타입을 발생 또는 액세스하는 수단이 구비되어 있고, 상기 레벨의 첫번째에는 네트워크의 성분내에서 전개될 수 있는 소프트웨어 대상으로 구성되는 서비스 애플리케이션을 발생 또는 액세스하는 수단이 있고, 상기 레벨의 두번째에는 시장가능성 있는 서비스 특징을 발생 또는 액세스 하는 수단이 있으며, 시장성있는 서비스 특성 각 각은 그래픽적인 인터페이스에 의해 상기 서비스애플리케이션 특성의 제공가능한 측면을 수정 또는 부과하는 그래픽적인 정의 데이터와 함께 상기 첫번째 레벨의 하나 이상의 서비스 애플리케이션 특성에 관련되며, 그리고 상기 두번째 레벨에는 상기 레벨의 세번째와 통신가능한 서비스 패키지을 발생 또는 액세스하는 수단이 더 있으며, 서비스 패키지 각 각은 시장가능성 있는 서비스 특성을 구비하고 또는 상기 시장성있는 서비스 특성들 간의 미리설정된 관계와 함께 시장서있는 서비스 특성의 세트에 관련되며, 서비스를 이루는데 시장가능서있는 서비스 특성의 조합을 발생 또는 수정하기 위해 상기 레벨의 세번째에서 사용자에 의해 운영상에 강제가 부여되는 것을 특징으로 하는 통신망용 서비스 창조 시스템.
제 2 항에 있어서,

상기 미리결정된 관계는 서비스 패키지내에 표현된 편집 그래프에 따라 URL 기준으로 결정되고 그래픽적인 스크린 설계를 결정하여 상기 세번째 레벨에서 상기 강제가 부여되는 것을 특징으로 하는 시스템.
제 2 항 또는 제 3 항에 있어서,

상기 두번째 레벨은 미터특성을 발생 또는 액세스하는 수단을 더 가지고 있는데, 각 미터특성은 상기 첫번째 레벨의 하나 이상의 서비스 애플리케이션을 가리키나 상기 세번째 레벨에서 사용자에게 어느 미터특성의 측면으로 수정 목적으로 인터페이스 정보가 제공되지 않도록 하는 데이터상의 그래픽적인 정의는 포함하지 않는 것을 특징으로 하는 시스템.
제 4 항에 있어서,

서비스 패키지는 시장성있는 서비스 특성, 또는 하나 이상의 그것과의 관계 또는 그것으로의 관계의 세트로 구성되는 것을 특징으로 하는 시스템.
제 4 항에 있어서,

서비스 패키지는 미터특성, 또는 그것과의 관계 및 시장성있는 서비스 특성이 아닌것 또는 그것으로의 관계의 세트로 구성되는 것을 특징으로 하는 시스템.
통신망을 통해 사용자에게 사용가능한 서비스를 창조, 수정 및 주문에 맞추는 다중-레벨 서비스 창조 환경에 있어서, 상기 환경은 적어도 세 개의 레벨로 구성되는데, 첫번째 레벨은 서비스 애플리케이션 특성으로의 액세스를 구성하거나 또는 액세스를 하고, 서비스 애플리케이션 특성은 사용자에게 서비스를 공급하는데 사용되는 네트워크 성분상에서 전개될 수 있는 재사용가능한 코드 대상으로 구성되어 있고, 각 각의 서비스 패키지는 시장성있는 서비스 특성으로 구성되거나, 또는 서비스를 제공하기위한 실행에서 사용되는 시장성있는 서비스 특성의 주문 및/또는 조합에 관한 강제와 함께 시장성 있는 서비스 특성으로의 참고로 구성되고, 시장성있는 서비스 특성 각 각은 스크린 정의 데이터와 함께 하나 이상의 서비스 애플리케이션 특성으로의 참조로 구성되고, 상기 레벨의 두번째는 서비스를 제공 또는 주문에 맞추기위해 상기 레벨의 세번째에서 사용자 운영에 의해 서비스 패키지의 전송을 위한 상기 레벨의 세번째와 연결되는 것을 특징으로 하는 다중-레벨 서비스 창조 환경.
통신망상으로 사용자에게 제공될 통신 서비스를 주문에 맞추는데 사용하는 편집 설비를 제공하는 방법에 있어서 :

a) 서비스를 위한 편집 그래프를 발생시키는 단계, 여기서 이 편집 그래프는 하나도 없거나 또는 그 이상의 시장성있는 서비스 특성 및 미리 선택된 관계와 링크된 적어도 하나의 미터 특성을 나타내는 노드 세트로 구성되고, 시장성있는 서비스 특성 각 각은 실행-시간에서 서비스를 제공하는데 사용되는 코드의 하나 이상의 실행가능한 유닛을 식별하고 그리고 상기 그래프를 사용함으로서 서비스를 목적에 맞추는데 사용자가 사용하기위한 스크린 정보를 구비하며, 그리고 미터특성 각 각은 실행-시간에서 서비스를 제공하는데 사용되는 코드의 하나 이상의 실행가능한 유닛을 식별하고;

b) 상기 편집 그래프를 사용자가 사용가능하게 발생시키는 단계; 및

c) 서비스의 제공에서 사용을 위한 실행 그래프를 수신하는 단계를 구비하고, 여기서 실행 그래프는 적어도 하나의 입력 데이터에 의해 목적에 맞추어진 상기 편집 그래프를 구비하고, 상기 사용자가 사용할 수 있는 편집 그래프는 상기 미터 특성이 사용자가 사용할 수 없게되는 모든 미터 특성에 대한 스크린 정보를 포함하고 있는 것을 특징으로 하는 방법.
제 8 항에 있어서,

상기 사용자가 사용할 수 있게 만들어진 편집 그래프는 적어도 하나의 시장성있는 서비스 특성을 포함하는 것을 특징으로 하는 방법.
제 8 항 또는 제 9 항에 있어서,

상기 편집 그래프에 관해 사용자게 사용할 수 있을 시장성있는 서비스 특성의 선택을 구비하고 이 선택으로부터 상기 편집 그래프로 시장성있는 서비스 특성을 선택 및 삽입하는데 사용자가 이용하도록 스크린 정보를 제공하는 것을 특징으로 하는 방법.
제 8 항 내지 제 10 항 중 어느 한 항에 있어서,

상기 스크린 정보는 관련된 시장성있는 서비스 특성을 식별하는 아이콘을 디스플레이하는 아이콘 데이터로 구성되는 것을 특징으로 하는 방법.
제 8 항 내지 제 10 항 중 어느 한 항에 있어서,

상기 스크린 정보중 적어도 하나는 사용자가 상기 편집 그래프로부터 상기 실행 그래프를 발생하는데 사용하는 형태 정보를 구비하는 것을 특징으로 하는 방법.