멀티미디어 통신 방법

멀티미디어 통신 방법{MULTIMEDIA COMMUNICATIONS METHOD}

본 발명은 전기 통신에 관한 것으로, 보다 구체적으로, 사용자가 라이브 모드(live mode) 또는 타임 쉬프트 모드(time-shifted mode) 중 어느 하나로 대화 메시지를 검토할 수 있도록 하고, 상기 두 개의 모드를 오가며 대화를 변환시킬 수 있으며, 다중 대화(multiple conversations)에 참여하고 추후 검토 또는 처리를 위해 대화 메시지를 보관하는 전기 통신 및 멀티미디어 관리 방법 및 장치에 관한 것이다.

음성 통신의 현재 상태는 타성에 젖어있다. 자동화된 스위칭(automated switching), 높은 대역폭의 네트워크 및 기술들, 예컨대 위성, 광섬유, VoIP(Voice over IP), 무선 및 셀룰러 네트워크에도 불구하고, 사람들이 전화기를 사용하는 방법에는 거의 변화가 없다. 사람들은 여전히 전화기를 들고, 다른 자에게 다이얼을 돌리고, 연결이 성사되기를 기다리고, 그리고 나서 다이얼된 자와의 양방향, 동기화된 대화에 참여하도록 요구된다. 만약 착신자가 대답을 하지 않으면, 연결은 성사되지 않고, 대화는 일어나지 않는다.

착신자가 음성 메일을 구비하는 경우, 고작 단-방향 비동기(one-way asynchronous) 음성 메시지가 남겨질 수 있다. 그러나, 음성 메일을 전달하는 프로세스는 번거롭고 시간을 소비하게 한다. 발신자는 다른 단의 전화기에서 전화벨이 멈추고, 음성 메일 시스템으로 전환되고, 음성 메시지의 인사말을 듣고, 그리고 나서 메시지를 남기도록 요구된다. 현재의 음성 메일 시스템은 또한 착신자에게도 불편하다. 착신자는 그들의 음성 메일에 액세스하기 위해 코드를 다이얼로 입력하고, 일련의 조언들을 거쳐, 큐(queue)에 저장된 임의의 기수신된 음성 메시지를 듣고, 그리고 나서 마침내 발신자의 메시지를 들어야 한다.

종래의 음성 메일 시스템의 또 다른 문제점은 음성 메시지의 조직화(organize) 또는 영구적인 보관이 불가능하다는 점이다. 일부 음성 메일 시스템에서, 사용자는 메시지를 보관할 수 있으나, 기결정된 기간이 지난 후에는 자동적으로 삭제되어 영원히 잃어버리게 된다.

현재의 음성 메일 시스템의 또 다른 문제점은 메시지가 남겨질 수 있기 전에 발신자와 음성 메일 시스템 간의 연결이 구축되어야하는 점이다. 연결이 구축되지 않으면, 발신자는 메시지를 남길 수 있는 방법이 없다.

현재의 전화 시스템은 다음과 같은 상대적으로 단순한 사용 패턴을 기반으로 한다: 실시간 라이브 콜 또는 분해된(disjointed) 음성 메일 메시지로서, 이들은 착신자에게 들려지면 일반적으로 삭제된다. 이러한 형태의 음성 통신은 음성 통신으로 달성될 수 있는 실제 파워(real power)를 포착하지 않거나 최근에 사용가능해진 네트워크 속도 및 대역폭의 발전에 대한 이로움을 취하지 않는다. 또한, 전화 네트워크가 다운되거나 또는 접속불가능한 경우(예컨대, 휴대폰 사용자가 커버리지가 아닌 영역에 있거나 기상 악화로 인해 전화선이 다운된 경우), 통신은 일어나지 않는다.

일반적으로, 전화 기반 통신은 텍스트-기반 통신의 진보와 보조를 맞추지 않았다. 인스턴트 메시지, 이메일, 팩스, 그룹 채팅, 및 텍스트 메시지의 보관을 위한 능력은 모두 텍스트 기반 통신에서는 평범한 것들이다. 이에 반해 음성 메일은은 음성 메시지를 관리하거나 및/또는 보관하도록 하는 툴은 거의 존재하지 않았다. 비교해보면, 현재 전화 통신을 관리하도록 하는 툴은 텍스트 통신에 비해 원시적이다.

통합 환경은 단지 현재의 음성 통신 툴의 결점의 일 예를 제공한다. 통합 자산(corporate asset)으로서 조직화를 거쳐 음성 통신을 관리하는 통합된 방법은 현재 존재하지 않는다. 고용인은 일반적으로 그들의 전화 대화를 기록하거나 지속적으로 저장하지 않는다. 음성 통신 자산과 관련된 대부분의 사업은 임의의 관리가능한 형태로 그들의 대화 내용을 관리하거나 저장하기 위한 방법이 없이, 단어가 말해지자마자 사라진다.

설명적인 예로서, 회사의 판매 중역을 생각해보자. 바쁜 일상 중에, 중역은 매우 많은 전화를 할 수 있으며, 전화를 통해 소비자와 다수의 판매를 완료시킬 수 있다. 이러한 대화를 조직화하고, 저장하고, 추후에 검색하는 기능이 없이 중역은 발생할 수 있는 잠재적인 이슈, 예컨대 다른 자와의 거래의 기간을 기억해내거나 판매에서 이전에 합의된 기간을 다투는 소비자를 환기하는 이슈를 해결할 방법이 없다. 이 중역이 대화를 용이하게 검색하고 검토하는 능력을 구비하였다면, 이러한 타입의 이슈는 쉽고 호의적으로 해결될 수 있었을 것이다.

현재의 전술적인 라디오 시스템, 예컨대 군대, 소방서, 경찰서, 의료기관, 구호 팀, 및 최초 대처자(first responders)에 의해 사용되는 라디오 시스템도 또한 매우 많은 결점으로 고민하고 있다. 대부분의 전술적인 라디오 통신은 메시지의 발신자와 착신자 간의 "라이브" 라디오 연결을 통해 발생되어야 한다. 만약 양자 간에 라디오 연결이 없는 경우, 통신은 구축될 수 없다. 발신자 또는 수신자 중 어느 하나라도 그들의 라디오에 접근할 수 없거나 라디오 회로 연결이 구축되지 않으면, 긴급 메시지는 전송될 수 없다. 따라서 전술적인 통신은 다수의 기본적인 문제를 가지고 있다. (i)메시지 전달의 보증, (ii) 착신자가 실시간으로 듣지 않은 메시지로 돌아가 듣도록 하는 것, (iii) 대화에 참여한 참여자의 단위(granularity)를 제어하고, (iv) 라이브 대화를 위한 신호 강도가 부족한 경우 시스템이 이를 극복하는 것을 위한 방법이 없다. 발신자 또는 착신자 중 어느 하나에게도 기전송된 대화의 메시지를 관리하고, 우선 순위를 매기고, 보관하고, 추후 검색(later retrieve)(즉, 타임-쉬프트)하도록 하는 툴을 가지고 있지 않다.

전술적인 라디오 통신 시스템의 또 다른 문제점은 오직 하나의 메시지만이 채널 당 시간(time per channel)에 전송될 수 있는 점이다. 대형 빌딩의 화재를 예로서 가정하고, 여기에 다수의 팀의 소방관, 경찰관 및 의료진이 동시에 빌딩에 갇힌 요구조자를 구출하고, 불을 끄고, 요구조자들에게 의료 지원을 제공하고, 구경꾼들을 통제한다고 가정한다. 각각의 팀이 동일한 채널을 사용하는 경우, 통신은 복잡해지고 혼란스러워질 수 있다. 하나 이상의 사람이 동시에 전송하는 경우 전송은 "스텝 온(stepped on)"된다. 또한, 높고 낮은 우선 순위 메시지 간의 구별이 불가능하다. 화재가 발생된 빌딩 내부에서 화재를 진화하거나, 갇힌 요구조자들을 구출하는 팀은 다른 팀, 예컨대 구경꾼을 통제하는 팀에 비해 보다 높은 우선 순위를 가져야 한다. 높은 우선 순위의 메시지가 낮은 우선 순위의 메시지에 의해 스텝 온되는 경우, 중요한 통신을 방해할 뿐만 아니라, 빌딩 내의 소방관 및 요구조자들의 생명을 위협할 수도 있다.

메시지를 우선 순위화 하는 기능의 부족에 대한 한 가지 가능한 해결책은 다수의 채널을 사용하는 것이며, 여기서 각각의 팀은 다른 채널을 할당받는다. 그러나, 이러한 해결책은 그들 자신만의 문제점을 발생시킨다. 소방대장은 임의의 시간에 어떤 채널을 들어야하는지 어떻게 결정하는가? 그들이 모두 다른 채널에 있으면 다수의 팀들은 어떻게 다른 팀과 통신하는가? 만약 한 팀이 급한 도움을 요청하는 경우, 다른 팀들이 다른 채널을 듣고 있으면 그들은 어떻게 이러한 상황을 알 것인가? 다수의 채널들이 일부 문제점을 해결할 수 있는 반면, 이는 또한 단일 채널이 사용될 때보다 더 많은 혼란을 야기하고 더 많은 문제점을 만들어낸다.

효율적으로 메시지를 우선 순위화하거나, 다수의 대화가 동시에 일어나도록 하거나, 타임-쉬프팅된 메시지의 전달을 보증하도록 하거나, 또는 추후 검색 및 검토를 위한 대화의 보관 및 저장을 지원하는 관리 툴의 부족은 모두 전술적인 라디오와 관련된 문제점에 기여한다. 군대, 경찰관, 및 소방관과 같은 최초 대처자의 상황에서, 효율적인 통신 툴은 글자그대로 사람과 죽음 간의 차이 또는 임무의 성공 또는 실패를 의미한다. 상술한 화재가 발생한 빌딩의 예는 현재의 전술적인 라디오 통신에 대한 일부 이슈들에 대한 설명에 유용하다. 유사한 문제점이 군대, 경찰, 최초 대처자 및 전술적인 통신을 사용하는 다른 자에게 존재한다.

패킷-기반 네트워크에서, 일반적으로 사용되는 프로토콜은 TCP(Transmission Control Protocol) 및 UDP(User Datagram Protocol)을 포함한다. UDP는 데이터의 빠른 전달을 장점으로 제공하지만, 완결성(completeness)에서는 손실이 있다. 패킷은 목적지에서 가능한 한 데이터를 넘겨주도록 하고자 하는 경우, 통과(transit)가 감소하고 사용불가능해질 수 있다. 이러한 단점에도 불구하고, UDP는 그 속도적 특징에 기인해 VoIP(Voice over Internet Protocol) 전송에 대한 표준을 이룬다. 반면 TCP는 데이터의 완전한 전달(즉, 전송된 데이터의 정확한 카피)을 보증하지만, 지연(latency)에서는 손실이 있다. 모든 패킷은 그것이 얼마나 걸리는지에 관계없이 전달된다. 이러한 지연은 TCP를 "라이브" 전화 통화에서의 사용에 부적절하게 만든다. 현재 이들 TCP 및 UDP 둘 모두의 성능적 장점을 제공하는 프로토콜은 존재하지 않으며, 여기서 "충분히 우수한" 미디어는 미디어의 완전한 카피의 종국적 전달과 함께 렌더링을 위해 가능한 한 전송될 수 있다. 또한 네트워크 상의 착신자의 존재 및 라이브 또는 타임-쉬프트 모드 중 어느 하나에서 데이터를 렌더링하는 그들의 의도를 기반으로 얼마나 많은 정보가 네트워크를 통해 전달되어야 하는지 결정하는 프로토콜은 존재하지 않는다. 또한, 일반적으로 고려되는 다른 팩터, 예컨대 네트워크 지연(network latency), 네트워크 저하(network degradation), 패킷 손실, 패킷 손상, 및 일반적인 대역폭 조건은 얼마나 많은 데이터가 전송되어야 하는지 결정하는 것에 사용된다. 그러나 종래의 시스템은 착신자의 존재 및 의도를 고려하지 않는다. 그 결과, 데이터가 실시간으로 착신자에 의해 렌더링되는 것을 기본 가정으로 한다. 착신자가 데이터를 즉시 렌더링하지 않는 경우, 이러한 종래의 시스템들은 이들이 필요하지 않은 경우에도 불필요하게 대역폭을 사용하고, 네트워크의 전반적인 성능을 저하시킨다.

상술한 바로 인해, 전화, 음성메일 및 전술적인 음성 통신 시스템은 부적절하다. 따라서, 향상된 음성 및 미디어 통신 및 관리 시스템 및 방법과, 패킷-기반 네트워크를 통한 향상된 음성 및 다른 미디어의 전달이 요구된다.

본 발명은 제 1 통신 장치에서 통신하기 위한 통신 방법에 관한 것이다. 상기 방법은 상기 제 1 통신 장치에서 네트워크를 통해 하나 또는 그 이상의 참여자와의 대화의 미디어를 수신하는 단계 및 상기 미디어가 상기 네트워크를 통해 수신됨에 따라 상기 수신된 미디어를 상기 제 1 통신 장치에 저장하는 단계를 포함한다. 상기 수신된 대화의 미디어는 거의 실시간 모드 또는 타임-쉬프트 모드 중 어느 하나로 렌더링(rendering)될 수 있다. 상기 미디어의 렌더링은 상기 제 1 통신 장치에서 상기 저장된 미디어를 검색하고(retrieving), 상기 검색된 미디어를 증가된 렌더링 레이트로 스토리지로부터 렌더링하고, 상기 증가된 레이트로의 상기 검색된 미디어의 렌더링이 상기 네트워크를 통해 수신되고 있는 상기 대화의 미디어를 따라잡고 이와 실질적으로 동시 발생하는 경우, 캐치업(catch-up) 지점을 확인하고, 상기 캐치업 지점 뒤를 상기 대화의 미디어가 상기 네트워크를 통해 수신됨에 따라 상기 대화의 미디어를 상기 거의 실시간 모드로 렌더링함으로써, 상기 타임-쉬프트 모드에서 상기 거의 실시간 모드로 전환될 수 있다.

본 발명은 첨부한 도면을 참조하여 이어지는 발명의 상세한 설명을 참조로 이해될 수 있으며, 이는 본 발명의 특정 실시예를 설명한다.
도 1은 본 발명의 통신 및 미디어 관리 시스템의 구성도이다.
도 2a 및 도 2b는 본 발명의 통신 및 관리 시스템에서 장치에서 구동하는 클라이언트의 블록도를 도시한다.
도 3은 본 발명의 통신 및 미디어 관리 시스템에서 사용되는 서버의 블록도이다.
도 4a 내지 도 4d는 본 발명의 통신 및 관리 시스템에서 사용되는 데이터 페이로드의 다양한 실시예를 설명한다.
도 5는 본 발명에 따라 공유된 IP 네트워크를 통해 전송되는 데이터를 설명하는 도면이다.
도 6은 본 발명에 따라 회선 기반 네트워크를 통해 전송되는 데이터를 설명하는 도면이다.
도 7은 본 발명에 따라 셀룰러 네트워크 및 인터넷을 걸쳐 전송되는 데이터를 설명하는 도면이다.
도 8a 내지 도 8f는 본 발명의 통신 및 관리 시스템의 저장 및 스트림 기능을 설명하는 일련의 흐름도이다.
도 9a 내지 도 9c는 PQM(Payload Quality Manager)의 동작을 설명하는 흐름도이고, 도 9d 내지 도 9f는 DQM(Data Quality Manager)을 설명하는 흐름도이며, 이들 모두는 본 발명의 클라이언트 및 서버에 의해 사용된다.
도 10은 본 발명의 시스템과 함께 사용될 수 있는 GUI를 구비한 예시적인 장치이다.
도 11a 내지 도 11f는 본 발명의 MCMS(Multiple Conversation Management System) 특징을 설명하는 도면이다.
도 12a 내지 도 12c는 본 발명의 MCMS-C(Multiple Conversation Management System-Consecutive) 특징을 설명하는 도면이다.
도 13a 내지 도 13d는 본 발명의 동작을 상세히 설명하는 일련의 도면을 도시한다.
도 14a 및 도 14b는 본 발명의 클라이언트 및 서버 애플리케이션을 구동하기 위해 사용되는 하드웨어를 설명하는 블록도이다.
본 발명의 상세한 설명에서 사용되는 식별번호는 도면의 구성요소를 나타냄을 알려둔다.

본 발명은 첨부한 도면에 도시된 바와 같이 그 다양한 실시예를 참조하여 상세하게 기술된다. 이어지는 명세서에서, 구체적인 세부사항은 본 발명의 이해를 위해 제공된다. 그러나, 당업자에게 있어서 본 발명이 여기에 기술되지 않은 일부 구현 세부사항을 사용하지 않고도 실현될 수 있음은 명백할 것이다. 또한 본 발명이 불필요하게 불분명해지지 않도록 하기 위해 잘 알려진 동작은 기술되지 않을 것이다.

A. 기능상 개관( Functional Overview )

통신 미디어 관리 방법 및 시스템은 음성 대화에 관여하거나 및/또는 다양한 미디어 타입, 예컨대 음성, 비디오, 텍스트, 위치, 센서 정보, 및 다른 데이터를 사용하여 다수의 동시적인 대화를 관리하는 새로운 모드를 지원한다. 사용자는 음성 메시지를 지정된 착신자에게 송신함으로써 대화에 관여할 수 있다. 선호도 및 우선 순위에 따라, 착신자(들)은 실시간으로 대화에 참여할 수 있거나, 또는 단순히 메시지의 검색이 준비되었음을 통지받을 수 있다. 후자의 경우, 착신자는 그들의 편의에 따라 기록된 메시지를 검토하고 응답함으로써 타임-쉬프트 모드에서 대화에 참여한다.

사용자는 다음 중 어느 하나로 통신을 수행하도록 허용된다: (i) 동기화에 가까운 또는 "라이브" 대화로서, 이는 표준 양방향 전화 통화(standard full duplex phone call)에 유사한 사용자 경험을 제공하며; 또는 (ii) 오가며(back and forth) 통신하는 일련의 시간-지연 전송(즉, 타임-쉬프트 모드). 또한, 대화에 참여한 사용자는 라이브 모드에서 타임-쉬프트 모드로 끊김없이 전환할 수 있고 다시 역으로 전환할 수 있다. 이러한 특성은 또한 각각의 대화에 대해 우선 순위화하고(prioritizing) 두 모드들 간에 이동을 함으로써 사용자가 동시에 다수의 대화에 참여할 수 있도록 한다. 따라서, 상기 시스템을 사용하는 두 명의 사용자는 서로 간에 주고 받으며 기록된 음성 메시지를 송신하고 편리한 때 메시지를 검토할 수 있거나, 메시지는 이들이 필수적으로 라이브의 동기적 음성 대화로 병합되는 비율로 송신될 수도 있다. 본 발명에서는 이러한 통신의 새로운 형태를 가리켜 "복싱(Voxing)"이라고 언급한다.

사용자가 다른 자에게 "복싱"하는 경우, 대화는 일련의 이산적인(discrete) 기록된 메시지로 구성되며, 이는 많은 위치에 기록되며, 그러한 장소는 송신자의 인코딩 장치(예컨대, 전화기 또는 컴퓨터), 네트워크를 걸쳐 호핑(hopping)하는 다중 전송 상의 서버, 및 수신자의 렌더링(rendering) 장치를 포함할 수 있다. 일반적인 전화 통화 또는 음성 메일과 달리, 상기 시스템은 다음과 같은 특징 및 장점을 제공한다: (i)대화는 라이브와 타임-쉬프트 간에 전환될 수 있고 그 역으로도 전환될 수 있으며; (ii) 대화의 이산적인 메시지는 의미적으로(semantically) 함께 스레딩(threading)되고 보관되며; (iii) 메시지가 기록되고 추후 검색을 위해 사용가능해지기 때문에, 주의집중이 일시적으로 대화로부터 전환되고 그리고 나서 편리한 때 대화는 추후에 검토될 수 있으며; (iv)대화는 수 초, 수 분, 수 시간, 또는 수 일까지 정지되고 그만둔 대화를 다시 취할 수 있으며; (v) 사용자는 진행 중인 대화에 다시 참여하고 빠뜨린 메시지를 신속하게 검토하고 현재의 메시지(즉, 라이브 메시지)까지 따라잡을 수 있으며; (vi) 일어날 대화를 위해 전용 회선을 구비할 필요가 없으며, (vii) 마지막으로, 사용자는 단순히 개인 또는 그룹으로의 전송을 시작하여 대화를 개시할 수 있다. 사람 또는 다른 단의 사람이 메시지의 수신을 인지하는 경우, 그들은 실시간으로 대화를 검토하고 수행하거나, 그들의 선택으로 추후에 검토하는 옵션을 가진다.

통신 미디어 관리 시스템은 또한 네트워크를 통한 데이터의 전송을 최적화하는 새로운 모드를 지원한다. 상기 시스템은 네트워크 상태가 이상적이지 못한 경우, 실시간으로 대화에 참여하는 착신자로의 페이로드의 전달을 능동적으로 관리한다. 예를 들어, 네트워크 상태가 열악한 경우, 상기 시스템은 전송을 위한 데이터의 품질을 착신자에 의한 착신에서 렌더링되기에 "충분히 양호한" 상태까지 의도적으로 감소시켜, 대화의 실시간 참여를 허용한다. 상기 시스템은 또한 시간 상에서 메시지의 "정확한" 카피의 종국적인 전달을 보증한다. 따라서 상기 시스템 및 방법은 속도 및 정확성 둘 모두의 장점을 제공한다. 네트워크 대역폭의 이용은 타임라인과 미디어 품질 간의 트레이드오프를 성사시킴으로써 최적화되며, 이는 네트워크 지연, 네트워크 저하, 패킷 손실 또는 손상, 및/또는 현재의 대역폭 상태 뿐만 아니라, 착신자의 존재(presence) 및 착신자(들)이 메시지를 실시간으로 즉시 검토할 의도가 있는지 여부에 대한 의도(intentions)를 사용하여 최적화된다.

대화의 메시지는 오직 음성만을 포함하거나, 음성, 영상 및 다른 데이터, 예컨대 센서 정보를 포함할 수 있음을 주의한다. 메시지가 검토될 때, 이들은 청취되거나 시각적으로 검토되거나, 또는 그 조합이 될 수 있으며, 이는 메시지에 포함된 미디어의 타입에 의존한다. 비록 본원의 출원 당시, 대부분의 대화가 음성만을 포함하더라도, 여기에 기술되는 통신 시스템 및 방법은 광범위하게 다수의 미디어 타입, 예컨대 음성 및 영상을 포함하는 대화를 포함한다.

향상된 음성 및 다른 미디어 통신 및 관리 시스템 및 방법이 하나 또는 그 이상의 다음과 같은 특징 및 기능을 제공하도록 개시된다:

i. 사용자가 다수의 대화 타입에 참여할 수 있도록 하며, 이는 라이브 전화 통화, 컨퍼런스 콜, 음성 메시지, 연속적이거나 동시적인 통신에 참여하도록 하며;

ii. 사용자가 라이브 모드 또는 타임-쉬프트 모드(음성 메시지) 중 어느 하나로 대화의 메시지를 검토하도록 하며;

iii. 사용자가 동기적인 "라이브" 모드 및 타임 쉬프트 모드 간에 대화를 끊김없이 전환하도록 하며;

iv. 사용자가 다른 참여자 또는 네트워크와의 연결 구축을 기다리지 않고도 대화에 참여하도록 한다. 이러한 속성은 사용자가 대화를 시작하고, 대화에 참여하고, 네트워크가 사용 가능하지 않거나, 네트워크가 열악한 상태이거나, 또는 다른 참여자가 유효하지 않은 상태인 경우, 기수신된 타임-쉬프트된 대화의 메시지를 검토할 수 있도록 하며;

v. 시스템이 송신자 측에 미디어 페이로드 데이터를 저장하도록 하고, 네트워크 전송 후, 모든 수신자 측에 미디어 페이로드 데이터를 저장하며;

vi. 시스템이 각각의 메시지가 식별되고 주어진 대화 내의 주어진 참여자에게 결합되어 메시지들을 의미상으로(semantically) 의미가 있는 대화로 순차적으로 스레딩함으로써 메시지를 조직화하도록 하며;

vii. 사용자가 기능, 예컨대 "라이브", 검토하기 용이한 때까지 대화의 일시정지 또는 타임 쉬프팅, 다양한 모드로의 재생(예컨대, 빠른 재생, 라이브로 따라잡기(catch up), 대화의 시작부분으로 점프) 및 대화를 관리하는 방법(보관, 태그달기(tagging), 검색, 및 보관장소로부터의 독출)이 제어되는 사용자의 그룹과 수행되는 각각의 대화를 관리할 수 있도록 하며;

