KR101455405B1 - 컨텐츠를 목표 주소로 전송하는 방법, 컨텐츠를 목표주소로 전송하는 시스템, 기본 사용자 인터페이스프리젠테이션을 적어도 하나의 컨텐츠-전달 아이콘으로채우는 방법 및 컴퓨터 판독가능 매체 - Google Patents

Abstract

제1 장치(102)를 사용하여 액세스된 컨텐츠를 제2 장치(104)로 전달하는 전략이 기술되어 있다. 예를 들어, 제1 장치(102)는 퍼스널 컴퓨터를 포함할 수 있고, 제2 장치(104)는 모바일 전화를 포함할 수 있다. 이 전략은 범용 CF(content-forwarding, 컨텐츠 전달) 기능을 이용한다. 서로 다른 컨텐츠 제공자가, 각각의 애플리케이션에 대해 시간이 많이 걸리고 번거로운 CF 기능의 수동 변경을 필요로 하지 않고, 컨텐츠를 제2 장치(104)로 전달하기 위해 동일한 범용 CF 기능에 의존할 수 있다.

컨텐츠 전달(CF), 기본 사용자 인터페이스 애플리케이션(BUIA), 기본 사용자 인터페이스 프리젠테이션, CF 아이콘

Description

컨텐츠를 목표 주소로 전송하는 방법, 컨텐츠를 목표 주소로 전송하는 시스템, 기본 사용자 인터페이스 프리젠테이션을 적어도 하나의 컨텐츠-전달 아이콘으로 채우는 방법 및 컴퓨터 판독가능 매체{STRATEGIES FOR SENDING CONTENT TO A TARGET DEVICE}

어떤 상황에서, 사용자는 제1 장치를 사용하여 컨텐츠에 액세스하고 이어서 그 컨텐츠를 제2 장치로 전송하고자 할 수 있다. 예를 들어, 사용자가 저녁을 먹기 위해 레스토랑을 방문하고자 계획하고 있는 것으로 가정한다. 사용자는 사무실에 있는 그의 퍼스널 컴퓨터를 사용하여 지도-관련 웹 사이트에 액세스할지도 모른다. 그 사이트로부터, 사용자는 레스토랑까지 찾아가는 길(directions)에 액세스할 수 있다. 사용자는 이어서 이 찾아가는 길을 그의 모바일 전화로 전송하고자 할 수 있다. 이렇게 함으로서 사용자는 레스토랑까지 운전하면서 이 찾아가는 길에 액세스할 수 있다.

전달 메카니즘(forwarding mechanism)을 구현함으로써 상기한 필요성을 해결하는 몇몇 애플리케이션이 개발되었다. 전달 메카니즘은 PC-액세스된 컨텐츠를 모바일 전화로 전송하도록 구성되어 있다. 그렇지만, 이러한 종류의 전달 메카니즘은 애플리케이션에 통합되어, 애플리케이션의 코드의 일부를 형성한다. 이러한 방법은 있을 수 있는 확장성(extensibility) 문제를 겪을 수 있다. 즉, 설계자가 제 1 애플리케이션에서 동작하는 전달 메카니즘을 개발하였으며 그 후에 유사한 메카니즘을 제2 애플리케이션에 적용하고자 하는 것으로 가정한다. 이렇게 하려면 사용자가 이 전달 메카니즘을 구현하기 위해 아마도 시간이 오래 걸리는 제2 애플리케이션의 코드를 수정하는 작업을 수행해야만 할지도 모른다. 게다가, 각각의 애플리케이션은 고유의 특성을 갖는다. 그에 따라, 전달 메카니즘을 새로운 애플리케이션에 추가하는 것은, 제2 애플리케이션과 적절히 통합될 수 있도록, 아마도 시간이 오래 걸리는 전달 메카니즘 자체를 커스텀-수정하는 작업을 수반할 가능성이 있다.

따라서, 당업계에서 컨텐츠를 제1 장치에서 제2 장치로 전달하기 위한 보다 효율적인 전략이 필요하다.

제1 장치를 사용하여 액세스된 컨텐츠를 제2 장치로 전달하기 위한 전략이 기술되어 있다. 예를 들어, 비록 전략이 특정의 종류의 장치들에 한정되지 않지만, 제1 장치는 퍼스널 컴퓨터를 포함할 수 있고, 제2 장치는 모바일 전화를 포함할 수 있다. 이 전략은 범용 CF(content-forwarding, 컨텐츠 전달) 기능을 이용한다. 서로 다른 컨텐츠 제공자가, 각각의 애플리케이션에 대해 시간이 많이 걸리고 번거로운 CF 기능의 수동 변경을 필요로 하지 않고, 컨텐츠를 제2 장치로 전달하기 위해 동일한 범용 CF 기능에 의존할 수 있다.

이 요약 부분에 기술된 내용은 본 발명에 대한 예시적인 설명을 말하는 것이며, 따라서 청구 범위에 설정된 본 발명의 범위를 제한하지 않는다.

도 1은 CF(content-forwarding) 기능을 사용하여 제1 장치로부터 제2 장치로 컨텐츠를 전달하는 시스템의 개요를 나타낸 도면.

도 2는 도 1의 시스템에서 사용될 수 있는 인터페이스 제공자의 예시적인 아키텍처를 부분적으로 나타낸 도면.

도 3은 도 1의 시스템에서 사용될 수 있는 RPF(request processing functionality, 요청 처리 기능)의 예시적인 아키텍처를 나타낸 도면.

도 4는 도 1의 시스템에서 사용될 수 있는 사용자 장치의 예시적인 아키텍처를 나타낸 도면.

도 5, 도 6a, 도 6b, 도 6c, 도 6d 및 도 6e는 도 1의 시스템에서 사용되는 제1 장치에 의해 제공되는 다양한 사용자 인터페이스 프리젠테이션을 나타낸 도면.

도 7은 도 1의 시스템에서 사용되는 제2 장치에 의해 제공되는 사용자 인터페이스 프리젠테이션을 나타낸 도면.

도 8-14는 도 1의 시스템의 다양한 측면들의 동작을 설명하는 다양한 절차를 나타낸 도면.

도 15는 도 1의 시스템의 측면들을 구현하는 예시적인 컴퓨터 환경을 나타낸 도면.

유사한 컴포넌트 및 특징을 참조하기 위해 명세서 및 도면 전체에 걸쳐 동일한 참조 번호가 사용된다. 100번대 번호는 도 1에서 처음으로 발견되는 특징들을 말하고, 200번대 번호는 도 2에서 처음으로 발견되는 특징들을 말하며, 300번대 번호는 도 3에서 처음으로 발견되는 특징들을 말하고, 이하 마찬가지이다.

본 명세서에 기술된 발명 내용은 목표 주소(target address)로 컨텐츠를 전송하기 위한 전략을 기술하고 있다. 예를 들어, 컨텐츠는 제1 장치를 사용하여 식별될 수 있고, 이어서 제2 장치("목표 장치(target device)"라고도 함)로 전달되며, 여기서 목표 장치는 목표 주소와 연관되어 있다. 이 전략은, 시간이 오래 걸리는 CF 기능의 수동 커스터마이즈(manual customization)를 필요로 하지 않고, 각종의 애플리케이션에 적용될 수 있는 유연한 CF(content-forwarding) 기능을 이용한다.

이 설명에서 가장 흔하게 등장하는 시나리오에서, 제1 장치는 퍼스널 컴퓨터(PC)에 대응하고, 제2 장치는 모바일 전화에 대응한다. 그렇지만, 이 시나리오는 단지 예시적이고 대표적인 것에 불과하다. 일반적으로, 제1 및 제2 장치는 퍼스널 컴퓨터, 랩톱 컴퓨터, PDA(personal digital assistant), 모바일 전화, 게임 콘솔, 셋톱 박스, 페이저형 장치(pager-type device), 웨어러블 컴퓨팅 장치(wearable computing device), 컴퓨터-장착된 가전 제품(computer-equipped appliance), 기타 등등(이에 한정되지 않음)을 비롯한 광범위한 부류의 전자 장치들 중에서 선택될 수 있다. 예를 들어, 다른 시나리오에서, 이 전략은 제1 퍼스널 컴퓨터를 사용하여 식별되는 컨텐츠를 제2 퍼스널 컴퓨터로 전송하는 데 사용될 수 있다. 다른 경우에, 이 전략은 소형(small scale) 전자 장치(모바일 전화, 기타 등등)를 사용하여 식별되는 컨텐츠를 실물-크기(full scale) 컴퓨팅 장치(퍼스널 컴퓨터, 기타 등등)로 전송하는 데 사용될 수 있다.

본 명세서는 이하의 섹션들을 포함하고 있다. 섹션 A는 컨텐츠를 목표 장치로 전달하는 예시적인 시스템을 제공한다. 섹션 B는 섹션 A의 시스템과 상호작용하는 데 사용될 수 있는 예시적인 사용자 인터페이스 프리젠테이션을 제공한다. 섹션 C는 섹션 A의 시스템의 다른 측면들의 동작을 설명하는 예시적인 절차를 기술한다. 그리고, 섹션 D는 섹션 A의 시스템의 측면들을 구현하는 예시적인 컴퓨터 환경을 기술한다.

A. 예시적인 시스템(도 1 내지 도 4)

일반적으로, 도면들을 참조하여 기술된 기능들 중 어느 것이라도 소프트웨어, 하드웨어(예를 들어, 고정 논리 회로(fixed logic circuitry)), 수동 처리(manual processing) 또는 이들 구현의 조합을 사용하여 구현될 수 있다. 용어 "논리", "모듈" 또는 "기능"은, 본 명세서에서 사용되는 바와 같이, 일반적으로 소프트웨어, 하드웨어, 또는 소프트웨어와 하드웨어의 조합을 나타낸다. 예를 들어, 소프트웨어 구현의 경우에, 용어 "논리", "모듈" 또는 "기능"은 처리 장치 또는 장치들(예를 들어, CPU 또는 CPU들) 상에서 실행될 때 지정된 작업을 수행하는 프로그램 코드(또는 선언적 내용(declarative content))를 나타낸다. 프로그램 코드는 하나 이상의 컴퓨터 판독가능 매체에 저장될 수 있다.

보다 일반적으로 말하면, 논리, 모듈 및 기능을 서로 다른 유닛으로 분리하여 나타낸 것은 이러한 소프트웨어 및/또는 하드웨어의 실제의 물리적 그룹화 및 할당을 반영할 수 있거나, 단일의 소프트웨어 프로그램 및/또는 하드웨어 유닛에 의해 수행되는 서로 다른 작업의 개념적 할당에 대응할 수 있다. 예시된 논리, 모듈 및 기능이 한 곳(예를 들어, 처리 장치에 의해 구현됨)에 위치될 수 있거나, 복수의 장소에 걸쳐 분산되어 있을 수 있다.

"기계 판독가능 매체" 또는 이와 유사한 용어들은 다양한 종류의 저장 장치(자기(magnetic), 광(optical), 고상(solid state), 기타)를 포함하는, 임의의 유형의 정보를 유지하기 위한 임의의 종류의 매체를 말한다. 용어 '기계 판독가능 매체'는 또한 한 지점에서 다른 지점으로 정보를 전송하는 다양한 유선 및/또는 무선 링크를 비롯하여, 정보를 표현하는 일시적 형태(transitory form)도 포함한다.

A.1. 시스템의 개요

도 1은 컨텐츠를 목표 장치로 전송하는 데 사용될 수 있는 한 예시적인 시스템(100)을 나타낸 것이다. 즉, 시스템(100)의 한가지 목적은 제1 장치(102)를 사용하여 컨텐츠를 식별하고 이어서 그 식별된 컨텐츠를 제2 장치(104)(목표 장치(target device)라고도 함)와 연관된 목표 주소(target address)로 전송하는 것이다. 본 설명의 가장 흔하게 등장하는 시나리오에서, 제1 장치(102)는 퍼스널 컴퓨터에 대응하고, 제2 장치(104)는 모바일 전화에 대응한다. 그렇지만, 상기한 바와 같이, 제1 및 제2 장치(102, 104)는 임의의 유형의 장치로서 구현될 수 있다. 가장 일반적으로 말하면, 제1 장치(102) 및 제2 장치(104)는 단지 제1 주소 및 제2 (목표) 주소로 각각 간주될 수 있다. 일반적으로, 제1 장치(102)는 제1 일련의 처리 및 프리젠테이션 특성들을 가질 수 있고, 제2 장치(104)는 제2 일련의 처리 및 프리젠테이션 특성들(제1 일련의 처리 및 프리젠테이션 특성들과 다름)를 가질 수 있다. 이렇게 하려면 시스템(100)이 제1 장치(102)를 사용하여 식별되는 컨텐츠를 제2 장치(104)에 의해 사용되는 처리 및/또는 프리젠테이션 특성들로 변환해야만 할지도 모른다. 물론, 시스템(100)이 실제로는 많은 수의 장치들(도시 생략)을 포함하고, 이들 중 어느 것이라도 컨텐츠의 소스를 포함할 수 있고 이들 중 어느 것이라도 이 컨텐츠의 수신자(목적지)를 포함할 수 있다는 것을 잘 알 것이다.

사용자는 여러가지 이유로 컨텐츠를 목표 장치(104)로 전송하고자 할지도 모른다. 이하는 예시적이고 비제한적인 사용 시나리오를 포함한다.

한 경우에, 사용자는 제1 장치(102)를 사용하여 컨텐츠를 식별하고, 이 컨텐츠를 나중에 아마도 다른 설정에서 제2 장치(104)를 사용하여 액세스하고자 할 수 있다. 예를 들어, 배경 기술 부분에서 언급한 시나리오에 따르면, 사용자는 퍼스널 컴퓨터를 사용하여 운전하여 찾아가는 길(driving directions) 또는 여행 정보(tourist information)에 액세스하고 이어서 이 정보를 사용자의 모바일 전화로 전송할 수 있다. 이렇게 함으로써 사용자는 여행을 하면서 그의 모바일 전화로 이 정보에 액세스할 수 있다.

