KR20100016604A

KR20100016604A - 컨테이너 문서 내의 통신 제어

Info

Publication number: KR20100016604A
Application number: KR1020097023910A
Authority: KR
Inventors: 미하엘 뷔르게; 베른하르트 제펠드
Original assignee: 구글 인코포레이티드
Priority date: 2007-04-18
Filing date: 2008-04-17
Publication date: 2010-02-12
Also published as: WO2008131104A1; US7958516B2; EP2149078A4; US20080263566A1; AU2008242904B2; DE202008018623U1; KR101059452B1; AU2008242904A1; EP2149078A1

Abstract

시스템은 컨테이너 문서 내에서 등의, 서로 상이한 도메인과 연관된 모듈들이 통신할 수 있게한다. 제 1 도메인과 연관된 제 1 모듈의 페이로드 데이터를 상이한 도메인과 연관된 제 2 모듈로 전송하기 위해, 제 1 모듈은 상기 페이로드 데이터를 제 2 도메인과 연관된 전송모듈 URL에 텍스트 스트링(text string)으로서 부가한다. 이러한 방법으로, 제 2 모듈은 수정된 전송모듈에 직접 억세스하여 그것의 URL의 페이로드 데이터를 획득할 수 있다. 이와 유사하게, 제 2 모듈은 제 1 도메인과 연관된 다른 전송모듈의 URL에 다른 페이로드 데이터를 텍스트 스트링으로서 부가할 수 있고, 이에 따라, 제 2 도메인으로부터 제 1 메인으로의 통신을 가능하게 할 수 있다.

컨테이너 문서, 도메인, 페이로드(payload), URL

Description

컨테이너 문서 내의 통신 제어{CONTROLLING COMMUNICATION WITHIN A CONTAINER DOCUMENT}

본 발명은 일반적으로 컨테이너 문서 내의 통신 제어에 관한 것이다.

대다수의 브라우저는 한 도메인 상에 호스팅된 코드가, 다른 도메인 상에 호스팅된 코드에 억세스하지 못하게 한다. 어떤 문서가 한 도메인 상에 호스팅되고 나서 다른 도메인 상에 호스팅된 컨텐츠를 참조하는 경우, 보통 그 문서는 다른 도메인 상의 컨텐츠와 통신하거나 억세스하는 것이 거부된다. 이러한 상황은 포털 웹페이지, 예를 들면, 사용자가 도시 안내 도메인(city guide domain)에 의해 호스팅된 프레임의 레스토랑을 선택한 후, 그 선택된 레스토랑까지의 경로를 맵핑 도메인(mapping domain)에 의해 호스팅된 프레임에서 생성되도록 설계된 포털 웹페이지에서 발생할 수 있다. 상이한 도메인들에 의해 호스팅된 프레임들간의 통신은, 보안상의 제한이라는 일부 원인과 기존 브라우저 프로그램의 한계라는 여타의 원인에 의해 일반적으로 허용되지 않고 있다.

서로 상이한 도메인과 연관된 모듈들(컨테이너 문서 내에서 제공된 경우 등) 사이의 통신을 가능하게 하기 위해, 본 발명의 여러가지 실시예들은 기존 브라우저 프로그램의 한계를 극복하기 위한 메커니즘을 제공한다. 시스템은 컨테이너 문서 내에서 등과 같이, 서로 상이한 도메인과 연관된 모듈들이 통신할 수 있게 한다. 제 1 도메인과 연관된 제 1 모듈의 페이로드 데이터를 상이한 도메인과 연관된 제 2 모듈로 전송하기 위해, 제 1 모듈은 상기 페이로드 데이터를 제 2 도메인과 연관된 전송모듈 URL에 텍스트 스트링(text string)으로서 부가한다. 이러한 방법으로, 제 2 모듈은 수정된 전송모듈에 직접 억세스하여 그것의 URL의 페이로드 데이터를 획득할 수 있다. 이와 유사하게, 제 2 모듈은 제 1 도메인과 연관된 다른 전송모듈의 URL에 다른 페이로드 데이터를 텍스트 스트링으로서 부가할 수 있고, 이에 따라, 제 2 도메인으로부터 제 1 도메인으로의 통신을 가능하게 할 수 있다.

일 실시예에서, 제 1 및 제 2 모듈은 웹 포털을 실행할 수 있는 컨테이너 문서(container document) 내에 담긴 인라인 프레임들(inline frames: IFRAMES)을 생성한다. 또한, 각 전송 프레임은 컨테이너 문서내에 숨겨진 빈(empty) IFRAME일 수도 있다.

다른 실시예에서, 제 2 모듈은 전송모듈을 폴링하여 제 2 모듈로 전송되었는지 여부를 판정한다. 이러한 폴링은 주기적으로 또는 알고리즘에 따라 결정된 기타의 방법으로 수행될 수 있다. 이러한 관점에서, 데이터 전송 메커니즘은 비동기 통신일 수 있다.

이점으로서, 전송모듈의 URL을 통한 페이로드 데이터 통신을 행하는 것은, 그 통신이 브라우저 프로그램 및 모듈들이 실행되는 클라이언트 장치에서 전적으로 일어날 수 있으므로, 응답 서버들 사이에 통신을 필요로 하지 않는 크로스 도메인 통신(cross-domain communication)을 가능하게 할 수 있다.

도 1은 본 발명의 실시예에 따른, 컨테이너 문서를 통해 사용자에게 컨텐츠를 제공하는 전체 컨테이너 문서 시스템 구조의 블럭도.

도 2는 본 발명의 실시예에 따른 컨테이너 문서를 예시적으로 나타낸 도면.

도 3은 본 발명의 실시예에 따른, 기능모듈들과 전송모듈들을 포함하는 컨테이너 문서를 나타낸 도면.

도 4는 본 발명의 실시예에 따른, 도 3의 컨테이너 문서 내의, 서로 상이한 도메인에 연관된 모듈들간의 통신을 위한 프로세스의 상호작용도.

이하, 본 발명의 실시예들을 상세하게 검토한다. 특정한 실시예가 검토되겠지만, 이는 설명의 목적만을 위한 것임을 이해할 수 있을 것이다. 당업자라면 본 발명의 사상 및 범위를 일탈하지 않는 범위 내에서 다른 요소 및 구성을 사용할 수 있음을 인식할 것이다. 본 발명의 여러가지 실시예들은 컨테이너 문서 내의 통신 제어에 관한 것이다.

실시예의 사용을 위한 예시적인 컨테이너 문서 환경

컨테이너 문서는 일례로서, 개인용 포털 사이트에 접속된 컨테이너 문서일 수 있다. 개인용 포털 사이트(예를 들어, My Yahoo!, start.com 또는 Google Personalized Homepage)는 사용자가 컨텐츠(예를 들어, 인터랙티브(interactive), 읽기 전용, 업데이팅, 데이터 공급 등)를 선택하는 것만으로 개인용 페이 지(personalized page) 상에 신규 이메일 알림, 현재 날씨 및/또는 교통 상태, 영화 시간표, 호로스코프(horoscope) 등을 디스플레이하게 할 수 있게 한다. 본 발명의 일 실시예에 따르면, 모듈 사용의 실례는 컨테이너에 포함되기 위해 개발된(예를 들면, 제3의 개발자에 의한) 모듈들과 함께 개인용 포털 페이지(컨테이너 문서의 일례)에 추가될 수 있는 모듈을 포함할 수 있다.

