KR100735908B1 - 통신 시스템 - Google Patents

Abstract

본 발명은 프리젠스(presence) 정보와 관련된 적어도 하나의 사용자를 포함하는 통신 시스템에 관련된 것으로서, 상기 프리젠스 정보는 다수의 파트(part)들을 포함하고, 상기 파트들 중 적어도 하나는 상기 적어도 하나의 파트가 상대하는 하는 애플리케이션을 식별하는 정보를 포함하고; 그리고, 적어도 하나의 사용자와 관련된 프리젠스 정보에 대한 적어도 하나의 엔티티(entity)가 제공되며, 상기 적어도 하나의 엔티티들은 적어도 하나의 엔티티 애플리케이션을 가지고, 상기 적어도 하나의 엔티티는 상기 적어도 하나의 엔티티 애플리케이션에 상대되는 상기 하나의 파트를 획득하기 위해 상기 정보를 사용하도록 된다.

Description

통신 시스템{A COMMUNICATION SYSTEM}

본 발명은 통신 시스템에 관한 것으로, 더욱 상세히는 통신 시스템에서 프리젠스 서비스(presence service)의 규정(provision)에 관한 것이다.

오늘날에 있어서 다양한 범위의 통신 시스템들은 사용자 장비 그리고/또는 시스템과 연계된 다른 노드들 간처럼 2 이상의 엔티티들 사이의 통신을 가능하게 하고 있다.

사용자 단말기 또는 다른 노드에 무선 통신을 제공하는 통신 시스템들이 알려져 있다. 무선 시스템의 일 예는 공중 육상 이동 통신 시스템(PLMN:public land mobile network)이다. PLMN은 일반적으로 셀룰러 네트워크이며, 여기서 기지국(BTS:base transceiver station) 또는 비슷한 액세스 엔티티(access entity) 서비스는 무선 인터페이스를 통한 이동국(MS:mobile stations)과 같은 사용자 장비(UE: user equipment)를 위해서 작동한다. 상기 통신을 위해 요구되는 장비의 운영은 일반적으로 스스로 상호연결될 수 있는 하나 이상의 제어 엔티티들에 의해 제어된다. 하나 이상의 게이트웨이(gateway) 노드들은 상기 PLMN을 다른 네트워크에 연결하도록 지원한다. 다른 네트워크의 예는 또 다른 셀룰러 네트워크, PSTN(public switched telephone network) 그리고 IP(Internet Protocol) 기반 네트워크와 같은 패킷 교환 데이터 네트워크이다. 사용자 장비와 통신 시스템의 다른 구성 장치 간의 통신은 적절한 통신 프로토콜을 따르는데, 프로토콜이란 시스템 내에서 통신이 처리되도록 하는 규칙을 규정한 것이다.

현 3세대(3G) 무선 시스템에서, 모바일 사용자를 위해서 다른 통신 서비스들의 처리를 위한 다양한 서버들이 규정되어 있다. 이러한 것들 중에는 CSCF로 알려진 호 상태 제어 기능(call state control functions)을 제공하는 서버를 포함한다. 또한, 제어 기능은 HSS(home subscriber server) 및 다양한 애플리케이션 서버에 의한 애플리케이션과 같은 엔티티에 의해 제공될 수도 있다. 일반적으로 상기 HSS는 상기 사용자의 프로파일을 영구적으로 저장하기 위한 것으로서, 인증 동안에 사용된다. 예를 들면, 3GPP(3 세대 파트너쉽 프로젝트)에 의해 기술된 3G release 5 아키텍처에서, 이러한 엔티티들은 IMS(IP Multimedia Subsystem)에 있는 것으로 알려질 수 있다.

상기 IMS 네트워크는 3G 아키텍쳐의 허브에 위치하며, 종래의 음성 전화 및 멀티미디어 서비스 모두를 취급하는 IP 기반 네트워크를 지원한다. 상기 3GPP는 3G 네트워크를 위한 코어 세션 시그널링 프로토콜(core session signaling protocol)로서 SIP(Session Initiation Protocol)를 택했다. SIP는 IETF(Internet Engineering task Force)에 의해 개발되었다. 관심 있는 사람들은 상기 IMS 네트워크의 기본 동작을 기술한 3GPP 사양서 24.299를 http://www.3gpp.org/ftp/Specs/Latest-drafts/24229-201.zip에서 "IP Multimedia Call Control Protocol based on SIP and SDP"로 제목 붙여진 SIP 전망으로부터 찾 을 수 있다. SIP는 소스로부터 보내진 모든 메세지 관점에서 보면, 요청/응답 스타일 프로토콜이며, 거기에는 상기 송신 메세지의 수령을 확인하는 목적지로부터의 대응 응답이 존재한다. ( 긍정 응답 ACK 메세지는 어떠한 응답도 보내지지 않은 특별한 경우이다.)

예를 들면, 3G 네트워크에서, 사용자가 자신의 모바일 단말기 스위치를 켜는 첫 순간, 그는 자신의 사용자 ID 또는 네트워크의 어드레스를 단말기가 완전히 연결되도록 하기 전에 등록해야 한다. 이는 상기 단말기에서 SIP '등록' 메세지를 상기 IMS로 전송함으로써 수행되며, 이러한 수행은 사용자 어드레스의 세부사항을 포함한다. 상기 IMS는 S-CSCF(serving call state control function)를 사용하여 이러한 정보를 수신하고, 그리고 처리한다. 이를 이하 "등록"이라고 한다. 상기 등록 메세지는 사용자의 알리어스(alias)와 접속 어드레스 간의 매핑을 제공하기 위해서만 사용되는데, 예를 들면, 알리어스 sip: mikko.lonnfors@sonera.com를 단말기 IP 어드레스에 매핑하는 것이다. 상기 IMS는 SIP에 따라 적당한 긍정 응답 메세지(예로, 200 OK 메세지)를 송신함으로써 상기 등록을 승인한다. 또한, 이전의 등록이 만료될 때마다, 또는 만료되는 중일 때 마다, 또는 사용자의 상태에 변화가 있을 때 다음 등록(재-등록)이 발생한다. 사용자가 다른 사용자와 음성 호출 또는 메세징 세션(메세지를 송신하는 또 다른 방법이 존재하는데, 이는 즉, SIP 메세지와 함께 전송하는 것으로서, 세션 설정이 요구되지 않는 경우이다)과 같은 세션을 수립하기 원할 때, 세션 교섭은 마찬가지로 SIP 하에서 수행될 것이다.