보다 일반적인 경우에, 사용자는 임의의 종류의 검색 결과를 제2 장치(104)로 전송하기 위해 제1 장치(102)를 사용할 수 있다.

다른 경우에, 사용자는 이메일 내용(또는 IM 내용 등의 기타 메시지 내용)을 제2 장치(104)로 전송하기 위해 제1 장치(102)를 사용할 수 있다.

다른 경우에, 사용자는 이미지 컨텐츠를 제2 장치(104)로 전송하기 위해 제1 장치(102)를 사용할 수 있다. 한 응용에 따르면, 사용자는 수신된 이미지를 제2 장치(104)에 대한 "배경 화면(wallpaper)"(예를 들어, 배경 이미지(background image))으로 사용할 수 있다.

다른 경우에, 사용자는 오디오 컨텐츠를 제2 장치(104)로 전송하기 위해 제1 장치(102)를 사용할 수 있다. 한 응용에 따르면, 사용자는 수신된 오디오 컨텐츠를 모바일 전화의 벨소리(ring tone)로서 사용할 수 있다.

다른 경우에, 사용자는 구성 정보(configuration information)를 제2 장치(104)로 전송하기 위해 제1 장치(102)를 사용할 수 있다. 이 구성 정보는 사용자 인터페이스 프리젠테이션의 구성(composition) 및 레이아웃(layout)을 제어할 수 있다. 따라서, 사용자는 제1 장치(102)를 사용하여 생성된 사용자 인터페이스 프리젠테이션을 제2 장치(104)에 복제하기 위해 이 기법을 사용할 수 있다.

다른 경우에, 사용자는 연락처 정보를 제2 장치(104)로 전송하기 위해 제1 장치(102)를 사용할 수 있다. 연락처 정보는 전화 번호 및 주소의 리스트를 포함할 수 있다. 또는, 연락처 정보는 명함 정보, 기타 등등을 포함할 수 있다.

한가지 일반 원칙에 따르면, 한명의 사용자가 제1 장치 및 제2 장치 둘다를 소유하거나 이들과 다른 방식으로 연관되어 있을 수 있다. 예를 들어, 사용자가 컨텐츠를 그의 집에 있는 그의 퍼스널 컴퓨터로 전송하기 위해 그의 직장 퍼스널 컴퓨터를 사용할 수 있다.

대안의 일반 원칙에 따르면, 제1 사용자가 임의의 종류의 컨텐츠를 제2 사용자(제2 장치(104)와 연관되어 있음)에게 전송하기 위해 제1 장치(102)를 사용할 수 있다. 예를 들어, 이 시나리오에서, 사용자는 컨텐츠를 친구의 퍼스널 컴퓨 터로 전송할 수 있다.

또다른 사용 시나리오들이 가능하다. 일반적으로, "컨텐츠"는, 본 명세서에서 광의로 사용되는 바와 같이, 그래픽 컨텐츠, 이미지 컨텐츠, 텍스트 컨텐츠, 오디오 컨텐츠, 코드-전달 컨텐츠(code-bearing content), 마크업 언어 컨텐츠, 기타 등등 또는 이들의 임의의 조합을 말할 수 있다.

이하의 설명에서는 시스템(100)의 예시적인 구성의 개요에 대해 기술하는 반면, 나중의 섹션들은 시스템(100)의 선택된 컴포넌트들에 관한 더 많은 상세를 제공한다.

일반적으로, 시스템(100)이 컨텐츠를 목표 장치(104)로 전달할 수 있게 해주는 기능을 본 명세서에서 CF(content-forwarding) 기능이라고 한다. 이 기능은 BUIA(base user interface application, 기본 사용자 인터페이스 애플리케이션)(106), 인터페이스 제공자(interface provider)(108), 및 RPF(request processing functionality, 요청 처리 기능)(110)를 비롯한 도 1의 각종의 컴포넌트들 간에 분산되어 있다. 장치(102, 104)는 또한 선택적으로 CF 기능의 측면들을 구현할 수 있다.

광의로 말하면, CF 기능은 소위 프런트-엔드 기능(front-end functionality)(112) 및 백-엔드 기능(back-end functionality)(114)으로 분할될 수 있다. BUIA(106) 및 인터페이스 제공자(108)는 프런트-엔드 기능(112)과 연관되어 있는 반면, RPF(110)는 백-엔드 기능(114)과 연관되어 있다. 프런트-엔드 기능(112)을 "프런트-엔드"라고 하는 이유는 이 기능(112)이 사용자가 시스템(100)과 상호작용할 수 있는 인터페이스를 제공함으로써 사용자와 "직면"하고 있기 때문이다. 백-엔드 기능(114)은 주로 식별된 컨텐츠를 목표 장치(104)로 전송하는 것에 관련된 백그라운드 처리 동작(background processing operation)을 수행한다.

시스템(100)의 상기한 컴포넌트들(BUIA(106), 인터페이스 제공자(108) 및 RPF(110)) 각각에 대해 이하에서 차례로 설명한다. BUIA(base user interface application)(106)부터 시작하면, 이 기능은 임의의 종류의 애플리케이션 도메인(application domain)에서 임의의 종류의 동작을 수행하는 임의의 종류의 애플리케이션 논리, 도구, 기타 등등을 말한다. 한 경우에, 서버측 기능(server-side functionality)이 BUIA(106)를 구현할 수 있다. 다른 경우에, 장치(102)가 BUIA(106)를 로컬적으로 구현할 수 있다. 다른 경우에, 서버측 기능 및 장치(102) 둘다가 BUIA(106)를 분산된 방식으로 구현할 수 있다. 한 경우에, BUIA(106)는 CF 기능을 관리하는 개체와 사전 설정된 관계를 갖는다. 이 경우에, BUIA(106)는 CF 기능을 관리하는 개체와 정식으로 협조하는 "파트너" 개체이다. 다른 경우에, BUIA(106)는 임의적인 웹 사이트 등의 임의적인 컨텐츠 어느 것이라도 나타낼 수 있다. 이 경우에, BUIA(106)를 호스팅하는 개체가 CF 기능을 관리하는 개체와 사전 설정된 관계를 꼭 가질 필요는 없다.

어쨋든, BUIA(106)는 "기본 사용자 인터페이스 프리젠테이션(base user interface presentation)"을 제공한다. 기본 사용자 인터페이스 프리젠테이션은 사용자가 BUIA(106)와 상호작용할 수 있게 해주는 인터페이스를 포함한다. 기본 사용자 인터페이스 프리젠테이션은 차례로 본 명세서에서 "정보 아이 템(information item)"이라고 하는 다수의 컴포넌트를 포함한다. 전반적인 개요로서, CF 기능의 목적은 제1 장치(102)를 사용하여 식별된 정보 아이템을 목표 장치(104)로 전송하는 것이다.

일례는 이 용어의 사용을 명확하게 해준다. 한 경우에, BUIA(106)는 검색-관련 애플리케이션 등의 인터넷을 통해 액세스가능한 임의의 종류의 애플리케이션 논리(application logic)를 제공하는 웹 사이트를 포함한다. 애플리케이션 논리는 차례로 하나 이상의 사용자 인터페이스 페이지의 형태로 기본 사용자 인터페이스 프리젠테이션을 사용자에게 제공한다. 예를 들어, 한 사용자 인터페이스 페이지는 검색의 결과를 확인하는 검색 결과 페이지를 포함한다. 각각의 페이지는 하나 이상의 정보 아이템을 포함할 수 있다. 예를 들어, 검색 결과 페이지는 검색 결과의 리스트를 제공할 수 있으며, 각각의 검색 결과는 정보 아이템에 관한 것일 수 있다. 상기 예에서, 정보 아이템은 기본 사용자 인터페이스 프리젠테이션에 의해 시각적으로 제공되거나 적어도 시각적으로 참조되는 정보에 대응한다. 다른 경우에서, 선택가능한 정보 아이템은 기본 사용자 인터페이스 애플리케이션에의 시각적 대응 부분을 꼭 가질 필요는 없는 BUIA(106)의 다른 측면들에 대응할 수 있다.

시스템(100)은 CF(content-forwarding) 아이콘으로 기본 사용자 인터페이스 프리젠테이션에 주석을 첨부할 수 있다. 즉, 시스템(100)은 정보 아이템에 근접한 위치에 CF 아이콘을 추가함으로써 기본 사용자 인터페이스 프리젠테이션에 주석을 첨부할 수 있다. 소위 CF(content-forwarding) 사용자 인터페이스 프리젠테이션을 제공하기 위해 각각의 CF 아이콘이 호출될 수 있다. 환언하면, CF 사용자 인터페 이스 프리젠테이션은 연관된 CF 아이콘을 클릭함으로써 호출될 수 있는 팝업(pop-up)이다. CF 사용자 인터페이스 프리젠테이션은 사용자가 식별된 정보 아이템을 목표 장치(104)로 전달할 수 있게 해주는 수단으로서 기능한다.

이 방식으로 기능하기 위해, BUIA(106)는 도 1에서 BUIA CF 기능(116)이라고 하는 컨텐츠-전달 논리(예를 들어, 실행가능 코드)를 포함할 수 있다. BUIA CF 기능(116)은 기본 사용자 인터페이스 프리젠테이션이 CF 아이콘으로 주석 첨부되는 방식을 제어할 수 있다. 예를 들어, BUIA CF(116)는 CF 아이콘을 로드할 수 있고 CF 아이콘이 기본 사용자 인터페이스 프리젠테이션과 관련하여 어디에 배치되는지를 제어할 수 있다. BUIA CF(116)는 또한 선택적으로 CF 아이콘의 거동의 어떤 측면들을 제어할 수 있다. 예를 들어, BUIA CF(116)는 각각의 CF 아이콘의 사용자 활성화 시에 CF 사용자 인터페이스 프리젠테이션의 로딩을 조정할 수 있다. BUIA CF(116)는 JavaScript 코드 모듈 등의 어떤 기술이라도 사용하여 구현될 수 있다.

이제부터 인터페이스 제공자(108)를 참조하면, 이 컴포넌트는 CF 아이콘이 호출될 때 CF 사용자 인터페이스 프리젠테이션을 제공한다. 이 점에서, 인터페이스 제공자(108)는 많은 서로 다른 BUIA(106)에 CF 사용자 인터페이스 프리젠테이션을 제공하는 중심 서비스이다. BUIA가 서로 다른 특성을 갖기 때문에, 인터페이스 제공자(108)는 BUIA(106)의 고유의 특성에 적합하도록 그가 제공하는 CF 사용자 인터페이스 프리젠테이션을 커스터마이즈하도록 구성되어 있다. 보다 일반적으로 말하면, 사용자는 특정의 컨텍스트에서 CF 아이콘을 활성화시킨다. 인터페이스 제공자(108)는 이러한 독특한 컨텍스트에 적합하도록 그가 BUIA(106)에 제공하는 CF 사 용자 인터페이스 프리젠테이션을 조정한다.

이 컨텍스트는 다수의 성분 또는 인자를 가질 수 있다. 컨텍스트의 일부는 사용자가 CF 아이콘을 활성화시킬 때 상호작용하고 있던 BUIA(106)의 일반적 속성에 관한 것이다. 예를 들어, 사용자는, 말하자면, 사진 브라우징 BUIA와는 대비되는 검색-관련 BUIA와 상호작용하고 있을 수 있다. 컨텍스트의 다른 부분은 사용자가 상호작용하고 있는 BUIA(106)의 특정의 측면("시나리오"라고 함)에 관한 것이다. 예를 들어, 사용자는 검색-관련 BUIA(106)의 뉴스 모드와 상호작용하고 있을 수 있다. 따라서, 이 뉴스 모드는 검색-관련 BUIA(106)의 시나리오를 정의한다. 컨텍스트의 다른 부분은 사용자가 BUIA(106)에 액세스하고 있는 장소(및/또는 목표 장치(104)가 위치할 것으로 추정되는 장소)에 관한 것일 수 있다. 컨텍스트의 다른 부분은 BUIA(106)를 호스팅하는 개체의 식별자(identity)에 관한 것일 수 있다. 또다른 컨텍스트 인자들이 CF 아이콘의 사용자 활성화에 적용될 수 있다. 어쨋든, 인터페이스 제공자(108)는 컨텍스트 인자에 적합하도록 커스터마이즈되는 사용자 인터페이스 프리젠테이션을 제공함으로써 이들 컨텍스트 인자들 전부를 고려한다.

한 예시적인 구현에 따르면, 인터페이스 제공자(108)는 BUIA(106)로부터 하나 이상의 파라미터를 받음으로써 상기한 동작들을 구현할 수 있다. 이들 파라미터는 각각 서로 다른 컨텍스트 인자들을 포착한다. 인터페이스 제공자(108)는 이어서 수신된 파라미터에 적합하도록 조정된 CF 사용자 인터페이스 프리젠테이션을 제공한다. 인터페이스 제공자(108)의 커스터마이즈 기능은 JavaScript 코드 모듈 등의 어느 기술이라도 사용하여 구현될 수 있다.