viii. 시스템이 현재 대화를 관리하고 온라인 상태를 포함하여 모든 대화 참여자와 함께 공유하도록 하며, 라이브 또는 타임-쉬프트 모드 중 어느 하나에서 임의의 주어진 메시지를 검토하는 것에 대한 의도, 메시지에 대한 현재 의도, 렌더링 방법, 및 송신자 및 수신자 간의 네트워크 상태를 공유하도록 하며;

ix. 사용자가 동시에 다수의 대화를 관리할 수 있도록 하며, 여기서 (a) 하나의 대화가 현재 진행되고 다른 모든 대화는 일시정지되거나; (b) 다수의 대화, 예컨대 전술적인 통신이지만 이에 제한되지는 않는 대화가 연속적으로 렌더링되거나; 또는 (c) 다수의 대화가 활성화되고 동시적으로 렌더링되며, 예컨대 스톡 교호나(stock exchange) 또는 트레이딩 플로어 환경(trading floor environment)에서 렌더링된다.

x. 사용자가 모든 대화를 저장하고, 원한다면 영구적으로 이들을 실재의 매체에 보관할 수 있도록 하고, 필요에 따라 구조화되고, 인덱스되고, 검색되고, 전사되고(transcribed), 번역되고 및/또는 검토될 수 있는 자산을 제공하며;

xi. 시스템이 가능한 한 즉시 렌더링하기에 "충분히 양호한" 비율로의 메시지 전달의 최적 모드(best-efforts mode)를 사용하는 실시간 콜 기능을 제공할 수 있도록 하고(UDP와 유사함), 근원적으로 저장된 완전한 카피로부터 임의의 잃어버리거나 결함이 있는 데이터를 재전송하도록 요구함으로써 전송됨에 따라 메시지의 정확한 카피의 종국적인 전달이 보증되도록 하며(TCP와 유사함);

xii. 시스템이 타임라인 및 미디어 품질 간의 트레이드오프를 수행함으로써 네트워크 대역폭의 이용을 최적화할 수 있도록 하며, 이는 네트워크 지연, 네트워크 저감, 패킷 손실 또는 손상, 및/또는 현재의 대역폭 상태 뿐만 아니라 착신자(들)의 존재 및 의도(즉, 실시간으로 미디어를 검토하거나 타임-쉬프트 모드로 검토하는 의도)를 이용하여 최적화하도록 한다.

다양한 실시예에서, 상술된 일부 또는 전부의 많은 특징 및 기능이 구현될 수 있다. 그러나, 본 발명의 다른 실시예는 상술된 특징 및 기능의 전부를 포함할 필요는 없음을 확인한다.

B. 용어 정리( Glossary )

본 발명을 상세하게 설명하기 전에, 명세서에 사용되는 일부 용어 및 두문자를 정의하는 것이 유용하다. 이러한 용어 정리는 시스템 컴포넌트, 미디어, 미디어 관리, 사람들 및 대화 관리의 그룹으로 조직화된다.

B.1. 시스템 컴포넌트( System Components )

클라이언트( Client ) : 클라이언트는 통신 시스템에서 사용자 애플리케이션이며, 이는 사용자 인터페이스, 영구적인 데이터 스토리지, 및 "복싱(Voxing)" 기능을 포함한다. 사용자는 클라이언트 애플리케이션과 상호작용하고, 클라이언트 애플리케이션은 모든 통신(메시지 및 신호) 및 네트워크를 통해 전송되거나 수신되는 페이로드 (미디어) 전송을 관리한다. 클라이언트는 미디어의 인코딩(예컨대, 음성, 영상, 또는 다른 데이터 컨텐츠의 캡쳐링) 및 미디어의 렌더링(rendering)을 지원하고, 네트워크를 걸친 데이터의 전송의 최적화뿐만 아니라 보안, 암호화(encryption) 및 인증(authentication)을 지원한다. 클라이언트는 하나 또는 다수의 사용자(즉, 다수의 차용자(tenant))에 의해 사용될 수 있다.

장치( Device ) : 클라잉너트 애플리케이션을 구동하는 물리적인 장치이다. 사용자는 능동적으로 임의의 주어진 시점에 단일의 장치 또는 다수의 장치에 로그인될 수 있다. 다양한 실시예에서, 장치는 전반적인 목적의 컴퓨터, 휴대용 컴퓨터 장치, 프로그래밍 가능한 전화, 프로그래밍 가능한 라디오, 또는 임의의 다른 프로그래밍 가능한 통신 장치일 수 있다.

서버( Servers ) : 통신 네트워크 상의 컴퓨터 노드이다. 서버는 네트워크 상의 사용자들과 용속적인 스토리지 간에 오가며 전송된 메시지를 라우팅하고, 미디어 페이로드를 보관한다. 서버는 네트워크를 걸쳐 데이터의 전송을 라우팅하고, 트랜스코딩하고, 보안, 암호화 및 인증, 및 최적화를 제공한다.

B.2. 미디어( Media )

메시지( Message ) : 임의의 사용자로부터 다른 사용자로의 통신의 개별적인 단위이다. 각각의 메시지는 음성 또는 영상과 같은 일부 종류의 미디어로 구성된다. 각각의 메시지는 특정 속성이 할당되며, 이는 (i) 메시지를 전송하는 사용자; (ii) 메시지가 속하는 대화; (iii) 선택적이거나 사용자가 생성한 중요 태그(Importance Tag); (iv) 타임 스탬프; 및 (v) 미디어 페이로드를 포함한다.

미디어( Media ) : 오디오, 비디오, 텍스트, 위치, 센서 기록값, 예컨대 온도, 또는 다른 데이터이다.

대화( Conversation ) : 장치 상의 둘 또는 그 이상의 사용자 간의 메시지(식별되고, 영구적으로 저장되고, 그룹화되고, 그리고 우선 순위화된)의 스레드(thread)이다. 사용자는 일반적으로 그들의 장치를 사용하여 실시간 또는 타임 쉬프트 모드로 메시지를 검토하거나, 또는 원하는 경우 대화의 메시지를 생성하여 송신함으로써 대화에 참여한다. 새로운 메시지가 생성된 경우, 이들은 새로운 대화를 정의하거나 또는 기존의 대화에 추가된다.

대화의 헤드( Head of a Conversation ) : 가장 최근의 스피커에 의해 인코딩된 대화의 가장 최근의 메시지이다. 이는 "라이브"로 검토하는 경우 사용자가 대화에 위치된 장소이거나, "라이브로의 점프(Jump To Live)" 특징이 사용된 경우 사용자가 점프하는 장소를 의미한다.

다중 대화 관리 시스템( Multiple Conversation Management System ) 또는 MCMS: 클라이언트 애플리케이션의 일부로서 동작하는 애플리케이션이며, 이는 사용자가 다양한 미디어 타입을 사용하여 다수의 대화에 참여할 수 있도록 한다. MCMS 애플리케이션을 사용하여, 사용자는 현재의 다수의 대화 중 하나의 대화를 선택하고, 여기서 오직 현재 대화의 메시지만이 렌더링된다. 선택된 현재의 대화에 대해, 사용자는 타임 쉬프트 모드에서 일련의 오가는 메시지들로부터 거의 동기적인 "라이브" 모드로 전환할 수 있으며, 이는 일반 전화 대화와 유사하며, 그 역으로도 전환할 수 있다. 선택되지 않은 대화의 메시지는 일시정지된 상태이다. 선택되지 않은 대화에 관한 메시지는 사용자들이 여전히 이들 대화에 참여하고 있는 경우 축적될 것이다. 사용자는 선택적으로 다수의 대화 중에서 현재의 대화를 전환할 수 있고 선택된 현재의 대화의 축적된 메시지를 검토할 수 있다.

다중 대화 관리 시스템-연속적( Multiple Conversation Management System - Consecntive) 또는 MCMS-C: MCMS와 유사하고, 렌더링하고 사용자가 우선 순위의 계층적 시스템(hierarchical system of Priorities)을 통해 연속적으로 다수의 대화를 관리하고 참여할 수 있도록 하는 추가된 특징이 구비되며, 이는 시스템에 의해 자동적으로 관리된다. MCMS-C 애플리케이션은 연속적인 대화의 메시지가 우선 순위화된 순서로 렌더링되도록 하며, 이는 현재 선택된 대화의 메시지만이 렌더링되는 MCMS와 다른 점이다. MCMS-C는 연속적인 대화의 메시지가 우선순위화된 순서로 렌더링되는 것이 중요하거나, 및/또는 비록 메시지들이 낮은 우선 순위 대화에 속하더라도 모든 메시지의 수신이 메시지의 실시간 수신보다 더 중요한 상황에서 특히 적용가능하다. MCMS-C가 적합할 수 있는 상황의 예는 병원, 택시 그룹의 관리, 또는 전술적인 통신을 포함하지만 이에 제한되지는 않는다.

다중 대화 관리 시스템-동시적( Multiple Conversation Management System - Simultaneous) 또는 MCMS-S: MCMS와 유사하고, MCMS-S를 사용하여 가능한, 다수의 대화가 동시적인 렌더링을 위해 선택되는 추가적인 특징을 구비하며, 이 점에서 오직 선택된 현재의 대화의 메시지만이 렌더링되는 MCMS와 다르다. MCMS-S 애플리케이션은 사용자가 다수의 대화를 동시에 청취하고 있는 상황, 예컨대 다른 교환 상의 다수의 브로커를 청취하는 트레이더 및 동시적으로 하나 또는 다수의 브로커에게 교역 요청을 주기적으로 송신하는 상황에 특히 적용가능하다. MCMS-S는 또한 전술적인 통신에서도 적합할 수 있다.

우선 순위( Priority ) : 사용자가 MCMS-C에 참여하고 있는 경우, 시스템이 어떤 메시지를 다음으로 렌더링할지 결정하는 메커니즘이다. 우선 순위는 시스템에 의해 자동적으로 관리된다. 사용자는 기본 우선 순위를 설정하거나, 또는 시스템 우선 순위의 기결정된 세트가 사용될 수도 있다. 하나 이상의 메시지가 동시에 렌더링될 준비가 된 충돌이 발생한 경우, 시스템은 우선 순위를 기반으로 적어도 부분적으로 충돌을 해결하며, 어떤 메시지를 즉시 렌더링하고 어떤 메시지를 타임 쉬프트할지를 결정한다.

태그( Tags ) : 사용자 또는 시스템이 대화 또는 메시지에 할당할 수 있는 속성의 세트로서, 예컨대 제목(회사 이름), 지시어("액션 아이템"), 지시자("대화 요약"), 또는 사용자가 데이터를 검색하거나 조직화하기를 원함에 의한 임의의 다른 라벨이다.

중요 태그( Importance Tangs ) : 메시지가 렌더링될 예정인 경우, 다른 우선 순위 설정에 관계없이 특정하도록 하는 특정 메시지 속성이다. "긴급" 중요 태그는 예를 들어 다른 우선 순위에 우선할 것이다. 이러한 특징은 임의의 시스템이 이러한 특징을 사용하도록 구성하거나 사용불능으로 구성할 수 있어도, 전술적인 시스템에서 중요하게 사용된다.

패킷( Packet ) : 컴퓨터 네트워크를 통해 라우팅될 수 있는 임의의 바이너리 데이터 단위이다. 각각의 패킷은 헤더(메타 데이터) 및 페이로드(미디어 데이터)로 구성된다. 이는 표준 패킷 프로토콜, 예컨대 IP(Internet Protocol), EvDO, UMTS 또는 라디오, 광섬유 또는 유선의 임의의 다른 패킷 기반 네트워크를 포함하지만 이에 제한되지는 않는다.

헤더 또는 패킷 헤더( Header or Packet Header ) : 패킷을 기술하는 패킷의 부분이며; 페이로드, 그 인코딩 타입 및 목적지에 관계된 메타데이터이다.

복스 패킷( Vox packet ) : 시스템 및 방법이 메시지, 미디어 및 다른 신호 정보의 전달을 개량하고 최적화하도록 하는 독점적인 패킷(proprietary packet)이다.

미디어 페이로드 (또는 페이로드 )( Media Payload or Payload ) : 패킷의 실제 미디어 부분이다.

B.3. 미디어 관리( Media Management )

TSD ( Time Shift Delay ) : 복스 패킷의 도달과 장치에서 패킷의 렌더링 간의 시간차이다. TSD는 MTSD를 초과해야한다. TSD는 일반적으로 착신 후 임의의 시간에 대화의 메시지를 검토하도록 선택하는 사용자의 행동에 의해 결정된다.

MTSD ( Minimum Time Shift Delay ) : 지터(jitter) 버퍼 기술을 사용한 지터 프로세싱을 허용하도록 클라이언트에 의해 강제된 타임 쉬프트 딜레이이다. 이는 시스템이 렌더링을 적절한 개수의 패킷이 도달하여 사용가능한 미디어 스트림을 생성할 때까지 지연시키도록 야기한다. 시스템은 일반적으로 적응적으로(adaptively) 시간 상에서 MTSD를 조절하여 네트워크의 변할 수 있는 상태를 보상한다.

렌더링( Rendering ) : 미디어 스트림을 사용자에게 사용자의 사용(예컨대, 음성, 텍스트, 그래픽 디스플레이, 영상, 또는 그 조합)에 적합한 형태로 전달하는 것이다.

믹싱 ( Mixing ) : 하나 또는 그 이상의 미디어 스트림을 렌더링하는 것이다. 예를 들어, 대화의 두 참여자로부터의 미디어 스트림은 렌더링될 때 믹스되어 다수의 사람들이 동시에 말하는 대화와 유사한 사용자 경험을 생성한다.

인코딩( Encoding ) : 사용자(예컨대 음성 또는 영상) 또는 장치에 구비된 다른 것(예컨대 GPS 또는 다른 센서 데이터에 의해 생성된 미디어를 번역하고, 미디어를 클라이언트에 의해 처리될 디지털 데이터를 변환하는 프로세스이다.

적응적 지터 버퍼( Adaptive Jitter Buffer ) : 지터 버퍼 또는 디-지터 버퍼가 패킷 교환 네트워크에 의해 도입된 지터(즉, 시퀀스 패킷의 도달 또는 패킷의 지연된 도달 중 어느 하나)를 카운트하기 위해 사용되어, 네트워크를 통해 전송된 오디오(또는 비디오) 신호의 연속적인 렌더링은 방해 없이 수행될 수 있다. 데이터는 렌더링 전에 버퍼에 저장되어 알맞게 사이즈가 조정된 버퍼의 미디어가 도달하도록 한다. 미디어는 모든 패킷이 수신되기 전에 렌더링될 수 있고, 전달성(currency)의 품질을 트레이드 오프한다. 적응적 지터 버퍼는 그 사이즈를 동적으로 변화시킬 수 있어 지연/품질 트레이드 오프를 최적화한다.

PIMB ( Persistent Infinite Message Buffer ) : PIMB는 "라이브" 데이터의 디-지터링과 보관된 데이터의 저장 및 검색 둘 모두를 수행하는 시간-기반 미디어의 저장을 위한 저장 관리 시스템이다. PIMB는 잠재적으로 무한하고 영구적인 미디어의 저장에 대한 추가적인 속성을 더 포함하낟. PIMB는 일부 또는 모든 참여자 장치 및/또는 서버에서 메시지 및 대화의 복스 패킷의 "정확하거나" 또는 완전한 카피를 유지한다.

PLC ( Packet Loss Compensation or Concealment ) : 미디어 스트림의 렌더링 도중, PLC 컴포넌트는 손실된 패킷을 보상하며, 이는 결과를 인터폴레이팅하여 스트림을 리뷰어(reviewer)로 제공하도록 수행된다. 손실된 패킷은 침묵(silence)으로 렌더링될 수 있거나, 패킷 주변으로부터의 정보는 인터폴레이트된 소리 또는 이미지를 제공하도록 사용될 수 있다. 사용될 특정 방법은 미디어, 사용중인 코덱, 및 다른 알려진 파라미터에 종속될 것이다.

B.4. 사람들( People )

사용자( User ) : 시스템을 사용하도록 허가된 사람이다.

연락처( Contact ) : 시스템의 사용자 또는 비-사용자의 어느 하나의 기록이다. 사용자는 일반적으로 연락처 리스트 상의 멤버와 대화에 참여한다. 비-사용자는 레거시(legacy) 전화, 라디오 또는 다른 비-클라이언트(12)가 사용가능한 장치에 액세스하거나 사용하는 사용자이다.

그룹( Group ) : 다수의 연락처의 연합이다. 연락처는 선택적으로 추가되거나 그룹으로부터 삭제될 수 있다. 대화가 그룹 중에서 일어난 경우, 그룹의 모든 멤버는 참여할 수 있거나 참여하지 않을 수 있다.

채널( Channel ) : 전술적인 통신 시스템에서 일반적으로 사용된다. 채널은 채널에 다수의 연락처를 연합시키는 점에서 그룹과 유사하다.

참여자( Paticipant ) : 대화의 멤버로 식별된 사람이다. 이는 사용자 또는 비-사용자 참여자일 수 있다.

B.5. 대화 관리( Conversation Management )

타임 쉬프팅 ( Time Shifting ) : 타임 쉬프팅은 메시지가 수신된 후 사용자-참여자에 의해 결정됨에 따라 임의의 시간에 임의의 메시지를 재생하는 능력이다. 타임-쉬프팅에 의해, 사용자는 메시지를 다음과 같이 검토할 수 있다: (i)MTSD 후 즉시 렌더링함으로써 요구에 의해 즉시; 또는 (ii) 사용자의 재량으로 메시지를 검토하는 모드에서 타임-쉬프트되어; (iii) 구(old) 대화의 검색, 재구성 등을 위해 보관소로부터; (iv) 지연된 기간 후 먼저 검토될 필요가 있는 다른 높은 우선 순위의 메시지(또는 대화)의 검토를 수용하기 위해; (v) 및/또는 다시 듣고 이해할 메시지를 위해 필요한 경우 반복적으로. 다른 말로, 타임 쉬프팅은 시스템이 MTSD를 부과한 후 임의의 시간에 메시지를 렌더링하는 사용자의 능력이다.

검토( Reviewing ) : 메시지 내의 미디어 컨텐츠를 청취, 시청, 읽기 또는 다른 관찰을 의미한다. 검토는 거의 동기적인 실시간 "라이브 모드" 또는 타임-쉬프트 모드 중 어느 하나로 일어날 수 있다.

의도( Intention ) : (i) 사용자가 대화의 메시지를 가능한 한 즉시 또는 타임 쉬프트 모드로 검토하기를 원하는지 여부를 포착하는 사용자-정의된 속성; 또는 (ii) 사용자의 행동에 의해 함축된 것 중 어느 하나; 또는 (i)과 (ii)의 조합이다.

주의( Attention ) : 지금 사용자가 주어진 대화의 메시지를 검토하고 있는지 여부를 포착하는 사용자 속성이다.

CTL ( Catch Up To Live ) : 대화의 헤드에 있지 않은 사용자가 "라이브(즉, 대화의 헤드)를 따라 잡기 위해(Catch Up To Live)" 보다 신속하게 이전 메시지를 검토하도록 하는 렌더링 모드이다. CTL 특징은 임의의 많은 따라잡기 기술, 예컨대 메시지의 빠른 재생, 메시지의 미디어 내의 간격을 제거, 주저하는 조각(hesitation particles)의 제거 등을 사용할 수 있다. 사용자가 CTL을 구비하는 경우, 시스템은 라이브 대화로 끊김없이 흘러간다. 이는 컨퍼런스 콜, 예컨대 사용자가 대화로부터 일시적으로 그의 주의를 이동시킬 필요가 있으나, 그가 돌아오자마자 전체 대화를 듣고자 하는 상황에서 매우 유용한 특징이다.

따라잡기 모드 ( Catch Up Mode ) : 어떻게 CTL 프로세스가 따라잡을 것인지(즉, 빠르게 재생, 침묵 및 주저하는 부분의 제거, 도는 그 조합) 결정하는 사용자-구성 또는 기구성된 모드이다.

JTL ( Jump To Live ) : 이 특징은 사용자가 그들의 현재 위치에서 대화의 헤드로 점프하도록 한다. 사용자는 일반적으로 그들이 대화 내 그들의 현재 위치와 헤드 간의 메시지 모두를 검토하기를 원하지 않는 경우 JTL 특징을 사용할 것이다.

MCMS 참여자 속성( MCMS Participant Attributes ) : 사용자에 의해 정의되거나, 사용자의 행위로부터 시스템에 의해 해석되거나, 관리자에 의해 할당되거나, 또는 그 조합 중 어느 하나에 의해 주어진 대화에 대한 수신자의 의도, 주의, 우선 순위, 및 렌더링 선호도에 대한 속성의 세트이다. 상기 속성은 다음을 포함하지만 이에 제한되지는 않는다: (i) 수신자가 대화의 메시지로 렌더링하기를 원하는 시기에 대한 의도. 가능한 의도 값은 다음을 포함한다: "지금", "타임-쉬프트", "라이브까지 따라잡기(CTL)", "일시정지", 및 "원치 않음(never)"; (ii) 따라잡기 모드로서, 이는 어떻게 CTL 프로세스가 수신자를 라이브까지 따라잡도록 할 것인지(예컨대, 빠른 재생, 침묵 간격 또는 주저하는 곳을 스킵, 또는 일반 속도로 재생) 결정하는 구성 설정이다; (iii) TSD(Time Shift Delay)로서, 이는 대화 상에서 수신자의 현재 위치가 대화의 헤드로부터 얼마나 멀리 떨어져 있는지를 정의하며, 그리고 (iv) 수신자의 다른 대화에 관한 메시지의 우선 순위이다.

C. 시스템 구성( System Architecture )

도 1을 참조하여, 본 발명의 일 실시예에 따른 통신 및 미디어 관리 시스템의 블록도가 도시된다. 시스템(10)은 다수의 클라이언트(12 ₁ 내지 12 _n )를 포함하며, 이는 장치들(13 ₁ 내지 13 _n )에서 각각 구동한다. 장치(13)는 통신 서비스 네트워크(14) 상에서 다른 장치와 통신하며, 하나 또는 그 이상의 서버(16)를 포함한다. 하나 또는 그 이상의 네트워크(18 ₁ 내지 18 _n )는 다수의 장치들(13 ₁ 내지 13 _n )을 통신 서비스 네트워크(14)와 결합하도록 제공된다. 다양한 실시예에서, 네트워크(18)은 PSTN(Public Switched Telephone Network), CDMA 또는 GSM을 기반으로 한 셀룰러 네트워크 예컨대 인터넷, 전술적인 라디오 네트워크, 또는 임의의 다른 통신 네트워크일, 또는 그 조합일 수 있다. 통신 서비스 네트워크(14)는 다양한 네트워크(18 ₁ 내지 18 _n )의 위에 있는 네트워크 레이어이거나 그와 통신하는 다른 네트워크이다. 다양한 실시예에서, 네트워크 레이어(14)는 이종(heterogeneous) 또는 동종(homogeneous) 중 어느 하나일 수 있다. 클라이언트(12 ₁ 내지 12 _n )는 네트워크(18 ₁ 내지 18 _n ) 및 네트워크(14)를 통해 "복스 패킷(Vox packets)"로 불리는 개별적인 메시지 유닛을 사용하여 다른 클라이언트 및 서버(16)와 통신하며, 이는 이하 상세하게 기술된다.

D. 클라이언트 구성( Client Architecture )

도 2a 및 도 2b를 참조하여, 장치(13)에서 구동하는 클라이언트(12)의 블록도가 설명된다. 도 2a에 도시된 바와 같이, 클라이언트(12)는 MCMS(Multiple Conversation Management System) 애플리케이션(20), 렌더링 및 인코딩 모듈(21), 및 MCMS 애플리케이션 데이터베이스(22)를 포함한다. 도 2b에 도시된 바와 같이, 클라이언트(12)는 PIMB(Persistent Infinite Message Buffer) 리더26)를 구비한 SAS(Store and Stream) 모듈(24), PIMB 라이터(28), PIMB 데이터베이스(30), DNQS(Data and Network Quality Store)(32), 및 미디어 드라이버 및 인코더 하드웨어(34)를 더 포함한다. MCMS 애플리케이션(20) 및 SAS 모듈(24)은 각각 메시지 핸들링 모듈(25a 및 25b)를 통해 서로 간에 통신한다. 클라이언트(12)는 인증-암호화-보안 모듈(40) 및 통신 프로토콜 모듈(44)을 더 포함한다.