애플리케이션 서버(AS: Application Server)는 IMS를 통하여 인스턴트 메세징, 프리젠스(presence), 로컬 트래픽 리포트, 그리고 회의 기능과 같은 서비스들을 제공할 수 있다. AS는 상기 IMS 네트워크 내에 또는 밖에 존재할 수 있다. 일반적으로, 지원되는 서비스가 써드 파티(third party)에 의해 제공되는 경우에는, 상기 AS는 외부에 존재한다.
상태 정보의 일 특정 예는 프리젠스 정보이다. 예를 들면 프리젠스 서비스에 가입된 사용자 또는 애플리케이션 서버들은 다른 프리젠스 특징/속성들에 대한 요청(장비 및 서비스 제공자에 따라서)을 수락하기 위해서 또 다른 사용자의 성능 및 이용가능성을 결정할 수 있다. 그러나 SIP를 지원하는 시스템들에서, 프리젠스는 '오피스에서 모든 요청을 위해 이용가능', 홈에서 오직 개인 요청만을 위해 이용가능' 그리고 '통화중' (혹은 적어도 그런 식으로 나타남)과 같은 다양한 표시를 추측할 수 있다. 따라서, 프리젠스 정보는 사용자가 전화를 시도하기 전에 다른 사용자의 이용가능을 확인할 수 있게 한다. 상기 프리젠스 서비스는 이용가능/이용 불가능과 같은 정보 이외의 다른 것도 제공할 수 있다. 예를 들면, 시각적이며, 살아 있는, 혹은 음성적인 요소들을 포함할 수 있고, 그리고 게임 세션에 관련된 다양한 이슈들을 묘사할 수 있다.

OMA 8(오픈 모바일 동맹(www.openmobilealliance.org)), 3GPP, 그리고 IETF에서 표준화되고 있는 프리젠스 서비스는 더더욱 집중을 받고 있다. 다수의 프리젠스 인식 애플리케이션은 미래에 더욱 증가할 것이다. 애플리케이션의 수가 증가함에 따라, 프리젠스의 정보 또한 증가할 것이다. 수신 단말기로부터 예상되는 정보의 증가는 프리젠스 정보를 어떻게 처리해야 하는지와 같은 도전을 받고 있는데, 즉 이는 프리젠스 정보의 파트(part)들이 어느 애플리케이션들과 관련이 있는가 이다. 단말기는 하나 이상의 애플리케이션들을 운영할 수 있다. 예를 들면, 단말기는 동적 전화 번호부 애플리케이션, 그리고 게임 애플리케이션을 작동시킬 수 있다.

현 IETF 및 3GPP 모듈에서, 튜플 구조(tuple structure)가 사용된다. 튜플은 어떤 시맨틱(semantic)도 포함하지 않는 '무작위' TUPLE ID를 갖는데, 즉, 튜플의 목적을 기술하는데에는 사용될 수 없다는 것을 말한다. 각각의 튜플에는 다수의 속성이 존재할 수 있다. 더욱이, 서로 다른 튜플들은, 동일한 이름이지만 송신/수신 애플리케이션에 따라 다르게 사용/해독되도록 의도되는 속성들을 가질 수도 있다. 예를 들면, 프리젠스 정보는 2개의 튜플(하나는 게임을 위해서, 그리고 다른 하나는 동적 전화번호부(DPB:dynimic phone book)를 위해서)을 포함할 수 있고, 그리고 이러한 튜플들 각각은 상태 필드를 포함할 수 있다. 동적 전화 번호부(DPB)는 이용가능, 고려중(discreet), 이용불가 라는 상태 값을 인식하도록 디자인되었을 수 있고, 반면에 상기 게임은 상태 값: 슈팅, 죽음, 멈춤, 패배(lost)를 인식하도록 디자인되었을 수 있다. 이 예로부터 알 수 있는 바와같이, 만약 상기 상태 필드가 올바른 의미를 가질려면, 상기 상태 필드는 올바른 애플리케이션에 전송되어야 한다. 그러나 단말기가 2 이상의 애플리케이션을 가진다면 문제가 된다. 수신 단말기는 단지 하나의 애플리케이션만 가지고 있는데, 송신 단말기 또는 프리젠티티(presentity)가 다수개의 애플리케이션들을 가지고 있는 경우 역시 문제가 된다. 상기의 예에서 제시된 데이터가 오로지 DPB만을 가진 단말기에 전송될 경우, 수신 단말기는 어떤 튜플이 DPB 애플리케이션에 대해 의도된 것인지를 결정할 수 있어야 한다.

현재에는, 각각의 애플리케이션에 대해 각각의 튜플들을 체크하고 그의 상태 값들이 상기 애플리케이션에 대해 어떠한 의미를 갖는지를 살펴보는 것 이외에 상기 정보를 올바른 애플리케이션에 전달하는 메커니즘은 없다. 즉 바꿔말하면, 시행 착오법이 채용되고 있다. 하지만, 이러한 방법은 정보의 정확성에 불확실성을 낳는다. 몇몇 경우에 있어서는 하나의 속성에 대해 상기 값이 같은 경우일 지라도, 엉뚱한 애플리케이션에 의해 올바르지 않게 식별되기 때문이다. 이에 대한 일례는 다음과 같다. 송신 단말기는 DPB와 IM(인스턴트 메세징) 애플리케이션을 가지고 있으며, 상태 값:DPB=Closed, IM=Open을 설정하는 경우이다. 참고로 이 일례에서는, 애플리케이션들 모두가 오로지 상태 값 Open 과 Closed 만을 사용한다. 이제, 수신 단말기는 IM 애플리케이션만을 가지고 있지만 상기 DPB와 IM 상태들을 수신하는 경우를 가정하자. 만일, 상기 수신 단말기가 첫 번째 상태 값인 DPB의 상태값을 시도한다면, 상기 수신 단말기는 DPB의 첫 번째 상태 값을 이해하고 이를 IM 애플리케이션을 통해 사용자에게 제공하는 바, 프리젠티티(presentity)의 단말기에서의 IM 애플리케이션이 open 되어있음에도 이것이 closed 되었다고 알리면서 사용자에게 제공하게 된다.