더 상세히 말하면, 사용자가 CF 아이콘을 처음으로 클릭할 때, 인터페이스 제공자(108)는 초기 CF 사용자 인터페이스 프리젠테이션을 제공한다. 초기 CF 사용자 인터페이스 프리젠테이션은 적어도 사용자에게 목표 장치(104)와 연관된 목표 주소를 입력하도록 요구한다. 이 주소는 전화 번호, 이메일 주소, 또는 어떤 다른 종류의 주소로 표현될 수 있다. 초기 CF 사용자 인터페이스 프리젠테이션은 BUIA(106)에 의해 인터페이스 제공자(108)에 제공된 컨텍스트 파라미터에 적합하도록 커스터마이즈된다. 예를 들어, 초기 CF 사용자 인터페이스 프리젠테이션은 목표 장치(104)의 추정된 장소에 맞게 커스터마이즈된 방식으로 사용자에게 목표 주소를 제공하도록 요청할 수 있다.

인터페이스 제공자(108)에 의해 수집된 모든 정보는 "요청 정보"를 구성하는 패키지를 형성한다. 요청 정보는 일반적으로 목표 장치(104)로 전송될 식별된 컨텐츠를 포함하는 사용자의 요청을 표현한다. 모든 요청 정보를 수집할 시에, 인터페이스 제공자(108)는 그 요청 정보를 RPF(request processing functionality, 요청 처리 기능)(110)로 전달한다. 그 후에, 인터페이스 제공자(108)는 요청의 상태에 관하여 RPF(110)에 질의를 하는 역할을 수행한다. 인터페이스 제공자(108)는 또한 하나 이상의 후속 CF 사용자 인터페이스 프리젠테이션을 제공한다. 이들 후속 프리젠테이션은 사용자에게 요청의 상태를 알려준다.

이제부터 RPF(110)를 참조하면, 이 컴포넌트의 한가지 목적은 요청 정보에 기초하여 메시지를 작성(formulate)하고 그 메시지를 목표 장치(104)로 전달하는 것이다. 이 메시지는 식별된 컨텐츠를 포함하고 및/또는 사용자가 원하는 컨텐츠 에 액세스할 수 있게 해준다. 예를 들어, 원하는 컨텐츠가 단순히 사용자가 목표 장치(104)에 대한 배경 화면으로서 사용하고자 하는 JPEG 이미지인 경우, 그 메시지는 컨텐츠 자체, 즉 JPEG 이미지를 포함할 수 있다. 다른 경우에, 원하는 컨텐츠는 검색 결과에 관한 것일 수 있고, 메시지는 그 검색 결과에의 링크를 포함할 수 있다. 사용자는 목표 장치(104) 상에서 그 링크를 활성화시킴으로써 검색 결과에 액세스할 수 있다. RPF(110)는 식별된 컨텐츠를 목표 장치(104)에 제공함으로써 목표 장치(104)에서 사용자의 동작을 처리한다. 다른 경우에, 원하는 컨텐츠의 일부가 메시지를 사용하여 직접 전송될 수 있는 반면, 컨텐츠의 다른 부분은 메시지에서 식별된 하나 이상의 링크를 통해 식별될 수 있다. 요약하면, RPF(110)의 한가지 목적은 메시지를 목표 장치(104)로 전송하는 것이고, 다른 목적은 사용자가 목표 장치(104)를 사용하여 컨텐츠를 검색할 수 있도록 사용자와 선택적으로 상호작용하는 것이다.

인터페이스 제공자(108) 및 RPF(110)는 서로 다른 기술을 사용하여 구현될 수 있다. 예를 들어, 인터페이스 제공자(108)는 제1 서버 시스템을 나타낼 수 있고, RPF(110)는 다른 서버 시스템을 나타낼 수 있다. 또는 인터페이스 제공자(108) 및 RPF(110)는 동일한 서버 시스템에 의해 구현될 수 있다.

시스템(100)은 상기한 동작들을 수행하기 위해 하나 이상의 통신 메카니즘을 사용할 수 있다. 일반적으로, 임의의 통신 메카니즘은 원거리 통신망(예를 들어, 인터넷), 인트라넷, DSL(Digital Subscriber Line, 디지털 가입자 회선) 네트워크 기반구조, 포인트-투-포인트 연결 기반구조(point-to-point coupling infrastructure), 모바일 전화 통신 시스템, 기타 등등의 임의의 종류의 네트워크(또는 네트워크들의 조합)를 포함할 수 있다. 연결 메카니즘은 일반적으로 임의의 종류의 프로토콜 또는 프로토콜들의 조합을 사용하거나 필요로 할 수 있고, 다양한 유선 및/또는 무선 링크, 라우터, 게이트웨이, 네임 서버(name server), 기타 등등(도시 생략)에 의존할 수 있다.

도 1에 도시된 특정의 예시적인 경우에, 시스템(100)은 연결 메카니즘 A(118) 및 연결 메카니즘 B(120)를 사용한다. 연결 메카니즘 A(118)는 인터넷 등의 원거리 통신망(WAN)에 대응할 수 있다. 연결 메카니즘 B(120)는 모바일 전화 통신 시스템에 대응할 수 있다. 예를 들어, 한 시나리오에서, 사용자는 연결 메카니즘 A(118)(예를 들어, 인터넷)를 통해 BUIA(106)를 제공하는 웹 사이트에 액세스하여 그와 상호작용할 수 있다. 이러한 상호작용에 의해 생성된 컨텐츠-전달 메시지는 궁극적으로 연결 메카니즘 B(120)(예를 들어, 모바일 전화 통신 시스템)를 사용하여 전달될 수 있다. 비록 도시되어 있지는 않지만, 연결 메카니즘 A(118) 및 연결 메카니즘 B(120)는 이들 2개의 메카니즘(118, 120) 사이에서 임의의 방식으로 정보가 교환될 수 있도록 통합될 수 있다.

상기한 아키텍처 및 일반 프로토콜은 예시적인 것이고 제한적인 것이 아니다. 요약하면, 상기한 방법에서, CF 기능은 CF 아이콘을 사용하여 기본 사용자 인터페이스 프리젠테이션에서의 미리 정해진 정보 아이템에 주석을 첨부한다. 이들 CF 아이콘의 활성화는 CF 기능으로 하여금 각자의 CF 사용자 인터페이스 프리젠테이션을 디스플레이하게 하며, 이 프리젠테이션은 요청 정보를 수집하고 여러가지 상태 정보를 전달하는 데 사용되는 각자의 팝업 프리젠테이션(pop-up presentation)을 포함한다. 다른 예시적인 방법에서, CF 기능에 의해 사용자는 임의의 기본 사용자 인터페이스 프리젠테이션에서의 임의의 컨텐츠를, 기본 사용자 인터페이스 프리젠테이션 내의 개개의 아이템을 클릭하는 것, 마우스 장치를 사용하여 기본 사용자 인터페이스 프리젠테이션의 일부분에 표시를 하는 것, 기타 등등의 자유-형식으로 또 임의적인 방식으로 지정할 수 있다. 이러한 자유 형식으로 선택된 아이템이 반드시 CF 아이콘으로 사전-주석 첨부될 필요는 없다. 사용자가 이 방법을 사용하여 아이템을 선택하면, 상기한 방식으로 CF 사용자 인터페이스 프리젠테이션을 디스플레이하기 위해 CF 기능이 호출된다. 이 기법의 한 응용에 따르면, 사용자는 임의적인 웹 컨텐츠를 선택하고 이 컨텐츠를 목표 장치(104)로 전송할 수 있다. CF 기능은 이 웹 컨텐츠를 목표 장치(104)에 가장 적합한 형식 및/또는 목표 장치(104)로 컨텐츠를 전달하는 선택된 모드로 변환할 수 있다.

다른 가능한 변형은 CF 아이콘이 구현되는 방식에 관한 것이다. 상기한 방법을 요약하면, BUIA(106)는 CF 아이콘 자체를 렌더링하기 위해 로컬 BUIA CF 기능(116)에 의존할 수 있다. 보다 구체적으로는, 이 경우에, BUIA CF 기능(116)은 CF 아이콘을 기본 사용자 인터페이스 프리젠테이션에서 미리 정해진 장소에 디스플레이할 수 있고, 이어서 CF 아이콘이 활성화될 때 인터페이스 제공자(108)로부터 CF 사용자 인터페이스 프리젠테이션을 로드할 수 있다. 그렇지만, 이 방법의 가능한 변형에서, BUIA(106)은 인터페이스 제공자(108)로부터 CF 아이콘 및 CF 사용자 인터페이스 프리젠테이션 둘다를 풀링(pull)한다.

다른 가능한 변형은 CF 기능을 구현하는 호스팅 사이트(hosting site)(들)에 관한 것이다. 상기한 방법을 요약하면, CF 기능의 프런트-엔드 측면들은 BUIA(106)에 위치한 BUIA CF 기능(116)과 인터페이스 제공자(108)에 의해 제공되는 기능으로 분할된다. BUIA(106)는 파트너 웹 사이트 또는 로컬 애플리케이션 등의 다양한 종류의 애플리케이션을 나타낸다. 다른 예시적인 구현에서, 상기한 CF 기능의 측면들은 개개의 사용자 컴퓨터 상에서 실행 중인 전용의 CF 코드에 의해 구현될 수 있다. 예를 들어, 제1 장치(102)는 사용자가 제2 장치(104)로 전송되어야만 하는 정보 아이템을 식별할 수 있게 해주는 코드를 브라우저 도구모음(browser toolbar) 또는 다른 종류의 애플리케이션에 구현할 수 있다. 이 기능을 호출함으로써 제1 장치(102)는 상기한 방식으로 중앙 인터페이스 제공자(108)로부터 CF 사용자 인터페이스 프리젠테이션에 액세스할 수 있다. 대안의 구현에서, 각각의 컴퓨터는 또한 인터페이스 제공자(108)에 의해 수행되는 역할의 하나 이상의 측면들을 로컬적으로 구현할 수 있어, 원격 인터페이스 제공자(108)에 액세스할 필요성이 없게 되거나 적어질 수 있다. 예를 들어, 시스템(100)은 SOAP(Simple Object Access Protocol) 인터페이스(또는 기타 종류의 인터페이스)를 백-엔드(114)에 제공할 수 있으며, 따라서 프런트-엔드 기능(112) 전부를 오프로드할 수 있다.

상기한 아키텍처 및 프로토콜의 또다른 변형이 가능하다. 그렇지만, 설명을 용이하게 하기 위해, 이하의 설명에서는 첫번째로 언급한 아키텍처 및 프로토콜에 중점을 둔다.

A.2. 예시적인 인터페이스 제공자

도 2를 참조하면, 동 도면은 인터페이스 제공자(108)는 물론 기타 특징들의 부가적인 상세를 보여준다.

인터페이스 제공자(108)는 UI 발생기 모듈(UI generator module)(202), 목표로 전송 요청 모듈(send-to-target request module)(204) 및 상태 문의 모듈(status inquiry module)(206)을 비롯한, 다수의 컴포넌트를 포함한다.

UI 발생기 모듈(202)의 한가지 목적은 CF 사용자 인터페이스 프리젠테이션을 발생하는 것이다. CF 사용자 인터페이스 프리젠테이션은 사용자가 연관된 CF 아이콘을 호출하는 컨텍스트에 기초하여 상기한 방식으로 커스터마이즈된다. 보다 구체적으로는, BUIA(106)는 컨텍스트를 기술하는 하나 이상의 파라미터를 UI 발생기 모듈(202)에 제공하고, UI 발생기 모듈(202)은, 이에 응답하여, 이들 파라미터에 적합하도록 구성되어 있는 CF 사용자 인터페이스 프리젠테이션을 제공한다. 전술한 바와 같이, 인터페이스 제공자(108)는 또한 수신된 파라미터를 사용하여 그의 시각적 사용자 인터페이스 측면들 이외에 CF 기능의 기타 측면들을 커스터마이즈할 수 있다.

서로 다른 기술 및 비지니스 환경에서 시스템(100)의 서로 다른 사용에 따라, UI 발생기 모듈(202)에 전달되는 파라미터들이 다양하다. 일례에서, 이들 파라미터로는 다음과 같은 것들이 있을 수 있다.

파트너 ID. 이 전달된 파라미터는 BUIA(106)를 관리하는 개체를 기술한다.

애플리케이션 ID. 이 전달된 파라미터는 사용자와 상호작용하고 있는 BUIA(106)의 기본적인 속성을 기술하며, 예를 들어, ID1 = 검색 애플리케이션, ID2 = 이메일 애플리케이션, 기타 등등이 있다.

시나리오 ID. 이 전달된 파라미터는 사용자와 현재 상호작용하고 있는 BUIA(106)의 측면을 기술한다.

로케일 ID(Locale ID). 이 전달된 파라미터는 장소, 아마도 목표 장치(104)의 장소를 기술한다.

사용자가 BUIA(106) 또는 어떤 다른 서비스에 로그인한 상황에서, UI 발생기 모듈(202)은 또한 사용자의 신원(identity) 및/또는 기타 특성들을 반영하는 자격 증명 정보(credential information)를 수신할 수 있다.

이름-값 쌍(들). 이들 전달된 파라미터는 사용자가 목표 장치(104)로 전송하고자 하는 특정의 정보를 지정한다. 예를 들어, 검색의 경우에, 전달된 이름-값 쌍은 ResultID = {결과를 나타내는 GUID}를 포함할 수 있다. 이미지 애플리케이션의 경우에, 전달된 이름-값 쌍은 Image = {원본 이미지에 대한 URL}을 포함할 수 있다. BUIA(106)는 특정의 호출하는 애플리케이션 및 기타 인자들에 따라 하나의 파라미터 쌍 또는 일군의 파라미터 쌍을 전달할 수 있다.

UI 발생기 모듈(202)에 의해 제공되는 CF 사용자 인터페이스 프리젠테이션들 중 어떤 것은 요청 정보를 수집하는 데 사용된다. 요청 정보는 컨텐츠를 목표 장치(104)로 전송하라는 사용자 요청의 두드러진 측면들을 정의한다. 최소한, 이 요청 정보는 목표 장치(104)의 주소를 지정한다.