모듈(40)은 클라이언트(12)로 "복스" 패킷의 전송하고 클라이언트(12)로부터 복스 패킷을 수신하는 도중 인증, 암호화 및 보안 서비스를 제공한다. 통신 프로토콜 모듈(44)은 데이터를 전송할 때 클라이언트(12)를 구동하는 장치(13)에 연결된 근원 네트워크(underlying network)(18)에 의해 사용되는 네이티브 패킷으로 복스 패킷을 캡슐에 넣고(encapsulate), 데이터를 수신할 때 네이티브 패킷으로부터 복스 패킷을 캡슐에서 뺀다(decapsulate). 모듈(40 및 44)을 사용하여, 멀티-파티(multy-party) 엔드-투-엔드 인증, 암호화 및 보안이 클라이언트(12)들 간에 제공된다. 메시지는 제 1 송신 장치(13)로부터 제 2 수신 장치(13)로의 네트워크(18 ₁ 내지 18 _n ) 및 네트워크(14)를 걸쳐 인증되고, 암호화되고 보안된다.

D.1.1. MCMS 데이터베이스( MCMS Database )

데이터베이스(22)는 시스템(10) 내의 많은 엔티티(entities)에 대한 영구적인 메타데이터를 저장하고 관리하며, 이는 연락처 및 참여자, 대화 및 메시지(라이브 및 저장된), 및 기본 우선 순위, 및 서버(16)에 대한 정보를 포함한다. 또한, MCMS 데이터베이스(22)는 사용자 또는 사용자의 연락처 리스트와 대화하는 모든 참여자의 모멘트-투-모멘트 동작 데이터뿐만 아니라, 사용자의 대화, 존재, 및 상태의 모멘트-투-모멘트 동작 데이터를 저장한다. 예를 들어, 대화 및 메시지에 대해, 데이터베이스(22)는 상태 정보, 예컨대 어떤 대화의 메시지를 사용자가 검토하였거나 검토하지 않았는지에 대한 정보, 그리고 클라이언트(12)가 참여자인 각각의 대화에 대한 CTL 상태, 모든 참여자의 존재 및 상태, 및 다른 네트워크 및 다른 시스템 관리 데이터를 추적한다.

D.1.2. MCMS 애플리케이션( MCMS Application )

MCMS 애플리케이션(20)은 대화에 참여하는 다른 복싱 모드 및/또는 다양한 미디어 및 데이터 타입(음성, 영상, 텍스트, 위치, 데이터 등)을 사용한 다수의 대화의 관리를 지원한다. 사용자는 클라이언트(12)를 사용가능하게 된 장치(client enabled device)(13)를 사용하여 메시지를 지정된 착신자에게 송신함으로써 대화에 개입한다. 선호도 및 우선 순위에 따라, 착신자는 실시간으로 메시지를 검토하거나, 단순히 메시지가 검토를 위해 준비되었음을 통지받을 수 있다. 사용자는 오가는 일련의 메시지로부터 전환할 수 있으며, 이는 타임-쉬프트(음성 메시지) 모드 또는 거의 동기화된 양방향 대화(일반 "라이브" 전화 통화와 유사함)에서 검토된 메시지이며, 그리고 나서 다시 음성 메시지로 돌아갈 수 있다. MCMS 애플리케이션(20)은 다른 진행중인 대화에서 임의의 메시지를 손실하지 않으면서 실시간으로 사용자가 그의 가장 중요한 대화와의 상호작용을 제어하도록 한다. 예를 들어, MCMS 애플리케이션(20)은 사용자에게 그들이 현재 검토하고 있지 않은 대화로부터의 긴급하거나 높은 우선 순위의 통신을 통지한다. MCMS 애플리케이션(20)은 또한 추후 검색을 위해 저장될 모든 대화로부터의 모든 메시지를 사용가능하게 하여, 이들이 임의의 시간에 검토될 수 있도록 한다.

다양한 실시예에 따라, MCMS 애플리케이션(20)의 다수의 상이한 동작 모드가 있으며, 이는 MCMS-C(Consecutive) 및 MCMS-S(Simultaneous)를 포함하며, 이는 각각 메시지의 연속적이고 동시적인 렌더링을 지원한다. 이들 각각의 실시에는 이하 더 상세하게 기술된다. 특별히 특정하지 않은 경우, 용어 "MCMS"는 일반적으로 MCMS 애플리케이션(20)을 의미하도록 의도되며, 이는 전술한 상이한 모드를 포함한다.

MCMS 애플리케이션(20)은 많은 모듈 및 서비스를 포함한 다중-계층(multi-tiered) 구조이다. 모듈 및 서비스는 MCMS 데이터베이스 모듈(20a), SAS 서비스 모듈(20b), 메시징 및 시그널링 서비스 모듈(20c), 사용자 인터페이스 API(Application Programming Interface)(20d), 사용자 인터페이스 모듈(20e), 대화/메시지 관리 서비스(20f), 우선 순위 서비스(20g), 연락처 서비스(20h), 존재/상태 서비스(20i), 및 메시지/신호 서비스(20j)를 포함한다.

D.1.2.1 MCMS 데이터베이스 모듈( MCMS Database Module )

MCMS 데이터베이스 모듈(20a)는 MCMSMS 데이터베이스(22)에 액세스하기 위해 MCMS 애플리케이션(20)에 필요한 모든 기능 콜을 관리하는 서비스 모듈이다.

D.1.2.2 SAS 서비스 모듈( SAS Service Module )

SAS 서비스 모듈(20b)은 MCMS 애플리케이션(20)과 SAS 모듈(24) 간의 통신과 조정(coordination)을 가능하게 하는 기능 콜의 세트를 포함하고, 이는 각각 메시지 핸들링 모듈(25a 및 25b)을 통해 오가며 전달된다. 기능 콜의 세트는 MCMS 애플리케이션(20) 및 SAS 모듈(24) 둘 모두가 사용자에 의해 개시된 때 다양한 복싱 기능을 구현하기에 필요한 대로 동작하거나 및/또는 네트워크 상태에 의해 지시된 대로 동작할 수 있도록 한다. SAS 서비스 모듈(20b)에 의해 수행되는 일부 기능성은 메시지 전송 및 메시지 확인응답(acknowledgments)의 상태, 메시지의 렌더링에 대한 지시, 및 사용자의 상태 및 존재를 유지하고 통신하는 것을 포함한다.

D.1.2.3 메시징 및 시그널링 서비스 모듈( Messaging and Signaling Services Module)

메시징 및 시그널링 서비스 모듈(20c)은 클라이언트(12) 및 서버(16) 둘 모두에서 구동하고, 시스템(10)의 클라이언트(12)와 서버(16) 간의 통신을 가능하게 한다. 메시지, 데이터 및 다른 신호를 포함하는 이러한 통신은 클라이언트(12) 및 시스템(10)이 관리자 통신, 네트워크 상태, 사용자 및 사용자 상태를 추적하도록 한다. 예를 들어, 클라이언트(12)에서 구동하는 메시지 및 시그널링 서비스 모듈(20c)과 서버(16) 간에 송신된 메시지 및 신호의 타입은 사용자의 네트워크 능력, 서버(16)가 클라이언트(12)로 송신하여("높은 워터 마크(high water mark)"를 포함할 수 있음) 전체 메시지 또는 메시지의 일부 부분이 손실되었는지 여부를 결정하는 메시지의 추적, (예컨대 "생성(generating)" 클라이언트에 의해 생성된 대화 당 참여자 당 시퀀스 번호), 사용자가 말하거나 주어진 대화의 메시지를 검토하는지 여부, 사용자가 대화의 헤드에 대해 존재하는 위치, 또는 참여자가 더 이상 대화를 라이브로 검토하고 있지 않은 시간을 포함한다. 클라이언트(12)의 메시지 및 시그널링 서비스 모듈과 서버(16) 간에 송신된 메시지 및 신호의 많은 타입 중 일부가 예로 존재하고, 이는 본 발명을 제한하는 의미로 해석되지 않는다.

D.1.2.4 사용자 인터페이스 API( User Interface API )

사용자 인터페이스 API(20d)는 사용자 인터페이스 모듈(20e) 및 MCMS 애플리케이션(20)의 근원 서비스 간의 프로그래밍 인터페이스를 정의하는 기능 콜의 세트를 정의한다. 사용자 인터페이스 API(20d)는 UI 애플리케이션 지원과 같은 일반적인 목적의 방법 및 사용자 인터페이스가 MCMS 애플리케이션(20)을 동작시키기 위해 필요한 모든 기능 콜을 지원한다. 다양한 실시예에서, 사용자 인터페이스 API(20d)는 클라이언트(12)가 넓은 다양성의 사용자 인터페이스 및 장치 타입, 예컨대 어도비 플래시-기반 및/또는 마이크로소프트 윈도우 애플리케이션, 셀룰러 또는 이동 통신 단말기, 톤(tone)으로 구동되는 PSTN 장치, VUI(Voice User Interface), 및 물리적 라디오 통신 인터페이스를 지원할 수 있도록 한다. 다양한 실시예에서, 사용자 인터페이스 API 모듈(20d)은 매우 유연하고 매우 강제적인 사용자 인터페이스의 디자인이 MCMS 애플리케이션(20)의 기능성을 지원할 수 있도록 한다.

D.1.2.5 MCMS 사용자 인터페이스 모듈( MCMS User Interface Module )

MCMS 사용자 인터페이스 모듈(20e)은 클라이언트(12)의 오디오 및 비디오 사용자 인터페이스의 동작 및 기능을 지원한다. 사용자 인터페이스 모듈(20e)은 사용자 상호작용의 호스트를 지원하고 다양한 상호작용 매체, 예컨대 GUI 스크린의 어레이, 오디오/DTMF 인터페이스, 또는 장치(13) 상의 음성 사용자 인터페이스를 사용하여 구현될 수 있으며, 이들 모두는 사용자가 시스템(10)과 인터페이스하도록 한다. 예를 들어, 지원되는 사용자 상호작용의 부분적인 리스트는: 로그인; 대화 관리, 참여, 및 감시; 대화 렌더링의 제어; 우선 순위의 관리; 및 보관된 대화의 검토를 위한 요구;하는 기능을 포함한다. 이러한 리스트는 예시적일 뿐 본 발명을 제한하도록 해석되지 않음을 명시한다.

D.1.2.6 대화/메시지 관리 서비스

대화/메시지 관리 서비스(20f)는 사용자가 대화의 참여자들 간에 전송되고 수신된 미디어(예컨대, 음성 또는 영상 컨텐츠 메시지)의 수신 및 검토를 관리하기 위해 필요한 모든 정보를 관리하고 유지하는 데이터 구조 및 프로세스를 관리하는 기능의 세트를 정의한다. 메시지는 대화로 조직화된다. 애플리케이션(20)을 구동하는 장치(13)에 의해 송신되거나 수신된 미디어는 수신되는 도중 즉각적인 검토를 위해 사용가능하다. 수신된 미디어는 또한 타임-쉬프트 모드에서의 검토, 대화 관리, 및 보관의 목적으로 기록된다. 대체적인 실시예에서, 메시지 또는 대화는 선택적으로 일시적이도록(transience) 마크될 수 있어, 그들의 요구되는 보유 요건(retention requirements)을 특정한다(예컨대, 일부 메시지는 즉각적인 렌더링을 위한 요건을 넘어 유지되거나 저장되지 않을 것이다). 다른 실시예에서, 미디어는 선택적으로 오직 타임-쉬프트 모드에서만 검토되도록 마크되고 착신 시 즉시 검토되지 않을 수 있다.

대화/메시지 관리 서비스(20f)는 사용자의 각각의 현재 또는 진행중인 대화를 위해 수신하는 클라이언트(12)로의 미디어의 송신이 임의의 시간에 수행되도록 할 수 있고, 수신하는 클라이언트(12)는 이들 메시지를 수신자의 활동 또는 휴지(inaction)에 관계없이 적절한 대화에 끊김없이 결합시킬 수 있다.

대화/메시지 관리 서비스(20f)를 사용하여, 모든 대화가 본질적으로 비동기화된다. 만약 두 명의 사용자가 능동적으로 주어진 대화에 관여되고 사용자가 제어하는 전송들 간의 지연이 최소화되면, 경험(experience)은 현재의 전화기 또는 VoIP 대화와 마찬가지로, 동기적인 양방향 대화 중 하나일 것이다. 어떤 이유든 간에, 사용자가 그들의 참여를 지연시키는 경우, 대화는 비동기 음성(또는 다른 미디어) 메시징 경험으로 이동한다. 대체적인 실시예에서, 대화는 선택적으로 오직 비동기적 메시지 또는 오직 동기적 메시지로서 태그될 수 있다. 이들 경우 중 하나에서, 대화는 태그가 리셋되지 않는 한 두 모드들 간에 이동할 수 없다. 태그가 리셋된 후, 대화는 다시 거의 동기적인 모드(즉, 라이브 또는 실시간)와 비동기 모드(즉, 타임-쉬프트 또는 음성 메시지) 간에 흐를 수 있다.

대화/메시지 관리 서비스(20f)는 점진적인 방식(progressive fashion)에서 메시지의 전송 및 수신을 처리한다. 전송 시, 미디어는 메시지가 동시적으로 인코딩되고 저장되고 전송되는 도중 생성될 수 있다. 다른 말로, 메시지의 전송은 사용자에 의한 미디어의 생성과 함께(즉, 그들의 장치(13)로 말하거나 영상을 생성하는 도중) 동시적으로 발생할 수 있다. 수신 단에서, 메시지의 착신, 저장, 및 렌더링은 또한 점진적으로(progressively) 모두 발생한다. 메시지는 그들이 렌더링될 수 있기 전에 완전히 수신될 필요는 없다. 메시지의 렌더링은 메시지가 전달되고 있는 동시에 바로 MTSD까지 발생할 수 있다. 게다가, 서비스(20f)는 또한 출력되는 메시지의 전송 및 입력되는 메시지의 렌더링을 동시에 수행할 수 있다. 서비스(20f)의 점진적인 성질은 여기에 기술되는 다른 기능 외에 추후 검색 및 검토를 위한 대화의 미디어를 저장하고 스트리밍하는 도중 사용자가 라이브 대화에 관여되도록 할 수 있다.

대화/메시지 관리 서비스(20f)에 의한 메시지의 타임-쉬프팅은 사용자가 이전 메시지를 손실하거나 다른 대화에 참여된 경우, 사용자가 대화에서 "라이브를 따라잡기(CTL)"가 가능하도록 한다. 이러한 타임-쉬프팅 프로세스는 사용자가 그들의 전체 그룹 또는 채널에게 메시지를 반복하도록 하는 요청을 방송할 필요를 제거한다. 더 오래된 메시지는 임의의 시간에 시간을 절약하기 위해 잠재적으로 빠른 속도로 재생될 수 있다. 사용자는 용이하게 그들의 메시지 및 개별적인 메시지 내에서 앞뒤로 스킵할 수 있다. 검토 프로세스는 메시지-우선 순위 기반에서 구성되어 잠재적으로 낮은 우선 순위의 메시지를 스킵하도록 구성될 수 있다.

일 실시예에서, 대화/메시지 관리 서비스(20f)는 또한 특정 참여자(발언자)에 의해 식별되고, 기본적으로 동시에 전달된 대화의 메시지(MCMS-S)를 믹스한다. 선택적인 실시예에서, 사용자는 분리하여 대화의 다른 참여자인 발언자의 전송을 검토할 수 있다.

대화/메시지 관리 모듈(20f)은 참여자 간의 대화 공유를 더 허용하며, 이들은 능동적이거나 보관된 대화로 추가될 수 있다. 일 실시예에서, 대화로 추가된 참여자는 대화로의 액세스가 제공되고 검토를 위한 대화의 이전 메시지를 검색하는 능력을 가진다. 대체적인 실시예에서, 추가된 참여자는 새로운 참여자가 참가된 지점으로부터의 대화의 메시지로의 액세스가 제공되고, 대화의 임의의 이전 메시지로의 액세스는 제공되지 않는다.

대화/메시지 관리 모듈(20f)은 또한 SAS 모듈(24)에 의해 수행되는 모든 렌더링 태스크를 제어하기 위해 사용되는 기능을 관리하도록 구성된다. 이러한 태스크는 애플리케이션(20)을 구동하는 장치(13)를 위해 적절하게 미디어(즉, 음성, 영상 등)를 렌더링하는 것을 포함한다. 이들 렌더링 태스크는 사용자-정의된 기준, 예컨대 빠른 재생, 라이브를 따라잡음(CTL), 침묵 제거, 주저하는 조각의 제거, 주파수 쉬프팅, 및 독립적인 이득 제어를 다자간 대화의 개별적인 송신자로 적용하는 능력에 따라 렌더링할 뿐만 아니라, 믹스된 메시지를 렌더링하는 것(즉, 메시지의 중복(overlapping))을 포함하지만, 이에 제한되지는 않는다.

D.1.2.7 우선 순위 서비스( Priority Services )

우선 순위 서비스(20g)는 사용자가 이들이 관여된 연속적인 대화(즉, MCMS-C)의 우선 순위를 관리하기 위해 필요한 모든 정보를 관리하고 유지하는 데이터 구조 및 프로세스를 관리하는 기능의 세트를 정의한다. 사용자가 많은 연속적인 라이브 대화에 참여하는 경우, 사용자는 대화를 우선 순위화하는 것이 요구된다. 상이한 대화의 메시지가 동시에 렌더링될 준비가 되는 경우 이슈가 발생한다. 알고리즘은 렌더링될 메시지의 능력 및 사용자에 의해 설정된 우선 순위를 고려하여 메시지가 렌더링되는 순서를 결정하도록 사용된다. 알고리즘은 가장 높은 우선 순위의 사용가능한 메시지가 우선적으로 렌더링되는 반면 임의의 동시적으로 사용가능한 메시지는 보다 높은 우선 순위의 메시지의 렌더링을 허용하기에 충분할만큼 자동으로 타임 쉬프트되도록 결정한다. 렌더링 시간이 사용가능해짐에 따라, 시스템은 사용자의 우선 순위에 따라 타임-쉬프트된 메시지를 자동으로 렌더링할 것이다.

D.1.2.8 연락처 서비스( Contacts Services )

연락처 서비스(20h)는 하나 또는 그 이상의 연락처를 인증하고 대화에 결합시키기 위해 필요한 모든 정보를 관리하고 유지하는 데이터 구조 및 프로세스를 관리하는 기능의 세트를 정의하는 모듈이다. 많은 연락처와 결합된 대화의 일부로서 메시지를 송신하는 경우, 모든 연락처들은 메시지를 수신한다.

D.1.2.9 존재/상태 서비스( Presence / Status Services )

존재/상태 서비스(20i)는 시스템의 특정 사용자 및/또는 비-사용자 간의 존재 및 상태 정보를 관리하고 공유하는 데이터 구조 및 프로세스를 유지하는 기능의 세트를 정의하는 모듈이다. 다양한 실시예에서, 존재 및 상태 정보는 대화에 관여된 모든 사용자 및 비-사용자를 위해 유지되며, 클라이언트(12)의 사용자는 연락처 리스트 내의 모든 사용자 및 비-사용자, 또는 기정의된 도메인 내의 사용자(예컨대, 법인 또는 다른 단체의 멤버)에 관여된다. 이러한 예는 단지 설명적일 뿐이며 제한적으로 해석되지 않는다. 존재/상태 서비스(20i) 모듈은 사용자 및/또는 비-사용자의 임의의 기정의된 세트에 대한 존재 및 상태 정보를 관리하고 공유할 수 있다.

존재/상태 서비스(20i)는 사용자가 다른 사용자의 의도, 주의, 및 그들의 임의의 주어진 대화 상의 타임 쉬프트 딜레이(TSD)의 상태를 감시할 수 있도록 한다(즉, 이들이 라이브 대화의 메시지 검토로부터 얼마나 멀리 떨어져 있는지). 일 실시예에서, 프라이버시(privacy) 제어가 존재 및 상태 데이터의 능력에 관여하도록 제공된다. 존재/상태 모듈(20i)은 시스템(10)이 사용자의 행동 및 의도를 매치하는 메시지를 전달할 수 있도록 하는 데이터를 더 제어한다. 예를 들어, 사용자는 라이브 대화를 검토하거나 검토하지 않는 것 중 어느 하나에 대한 의도를 지정함으로써 그들의 상태를 지시할 수 있다. 이에 응답하여, 존재/상태 서비스(20i)는 사용자의 의도에 따라, "라이브" 또는 타임-쉬프트 중 어느 하나로 메시지의 렌더링을 야기하는 명령을 발급한다. 또한, 사용자의 의도는 대화의 다른 참여자와 공유된다. 서비스(20i)는 또한 사용자의 행동으로부터 다른 상태 값을 추측할 수도 있다. 존재 및 상태 정보는 또한 이하 보다 상세하게 기술되는 바와 같이, 네트워크 트래픽 및 대역폭을 최적화하도록 사용된다.

D.1.2.10 메시지/신호 서비스( Messages / Signals Services )

메시지/신호 서비스(20j)는 시스템(10)의 사용자에게 메시징하고 시그널링하는 데이터 구조 및 프로세스를 관리하는 기능의 세트를 정의하는 모듈이며, 이는 특정 메시지 또는 들을수 있는 톤(tones)을 사용한다. 특정 메시지 또는 톤은 예를 들어 메시지 또는 메시지들이 라이브이거나 타임-쉬프트된 경우를 지시하고, 메시지(들)이 어디로부터 오는지, 우선 순위, 및 다른 팩터를 지시하는 지시(indication)를 포함할 수 있다. 메시지/신호 서비스(20j)는 (i) 하나 또는 그 이상의 사용자가 더 이상 능동적으로 대화의 메시지를 검토하지 않는지 여부를 통지하는 기능뿐만 아니라 네트워크 상의 사용자의 존재 또는 부재를 시그널링하며; (ii) 다른 사용자들이 다른 대화에 주의를 기울이거나 그들의 장치(13)에 전혀 주의를 기울이지 않는 경우 다른 사용자에게 "벨을 울리거나(ring)" 통지하여 그들의 주의를 집중시키며; (iii) 현재 네트워크(18)에 있지 않은 사용자를 위해 메시지를 남겨 다음에 개인이 네트워크(18)에 재접속하면 즉시 메시지를 검토하도록 하며; (iv) 송신된 메시지가 착신자(들)에 의해 수신되지 않음을 송신자에게 경고하는 들을 수 있거나 볼 수 있는 피드백을 생성하고, 메시지가 착신자(들)에 의해 수신되면 확인을 생성하고, 및/또는 메시지가 착신자(들)에 의해 청취된 때를 지시하는 확인을 생성하고; (v) 컨퍼런스 또는 전술적인 콜을 받는 개인이 그들의 주의가 상기 콜에 즉시 필요함을 통지받는 우선 순위 구조를 구현한다. 이러한 지시는 다수의 레벨의 긴급도(urgency) 및 착신자에 의한 일부 종류의 확인응답(acknowledgement)을 전달할 수 있다.

D.1.2.11 렌더링 및 인코딩( Rendering and Encoding )

렌더링 및 인코딩 모듈(21)은 MCMS 애플리케이션(20)에 대한 모든 렌더링 태스크를 수행한다. 이러한 태스크는 애플리케이션(20)을 구동하는 장치(13)를 위해 적절히 미디어를 렌더링하는 것을 포함한다.

D.2 저장 및 스트림 모듈( Store and Stream Module )

저장 및 스트림 모듈(24)은 많은 기능 및 성능적 속성을 지원하며, 이는 이하 기술된다.

저장 및 스트림 모듈(24)을 사용하여, 메시지 전송은 본질적으로 "양-방향(full-duplex)"이 되고, 다른 사용자가 메시지를 송신하거나 다른 사용자가 사용가능하지 않거나 관여된 경우에도, 임의의 사용자가 임의의 시간에 메시지를 송신할 수 있도록 한다. 저장 및 스트림 모듈은 라이브 PSTN 또는 VoIP 콜의 경우와 같이 메시지를 렌더링할 수 있거나, 메시지를 타임 쉬프트된 메시징 모드로 전달할 수 있다. 이는 사용자의 요구에 따라 전송을 최적화하고 렌더링을 제어할 수 있다.