사용자가 서로 다른 사용자의 프리젠스 정보를 얻기 원할 때, 사용자는 프리젠스 서버로부터의 데이터, 즉 프리젠스 정보를 줄이기 위해 필터를 포함할 수 있다고 제안되어 왔다. 이러한 필터들은 관심 있는 사용자의 파트들만을 포함하도록 상기 프리젠스 서버로부터의 데이터를 줄일 수 있다. 상기 튜플 식별자들이 주시자들(watcher)(프리젠스 정보를 요청하는 사용자들)에 의한 필터링 기준으로서 사용되고, 그리고 권한이 튜플 식별에 근거하는 방식은 많은 단점이 있다. 예를 들면 주시되고 있는 사용자가 4 개의 튜플들(T1, T2, T3, T4)를 가지고 있고, 그리고 하나의 주시자는 튜플 T2와 T3에만 관심이 있는 경우, 상기 주시자는 오직 튜플 T2 와 T3만이 그에게 통지되게끔 필터를 설정할 수 있다. 그러면 상기 주시되는 사용자는 모든 튜플들을 고려하는 특정한 주시자에 대해서는 여러 이유로 다른 값들을 표시하길 시작하도록 결정할 것이다. 따라서, 상기 주시 되는 사용자는 새로운 튜플들 T5, T6, T7, 그리고 T8 과 새로운 액세스 리스트(access list)를 생성하여, 상기 주시자에게 튜플 T1-T4가 아닌 튜플 T5-T8이 보이도록 할 것이다. 그러나 상기 주시자는 상기 튜플 식별자에 근거하여 필터링을 설정하였기에, 어떠한 튜플들도 그에게는 제공되지 않는다. 이는 단점이다.

필터링에서 튜플 식별자를 사용하는 또 다른 단점은 일반적으로 상기 프리젠티티는 특정한 주시자가 다른 주시자 만큼 자세한 정보를 얻도록 허용되지 않는다는 점, 또는 다른 별개의 그룹에게 제공된 정보가 다른 주시자에게 제공된 정보와는 경미하게 또는 완전히 전혀 다르다는 점을, 주시자에게 알려지길 원하지 않는다는 것이다.

만약 필터링 세팅이 매 시간마다 바뀌게 되면, 상기 주시자에게 제공되었던 정보의 다른 세부 단계도 바뀌기 때문에, 주시자의 권한 정보도 바뀌게 되는 점은 단점이다. 이는 상기 필터링이 유일한 튜플 식별자에 근거하는 경우일 수 있다.

본 발명의 실시예는 상기 문제들 하나 이상을 극복하기 위함이다.

본 발명의 일 양상에 따르면, 프리젠스 정보와 관련된 적어도 하나의 사용자를 포함하는 통신 시스템이 제공되는데, 상기 프리젠스 정보는 다수의 파트들을 포함하고, 상기 파트들 중 적어도 하나는 상기 적어도 하나의 파트를 상대하는 애플리케이션을 식별하는 정보를 포함한다.

본 발명의 제 2 양상에 따르면, 관련 사용자를 위해 프리젠스 정보를 제공하는 단계를 포함하는 통신 방법이 제공되며, 여기서 상기 프리젠스 정보는 다수의 파트들을 포함하고, 상기 파트들 중 적어도 하나는 상기 적어도 하나의 파트를 상대하는 애플리케이션을 식별하는 정보를 포함하고; 그리고, 적어도 하나의 엔티티는 상기 파트들 중 적어도 하나를 획득하고, 상기 적어도 하나의 엔티티는 적어도 하나의 엔티티 애플리케이션을 가지며, 상기 적어도 하나의 엔티티는 상기 적어도 하나의 엔티티 애플리케이션을 식별하기 위한 정보를 포함하는 파트들을 포함한다.

본 발명의 제 3 양상에 따르면, 통신 시스템에 사용자가 제공되며, 여기서 상기 사용자는 관련 프리젠스 정보를 가지고, 상기 프리젠스 정보는 다수의 파트들을 포함하며, 상기 사용자는 상기 적어도 하나의 파트를 상대하는 애플리케이션을 식별하는 정보를 상기 파트들 중 적어도 하나에 제공할 수 있도록 된다.

본 발명의 제 4 양상에 따르면, 통신 시스템에 엔티티가 제공되며, 여기서 상기 엔티티는 사용자와 관련된 프리젠스 정보의 적어도 하나의 파트를 획득하기 위한 방법을 얻는 적어도 하나의 애플리케이션을 포함하고, 상기 적어도 하나의 파트들은 애플리케이션을 식별하는 정보를 포함하고, 상기 획득 방법은 상기 적어도 하나의 애플리케이션을 식별하는 정보를 포함하는 상기 적어도 파트를 얻도록 배열된다.

본 발명의 실시예에서 가능한 상당히 정적인 필터링 세팅들은 상기 필터가 특정 서버(예로, 프리젠스 목록 케이스에서) 또는 상기와 같은 것에서 저장될 때, 특히 유용하다.

본 발명의 실시예들은 다른 주시자에게는 이용가능한 정보의 다른 레벨(또는 완전히 다른 정보)이 있다는 사실을 주시자로부터 감추는 것을 허용할 수 있다.

본 발명의 실시예들은 예를 들어 필터링 세팅, 또는 더 많은 시맨틱을 프리젠스 정보 구성요소에 제공함으로써 권한이 분리될 수 있는 일부 다른 기능에는 영향을 주지 않으면서 권한을 변경할 수 있게 한다.