어떤 경우들에, 사용자는 목표 장치(104)의 주소 등의 어떤 요청 정보를 미 리 지정해두었을 수도 있다. 이 요청 정보는 사용자의 ID 정보와 관련하여 프로파일 저장소(profile store)(208)에 저장될 수 있다. 또는, 이 요청 정보가 쿠키 형태 등의 보다 비형식적인 방식으로 저장될 수 있다. 어느 경우든지, 사용자의 개인 데이터가 암호화되어 이 정보를 사용자(또는 임의의 다른 최종 사용자)가 쉽게 이용할 수 없도록 될 수 있다. 이 동일 사용자가 다시 로그인하는 경우, UI 발생기(202)는 사용자가 이 정보를 다시 입력할 필요없이 이전에 저장된 요청 정보에 액세스할 수 있다. 이 경우, 사용자는 식별된 정보 아이템을 목표 장치(104)로 자동적으로 전송하기 위해 단순히 CF 아이콘을 클릭할 수 있다.

목표로 전송 요청 모듈(send-to-target request module)(204)은 수집된 요청 정보를 RPF(110)로 전송하는 데 사용된다. RPF(110)는 수신된 요청 정보를 사용하여 메시지를 작성하고, 이 메시지는 이어서 목표 장치(104)로 전달된다.

상태 문의 모듈(206)은 RPF(110)로부터 참조 정보(예를 들어, 핸들)를 수신한다. 이 핸들은 RPF(110)에 의해 메시지와 연관되어 있다. 상태 문의 모듈(206)은 RPF(110)에 주기적으로 질문을 하여 메시지의 상태, 예를 들어, RPF(110)가 메시지를 목표 장치(104)로 성공적으로 전송할 수 있는 것으로 판정했는지 및 메시지가 실제로 목표 장치(104)로 전달되었는지를 판정하기 위해 이 핸들을 사용한다. 상태 문의 모듈(206)은 또한 UI 발생기 모듈(202)에 상태 정보를 제공하고, UI 발생기 모듈(202)은 차례로 하나 이상의 CF 사용자 인터페이스 프리젠테이션에서 이 정보를 사용자에게 전달한다.

A.3. 자동-아이콘 채움기(Auto-Icon Populator)

도 2는 선택적인 자동-아이콘 채움기(auto-icon populator)(210)가 BUIA(106)에 의해 제공된 기본 사용자 인터페이스 프리젠테이션에 CF 아이콘을 자동적으로 추가하는 데 사용될 수 있음을 나타내고 있다. 즉, 기준 체계로서, 한 기법에서는, 설계자가 CF 아이콘으로 주석 첨부되어야만 하는 정보 아이템을 특정의 기본 사용자 인터페이스 프리젠테이션에서 수동으로 선택할 수 있고, 기본 사용자 인터페이스 프리젠테이션을 CF 아이콘으로 채우는 코드(예를 들어, BUIA CF 기능(116))를 생성할 수 있다. 이와 달리, 자동-아이콘 채움기(210)는 (이들 정보 아이템을 목표 장치(104)로 전송하는 것이 바람직할 수 있기 때문에) CF 아이콘으로 주석 첨부하는 것이 바람직할 수 있는 하나 이상의 정보 아이템의 존재를 판정하기 위해 기본 사용자 인터페이스 프리젠테이션을 자동적으로 스캔하는 동작을 한다.

이와 같이 기능하기 위해, 자동-아이콘 채움기(210)는 기준 데이터 저장소(criteria data store)(212)에 기술되어 있는 규칙들에 의존할 수 있다. 이들 규칙은 자동-아이콘 채움기(210)가 CF 아이콘을 기본 사용자 인터페이스 프리젠테이션에 추가하게 되는 상황을 지정하고 있다. 이들 규칙은 일반적으로 "특징 X가 기본 사용자 인터페이스 프리젠테이션에서 발견되는 경우, 그 특징 X를 식별해주는 CF 아이콘을 추가한다(if feature X is found in the base user interface presentation, then add a CF icon which identifies the feature X)"의 형태를 갖는다. 특정의 규칙으로는 이하의 것들이 있을 수 있다.

규칙은 사용자 연락처 정보를 보여주는 것으로 보이는 컨텐츠를 식별하 고, 이어서 하나 이상의 CF 아이콘으로 그 컨텐츠에 주석 첨부할 수 있다. 예를 들어, 이 규칙은 텍스트가 전화 번호, 이메일 주소, 거리 주소, 기타 등등을 나타낸다는 것을 알려주는 암시 표시(telltale sign)를 갖는 텍스트를 식별할 수 있다.

규칙은 사용자가 목표 장치(104)에 대한 배경 이미지(예를 들어, 배경 화면)로서 또는 목표 장치(104)에 대한 벨소리로서, 기타 등등으로서 적용하고자 할 수 있는 컨텐츠를 식별할 수 있고, 이어서 그 컨텐츠에 하나 이상의 CF 아이콘으로 주석 첨부할 수 있다. 예를 들어, 이 규칙은 미리 정해진 파일 크기를 갖는 이미지 또는 오디오 컨텐츠를 탐색할 수 있다.

규칙은 소정의 수의 상위 검색 결과를 식별할 수 있고, 이어서 이들 검색 결과에 하나 이상의 CF 아이콘으로 주석 첨부할 수 있다.

또다른 규칙이 CF 아이콘을 기본 사용자 인터페이스 애플리케이션에 추가하는 데 적용될 수 있다. 다른 경우에, 자동-아이콘 채움기(210)는 CF 아이콘으로 주석 첨부되어야만 하는 정보 아이템을 식별하기 위해, 인공 지능 분석 도구, 신경망 분석 도구, 기타 등등을 비롯한 더 진보된 도구에 의존할 수 있다. 게다가, 자동-아이콘 채움기(210)는 최종 사용자 또는 다른 사람이 자동-아이콘 채움기(210)에 의해 생성된 주석 첨부 결과가 바람직한지(desirability)를 비판할 수 있게 해주는 피드백 메카니즘을 포함할 수 있다. 이어서, 자동-아이콘 채움기(210)는 이 피드백으로부터 학습을 하여 장래의 그의 성능을 향상시킬 수 있다. 예를 들어, 자동-아이콘 채움기(210)는 만족스럽지 않은 것으로 식별되는 결과에 마이너스 가중치를 줄 수 있고(negatively weight), 만족스러운 것으로 식별되는 결과에 플러 스 가중치를 줄 수 있다(positively weight). 또다른 종류의 분석 엔진도 사용될 수 있다.

자동-아이콘 채움기(210)는 또한 실용적 속성(pragmatic nature)의 다양한 규칙들을 구현할 수 있다. 예를 들어, 자동-아이콘 채움기(210)는 CF 아이콘의 수를 소정의 수로 제한할 수 있다. 그렇게 함에 있어서, 자동-아이콘 채움기(210)는 (데이터 저장소(212)에 저장된 기준에 기초하여) 서로 다른 정보 아이템의 중요도에 순위를 부여할 수 있고, 이어서 아이콘을 받을 상위 N개의 아이템을 선택할 수 있다.

한 경우에, 자동-아이콘 채움기(210)는 웹-액세스가능한 서비스로서 설치될 수 있다. 웹 서비스는 웹 페이지 및 기타 컨텐츠를 분석하고 이 컨텐츠에 CF 아이콘을 추가할 수 있다. 다른 경우에, 자동-아이콘 채움기(210)는 로컬 클라이언트 사이트(local client site)에서 이용될 수 있다. 이러한 응용에서, 자동-아이콘 채움기(210)는 제1 장치(102)에 의해 로딩된 웹 페이지 또는 기타 컨텐츠를 로컬 레벨에서 분석하고 이 컨텐츠에 CF 아이콘을 추가할 수 있다. 예를 들어, 자동-아이콘 채움기(210)는 브라우저 도구 모음 내의 도구로서 추가될 수 있다.

임의의 구현에서, 사용자가 자동-아이콘 채움기(210)를 활성화 및 비활성화할 수 있게 해주는 기능이 포함될 수 있다. 채움기(210)가 활성화될 때, 채움기(210)는 CF 아이콘을 그대로 둔채로 기본 사용자 인터페이스 프리젠테이션을 새로고침할 수 있다. 채움기(210)가 비활성화될 때, 채움기(210)는 CF 아이콘을 제거한 채로 기본 사용자 인터페이스 프리젠테이션을 새로고침할 수 있다.

A4. 예시적인 요청 처리 기능

도 3은 RPF(request processing functionality, 요청 처리 기능)(110)의 예시적인 내용을 나타낸 것이다. RPF(110)는 몇가지 컴포넌트를 포함할 수 있다. 주요 컴포넌트로서, RPF(110)는 요청 핸들러 모듈(request handler module)(302)을 포함할 수 있다. 요청 핸들러 모듈(302)의 기본적인 목적은 인터페이스 제공자(108)로부터 요청 정보를 수신하고, 이 요청 정보를 메시지로 작성(formulate)하며, 그 메시지를 목표 장치(104)로 전달하고, 이어서 그 전달된 메시지와 연관된 목표 장치(104)와의 임의의 상호작용을 잘 처리(field)하는 것이다.

우선 먼저, 요청 핸들러 모듈(302)은 요청 허가 모듈(request authorization module)(304)과 상호작용할 수 있다. 요청 허가 모듈(304)의 한가지 목적은 사용자가 식별된 컨텐츠를 목표 장치(104)로 전달하도록 허가되어 있는지를 판정하는 것이다. 이 동작은 사용자 프로파일 정보의 하나 이상의 데이터 저장소(도시 생략)를 조회함으로써 로그인한 사용자(signed-in user)에 대해 수행될 수 있다. 사용자 프로파일 정보는 (사용자 ID로 식별되는) 특정의 사용자가 특정의 목표 장치로 컨텐츠를 전송하도록 허용되어 있는지를 알려줄 수 있다. 허가 모듈(304)은 사용자가 BUIA(106)에 로그인한 결과로서 또는 사용자가 어떤 다른 애플리케이션 또는 서비스에 로그인한 결과로서 사용자의 신원을 판정할 수 있다.

사용자가 컨텐츠를 전송하도록 허용되어 있는 경우, 목표 장치(104)로 전송될 메시지를 작성하기 위해 메시지 생성 모듈(304)이 사용된다. 상기한 바와 같이, 이 메시지는 목표 장치(104)로 전송될 컨텐츠를 직접 제공할 수 있고 및/또는 나중에 목표 장치(104)에 의해 액세스될 수 있는 컨텐츠를 단순히 참조할 수 있다.

메시지 생성 모듈(304)이 메시지를 작성할 수 있는 한가지 방법은 플러그인 애플리케이션 프레임워크(plug-in application framework)(306)를 사용하는 것이다. 플러그인 애플리케이션 프레임워크(306)는 다양한 플러그인 애플리케이션 모듈(308, 310, ... 312)을 포함한다. 이들 애플리케이션 모듈(308, 310, ... 312) 각각은 서로 다른 BUIA(106)에 관한 것이다. 예를 들어, 하나의 애플리케이션 모듈은 검색 애플리케이션에 관한 것일 수 있는 반면, 또하나의 애플리케이션 모듈은 사진 브라우징 애플리케이션에 관한 것일 수 있으며, 이하 마찬가지이다. 각각의 애플리케이션 모듈(308, 310, ... 312)의 목적은 사용자가 목표 장치(104)로 전달하고자 하는 컨텐츠와 연관된 URL 및/또는 메시지 컨텐츠를 제공하는 것이다. 서로 다른 애플리케이션 모듈(308, 310, ... 312)이 사용되는 이유는 서로 다른 애플리케이션이 URL 및 메시지 컨텐츠의 선택에 서로 다른 규칙을 적용할 수 있기 때문이다. 한 경우에, 메시지 컨텐츠는 일반 영숫자 및/또는 그래픽 컨텐츠를 포함할 수 있다. 이 컨텐츠는 이 메시지 컨텐츠가 특정의 컨텐츠-전달 시나리오에 적합하도록 커스터마이즈될 수 있게 해주는 와일드카드 엔트리(wildcard entry)를 포함할 수 있다.

그렇지만, 목표 장치(104)로 전송되는 메시지는 플러그인 애플리케이션 프레임워크(306)에 의해 제공되는 특정의 URL 및 메시지 컨텐츠 모두를 포함할 수도 있고 포함하지 않을 수도 있다. 예를 들어, 어떤 제한적인 프로토콜(단일의 SMS 패킷을 통한 전송 등)은 목표 장치(104)로의 URL 정보의 전송에 즉각 대처하지 못할 지도 모른다. 이 문제에 대처하기 위해, 메시지 생성 모듈(304)은 miniguid 등의 단축 참조 식별자(shorthand reference identifier)를 그 메시지에 할당할 수 있고, 이어서 실제 URL 대신에 이러한 miniguid를 목표 장치(104)로 전송할 수 있다. 사용자가 목표 장치(104)에서 miniguid를 활성화시킬 때, 요청 핸들러 모듈(302)은 이 miniguid를 실제 URL로 다시 매핑할 수 있고, 따라서 사용자를 실제 URL과 연관된 원하는 컨텐츠로 리디렉션할 수 있다.

그렇지만, 이 초기 단계에서, 메시지 생성 모듈(304)은 단지 메시지를 메시지 저장소(314)에 저장할 뿐이다. 보다 구체적으로는, 메시지 저장소(314)는, 메시지를 작성하는 데 사용되는 요청 정보, 플러그인 애플리케이션 프레임워크(306)로부터 검색된 실제 URL 및 메시지 컨텐츠, 및 메시지 생성 모듈(304)에 의해 할당된 miniguid 등의, 메시지와 연관된 다양한 정보를 저장할 수 있다. 이 메시지 저장소(314)는 목표 장치(104)로부터 수신된 miniguid에 기초하여 원하는 컨텐츠의 실제 URL을 찾기 위한 매핑 테이블(mapping table)로서 역할할 수 있다. 메시지가 메시지 저장소(314)에 처음으로 저장될 때, 이는 "통신 사업자 탐색 보류 중(pending carrier lookup)"의 상태로 플래깅된다.