저장 및 스트림 모듈(24)은 근원 네트워크(18) 상의 모든 타겟 착신자(예컨대 서버(16) 또는 다른 장치(13))와의 연결성(connectivity)을 유지하고, 모든 메시지, 신호, 및 미디어 전송을 관리하고, 네트워크 품질 및 역량(capacity)을 관리함과 동시에, 네트워크(18)를 걸친 전달 속도 및 대역폭 사용을 최적화하여 사용자의 즉각적인 성능 요구를 만족시킨다. 모듈(24)은 근원 네트워크(18)의 품질 및 용량에 적당한 미디어 전달을 적응시키고 최적화한다. 불충분한 근원 네트워크 리소스가 사용가능한 경우, 전송된 미디어 스트림의 품질은 떨어질 수 있다. 대역폭이 사용가능해짐에 따라, 전송된 미디어 스트림의 품질은 증가될 수 있다. 미디어 품질의 트레이드 오프에 더하여, 저장 및 스트림 기능성은 사용자의 의도를 기반으로 각각의 패킷에 전송된 미디어의 양을 트레이드 오프하여 아래 기술한 바와 같이 데이터를 실시간으로 렌더링할 수 있다.

근원 네트워크(18)의 상태를 기반으로 미디어의 전달률을 동적으로 제어함으로써, 저장 및 스트림 모듈(24)은 착신 시 렌더링하기에 "충분히 양호한" 시간에 민감한(time-sensitive) 미디어를 전달하기 위해 최적화되고, 보관의 목적을 위해 손실되거나, 낮은 품질의, 또는 손상된 패킷의 재전송을 요청하는 백그라운드 프로세스를 통해 미디어의 정확하거나 완전한 카피의 종국적인 전달을 보증한다. 충분한 네트워크 리소스가 최소 미디어 품질 레벨을 만족하도록 존재하는 한, 이러한 재전송은 라이브 콜 미디어의 렌더링을 방해하지 않는다. 따라서, 시스템(10)의 클라이언트(12)는 완전성에 대한 보증이 없지만 미디어의 신속한 전달에 대한 실질적인 잠재적 지연(latency)을 희생하면서 미디어의 정확하거나 완전한 카피의 전달 간의 성능적 갭을 연결하도록 설계된다. 본원의 맥락에서, 용어 "충분히 양호한"은 미디어의 품질이 충분하여 그것이 렌더링되면, 의미가 명료한 것을 의미한다. 따라서, "충분히 양호한"의 개념은 주관적이고 절대적인 용어로 해석되지 않아야 한다. 예를 들어, 충분히 양호할 정도의 특정 미디어의 품질 레벨은 미디어의 타입, 환경, 및 다른 팩터에 의해 변할 수 있다.

저장 및 스트림 모듈(24)은 장치(13)에 의해 생성되거나 장치(13)를 사용하여 발생하거나 또는 다른 장치(13) 및/또는 사용자로부터 네트워크(18)를 통해 수신된 모든 미디어를 영구적으로 더 저장한다. 클라이언트(12)를 구동하는 장치(13) 상의 이러한 미디어를 저장함으로써 다음과 같은 다수의 현저한 장점이 있다: (i)이는 송신자 및/또는 착신자가 사용불가능하거나 또는 열악한 네트워크 연결성을 가지는 경우에도, 사용자가 메시지를 다른 자에게 남길 수 있도록 한다. 불충분한 대역폭의 경우, 메시지는 대역폭이 효율적으로 사용될 수 있자마자 전송될 것이다. 연결성이 없는 경우, 메시지는 네트워크 연결성이 사용가능해지자마자 전송될 수 있도록 큐잉되고, 이는 타임-쉬프트 전달을 야기하며; (ii) 사용자는 이전 대화의 보관된 메시지를 검색하고 검토할 뿐만 아니라, 일시정지, 재생, 빠른 재생, 및 들오오는 대화에 대해 라이브를 따라잡기(CTL)의 기능을 구비하며; (iii) 이는 시스템(10) 상의 데이터 페이로드의 최적화를 가능하게 하고 가끔씩 발생할 수 있는 네트워크 대역폭 및 연결성 문제에 대해 시스템의 복원력을 향상시킨다.

저장 및 스트림 모듈(24)은 또한: 다른 잠재적인 렌더링 옵션뿐만 아니라; 중복 메시지(overlapping messages)(대화 내 화자 또는 배경 잡음의 일반적인 중첩에 의해 생성됨)를 생성하도록 적절해짐에 따라 메시지를 믹싱하고, 다수의 사용자가 말하는 실제 대화를 시뮬레이팅하며; 오디오 미디어의 전사(transcription) 또는 번역을 렌더링하며; 빠른 재생, 발설된 단어들 간의 침묵 간격(silence gaps)의 제거, 주저하는 조각(hesitation particles)의 제거, 및 주파수 쉬프팅을 포함하는 많은 사용자-정의 기준에 따라 미디어의 렌더링을 조절하며; 독립적인 이득 제어를 다자간 대화의 개별적인 송신자에게 적용하는 능력을 가진다.

저장 및 스트림 모듈(24)은 그 자체 및 MCMS 간의 제어 및 정보적인 메시징을 관리한다.

D.2.1 PIMB( Persistent Infinite Message Buffer )

영구적인 무한 메시지 버퍼(Persistent Infinite Message Buffer) 또는 PIMB(30)는 미디어의 저장 및 검색을 위한 인덱스된(즉, 타임-스탬프되고 순차적으로 넘버링된) 미디어 페이로드 데이터 구조 및 시스템의 세트이다. 일 실시예에서, PIMB(30) 내의 데이터는 독단적으로(arbitrarily) 영구적이고, 이는 그 데이터가 가상적으로 영원히 사용가능하거나 적어도 시스템의 스토리지가 고갈될 때까지 사용가능하다는 의미이다. 다양한 보유(retention) 비율 및 전략이 스토리지 리소스의 효율적인 사용을 구현하도록 적용될 수 있다. 많은 가능한 구현들이 PIMB(30)의 물리적인 스토리지 구현을 위해 존재하며, 이는 다음을 포함하지만 이에 제한되지는 않는다: RAM, 플래시 메모리, 하드 드라이브, 광학 미디어, 또는 그 일부 조합. PIMB(30)은 또한 사이즈가 "무한하며", 이는 PIMB(30)에 저장될 수 있는 데이터의 양이 본래 제한되지 않음을 의미한다. 이러한 제한의 부족은 렌더링되자마자 데이터를 폐기하는 종래의 지터(jitter) 버퍼 기술과 비교된다. 일 특정 실시예에서, PIMB(30)은 영구적인 저장을 위한 하드 드라이브와 결합된 작고 상대적으로 빠른 RAM 캐쉬 메모리를 사용하여 구현될 수 있다. PIMB(30)의 물리적인 저장 용량이 초과함에 따라, 데이터는 추후 요구에 따른 검색을 위해 서버(16)에서 유지된다. 사용자 기준 또는 대체(replacement) 알고리즘, 예컨대 LRU(least-Recently-Used), 또는 FILO(First-In-Last-Out)가 PIMB(30)에 저장된 실제 데이터 및 서버(16)에 유지되거나 임의의 시점에 보관된 데이터를 제어하도록 사용된다. PIMB(30)는 파일 시스템 스토리지 및 데이터베이스의 랜덤 액세스 속성을 더 제공한다. 각각의 메시지의 지속기간 또는 개수에 관계없이, 임의의 개수의 대화는 검토를 위해 저장되고 추후 검색될 수 있다. 또한, 대화의 메시지와 결합된 메타데이터, 예컨대 그 창설자 및 그 길이는 또한 PIMB(30)에 저장될 수 있다. 대체적인 실시예에서, 인덱스된 미디어 페이로드 및 다른 데이터는 지정된 기간의 시간동안(예컨대 30일) 저장될 수 있다. 미디어의 저장 기간이 지정된 기간을 초과하면, 페이로드 및 데이터는 폐기된다. 또 다른 실시예에서, 페이로드는 페이로드를 포함하는 메시지의 송신자 및/또는 착신자, 또는 페이로드와 결합된 대화 또는 메시지의 제목을 기반으로 폐기될 수 있다. 다른 실시예에서, 페이로드 및 데이터는 일시적이도록 마크될 수 있으며, 이는 메시지가 즉각적인 렌더링을 위한 요구를 벗어나 PIMB(30)에 저장되지 않을 것을 의미한다.

D.2.2 데이터 및 네트워크 품질 저장( Data and Network Quality Store )

DNQS(Data and Network Quality Store)(32)는 PIMB(30)로부터 독출되거나 PIMB(30)로 기록되는 미디어 페이로드 및 복스 패킷에 관한 정보를 저장하는 데이터 저장이다.

D.2.3 PIMB 라이터( PIMB Writer )

PIMB 라이터(28)는 두 가지 기본적인 목적을 위해 데이터를 PIMB(30)에 기록한다. PIMB 라이터(28)는 클라이언트(12)를 구동하는 장치(13) 상의 미디어 캡쳐 장치(예컨대 마이크 또는 카메라)로부터의 데이터를 기록한다("인코딩 수신(Encode Receive)"). PIMB 라이터(28)는 또한 네트워크(18)를 통해 다른 클라이언트(12)로부터 수신된 데이터를 PIMB(30)로 기록한다("네트 수신(Net Receive)").

D.2.3.1 인코딩 수신( Encode Receive )

장치(13)로부터의 미디어를 캡쳐하기 위해, PIMB 라이터(28)는 인코더 리시버(28a) 및 데이터 스토어(28c)를 포함한다. 예를 들어, 사용자가 마이크로 말하거나 장치(13)를 사용하여 비디오 이미지를 생성하는 경우, 하드웨어(34)는 로우 오디오(raw audio) 및/또는 비디오 신호를 수신하고 이들을 인코더 리시버(28a)로 제공하며, 이는 신호를 인덱스된 미디어 페이로드로 인코딩한다(이하, 가끔씩 단순하게 "페이로드" 또는 "페이로드들"로 언급된다). 데이터 스토어(28c)는 페이로드를 PIMB(30)으로 저장한다. 미디어의 다른 타입, 예컨대 센서 데이터는 유사한 방식으로 페이로드로 변환된다.

D.2.3.2 네트 수신( Net Receive )

네트워크(18)를 통해 수신된 미디어를 PIMB(30)로 저장하기 위해, PIMB 라이터(28)의 네트 수신 기능은 네트워크 리시버(28d), 데이터 버퍼(28e), 데이터 스토어(28f), 데이터 품질 관리자(28g), 및 네트워크 품질 관리자(28h)를 포함한다. 네트워크 리시버(28d)는 네트워크(18)를 통해 복스 패킷을 수신한다. 데이터 버퍼(28e)는 수신된 복스 패킷을 적절한 시퀀스로 위치시키고, 들어오는 복스 패킷의 렌더링의 MTSD(Minimum Time Shift Delay)의 지연을 방지한다. 데이터 스토어(28f)는 패킷을 인덱스된 미디어 페이로드로 변환하고 인덱스된 미디어 페이로드를 PIMB(30)에 저장한다. 페이로드가 저장됨에 따라, DQM(Data Quality Manager)(28g)은 임의의 손실되거나 결함있는 패킷을 파악한다. 패킷이 손실되거나 결함이 있는 경우, DQM(28g)은 네트워크(18)를 통한 재전송을 요청하도록 스케쥴링한다. 송신 장치는 손실되거나 결함있는 패킷을 재송신함으로써 대답한다. 결과적으로 이들 패킷은 인덱스된 미디어 페이로드로 변환되고 PIMB(30)에 저장된다. 손실되거나 결함있는 패킷을 검색함으로써, 송신자의 메시지의 "정확한" 카피는 결과적으로 PIMB(30)에 저장된다. 손실되거나 및/또는 결함있는 패킷의 재전송은 실시간의 메시지 렌더링을 지연시키지 않으며, 전달된 패킷이 충분히 양호한 품질 및 양을 가지도록 제공된다. 불충분한 네트워크 리소스가 재전송 뿐만 아니라 새로운 "라이브" 데이터 둘 모두를 지원하는 경우, 재전송 요청은 DQM(28g)에 의해 지연될 수 있다.

D.2.4 PIMB 리더( PIMB Reader )

PIMB 리더(26)는 두 가지 목적을 위해 PIMB(30)로부터 데이터를 독출한다. PIMB 리더(26)는 데이터가 로컬 클라이언트(12)를 위해 렌더링될("렌더(Render)") 경우 PIMB(30)에 액세스한다. 데이터는 또한 데이터가 네트워크(18)를 통해 클라이언트(12)에 의해 전송될 경우 PIMB(30)로부터 독출된다.

D.2.4.1 렌더링( Render )

클라이언트(12) 상의 메시지의 렌더링을 위해, PIMB 리더(26)는 데이터 우선 순위 지정기(Prioritizer)(26a), 데이터 리트리버(Retriever)(26b), 패킷 손실 보상(Packet Loss Compensation)/인터폴레이터("PLC/Interpolator")(26c), 데이터 믹서(26d) 및 데이터 렌더러(Render)(26e)를 포함한다. 우선순위 지정기(26a)는 잠재적으로 렌더링될 수 있는 메시지의 순서화된 큐(queue)를 구축함으로써 렌더링될 데이터를 우선순위화 할 수 있다. 이는 연속적인 대화의 렌더링을 위해 사용자 구성 우선순위(user configured priority)를 사용한다(MCMS-C). 또한, 데이터 우선순위 지정기는 미디어 데이터의 가용성(avalability)을 사용하여 MTSD, 사용자의 현재 의도, 및 사용자에 의해 정의되고 함축된 의도에 의해 부과되는 제한 내에서 렌더링한다. 데이터 리트리버(26b)는 PIMB(30)로부터 우선순위화되고 인덱스된 미디어 페이로드를 검색한다(retrieve). PLC/인터폴레이터(26c)는 검색된 페이로드에 패킷 손실 보상 및 인터폴레이션을 수행하며, 이는 알려진 패킷 손실 보상 및 인터폴레이션 알고리즘을 사용하여 수행한다. 사용될 특정 방법은 사용되는 미디어 코덱, 및 다른 알려진 파라미터에 종속된다. 믹서(26d)는 단일 대화의 다수의 메시지로부터의 동시 발생하는(concurrent) 데이터 스트림을 함께 적절하게 믹스하도록 사용된다. 예를 들어, 대화의 둘 또는 그 이상의 참여자가 동시에 말하는 경우, 믹서(26d)는 메시지를 믹스하여, 두 참여자 모두가 동시에 말하는 효과를 생성한다. 대체적인 실시예에서, 사용자는 한 번에 하나의 참여자로부터의 다수의 스트림을 검토하는 옵션을 가진다. 대화에서 오직 하나의 참여자만이 말하는 경우, 믹서(26d)는 단순히 임의의 믹싱을 수행하지 않고 단일 메시지 스트림을 전달할 수 있다. 렌더러(26e)는 믹서 모듈(26d)로부터 데이터를 수신하고 이를 하드웨어 드라이버(34)에 적합한 형태로 변환한다. 그리고 나서 하드웨어(34)는 장치(134)의 스피커 또는 비디오 디스플레이 중 어느 하나를 구동하며, 이는 미디어의 타입에 종속되며, 음성, 영상 또는 장치(13) 상에서 다른 들을 수 있거나 및/또는 볼 수 있는 통지자(notifier)를 생성한다.

D.2.4.2 전송( Transmit )

메시지를 네트워크(18)를 통해 클라이언트(12)로부터 전송하도록 준비하기 위해, PIMB 리더(26)는 데이터 우선순위 지정기(26f), PQM(Packet Quality Manager)(26g), 데이터 리트리버(26h), 패킷타이저(26i), 트랜스미터(26j) 및 확인응답기(acknowledger)(26k)를 포함한다. 데이터 우선순위 지정기(26f)는 네트워크(18)를 통한 전송을 위해 메시지를 우선순위화한다. 우선순위는 전송, 네트워크 연결성 및 대역폭 조건, 및 다음 호핑(hopping)부터 라이브 또는 타임-쉬프트 중 어느 하나로 렌더링할지에 대한 사용자의 의도에 대해 사용가능한 페이로드에 관련된 MCMS 참여자 속성을 사용하여, 그리고 일부 실시예에서는 임의의 주어진 다음 네트워크 홉(hop)으로의 다수의 패킷이 사용가능한 전송 번들링(bundling)의 가능한 최적화(optimizations)를 사용하여 결정된다. 그리고 나서, 우선순위화된 패킷은 PQM(26g)를 사용하여 최적화되며, 이는 실시간 대역폭을 최소화하는 반면, 라이브 메시지를 위해 "충분히 양호한" 데이터 품질의 적시 전달을 보증하며, 이는 이하 보다 상세히 기술되는 바와 같다. 데이터 리트리버(26h)는 PIMB(30)로부터 적절한 페이로드를 검색한다. 패킷타이저(26i)는 페이로드를 복스 패킷으로 어셈블링하며, 그리고 나서 이는 트랜스미터 모듈(26j)에 의해 네트워크(18)를 통해 전송된다. 착신자가 복스 패킷을 수신하는 경우, 메시지가 그 목적지에 도달하였음을 송신자인 사용자에게 알리기 위해 네트워크(18)를 통해 확인 응답(acknowledgement)이 확인응답기(26k)로 송신된다.

D.2.5 PQM( Packet Quality Manager )

PQM(26g)는 다음과 같은 다수의 최적화 목표가 있다: (i) 시간에 민감한(time-sensitive) 미디어("가능한 한 즉시 렌더링을 위해 충분히 양호한" 미디어)의 적절한 카피의 적시 전달; (ii) 사용가능한 대역폭의 효율적인 사용, 이는 최적의 전송 주파수, 페이로드 품질, 및 근원 네트워크를 위한 패킷 사이즈를 사용하는 것을 의미한다; (iii) 네트워크 상태의 변화에 따라 전송 주파수, 페이로드 컨텐츠, 페이로드 품질, 패킷 사이즈 등을 동적으로 조절하거나 변화시키는 기능.

D.2.6 NQM( Network Quality Manager )

네트워크 전송의 수신단은 NQM(Network Quality Manager)(28h)이다. NQM은 미디어를 클라이언트(12)로 송신한 각각의 송신자에 대한 네트워크 성능의 특정 성질을 관찰하도록 구성되며, 지터(jitter), 손실, 및 실제 값에 대한 처리량(throughput)의 예상과 비교한다. 이는 모든 송신자에 대한 NQR(Network Quality Rating)을 계산하도록 사용된다. 이러한 NQR은 송신자 가용성(sender availability) 및 대화 라이브화(conversation live-ness)를 수신 장치의 사용자에게 지시하도록 사용된다.

D.2.7 DQM( Data Quality Manager )

DQM(28g)는 패킷 손실, 지터 및 처리량을 관찰함으로써 네트워크를 통해 수신되고 있는 데이터의 품질을 측정한다. DQM(28g)은 다음과 같은 세 가지 목적을 위해 이들 측정값을 사용한다: (i) 착신 보고(receipt report)를 송신자에게 역전송하기 위해; (ii) 상기 착신 보고를 선택적으로 사용하여 특정 데이터의 재전송을 요청하기 위해; (iii) 상기 측정값들을 NQM(28h)에서 사용가능하도록 하기 위함이다.

E. 서버 구성( Server Architecture )

도 3을 참조하여, 서버(들)(16)에서 구동하는 애플리케이션(78)의 블록도를 설명한다. 애플리케이션(78)은 많은 부분에서 클라이언트 애플리케이션(12)과 유사하고 MCMS 서버 애플리케이션(80), MCMS 데이터베이스(82), SAS 모듈(84), PIMB(85), DNQS(Data and Network Quality Store)(86), MCMS 서버 애플리케이션(80) 및 SAS 모듈(84) 간에 오가는 메시지 및 신호를 관리하는 MCMS-SAS 메시지 핸들링 모듈(87a 및 87b), 보관/리트리버(88), 및 아카이브(archive)(89)를포함한다. 애플리케이션(78)은 인증-암호화-보안 모듈(40) 및 통신 프로토콜 모듈(44)을 더 포함한다.

MCMS 서버 애플리케이션(80)은 MCMS 데이터베이스 모듈(20a), SAS(Store and Stream) 모듈(20b), 메시징/시그널링 모듈(20c), 대화/메시지 관리 서비스(20f), 우선순위 서비스(20g), 연락처(사용자 및 인증을 포함함) 서비스(20h), 존재/상태 서비스(20i), 및 메시지/신호 서비스(20)를 포함하는 다중-계층 구조이다. 전술한 애플리케이션(78)의 모듈 및 서비스는 클라이언트(12)의 참조번호를 가지는 모듈 및 서비스와 유사하거나 동일하고, 따라서 하나의 주목할만한 예외를 제외하고 여기에서는 상세하게 기술하지 않는다. 다양한 실시예에서, MCMS 데이터베이스(82)를 포함하는 MS 서버 애플리케이션(80) 및 SAS 모듈(84)는 애플리케이션의 한 인스턴스(instance)에서 많은 사용자를 지원하도록 구성된다. 상기 한 인스턴스는 다수의 도메인을 지원하도록 더 구성되며, 여기서 각각의 도메인은 사용자의 그룹(즉, 회사 또는 공통의 조직체에 속하는 사용자의 다른 그룹)으로 정의된다.이러한 구성은 서버(16) 상의 각각의 애플리케이션(78)이 다수의 사용자(또는 도메인)에게 서비스를 제공하도록 하며, 이는 각각의 사용자(또는 도메인)은 다른 사용자에게 보여지지 않는다. 이러한 구분은 "다중-차용(multi-tenancy)"이라고 불린다.

서버의 SAS 모듈(84)은 네트 수신 및 전송(Net Receive and Transmit)의 기능을 수행한다. 네트 수신 기능을 위해, 모듈(84)은 네트 리시버(28d), 데이터 버퍼(28e), 데이터 스토어(28f), DQM(Data Quality Manager)(28g), 및 NQM(Network Quality Manager)(28h)를 포함한다. 전송 기능을 위해, 모듈(84)은 데이터 우선순위 지정기(26f), 패킷 최적화기(26g), 데이터 리트리버(26h), 패킷타이저(26i), 트랜스미터(26j) 및 확인응답기(26k)를 포함한다. 전술한 SAS 모듈(84)의 구성요소는 클라이언트(12)의 참조번호를 가지는 구성요소와 유사하거나 동일하며, 따라서 여기서 상세하게 기술하지 않는다.

서버(16)가 직접적으로 사용자와 상호작용하지 않으므로, 클라이언트(12)의 SAS 모듈(24)에 제공된 인코딩 및 렌더링 기능은 존재할 필요는 없다. 서버(16)에서 구동하는 경우, MCMS 애플리케이션(80)은 사용자와 직접적으로 상호작용하지 않는다. 결과적으로, 사용자 인터페이스 및 사용자 인터페이스 API 모듈 및 서비스(20e 및 20d)는 필요하지 않다.

각각의 서버(16) 상의 애플리케이션(78)은 잠재적으로 다수의 차용자(tenants)에게 서비스를 제공하며, 이는 시스템(10)의 다수의 사용자에게 서비스를 제공하는 것을 의미한다. 따라서, 오직 단일의 사용자의 생성되거나 수신된 페이로드를 단지 저장하기 위해 사용되는 PIMB(30)과 달리, 서버 애플리케이션(78)의 PIMB(85)는 현저히 커지고 다수의 사용자의 미디어 페이로드를 저장하기 위해 사용된다. SAS 모듈(84)의 주된 목적은 클라이언트(12)에 의해 전송된 메시지를 수신하고 다른 클라이언트(12)로 메시지를 전송하는 것이다. 메시지가 수신되면, 이들은 PIMB(85)에 저장되고 의도된 착신자(들), 또는 시스템 구성에 직접적으로 종속하는 착신자(들)로의 경로를 따라 네트워크 레이어(14)의 다음 서버(16)(즉, 다음 "홉(hop)")으로 전송된다. 보관/리트리버(88)는 PIMB(85)에 저장된 미디어 페이로드를 아카이브(89)에 보관하도록 구성된다. PIMB(85) 내의 물리적인 공간이 고갈됨에 따라, PIMB(85) 내의 미디어 페이로드는 아카이브(89)로 이동하며, 상기 아카이브는 커다란 저장장치이다. 다양한 실시예에서, PIMB(85)에 저장된 페이로드는 사용자 정의 기준 및/또는 임의의 알려진 대체 알고리즘, 예컨대 FIFO(First-In-Fist-Out) 또는 LRU(Least Recently Used)에 따라 보관될 수 있다. 도 1에는 단순화를 위해 오직 단일의 서버(16)가 도 1에 도시되었다. 실제 실시예에서는 다수의 서버 또는 "서버 팜(server farm)"이 많은 수의 사용자를 구비한 네트워크를 위해 사용될 수 있다.