본 발명의 실시예들은 상기 주시자에게 "의미 없는" 식별 정보에 대한 요청을 하도록 하는 대신에, 시맨틱적으로 인식할 수 없는 정보를 요청하는 가능성을 제공할 수 있다.

본 발명을 보다 잘 이해할 수 있게 하기 위하여, 그리고 효과적으로 동일한 내용을 전달하기 위하여, 하기의 도면에 대한 예시 방식으로 참조 될 것이다.

도 1은 본 발명이 적용될 수 있는 통신 시스템을 예시한다.

도 2는 본 발명의 실시예를 도식화하여 예시한다.

도 3은 도2의 실시예를 더욱 상세히 예시한다.

도 4는 도 1의 시스템에 대한 IMS 파트를 더욱 상세히 예시한다.

도 5는 본 발명의 실시예를 도식화하여 예시한다.

먼저 도 1을 참조하면, UMTS(Univsersal Mobile Telecommunications System)하에서 동작하는 전형적인 3^rd 세대 무선 통신 시스템이 예시된다. 이 시스템의 중앙(hub)에는 IMS(IP Multimedia Subsystem)(100) 네트워크가 존재하며, 이는 상기 네트워크의 2 이상의 사용자들 간의(또는, 사용자와 네트워크 구성요소(예로, 애플리케이션 서버) 사이의) 호출들 및 모든 종류의 세션을 라우트 한다. 사용자의 예를 들면 모바일 단말기(111), 랩탑(112), PDA(personal desktop assistant)(113), PSTN(Public Switched Telephone Network) 텔레폰(131), 컴퓨터 단말기(123), 애플리케이션 서버(121), 그리고 애플리케이션 서버(122)이다. 상기 IMS는 이러한 호출들을 다루기 위해 IP 기반의 네트워크를 이용하며, 이러한 호출에는 음성 호출(voice call)과 멀티미디어 호출(multimedia call)이 포함될 수 있다.

상기 IMS 네트워크는 상기 사용자들(111,123,113)과 PSTN(130) 및 외부 IP 기반 네트워크(120)와 같은 다른 네트워크 사이에서, 3G 시스템 내의 게이트웨이로서 효율적으로 동작한다. 모바일 단말기와 IMS 네트워크의 다른 사용자들 사이의 시그널링 및 IMS 네트워크 범위 내의 시그널링은 셰선 개시 프로토콜(Session Initiation Protocol : SIP)하에서 수행된다. 이하 특별히 언급되지 않는다면, 메세지에 대한 모든 참조는 SIP 메세지이며, 대문자로 표기된다. 본 발명의 바람직한 실시예는 SIP을 배경으로 하여 설명되지만, 본 발명의 다른 실시예들은 SIP 환경이 아닌 다른 환경에서도 수행될 수 있다는 점을 인식해야 한다.

도 2 및 도3을 참조하면, 본 발명의 실시예를 도식화하여 나타낸다. 도 2는 송신 단말기(10)와 수신 단말기(12)를 나타낸다. 상기 송신 단말기(10)는 프리젠스 정보를 상기 수신 단말기(12)에 제공한다. 또한, 프리젠스 서버가 제공된다. 상기 프리젠스 서버(14) 및 상기 송신 단말기는 때로는 프리젠티티(presentity)로 언급되기도 한다. 상기 프리젠스 서버(14)는 상기 수신 단말기(12)에게 필요한 프리젠스 정보를 제공한다. 상기 프리젠스 서버는 상기 송신 단말기(10)로부터 상기 프리젠스 정보를 수신할 것이다. 상기 송신 단말기(10)와 상기 프리젠스 서버(14) 간의 접속, 그리고 상기 프리젠스 서버(14)와 상기 수신 단말기간의 접속은 네트워크 구성요소, 또는 도면에는 도시되지 않은 엔티티를 통해 이루어질 것이다.

본 발명의 실시예에서, 수신 단말기(12)(상기 기술한 것처럼 임의의 사용자일 수 있고, 그리고 주시자로 언급될 수도 있음) 및 어쩌면 상기 프리젠스 서버(14)가 프리젠스 정보의 다른 파트들을 식별하여, 올바른 애플리케이션에 프리젠스 정보의 파트들을 전송할 수 있게 하기 위해서는, 송신 단말기(10)(상기 기술한 것처럼 임의의 사용자일 수 있고, 주시되는(또는 프리젠티티) 사용자로 언급될 수도 있음)는 프리젠스 튜플을 기록하여야 할 것이다. 특별히 본 발명의 실시예에서는, 시맨틱적으로 의미있는 애플리케이션 식별 정보 필드가 각각의 튜플에 제공되거나, 또는 적어도 일부의 튜플에게 제공된다. 이러한 필드는 애플리케이션 ID 필드 라고 언급될 수 있다. 상기 정보는 신원(identity) 그 자체 일수 있거나, 또는 신원(identity)에 관계된 정보일 수 있다. 상기 전송 애플리케이션은 애플리케이션별 특정 식별자를 상기 애플리케이션 식별 정보 필드에 삽입하는 바, 이는 수신단에서 인식될 수 있다. 상기 수신 단말기는 상기 튜플들을 상기 애플리케이션 ID 필드에서 식별된 상기 수신 단말기 내의 애플리케이션에 전송한다.

이는 도 3에서 참조와 함께 더욱 상세히 기술될 것이다. 단계 1에서, 상기 송신 단말기 내에 있는 상기 애플리케이션들(16a, 16b, 16c)은 자신들의 애플리케이션 식별을 상기 단말기내의 프리젠스 엔진(18)에 등록한다. 이 단계 다음에, 애플리케이션은 정보 알림을 시작하는데, 정보 알림이란 정보를 프리젠스 서버로(그리고 상기 주시자가 프리젠스 가입(subscription)을 한 경우 서버에서 상기 수신 단말기로) 전송하는 것을 말한다. 도 3의 예시에서, 상기 단말기는 3개의 애플리케이션을 가진 것으로 나타난다. 이 예시와 같이, 그리고 단말기 또는 다른 사용자들은 3개 보다 많거나 혹은 적은 애플리케이션을 포함할 수 있다.