통신사업자 탐색(carrier lookup)의 주제에 관하여, 요청 핸들러 모듈(302)은 전달 선택 모듈(delivery selection module)(316)을 포함한다. 전달 선택 모듈(316)의 한가지 목적은 CF 사용자 인터페이스 프리젠테이션을 통해 사용자에 의해 입력된 주소 정보(전화 번호 등)를 목표 장치(104)로 메시지 및 그의 선택적인 링크된 컨텐츠를 전달하는 데 사용될 수 있는 통신사업자(carrier)에 매핑하는 것 이다. 이 기능을 수행하기 위해, 전달 선택 모듈(316)은 이 매핑 기능을 수행하는 다양한 공지된 서비스에 의존할 수 있다.

그에 부가하여, 전달 선택 모듈(316)은 통신사업자가 지원하는 가능한 전달 방법들의 리스트를 제공할 수 있다. 예시적인 전달 방법으로는, WAP Push 프로토콜(여기서 WAP는 Wireless Application Protocol(무선 애플리케이션 프로토콜)의 줄임말임), SMS(여기서, SMS는 Short Message Service(단문 메시지 서비스)의 줄임말임), SMTP(여기서, SMTP는 Simple Mail Transfer Protocol(단순 메일 전송 프로토콜)의 줄임말임), MMS(Multimedia Message Service, 멀티미디어 메시지 서비스), 기타 등등이 있다. 전달 선택 모듈(316)은 이들 프로토콜 각각에 서로 다른 선호도 점수(preference score)를 할당할 수 있다. 이들 점수는 사용되는 통신사업자의 ID(identity), 전송되는 컨텐츠의 특성, 목표 장치(104)의 특성(알려져 있는 경우), 기타 등등을 비롯한 다수의 컨텍스트 인자들에 따라 다를 수 있다. 전달 선택 모듈(316)은 이어서 최고 점수를 갖는 프로토콜에 대응하는 가장 선호되는 전달 방법을 선택할 수 있다. 한 경우에, 선택된 전달 방법은 컨텐츠가 목표 장치(104)로 전송되는 기본적인 방식을 결정한다. 예를 들어, 컨텐츠가 이미지에 대응하는 것으로 가정한다. 제1 전달 방법이 선택된 경우, 그 이미지는 메시지 자체와 함께 전송될 수 있다. 제2 전달 방법이 선택된 경우, 이미지 자체가 아니라 이미지에 대한 링크가 전송될 수 있다.

마지막으로, 전달 선택 모듈(316)(또는 아마도 요청 핸들러 모듈(302) 내의 다른 모듈)은 선택에 따라서는 전달을 수행하는 데 사용될 통신사업자 및 선택된 전달 프로토콜 및/또는 메시지를 수신할 목표 장치(104)(알려져 있는 경우)에 가장 적합하도록 메시지 및/또는 그의 선택적인 링크된 컨텐츠를 형식화할 수 있다.

한 경우에, 전달 선택 모듈(316)은 "통신사업자 탐색 보류 중" 상태를 갖는 엔트리가 있는지 메시지 저장소(314)를 주기적으로 스캔하는 동작을 할 수 있다. 전달 선택 모듈(316)은 이들 엔트리에 대해 통신사업자 탐색을 수행할 수 있다.

상태 문의 모듈(320)은 메시지 전달의 상태에 관하여 인터페이스 제공자(108)에 상태 정보를 제공하는 데 사용된다. 인터페이스 제공자(108)는, 차례로, 이 상태 정보를 하나 이상의 CF 사용자 인터페이스 프리젠테이션을 통해 사용자에게 전달한다. 즉, 메시지가 처음으로 생성되어 저장될 때, 상태 문의 모듈(320)은 그 메시지와 연관되어 있는 핸들을 인터페이스 제공자(108)에 반환할 수 있다. 인터페이스 제공자(108)는 그 후에 RPF(110)에 질의를 하여 전달의 상태를 판정하기 위해 이 핸들을 사용할 수 있다. 인터페이스 제공자(108)가 이러한 질문을 할 때, 상태 문의 모듈(320)은 상태 정보를 인터페이스 제공자(108)에게 제공하는 것으로 응답을 한다.

메시지가 처음으로 생성될 때, 이는 "통신사업자 탐색 보류 중"의 상태를 할당받는다. 통신사업자가 성공적으로 결정되었을 때, 상태는 "전달 보류 중(pending delivery)"으로 변할 수 있다. 메시지가 실제로 전달될 때, 상태는 "전달됨(delivered)"으로 변할 수 있다. 이 프로세스에서 여러가지 에러가 일어날 수 있다. 예를 들어, 메시지를 식별된 목표 장치(104)로 전달하는 데 적합한 통신사업자가 존재하지 않을 수도 있다. 이 경우에, 상태 문의 모듈(320)은 인터페이 스 제공자(108)에게 여러가지 에러 메시지를 반환할 수 있고, 인터페이스 제공자(108)는 다양한 CF 사용자 인터페이스 프리젠테이션에서 이들 에러 메시지를 사용자에게 전달할 수 있다.

메시지 전달 모듈(322)은 메시지 저장소(314) 내의 메시지를 목표 장치(104)로 전달하는 작업을 수행한다. 이 모듈(322)은 목표 장치(104)로 전송될 준비가 된 메시지들을 식별하기 위해 메시지 저장소(314)를 주기적으로 스캔하고 이어서 그 메시지들을 전송함으로써 이 작업을 수행할 수 있다. 메시지의 상태가 이 메시지에 대해 통신사업자 탐색 동작이 성공적으로 수행되었음을 반영할 때, 메시지는 목표 장치로 전송될 준비가 되어 있다.

요청 핸들러 모듈(302)의 나머지 컴포넌트는 목표 상호작용 모듈(target interaction module)(324)이다. 목표 상호작용 모듈(324)의 목적은 목표 장치(104)와 상호작용하는 것이다. 예를 들어, 목표 장치(104)에 의해 수신된 메시지는 하나 이상의 링크를 포함할 수 있다. 사용자가 이들 링크 중 하나를 활성화시킬 때, 목표 장치(104)는 정보를 다시 목표 상호작용 모듈(324)로 전달한다. 목표 상호작용 모듈(324)은 이어서 활성화된 링크와 연관되어 있는 모든 컨텐츠에 액세스하고 이를 공급함으로써 목표 장치(104)의 요청을 처리한다.

한 경우에, 전달 모듈(322)에 의해 목표 장치(104)로 전송된 메시지는 링크된 컨텐츠의 실제 URL을 제공할 수 있다. 이 경우에, 목표 상호작용 모듈(324)은 목표 장치(104)로부터 이 URL을 다시 수신할 수 있고, 이어서 이 URL을 사용하여 링크와 연관된 컨텐츠를 직접 검색할 수 있다. 다른 경우에, 이 메시지는 실제 URL에 대한 단축 참조(shorthand reference)인 miniguid를 제공할 수 있다. 실제 URL을 검색하기 위해, 목표 상호작용 모듈(324)은 이 miniguid을 매핑 참조로서 사용하여 실제 URL을 찾아낸다. 메시지 저장소(314)는 이러한 매핑 기능을 제공할 수 있다. 실제 URL과 연관된 컨텐츠는 이어서 검색되어 목표 장치(104)로 전송될 수 있다.

한 경우에, 메시지 저장소(314)는 3주후 등의 소정의 시간 후에 메시지 저장소 내의 아이템들을 은퇴(예를 들어, 삭제)시킨다. 따라서, 사용자가 3주 기간 내에 목표 장치(104)에 수신된 메시지를 활성화시키면, 이 매핑이 성공적으로 수행될 수 있다. 사용자가 3주 기간 후에 메시지를 활성화시키면, 매핑이 성공하지 않을 수도 있다. 그 경우에, 목표 상호작용 모듈(324)은 사용자를, 통신사업자와 연관된 기본 페이지(default page) 등의 기본 페이지로 보낼 수 있다. 통신사업자는 다양한 방식으로 식별될 수 있다. 한 경우에, 목표 장치(104)로 전송된 miniguid는 통신사업자에 대한 참조는 물론 기타 파라미터 정보도 포함할 수 있다. 이렇게 함으로써 목표 장치(104)가 기본 페이지에 액세스할 수 있다. 사용자를 기본 페이지로 보내는 것은 마케팅 관점에서 아마도 중요할 수 있다. 예를 들어, 기본 페이지는 선택에 따라서 사용자를 하나 이상의 서비스에 관심을 갖게 하려고 할 수 있다.

목표 장치(104)로부터의 요청에 응답하여, 목표 상호작용 모듈(324)은 목표 장치(104)의 특성(및/또는 컨텐츠를 목표 장치(104)로 전달하는 데 사용되는 프로토콜들)에 가장 적합하도록 목표 장치(104)로 전송되는 컨텐츠를 형식화하기 위해 전달 선택 모듈(316)을 이용할 수 있다. 예를 들어, 목표 장치(104)가 작은 사용자 인터페이스를 갖는 모바일 전화 등의 소형 장치인 것으로 가정한다. 전달 선택 모듈(316)은 정보가 목표 장치(104)의 화면에 "들어"가도록 실제 크기의 정보 아이템 내의 정보를 압축할 수 있다. 일반적으로, 목표 상호작용 모듈(324) 및 전달 선택 모듈(316)은 어떤 사용자 인터페이스 특징들을 재형식화하는 것(reformatting), (예를 들어, 어떤 특징들을 필터링 및 생략함으로써) 어떤 사용자 인터페이스 특징들을 간소화시키는 것(simplifying), (예를 들어, 어떤 특징들을 추가함으로써) 어떤 사용자 인터페이스 특징들을 향상시키는 것(enhancing), (예를 들어, HTML 대신에 WML, XHTML, cHTML, 기타 등등으로 변환함으로써) 사용자 인터페이스 특징들과 연관된 마크업 언어를 변경하는 것(changing), 기타 등등에 의해 이러한 변환을 협동적으로 수행할 수 있다. 목표 장치(104)에 관한 정보는, 예를 들어, 목표 장치(104)가 메시지와 연관된 특정의 컨텐츠를 검색하기 위해 RPF(110)와 접촉할 때, 전달될 수 있다. 예를 들어, 목표 장치(104)에 관한 정보는 목표 장치(104)의 요청 내의 다양한 파라미터에 의해 전달될 수 있다.

A.5. 예시적인 사용자 장치

도 4는 대표적인 제1 장치(102) 또는 제2 장치(104) 등의 예시적인 사용자 장치(402)의 예시적인 컴포넌트들을 나타낸 것이다.

사용자 장치(402)는 프리젠테이션 유닛(presentation unit)(406)에 연결된 처리 장치(404)를 포함한다. 처리 장치(404)는 다양한 배속된 작업들을 수행하는 임의의 데이터 처리 기능을 포함한다. 프리젠테이션 유닛(406)은 임의의 종류의 출력 메카니즘을 제공하며, 이 메카니즘에 의해 사용자는 처리 장치(404)와 상호작용할 수 있다.

본 발명과 관련하여, 처리 장치(404)는 선택에 따라서 클라이언트 CF-관련 기능(408)을 포함할 수 있다. 제1 장치(102)의 경우에, 이 기능(408)은 목표 모듈(target module)(408)로 컨텐츠를 전달하는 것과 관련된 여러가지 동작들을 수행할 수 있다. 한 경우에, 클라이언트 CF-관련 기능(408)은, BUIA CF 기능(116)을 비롯한, BUIA(106)의 하나 이상의 측면들을 구현할 수 있다. (그렇지만, 다른 경우들에서, 상기한 바와 같이, BUIA(106)는 원격 파트너 웹 사이트, 기타 등등에 의해 구현될 수 있다.)

다른 경우에, 전술한 바와 같이, CF 기능(BUIA CF 기능(116) 등)의 하나 이상의 측면들이 사용자 장치(402)에 의해 로컬적으로 구현되는 브라우저 기능에서 구현될 수 있다. 예를 들어, 이 브라우저 기능은 CF 기능을 활성화 또는 비활성화하도록 구성될 수 있다. 활성화될 때, CF 기능은 기본 사용자 인터페이스 프리젠테이션에서 CF 아이콘 및 CF 사용자 인터페이스 프리젠테이션을 디스플레이할 수 있다. 비활성화될 때, CF 기능은 이 CF 정보를 디스플레이하지 않는다. 다양한 CF-관련 명령이 브라우저의 도구모음 내에 구현될 수 있다.

다른 경우에, 자동-아이콘 채움기(210)(도 2 참조)의 측면들이 사용자 장치(402)에 의해 로컬 레벨에서 구현될 수 있다. 다시 말하면, 이 기능은 로컬 브라우저에 포함될 수 있다. 이 기능은 사용자 장치(402)에 의해 로딩되는 기본 사용자 인터페이스 프리젠테이션을 스캔할 수 있고 이들 프리젠테이션에 CF 아이콘으 로 적절히 주석 첨부할 수 있다. (그렇지만, 상기한 바와 같이, 이들 자동-채움기 동작들은 또한 하나 이상의 원격 사이트에 의해 수행될 수 있고, 이러한 구현에서, 사용자 장치(402)는 CF 아이콘으로 이미 주석 첨부되어 있는 기본 사용자 인터페이스 프리젠테이션을 수신할 수 있다.)