PIMB(30) 및 PIMB(85)를기술하기 위해 사용된 용어 "영구적인(persistent)" 및 "무한의(infinite)"는 문자그대로인 절대적인 용어로 해석되지 않아야 한다. 사용자는 중요하다고 간주되는 일부 메시지를 무기한으로 저장하기를 원할 수 있다. 다른 상황에서, 예컨대 두 친구들 간의 캐쥬얼 채팅에서, 메시지는 저장공간을 아끼기 위해 소정 기간 후 삭제될 수 있다. 본 발명의 다양한 실시예에 따르면, 다른 유지 정책이 사용될 수 있으며, 이는 시스템(10)에 의해 설정되거나 또는 사용자에 의해 구성될 수 있다. 단어 "무한의"의 사용은 PIMB에 의해 강제된 임의의 기설정된 시간 경계의 결여를 의미한다. 이는 현재의 지터 버퍼 시스템과 대조되며, 지터 버퍼 시스템은 미디어가 렌더링된 후 폐기되는 시스템이다. 따라서, 용어 영구적이고 무한한은 PIMB(30) 및 PIMB(85)가 시간 영역에서 내부적인 제한이 없으며 그 안에 저장될 수 있는 메시지의 양에 제한이 없음을 의미하도록 광범위하게 해석되어야 한다.

대화의 메시지를 영구적인 저장 매체에 보관하는 것은 많은 장점이 있다. 음성 메시지 및 다른 미디어는 필요에 따라 구조화되고, 인덱스되고, 검색되고, 전사되고, 번역되고 검토될 수 있다. 따라서, 다른 미디어 뿐만 아니라 음성은 사용자 및 조직 둘 모두에 의해 관리될 수 있는 자산이 된다. 이러한 미디어 자산은 군대뿐만 아니라 회사, 최초 대처자, 경찰서 및 소방서에게도 가치가 있다.

F. 복스 프로토콜 및 인덱스된 미디어 페이로드( Vox Protocol and Indexed Media Payloads)

상술한 바와 같이, 복스 프로토콜은 페이로드 전송, 저장, 및 최적화의 모든 국면을 지원하도록 SAS 모듈(24)에 의해 사용된다. 복스 패킷은 네트워크(18)의 근원 기술의 전송 패킷 또는 전송 패킷들 내에 캡슐화(encapsulate)하도록 설계된 구조화된 메시지 포맷이다. 이러한 배열은 시스템(10)의 유연성을 현저히 향상시킨다. "복싱" 애플리케이션을 위한 새로운 전송 레이어를 정의하는 것과 달리, 복스 패킷을 종래의 전송 패킷에 임베딩시킴으로써, 시스템(10)은 종래의 전기 통신 인프라구조 상에서 구동하는 현재 패킷 기반의 통신 네트워크의 장점을 취할 수 있다. 따라서 이하 기술되는 시스템 및 방법의 모든 이익을 장점으로 취하기 위해 복스 패킷을 다루는 새로운 네트워크 인프라구조가 생성될 필요는 없다.

도 4a를 참조하여, 복스 패킷(95)의 일반적인 포캣 구조가 설명된다. 복스 패킷(95)의 포맷은 타입, 서브-타입, 길이, 및 페이로드를 위한 필드를 포함한다. 복스 패킷의 다른 타입은 인증, 시그널링, 미디어 페이로드, 미디어 멀티플렉스(하나의 메시지), 및 미디어 멀티플렉스(다수의 메시지)를 포함한다. 서브-타입 필드는 인증, 시그널링 또는 미디어 타입 메시지의 다른 타입을 지정하기 위해 사용된다. 메시지 인증을 위한 가능한 서브-타입은 키 교환(key exchanges) 및 인증을 위해 필요한 것들을 포함한다. 메시지 시그널링을 위한 가능한 서브-타입은 등록(registration), 라우팅, 메시지 설정, 및 네트워크 관리를 포함한다. 미디어 메시지를 위한 가능한 서브-타입은 상이한 코덱 스타일 및 상이한 페이로드 집합(aggregation) 기술을 포함한다. 길이 필드는 전체 길이 또는 페이로드의 사이즈를 정의한다. 페이로드 필드는 패킷(95)의 실제 페이로드 또는 미디어를 포함한다.

도 4b를 참조하여, 네트워크(18)에 의해 사용되는 예시적인 프로토콜로 캡슐화된 복스 패킷(95)을 설명하는 도면을 도시한다. 이 예에서, 복스 패킷(95)은 각각 근원 UDP, IP 및 이더넷 전송 패킷(96)에 임베딩된다. 이러한 방식에서, 복스 패킷(95)은 네트워크(18)의 근원 UDP, IP 및 이더넷 레이어를 걸쳐 전송될 수 있다. 이는 패킷 네트워크에 의해 사용되는 표준적인 프로토콜 캡슐화(encapsulation) 기술이다.

도 4c를 참조하여, UDP, IP, 및 이더넷(97)에 캡슐화된 미디어 멀티플렉스 복스 패킷(95)을 설명하는 도면이 설명된다. 이 예에서, 복스 패킷(95)은 미디어 타입 필드, 미디어 서브-타입 필드, 길이 필드, 메시지 ID 필드, 타임 스탬프 필드, 시퀀스 ID 필드, 및 미디어 페이로드 필드를 포함한다.

도 4d를 참조하여, 인덱스된 미디어 페이로드(98)의 포맷이 설명된다. 인덱스된 미디어 페이로드는 서브-타입 필드, 길이 필드, 메시지 식별자(ID) 필드, 타임-스탬프 필드, 시퀀스 식별자(ID) 필드, 및 미디어 페이로드를 위한 필드를 포함한다.

근원 네트워크의 전송 패킷으로의 복스 패킷(95)의 캡슐화는 미디어, 메시지 및 대화가 각각 많은 속성에 의해 정의되도록 한다.

미디어가 생성되거나 또는 장치(13)에서 발생된 경우, 이는 일반적으로 시간-기반(time-based)이며, 이는 미디어가 시간에 걸쳐 일부 의미있는 방식으로 변화하는 것을 의미한다. 예를 들어, 사용자가 대화에 참여함에 따라, 그들이 말한 단어는 문장 또는 진술로 함께 엮여지며(string), 이는 시간에 걸쳐 변하고, 결과 데이터(스트림 및 패킷)은 시간에 걸쳐 동일한 분산(variance)를 유지할 것이다. 유사하게, GPS 또는 다른 센서 데이터 뿐만 아니라 영상(정지 사진과 달리)도 시간에 걸쳐 변화할 것이다. 타입 또는 그것이 어떻게 발생되었는지에 관계없이, 미디어는 분할되고 다수의 복스 패킷(95)의 페이로드에 위치된다. 그리고 나서, 패킷은 각각 전송 및 수신 장치(13)에서 연속적으로 저장되고, 전송되고, 수신되고, 스트림(즉, 스트리밍 미디어)으로 저장되고 렌더링된다. 각각의 패킷(95)이 인덱스되고, 타임-스탬프되고, 시퀀스 식별자가 주어지므로, 개별적인 패킷은 메시지로 분할될 수 있다. 개별적인 메시지를 순차적으로 함께 스레딩함으로써, 대화가 파악될 수 있다.

시스템(10)의 또 다른 한 독특한 양상은 클라이언트(12)에 의해 생성된 미디어 페이로드가 다수의 위치에 저장되는 것이다. 생성 장치(13)의 PIMB(30)에 저장되는 페이로드 뿐만 아니라, 서버(들)(16)의 PIMB(85) 및 수신 장치(13)의 PIMB(30)에도 저장된다. 이러한 기본적인 특징은 비록 네트워크 상태가 열악하거나 대화의 참여자가 네트워크에 연결되지 않은 경우에도, 상술한 다수의 복싱 기능성이 가능하도록 하고 시스템(10)에 탄성과 동작성을 제공한다.

G. 근원 전기통신 프로토콜과의 상호 운용성(Interoperability With Underlying Telecommunication Protocols)

시스템(10)은 다양한 기존의 통신 네트워크(18), 예컨대 인터넷, 고정된 PSTN 타입의 회선 네트워크, 및 모바일 또는 셀룰라 폰 네트워크, 또는 그 조합 상에서 구동하고 레이어를 구성하도록 의도된다. 시스템(10)은 시스템(10) 내 상이한 클라이언트(12)와 서버(16) 간에 이동하는 많은 작은 정보 단위(즉, 복스 패킷)의 개념에 대해 설계된다. 복스 패킷의 기능 및 페이로드에 종속하는 복스 패킷의 사이즈가 변하면, 이들은 모두 근원 네트워크 레이어에 동일한 종류의 데이터가 되도록 나타난다. 일 실시예에서, 시스템(10)은 IPv4 네트워크, 예컨대 인터넷에 대해 디자인되고 최적화되지만, 다른 타입의 네트워크 또한 지원될 수 있다. 본 발명의 명세서의 목적을 위해, 용어 "IP"는 IPv4, IPv6 또는 임의의 다른 현재 또는 미래의 인터넷 프로토콜의 구현을 의미하도록 이해되어야 한다.

도 5를 참조하여, 장치(13)에서 구동하고 공유된 IP 네트워크(100)를 통해 서버(16)와 통신하는 클라이언트(12)의 도면이 도시된다. 도시된 바와 같이, 클라이언트(12)는 제 1 인터넷 서비스 제공자 A를 통해 공유된 IP 네트워크(100)와 결합되고, 서버(16)는 제 2 인터넷 서비스 제공자 B에 의해 공유된 IP 네트워크 (100)와 결합된다. 통신 도중, 복스 패킷(95)(도면에서 "VP"로 도시됨)은 UDP/IP 패킷 내에 캡슐화되고, 그리고 나서 알려진 바와 같이 다른 IP프로토콜 패킷 중에 인터리브(interleave)되고, 공유된 IP 네트워크(100)를 걸쳐 클라이언트(12)로부터 서버(16)로 전송되거나, 그 역으로 전송된다. 알려진 바와 같이, 각각의 낮은 패킷 레이어는 바로 위 레이어의 전체 패킷을 캡슐화한다. 패킷은 또한 두 서버(16) 간에 유사한 방식으로 전송될 수도 있다. 메시지는 임의의 클라이언트(12)가 이네이블된 장치(13)로부터 공유된 IP 네트워크(100)를 통해 다른 곳으로 송신된다. 각각의 홉(hop)에서, 복스 패킷(95)은 근원 IP 프로토콜에 임베디드되고 그들이 타겟 목적지에 이르기까지 전송된다.

도 5의 도면은 단지 예시적이며, 설명을 위해 네트워크(100)에 연결된 단일의 클라이언트(12) 및 서버(16)만을 도시한다. 시스템(10)의 실제 실시예에서, 많은 수의 클라이언트(12) 및 하나 또는 그 이상의 서버(16)가 일반적으로 공유된 IP 네트워크(100)에 연결된다. 또한 클라이언트(12) 및 서버(16)는 IP 네트워크(100)의 사용을 독점할 필요가 없는 점에서 유용하다. 도시된 예에서, 인터넷 제공자 A를 통해 네트워크(100)와 결합된 HTTP 클라이언트는 제3 인터넷 제공자 C를 통해 네트워크(100)에 결합된 HTTP 서버를 사용하여 오가며 패킷을 전송할 수 있다. 시스템(10)은 IP 패킷에 임베디드된 VP가 네트워크(100)를 가로지르는 방식을 제어하지 않는다. 이보다는, 네트워크(100)를 가로지르고 공유하는 모든 패킷이 근원적인 공유된 IP 네트워크(100)의 표준 과정에 따라 전송된다.

도 6을 참조하여, "회선" 기반 네트워크(104), 예컨대 GSM 이동 통신 단말기 네트워크가 설명된다. 회선 네트워크(104)는 장치(13)에서 구동하는 클라이언트(12)와 서버(16) 사이에 결합된다. 회선이 클라이언트(12)와 서버(16) 사이에 구축되면, 시스템(10)은 복스 패킷들(VP1, VP2, VP3, VP4, VP5 등)을 네트워크(104)에 의해 사용되는 근원 패킷에 층으로 쌓아놓고(layer) 이들을 네트워크(104)를 걸쳐 전송하여, "가상 복스(virtual Vox)" 회선을 생성한다. 복스 패킷은 순차적으로 회선 네트워크(104)를 가로지르며, 이는 일반적으로 회선 네트워크를 통해 데이터를 전송하기 위해 잘 알려진 방법으로 데이터에 간격을 적용하고(spacing) 프레임화(framing)하여 수행된다. 또한, 패킷 구성 파라미터, 예컨대 페이로드 사이즈 및 포함된 헤더 필드의 개수는 패킷 별 오버헤드(per-packet overhead)의 결여를 이용하기 위해 사용될 수 있으며, 네트워크(104)를 걸친 데이터 전송의 속도 및/또는 효율을 증가시키기 위해 사용된다. 또 다시 단순화를 위해, 단일 클라이언트(12) 및 서버(16)만이 네트워크(104)에 연결되도록 도시되었다. 그러나, 다른 컴포넌트뿐만 아니라 클라이언트(12)와 서버(16) 사이에 추가적인 회선이 네트워크(104)를 통해 동시적으로 구축될 수 있음이 이해되어야 한다. 따라서, 네트워크(104)는 복스 패킷의 전송을 위해 전용되지 않고, 네트워크 트래픽의 다른 타입과 공유될 수 있다.

도 7을 참조하여, 제 1 네트워크 A와 결합된 제 1 클라이언트(12A)가 이네이블된 장치(13A)와 제 2 네트워크 B와 결합된 제 2 클라이언트(12B)가 이네이블된 장치(13B) 간의 통신을 설명하는 도면이 설명된다. 네트워크 A 및 B는 각각 게이트웨이 서버(16A 및 16B)를 더 포함한다. 게이트웨이 서버 쌍(16A 및 16B)은 두 네트워크 A 및 B 간의 통신을 구현하여, 장치(13A 및 13B)가 서로 간에 통신할 수 있도록 한다. 다양한 실시예에서, 네트워크 A 및 B는 각각 임의의 타입의 네트워크가 될 수 있다. 예를 들어, 각각의 네트워크 A 및/또는 B는 IP 네트워크, 회선 타입 네트워크, 또는 무선 또는 셀룰러 네트워크(즉, CDMA, GSM, TDMA 등)일 수 있다. 서버(16)는 트래픽을 라우팅하거나 두 네트워크 간의 "게이트"로서 역할하기 때문에, 두 네트워크 A 및 B를 걸치고 있는 서버(16)는 게이트웨이 서버로 간주된다.

시스템(10)에 대하여, 시스템 성능을 최적화하기 위한 다수의 기본적인 네트워크 상호작용 고려사항이 존재한다. 이러한 고려사항은 팩터, 예컨대 근원 어드레스를 복스 패킷(95)이 송신되는 곳으로 적용시키고, 임의의 송신된 복스 패킷의 보전(integrity), 및 주어진 네트워크 또는 네트워크의 조합을 걸쳐 송신될 ㅅ수U( 있는 단일 메시지의 Maximum Transmission Unit)의 관리를 포함한다.

타겟 클라이언트(12)의 어드레스는 알려져야할 필요가 있어, 근원 네트워크가 복스 패킷(95)을 정확한 장소로 전달하도록 한다. IPv4 네트워크에 대하여, 어드레스는 일반적으로 IPv4 어드레스이며, 이는 고유하게 네트워크 내의 호스트를 식별하는 32 비트의 숫자이다. 다른 네트워크 기술에 대해, 어드레스는 다른 타입의 식별자일 수 있다. IP 네트워크는 DNS(Domain Name System)를 사용하여 인간이 읽을 수 있는 이름을 IP 주소에 적용하고, ARP(Address Resolution Protocol)를 사용하여 IP 어드레스를 물리적인 어드레스로 적용시킨다. 근원 네트워크 기술에 관계없이, 시스템(10)은 복스 패킷(95)을 정확한 장소로 전달하기 위해 상술하거나 다른 알려진 어드레싱 구성 중 어느 하나를 사용한다.

대부분의 임의의 패킷-기반 통신 시스템과 같이, 근원 네트워크가 복스 패킷이 캡슐화된 패킷을 전달할 수 없는 경우, 전송된 복스 패킷은 그들의 어드레스된 장소로 전달되지 않을 수 있다. 대부분의 패킷 네트워크는 트랜스미터에게 패킷이 언제 손실되었는지 알려주지 않는다. 대신 임의의 손실된 패킷을 알리고 보상하는 작업을 트랜스미터 및 리시버에 의지한다. 시스템(10)은 리시버 수신 보고 메시지를 사용하여 이러한 패킷 손실 관리를 조정하도록 지정된다. 만약 근원 네트워크가 송신자에게 손실되거나 분실된 패킷을 알려줄 수 있는 경우, 시스템(10)은 이러한 정보를 재전송 프로토콜에 이용한다.

MTU의 관리는 네트워크를 걸쳐 송신될 수 있는 최대 전송 단위(즉, 단일 메시지의 최대 크기)의 결정이다. 패킷-기반 네트워크에서, 근원 네트워크는 MTU를 부과한다. 회선-교환 네트워크에서, MTU는 네트워크 효율 및 성능을 위한 조율가능한 파라미터일 수 있다. 따라서 대부분의 경우, 근원 네트워크는 효율적으로 전송될 수 있는 복스 패킷(95)의 최대 크기를 부과하거나 결정한다. 예를 들어, IP 네트워크에서, 페이로드가 MTU를 초과하는 경우, 패킷은 분할될 수 있으나, 이는 실질적인 성능적 페널티이다. 이더넷 네트워크 상의 IP에서, 전송 장치는 1518 바이트의 MTU를 가지며, 이는 이더넷에 의해 강제된다. 가장 큰 IP 패킷은 이더넷 헤더를 위한 공간을 남겨두어야 한다. 가장 큰 UDP 패킷은 IP 및 이더넷 헤더 둘 모두를 위한 공간을 남겨두어야 하고, 예를 들어 이더넷 상에서 생성될 수 있는 가장 큰 복스 프로토콜은 이더넷 MTU(1518) - IP 헤더(20) - UDP 헤더(8) = 1490 바이트이다. 복스 프로토콜이 그 자체의 헤더를 구비할 것이기 때문에, 실제 복스 미디어 페이로드는 이더넷 네트워크 상의 1490 바이트보다 더 작을 것이다. 기가비트(Gigabit) 이더넷에서, MTU는 보다 클 수 있으나, 유사한 공식을 사용하여 결정될 것이다.

순수한 패킷-기반 네트워크는 MTU에 대한 두 가지 잠재적인 값, 로컬 링크 MTU 및 경로 MTU가 있다. 로컬 링크 MTU는 로컬 네트워크 인터페이스로 효율적으로 송신될 복스 패킷을 위한 최대 크기를 나타내도록 결정한다. 경로 MTU는 원거리 노드로 손상되지 않은 채 완전히 송신될 수 있는 복스 패킷의 최대 크기를 나타낸다. 송신자가 이더넷을 통해 연결되는 경우, 복스 패킷은 착신자로 향하는 더 작은 MTU 경로를 사용하여 다양한 다른 시스템을 통과할 수 있다. 목적지까지의 경로 상 가장 작은 MTU는 송신자에 의해 적용되고 알려질 필요가 있다. IP 분야에는 "경로 MTU 발견(Path MTU Discovery)"라고 불리는 가장 작은 MTU를 발견하는 표준 과정이 있다. 다른 종류의 네트워크에서, 동등한 과정이 사용될 수 이TEk. 또 다시, 시스템(10)이 다른 네트워크의 상부에 레이어를 구성하기 때문에, 상술한 MTU 알고리즘 중 임의의 알고리즘이 사용될 수 있다.

H. 동작 흐름도( Operation Flow Diagrams )

H.1 저장 및 스트림( Store and Stream )

도 8a 내지 도 8f를 참조하여, 일련의 흐름도가 클라이언트(12) 및 서버(16)의 저장 및 스트림 모듈(24 및 84)을 각각 설명하기 위해 제공된다. 도 8a는 메시지를 제 2 클라이언트(12 ₂ )로 전송하는 제 1 클라이언트(12 ₁ )에 대한 동작의 순서를 도시한다. 도 8b 및 도 8c는 전송 클라이언트(12 ₁ )의 PIMB 라이터(28) 및 PIMB 리더28)의 동작을 설명한다. 도 8d 및 도 8e는 수신 클라이언트(12 ₂ )의 PIMB 라이터(28) 및 PIMB 리더(26)의 동작을 설명한다. 도 8f는 서버(16)의 저장 및 스트림 모듈(84)의 흐름도를 설명한다.

도 8a에서, 장치(13 ₁ )에서 구동하는 클라이언트(12 ₁ )의 사용자는 전송될 미디어를 발생시킨다. 미디어는 많은 다른 방법으로 장치(13)에서 발생될 수 있으며, 사용자는 마이크를 통해 발언하거나 장치(13)에서 영상 컨텐츠를 생성함으로써 미디어를 생성한다. 미디어는 또한 센서 데이터, 예컨대 GPS 정보 또는 온도 값을 수신함으로써 장치(13)에 의해 생성된다. 어떻게 미디어가 발생되는지에 관계없이, 미디어는 PIMB 라이터(28)에 의해 인코딩되며(박스(130)), 이는 미디어를 인덱스된 미디어 페이로드로 변환하고 이들을 클라이언트(12 ₁ )의 PIMB(30)에 저장한다(박스(132)). 클라이언트(12 ₁ )의 PIMB 리더(26)은 PIMB(30)에서 페이로드를 독출하고, 복스 패킷을 생성하고, 네트워크(18)를 통해 패킷을 수신 클라이언트(12 ₂ )로 전송한다(박스(134)). 송신 클라이언트(12 ₁ )와 수신 클라이언트(12 ₂ ) 간의 경로를 따라 구성된 각각의 서버(16)는 전송된 페이로드를 PIMB(85)에 저장하고 복스 패킷을 다음 홉으로 전송한다(박스(133)). 수신 클라이언트(12 ₂ )에서, PIMB 라이터(28)의 네트 수신 기능은 복스 패킷을 인덱스된 미디어 페이로드로 변환하고(박스(136)), 페이로드를 클라이언트(12 ₂ )의 PIMB(30)으로 저장한다(박스(138)). 클라이언트(12 ₂ )의 PIMB 리더26)의 렌더링 모듈은 PIMB(30)으로부터 독출한 페이로드 정보를 인간이 사용하기에 적절한 매체, 예컨대 음성 또는 영상으로 렌더링한다(박스(140)). 이들 각각의 단계는 도 10b 내지 도 10e를 참조로 이하 보다 상세하게 기술된다.

도 8b에서, PIMB 라이터(28)에 의해 수행되는 인코딩 수신 기능의 순서(도 8A에서 단계(130))가 상세하게 제공된다. 개시 단계(130 ₁ )에서, 클라이언트(12 ₁ )를 구동하는 장치(13)의 사용자는 전송될 미디어를 발생시킨다. 상술한 바와 같이, 미디어는 마이크를 통해 발언하거나, 카메라를 사용하거나, 센서 데이터를 수신하거나 또는 다른 미디어 생성 컴포넌트에 의해 도출될 수 있다. 다음 단계(130 ₂ )에서, 인코딩 리시버(28a)는 미디어를 인코딩하고 인덱스된 미디어 페이로드를 생성하며(단계(130 ₃ )), 그리고 나서 이는 데이터 저장기(28c)에 의해 PIMB(30)에 저장된다(단계(132)).

도 8c에서, 송신 클라이언트(12 ₁ )의 PIMB 리더(26)에 의해 수행되는 전송 기능의 순서(도 8a에서 단계(134))가 상세하게 제공된다. 루프(134 ₁ )의 결정에서, PIMB 리더(26)의 전송 기능은 전송될 인덱스된 미디어 페이로드가 PIMB(30)에 기록되었는지 그리고 전송을 위해 사용가능한지 여부를 연속적으로 확인한다. 그러한 페이로드가 PIMB(30)에서 사용가능한 경우, 단계(134 ₂ )에 설명된 바와 같이, 데이터 우선순위 지정기(26f)는 우선 송신되어야할 페이로드를 우선순위화하며, 이는 MCMS 참여자 속성 정보를 사용하여 수행된다. 가장 높은 우선순위 페이로드에 대한 정보가 PQM을 구동하는 패킷 최적화기 모듈(26g)로 전달되며, 이는 도 9a 내지 도 9c를 참조로 보다 상세하게 기술된다. 그리고 나서 적절한 페이로드가 데이터 리트리버(26h)에 의해 PIMB(30)으로부터 검색되고(단계(134 ₄ )), 패킷타이저(26i)에 의해 복스 패킷(95)으로 변환된다(단계(134 ₅ )).그리고 나서, 복스 패킷(95)은 트랜스미터(26j)에 의해 네트워크(18)를 통해 수신 클라이언트(12 ₂ )로 전송되며(단계(134 ₆ )), 수신 클라이언트는 수신된 패킷의 속성(손실, 지터, 처리량)을 반영하는 착신 보고를 역전송한다. 이러한 착신 보고는 PQM이 주어진 리시버를 위한 MABR의 계산에 필요한 정보를 제공한다. 전술한 프로세스는 전송 단계에서 흐름도의 최상부로 향하는 귀환 화살표에 의해 지시되는 바와 같이 각각의 전송 루프에서 반복된다.