단계 2에서, 각각의 애플리케이션(16)은 프리젠스 정보를 하나 이상의 튜플들을 포함하는 형태로 알리고, 프리젠스 엔진은 애플리케이션 ID를 각각의 튜플에 첨부한다. 그 후에 상기 프리젠스 엔진(18)은 상기 정보를 상기 프리젠스 서버(14)에 전송한다. 대안적인 실시예에서, 상기 애플리케이션은 애플리케이션 ID의 첨부를 직접 할 수도 있다.

단계 3에서, 상기 수신 터미널(12)의 프리젠스 엔진(20)은 상기 프리젠스 서버(14)로부터 새로운 프리젠스 정보의 NOTIFY 메세지를 받을 수 있다. 애플리케이션 ID(각각의 튜플에 전달됨)에 따르면, 상기 튜플들은 상기 프리젠스 엔진에 의해 수신 단말기의 대응 애플리케이션으로 라우트된다. 대안적으로, 각각의 애플리케이션은 모든 튜플을 수신할 수 있으나, 엉뚱한 애플리케이션 식별을 가진 임의의 튜플들은 무시할 것이다.

따라서, 모든 애플리케이션은 그 자신의 애플리케이션 ID를 가질 것이다. 예를 들면, 게임1, 게임2, SMS, IM-1, IM-2, 이메일이다. 만약 2개의 단말기(1 및 2)가 동일 애플리케이션, 예로 IM-1을 갖는 경우, 상기 애플리케이션 ID는 상기 애플 리케이션에 대해 동일하다. 그러나 만약 터미널(3)이 IM-2(예를 들면, 또 다른 벤더에 의해 제작된)에 의해 식별되는 애플리케이션을 갖는 경우, 상기 애플리케이션은 터미널(1 및 2) 내의 IM-1 애플리케이션과 다른 애플리케이션 ID를 가질 것이다. 그러한 경우에, 제공된 속성은 다른 애플리케이션에 의해서도 사용될 수 있으나, 그러나 속성들 또는 그들의 값들이 올바르게 인식되지 않을 수 있기 때문에 주의가 필요하다. 이에 대한 일 예로는 IM에 대해 2개의 다른 클라이언트가 존재하는 경우이다. 기본 기능은 같을 수 있기에, 따라서 상태 속성은 애플리케이션이 나머지 속성들을 적절히 또는 완전히 부적절하게 해석할지라도 유효할 수 있다.

상기 튜플들이 상기 애플리케이션 식별을 포함하기 때문에, 효율적인(애플리케이션별로 특정된) 필터링 능력을 제공할 수도 있고, 그리고 또한 상기 튜플을 상대하는 올바른 애플리케이션을 발견할 수도 있게 된다.

튜플들은 draft-impp-cpim-pidf-05.txt 에 제시된 바와 같은 일반적인 구조를 갖으며, 이는 http://www.ietf.org/internet-drafts/draft-ietf-impp-cpim-pidf-05.txt 에 링크되어 있다. 그러면 애플리케이션은 새로운 XML 네임스페이스(namespace)를 정의함으로써 "include additional information)" 옵션을 확장할 수 있다. XML은 Extensible Markup Language 을 뜻한다(이는 SGML에 기반한 World Wide Web-a markup language이며, 그리고 HTML의 한계를 극복하기 위해 디자인되었다. 페이지가 구성 요소들 및 그들의 문맥을 위해 정의 및 실행 계획을 포함하도록 한 것이다.).

상이한 튜플들이 상이한 애플리케이션과 함께 사용될 수 있도록 누군가가 혹 은 무엇이 정의했을지라도 변화될 수 있는 것이다. 이는 애플리케이션의 타입에 의존할 수 있는 것이다. 일부 또는 모든 튜플들이 표준 포맷(표준 속성이 예를 들면 3GPP표준으로 정의될 수 있음)을 갖도록 정의될 수 있다. 대안적으로 혹은 추가적으로, 애플리케이션 개발자가 그들 자신의 튜플들을 정의할 수도 있다.

일반적으로, 튜플들의 개수 및 하나의 프리젠티티가 가질 수 있는 튜플들 내의 속성의 개수에는 제한이 없다.

상기 애플리케이션 ID를 각각의 튜플에 놓는 엔티티들은 상기 정보를 알리는 프리젠스 엔진 또는 애플리케이션일 수 있다. 본 발명의 일부 실시예어서, 상기 애플리케이션 ID의 유일성은 그것의 등록을 요한다. 상기 애플리케이션 ID의 유일성은 다른 애플리케이션 및 시맨틱 의미를 요구하는 정보의 다른 수집 내에 있는 경우일 수 있다.

상기 애플리케이션 ID는 다중 값 지원 및 필터링에서 사용될 수 있다. 예를 들면, 상기 애플리케이션 ID는 정보의 상이한 "정확도" 레벨을 감추기 위해 사용될 수 있다. 명확히 말하면, 상기 애플리케이션 정보는 다른 애플리케이션들이 동일 애플리케이션 ID를 사용하지 않는다는 관점에서 보면 유일하나, 상기 동일한 애플리케이션 ID가 프리젠스 서버의 상이한 튜플들의 문맥에서 여러 번 나타날 수도 있다는 것을 의미한다. 예를 들면, 상기 튜플 ID는 유일하나, 프리젠티티의 프리젠스 정보 상에서 2개 또는 3개의 튜플들 내에 동일한 애플리케이션 ID가 존재할 수 있다. 그러면 상기 애플리케이션 ID는 필터링에 사용될 수 있다. 다른 말로 하면, 상기 주시자(수신 단말기)는 필터를 설정함으로써, 주시자가 상기 주시 되는 사용자( 프리젠티티)의 모든 이용가능한 프리젠스 정보를 수신하지 않게 된다. 상기 주시자가 특정 애플리케이션을 위한 프리젠스 정보만을 수신할 수 있게 하기 위해, 상기 필터가 특정 프리젠스 정보 또는 상기 2개를 조합하여 필터 하게끔 설정될 수 있다.