따라서, 본 명세서에서는 예시적 목적으로 컨테이너 문서 또는 모듈을 설명하겠지만, 다양한 실시예들이 다른 콘텍스트(context) 내의 접속에 채용될 수도 있다. 또한, 모듈에 관한 상세한 설명은 동시계속(co-pending) 출원되어 통상적으로 할당된 4개의 특허출원의 상세한 설명에 제공되어 있으며, 본 명세서에서는 그들 4개의 특허출원 전체를 참조하는 것에 의해 통합하도록 한다. 상기 특허출원은, 미국 특허출원번호 제11/298,930호(2005년 12월 12일, "Remote Module Incorporation into a Container Document)"와, 미국 특허출원번호 제11/298,922호(2005년 12월 12일, "Module Specification for a Module to be Incorporated into a Container Document")와, 미국 특허출원번호 제11/298,987호(2005년 12월 12일, "Customized Container Document Modules Using Preferences")와, 미국 특허출원번호 제11/298,988호(2005년 12월 12일, "Proxy Server Data Collection")이다. 상기 특허출원에는 그 상세한 기술이 설명되어 있으며, 다음의 설명에 의해 그러한 시스템을 전반적으로 이해할 수 있을 것이다.

본 시스템은 다수의 구성요소를 포함할 수 있다. 본 시스템은 컨테이너 문서(예를 들면, 개인용 페이지(personalized page))를 제공하는 컨테이너 서버를 포 함할 수 있다. 컨테이너 문서는 하나 이상의 원격 모듈을 포함하는, 하나 이상의 모듈을 "담고 있다". 여기에 사용되는 용어, "컨테이너 문서" 또는 "컨테이너"는 웹사이트의 개인용 홈페이지, 사이드바, 하나 이상의 그러한 모듈들을 통합하는 툴바 구성, 사이트에 의해 호스팅된 페이지, 모듈(예를 들면, XML)의 포맷에서 모듈들을 렌더링할 수 있는 문서(예를 들면, HTML 코드 또는 XML 코드를 렌더링할 수 있는 문서)를 포함하는 것으로 이해되어야 한다. 또한, 컨테이너는 신디케이션 시스템(syndication system)을 통해 모듈이 제공될 때, 그러한 모듈을 통합하는 다른 주체의 웹사이트일 수 있다.

여기에 사용되는 용어, "모듈"은 컨테이너 문서 내에서의 사용을 위해 데이터를 렌더링하는 소프트웨어 및/또는 하드웨어의 일부를 말하는 것으로 이해될 수 있다. 모듈은 사용자 프리퍼런스(preference), 컨테이너의 프리퍼런스, 환경 또는 다른 입력의 프리퍼런스로 개인화될 수 있다. 바람직한 실시예에서, 다양한 모듈들은 컨테이너 문서의 뷰어에게 보여지거나 보여지지 않을 수 있다. 모듈 사양서(module specification)는 미리 정의된 요소(elements)를 사용하여 컨테이너 문서용 데이터를 렌더링하도록 사용된 일련의 명령들을 포함하는 것으로 이해될 수 있다.

개요 및 컨테이너 문서 시스템의 시스템 구조

도 1은 본 발명의 일 실시예에 따른 통신 구현이 채용될 수 있는 전체 시스템도를 나타낸다. 도시된 바와 같이, 도 1은 자신과 연관될 수 있는 다수의 모듈을 구비한 호스트 서버 시스템(10)을 포함할 수 있다. 이러한 모듈은 컨테이너 서 버(12), 모듈 서버(14), 사양 서버(16), 백엔드 서버(back end server)(18), 분석 모듈(28), 모듈 생성 서버(32), 신디케이션 서버(syndication server)(34), 광고 서버(36), 지오코드 서버(geocode server)(37), 및 맵 서버(39)를 포함할 수 있다. 도시된 바와 같이, 개인용 컨테이너 서버(10)는 네트워크(26)를 통하여 다수의 시스템에 접속할 수 있다.

네트워크에 접속된 다른 시스템은 하나 이상의 사용자 시스템(22), 하나 이상의 원격 소스 시스템(24), 하나 이상의 모듈 개발자 시스템(30), 하나 이상의 신디케이션 수신인 서버(38)를 포함할 수 있다. 또한, 하나 이상의 데이터베이스 시스템(20)은 호스트 서버 시스템(10)의 다양한 모듈과 연동할 수 있다.

컨테이너 서버(12)는 네트워크(26)를 통하여 컨테이너 문서를 사용자 시스템(22)에 제공할 수 있다. 컨테이너 서버(12)는 데이터 및/또는 명령을 수용하고 네트워크를 통해 사용자 시스템(22)에 전송하기 위한 컨테이너를 형성하는 웹 서버 또는 관련 서버 시스템을 포함할 수 있다. 그러나, 컨테이너 서버(12)는 네트워크 접속을 사용하지 않고 사용자 시스템(22)에 상주할 수도 있음을 고려해야 한다. 예를 들면, 컨테이너 문서가 워드 프로세싱 문서를 포함하는 일례에서는, 컨테이너 서버(12)가 워드 프로세싱 모듈을 포함할 수 있다.

모듈 서버(14)는 컨테이너 문서 내로 편입하기 위하여, 모듈들의 데이터를 컨테이너 서버(12)에 제공할 수 있다. 일 실시예에서, 컨테이너 서버(12) 및 모듈 서버(14)는 양쪽 모두의 기능을 수행하는 단일 유닛을 포함할 수 있다. 모듈 서버(14)는 모듈과 연관된 모듈 사양서(module specification) 내의 명령을 해석 및/ 또는 파싱(parsing)함으로써 컨테이너 문서에 데이터를 제공할 수 있다. 일 실시예에 따라, 모듈 서버(14)는 브라우저 인라인 프레임(IFRAME)을 사용하여 컨테이너 문서에 모듈 컨텐츠를 제공할 수 있다. IFRAME은 일반적으로 컨테이너 문서 내에서 독립적으로 동작되는 브라우저 윈도우 인스턴스(instance)로 이해될 수 있다. IFRAME의 한 잇점은 IFRAME의 컨텐츠로부터 컨테이너 문서를 보호하고 그 역도 가능하다는 것이고, 예를 들면, 컨테이너 문서상의 JavaScript는 내부 IFRAME(CSS, DOM, 또는 쿠키 객체에 대해서도 동일함)의 임의의 JavaScript 코드에 억세스하는 것이 허용되지 않을 수 있다. 바람직한 실시예에서, 이러한 내부 IFRAME에서 임의 JavaScript 코드에의 접근 허용 실패는 브라우저 보안 설정에 따른 결과일 수 있다.

컨테이너 문서의 디스플레이를 촉진시키기 위해서, 모듈들은 컨테이너 문서 내에서 인라인(inline)으로 디스플레이될 수 있다. 인라인 디스플레이(inline display)는 다른 문서 요소와 함께 디스플레이되는 것을 지칭하는 것으로 이해될 수 있다. 일례로 HTML 기준에 따른 바디(body)에 HTML용 코드로부터 발생된 디스플레이가 있다. 일 실시예에서, 모듈 서버(14) 또는 일부 다른 구성요소는 인라인 모듈이 생성할 수 있는 다양한 보안 이슈의 위험 때문에, 컨테이너 문서 내에 모듈을 인라인으로 포함하기 전에 그 모듈을 신뢰하는 것으로 간주할 지 여부를 판정할 수 있다. 일 실시예에 따르면, 모듈은 컨테이너 모듈 또는 아래에 상세하게 기술된 바와 같은 컨테이너 모듈과 연관된 실체에 의해 발행된 승인의 증표(indicia)(예를 들면, 디지털 식별)를 포함할 수 있다. 승인의 증표가 존재하면, 모듈 서버(14)는 컨테이너 문서 내의 인라인 제출용 모듈로부터의 데이터를 렌더링할 수 있다.

사양 서버(16)는 모듈 서버(14)에게 모듈 사양 파일(module specification file)을 제공한다. 모듈 사양(module specification)은 모듈 서버(14) 및/또는 사양 서버(16)에 접근가능한 데이터베이스 내에 캐싱(cache)되거나 저장될 수 있으며, 또는 후에 상세히 설명되는 바와 같은 사양과 연관된 위치로부터 검색될 수 있다. 예를 들면, 사양 서버(16)는 원격 소스 시스템(24) 상에 상주할 수 있다. 또한, 사양 서버(16)는 사양 서버(16)에 접근가능한 네트워크상의 다른 위치에 위치된 모듈 사양을 이용하여 네트워크를 통해 모듈 서버에 접속될 수 있다.

백엔드 서버(18)는 하나 이상의 데이터베이스(예를 들면, 정보가 크거나 동적인 데이터베이스)와 상호작용하기 위해 제공될 수 있다. 예를 들면, 빈번한 업데이트를 획득하여 데이터의 플로우(예를 들어, RSS 피드로부터)를 요구하는 뉴스 모듈을 위하여, 백엔드 서버(18)는 데이터를 컨테이너용 HTML로 포맷할 수 있다.

하나의 구체예로서, 개인은 기존의 맵핑 프로그램에 어플리케이션 프로그램 인터페이스(Application Program Interface; API)를 사용하여 캘리포니아의 마운틴 뷰 도시의 지도를 디스플레이하도록 하는 모듈을 생성하는 것 같이, 모듈(예를 들면, 맵 모듈)을 생성할 수 있다. 모듈은 사양 서버에 저장된 XML 사양 파일 또는 모듈 사양 파일을 포함할 수 있다. 사양 서버는 컨테이너 페이지를 호스팅하는 사이트 또는 임의의 다른 사이트상에서의 서버를 포함하는 임의의 서버를 포함할 수 있다. 또한, 사용자 또는 다른 개인은 이러한 새로운 모듈을 개인용 홈페이지(컨테이너 문서) 상에 포함할 수 있다. 컨테이너 문서를 공급하는 서버는 모듈 서버로서 동작할 수 있고, 그것의 API로부터의 질의를 통하여 맵핑 데이터를 생성하는 서버는 백엔드 서버로 간주될 수 있다.

본 발명의 일 실시예에 따라, 분석 모듈(28)은 다양한 시점(예를 들면, 모듈이 사용자에 의해 처음으로 선택될 때, 모듈이 포함되기 위해 컨테이너에 의해 호출되는 각 시점, 또는 안전과 보안을 위해 바람직하다고 결정되는 임의의 시점 및 다른 시점들)에서 모듈을 분석할 수 있다. 분석 모듈(28)은 그 모듈을, 비승인되거나 위험한 모듈들의 목록 또는 승인된 모듈들의 목록과 비교하는 것을 포함하는, 다수의 동작들을 수행할 수 있다. 비교는 이름 또는 위치(예를 들면, URL), 사양의 컨텐츠, 그 사양이 존재하는 위치의 컨텐츠, 또는 그 모듈에 대해 확인가능한 정보에 의한 정확한 매칭 또는 서브스트링(substring)(예를 들면, 접두사, 접미사 및 통상의 표현) 매칭을 포함할 수 있다. 분석 모듈(28)은 모듈이 비승인되거나 위험하다는 판정에 응답하여 하나 이상의 동작들을 취할 수 있고, 이 동작들은 예를 들면, 그 요청(request)을 아무런 설명없이 차단하는 것(즉, 일반적 에러를 제공함), 그 요청을 그것이 차단되는 이유를 설명하는 에러와 함께 차단하는 것, 또는 그 요청을 안전한 것으로 판정되고 비승인된 모듈과 관련된 별개의 다른 모듈 사양(예를 들면, 만약 처음의 것이 비승인된 맵핑 사이트라면, 맵과 관련된 다른 모듈, 만약 비승인된 모듈이 농구 모듈이었다면 키워드 "농구"를 포함하는 모듈)로 재지향(redirecting) 하는 것을 포함한다. 예를 들면, 재지향을 통해 오리지널 모듈의 URL은 "안전한" 모듈로 보내질 수 있다. 또한, 안전한 모듈은 아래에서 설명하는 바와 같이, 오리지널 URL의 컨텐츠를 검색하기 위해 프락시 서버를 사용할 수 있 다. 또한, 개발자는 에러 처리자(error handler)를 대체하여 오리지널 모듈의 작은 버그를 수리함으로써, 오리지널 모듈의 컨텐츠를 디스플레이할 수 있다. 다른 실시예에서, 분석 모듈(28)은 모듈에 포함된 JavaScript 또는 다른 스크립트를 컴파일링하여 그 모듈이 수행할 수 있는 안전하지 않은 동작들 또는 바람직하지 않은 동작들을 식별하도록 시도하는 등으로 모듈 컨텐츠가 안전한지 여부를 판정하기 위하여, 모듈 컨텐츠를 파싱할 수 있다.

하나 이상의 모듈 생성 서버(32)가 제공될 수 있다. 이 서버는 모듈 크리에이터들(module creators)이 모듈 생성 서버(32)에 의해 제어되는 인터랙티브 프로세스(interactive process)를 통해 모듈을 생성할 수 있도록 "위저드(wizard)"로서 동작할 수 있다. 예를 들면, 모듈 생성 서버(32)는 모듈 크리에이터로 하여금 입력을 제공할 수 있도록 상기 모듈 크리에이터에 의해 사용되어 자동으로 모듈 사양을 생성하는 일련의 사용자 인터페이스를 제공한다. 예를 들면, 다양한 모듈 사양 템플릿이 대응하는 입력을 제공받을 수 있다. 또한, 모듈 생성 서버(32)는 모듈 크리에이터에 의해 공급된 입력을 받고, 그들을 템플릿에 삽입한 다음, 그 모듈에 대한 모듈 사양을 생성할 수 있다. 또한 미리 보기, 테스팅 및 디버깅 기능이 이 "위저드(wizard)"의 일부로서 제공될 수 있다. 이러한 모듈은 네트워크 상의 임의의 노드에 설치되어 동작될 수 있고, 다운로드 될 수도 있다.

신디케이션 서버(34)는 모듈과 관련된 하나 이상의 신디케이션 수신인 서버(38)에 전송하기 위한 데이터를 준비할 수 있다. 신디케이션 서버(34)는 모듈 및/또는 모듈 컨텐츠에 대한 요청을 수신하고, 그러한 모듈 또는 컨텐츠를 네트워 크(26)를 통해 신디케이션 수신인 서버(38)로 전달할 수 있다. 신디케이션 서버(34)는 호스트 서버 시스템(10) 또는 네트워크 상의 다른 위치에 상주할 수 있다. 예를 들면, 만약 스포츠 웹사이트(예를 들면, 신디케이션 수신인 시스템(38))의 운영자가 원격 소스 시스템(24)에 의해 생성된 맵 모듈을 포함하길 원하면, 신디케이션 서버(34)에 대한 요청을 통해 그렇게 할 수 있다. 또한, 신디케이션 서버(34)는 모듈 서버(14)와 협력하여 컨테이너 문서(여기에서는 신디케이션 수신인 시스템(38)의 스포츠 웹사이트 페이지)를 위한 데이터를 생성할 수 있다. 그것은 원격 소스 시스템(24)으로부터 모듈 사양을 검색하고, 신디케이션 수신인 서버(38)로부터 수신된 프리퍼런스(예를 들면, 디스플레이되어 있는 페이지의 스포츠 팀에 대한 도시 정보)를 공급하고 및/또는 컨테이너를 위한 데이터를 생성하는 것을 포함할 수 있다. 또한, 그 데이터는 신디케이션 수신인 서버(38)에서 IFRAME 또는 인라인(inline) 중 어느 한쪽에 그것의 컨테이너 문서로 렌더링될 수 있다. 따라서, 신디케이션 서버(34)는 그것에 접근가능한 모듈을 신디케이팅할 수 있다. 그것은 특정 모듈에 대한 요청 또는 그것을 판정하는 다른 기준(예를 들면, 컨텐츠 일치, 키워드 일치, 모듈 및/또는 신디케이션 요청자와 관련한 금전적 가치 등)에 의거하여 이루어질 수 있다.

광고 서버(Ad server)(36)는 컨테이너에게 모듈과 연관된 광고를 제공할 수 있다. 예를 들면, 광고는 데이터가 컨테이너 문서에 전달될 때 모듈 데이터와 결합될 수 있다. 광고 서버(36)는 모듈에 대한 신디케이션 요청에 의거하여 신디케이션 수신인 서버(38)에 광고를 전달할 수 있도록 신디케이션 서버(34)와 함께 동작할 수 있다. 광고 서버(36)는 컨테이너, 모듈, 컨테이너 내의 다른 모듈, 신디케이션 수신인 서버 정보, 전술한 임의의 것과 관련된 금전적 요소/관계 및/또는 그들의 조합에 관한 정보 또는 그 컨텐츠 사이의 관계를 포함하는(그러나, 이것에 한정되는 것은 아님) 넓고 다양한 기준에 의거하여 광고를 선택할 수있다. 광고 서버(36)는 본 발명의 일 실시예에 따라, Google AdSense 시스템을 포함할 수 있다. 광고 서버(36) 본 명세서에 전체로서 참조됨으로써 그 주제가 통합된, 하나 이상의 다음과 같은 특허출원에 서술된 바와 같이 동작할 수 있다. 구체적으로, 광고 서버(36)는 본 명세서에 전체로서 참조되어 통합된, 미국 특허출원번호 제10/340,193호(2003년 1월 10일, "Pricing Across Keywords Associated with One or More Advertisements")의 전자 문서와 함께 광고를 제공하는 콘텍스트에서 논의된 방식으로, 모듈에 관한 둘 이상의 컨셉을 광고와 연관시키고, 비드를 집합적으로 둘 이상의 키워드와 연관시킴으로써 온라인 광고를 관리할 수 있다. 광고를 제시하고 광고 비용을 관리하는 부가적인 예가, 본 명세서에 전체로서 참조되어 통합된, 미국 특허출원번호 제10/340,543호(2003년 1월 10일, "Automated Price Maintenance for Use With a System in which Advertisements are Rendered with Relative Preferences") 및 미국 특허출원번호 제10/340,542호(2003년 1월 10일, "Automated Price Maintenance for Use With a System in which Advertisements are Rendered with Relative Preferences Based on Performance Information and Price Information")에 논의되어 있다.

지오코드 서버(37)는 당업계에서 잘 알려진 바와 같이 위치 기술(location descriptions)로부터 지오코드 정보를 생성하기 위해 제공될 수 있다. 지오코드 서버(37)는 지리학적 위치로부터 위도 및 경도의 수치값을 생성할 수 있다.

맵 서버(39)는 맵 출력(map output)을 생성할 수 있다. Google Maps와 Google Earth와 같은 맵핑 시스템은 이러한 데이터를 생성하기 위해 사용될 수 있다.

하나 이상의 데이터베이스 시스템(20)은 다양한 방법으로, 컨테이너 정보, 모듈 사양 및/또는 관련 정보, 포맷팅 데이터, 사용자별(per-user) 및 모듈별(per-module) 프리퍼런스 데이터, 원격 모듈 ID 데이터, 원격 모듈 위치 참조 데이터, 광고 데이터, 광고자 데이터, 컨텐츠/금전적 데이터, 신디케이션 수신인 데이터, 모듈을 위한 템플릿, 모듈을 위한 입력, 신뢰 및 비신뢰 모듈의 목록, 승인 기준 및 관련 정보 및/또는 여기서 기재된 바와 같이 동작하기 위해 모듈에 의해 사용되는 임의의 다른 정보를 저장하도록 제공될 수 있다. 단일의 데이터베이스 구조가 도시되어 있지만, 데이터는 다수의 위치에 및 하나 이상의 시스템들에 저장될 수 있음에 대해 충분히 이해할 수 있을 것이다.

도 1에는 하나의 구성이 도시되어 있지만, 당업계에서 통상적인 기술을 가진자라면 이러한 다양한 모듈의 다른 구성도 가능하다는 것을 인식해야 한다. 예를 들면, 호스트 서버 시스템(10) 내에 도시된 다양한 모듈은 네트워크(26) 주변의 다양한 위치 또는 일부 네트워크 상의 다양한 위치에 배치될 수 있다. 또한, 단일 호스트 서버 시스템(10)이 도시되어 있지만, 도 1에 도시된 각의 모듈의 일부는 네트워크(26)를 포함하여 제공될 수 있다는 것을 인식해야 한다.

일 실시예에서, 네트워크(26)는 인터넷을 포함할 수 있다. 또한, 다른 네트워크는 여러가지 시스템 및/또는 서버 각각을 접속하기 위해 사용될 수 있다.

또한, 사용자 시스템(22)으로 도시된 것은 원격 소스 시스템(24) 및/또는 모듈 개발자 시스템(30)으로서도 동작할 수 있다. 즉, 하나의 컴퓨터 시스템은, 사용자 시스템, 원격 소스 시스템, 신디케이션 서버, 타겟 컨텐츠 서버, 및/또는 모듈 개발자 시스템으로서 동작하는 것 같이, 다른 용도로 동작할 수 있다. 또한, 이하에서 더 상세히 설명된 바와 같이, 호스트 서버 시스템(10) 내에 도시된 각각의 모듈은 사용자 시스템(22), 원격 소스 시스템(24), 모듈 개발자 시스템(30)에 배치될 수도 있다. 이와 유사하게, 데이터베이스(20)는, 요구되는 구성에 따라, 도 1 내에 도시된 각 모듈과 연관될 수 있다.

모듈들을 포함하는 컨테이너 문서

본 발명의 일 실시예에 따른, 시스템 및 방법은 모듈들을 컨테이너 문서 내로 도입하기 위해 제공된다. 컨테이너 문서의 일례는, 인터넷 상의 구글 서비스 사용자가 현재 이용가능한 구글 개인용 홈페이지(Google Personalized Hompage)와 같은, 개인용 홈페이지일 수 있다. 본 발명의 하나 이상의 실시예들은, 사용자가 개인용 홈페이지 등의 컨테이너 문서에 포함할 수 있는 컨텐츠의 타입에 제한받지 않고, 컨테이너 문서의 소스 이외의 소스로부터의 모듈들을 선택할 수 있게 한다. 따라서, 예를 들면, 사용자는 그의(또는 그녀의) 개인용 구글 홈페이지 내에, 구글과 연관되지 않은 소스로부터의 모듈을 포함하도록 선택할 수 있다.

여러가지 형태의 컨테이너 문서가 존재할 수 있겠지만, 도 2에서는 설명에 도움이 될 하나의 실례를 나타내고 있다. 도 2는 컨테이너 문서 내로 도입된 복수의 모듈을 가지는 컨테이너 문서(100)를 나타낸다. IFRAME 및 인라인 HTML 기술의 이용을 포함하는, 다수의 도입 방법이 가능하다. 이하에서는, 이러한 내용을 더욱 상세하게 논의할 것이다. 도 2는 사진 원격 모듈(101), 작업 목록 모듈(102), 게임 모듈(104), 주식 모듈(105), 맵 모듈(106), 원격 모듈(108), 원격 모듈(210), 원격 모듈(312) 및 원격 모듈(114)을 포함하는 다수의 모듈을 도시하고 있다. 모듈의 크리에이터(creator)에 의해 제공되는 사양에 따라, 여러가지 모듈들에 대한 상이한 포맷들이 존재할 수 있다. 도시된 바와 같이, 일부 모듈은 스크롤바를 제공할 수 있고, 다른 모듈은 스크롤바를 제공하지 않을 수 있다. 일부 모듈은 다른 모듈과 다른 사이즈 또는 형상일 수 있다. 또한, 일부 모듈은 사용자가 디스플레이이 프리퍼런스(display preference) 및/또는 그 모듈과 연관된 사용자별 데이터(per-user data)를 편집할 기회를 제공할 수 있다(예를 들면, 편집 링크를 제공하는 모듈들(102,104,105,106,110)). 예를 들어, 만일 모듈이 맵 모듈(106)과 관련이 있다면, 사용자는 그 모듈에 맵핑된 주소(또는 주소들)을 편집할 기회를 제공받을 수 있다. 일 실시예에서, 인라인된 모듈들(inlined modules)은 컨테이너 문서에 의해 자동으로 사이즈 조절될 수 있으므로, 스크롤링, 높이 또는 스케일링 정보가 제공되지 않을 수 있다. 만일 모듈 개발자가 그 모듈이 본 실시예의 이러한 특성들을 가지길 원한다면, 인라인된 모듈은 고정 사이즈 <DIV> 태그 및 그 태그에 놓인 컨텐츠로 랩핑(wrapping)될 수 있다. 그리고 나서, 스크롤바, 높이 및 다른 특징들이 그 인라인된 컨텐츠(inlined content)에 대해 지정될 수 있다. 어트리뷰 트(attribute)들 중의 하나인 specifying scaling="..."에 의해 개발자는 컨테이너 문서 내에서 어떻게 모듈을 스케일 업 또는 다운하여 다른 사이즈의 게재(placements)를 할 것인지를 지시할 수 있다.

이러한 예시적 컨테이너 문서(100)가 제공된 기능들 중의 하나는 컨텐츠 부가 요소(103)의 선택을 통해, 컨테이너 페이지에 컨텐츠를 부가할 기회이다. "컨텐츠 부가" 요소(103)를 선택하면, 시스템은 사용자에게 컨테이너 페이지에 포함될 부가 요소를 상호작용적 방식으로 지시할 기회를 제공할 수 있다. 그러한 입력을 수신하기 위한 다양한 형태의 인터페이스가 제공될 수 있다. 도 2의 섹션(120) 내 페이지의 바닥쪽에는 설명에 도움이 될 하나의 형태가 나타나 있다. 이러한 섹션에서, 사용자는 카테고리화 구조(cartegorization structure)로 배열될 수 있는 모듈의 검색 가능한 목록으로부터 선택할 인터페이스 요소를 제시받을 수 있다. 입력 섹션(120)의 다른 섹션은 사용자가 컨테이너 문서 내로 도입될 모듈을 위한 위치 레퍼런스를 지정하는 것이 가능하게 할 수 있다. 그러한 섹션은 제출 요소(128)를 갖는 입력 박스(126)를 통해 도시된 바와 같을 수 있다. 설명에 도움이 될 하나의 실례에서, 사용자는 도입될 모듈에 관한 데이터가 존재하는 위치 레퍼런스(예를 들면, 유니폼 리소스 로케이터(Uniform Resource Locator; URL))를 지정할 수 있다. 이하에서 더욱 상세하게 설명된 바와 같이, 데이터의 일례로서는 컨테이너 문서 시스템(10) 운영자의 스크립팅 프리퍼런스(scripting preferences)를 만족시키는 XML-기반 파일이 있다.

기본 레벨에서, 그 사양은 XML 버젼 정보, 모듈 프리퍼런스(선택적일 수 있 음), 사용자 프리퍼런스(선택적일 수 있음), 컨텐츠 타입 지시자(content type designator) 및 모듈에 대해 할당된 컨테이너 부분을 차지하도록 사용된 컨텐츠 요소를 포함하는, 다수의 요소들을 포함할 수 있다. 컨텐츠는 다양한 형태의 코드(전형적으로는, 프리젠테이션용 컨테이너를 생성할 때, 사용자 시스템에 의해 해석될 수 있는 코드)로 지정될 수 있음을 인식해야 한다. 그러한 코드는 HTML, Java Script, 또는 웹 페이지의 포맷을 표시하기 위해 사용될 수 있는 다른 형태의 코드들을 포함할 수 있다.

본 발명의 다른 실시예에 따르면, 모듈 사양(module specification)은 하나 이상의 다른 파일 또는 컴퓨터 명령에 임베디드될 수 있다. 이 실시예에 따르면, 모듈 서버(14)는, 모듈 생성용 데이터를 식별한 때에 그 데이터 내부의 모듈 사양을 탐색한다.

모듈들 사이의 통신을 위한 전송 메커니즘

바람직한 실시예에 따라, IFRAME은 컨테이너 문서 내의 통신을 제어하기 위해 사용될 수 있다. 앞서 설명한 바와 같이, 모듈 컨텐츠는 컨테이너 서버의 도메인(domain)과는 별개의 도메인 상에 호스팅된 IFRAME에 제공될 수 있다. 이러한 실시예에서는, 별개의 도메인 상에 호스팅될 수 있는 IFRAME이 컨테이너 서버와 통신 및/또는 억세스하는 것을 방지하는 정책이 존재할 수 있다. 그 하나의 정책은, 예를 들면, "동일 출처 정책(Same Origin Policy)"으로 호칭될 수 있다.

다양한 시스템에서, 모듈들 및/또는 컨테이너 문서 사이의 통신이 제어될 수 있다. 예를 들면, 이러한 통신은 특정 모듈의 도메인에 억세스하는 것을 제한하거 나 통신을 시도하는 윈도우를 담는 것을 제한하도록 제어될 수 있다.

본 명세서에서 사용되는, 도메인은 단일 DNS 엔트리(예를 들면, www.google.com) 또는 관련 DNS 엔트리(베이스 네임 www.google.com을 가지는 모든 레지스트레이션) 또는 트러스트 도메인(trust domain)으로 불리는 것과 같은, 소스로 이해될 수 있다. 또한, 본 명세서에서 사용되는, 텀 모듈(term module)은 컨테이너 문서 그 자체를 참조하거나, 다른 도메인의 사용자에게 컨텐츠를 제공하는 다른 모듈을 참조할 수 있다. 따라서, 컨테이너 문서 내의 별개의 도메인들과 연관된 모듈들 사이의 통신 또는 컨테이너 문서 자체와 그 컨테이너 문서와는 별개의 도메인과 연관된 모듈 사이의 통신이 제어될 수 있다.

모듈은 컨테이너 문서 내에 제공되는 프레임을 참조할 수 있다. 바람직한 실시예에서, 컨테이너 문서 및 하나 이상의 다른 모듈들은, 예를 들면 IFRAME을 참조하는 코드를 각각 포함할 수 있다. 또한, 모듈은 파라미터를 수신하는 코드를 포함할 수도 있다. 예를 들면, 컨테이너 문서는 파라미터로서 "payload"를 수신하는 "ProcessPayload" 함수를 정의한 스크립트를 포함할 수 있다. 이러한 실시예에서, "ProcessPayload" 함수는 "payload"를 수신 및 처리하는 임의의 함수일 수 있고, 여기서 "payload"는 어떤 값을 나타낼 수 있는 문자들의 스트링 구조를 나타낸다. "ProcessPayload" 함수가 컨테이너 문서 및 임의의 다른 모듈 내에 포함될 수 있지만, "ProcessPayload" 함수는 반드시 어떤 특정 모듈 내에서 정의될 필요가 없고, 다른 장소에서 정의 및/또는 실행될 수도 있다. 또한, 바람직한 실시예에서, 이러한 함수에 의해 캡슐화된 로직(logic)은 그 함수와는 별개로 실행될 수 있다.

컨테이너 문서 내의 하나 이상의 모듈은 그 컨테이너 문서 내에 IFRAME을 구축하기 위한 스크립트(예를 들면, var iframe_1=document.createElement("IFRAME"))를 포함할 수 있다. 구축된 IFRAME은 컨테이너 문서 내에 그 모듈을 디스플레이하기 위한 모듈 컨텐츠를 포함할 수 있다. 일 실시예에서, 그 모듈들은 컨테이너 문서의 로딩시에 하나 이상의 IFRAME을 구축하지만, IFRAME은 동적으로 구축될 수도 있다.

도 3은 상이한 도메인의 모듈들이 컨테이너 문서 내에서 통신할 수 있는, 시스템의 일례를 나타낸다. 본 예에서, 컨테이너 문서는 도메인 'a.com'과 연관된 'IFRAME_A(315)'과 도메인 'b.com'과 연관된 'IFRAME_B(325)'를 생성한다. 또한, 컨테이너 문서는 'IFRAME_A(315)' 내로 'Module_A(310)'을 로딩하고, 'IFRAME_B(325)' 내로 'Module_B(320)'을 로딩한다. 이러한 방식으로, IFRAME(315, 325)은 사용자가 연관된 도메인의 컨텐츠를 디스플레이하고 상호작용할 수 있도록 사용될 수 있다. 이것은 외래 코드(예를 들면, 다른 도메인의 코드)가 컨테이너 문서의 유효 범위(scope) 내에서 실행되기 보다는 IRAME 내에서 캡슐화되는 것을 방지할 수 있다.

컨테이너 문서는 컨테이너 문서의 로딩시에 생성될 수도 있고, 또는 동적으로 생성될 수 있는 제 1 전송모듈(330) 및 제 2 전송모듈(340)을 더 포함할 수 있다. 일 실시예에서, 전송모듈(330, 340)은 내부에 컨텐츠 또는 코드를 가지지 않는 숨겨진 IFRAME들로 구현된다.

도 3, 도 4의 예시적인 시스템을 참조하여, 하나의 도메인(예를 들면, Module_A) 상에 호스팅된 모듈 및 다른 도메인(예를 들면, Module_B) 상에 호스팅된 모듈 사이에서의, 컨테이너 문서 내의 통신이 가능하게 하는 프로세스를 설명한다. 본 예에서, 제 1 전송모듈(330)은 도메인 'a.com'과 연관되어 있고, 제 2 전송모듈(340)은 도메인 'b.com'과 연관되어 있다. 이러한 프로세스에서, Module_A(310)은 Module_B(320)와 통신하기 위한 정보를 생성하거나(410), 또는 기타의 방법으로 획득한다. 이미 설명한 바와 같이, Module_A(310)와 Module_B(330)는 서로 상이한 도메인과 연관되어 있기 때문에, Module_A(310)는 Module_B(330)와 직접 통신할 수는 없다.

일 실시예에서, Module_A(310)는 통신하기 위한 데이터를 텍스트 스트링(text string)으로서 포함하고, 이러한 페이로드(payload) 데이터는 제 2 전송모듈(340)의 URL 레퍼런스에 부가된다. 이미 설명한 바와 같이, 임의의 모듈은 변수 정보(variable information)를 포함할 수 있는 URL 레퍼런스에 의해 참조될 수 있다. 일 실시예에서, URL 레퍼런스는 해쉬 부호 "#" 를 포함하고, 그 URL에 변수 정보("페이로드(payload)")를 추가할 수 있다. 해쉬 부호 이후의 URL 부분은 프래그먼트 ID(fragment ID) 또는 URL의 앵커(anchor)로 호칭될 수 있다. 해쉬 부호를 나타내어 설명하였지만, URL 내로 변수 정보 및/또는 파라미터를 도입하기 위한 일부 다른 메커니즘, 예를 들면, 파일네임(filename), 디렉토리 경로(directory path), 또는 URL 내의 서브도메인네임(subdomain name)을 통한 방법 등이 사용될 수 있다. 따라서, 일 실시예에서, Module_A(310)은 제 2 전송모듈(340)의 URL 레퍼런스를 설정하는 것에 의해(420), 그 페이로드와 통신한다. 예를 들면, Module_A(310)은 페 이로드 데이터를 준비하고, 그것을 제 2 전송모듈(340)과 연관된 URL 내에 "http://b.com/path#<payload_data>" 형태로 임베드(embed)한다.

사용되는 개개의 브라우저 프로그램에 의해 페이로드의 사이즈가 제한될 수 있다. 예를 들면, 일반적인 브라우저는 URL을 4킬로바이트로 제한할 수 있으므로, 페이로드는 URL의 시작 부분의 사이즈보다 훨씬 더 작게 제한될 수 있다. 외부적으로 강요된 제한이 아니더라도, 본 발명의 실시예는 페이로드(또는 URL)의 사이즈를 제한할 수 있다. 예를 들면, 너무 큰 페이로드(예를 들면, 10킬로바이트 이상)는 하이 레이턴시(high latency)를 초래할 수 있다. 이러한 파라미터들을 설정하는 방법은 여기서 기술된 통신 기술을 적용하는 것에 의한다.

대표적인 실시예에서, Module_B(320)는 제 2 전송모듈(340)이 Module_B(320)가 판독할 수 있는 페이로드 데이터를 가지는 시점을 반드시 알지는 못한다. 따라서, 일 실시예에서, Module_B(320)는 제 2 전송모듈(340)을 폴링하여(440), 어떤 신규 페이로드 데이터를 가졌는지 여부를 확인한다. 도 4에 나타낸 바와 같이, Module_B(320)는 제 2 전송모듈(340)을 주기적으로 폴링할 수 있고(440), 이러한 폴링은 규칙적인 간격으로 이루어질 수 있다. 한편, 폴링의 빈도는 마지막 페이로드가 도착한 시점에 기초하여 동적으로 조정될 수 있다. 예를 들면, 이전의 데이터가 도착한 다음에는 추가적인 데이터가 전송될 가능성이 높으므로, 페이로드 데이터의 이송 후에는 폴링을 더욱 빈번하게 행할 수 있다. 최대 폴링 간격을 통신 허용가능한 레이턴시만큼 설정하거나 또는 기타의 방법으로 강제할 수 있음을 알 수 있을 것이다. 한편, 너무 빈번한 폴링은 컴퓨팅 리소스들(computing resources)을 바람직하지 않게 드레인(drain)할 수 있다.

Module_B(320)가 제 2 전송모듈(340)을 폴링하여(440) 제 2 전송모듈(340)이 획득가능한 페이로드 데이터를 가진것으로 판정하면, Module_B(320)는 제 2 전송모듈(340)의 URL 레퍼런스로부터 페이로드 데이터를 판독한다(450). 이러한 방식으로, 도메인 'a.com'인 모듈로부터 도메인 'b.com'인 모듈로의 상기 페이로드 데이터의 통신을 수행할 수 있다.

일 실시예에서, Module_A(310)로부터 Module_B(320)로의 통신 더욱 가능하게 하기 위해, 전술한 프로세스를 반복할 수 있다. 또한, Module_B(320)는 예를 들면, 제 1 전송모듈(330)의 URL 레퍼런스를 설정하는 것에 의해, 역의 방향으로 Module_A(310)와 데이터 통신을 할 수 있다. 이러한 통신은 실제의 데이터 전송을 사용되거나, 또는 페이로드를 수신했다는 응답 메시지(acknowledgement message)를 송신하기 위해 사용될 수 있다. 데이터 수신을 가능하게 하기 위해, Module_A(310)는 제 1 전송모듈(330)을 폴링하여(470), 신규 데이터를 로딩했는지 여부를 확인한다.

전술한 프로세스를 반복하는 것에 의해, Module_A(310) 과 Module_B(320)는 어느 한쪽 방향으로 통신할 수 있다. 일 실시예에서, 다수의 페이로드들이 통신되는 모듈들은 일련 번호(sequence number)로 각 페이로드를 라벨링하는 것에 의해 그 메시지를 트랙킹할 수 있다. 또한, 컨테이너 문서는 다른 도메인의 모듈들도 포함할 수 있다. 이러한 경우에, 그들 다른 도메인과 초기에 연관되고, 그 다른 도메인의 모듈들이 통신하게 하는 하나 이상의 전송모듈이 있을 수 있다.

대안 환경(Alternative Environments)

본 명세서에서 설명한 프로세스 및 시스템은 본 발명의 범위 내에서 다른 콘텍스트 및 환경에 적용될 수 있다. 예를 들면, 컨테이너 문서는 호스팅된 페이지 크리에이터(예를 들면, geocities.com 또는 page.google.com 등)로부터 생성된 페이지를 포함할 수 있다. 이러한 콘텍스트에서, 생성되는(또는 미리 생성된) 페이지 내의 IFRAME은 호스팅된 페이지 크리에이터 도메인과는 상이한 도메인 상에 보존된 모듈(예를 들면, 플러그인(plugin))을 포함할 수 있고, 또한 그 모듈은 IFRAME을 이용하여 그 호스팅된 페이지 크리에이터가 참조할 수 있도록 하기 위한, 그 생성되는 페이지의 수정을 허용하는 컨텐츠(그 생성되는(또는 이미 안전한 방식으로 생성된) 페이지의 수정을 허용하는 IFRAME을 포함)를 생성할 수 있다.

또한, 그 코드를 랩핑(wrapping)하는 IFRAME는 컨테이너 문서(예를 들면, 웹페이지) 상에서 사용자에게 노출되지 않을 수도 있다. 이에 따라, 본 기술을 사용하는 경우, 본 명세서에서 설명한 IFRAME 기술 내의 IFRAME을 채용함으로써 하나의 예시적인 반복(iteration)으로, 유저 인터랙션(user interaction)을 제거할 수 있다.

다른 실시예에서, 어떤 웹페이지(예를 들면, 개인, 법인, 교육용 등)는 IFRAME 방법 및 시스템 내의 IFRAME을 사용하여 제 3 주체(third party)의 피쳐(features) 또는 컨텐츠를 포함하는 한편, 그 제 3 주체가 그 웹페이지의 서버 상의 쿠키(cookies)를 검색하거나 그 밖의 안전/프라이버시 문제를 발생시키는 것을 제한하도록 할 수 있다.

앞서 설명한 본 발명의 실시예들은 설명의 목적으로 제공된 것이며, 개시된 특정 형태들로만 본 발명을 축소하거나 한정하기 위한 것이 아니다. 당업자라면, 상기의 교시에 비추어 다양한 수정 및 변형이 가능함을 이해할 수 있을 것이다.

상술한 설명의 일부는 본 발명의 실시예들을 정보에 대한 오퍼레이션의 알고리즘 및 기호 표시의 관점으로 나타내었다. 이러한 알고리즘 설명 및 표시는 데이터 처리 분야의 당업자가 그들의 업무의 실체를 다른 당업자에게 가장 효율적으로 전달하기 위해서 사용되는 수단이다. 기능적, 컴퓨터사용적, 또는 논리적으로 기재되는 이러한 오퍼레이션은 컴퓨터 프로그램, 또는 이와 동등한 전기회로, 마이크로코드 등에 의해서 실시되는 것으로 이해된다. 또한, 때때로 오퍼레이션의 이러한 구성을 일반성의 상실 없이 모듈로서 칭하는 것이 편리하다는 것이 입증되었다. 상술한 오퍼레이션 및 그들의 연관된 모듈은 소프트웨어, 펌웨어, 하드웨어, 또는 그들의 임의 조합에서 구현될 수 있다.

또한, 본 발명의 실시예들은 본 명세서의 오퍼레이션들을 수행하는 장치에 관한 것일 수 있다. 이러한 장치는 요구된 목적을 위해서 특별하게 구성되거나, 컴퓨터에 저장된 컴퓨터 프로그램에 의해서 재구성되거나 선택적으로 활성화되는 범용 컴퓨팅 장치를 포함할 수 있다. 이러한 컴퓨터 프로그램은 플로피 디스크, 광 디스크, CD-ROM, 자기-광 디스크, ROM(read only memory), RAM(random access memory), EPROM, EEPROM, 자기 또는 광 카드, 특정 용도 집적 회로(ASIC)를 포함하는 임의 종류의 디스크, 또는 전자 명령을 저장하는데 적합하고 컴퓨터 시스템 버스에 각각 접속되는 임의 종류의 매체와 같은 컴퓨터 판독 가능 저장 매체 내에 저 장될 수 있지만, 그것에 한정되는 것은 아니다. 또한, 본 명세서 내에서 칭해지는 컴퓨터는 단일 프로세서를 포함할 수 있고, 또는 증가된 컴퓨팅 능력을 위한 복합 프로세서 디자인을 채용한 아키텍처(architecture)일 수 있다.

또한, 본 발명의 실시예들은 반송파(carrier wave)에 구현된 컴퓨터 데이터 신호에 관한 것일 수 있고, 여기서 컴퓨터 데이터 신호는 컴퓨터 프로그램 제품 또는 본 명세서에 기재된 다른 데이터의 조합의 임의 실시예를 포함한다. 컴퓨터 데이터 신호는 유형의 매개체(tangible medium)로 제공되어 변조되거나 또는 그 밖의 방법으로 임의의 적합한 방식에 따라 전송된 반송파 내에 부호화된 제품이다.

본 명세서에 기재된 알고리즘 및 디스플레이는 임의의 특정 컴퓨터 또는 다른 장치와 본질적으로 관련되지는 않는다. 또한, 다양한 범용 시스템이 본 명세서의 교시에 따른 프로그램과 함께 사용될 수 있거나, 요구되는 방법 스텝을 수행하기 위한 더욱 특화된 장치를 구성하는 것이 편리하다는 것이 입증될 수 있다. 다양한 이들 시스템의 필요 구조는 상기의 설명으로부터 자명할 것이다. 또한, 본 발명의 실시예들은 임의의 특정 프로그래밍 언어를 참조하여 기재된 것이 아니다. 각종 프로그래밍 언어가 본 명세서에 기재된 본 발명의 다양한 실시예들을 실행하기 위해 사용될 수 있고, 특정 언어에 대한 임의의 참조는 본 발명의 가능 및 최선의 모드를 개시하기 위해 제공된 것이다.

마지막으로, 본 명세서에서 사용된 언어는 본질적으로 가독성 및 교시적 목적을 위해서 선택되었으며, 본 발명의 주안점을 정확히 서술하거나 제한하기 위해서 선택된 것은 아니다. 따라서, 본 발명의 실시예들의 개시는 이해를 돕기 위한 것일 뿐, 다음의 청구범위에 기재된 본 발명의 범주를 한정하는 것이 아니다.

Claims

브라우저 어플리케이션 내에서 서로 상이한 도메인들과 연관된 모듈들 사이의 통신을 용이하게 하는 방법으로서,

제 2 도메인과 연관된 전송모듈을 생성하는 단계 - 상기 전송모듈은 URL 레퍼런스를 가짐 - ;

제 1 도메인과 연관된 제 1 모듈로부터의 페이로드 데이터(payload data)를 상기 전송모듈의 URL 레퍼런스의 부분에 부가하는 단계; 및

상기 제 2 도메인과 연관된 제 2 모듈에 의해 상기 페이로드 데이터를 판독하는 단계를 포함하는 방법.
제 1 항에 있어서,

상기 제 1 및 제 2 모듈은 컨테이너 문서(container document) 내에 담긴 인라인 프레임들(inline frames)을 포함하는 것을 특징으로 하는 방법.
제 1 항에 있어서,

상기 전송모듈은 빈(empty) 인라인 프레임을 포함하는 것을 특징으로 하는 방법.
제 1 항에 있어서,

상기 페이로드 데이터는, 상기 전송모듈의 URL 내의 해쉬 부호(hash symbol) 이후의 프래그먼트 ID(fragment ID)에 부가되는 것을 특징으로 하는 방법.
제 1 항에 있어서,

상기 제 1 도메인과 연관된 전송모듈의 URL 레퍼런스의 부분에, 상기 제 2 모듈로부터의 페이로드 데이터를 부가하는 단계; 및

상기 제 1 모듈에 의해 상기 제 1 도메인과 연관된 상기 전송모듈 내의 상기 페이로드 데이터를 판독하는 단계를 더 포함하는 것을 특징으로 하는 방법.
제 1 항에 있어서,

상기 제 2 모듈에 의해 상기 전송모듈을 주기적으로 폴링(polling)하는 단계 - 상기 폴링은 상기 전송모듈과 연관된 도메인을 적어도 일부 확인하는 것임 - ;를 더 포함하는 것을 특징으로 하는 방법.
제 6 항에 있어서,

상기 폴링의 빈도는, 이전에 상기 제 1 모듈과 통신한 이후의 시간을 적어도 일부의 근거로 하여 동적으로 조정되는 것을 특징으로 하는 방법.
브라우저 어플리케이션 내에서 서로 상이한 도메인들과 연관된 모듈들 사이의 통신을 용이하게 하는 컴퓨터 프로그램 제품으로서, 상기 컴퓨터 프로그램 제품 은 컴퓨터 판독가능한 매체를 포함하고, 상기 컴퓨터 판독가능한 매체는,

제 2 도메인과 연관된 전송모듈을 생성하는 단계 - 상기 전송모듈은 URL 레퍼런스를 가짐 - ;

제 1 도메인과 연관된 제 1 모듈로부터의 페이로드 데이터를 상기 전송모듈의 URL 레퍼런스의 부분에 부가하는 단계; 및

상기 제 2 도메인과 연관된 제 2 모듈에 의해 상기 페이로드 데이터를 판독하는 단계를 포함하는 방법을 수행하기 위한 컴퓨터 프로그램 코드를 포함하는 컴퓨터 프로그램 제품.
제 1 항에 있어서,

상기 제 1 및 제 2 모듈은 컨테이너 문서(container document) 내에 담긴 인라인 프레임들(inline frames)을 포함하는 것을 특징으로 하는 컴퓨터 프로그램 제품.
제 1 항에 있어서,

상기 전송모듈은 빈(empty) 인라인 프레임을 포함하는 것을 특징으로 하는 컴퓨터 프로그램 제품.
제 1 항에 있어서,

상기 페이로드 데이터는, 상기 전송모듈의 URL 내의 해쉬 부호 이후의 프래 그먼트 ID(fragment ID)에 부가되는 것을 특징으로 하는 컴퓨터 프로그램 제품.
제 1 항에 있어서,

상기 제 1 도메인과 연관된 전송모듈의 URL 레퍼런스의 부분에, 상기 제 2 모듈로부터의 페이로드 데이터를 부가하는 단계; 및

상기 제 1 모듈에 의해 상기 제 1 도메인과 연관된 상기 전송모듈 내의 상기 페이로드 데이터를 판독하는 단계를 더 포함하는 것을 특징으로 하는 컴퓨터 프로그램 제품.
제 1 항에 있어서,

상기 제 2 모듈에 의해 상기 전송모듈을 주기적으로 폴링하는 단계 - 상기 폴링은 상기 전송모듈과 연관된 도메인을 적어도 일부 확인하는 것임 - ;를 더 포함하는 것을 특징으로 하는 컴퓨터 프로그램 제품.
제 13 항에 있어서,

상기 폴링의 빈도는, 이전에 상기 제 1 모듈과 통신한 이후의 시간을 적어도 일부의 근거로 하여 동적으로 조정되는 것을 특징으로 하는 컴퓨터 프로그램 제품.