프리젠테이션 유닛(406)은 시각적 출력, 오디오 출력, 촉각적 출력, 이러한 출력들의 임의의 조합, 기타 등등을 제공할 수 있다. 예를 들어, 프리젠테이션 유닛(406)은 (예를 들어, 하나 이상의 그래픽 사용자 인터페이스 프리젠테이션에서) 사용자에게 시각적 출력을 제공하는 사용자 인터페이스(410)를 제공할 수 있다. 사용자 인터페이스(410)는 장치 레벨에서, 원격 서버 레벨에서, 또는 장치 레벨과 원격 서버 레벨의 조합에서 저장된 논리에 기초하여 사용자 인터페이스 프리젠테이션을 제공하는 데 사용될 수 있다. 사용자는 키보드, 마우스 장치, 터치 스크린, 기타 등등의 다양한 입력 메카니즘을 통해 사용자 인터페이스 프리젠테이션과 상호작용을 할 수 있다. 다른 대안으로서, 사용자 인터페이스(410)는 전체적으로 또는 부분적으로 오디오 메카니즘에 의해, 예를 들어, 정보의 구두 교환(verbal exchange)을 통해 사용자가 시스템(100)과 상호작용할 수 있게 해줌으로써 구현될 수 있다.

B. 예시적인 사용자 인터페이스 프리젠테이션(도 5 내지 도 7)

도 5 내지 도 7은 사용자가 시스템(100)과 상호작용하는 데 사용할 수 있는 예시적인 사용자 인터페이스 프리젠테이션을 제공한다. 본 명세서를 읽어보면 이들 사용자 인터페이스 프리젠테이션의 스타일, 구성 및 내용이 다른 기술 및 비지 니스 환경에 적합하도록 변경될 수 있다는 것을 잘 알 것이다.

B.1. 기본 사용자 인터페이스 프리젠테이션을 CF 아이콘 및 CF 사용자 인터페이스 프리젠테이션으로 주석 첨부하기

우선 먼저, 도 5는 BUIA(106)에 의해 제공될 수 있는 한 예시적인 사용자 인터페이스 프리젠테이션(500)을 나타낸 것이다. 사용자 인터페이스 프리젠테이션(500)은 제1 사용자 장치(102)의 사용자 인터페이스(410)에 디스플레이될 수 있다. 광의적 측면에서 볼 때, 이 사용자 인터페이스 프리젠테이션(500)은 이상에서 "기본 사용자 인터페이스 프리젠테이션"라고 한 것에 대응한다.

도 5의 BUIA(106)는 검색 기능을 제공한다. 이 특정의 예시적인 시나리오에서, 사용자는 그의 현재의 위치인 Virginia주의 Alexandria에 가까운 피자 레스토랑의 위치를 결정하고자 한다. 따라서, 사용자는 "Pizza" 및 "Alexandria, VA" 등의 다양한 검색어를 입력한다. 이에 응답하여, 사용자는 검색어들에 일치하는 검색 결과(502)의 리스트를 받는다. 각각의 검색 결과는 정보 아이템을 포함한다. 예를 들어, 처음 2개의 검색 결과(504, 506)는 2개의 개별적인 정보 아이템을 포함한다. 사용자 인터페이스 프리젠테이션은 또한 검색 결과(502)에서 식별된 레스토랑들 중 하나 이상의 위치를 보여주는 지도(508)를 제공할 수 있다.

검색 결과(502)에서의 정보 아이템들 각각은 CF 아이콘으로 주석 첨부된다. 예를 들어, 정보 아이템(506)은 CF 아이콘(510)으로 주석 첨부된다. 이 CF 아이콘(510)은 라벨 "Send to mobile(모바일로 전송)"을 가지고 있어, 이 아이콘(510)을 활성화시켜 정보 아이템(504)을 목표 장치(104)(예를 들어, 모바일 전화)로 전 송할 수 있음을 사용자에게 알려준다. CF 아이콘(510)의 시각적 외관은 대표적인 것이지 제한하기 위한 것이 아니며, 이 시각적 외관은 다수의 환경적 고려 사항들에 따라 크게 달라질 수 있다.

기본 사용자 인터페이스 프리젠테이션은 여러 방법들을 사용하여 CF 아이콘으로 주석 첨부될 수 있다. 한 방법에서, 설계자는 CF 아이콘을 각자의 검색 결과에 추가하는 일정한 코드(fixed code)를 작성할 수 있다. 다른 방법에서, 기본 사용자 인터페이스 프리젠테이션의 내용을 자동적으로 분석하고 데이터 저장소(212) 내의 사전 정의된 규칙과 일치하는 정보 아이템들에 CF 아이콘을 추가하기 위해 자동-아이콘 채움기(210)가 사용될 수 있다. 제2 방법은 그에 따라 제1 방법보다 더 유연성이 있다.

도 5에 도시된 사용 시나리오에서, 사용자는 제2 정보 아이템(506)을 목표 장치(104)로 전송하려고 한다. 이 동작을 수행하기 위해, 사용자는 제2 항목(506)과 연관된 CF 아이콘을 클릭한다. 이것은, 차례로, 시스템(100)으로 하여금 CF 사용자 인터페이스 프리젠테이션(512)을 디스플레이하게 한다. 상기한 바와 같이, 인터페이스 제공자(108)는 CF 사용자 인터페이스 프리젠테이션(512)을 제공한다. 따라서, 그 결과로서 사용자에게 제공되는 사용자 인터페이스 프리젠테이션은 기본 사용자 인터페이스 프리젠테이션과 CF 사용자 인터페이스 프리젠테이션을 합한 것(aggregate)이다. 이들 2개의 사용자 인터페이스 컴포넌트는 상기한 바와 같이 2개의 서로 다른 소스로부터 온 것일 수 있다.

이러한 초기 CF 사용자 인터페이스 프리젠테이션(512)의 목적은 사용자로부 터 요청 정보를 수집하는 것이다. 보다 구체적으로는, CF 사용자 인터페이스 프리젠테이션(512)은 사용자에게 주소 정보를 요청하도록 설계된 주소 입력 필드(514)를 포함한다. 이 주소 정보는 컨텐츠를 수신하게 될 목표 장치(104)의 주소를 식별해준다. CF 사용자 인터페이스 프리젠테이션(512)은 또한 수집된 요청 정보를 처리를 위해 RPF(110)로 전달하도록 인터페이스 제공자(108)에게 지시하는 전송 명령 버튼(send command button)(516)을 포함한다.

이전의 섹션들에서 상세히 설명한 바와 같이, 인터페이스 제공자(108)는 사용자가 대응하는 CF 아이콘을 호출하는 컨텍스트에 적합하도록 CF 사용자 인터페이스 프리젠테이션(512)을 커스터마이즈한다. 이 컨텍스트는 인터페이스 제공자(108)에게 제공되는 하나 이상의 파라미터로서 표현될 수 있다. CF 인터페이스 프리젠테이션(512)은, 예를 들어, 목표 장치(104)의 로케일(locale)을 반영하는 파라미터에 응답하여 커스터마이즈된다. 예를 들어, 주소 입력 필드(514)의 형식은 미국 내의 배달 구역에 대한 전화 번호를 받도록 구성되어 있다.

B.2. 예시적인 기타 유형의 CF 사용자 인터페이스 프리젠테이션

도 6a 내지 도 6e는 다양한 기타 유형의 CF 사용자 인터페이스 프리젠테이션을 제공한다. 이들 프리젠테이션은, 어떤 조건들이 만족되는 경우에, 도 5의 CF 사용자 인터페이스 프리젠테이션(512)의 제공 이후에 사용자에게 제공된다.

도 6a의 경우에, 사용자는 도 5의 CF 사용자 인터페이스 프리젠테이션(512)에서 "Not in the United States(미국 이외)" 링크를 활성화하였다. 이것은 인터페이스 제공자(108)로 하여금 다른 로케일을 선택하는 옵션을 사용자에게 제공하는 CF 사용자 인터페이스 프리젠테이션을 디스플레이하도록 한다.

도 6b의 경우에, 인터페이스 제공자(108)는 선택에 따라 사용자가 시스템(100)과 상호작용하게 허가되도록 다양한 보안 동작을 관리할 수 있다. 도 6b의 경우에, 인터페이스 제공자(108)는 사용자에게 HIP(Human Interaction Proof) 입력 절차를 성공적으로 완료하도록 요구하는 사용자 인터페이스 프리젠테이션을 제공한다. HIP는 사람만이 이해하고 반복할 수 있는 문자들을 디스플레이하는 사용자 인터페이스 프리젠테이션을 말한다. 이러한 프리젠테이션의 사용은 자동화된 애플리케이션이 부적절한 목적으로 CF 기능을 활용할 수 있는 위험을 줄여준다.

도 6c의 경우에, 인터페이스 제공자(108)는 RPF(110)가 한가지 이상의 이유로 이번에 사용자의 목표 장치(104)에 접속할 수 없었음을 사용자에게 알려준다. 예를 들어, RPF(110)는 목표 장치(104)로 메시지를 전달할 수 있는 통신사업자를 찾는 데 성공하지 못했을 수도 있다. 이러한 실패의 경우에, 도 6c에 도시된 CF 사용자 인터페이스 프리젠테이션은 CF 기능을 후원하는 개체에 의해 또는 어떤 다른 개체에 의해 제공되는 다른 모바일-관련 서비스로 사용자를 보낼 수 있다. 이렇게 함으로써 CF-후원 개체는 잠재적으로 실패를 마케팅 기회로 이용할 수 있다.

도 6d의 경우에, 인터페이스 제공자(108)는 요청이 여전히 보류 중에 있음을 사용자에게 알려주며, 이는 메시지가 아직도 사용자의 목표 장치(104)로 전달되지 않았음을 의미한다.

마지막으로, 도 6e의 경우에, 인터페이스 제공자(108)는 사용자의 요청이 성공적임을 사용자에게 알려주며, 이는 메시지가 사용자의 목표 장치(104)로 전달되 었음을 의미한다.

B.3. 예시적인 목표 장치 사용자 인터페이스 프리젠테이션

도 7은 목표 장치(104)의 사용자 인터페이스 상에 디스플레이되는 예시적인 사용자 인터페이스 프리젠테이션(700)을 나타낸 것이다. 목표 장치(104)는 이 경우에 모바일 전화 등의 소형 장치에 대응한다. 이 예시적이고 비제한적인 경우에, 사용자 인터페이스 프리젠테이션(700)은 도 5의 검색 결과(502)의 리스트에서의 정보 아이템(506)에 대응하는 텍스트 정보(702)를 제공한다.

사용자 인터페이스 프리젠테이션은 또한 검색 결과와 연관된 하나 이상의 링크(704)를 포함할 수 있다. 링크(704)에 의해 사용자는 검색 결과와 연관된 지도에 액세스할 수 있고, 검색 결과와 연관된 찾아가는 길을 검색할 수 있으며, 선택에 따라 새로운 검색을 수행할 수 있다. 사용자가 이들 링크(704) 중 하나를 활성화시킬 때, 사용자의 목표 장치(104)는 RPF(110)로 다시 메시지 파라미터를 전송한다. 이 메시지 파라미터는, miniguid 정보(RPF(110)에 의해 차례로 목표 장치(104)로 전달되었음)와 함께, 활성화된 링크에 대응하는 식별자를 적어도 포함할 수 있다. RPF(110)는 이어서 miniguid 정보를 링크와 연관된 실제 URL에 매핑할 수 있고, 요청된 컨텐츠를 목표 장치(104)에 있는 사용자에게 제공할 수 있다.

C. 예시적인 프로세스(도 8 내지 도 14)

도 8 내지 도 14는 도 1에 도시된 시스템(100)의 예시적인 동작 방식을 설명하는 절차를 나타낸 것이다. 설명을 용이하게 하기 위해, 어떤 동작들은 어떤 순서로 수행되는 서로 다른 단계들을 구성하는 것으로 기술되고 있다. 이러한 구현 은 예시적인 것이며 제한하는 것이 아니다. 본 명세서에 기술된 어떤 단계들은 그룹화되어 한번의 동작으로 수행될 수 있으며, 어떤 단계들은 본 명세서에 기술된 예들에서 이용되는 순서와 다른 순서로 수행될 수 있다. 시스템(100)의 예시적인 동작 방식이 이전의 섹션들에서 이미 기술되었기 때문에, 이 섹션은 주로 재검토하는 역할을 한다.

C.1. 요청 정보의 수집

도 8은 요청을 작성하는 절차(800)를 나타낸 것이다. 이 요청은 식별된 컨텐츠를 목표 장치(104)로 전달하도록 RPF(110)에 지시한다.

단계(802)에서, 시스템(100)은 BUIA(106)에 의해 제공된 기본 사용자 인터페이스 프리젠테이션에서 CF 아이콘을 사용자가 활성화하였음을 수신한다. CF 아이콘은 사용자가 목표 장치(104)로 전송하려고 하는 정보 아이템과 연관되어 있다. CF 아이콘의 활성화는 BUIA(106)로 하여금 하나 이상의 파라미터를 인터페이스 제공자(108)에게 전달하도록 요청한다. 이들 파라미터는, 애플리케이션 ID, 시나리오 ID, 로케일, 하나 이상의 이름-값 쌍, 기타 등등을 비롯하여, 사용자가 CF 아이콘을 활성화시킨 컨텍스트를 기술한다.

단계(804)에서, 인터페이스 제공자(108)는 인터페이스 제공자(108)로 전달된 파라미터와 일치하게 CF 사용자 인터페이스 프리젠테이션을 렌더링한다.

단계(806)에서, 인터페이스 제공자(108)는 제공된 CF 사용자 인터페이스 프리젠테이션을 사용하여 사용자로부터 정보를 수신한다. 이러한 정보는, 예를 들어, 목표 장치(104)의 주소를 포함한다. 이 동작은 사용자가 그의 주소 정보를 이 전에 제공한 경우 및 사용자가 현재 로그인되어 있는 경우(또는 어떤 다른 메카니즘으로부터 사용자의 신원이 추론될 수 있는 경우) 생략될 수 있다. 사용자에 관한 정보는 쿠키-기반 기술을 사용하여 또는 어떤 다른 방식으로 전용의 사용자 프로파일 저장소(208)에 저장될 수 있다.