예를 들면, 만약 "user provided location"와 관련된 모든 튜플들을 제공하도록 필터링이 설정되었다면, 하기의 튜플들이 주시자(watcher)에게 제공된다.(프리젠티티에서 프리젠스 서버로 제공되는 경우)

Presentity=ABC

TUPLE 1

tuple-id: xyz3226

application id = "user provided location"

user provided location = TAMPERE

TUPLE 2

tuple-id: xyb3293

application id = "user provided location"

user provided location = HOME

TUPLE 3

tuple-id: xya3288

application id = "user provided location"

user provided location = x-coord, y-coord

도 5를 참조하면, 제 1 프리젠티티(30)이 튜플1,2,3,4, 그리고 5를 제공한다. 각각의 튜플들은 애플리케이션 ID를 포함하는데, 튜플 1 과 2는 애플리케이션 ID "A"를, 튜플 3과 4는 애플리케이션 ID "B"를, 그리고 튜플 5는 애플리케이션 ID "C"를 갖는다. 주시자(32)가 오직 애플리케이션 "A"만을 필요로 한다고 하자. 그러면 필터(34)는 상기 튜플들을 필터 하여, 상기 사용자(32)에게 튜플 1 및 2를 제공한다. 실제로 상기 필터는 서버 또는 상기 주시자(32)의 일부와 같은 독립된 엔티티의 일부인 프리젠티티의 일부일 수 있다고 인식되어야 한다. 따라서 상기 애플리케이션 ID는 상기 튜플들을 필터하기 위해 사용된다.

상기 튜플들은 별개의 사용자들을 위해 의도될 수 있다. 그러면, 튜플 1, 3, 그리고 5는 일 주시자를 위해 의도된 것 일 수 있고, 그리고 튜플 5는 별개의 주시자를 위한 것일 수 있다. 따라서, 상기 주시자는 튜플 1, 3, 그리고 5만을 볼 수 있게 된다. 결국, 만약 상기 주시자가 오직 애플리케이션 "A"를 위한 튜플들 만을 원한다면, 상기 주시자에게 튜플 1이 제공될 것이다. 상기 필터(34)가 이러한 추가적인 필터링을 제공한다. 본 발명의 일부 실시예에서는, 주시자가 오직 특정 애플리케이션 ID에 상대되는 튜플들만을 획득할 수 있도록 보장하기 위해, 독립적인 필터가 제공되거나, 또는 직접적인 방법이 제공된다.

또한, 별개의 주시자 그룹이 개별적인 그룹에 대해 이용가능한 개별적인 프 리젠스 정보를 갖을수도 있다.

본 발명의 실시예는 애플리케이션들이 프리젠스 정보로부터 상기 특정 애플리케이션이 해석하고, 이해할 수 있는 모든 정보를 쉽게 인식할 수 있게 한다.

본 발명의 실시예에서, 필터링 동작을 수행할 때 상기 애플리케이션 식별자가 상기 프리젠스 서버에 의해 사용될 수 있다는 점을 인식해야 한다. 또한, 본 발명의 일부 실시예에서, 운영자 특정 애플리케이션이 상기 애플리케이션 ID들을 이용할 수 있는 상기 프리젠스 서버에 제공될 수 있다. 예를 들면, 상기 프리젠스 서버는 자신이 인식할 수 있는 튜플내의 일부 속성값들을 수정할 수 있고, 그리고 어느 사용자가 상기 프리젠스 서버에 대해 액세스 권한이 허용되었는지를 알 수 있다.

본 발명의 실시예들이 필터를 하기 위해 사용될 수 있다. 예를 들면, 주시자는, 오직 하나 이상의 특정 애플리케이션과 관련된 프리젠스 정보의 파트만을 요청할 수 있다. 상기 필터링은 주시되고 있는 프리젠티티에 의해 -상기 사용자 또는 상기 프리젠스 서버에 의해, 상기 주시자에 의해, 또는 임의의 다른 엔티티에 의해- 수행될 수 있다. 프리젠스 정보가 특정 프리젠티티에 의해 특정 주시자에게 제공될 때마다, 프리젠스 정보가 요구된 애플리케이션에 맞춰 필터 될 수 있도록, 상기 필터 정보는 미리 저장될 수 있다. 상기 필터링은 상기 애플리케이션이 요구되는지를, 상기 애플리케이션이 요구되지 않는지를, 또는 이러한 기법의 조합에 의해서 정의할 수 있다.

상술한 바와 같이, 주시자는 일반적으로 상기에 기술한 바처럼 사용자이다. "프리젠티티"는 사용자 및 상기 사용자와 관련된 프리젠스 서버로 여겨질 수 있다. 상기 프리젠스 서버는 상기 프리젠스 서버와 관련된 상기 사용자를 위한 프리젠스 정보를 저장한다. 실제로, 하나 이상의 사용자가 각각의 서버와 관련되어 있다는 점을 인식하여야 한다. 상기 프리젠스 서버는 종단 장치(단말기)내에 위치할 수 있다.

현재 3GPP에서 정의한 프리젠스 정보는 아래에 서술할 다음과 같은 정보를 포함할 수 있지만, 상기 정보는 이러한 것들 및 stage 1 (requirements group)으로부터의 요구사항들에 한정되는 것은 아니며, 프리젠스를 확장시키려는 개념을 개발하기 위한 표준들이 진행중이다.

가입자(subscriber) 상태; 네트워크 상태; 통신 방법; 접속 어드레스; 가입자 위치 제공; 네트워크 위치 제공; 우선순위를 포함할 수 있다.

또한 프리젠스는 기분, 좋아하는 색깔, 그리고 기타 등등과 같은 다른 정보도 포함할 수 있다.

본 발명이 실시예들이 애플리케이션 식별 정보로 불리는 속성들에 의해서 제한되는 것은 아니며, 비슷한 타입의 동작할 수 있는 가능성이 제공된다면 임의의 속성에도 적용될 수 있다는 점을 인식해야 한다.