상술한 실시예에서, 미디어는 인코딩되고 PIMB(30)에 저장되고 그리고 나서 직렬 방식으로 네트워크를 통해 전송된다. 대체적인 실시예에서, 인코딩된 미디어는 PIMB(30)에 저장되고 네트워크를 통해 병렬적으로 전송될 수 있으며, 이는 두 개의 기능이 실질적으로 동시에 발생하는 것을 의미한다.

도 8d에서, 수신 클라이언트(12 ₂ )의 PIMB 라이터(28)의 네트 수신 기능에 대한 순서(도 8a에서 단계(136))가 설명된다. 개시 단계(1361)에서, 네트워크 리시버(28d)는 네트워크(18)를 통해 복스 패킷(95)을 수신한다. 데이터 저장기(28f)는 패킷을 인덱스된 미디어 페이로드로 변환하며(단계(136 ₃ )), 이는 PIMB(30)에 저장된다(단계(136 ₄ )). 페이로드가 저장됨에 따라, DQM(Data Quality Manager)(28g)가 구동한다. DQM(28g)는 손실되거나 손상된 패킷을 확인하고, 전송된 데이터의 정확한 카피의 종국적인 저장을 확인하고, 네트워크의 상태에 대한 착신 보고를 트랜스미터로 송신한다. DQM(28g)의 이러한 각각의 기능은 도 9d 내지 도 9f를 참조로 이하 보다 상세하게 기술된다.