단계(808)에서, 인터페이스 제공자(108)는 수집된 요청 정보를 처리를 위해 RPF(110)에 제공한다.

C.2. 메시지의 생성

도 9는 인터페이스 제공자(108)로부터 수신된 요청 정보에 기초하여 메시지를 생성하는 절차(900)를 나타낸 것이다.

단계(902)에서, RPF(110)는 허가 모듈(304)을 사용하여 요청이 허가되었는지를 결정한다. 이 동작은, 사용자가 로그인되어 있을 때, 사용자가 식별된 목표 장치(104)로 컨텐츠를 전송하도록 허가받았는지를 판정하기 위해 하나 이상의 데이터 저장소에 액세스하는 것으로 수행될 수 있다.

단계(904)에서, RPF(110)는 메시지를 작성하는 데 사용하기 위해 URL 및 텍스트 컨텐츠에 액세스한다. RPF(110)는 이 정보를 검색하기 위해 플러그인 애플리케이션 프레임워크(306)에 의존할 수 있다. 구체적으로는, RPF(110)는 사용 중인 BUIA(106)의 유형과 연관되어 있는 프레임워크(306)에서의 애플리케이션 모듈을 조회할 수 있다.

단계(906)에서, RPF(110)는 작성된 메시지를 메시지 저장소(314)에 저장할 수 있다. 그에 부가하여, RPF(110)는 miniguid를 생성하여 메시지 저장소(314)에 저장할 수 있다. miniguid는 메시지에 대한 단축 참조로서 역할하며, 이로부터 실제 URL이 검색될 수 있다. 다양한 제한적인 프로토콜의 사용에 대처하기 위해 목표 장치(104)로 실제 URL 대신에 miniguid를 전송하는 것이 바람직하다. 그렇지만, 메시지와 함께 실제 URL을 전송하는 것도 가능하며, 이 경우 miniguid 매핑 절차가 생략될 수 있다.

단계(908)에서, RPF(110)는 인터페이스 제공자(108)로 핸들(handle)을 전송한다. 이 핸들은 메시지와 연관되어 있다. 인터페이스 제공자(108)는 이 핸들을 사용하여 사용자의 요청의 상태를 판정한다.

C.3. 메시지를 목표 장치로 전송

도 10은 메시지 저장소(314)에 저장된 메시지를 목표 장치(104)로 전송하는 절차(1000)를 나타낸 것이다.

단계(1002)에서, RPF(110)는 통신사업자 탐색 보류중(pending carrier lookup)인 메시지 저장소(314) 내의 메시지들을 검사한다. 단계(906)에서 생성된 메시지는 처음에 "통신사업자 탐색 보류중(pending carrier lookup)" 상태를 부여받는다.

단계(1004)에서, RPF(110)는 단계(906)에서 생성된 메시지에 대해 통신사업자 탐색을 수행한다. 메시지를 전달하는 데 사용되어야만 하는 통신사업자를 식별하는 것에 부가하여, RPF(110)는 그 메시지를 목표 장치(104)로 전송하기 위한 선호되는 프로토콜(SMS, WAP Push, SMTP, MMS, 기타 중 어느 하나를 포함함)도 결정할 수 있다. 게다가, RPF(110)는 메시지를 전달하기 위해 컨텐츠의 재형식 화(reformatting)가 수행될 필요가 있는지를 결정할 수 있다.

단계(1006)에서, RPF(110)는 메시지가 단계(1004)의 통신사업자 탐색 동작을 통과한 경우 메시지의 상태를 변경한다. 메시지를 목표 장치(104)로 전송하는 데 적어도 하나의 통신사업자 및 적어도 하나의 전달 프로토콜이 이용가능한 경우 탐색이 성공적이다.

단계(1008)에서, 성공적인 통신사업자 탐색 이후에, RPF(110)는 메시지를 목표 장치(104)로 전송한다.

C.4. 상태 문의

도 11은 메시지 전달의 상태를 조사하는 절차(1100)를 나타낸 것이다.

단계(1102)에서, RPF(110)는 인터페이스 제공자(108)로부터 상태 요청을 수신한다.

단계(1104)에서, RPF(110)는 식별된 메시지의 상태를 판정하기 위해 메시지 데이터 저장소(1104)에 질의를 한다.

단계(1106)에서, RPF(110)는 상태 정보를 인터페이스 제공자(108)에게 제공한다.

단계(1108)는 일반적으로, RPF(110)로부터 메시지의 성공적인 전달의 표시를 수신하지 않고 소정의 시간이 경과한 경우, 인터페이스 제공자(108)가 사용자에게 에러 메시지를 제공할 수 있다는 것을 나타낸다.

C.5. 목표 장치로 전송된 컨텐츠의 활성화

도 12는 목표 장치(104)가 그가 수신한 메시지에 기초하여 컨텐츠를 검색할 수 있는 절차(1200)를 나타낸 것이다.

단계(1202)에서, RPF(110)는 컨텐츠를 검색하도록 목표 장치(104)로부터 요청을 수신한다. 예를 들어, 이 단계는 사용자가 RPF(110)로부터 수신된 메시지 내의 링크를 활성화시켰으며 그에 따라 사용자가 이 링크와 연관된 컨텐츠를 검색하고자 한다는 사실을 반영할 수 있다.

단계(1204)에서, RPF(110)는 목표 장치(104)에 의해 제공된 miniguid를 원하는 컨텐츠의 실제 URL에 매핑하기 위해 메시지 저장소(314)를 검사한다.

단계(1206)에서, RPF(110)는 사용자를 URL과 연관된 원하는 컨텐츠로 리디렉션한다. 반면에, miniguid가 만료되거나 다른 에러가 발생하는 경우, RPF(110)는 사용자를 기본 페이지로 리디렉션할 수 있다. 한 경우에, RPF(110)는 사용자를 목표 장치(104)의 통신사업자와 연관된 기본 페이지로 리디렉션한다. miniguid 자체는 목표 장치(104)의 통신사업자를 식별해주는 주소 정보를 포함할 수 있다.

다른 경우에, 목표 장치(104)로 전송되는 메시지는 원하는 컨텐츠의 실제 URL을 포함한다. 이들 경우에, 목표 장치(104)는 (miniguid에 기초하여) 상기한 메시지 저장 및 매핑 절차를 수행하지 않고 컨텐츠를 검색할 수 있다. 이것은 또한 목표 장치(104)로 전송되는 URL 정보가 (메시지 저장소(314) 내의 miniguid 정보가 그런것처럼) 꼭 만료될 필요는 없다는 것을 의미한다. (실제 URL을 전송하는) 이 방법의 다른 이점은 URL이 사용자에게는 (miniguid와 비교하여) 더 이해하기 쉬울 수 있다(예를 들어, 유용할 수 있다)는 것이다.

C.6. 기본 사용자 인터페이스 프리젠테이션에 CF 아이콘으로 자동 주석 첨부

도 13은 기본 사용자 인터페이스 프리젠테이션을 CF 아이콘으로 자동적으로 채우는 절차(1300)를 나타낸 것이다.

단계(1302)에서, 자동-아이콘 채움기(210)는 CF 아이콘으로 주석 첨부되어야만 하는 정보 아이템이 있는지 기본 사용자 인터페이스 프리젠테이션을 검사한다. 자동-아이콘 채움기(210)는 이 판정을 하기 위해 데이터 저장소(212) 내의 규칙들에 의존할 수 있다.

단계(1304)에서, 자동-아이콘 채움기(210)는 단계(1302)의 분석에 기초하여 기본 사용자 인터페이스 프리젠테이션에 CF 아이콘을 삽입한다.

C.7. 구성 정보를 목표 장치로 전송

도 14는 제1 장치(102)를 사용하여 생성된 구성 정보를 제2 장치(104)로 전송하는 절차를 나타낸 것이다.

단계(1402)에서, 시스템(100)은 제1 사용자 장치(102)에 디스플레이하기 위한 사용자 인터페이스 프리젠테이션을 구성하는 데 사용되는 구성 정보를 사용자가 선택하였음을 수신한다.

단계(1404)에서, 시스템(100)은 제1 장치(102)에 대해 생성된 구성 정보를 제2 장치(104)로 전달하라는 사용자의 지시를 수신한다.

단계(1406)에서, 시스템(100)은 이 구성 정보를 제2 장치(104)로 전달한다. 제2 장치(104)에서, 이 구성 정보는, 제1 장치(102)에서 사용하기 위해 생성된 구성과 유사한 방식으로, 제2 장치(104)에 대한 사용자 인터페이스 프리젠테이션을 구성하는 데 사용될 수 있다.

유의할 점은, 사용자가 시스템(100)에 로그인되어 있지 않을 수 있더라도, 도 14에 도시된 구성 절차(1400)가 수행될 수 있다는 것이다.

D. 예시적인 컴퓨터 환경(도 15)

도 15는 제1 장치(102), 제2 장치(104), BUIA(106)의 임의의 제공자(웹 사이트 서버 시스템 등), 인터페이스 제공자(108), RPF(110), 기타 등등의 이전의 섹션들에 기술된 처리 기능들 중 임의의 것을 구현하는 데 사용될 수 있는 예시적인 컴퓨터 환경(1500)에 관한 정보를 제공한다.

컴퓨팅 환경(1500)은 범용 또는 서버형 컴퓨터(1502) 및 디스플레이 장치(1504)를 포함한다. 그렇지만, 컴퓨팅 환경(1500)은 다른 종류의 컴퓨팅 장비를 포함할 수 있다. 예를 들어, 비록 도시되어 있지는 않지만, 컴퓨팅 환경(1500)은 핸드헬드 또는 랩톱 장치, 셋톱 박스, 게임 콘솔, 메인프레임 컴퓨터, 기타 등등을 포함할 수 있다. 게다가, 도 15는 설명을 용이하게 하기 위해 컴퓨팅 환경(1500)의 구성요소들을 그룹화하여 나타내고 있다. 그렇지만, 컴퓨팅 환경(1500)은 분산 처리 구성을 이용할 수 있다. 분산 컴퓨팅 환경에서, 컴퓨팅 자원들은 이 환경 전체에 걸쳐 물리적으로 분산되어 있을 수 있다.

예시적인 컴퓨터(1502)는 하나 이상의 프로세서 또는 처리 장치(1506), 시스템 메모리(1508) 및 버스(1510)를 포함한다. 버스(1510)는 다양한 시스템 컴포넌트들을 서로 연결시킨다. 예를 들어, 버스(1510)는 프로세서(1506)를 시스템 메모리(1508)에 연결시킨다. 버스(1510)는 메모리 버스 또는 메모리 컨트롤러, 주변 장치 버스, AGP(accelerated graphics port), 및 각종의 버스 아키텍처 중 임의의 것을 사용하는 프로세서 또는 로컬 버스를 비롯한, 임의의 종류의 버스 구조 또는 버스 구조들의 조합을 사용하여 구현될 수 있다.

컴퓨터(1502)는 또한 각종 유형의 휘발성 및 비휘발성 매체(이들 각각은 이동식 또는 비이동식일 수 있음)를 비롯한 각종의 컴퓨터 판독가능 매체도 포함할 수 있다. 예를 들어, 시스템 메모리(1508)는 랜덤 액세스 메모리(RAM)(1512) 등의 휘발성 메모리 및 판독 전용 메모리(ROM)(1514) 등의 비휘발성 메모리 형태의 컴퓨터 판독가능 매체를 포함한다. ROM(1514)은 시동 중과 같은 때에 컴퓨터(1502) 내의 구성요소들 간의 정보 전송을 돕는 기본적인 루틴을 포함하는 입/출력 시스템(BIOS)(1516)을 포함한다. RAM(1512)은 통상적으로 처리 장치(1506)에 의해 신속하게 액세스될 수 있는 형태로 데이터 및/또는 프로그램 모듈을 포함한다.

다른 종류의 컴퓨터 저장 매체로는 비이동식, 비휘발성 자기 매체로부터 판독을 하고 그에 기록을 하는 하드 디스크 드라이브(1518), 이동식, 비휘발성 자기 디스크(1522)(예를 들어, "플로피 디스크")로부터 판독을 하고 그에 기록을 하는 자기 디스크 드라이브(1520), 및 CD-ROM, DVD-ROM, 기타 광 매체 등의 이동식, 비휘발성 광 디스크(1526)로부터 판독을 하고 및/또는 그에 기록을 하는 광 디스크 드라이브(1524)가 있다. 하드 디스크 드라이브(1518), 자기 디스크 드라이브(1520) 및 광 디스크 드라이브(1524)는 각각 하나 이상의 데이터 매체 인터페이스(1528)에 의해 시스템 버스(1510)에 연결되어 있다. 다른 대안으로서, 하드 디스크 드라이브(1518), 자기 디스크 드라이브(1520) 및 광 디스크 드라이브(1524)는 SCSI 인터페이스(도시 생략) 또는 기타 연결 메카니즘에 의해 시스템 버스(1510)에 연결될 수 있다. 비록 도시되어 있지는 않지만, 컴퓨터(1502)는 자기 카세트 또는 기타 자기 저장 장치, 플래쉬 메모리 카드, CD-ROM, DVD(digital versatile disk) 또는 기타 광 저장 장치, 전기적 소거가능 프로그램가능 판독 전용 메모리(EEPROM), 기타 등등의 다른 유형의 컴퓨터 판독가능 매체를 포함할 수 있다.