본 발명의 실시예들이 튜플들의 사용에 제한되는 것은 아니다. 모든 시스템은 아니지만 프리젠스 문서를 구축하기 위해 튜플들을 사용할 수 있으며, 예를 들면 무선 빌리지 프리젠스(wireless village presence)가 속성 레벨에서 프리젠스 정보를 조작할 수 있고, 그리고 애플리케이션 ID가 각각의 독립된 속성과 연결된 경우에도 그러하다.

도 4는 도식화한 IMS 네트워크(100)를 나타낸다. 상기 IMS는 다수의 CSCF(Call state Contrl Function)을 포함하는 다양한 구성요소들을 포함한다. CSCF는 IETF 아키텍처 상에서 SIP 서버와 상응하는 것이다.

질의형 CSCF(I-CSCF:Interrogating CSCF)(201)는 상기 IMS 네트워크에서 호(call)를 끝내기 위해 사용되는 기본적인 IMS 노드이며, 네트워크 가장자리에서 기능을 수행한다. 여기에는, 모바일 단말기(101), PDA(113), 그리고 애플리케이션 서버(AS)(121)의 외부 노드들과의 통신이 제시된다. 도 1에서 볼 수 있는 바와 같이, I-CSCF에 대한 상기 모바일 단말기, 상기 PDA, 그리고 상기 애플리케이션 서버 간의 접속은 직접적인 것이 아니라, 상기 모바일 단말기를 위한 모바일 코어 네트워크, 및 상기 애플리케이션 서버를 위한 인터넷(120)과 같은 적당한 중간 네트워크를 경유하여 연결될 수 있다.

HSS(202)는 상기 I-CSCF와 CSCF(204) 모두를 인터페이스로 연결하는 중앙 집중 사용자 데이터베이스로서, IMS의 모든 사용자의 정보를 저장한다. 상기 I-CSCF는 새로운 사용자의 인증 및 외부 구성요소로부터 상기 S-CSCF로 메세지들을 전송하기 위해 S-CSCF상의 라우팅 정보를 검색하는 것과 같은 기능을 수행하기 위해 HSS를 사용한다.

상기 S-CSCF는 IMS 사용자와 관련된 서비스들을 호출하는 의무가 있는 IMS 노드이다. 예를 들면, 또한 상기 S-CSCF는 IMS 사용자를 위한 등록 기능을 수행하는데, 이를 통해 사용자 등록을 처리한다. 상기 프리젠스 서버 기능은 애플리케이션 서버처럼 실행된다.

도 4의 설명은 단지 도식화된 표현일 뿐이며, 실제로는 예를 들면 문장으로부터 무언가가 빠진 proxy-CSCF(P-CSCF)와 같이 추가적인 요소들이 존재한다는 것을 인식해야 한다. 본 발명의 실시 예들은 도 4에서 나타난 것과 다른 시스템 내에서도 사용될 수 있다.

프리젠스 패키지(package)가 임의의 사용자의 프리젠스 정보에 가입하기 위해서 사용될 수 있다. 프리젠스 패키지의 시맨틱들은 임의의 사용자가 프리젠스 정보를 위해 상기 프리젠스 서버에 가입 메세지를 송신할 수 있는데, 만약에 그러한 정의된 프리젠스 패키지가 존재하지 않는다면, 상기 프리젠스 서버는 상기 사용자가 가입하기 위해 시도했던 모든 이벤트들을 인식할 수 없다는 것을 의미한다. 결국, 상기 프리젠스 패키지는 프리젠스 서버상에 정의될 필요가 있으며, 정의되고 난 후에는 프리젠스 정보의 변화에 대한 관련 이벤트를 위해 가입 메세지를 수신할 수 있고, 그리고 인식할 수도 있다. 상기 프리젠스 서버는 상기 프리젠스 정보와 연결된 상태를 생성하고, 그리고 상기 프리젠스 정보 상에 어떠한 변화가 발생할 때, 상기 프리젠스 서버는 응답 또는 통지를 개시할 것이다.

본 발명의 실시예가 SIP를 사용하여 3G 문맥으로 기술하였으나, 다른 적당한 시스템 및 인터페이스 프로토콜이 사용될 수도 있다는 점을 인식해야 한다. 특별히, 본 발명의 실시에는 IETF 사양서를 따르는 애플리케이션에서 사용될 수도 있다.

이상 본 발명의 예시적인 실시예들을 기술하였으며, 하기의 청구 범위에 의해 한정된 본 발명의 범위를 넘어서지 않으면서 개시된 해결책을 강구할 수 있는 다수의 변형과 수정이 존재한다.

Claims (25)

1. 프리젠스(presence) 정보와 관련된 적어도 하나의 사용자와, 여기서 상기 프리젠스 정보는 다수의 파트들을 포함하고, 상기 파트들 중 적어도 하나는 상기 적어도 하나의 파트가 상대하는 애플리케이션을 식별하는 정보를 포함하고; 그리고

   상기 적어도 하나의 사용자와 관련된 프리젠스 정보가 제공되는 적어도 하나의 엔티티를 포함하는 통신 시스템으로서, 여기서 상기 적어도 하나의 엔티티는 적어도 하나의 엔티티 애플리케이션을 가지며, 상기 적어도 하나의 엔티티는 상기 적어도 하나의 엔티티 애플리케이션에 상대 되는 상기 적어도 하나의 파트를 획득하기 위해서 상기 정보를 사용하도록 된 것을 특징으로 하는 통신 시스템.
2. 제 1항에 있어서,

   상기 적어도 하나의 엔티티는 상기 정보의 상기 적어도 하나의 파트를 수신하기 위한 수단를 포함하는 것을 특징으로 하는 통신 시스템.
3. 제 2항에 있어서,

   상기 엔티티는 상기 정보의 상기 적어도 하나의 파트를 식별된 엔티티 애플리케이션에 송신하기 위한 수단을 포함하는 것을 특징으로 하는 통신 시스템.
4. 제 3항에 있어서,

   상기 송신 수단은 애플리케이션 엔진을 포함하는 것을 특징으로 하는 통신 시스템.