도 9e에서, 수신 클라이언트(12 ₂ )의 PIMB 리더(26)의 렌더링 기능에 대한 순서(도 8a의 박스(140))가 설명된다. 개시 단계(140 ₁ )에서, 데이터 우선순위 지정기(26a)는 렌더링될 인덱스된 미디어 페이로드를 사용자 상태 및 존재 정보뿐만 아니라 MTSD 정보를 사용하여 MCMS 애플리케이션(20)에 의해 결정되는 바대로 우선순위화 하며, 상기 사용자 상태 및 존재 정보는 이는 사용자의 의도 및 주의 상태를 포함한다. 그리고 나서, 우선순위화된 페이로드는 데이터 리트리버(26b)에 의해 PIMB(30)으로부터 독출된다(단계(140 ₂ ). PLC/인터폴레이터(26c)는 검색된 페이로드에 대해 패킷 손실 보상 및 인터폴레이션을 수행하며(단계(140 ₃ )), 이는 어떤 코덱을 사용하는지에 종속하는 알려진 패킷 손실 보상 및 인터폴레이션 알고리즘을 사용한다. 다음 단계에서, 둘 또는 그 이상의 참여자가 동일한 대화에서 동시에 미디어를 생성한 경우(예컨대, 둘 모두가 동시에 발언한 경우), 믹서(26d)는 대화의 다수의 메시지를 믹스한다(단계(140 ₄ )). 렌더러(26e)는 믹서(26d)로부터 데이터 스트림을 렌더링하고(단계(140 ₅ ), 착신 사용자를 위한 음성, 영상, 또는 다른 미디어를 생성한다(단계(140 ₆ )).

도 8f에서, 서버(16)가 네트워크(18) 상의 이전 홉으로부터 복스 패킷을 수신하고, 저장하고, 보관하고 다음 홉으로 복스 패킷을 전송하는 순서가 설명된다. 개시 단계에서, 서버(16)는 PIMB 라이터의 네트 수신 기능을 수행하여(도 8d와 유사함) PIMB(85) 및 아카이브(89) 또는 서버(16) 내에 수신된 데이터의 인덱스된 미디어 페이로드를 저장한다. 서버(16)는 또한 PIMB 라이터의 전송 기능을 수행하여(도 8c와 유사함) 수신된 패킷을 네트워크(18) 상의 다음 홉으로 전달한다. 이러한 방식에서, 전송 클라이언트(12 ₁ )에 의해 생성된 미디어의 카피가 수신되고, 저장되고 각각의 홉에서 수신 클라이언트(12 ₂ )로의 경로를 따라 전송된다.

전술한 실시예에서, 수신된 인덱스된 미디어의 기록은 서버(16)의 PIMB(91)에 저장되고 직렬 방식으로 다음 홉으로 전송된다. 대체적인 실시예에서, 수신된 인덱스된 미디어 페이로드는 PIMB(91)에 저장되고 실질적으로 동시에 다음 홉으로 전송될 수 있다. 전송 및 수신 장치(13) 둘 모두의 PIMB(30) 상의 미디어의 저장은 미디어의 점진적인 전송 및 렌더링을 허용한다. 전송 단에서, 전송 장치에서 발생된 미디어는 그것이 수신됨에 따라 점진적으로(progressively) 네트워크를 통해 전송될 수 있다. 다양한 실시예에서, 인코딩된 미디어(그것이 어떻게 발생되는지 여부에 관계없이)는 그것이 PIMB(30)에 저장되기 전, 후, 또는 실질적으로 그와 동시에 점진적으로 전송될 수 있다. 수신단에서, 유입되는 미디어는 또한 그것이 네트워크를 통해 수신됨에 따라 점진적으로 렌더링될 수 있으며, 이는 사용자가 거의 실시간 모드로 미디어를 검토하도록 선택되는 것을 제공한다. 다양한 실시예에서, 유입되는 미디어는 그것이 수신 장치(13)의 PIMB(30)에 저장되기 전, 후, 또는 실질적으로 그와 동시에 점진적으로 렌더링될 수 있다. 만약 수신된 미디어가 타임-쉬프트 모드에서 검토될 경우, 미디어는 사용자에 의해 지정된 시간에 추후 검토되기 위해 PIMB(30)(또는 로컬 PIMB(30)에 교체된 경우 서버(16)의 PIMB(85))로부터 검색된다.

본원의 문맥 상에서, 용어 점진적인(progressive) 또는 점진적으로(progressively)는 광범위하게 해석되도록 의도되며 일반적으로 데이터의 가용성(availability)을 기반으로 하는 데이터 스트림의 연속적인 처리를 의미한다. 예를 들어, 미디어가 생성되거나 장치(13)에서 발생됨에 따라, 상기 미디어의 점진적인 인코딩, 저장, 패킷타이징 및 전송은 미디어가 사용가능한 한 연속적이다. 사용자가 발언함에 따라, 상기 미디어는 사용자의 발언의 지속기간 동안 연속적이거나 연속적으로 인코딩되고, 저장되고, 패킷타이징되고 전송된다. 사용자가 발언을 일시정지하거나 중단하는 경우, 점진적으로 처리될 미디어가 존재하지 않는다. 사용자가 발언을 다시 재개하는 경우, 미디어의 점진적인 처리는 재개된다. 수신단에서, 미디어는 또한 미디어가 수신됨(즉, 사용가능함)에 따라 처리된다. 미디어가 수신됨에 따라, 이는 연속적으로 저장된다. 이는 또한 거의 실시간 모드에서는 미디어가 수신됨에 따라 연속적으로 렌더링되거나, 타임-쉬프트 모드에서는 저장장치로부터 수신됨에 따라 연속적으로 렌더링된다. 비록 상술한 설명이 음성의 맥락에서 제공되더라도, 이는 모든 타입의 미디어가 유사한 방식으로 점진적으로 처리될 수 있음이 이해되어야 한다. 또한, 미디어의 점진적인 처리는 필수적으로 시간-인덱스된 순서로 점진적으로 처리될 필요는 없다. 오히려 미디어는 수신된 순서로 처리된다. 일 실시예에서, 미디어가 인덱스 순서를 벗어나 수신되면, 미디어는 수신된 순서로 점진적으로 처리되고, 그리고 나서 PIMB(30)에 인덱스된 순서로 구성된다. 대체적인 실시예에서, 수신된 미디어는 그 인덱스된 순서로 구성되고 그리고 나서 점진적으로 렌더링될 수 있다.

H.2 PQM 동작 흐름도( PQM Operation Flow Diagrams )

PQM(26g)은 MABR(Maximum Available Bit Rate)로 불리는 수치에 의존하며, 이는 송신 및 수신 노드 쌍 간의 실제 전송 용량 또는 대역폭의 연속적으로 계산되는 근사값(즉, 주어진 시점에서의 네트워크의 능력의 수치)이다. 즉각적인 네트워크 상태 변화에 따라, MABR는 업데이트된다. 네트워크 처리량, 패킷 손실, 및 지터의 일반적인 측정값은 MABR의 계산에 고려된다. 대체적인 실시예에서, MABR은 또한 수동으로 설정되거나 하루 중 시간, 네트워크의 타입, 다른 조건 또는 파라미터를 기반으로 제한될 수도 있다.

PQM은 또한 착신자(들)의 의도를 고려하여 시간에 민감한 전송을 최적화한다. 전송은 다음과 같은 경우 시간에 민감한 것으로 간주된다: (i) 착신자(들)의 의도가 "라이브" 전송을 검토하거나 거의 실시간 모드로 검토하는 것이거나, (ii) 착신자가 어떠한 이유로 그들의 장치(13)에 동시적으로 저장되지 않은(예컨대, 메시지가 아카이브(89)에 기저장됨) 메시지를 즉시 검토하기를 원하는 경우. 착신자의 의도는 착신자의 행동에 의해 추측되거나 또는 착신자가 그들의 의도를 설정하거나 지정할 수 있다. 반면에, 착신자의 의도가 타임-쉬프트 모드로 메시지를 검토하는 것인 경우, 전송은 시간에 민감한 것이 아닌 것으로 간주된다. 라이브 또는 타임-쉬프트 모드 중 어느 하나로 전송을 검토하는 착신자의 의도는 적어도 부분적으로 전송의 "즉시성 요건(timeliness requirement)"을 정의한다. 다양한 실시예에서, 팩터, 예컨대 전송의 긴급도 또는 우선순위는 또한 전송의 즉시성 요건을 정의하는데 고려될 수도 있다.

송신자 및 수신자 쌍 간의 네트워크 경로에서 노드는 또한 착신자의 의도의 상태를 고려하여 일관될 필요가 있다. 만약 한 타겟 착신자가 즉시성을 지시한 경우, 즉 그들이 즉시 또는 라이브로 전송을 검토하기를 원하는 경우, 다른 착신자의 요구에 관계없이, 송신자-수신자 경로를 따른 네트워크 상의 모든 중간 노드는 동일한 즉시성 요건을 구비할 것이 요구된다. 따라서, 각각의 중간 노드의 즉시성 요건은 전송이 송신되고 있는 수신 노드에 의존한다. 이러한 종속성은 가끔씩 네트워크 전송 경로의 타겟 노드를 위한 "요건 연합(union of requirements)"으로 불린다.

PQM은 각각의 스케쥴된 메시지 페이로드 전송을 위한 "IBR(Ideal Bit Rate)" 또는 이상 비트율을 더 고려한다. 시간에 민감한 전송에서, IBR은 실질적으로 실시간이거나 라이브 통신을 위해 요구되는 패킷화율(여기서는 RTBR(Real Time Bit Rate) 또는 실시간 비트율로 언급한다)을 기반으로 계산된다. 예를 들어, 음성에서, 20 msec의 음성 데이터를 포함하는 매 20 msec의 패킷의 패킷화율이 라이브 대화를 수행하기 위해 허용가능한 IBR로 간주된다. 초당 킬로비트의 시스템을 위한 RTBR은 1초의 음성 페이로드 데이터의 사이즈에 전송을 위해 생성될 모든 네트워크 헤더의 사이즈를 더한 것일 수 있다. 영상 미디어 또는 음성 및 영상의 조합에서, RTBR은 단순한 음성보다 실질적으로 더 높을 것이다. 다른 타입의 미디어, 예컨대 센서 또는 GPS 위치 데이터에서, RTBR은 음성의 RTBR보다 더 낮을 것이다. 시간에 민감하지 않은 전송에서, IBR은 MEBR(Maximum Efficiency Bit Rate)로 설정되어 네트워크를 통한 전송의 사용 또는 효율을 최적화한다. MEBR은 근원 네트워크를 위한 가장 큰 가능한 값으로 패킷화율을 조절함으로써 계산된다. 다중 메시지 또는 페이로드가 송신 및 수신 쌍 간에 전송될 경우, AIBR(Aggregate IBR)은 전송을 위해 고려된다.

PQM은 각각의 송신 및 수신 쌍에 대해 데이터를 일련의 전송 루프로 송신함으로써 동작한다. 각각의 송신 및 수신 쌍에 대한 전송 루프는 독립적이다. 네트워크 상의 임의의 전송은 다른 송신-수신 쌍의 MABR에 영향을 미칠 수 있다. 따라서, MABR은 바람직하게 모든 착신자에 대해 연속적으로 계산된다.

도 9a 내지 도 9c를 참조하여, 단일의 송신 및 수신 쌍에 대한 PQM의 동작의 순서를 설명하는 흐름도가 설명된다. 도 9a에서, 단일의 송신 및 수신 쌍 간의 MABR이 결정되는 단계가 설명된다. 도 9b에서, 단일의 송신 및 수신 쌍에 대한 각각의 전송 루프에 대한 AIBR의 계산을 위한 단계를 설명하는 흐름도가 설명된다. 도 9c에서, 송신 및 수신 쌍 간에 전송할 데이터의 양을 결정하는 순서가 설명된다. 위 세 도면에서 설명되는 프로세스는 이하 보다 상세하게 기술되는 바와 같이, 동시에 수행되고 서로 간에 상호작용한다.

*도 9a에서, 송신 및 수신 쌍 간의 네트워크 인터페이스에 대한 MABR을 계산하는 흐름도(50)이 도시된다. 개시 단계(50 ₁ )에서, 송신 및 수신 쌍 간의 네트워크 인터페이스가 감시된다. 송신자는 주기적으로 보고를 수신하며, 이는 단계(50 ₂ )의 수신자 단에서 네트워크 연결의 상태에 관한 정보를 포함한다. 상기 보고는 네트워크 인터페이스에서 수신자에 의해 관찰된 데이터 처리량(50 ₃ ), 패킷 손실(50 ₄ ), 및 지터(50 ₅ )의 현재 상태에 관한 정보를 포함한다. 단계(506)에서, MABR은 상기 보고에 포함된 이러한 관찰을 기반으로 송신자 측에서 계산된다. 이러한 보고 내의 데이터를 감시하거나 관찰함으로써, MABR 값은 송신 및 수신 쌍 간의 현재 네트워크 용량 또는 상태를 기반으로 연속적으로 조절된다. 네트워크 용량이 데이터 전송을 위해 보다 호의적으로 됨에 따라, MABR은 증가할 것이다. 만약 네트워크 용량이 전송에 덜 호의적으로 되는 경우, MABR은 감소할 것이며, 사용불가능한 네트워크에서는 잠재적으로 완전히 영으로 된다. 상기 보고는 TCP 네트워크에서 노드에 의해 생성되는 패킷 손실 보고와 유사하지만, 그뿐만 아니라 추가적으로 처리량 및 지터 정보를 더 포함한다.

송신 및 수신 쌍 간에 다수의 네트워크 인터페이스가 있는 경우, MABR은 착신 보고가 수신되는 각각의 인터페이스에 대해 계산된다. 만약 어떠한 트래픽도 네트워크 상에서 최근에 송신되지 않은 경우, 또는 어떠한 착신 보고도 수신되지 않은 경우, MABR은 현재의 네트워크 상태를 반영하지 않을 수 있다. 그러나, 착신 보고는 데이터가 전송되는 동안 수신자에 의해 연속적으로 생성되며, 송신자의 MABR 수치는 보다 정확한 값으로 빠르게 수렴할 것이다.

도 9b를 참조하여, 전송 루프에 대한 AIBR을 계산하는 단계를 설명하는 흐름도(52)가 설명된다. 개시 단계(52 ₁ )에서, 현재 루프 내의 송신 및 수신 쌍 간에 전송될 준비가 된 미디어(이 메시지에 속하는 시간이 인덱스된 미디어의 일부를 의미함)를 구비한 메시지가 확인된다. 미디어를 구비한 메시지의 리스트가 구축된다(52 ₂ ). 리스트 내의 각각의 메시지에서(52 ₃ ), 각각의 메시지의 시간 민감성(time-sensitivity) 즉시성 요건(timeliness requirement)이 고려된다(52 ₄ ). 특정 메시지가 시간에 민감하지 않은 경우, IBR은 MEBR(Maximum Efficiency Bit Rate)로 설정된다(52 ₅ ). 반면에, 메시지가 시간에 민감한 경우, IBR은 RTBR(Real Time Bit Rate)로 설정된다(52 ₆ ). 다음 단계(52 ₇ )에서, 리스트 내의 각각의 메시지에 대한 이전에 계산된 IBR이 함께 합산되며, 이는 전송 루프에 대한 AIBR(Aggregate Ideal Bit Rate)를 도출한다(52 ₈ ). 복귀 화살표에 의해 지시되는 바와 같이(52 ₉ ), 전술한 프로세스는 송신 및 수신 쌍 간의 각각의 전송 루프마다 반복된다.

도 9c를 참조하여, 전송 루프마다 송신 및 수신 쌍 간에 전송할 데이터의 비율을 결정하는 순서를 설명하는 흐름도(54)가 설명된다. 개시 단계(54 ₁ )에서, MABR은 다음 전송을 위해 AIBR(도 9b에서 결정된 바와 같음)과 비교된다.

MABR이 AIBR보다 크거나 동일한 경우, 루프 내의 전송이 준비된 것으로 식별되는 모든 메시지는 IBR 레이트에서 패킷화되고(54 ₂ ), 전송된다(54 ₃ ).

반면에, MABR이 AIBR보다 작은 경우, PQM이 데이터의 적절한 카피의 적시 전달, 사용가능한 대역폭의 효율적인 사용, 및/또는 페이로드 컨텐츠 및 품질, 패킷 사이즈, 및 현재 네트워크 상태를 만족시키는 전송율에 대한 조절의 목표를 만족하도록 일련의 과정들이 적용된다.

개시 단계에서, 리스트 내의 메시지는 시간 민감성(time sensitivity)에 대해 검토된다(54 ₄ ). 시간에 민감한 메시지가 없는 경우, 비트율은 MABR까지 감소되고(54 ₅ ), 메시지는 전송된다(54 ₃ ).

리스트가 시간에 민감한 메시지를 포함하는 경우, 시간에 민감하지 않은 메시지에 대해 할당된 비트율이 MABR 한계를 만족할 때까지 감소된다(54 ₆ ). 비트율이 완전히 영까지 감소하는 단계가 MABR을 만족하기에 불충분한 경우, 시간에 민감하지 않은 메시지는 루프 내에서 전송될 메시지의 리스트로부터 제거된다. 비트율이 감소되어 MABR보다 작거나 동일한 경우, 남은 메시지는 패킷화되고 전송된다(54 ₃ ).

시간에 민감하지 않은 메시지의 제거가 MABR을 만족하기에 충분하지 않은 경우, 남은 시간에 민감한 메시지에 대한 보다 낮은 품질의 코덱(또는 코덱들)의 사용을 포함하는 또 다른 과정이 사용된다. 전송 루프 도중 보다 적은 비트를 송신함으로써 페이로드 데이터를 가능한 한 신속하게 전송하도록 하는 시도가 수행된다. 다른 말로, 페이로드의 품질을 감소시킴으로써, 전송은 주어진 기간에 보다 적은 비트를 송신한다. 다양한 실시예에서, 각각 서로 다른 비트율 대 품질의 트레이드 오프를 구비하는 상이한 코덱 또는 코덱들이 사용될 수 있다. 보다 낮은 품질의 코덱 또는 코덱들의 사용이 충분한 경우, 즉 MABR 제한이 만족된 경우, 메시지는 전송된다(54 ₃ ).

보다 낮은 품질의 코덱(들)의 사용이 여전히 MABR을 만족하지 못하는 경우, 시간에 민감한 메시지의 패킷화 간격이 증가된다(54 ₈ ). 이러한 과정으로, 헤더 대 페이로드(header-to-payload) 비율이 증가되며, 이는 전반적인 비트율을 감소시키지만 지연을 야기한다(즉, 착신자로의 전송의 전달의 지연). 이러한 과정이 AIBR을 MABR보다 작거나 동일한 정도로 감소시키면, 전송이 수행된다(54 ₃ ).

패킷화 간격의 변경 후 MABR이 여전히 만족되지 않은 경우, 비트율은 MABR 한계 내로 진입할 때까지 점진적으로 낮아진다(54 ₉ ). 비트율이 이러한 방식으로 낮아지는 경우, 시간에 민감한 메시지는 라이브 대화를 유지하기에 불충분한 비율로 전송된다. 따라서, 대화는 "라이브"에서 벗어나도록 강제된다. 네트워크가 다운되거나 상태가 매우 열악한 경우, 데이터 전송이 발생하지 않을 가능성이 있다. 또 다시, 전술한 시퀀스가 각각의 송신 및 수신 쌍 간의 전송 루프(54 ₁₀ )에 대해 반복된다.

송신 및 수신 쌍 간에 다수의 네트워크 인터페이스가 존재하는 경우, 도 9c에관하여 기술된 시퀀스가 착신 보고가 사용가능한 각각의 인터페이스에 대해 수행된다. 다양한 실시예에서, 송신자는 다수의 인터페이스 사이에 전송 로드를 분배하는 로직을 포함할 수 있다. 다른 예에서, 페이로드는 오직 하나의 인터페이스 상으로 송신될 수 있는 반면, 다른 실시예에서, 인터페이스의 일부 또는 전부가 사용될 수 있다.

전술한 기술은 시스템(10)의 임의의 송신 및 수신 쌍에 관련된다. 대부분의 상황에서, 송신 및 수신 쌍은 각각 클라이언트(12), 사용가능한 장치(13) 및 서버(16), 두 개의 서버(16), 서버(16) 및 클라이언트(12)가 이네이블된 장치(13), 또는 두 개의 클라이언트들(12)조차 포함할 것이다. 송신 노드가 동시에 둘(또는 그 이상)의 수신 노드로 전송하는 경우, 도 9a 내지 도 9c에 관련하여 기술된 바와 같은 전술한 시퀀스는 각각의 수신-송신 쌍에 대해 동시적으로 발생한다.

H.3 DQM 동작 흐름도( DQM Operation Flow Diagrams )

DQM(28g)는 클라이언트(12)에서 수신된 데이터가 손상되었는지 또는 손실된 패킷이 있는지 여부를 결정한다. 또한, 수신 클라이언트(12)의 DQM(28g)는 착신 보고를 생성하며, 이는 네트워크 상의 전송 노드로 역전송된다. DQM(28g)는 또한 백그라운드 프로세스를 구동하여 전송된 데이터의 정확한 카피가 종국적으로 수신되고 저장되는지 보증한다. 이러한 기능은 이하 도 9d 내지 도 9f에 각각 기술된다.

도 9d를 참조하여, 손실되거나 및/또는 손상된 데이터를 확인하는 DQM(28g)의 동작을 설명하는 흐름도가 설명된다. 개시 단계(56 ₁ )에서, DQM(28g)은 알려진 기술, 예컨대 CRC 또는 유사한 완전성 확인 메커니즘을 사용하여 손상된 패킷을 확인한다. 패킷이 손상된 경우, 패킷은 손실된 것으로 처리된다(56 ₂ ). 다음으로 DQM(28g)은 임의의 패킷이 손실되었는지 확인한다(56 ₃ ). 기결정된 기간 후 순서를 벗어난 패킷이 수신되지 않은 경우, 손실된 것으로 간주된다. DQM(28g)은 DNQS(32) 내에 임의의 손실되거나 손상된 패킷을 기록한다(56 ₄ ). 반면, 손상되거나 손실된 패킷이 검출되지 않으면, DQM(28g)은 수신된 데이터의 품질이 대역폭을 절약하기 위한 목적으로 송신자에 의해 의도적으로 저하되지 않았는지 여부를 결정한다(56 ₅ ). 저하된 품질은 DNQS(32)에 기록된다. 수신된 데이터의 품질이 저하되거나 그렇지 않음에 관계없이, 데이터의 착신 정보(예컨대, 패킷 시퀀스 번호, 타임 스탬프, 및 패킷이 송신될 네트워크에서 다음 노드의 네트워크 어드레스)가 DNQS(32)에 저장된다(56 ₇ ). 전술한 프로세스는 흐름도의 시작으로 돌아가는 화살표에 의해 지시된 바와 같이 연속적으로 반복된다.

도 9d에 상세하게 기술된 프로세스의 결과에 따라, 저하되지 않은 패킷의 수신에 관한 정보, 저하된 품질의 패킷의 결함, 및 손실된 패킷은 모두 DNQS(32)에 저장된다. 미디어가 수신되는 대로, DNQS(32)는 미디어의 상태에 관한 정보를 업데이트하도록 유지한다.

도 9e를 참조하여, DQM(28g)의 착신 보고 생성기 기능의 동작을 설명하는 흐름도가 설명된다. 개시 단계에서, DNQS(32)는 착신 보고가 생성될 필요가 있는 임의의 미디어가 존재하는지 여부를 결정하기 위해(58 ₂ ) 주기적으로 스캐닝을 수행한다(58 ₁ ). 대답이 아니오인 경우, 상기 스캐닝 프로세스는 반복된다. 반면, 미디어가 식별되면, 프로세스는 미디어가 시간에 민감한 것인지 여부를 결정하며(58 ₃ ), 이는 사용자가 미디어를 라이브로 검토하기를 의도하는지 또는 사용자가 그들의 장치(13)에 저장되지 않은 미디어를 즉시 검토하기를 원하는지 여부를 의미한다.

시간에 민감하지 않은 경우, 착신자는 송신자에게 재전송 우선순위를 낮게 설정하도록 알린다(58 ₄ ). 시간에 민감한 경우, 패킷 손실의 양이 고려된다(58 ₅ ). 패킷 손실의 양이 사용가능한 품질 범위를 벗어나는 경우, 재전송 우선순위가 높게 설정된다(58 ₆ ). 상술한 바와 같이, 패킷 손실의 양이 너무 크면, 착신자는 수신 시 미디어를 검토할 수 없을 수 있다. 품질이 허용가능한 범위에 있는 경우, 즉 전송의 품질이 렌더링되면 이해할 수 있을 정도로 충분한 경우, 착신 보고의 송신에 대한 우선순위가 낮게 설정된다(58 ₄ ). 착신자가 수신시 검토하고 있는지 아닌지에 관계없이, 착신 보고는 송신되며(58 ₇ ), DNQS(32)는 업데이트되고 NQM(Network Quality Manager)(28h)는 업데이트된다(58 ₉ ). 따라서, 단계(58 ₄ )에 정의된 재전송 요청은 시간-민감성을 기반으로 조건부이다. 단계(58 ₆ )에 정의된 전송 요청은 시간-민감성 및 품질 둘 모두에 조건부이다.

재전송 우선순위는 재전송을 요구하는 미디어에 대한 전송률을 적절히 우선순위화하도록 송신자의 PQM(26g)에 알린다. 예를 들어, 재전송 우선순위가 높게 설정되면, 송신자의 송신하는 PQM(26g)은 임의의 새로운 미디어가 오기 전에 임의의 재전송을 송신해야 한다. 우선순위가 낮으면, PQM(26g)은 임의의 새로운 미디어 후에 재전송된 미디어를 송신해야 한다.

전술한 프로세스는 연속적으로 반복되어 미디어가 수신됨에 따라 착신 보고가 생성된다. 송신자가 적절한 방식으로 착신 보고를 수신하지 않으면, 송신자의 PQM(26g)은 전송률을 감소시킬 것이며, 어떠한 착신 보고도 수신되지 않으면 종국적으로 전송을 중지할 것이다.

도 9f를 참조하여, 손실되거나 저감된 미디어의 요청에 대한 순서를 설명하는 흐름도가 설명된다. 개시 단계(60 ₁ )에서, DNQS(32)는 손실되거나 저감된 미디어(60 ₂ )를 주기적으로 스캔한다. 만약 손실되거나 저감도니 미디어가 존재하지 않는 경우, 상기 정의된 스캔은 주기적으로 반복된다.

순서에서 벗어난 패킷이 기결정된 임계 기간 후에 도달하지 않은 경우 미디어는 손실된 것으로 간주된다(60 ₃ ). 임계 기간 전에 패킷이 도달하면, 이는 더 이상 손실된 것으로 간주되지 않는다. 반면에, 패킷이 임계치를 초과한 후에도 도달하지 않으면, 손실된 것으로 간주된다. 손실된 패킷으로, 재전송의 낮은 우선순위 요청이 만들어지고(60 ₄ ) 요청의 시간이 DNQS(32)에 기록된다(60 ₅ ). 이러한 프로세스는 손실된 패킷이 수신될 때까지 반복된다. 손실된 패킷이 도달하고 대응 미디어가 PIMB(30)에서 사용가능한 경우, 미디어의 손실된 상태는 DNQS(32)에서 제거된다. 따라서, 단계(60 ₄ )에 정의된 재전송 요청은 미디어가 손실된 것으로 결정되는지 여부를 기반으로 조건부이다.

저감된 경우, DQM(32)은 미디어가 라이브 대화의 일부인지 여부를 결정한다(60 ₆ ). 그렇지 않은 경우, 저감된 미디어의 완전한 품질의 카피에 대한 요청이 만들어지며(60 ₇ ), 완전한 품질의 미디어가 손실된 것으로 지정되고(60 ₈ ) 요청 시간이 DNQS(32)에 기록된다(60 ₉ ). 미디어가 라이브 대화의 일부인 경우, 네트워크 대역폭을 보존하기 위한 어떠한 조치도 즉시 취해지지 않는다. 대화가 라이브 모드를 벗어나도록 전환하면, 단계(60 ₇ ) 내지 단계(60 ₉ )는 저감된 미디어의 완전한 품질(즉, 정확하거나 완전한) 카피가 종국적으로 수신됨을 보증하도록 수행된다. 데이터가 착신자 클라이언트(12)의 PIMB(30)에 사용가능하게 된 경우, 결합된 미디어의 저감된 상태가 DQNS(32)로부터 제거된다. 단계(60 ₇ )에 정의된 전송 요청은 미디어가 저감되고 라이브 대화의 일부인지 여부에 대해 조건부이다.

전술한 프로세스는 단계(60 ₅ ) 및 단계(60 ₉ )로부터 흐름도의 최상부인 단계(60 ₁ )까지의 복귀 화살표에 의해 지시된 바와 같이, 연속적으로 반복된다. 도 9f에 도시된 프로세스를 반복함으로써, 모든 전송된 미디어의 정확한 카피가 종국적으로 착신 장치(13)의 PIMB(30)에 저장된다. 이러한 방식으로, 전송된 미디어의 정확한 카피의 저장이 착신자 장치(13)에서 보증된다.

I. GUI( Graphical User Interface )

도 10을 참조하여, 클라이언트 애플리케이션(12)을 구동하는 예시적인 장치(13)가 설명된다. 장치(13)는 GUI 디스플레이(110), 데이터 엔트리 버튼, 키, 또는 키보드(112), 마이크(114), 및 전기적 신호를 음성으로 변환하는 트랜스듀서(116), 예컨대 스피커를 포함한다. 디스플레이(110)는 또한 터치 스크린으로서 입력을 수용할 수 있다. 또한, 디스플레이(110) 및 키보드(112)는 터치 스크린 인터페이스를 이용하여 결합될 수 있다. 상술한 바와 같이, 장치(13)는 다양한 서로 다른 통신 툴, 예컨대 데스크탑 컴퓨터, 랩탑 또는 다른 모바일 컴퓨터, PDA(Personal Digital Assistants), 프로그래밍 가능한 랜드-라인(land-line) 또는 이동통신 전화기, 또는 프로그래밍 가능한 라디오, 또는 프로그래밍 가능한 통신 장치의 임의의 다른 타입일 수 있다. 도면에 도시된 예시적인 장치(13)는 "일반적"이도록 의도되며, 이러한 견지에서 이는 상기 열거된 모든 통신 장치를 나타내거나 포괄한다. 또한, 용어 "시각적인(graphical)" 사용자 인터페이스는 제한적으로 해석되지 않아야 한다. 오디오/DTMF 인터페이스, VUI(Voice User Interface), 라디오 스위치 인터페이스, 또는 그 조합을 포함할 뿐만 아니라 장치(13)에 구현될 수 있는 다른 타입의 사용자 인터페이스는 모두 이하 기술되는 다양한 기능을 구현하도록 사용될 수 있다. 단순화를 위해, 사용자가 장치(13)와 상호작용할 수 있는 이러한 타입의 방법 각각은 일반적으로 "사용자 인터페이스"로 언급된다.

타입에 관계없이, 모든 장치(13)는 바람직하게 사용자가 장치(13)를 동작하고 시스템(10) 내의 다른 사용자와 통신할 수 있는 사용자 인터페이스를 구비한다. 비록 사용자 인터페이스가 가상적으로 무한한 개수의 상이한 외관 및 느낌 구현을 구비하도록 설계될 수 있어도, 모든 장치(13)가 공통으로 구비해야하는 특정 기능 및 특징이 존재한다. 이러한 기능 및 특징은 이하 열거된다.

사용자 인터페이스는 바람직하게 하나 또는 그 이상의 다음과 같은 상태 지시자(status indicators) 또는 플래그(flags)를 포함한다: (i) 배터리 지시자; (ii) 연결성(connectivity) 지시자; (iii) 시계; (iv) 트랜스미터 상태; (ㅍ) 전송 싱크 상태; (vi) 검토(reviewing) 상태; (vii) 주의가 필요한 우선순위 메시지; 및 (viii) 손실된 메시지.

사용자 인터페이스는 바람직하게 다음과 같은 단일 대화를 수행하고 관리하는 기능, 플래그 및 컴포넌트를 포함한다: (i) 대화의 이름 및/또는 참여자의 리스트; (ii) 대화 상태; (iii) 대화 타입; (iv) 대화 지속기간; (v) 대화의 헤드 뒤의 시간; (vi) 눈에 띄는(outstanding) 메시지; (vii) 참여자의 존재/상태; (viii) 내비게이션을 구비한 메타데이터; (iix) 대화 속성 또는 지정자(designators); (ix) 제목, 스케쥴링, 참여자, 대화 요약을 포함한 대화 설정; 및 (v) 어떤 참여자가 메시지에 기여하고 어떤 참여자가 메시지를 청취하거나 검토하는지를 보여주는 지시자.

사용자 인터페이스는 또한 바람직하게 바로 위에서 열거된 사항들 외에 다음과 같은 다수의 대화를 수행하고 관리하는 기능, 플래그 및 컴포넌트를 포함한다: (i) 각각의 대화에 대한 이름/식별자; (ii) 라이브/액티브 또는 스탠딩/인액티브 지시자; (iii) 리뷰 위치, 헤드 또는 타임 쉬프트 중 어느 하나; (iv) 우선 순위 및 다른 속성; 및 (v) 어떤 위치의 대화가 손실되었는지의 지시자.

사용자 인터페이스는 또한 바람직하게 다음과 같은 많은 내비게이션 특징을 포함한다: (i) 대화 당 DVR 스타일의 빠른 전/후 재생; (ii) 인스턴트 메시징 스타일의 퍼스널 메시지 내비게이션; (iii) 대화 시간 지시자; (iv) 타임 스케일 쉬프팅(즉, 대화의 메시지 또는 메시지들에 걸친 전방 및 후방의 줌(zooming)); (v) 대화의 우선순위 변경; (vi) 통화 종료(hanging up); 및 (vii) 홈(home).

전술한 기능 및 특징은 다양한 방법, 예컨대 터치스크린의 GUI(110), 또는 다른 입력 장치, 예컨대 데이터 엔트리 버튼, 키, 또는 키보드(112), 마우스, 음성 활성화 명령, 또는 그 조합을 사용하여 구현될 수 있다. 또 다시 상기 열거된 기능 및 특징 및 그들이 어떻게 구현되었는지는 소모적으로 되도록 의도되지 않는다. 사용될 수 있는 다양한 방법 및 기술은 매우 포괄적이고, 여기에 이들 모두를 열거하거나 논의하는 것은 실제적이지 않다.

J. 대화( Conversations )

MCMS 애플리케이션(20)은 대화의 많은 상이한 타입, 예컨대 지연이 어디부터 되었는지 참여자가 언제 발언하는지 및 다른 참여자(들)이 첫 번째 참여자를 듣는 것이 매우 작은 거의 실시간 또는 "라이브"의 콜, 참여자가 메시지들 간에 보다 긴 지연을 두고 앞뒤로 음성 메시지를 교환하는 대화, 다수의 사용자가 관여되는 "라이브" 컨퍼런스 콜, 일반적으로 스케쥴된 시간의 스탠딩 컨퍼런스 콜, 또는 동시 프리핑으로서 참여자 각각이 다른 사람을 위해 미리 메시지 브리핑을 남겨 모두가 라이브 컨퍼런스 콜에 참여하기 전에 검토하는 구성가능하도록 구조화된 콜 타입을 지원한다. MCMS 애플리케이션(20)의 또 다른 고유한 속성은 사용자가 다른 타입의 대화간에 전환할 수 있는 기능이다. 예를 들어, 참여자는 음성-메시징 모드에서 라이브 콜로 끊김없이 전환하거나 역으로 전환할 수 있다. 또는 라이브 컨퍼런스 콜의 참여자는 음성-메시징 모드로 전환하고, 컨퍼런스 콜 후에 업데이트 또는 액션 아이템을 서로 간에 송신할 수 있다. 다수의 예가 기록되지만, 시스템(10)은 매우 유연하고 상이한 타입의 콜 또는 대화 및 다수의 대화들간의 전환을 위한 많은 옵션을 제공하는 것이 이해되어져야 한다. 메시지들 간의 지연을 변경함으로써, 참여자는 효율적으로 그들의 필요에 가장 적합한 타입의 대화 사이에 흘러갈 수 있다. 따라서, 상기 예는 제한적으로 해석되지 않아야 한다.

상술한 바와 같이, 대화는 그들의 원래의 문맥 및 문장으로 유지되는 메시지로 구성된다. 송신된 메시지는 기존의 대화에 속하거나 또는 새로운 대화를 개시한다. 일반적은 대화는 정의된 내용, 주제, 시간, 그룹 또는 채널에 연관된 메시지의 세트를 포함한다. 예를 들어, 대화는 사람들의 공통 그룹, 예컨대 클럽의 멤버를 포함할 수 있으며, 회사는 고정된 시간, 에컨대 주간 판매 미팅에 스탠딩 대화를 구비하거나, 친구들은 다양한 주제, 예컨대 저녁식사 계획을 짜는 것에 대한 애드-호크(ad-hoc) 대화를 가질 수 있다.

각각의 대화는 한 세트의 속성에 의해 정의되며, 이는 이름, 참여자의 리스트, 시작 및 종료 시간, 및 적어도 진행중이거나, 활성화되거나, 또는 종료된 상태를 포함한다. 다른 대화 상태가 다른 실시예에서 가능하다. 사용자는 그들의 장치(13) 상의 MCMS 애플리케이션(20)과 상호작용한다. 바람직한 실시예에서, 인터페이스는 사용자가 임의의 다양한 속성에 의해 대화를 구성하도록 한다.

참여자 및 대화 간의 관계는 또한 속성을 가진다. 이러한 속성은 우선순위, 상태(대화의 참여자의 상태)를 포함하지만, 이에 제한되지는 않는다. 참여자 상태의 값은 능동(active), 한 번에 하나 이상의 대화에 참여, 타임-쉬프트 모드로 대화를 검토, 라이브를 따라잡기(CTL), 수동적으로 참여(즉, 능동적이지 않게 검토하지만, 높은 우선순위 메시지를 수신), 대기, 또는 대화 무시(즉, 대화에 참여하거나 기록하는 것을 거부)를 포함한다.

참여자의 관점으로부터, 사용자는 메시지의 상대적인 우선순위를 선택하거나 정의할 수 있다. 예를 들어, 사용자의 상관으로부터의 메시지는 일반적으로 사회적 지인보다 높은 우선순위가 주어질 것이다. 일부 실시예에서, 착신자는 그들 소유의 우선순위를 설정하는 기능을 구비한다. MCMS-C의 구현에서, 사용자는 연속적으로 렌더링될 그들의 대화의 서브세트를 선택한다. 그리고 나서, 사용자는 이들 대화를 위한 순서화된 우선순위를 설정한다. 시스템은 사용자에 의해 설정된 우선순위를 사용하여 렌더링될 메시지를 순서화한다. 전술한 알고리즘은 사용자 우선순위 및 사용가능한 메시지 데이터에 관한 정보(MTSD를 넘어섬)를 사용하여 렌더링될 메시지를 큐잉한다(queue).

다른 실시예에서, 예컨대 전술적인 통신에서, 착신자는 우선순위를 설정하는 기능을 가지지 않거나 제한된 기능을 가질 수 있다. 예를 들어, 소방관은 소방대장으로부터의 메시지의 우선순위를 낮추는 기능을 구비하지 않을 수 있다. 그러나, 송신하는 사용자는 긴급한 도는 매우 중요한 메시지를 송신하는 기능을 구비할 수 있다. 메시지를 긴급하거나 비상상태로 태깅함으로써, 메시지는 착신자에게 가능한한 즉시 렌더링되며, 착신자의 임의의 우선순위 설정에 우월해진다. 다수의 응급 메시지 간의 임의의 충돌은 기결정된 우선순위 구성을 기반으로 해결된다.

K. MCMS 동작( MCMS Operation )

도 11a를 참조하여, MCMS 애플리케이션(20)의 주요 기능을 그룹화하는 조직도가 설명된다. 주요 기능은 계정(account) 관리(1102), 대화 관리(1104), 집합적인(aggregate) 대화 리스트 관리(1106), 대화 참여자(1108), 콜 제어(1110), 및 연락처 관리(1112)를 포함한다. 시스템(10)에 등록하고 로그인한 후, 사용자는 다양한 관리 기능을 구현한 그들의 장치(13)의 사용자 인터페이스를 통해 탐색할 수 있으며, 이는 이하 상세하게 기술된다. 일부 실시예에서, 이러한 기능성은 매우 큰 유연성을 제공할 것이다. 다른 실시예에서, 예컨대 전술적이거나 통신 라디오에서, 사용자 인터페이스의 구현은 장치의 이용성을 만족시키도록 기구성된 많은 사용자 기능성 및 옵션으로 제한될 수 있다. 이하의 논의는 예시적이고 MCMS 기능성의 소모적인 설명이 되도록 의도되지 않으며, 단지 일부 MCMS 속성의 개관을 제공하도록 의도된다.

K.1 계정 관리( Account Management )

계정 관리 기능(1102) 하에서, 등록된 사용자는 특정 설정 및 선호도를 변경할 수 있다. 사용자는 그들의 이메일 주소, 패스워드, 이름, 전화번호, 전화 패스워드, 착신 번호(call-in number), 기본 및/또는 사용자 정의 렌더링 속도, 태그, 메시지 검토에 관한 이득(gain) 또는 볼륨 레벨, 라이브로 따라잡기(CTL) 모드 등을 변경할 수 있다. 이러한 변경을 가하기 위해, 사용자는 적절한 정보를 장치(13)의 인터페이스(110)를 통해 입력한다. MCMS 애플리케이션(20)은 업데이트된 선호도를 MCMS 데이터베이스(22)로 기록함으로써 응답한다.

K.2 대화 관리( Conversation Management )

도 11b에 도시된 바와 같이, 대화 관리(1104)는 사용자가 그들의 집합적인 대화 리스트를 보고, 새로운 대화를 생성하고, 대화의 세부사항을 업데이트하고, 대화를 삭제하고, 대화를 종료하도록 하는 기능의 세트이다. 각각의 기능은 이하 기술된다.

대화 보기(View Converesation)(1104a) - 각각의 대화에 대해, MCMS 애플리케이션(20)은 사용자에게 다음과 같은 속성 중 하나 또는 그 이상을 제공할 수 있다: 대화의 이름, 실제 시작 시간, 마지막 활동, 태그, 지속기간, 및 참여자의 리스트. 각각의 참여자에 대한 이름 및/또는 전화 번호, 상태(라이브, 다른 콜, 과거(in past), 따라잡기 모드(catch-up-mode), 오프라인-연락가능함(offline-reachable), 오프라인-연락불가능(offline-unavailable)).

대화 생성(1104b) - 사용자는 대화 이름, 연락처 리스트, 및 선택적인 스케쥴된 시작 시간을 입력함으로써 인터페이스(110)을 통해 대화를 생성한다. 만약 시작 시간이 지정되지 않는다면, 시작 시간은 즉시이다. 이에 응답하여, MCMS 애플리케이션(20)은 데이터베이스(22)에 새로운 대화를 생성하며, 이는 연락처 리스트 상의 각각의 참여자에 대한 기록과 결합된다. MCMS 애플리케이션(20)은 또한 연락처 리스트 상의 각각의 사용자에 대한 참여자 기록을 데이터베이스(22)에 생성하며, 이는 발신자가 연락처 리스트 상의 다른 사람의 존재 정보를 수신하도록 한다. 대화가 스케쥴링되면, MCMS 애플리케이션(20)은 지정된 시간에 대화를 시작한다. 그 외에, 대화는 바로 시작된다.

대화의 세부사항 업데이트(1104c) - 사용자는 사용자 인터페이스(110)를 통해 대화에 변경을 가할 수 있다. 예를 들어, 참여자는 추가되거나 제거될 수 있다. 참여자의 상태에 대한 임의의 변화는 MCMS 데이터베이스(22)에 업데이트된다.

대화 삭제(1104d) - 사용자는 인터페이스(110)를 통해 특정 대화를 그들의 대화 리스트에서 삭제할 수 있다. 이에 응답하여, MCMS 애플리케이션(20)은 데이터베이스(22)에 그 변화를 기록하고, 대화가 삭제된 것으로 지시한다.

대화 종료(1104e) - 사용자는 대화의 종료 또는 차단을 결정할 수 있다. 일 실시예에서, 대화를 생성한 사용자만이 대화의 종료를 결정할 수 있다.

K.3 집합적인 대화 리스트 관리( Aggregate Conversation List Management )

도 11c에 도시된 바와 같이, 집합적인 대화 리스트 관리(1106)는 사용자가 다수의 대화에 관여하도록 하는 기능의 세트이다. 집합적인 대화 리스트 관리 기능은 사용자가 그들의 장치의 인터페이스(110)를 통해, 임의의 대화에 "라이브"로 참여하도록 하는 반면, 다른 대화에는 타임-쉬프트 모드로 참여하도록 한다.

선택된 대화(1106a) - 인터페이스(110)를 통해, 사용자는 현재의 사용자의 집합적인 대화 리스트 중 임의의 대화를 선택할 수 있다. 현재 대화의 메시지는 "라이브" 또는 타임-쉬프트 모드 중 어느 하나로 렌더링될 수 있다. 사용자는 집합적인 대화 리스트에서 현재의 대화를 때때로 전환할 수 있다.

대화 교환 모드(1106b) - 선택적인 실시예에서, 사용자는 동작의 MCMS, MCMS-C 및 MCMS-S 모드로부터 교환할 수 있다.

K.4 대화 참여( Conversation Participation )

도 11d에 도시된 바와 같이, 대화 참여(1108)는 사용자가 대화를 시작하고, 대화에 참여하도록 하는 통지를 수신하고, 대화 상태 정보를 획득하고, 대화를 끊도록 하는 기능의 세트이다.

대화 시작(1108a) - 대화가 생성된 후, 인터페이스(110)를 통한 사용자에 의하거나 또는 MCMS 애플리케이션(20)의 스케쥴러에 의해, 각각의 참여자의 상태가 확인된다. 참여자가 오프라인에 있는 경우, 그 사용자에게 연락을 시도한다. 참여자가 온라인에 있으나 다른 대화에 참여하고 있으면, MCMS 애플리케이션(20)은 참여자에게 알린다. 모든 온라인 상 참여자의 존재 상태는 데이터베이스(22)에 업데이트된다.

통지 수신(1108b) - 시스템은 사용자의 주의가 사용자 인터페이스(110)를 통해 그래픽 디스플레이 및/또는 들을 수 있는 통지로 대화 상에 요청되었음을 사용자에게 통지할 수 있다.

대화 상태(1108c) - 사용자는 그들의 장치(13)의 인터페이스(110)를 통해 대화의 상태를 요청할 수 있다. 이에 응답하여, MCMS 애플리케이션(20)은 데이터베이스(22)에 저장된 상태 정보를 조합하고 사용자에게 그 정보를 제공한다.

대화 정지(1108d) - 사용자 인터페이스(110)를 통해, 사용자는 활성화된 대화를 끊거나 그로부터 전환될 수 있다. 이에 응답하여, MCMS 애플리케이션(20)은 활성화된 대화에 대한 사용자의 참여자 상태를 데이터베이스(22)에 업데이트하고, 대화로부터 사용자를 제거하도록 저장 및 스트림 모듈(24)에 지시한다.

K.5 대화 제어( Conversation Controls )

도 11e에 도시된 바와 같이, 대화 제어(1110)은 사용자가 대화 내 그들의 참여를 제어하도록 하는 기능의 세트이다. 이러한 기능은 사용자가 라이브로 따라잡기(CTL), 헤드로 스킵하기, 지난 위치까지 점프하기, 일시정지, 대화의 메시지를 검토할 때 빠른 재생 및 느린 재생을 가능하게 한다. 이러한 기능 각각은 장치(13)의 인터페이스(110)를 통해 사용자에 의해 시작된다.

라이브로 따라잡기(Catch-up-to-live)(1110a) - 사용자는 "CTL" 기능을 사용하여 진행 중인 대화에서 라이브까지 따라잡을 수 있다. 이 기능이 가동되면, MCMS 애플리케이션(20)은 사용자가 검토하였던 대화의 마지막 지점을 확인하고, 이전에 듣지 않은 메시지를 렌더링하도록 저장 및 스트림 모듈(24)을 지시하며, 이는 사용자에 의해 지정된 일반적인 렌더링 옵션보다 더 빠른 렌더링을 사용하고, 헤드에 도달하면 끊김없이 라이브 모드로 전환하도록 한다.

헤드로 점프하기(1110c) - 이 기능은 사용자가 대화의 헤드로 점프하도록 하며, 이는 대화 내 사용자의 현재 지점과 헤드 사이에 임의의 개입되는 메시지를 스킵한다. 이 기능이 구현되면, MCMS 애플리케이션(20)은 대화의 헤드에 있는 메시지를 즉시 렌더링하도록 저장 및 스트림 모듈을 지시한다. (대화의 헤드가 현재 라이브이면 이는 JTL(Jump To Live)로 언급된다.)

지난 위치로 점프(1110d) - 이 기능은 사용자가 대화 내 이전 메시지 또는 이전 지점으로 점프하도록 하며, 되감기 또는 재생(replay) 기능과 유사하다. 이 기능이 구현되면, MCMS 애플리케이션(20)은 되감기 지점부터 시작하는 미디어를 렌더링하도록 저장 및 스트림 모듈(24)을 지시한다.

일시정지(1110e) - 이 기능은 사용자가 대화의 메시지의 검토를 일시정지하도록 한다. 이에 응답하여, 저장 및 스트림 모듈(24)은 또 다른 명령이 발급될 때까지 메시지의 렌더링을 정지한다.

빠른 재생(1110f) - 이 기능은 사용자가 메시지를 보다 빨리 렌더링하도록 한다. 이에 응답하여, 저장 및 스트림 모듈(24)은 메시지를 정상보다 더 빠른 비율로 렌더링한다. 렌더링 비율은 사용자에 의해 특정되거나 사용자가 많은 기설정된 옵션으로부터 선택할 수 있다.

느린 재생(1110g) - 이 기능은 사용자가 메시지를 보다 느리게 렌더링하도록 한다. 이에 응답하여, 저장 및 스트림 모듈(24)은 메시지를 정상보다 더 느린 비율로 렌더링한다. 렌더링 비율은 사용자에 의해 특정되거나 사용자가 많은 기설정된 옵션으로부터 선택할 수 있다.

K.6 연락처 관리( Contact Management )

도 11f에 도시된 바와 같이, 시스템(10)은 연락처 리스트 및 사용자 그룹을 관리하기 위해 호스트의 기능을 사용자에게 제공한다. 이러한 기능은 연락처 및 사용자 그룹의 추가, 편집, 삭제를 포함한다. 이러한 기능 각각은 그들의 장치(13)의 인터페이스를 통해 사용자에 의해 구현된다. 사용자의 연락처 리스트 또는 그룹 리스트에서의 임의의 수정 또는 삭제는 MCMS 데이터베이스(22)에 저장된다.

연락처 추가(1112a) - 이 기능은 사용자가 새로운 연락처를 그들의 연락처 리스트에 추가할 수 있도록 한다. 새로운 연락처는 등록된 사용자 또는 외부 연락처일 수 있다. 일반적으로 이름, 전화 번호(들), 임의의 타입의 번호(휴대폰, 사무실, 가정, 컴퓨터 등), 이메일 주소 및 다른 개인적인 정보가 각각의 연락처 기록에 제공된다.

연락처 편집(1112b) - 이 기능은 사용자가 기존의 연락처 기록을 편집하거나 업데이트할 수 있도록 한다.

연락처 삭제(1112c) - 이 기능은 사용자가 기존의 연락처 기록을 제거하거나 삭제할 수 있도록 한다.

연락처 검색(1112d) - 이 기능은 사용자가 그들의 연락처 리스트에서 특정 연락처를 검색할 수 있도록 한다. 검색은 많은 기준, 예컨대 이름, 전화 번호, 최근 발신 번호, 가장 자주 발신한 번호, 그룹 등을 사용하여 수행될 수 있다.

참여자 리스트 획득(1112e) - 이 기능은 사용자가 많은 상이한 검색 기준을 사용하여 대화의 참여자의 리스트를 검색하고 독출할 수 있도록 하며, 상기 검색 기준은 이름, 최근 발신 번호, 최근 착신 번호, 가장 자주 발신한 번호 등이다.

발신자의 상태 검토 인증(1112f) - 이 기능은 다른 사용자가 제 1 사용자의 상태를 보는 것을 제 1 사용자가 인증할 수 있도록 한다. 인증되지 않은 사용자는 제 1 사용자의 상태를 볼 수 없다.

연락처의 그룹 생성(1112g) - 이 기능은 사용자가 많은 연락처를 그룹으로 결합시킬 수 있도록 한다. 사용자가 그룹을 정의하는 경우, 그 그룹 내 연락처의 리스트는 MCMS 데이터베이스(22)에 저장된다.

연락처 그룹 편집(1112h) - 이 기능은 사용자가 그룹을 편집하거나, 그룹의 멤버에 대한 연락처 정보를 업데이트할 수 있도록 한다.

연락처 그룹 삭제(1112i) - 이 기능은 사용자가 그룹을 삭제할 수 있도록 한다.

L. MCMS 동작( MCMS Operation )

L.1 MCMS -C

상술한 바와 같이, MCMS-C 동작은 MCMS와 유사하며, 사용자가 우선순위의 계층화된 시스템 및 메시지의 타임-쉬프팅을 통해 연속적으로 다수의 대화를 관리하고 이에 참여할 수 있도록 하는 특징이 추가되며, 이는 시스템에 의해 자동으로 관리된다. MCMS-C 기능성의 구현은 세 가지 기본적인 프로세스를 포함한다. 도 12a에 도시된 바와 같이, 첫 번째 프로세스는 연속적인 렌더링을 위한 대화의 세트를 정의하는 단계를 포함한다. 리스트가 정의되면, 우선순위의 계층화된 세트 및 다른 팩터가 대화의 세트와 결합된 인덱스된 미디어 페이로드에 적용된다. 그리고 나서, 인덱스된 미디어 페이로드는 시퀀스 순서대로 순서화된다. 미디어를 시퀀스 순서대로 렌더링함으로써, 대화의 세트의 메시지는 연속적으로 렌더링된다.

도 12a를 참조하여, 연속적으로 렌더링할 대화의 리스트를 정의하는 단계를 설명하는 흐름도가 도시된다. 개시 단계(1202)에서, 사용자의 집합적인 대화의 리스트가 정의된다. 사용자 또는 기구성 데이터 중 어느 하나가 다음으로 사용되어 연속적인 렌더링(단계(1206))을 위한 집합적인 리스트 중 대화를 선택한다(단계(1204)). 예를 들어, 전술적인 통신 시스템에서, 일반적으로 기-구성 데이터는 연속적으로 렌더링될 대화를 부과하도록 사용된다. 비-전술적 애플리케이션에서, 사용자는 일반적으로 연속적인 렌더링을 위한 대화를 선택하기 위해 보다 높은 정도의 유연성이 주어진다.

도 12b를 참조하여, 연속적인 대화의 메시지를 렌더링하기 위한 계층적인 우선순위의 세트를 정의하는 단계를 설명하는 흐름도가 도시된다. 개시 단계(단계(1208))에서, 우선순위 룰의 세트가 정의되고 연속적으로 렌더링될 대화의 리스트에 적용된다(단계(1206)). 다양한 실시예에서, 우선순위 룰의 세트는 엄격하고, 계층적인 통신 프로토콜에서 매우 유연한 통신 프로토콜에 이를 수 있다. 예를 들어, 엄격한 계층화가 자주 요구되는 전술적인 통신 시스템에서, 우선순위 룰의 세트는 바람직하게 동시 발생하는 메시지가 렌더링되는 특정 순서를 부과할 것이다. 예를 들어, 전술적 시스템에서 최초 대처자에 대해, 소방대장으로부터의 메시지는 가장 높은 우선순위가 주어질 수 있다. 우선순위의 다음 레벨은 화재 빌딩 내부에 있는 소방관에게 주어질 수 있다. 다음 레벨에서, 우선순위는 빌딩 밖에 있는 소방관에게 주어질 수 있다. 엄격한 우선순위를 정의함으로써, 화재를 진압하는 행위를 감독하는 현재의 메시지, 또는 위험한 경로는 보다 덜 중요한 역할을 수행하는 메시지보다 앞서서 렌더링된다. 비-전술적인 통신에서, 사용자는 개인적인 요구를 만족시키기 위해 그들 자신의 우선순위 구성을 정의하도록 큰 유연성이 주어질 수 있다. 예를 들어, 판매 중역은 클라이언트와의 연속적인 대화를 열거한 우선순위 구성을 가장 중요한 것부터 가장 중요하지 않은 것까지 정의할 수 있다. 또는 사용자는 가족 및 친구로부터의 연속적인 메시지를 우선순위화 할 수 있다. 사용된 구성에 관계없이, 연속적인 대화에 대한 우선순위 리스트가 이러한 프로세스로 정의된다(단계(1210)).

도 12c를 참조하여, 다양한 연속적인 대화로부터 수신된 메시지의 큐 구성을 설명하는 흐름도가 도시된다. 개시 단계에서, 메시지의 렌더링되지 않은 인덱스된 미디어 페이로드의 가용성이 연속적으로 렌더링될 각각의 대화에 대해 연속적으로 검출된다. 우선순위 계층화가 사용가능한 인덱스된 미디어 페이로드 스트림에 적용된다(단계(1214)). 우선순위 계층화의 적어도 일부를 기반으로, 그리고 이하 언급되는 바와 같은 다른 가능한 파라미터를 기반으로, 사용가능한 인덱스된 미디어 페이로드가 시퀀스 순서로 배열된다(단계(1216)). 그리고 나서, 인덱스된 미디어 페이로드는 시퀀스 오더로 연속적으로 렌더링된다(단계(1218)). 상술한 프로세스를 연속적으로 반복함으로써, 다수의 대화의 메시지가 연속적으로 렌더링된다.

일 실시예에서, 시퀀스 순서는 우선순위 계층화의 일부 또는 전부를 기반으로 한다. 대체적인 실시예에서, 계층 및 가용성에 더하여 다른 파라미터가 더 고려될 수 있다. 예를 들어, 시퀀스 순서는 하나 또는 그 이상의 파라미터, 예컨대 인덱스된 미디어 페이로드의 현재 렌더링된 스트림을 중단하고 보다 높은 우선순위 대화의 인덱스된 미디어 페이로드로 전환하는 전환 비용, 인덱스된 미디어 페이로드의 사용가능한 스트림의 품질, 인덱스된 미디어 페이로드가 수신된 상대적인 시간, 셔플링(shuffling) 순서, 또는 시스템의 컨트롤러의 입력을 사용하여 정의될 수 있다.

일반적으로 다른 대화의 메시지들 간의 충돌이 발생한 경우, 시퀀스 순서에서 가장 빠른 순서의 인덱스된 미디어 페이로드가 렌더링되는 반면 다른 사용가능한 인덱스된 미디어 페이로드의 렌더링은 정지되거나 지연된다. 충돌이 없는 경우, 인덱스된 미디어 페이로드는 그들이 사용가능해짐에 따라 즉시 렌더링된다.

다른 실시예에서, 연속적으로 렌더링되는 대화의 메시지는 타임-쉬프트 모드에서 선택적으로 검토될 수 있다. 첫 번째 통신 장치의 사용자가 연속적으로 렌더링된 대화와 결합된 임의의 미디어를 생성하면, 그 미디어는 인덱스되고 네트워크 상의 서버(16)의 PIMB(들)(85) 뿐만 아니라 장치의 PIMB(30)에도 저장된다. 따라서, 대화가 타임 쉬프트 모드에서 검토되면, 사용자는 단지 대화와 결합된 유입되는 메시지를 검토하는 옵션을 가지거나, 또는 타임 인덱스 순서대로 대화와 결합된 첫 번째 사용자에 의해 생성된 미디어 뿐만 아니라 유입되는 메시지 둘 모두를 검토하는 옵션을 가진다.

L.2 MCMS -S 동작( MCMS -S Operation )

MCMS-S 또는 동시적인 모드에서, 클라이언트(12)가 이네이블된 장치(13)의 사용자는 동시적인 렌더링을 위한 대화의 세트를 정의할 수 있다. 대화의 세트가 정의되면, 대화의 세트와 연관된 인덱스된 미디어 페이로드 스트림은 동시적으로 장치(13)에 렌더링되며, 이는 이들이 중첩되는지 여부에 관계없이 진행된다. 대체적인 실시예에서, 사용자는 선택적으로 미디어 스트림의 세트로부터 수신된 인덱스된 미디어 페이로드를 개별적으로 렌더링할 수 있다. 동시적인 대화의 인덱스된 미디어 페이로드는 또한 거의 실시간으로 또는 타임-쉬프트 모드로 선택적으로 렌더링될 수도 있다.

L.3 MCMS , MCMS -C 및 MCMS -S의 예

도 13a 내지 도 13d에서, 대화의 속성 및 MCMS, MCMS-C 및 MCMS-S의 동작을 설명하는 일련의 도면이 도시된다.

도 13a에서, 사용자 "X" 및 "Y"와 "Z"로 지시된 두 명의 다른 사용자 간에 "A"로 라벨된 대화의 메시지의 인덱스된 미디어 페이로드의 렌더링 순서를 설명하는 시간 흐름도가 도시된다. 이 예에서, 미디어는 t1, t5, t6, t7 및 t9에 의해 지시된 타임 인터벌 동안 사용자 Y에 의해 생성된다. 미디어는 t3, t6 및 t9 내지 t10으로 지시된 타임 인터벌 동안 사용자 Z에 의해 생성된다.

사용자 X의 장치(13)에서 렌더링 시퀀스는 도면의 하단에 도시된다. 인터벌 t1, t5 및 t7 동안, 오직 Y로부터 도출된 미디어가 렌더링된다. 인터벌 t3 및 t10동안, 오직 Z로부터 도출된 미디어만이 렌더링된다. 인터벌 t6 및 t9에서, Y 및 Z 둘 모두로부터의 미디어가 렌더링된다. 인터벌 t2, t4 및 t8에서는, 사용자 Y 또는 Z 어느도 이 기간동안 미디어를 생성하지 않기 때문에 아무 것도 렌더링되지 않는다. 인터벌 t1 내지 t10은 고정된 타임 인터벌을 의미하지 않으며, 단지 미디어가 생성되고 있는 시간 간격을 의미하도록 의도된다.

도 13a의 도면은 대화의 속성을 설명하는데 유용하다. 한 사용자(Y 또는 Z 중 어느 하나)가 미디어를 생성하는 경우, 그 미디어는 X의 장치(13)에서 수신되고 렌더링을 위해 사용가능해진다. 사용자 X 및 Y 둘 모두가 미디어를 생성하는 경우, 둘 모두의 미디어 스트림은 X의 장치(13)에서 수신되고 믹싱을 위해 사용가능해진다. 사용자 X 또는 Y 어느 누구도 미디어를 생성하지 않는 경우, 어떠한 미디어도 X의 장치(13)에 수신되지 않는다. 상술한 바와 같이, 사용자 X는 대화 A 도중 생성된 미디어를 거의 실시간으로 또는 타임-쉬프트 모드 중 어느 하나로 검토하는 옵션을 가진다. 또한, 사용자 X는 도시된 바와 같이 믹스된 형태로 미디어를 검토하는 옵션을 가지거나, 또는 타임-쉬프트 모드에서 Y 및 Z로부터의 미디어를 개별적으로 검토하는 옵션을 가진다.

도 13b는 MCMS의 동작을 설명한다. 이 예에서, 사용자는 세 개의 대화에 참여하고 있으며, 이는 A, B 및 C로 지정된다. 대화 A, B, 및 C에 대해, 사용자는 각각 (A1, A2, A3 및 A4), (B1, B2 및 B3) 및 (C1 및 C2)로 지시된 메시지를 생성하거나 수신한다. 각각의 메시지의 타이밍 및 지속시간은 타임-라인을 따라 시작 지점에 의해 지시된다. 이 예에서, 메시지 B2를 제외한 모든 메시지가 일정한 정도로 시간에서 중첩되는 것을 주목하는 것은 유용하다.

MCMS 애플리케이션에서, 사용자는 현재로서 한 대화를 선택한다. 선택된 대화에서, 사용자는 유입되는 메시지를 검토하고 대화의 다른 참여자로 전송되는 메시지를 생성할 수 있다. 이러한 예에서, 사용자는 현재로서 각각 대화 B, C 및 A의 순서로 선택한다. 따라서, 메시지 시퀀스는 처음으로 B1, B2 및 B3이며, C1 및 C2가 뒤따르고, 그리고 나서 마지막으로 A1부터 A4가 뒤따른다. 또 다시, 특정 대화가 현재로서 선택되며, 사용자는 거의 실시간 모드에서 타임-쉬프트 모드 간에 전환할 수 있고 그 역으로 전환할 수 있다. 도면에 도시된 바와 같이 마지막 렌더링은 도면의 상부에 도시된 바와 같은 수신된 메시지의 타이밍에 일치하도록 의도되지 않는다. 도면의 하부는 메시지의 렌더링 순서만을 도시하도록 의도되며, 이는 사용자에 의해 선택된 대화 순서를 기반으로 한다.

따라서, 도 13b의 예는 MCMS 애플리케이션의 속성을 설명하기에 유용하다. 사용자는 현재로서 하나의 대화를 선택한다. 다른 대화는 일시정지된다. 사용자는 또한 임의의 시간에 현재의 대화를 모든 대화 중에서 전환할 수 있다.

도 13c를 참조하여, MCMS-C의 동작을 설명하는 도면이 설명된다. 이 실시예에서, 사용자는 두 개의 연속적인 대화, A 및 B에 참여하고 있다. 대화 A에서, 세 개의 메시지 A1, A2 및 A3가 수신된다. 대화 B에서, 세 개의 메시지 B1, B2 및 B3가 수신된다. 이 예에서, 메시지 B1은 메시지 A1과 충돌하는 것을 주목하는 것이 유용하다. 또한 대화 A는 대화 B보다 더 높은 우선순위를 가진다.

두 대화의 연속적인 렌더링 도중, 보다 높은 우선순위의 메시지 A1 및 A2는 우선 거의 실시간으로 렌더링되며, 이는 도면의 수직적인 점선에 의해 나타나는 바와 같다. 메시지 A2와 A3 간에 상대적으로 큰 시간 간격이 있으므로, 이 공간은 타임 쉬프팅 및 메시지 B1 및 B2의 렌더링에 의해 채워진다. A3가 도달하면, 이는 거의 실시간으로 렌더링되는 반면, 메시지 B3는 오직 보다 높은 우선순위 메시지 A3가 렌더링된 후에 렌더링된다. 높은 우선순위 메시지들 사이에 낮은 우선순위 메시지의 타임-쉬프팅 렌더링을 수행함으로써, 연속적인 다수의 대화가 관리될 수 있다. 이러한 단순한 예에서, 우선순위는 렌더링에 대한 연속적인 순서를 결정하기 위해 사용되는 유일한 파라미터이다. 상술한 바와 같이, 많은 다른 파라미터가 사용될 수도 있다.

도 13d를 참조하여, MCMS-S를 설명하는 도면이 도시된다. 이 예에서, 사용자는 세 개의 동시적인 대화, A, B 및 C에 참여된다. 메시지 A1, A2 및 A3, B1, B2 및 B3, 및 C1 및 C2는 각각의 대화 A, B 및 C에 대해 각각 수신되는 것이 도시된다. MCMS-S에서, 유입되는 메시지는 그들이 수신됨에 따라 착신자 장치(13)에서 렌더링된다. 따라서, 도면의 하부에 도시된 바와 같이, 세 개의 대화 A, B 및 C의 메시지의 렌더링 시퀀스는 메시지가 수신된 바와 동일하다. 이러한 방식으로, 다수의 대화는 동시적으로 렌더링될 수 있다.

전술한 예에서, MCMS 애플리케이션의 다수의 변화가 기술되며, 이는 MCMS-C 및 MCMS-S를 포함한다. 사용되는 특정 타입의 MCMS 애플리케이션에 관계없이, 이들 모두는 다수의 공통된 특징을 공유한다. 각각의 경우에서, 대화는 메시지의 스레딩된 시퀀스 또는 조합에 의해 정의된다. 메시지는 미디어의 스트림으로 분할되며, 각각의 메시지는 시퀀스 식별자가 주어지고 미디어가 생성된 시간에 의해 인덱스된다. MCMS 애플리케이션의 변화에 종속하여, 메시지는 하나 또는 그 이상의 렌더링 옵션에 따라 렌더링될 수 있다. 어느 한 형태 또는 다른 형태에서, 렌더링 옵션은 메시지의 필터링, 그룹화, 중첩화 및/또는 일련화(serialization)를 포함하며, 이는 영부터 다수의 상이한 속성에 이르는 것을 사용한다. 이러한 방식으로, 각각이 메시지의 스트링을 포함하는 다수의 대화는 단일의 클라이언트(12)가 이네이블된 장치(13)에서 수행될 수 있다. 마지막으로, MCMS의 각각의 변화는 동일한 방식으로 중단된 메시지의 수신을 조절할 수 있다. 중단된 메시지가 수신되면, 이는 일반적으로 다른 대화에 속하는 다른 메시지에 우선하고 그 전에 렌더링된다.

M. 클라이언트 및 서버 하드웨어( Client and Server Hardware )

도 14a를 참조하여, 클라이언트 애플리케이션(12)를 저장하고 실행하기 위해 사용되는 장치(13)의 하드웨어를 설명하는 블록도(140)가 도시된다. 하드웨어는 CPU(142), 메인 메모리(144) 및 매스 스토리지(146)를 포함한다. 잘 알려진 바와 같이, 클라이언트 애플리케이션(12)은 메인 메모리(144) 및 매스 스토리지(146)에 독출되고 저장되며, CPU(142)에 의해 실행된다.

도 14b를 참조하여, 서버 애플리케이션(78)을 저장하고 실행하기 위해 사용되는 서버(16)의 하드웨어를 설명하는 블록도(150)이 도시된다. 하드웨어는 CPU(152), 메인 메모리(154), 매스 스토리지(156), 및 아카이브(archive)(89)를 포함한다. 잘 알려진 바와 같이, 서버 애플리케이션(78)은 메인 메모리(154) 및 매스 스토리지(156)에 독출되고 저장되며, CPU(152)에 의해 실행된다. 상술한 바와 같이, 하나 또는 그 이상의 사용자의 인덱스된 미디어 페이로드는 아카이브(89)에 저장된다.

비록 많은 컴포넌트 및 프로세스들이 편의를 위해 단독으로 전술되었지만, 당업자는 의해 다수의 컴포넌트 및 반복된 프로세스들이 또한 여기에 기술된 시스템 및 방법의 기술을 구현하도록 사용될 수도 있음을 파악할 것이다. 또한, 본 발명이 그 특정 실시예를 참조로 특별히 도시되고 기술되지만, 당업자는 개시된 실시예의 형태 및 세부사항의 변화가 본 발명의 사상 또는 범위로부터 분리되지 않으면서 가해질 수 있음을 파악할 것이다. 예를 들어, 본 발명의 실시예들은 다양한 컴포넌트와 함께 적용될 수 있으며 전술된 바에 제한되지 않아야 한다. 따라서, 본 발명은 본 발명의 진실한 사상 및 범위 내에 들어오는 모든 변화 및 균등물을 포함하도록 해석되도록 의도된다.