일반적으로, 상기한 컴퓨터 판독가능 매체는 컴퓨터(1502)에서 사용하기 위한 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈, 및 기타 데이터의 비휘발성 저장을 제공한다. 예를 들어, 판독가능 매체는 운영 체제(1530), 애플리케이션-관련 기능(1532), 기타 프로그램 모듈(1534) 및 프로그램 데이터(1536)를 저장할 수 있다.

컴퓨터 환경(1500)은 각종의 입력 장치를 포함할 수 있다. 예를 들어, 컴퓨터 환경(1500)은 명령 및 정보를 컴퓨터(1502)에 입력하기 위한 키보드(1538) 및 포인팅 장치(1540)(예를 들어, "마우스")를 포함한다. 컴퓨터 환경(1500)은 마이크, 조이스틱, 게임 패드, 위성 안테나, 직렬 포트, 스캐너, 카드 판독 장치, 디지털 또는 비디오 카메라, 기타 등등의 기타 입력 장치들(도시 생략)을 포함할 수 있다. 입/출력 인터페이스(1542)는 입력 장치를 처리 장치(1506)에 연결시킨다. 보다 일반적으로 말하면, 입력 장치는 병렬 포트, 직렬 포트, 게임 포트, USB(universal serial bus) 포트, 기타 등등의 임의의 종류의 인터페이스 및 버스 구조를 통해 컴퓨터(1502)에 연결될 수 있다.

컴퓨터 환경(1500)은 또한 디스플레이 장치(1504)도 포함한다. 비디오 어댑터(1544)는 디스플레이 장치(1504)를 버스(1510)에 연결시킨다. 디스플레이 장 치(1504)에 부가하여, 컴퓨터 환경(1500)은 스피커(도시 생략), 프린터(도시 생략), 기타 등등의 기타 출력 주변 장치를 포함할 수 있다.

컴퓨터(1502)는 원격 컴퓨팅 장치(1546) 등의 하나 이상의 원격 컴퓨터로의 논리적 접속을 사용하여 네트워크화된 환경에서 동작한다. 원격 컴퓨팅 장치(1546)는 범용 퍼스널 컴퓨터, 휴대용 컴퓨터, 서버, 기타 등등을 비롯한 임의의 종류의 컴퓨터 장비를 포함할 수 있다. 원격 컴퓨팅 장치(1546)는 컴퓨터(1502)와 관련하여 상기한 특징들 전부 또는 그의 어떤 서브셋을 포함할 수 있다.

컴퓨터(1502)를 원격 컴퓨팅 장치(1546)와 연결시키기 위해 도 4의 WAN(402), LAN, 기타 등등의 임의의 유형의 네트워크(1548)가 사용될 수 있다. 컴퓨터(1502)는 광대역 접속, 모뎀 접속, DSL 접속, 또는 기타 접속 전략을 이용할 수 있는 네트워크 인터페이스(1550)(예를 들어, 도 4에 도시된 인터페이스(416))를 통해 네트워크(1548)에 연결된다. 비록 도시되어 있지는 않지만, 컴퓨팅 환경(1500)은 (예를 들어, 변조된 무선 신호, 변조된 적외선 신호, 기타 등등을 통해) 컴퓨터(1502)를 원격 컴퓨팅 장치(1546)와 연결시키기 위한 무선 통신 기능을 제공할 수 있다.

비록 본 발명이 구조적 특징 및/또는 방법적 동작과 관련한 언어로 기술되어 있지만, 첨부된 청구항들에 정의된 본 발명이 반드시 기술된 특정의 특징 또는 동작으로 제한되는 것은 아니라는 것을 잘 알 것이다. 오히려, 특정의 특징 및 동작은 청구된 발명을 구현하는 예시적인 형태로서 기술된 것이다.

Claims (20)

1. 제1 장치를 사용하여 목표 주소(target address)와 연관된 제2 장치에 컨텐츠를 전송하는 방법으로서,

   인터페이스 제공자가, 상기 제1 장치에 표시된 기본 사용자 인터페이스 내의 정보 아이템과 연관된 컨텐츠 전송 아이콘이 활성화되는 것에 응답하여 컨텐츠 전달 사용자 인터페이스를 호출하는 단계 - 상기 기본 사용자 인터페이스는 기본 사용자 인터페이스 애플리케이션에 의해 제공됨 - ,

   상기 인터페이스 제공자가, 상기 컨텐츠 전송 아이콘의 활성화에 응답하여, 상기 기본 사용자 인터페이스 애플리케이션으로부터 적어도 하나의 파라미터를 수신하는 단계 - 상기 적어도 하나의 파라미터는 상기 기본 사용자 인터페이스 애플리케이션을 식별하기 위한 애플리케이션 정보, 상기 기본 사용자 인터페이스 애플리케이션 내에서 시나리오를 식별하기 위한 애플리케이션 시나리오 정보, 상기 목표 주소와 연관된 위치를 식별하기 위한 위치 정보, 및 상기 기본 사용자 인터페이스 애플리케이션을 제공하는 엔티티를 식별하기 위한 파트너 정보 중 하나 이상을 포함함 - ,

   상기 인터페이스 제공자가, 상기 적어도 하나의 파라미터에 기초하여 컨텐츠 전달 사용자 인터페이스를 커스터마이즈하는 단계,

   상기 인터페이스 제공자가, 상기 커스터마이즈된 컨텐츠 전달 사용자 인터페이스를 상기 제1 장치에 전송하는 단계,

   상기 인터페이스 제공자가, 상기 제1 장치로부터 요청 정보를 수신하는 단계 - 상기 요청 정보는 상기 기본 사용자 인터페이스와 함께 표시되는 상기 커스터마이즈된 컨텐츠 전달 사용자 인터페이스를 통해 입력되는 정보 및 상기 목표 주소를 포함함 - , 및

   상기 인터페이스 제공자가, 상기 요청 정보에 기초하여 상기 정보 아이템과 연관된 컨텐츠를 상기 제2 장치에 송신함에 있어서 사용되는 메시지를 작성하기 위해 상기 요청 정보를 요청 처리 기능(RPF)으로 송신하는 단계

   를 포함하는 방법.
2. 제1항에 있어서,

   상기 제1 장치는 컴퓨터이고 상기 제2 장치는 모바일 전화인

   방법.
3. 제1항에 있어서,

   상기 요청 정보는 상기 목표 주소와 연관된 전화 번호를 지정하는

   방법.
4. 제1항에 있어서,

   상기 요청 처리 기능이, URL 및 텍스트 컨텐츠에 기초하여 상기 메시지를 작성하는 것을 포함하는

   방법.
5. 제1항에 있어서,

   상기 요청 처리 기능이, 상기 메시지를 상기 목표 주소로 전달하기 위한 프로토콜을 결정하는 단계, 및

   상기 요청 처리 기능이, 상기 프로토콜을 사용하여 상기 메시지를 상기 목표 주소로 전달하는 단계

   를 더 포함하는 방법.
6. 제1항에 있어서,

   상기 요청 처리 기능이, 상기 메시지를 상기 목표 주소로 전달하기 위한 형식(format)을 결정하는 단계, 및

   상기 요청 처리 기능이, 상기 형식을 사용하여 상기 메시지를 상기 목표 주소로 전달하는 단계

   를 더 포함하는 방법.
7. 제1항에 있어서,

   상기 컨텐츠는 복수의 컨텐츠 유형(content type) 중 하나 이상을 포함하고, 상기 복수의 컨텐츠 유형은 검색 결과, 지도, 이미지, 오디오 정보, 구성 정보(configuration information)를 포함하는

   방법.
8. 제1항의 방법을 구현하는 기계-실행가능 명령어들을 포함하는 하나 이상의 컴퓨터 판독가능 매체.
9. 목표 주소로 컨텐츠를 전송하기 위한 시스템으로서,

   제1 장치와,

   상기 목표 주소와 연관된 제2 장치와,

   하나 이상의 저장 매체를 포함하되,

   상기 하나 이상의 저장 매체는

   상기 제1 장치에 표시되는 기본 사용자 인터페이스를 제공하기 위한 기본 사용자 인터페이스 애플리케이션,

   상기 기본 사용자 인터페이스와 함께 상기 제1 장치에 표시되는, 커스터마이즈된 컨텐츠 전달 사용자 인터페이스를 제공하기 위한 인터페이스 제공자, 및

   요청 정보를 처리하기 위한 요청 처리 기능 - 상기 요청 정보는 상기 기본 사용자 인터페이스와 함께 표시되는 상기 커스터마이즈된 컨텐츠 전달 사용자 인터페이스를 통해 입력되는 정보 및 상기 목표 주소를 포함함 -

   을 포함하고,

   상기 인터페이스 제공자는, 상기 기본 사용자 인터페이스 내의 정보 아이템과 연관된 컨텐츠 전송 아이콘이 활성화되는 것에 응답하여 컨텐츠 전달 사용자 인터페이스를 호출하고 상기 기본 사용자 인터페이스 애플리케이션으로부터 적어도 하나의 파라미터를 수신하며, 상기 적어도 하나의 파라미터에 기초하여 컨텐츠 전달 사용자 인터페이스를 커스터마이즈하고, 상기 커스터마이즈된 컨텐츠 전달 사용자 인터페이스를 상기 제1 장치에 전송하며, 상기 커스터마이즈된 컨텐츠 전달 사용자 인터페이스를 통해 상기 제1 장치로부터 상기 요청 정보를 수신하고, 상기 요청 정보를 상기 요청 처리 기능으로 송신하도록 구성되며,

   상기 요청 처리 기능은, 상기 요청 정보에 기초하여 상기 정보 아이템과 연관된 컨텐츠를 상기 제2 장치에 송신함에 있어서 사용되는 메시지를 작성하도록 구성되고,

   상기 적어도 하나의 파라미터는 상기 기본 사용자 인터페이스 애플리케이션을 식별하기 위한 애플리케이션 정보, 상기 기본 사용자 인터페이스 애플리케이션 내에서 시나리오를 식별하기 위한 애플리케이션 시나리오 정보, 상기 목표 주소와 연관된 위치를 식별하기 위한 위치 정보, 및 상기 기본 사용자 인터페이스 애플리케이션을 제공하는 엔티티를 식별하기 위한 파트너 정보 중 하나 이상을 포함하는

   시스템.
10. 제9항에 있어서,

    상기 제1 장치는 컴퓨터이고 상기 제2 장치는 모바일 전화인

    시스템.
11. 컨텐츠를 목표 주소로 전송하는 시스템으로서,

    전송될 컨텐츠에 대한 액세스를 가지는 소스 장치 - 상기 컨텐츠는 복수의 유형 중 적어도 하나이고, 상기 복수의 유형은 검색 결과, 지도, 이미지, 오디오 정보, 구성 정보를 포함함 - ,

    목표 주소와 연관된 목표 장치,

    하나 이상의 저장 매체를 포함하되,

    상기 하나 이상의 저장 매체는

    상기 소스 장치에 표시되는 기본 사용자 인터페이스를 제공하는 기본 사용자 인터페이스 애플리케이션 - 상기 기본 사용자 인터페이스는 상기 소스 장치상의 복수의 애플리케이션에 의해 액세스가능함 - ,

    상기 기본 사용자 인터페이스와 함께 상기 소스 장치에 표시되는, 커스터마이즈된 컨텐츠 전달 사용자 인터페이스를 제공하는 인터페이스 제공자 - 상기 컨텐츠 전달 사용자 인터페이스는 상기 소스 장치상의 복수의 애플리케이션으로부터 복수의 컨텐츠 유형을 입력으로서 수신할 수 있음 - ,

    요청 정보를 수신하고 상기 인터페이스 제공자로부터 수신받은 컨텐츠를 상기 목표 장치에 수신가능한 형식으로 상기 목표 장치에 전달하는 요청 처리 제공자 - 상기 요청 정보는 상기 커스터마이즈된 컨텐츠 전달 사용자 인터페이스를 통해 입력되는 정보 및 상기 목표 주소를 포함함 - ,

    를 포함하고,

    상기 인터페이스 제공자는, 상기 기본 사용자 인터페이스 내의 정보 아이템과 연관된 컨텐츠 전송 아이콘이 활성화되는 것에 응답하여 컨텐츠 전달 사용자 인터페이스를 호출하고 상기 기본 사용자 인터페이스 애플리케이션으로부터 적어도 하나의 파라미터를 수신하며, 상기 적어도 하나의 파라미터에 기초하여 컨텐츠 전달 사용자 인터페이스를 커스터마이즈하고, 상기 커스터마이즈된 컨텐츠 전달 사용자 인터페이스를 상기 소스 장치에 전송하며, 상기 커스터마이즈된 컨텐츠 전달 사용자 인터페이스를 통해 상기 소스 장치로부터 상기 요청 정보를 수신하고, 상기 요청 정보를 상기 요청 처리 제공자로 송신하도록 구성되며,

    상기 요청 처리 제공자는, 상기 요청 정보에 기초하여 상기 정보 아이템과 연관된 컨텐츠를 상기 목표 장치에 송신함에 있어서 사용되는 메시지를 작성하도록 구성되고,

    상기 적어도 하나의 파라미터는 상기 기본 사용자 인터페이스 애플리케이션을 식별하기 위한 애플리케이션 정보, 상기 기본 사용자 인터페이스 애플리케이션 내에서 시나리오를 식별하기 위한 애플리케이션 시나리오 정보, 상기 목표 주소와 연관된 위치를 식별하기 위한 위치 정보, 및 상기 기본 사용자 인터페이스 애플리케이션을 제공하는 엔티티를 식별하기 위한 파트너 정보 중 하나 이상을 포함하는

    시스템.
12. 삭제
13. 삭제
14. 삭제
15. 삭제
16. 삭제
17. 삭제
18. 삭제
19. 삭제
20. 삭제

Images