5. 제 1항에 있어서,

   상기 엔티티는 사용자인 것을 특징으로 하는 통신 시스템.
6. 제 1항에 있어서,

   상기 엔티티는 엔티티로부터의 요청에 응답하여 상기 정보의 상기 적어도 하나의 파트를 수신하는 것을 특징으로 하는 통신 시스템.
7. 제 1항에 있어서,

   상기 적어도 하나의 사용자는 적어도 하나의 애플리케이션을 포함하는 것을 특징으로 하는 통신 시스템.
8. 제 1항에 있어서,

   상기 적어도 하나의 사용자는 프리젠스 엔진을 포함하는 것을 특징으로 하는 통신 시스템.
9. 제 8항에 있어서,

   상기 적어도 하나의 애플리케이션은 상기 애플리케이션을 식별하는 상기 정 보를 상기 프리젠스 엔진에 등록하도록 된 것을 특징으로 하는 통신 시스템.
10. 제 8항 또는 제 9항에 있어서,

    상기 적어도 하나의 애플리케이션 및 상기 프리젠스 엔진 중 적어도 하나는 상기 식별 정보를 적어도 하나의 파트에 부가하도록 된 것을 특징으로 하는 통신 시스템.
11. 제 1항에 있어서,

    상기 사용자는 사용자 장비를 포함하는 것을 특징으로 하는 통신 시스템.
12. 제 1항에 있어서,

    상기 프리젠스 정보는 하기의 정보 파티들: 가입자 상태; 네트워크 상태; 통신 수단; 접속 어드레스; 가입자 위치 제공; 네트워크 위치 제공; 텍스트; 우선 순위; 기분; 좋아하는 색깔 중 적어도 하나를 포함하는 것을 특징으로 하는 통신 시스템.
13. 제 1항에 있어서,

    상기 시스템은 세션 개시 프로토콜(SIP: Session Initiation protocol)에 따라 동작하는 것을 특징으로 하는 통신 시스템.
14. 제 1항에 있어서,

    상기 정보의 파트는 튜플(tuple)을 포함하는 것을 특징으로 하는 통신 시스템.
15. 제 14항에 있어서,

    상기 튜플은 상기 사용자를 식별하는 정보 및 상기 애플리케이션 식별 정보를 포함하는 것을 특징으로 하는 통신 시스템.
16. 제 1항에 있어서,

    상기 엔티티는 상기 엔티티의 하나 이상의 애플리케이션에 의해 처리되는 상기 프리젠스 정보의 오직 하나 이상의 파트들을 요청하도록 된 것을 특징으로 하는 통신 시스템.
17. 제 16항에 있어서,

    오로지 상기 프리젠스 정보의 요청된 파트만을 제공하기 위해 필터링 수단이 제공되는 것을 특징으로 하는 통신 시스템.
18. 제 17항에 있어서,

    상기 필터링 수단은 서버, 프리젠스 서버, 그리고 상기 적어도 하나의 사용자 중 적어도 하나에 제공되는 것을 특징으로 하는 통신 시스템.
19. 제 1항에 있어서,

    상기 적어도 하나의 엔티티는 상기 프리젠스 정보를 필터 하기 위해 상기 정보를 사용하도록 된 것을 특징으로 하는 통신 시스템.
20. 제 1항에 있어서,

    상기 엔티티 애플리케이션은 상기 엔티티 애플리케이션을 식별하는 정보를 포함하는 프리젠스 정보의 적어도 하나의 파트를 처리하도록 된 것을 특징으로 하는 통신 시스템.
21. 프리젠스 정보를 관련 사용자에게 제공하는 단계와, 여기서 상기 프리젠스 정보는 다수의 파트들을 포함하며, 상기 파트들 중 적어도 하나는 상기 적어도 하나의 파트를 상대하는 애플리케이션을 식별하는 정보를 포함하고; 그리고

    적어도 하나의 엔티티가 상기 파트들 중 적어도 하나를 획득하는 단계를 포함하는 통신 방법으로서, 여기서 상기 적어도 하나의 엔티티는 적어도 하나의 엔티티 애플리케이션을 가지며, 상기 적어도 하나의 엔티티가 파트들을 획득하는 단계는 상기 적어도 하나의 엔티티 애플리케이션을 식별하는 정보를 포함하는 것을 특징으로 하는 통신 방법.
22. 제 21항에 있어서,

    상기 통신 방법은 상기 적어도 하나의 엔티티 애플리케이션에서 처리하는 단계를 포함하고, 프리젠스 정보의 적어도 하나의 파트들은 상기 엔티티 애플리케이션을 식별하는 정보를 포함하는 것을 특징으로 하는 통신 방법.
23. 통신 시스템의 사용자 장비에 있어서,

    상기 사용자 장비는 관련 프리젠스 정보를 가지고, 여기서 상기 프리젠스 정보는 다수의 파트들을 포함하며, 상기 사용자 장비는 상기 적어도 하나의 파트를 상대하는 애플리케이션을 식별하는 정보를 상기 파트들 중 적어도 하나에 제공하도록 된 것을 특징으로 하는 통신 시스템의 사용자 장비.
24. 통신 시스템의 엔티티에 있어서,

    상기 엔티티는 사용자와 관련된 프리젠스 정보의 적어도 하나의 파트를 획득하기 위한 적어도 하나의 애플리케이션 획득 수단과, 여기서 상기 적어도 하나의 파트는 애플리케이션을 식별하는 정보를 포함하며, 상기 적어도 하나의 파트를 획득하는 상기 획득 수단은 상기 적어도 하나의 애플리케이션을 식별하는 정보를 포함하여 이루어지는 것을 특징으로 하는 통신 시스템의 엔티티.
25. 제 24항에 있어서,

    상기 적어도 하나의 파트내에서 식별되는 상기 애플리케이션은,

    상기 애플리케이션을 식별하는 정보를 포함하여 이루어진 상기 프리젠스 정보의 적어도 하나의 파트를 처리하도록 된 것을 특징으로 하는 통신 시스템의 엔티티.

Images