KR101367928B1

KR101367928B1 - 컨테이너 문서로의 원격 모듈 편입

Info

Publication number: KR101367928B1
Application number: KR1020087016368A
Authority: KR
Inventors: 아담 사; 딜란 파커; 제시카 린 그레이; 스티븐 엘. 골드버그; 크리스토퍼 에이치. 롤스
Original assignee: 구글 인코포레이티드
Priority date: 2005-12-12
Filing date: 2006-12-12
Publication date: 2014-03-14
Also published as: US20070136320A1; AU2010201642B2; EP1963956A4; EP1963956A2; US7730082B2; WO2007070405A2; AU2010201642A1; AU2006326623A1; KR20080083300A; AU2006326623A2; WO2007070405A3

Abstract

컨테이너 문서에 컨텐츠를 제공하기 위한 시스템 및 방법. 시스템은 컨테이너 문서를 사용하기 위해 하나 이상의 모듈을 식별하는 컨테이너 서버를 포함하고, 원격 서버로부터 모듈 상세를 수신하며, 그러한 모듈 상세에 기반하여 모듈 데이터를 포함하는 컨테이너 문서를 제공한다. 모듈 상세는 컨텐츠 요소 및 컨테이너 서버가 모듈을 선호하게 해주는 하나 이상의 선택적 선호 요소를 포함한다.

Description

컨테이너 문서로의 원격 모듈 편입{REMOTE MODULE INCORPORATION INTO A CONTAINER DOCUMENT}

본 발명의 실시 형태는 컨테이너 문서에 원격 모듈을 편입하는 것에 관한다.

다수의 웹사이트는 사용자에게 홈페이지를 개인화하는(personalize) 능력을 제공한다. 그러한 웹사이트는 일반적으로 사용자에게, 웹사이트 운영자에 의해 설계되고 편입된 선택들(choices)로부터 선택된 미리 규정된(predefined) 제시 포맷으로 정보 또는 데이터의 미리 규정된 섹션을 포함시키는 기회를 제공해왔다. 그러한 시스템의 사용자는 일반적으로, 특정 재고품을 재고품 가격을 나타내는 섹션에 포함하도록 선택하는 것과 같이, 섹션 내에 컨텐츠를 개인화할 수 있다. 이러한 개인화된 홈페이지는 매우 제한된 유연성을 제공한다.

이러한 및 다른 결점들이 현재 시스템에 존재한다.

따라서, 본 발명의 다양한 예시적 실시 형태가 컨테이너 문서에 컨텐츠를 제공하는(serve) 시스템에 관련된다. 시스템은 컨테이너 문서와 함께 사용하기 위한 하나 이상의 모듈을 식별하고, 원격 서버로부터 모듈 상세(specification)를 수신하고, 그러한 모듈 상세에 기반한 모듈 데이터를 포함하는 컨테이너 문서를 제공하는 컨테이너 서버를 포함한다. 모듈 상세는 컨텐츠 요소 및 컨테이너 서버가 선 호(preference)를 모듈에 제공하게 해주는 하나 이상의 선택 선호 요소를 포함한다.

다른 실시 형태에 따라, 하나의 방법은 컨테이너 문서와 함께 사용하기 위한 하나 이상의 모듈을 식별하는 단계, 원격 서버로부터 모듈 상세를 수신하는 단계, 및 모듈 상세에 기반하여 컨테이너 문서에 모듈 데이터를 제공하는 단계를 포함하며, 여기에서 컨테이너 서버는 모듈 데이터를 포함하는 컨테이너 문서를 제공한다.

다른 실시 형태에 따라, 하나의 시스템은 컨테이너 문서의 모듈 데이터를 발생시키는데 사용하기 위하여 모듈 상세를 원격 컨테이너 서버에 제공하는 모듈 상세 서버를 포함하며, 여기에서 모듈 상세는 컨테이너 문서를 위해 원격 컨테이너 서버에 의해 규정된 포맷을 포함한다.

다른 실시 형태에 따라, 하나의 시스템은 컨테이너 문서와 함께 사용할 하나 이상의 모듈을, 컨테이너 문서와 연관된 URL을 기반으로 식별하는 컨테이너 서버, 및 모듈 상세를 인터넷의 URL로부터 수신하고 컨테이너 서버에 데이터를 발생시키는 모듈 서버를 포함한다. 컨테이너 서버는 컨테이너 문서의 모듈 데이터를 포함할 수 있다.

다른 예시적 실시 형태에 따라, 컨테이너 문서에 컨텐츠를 제공하는 하나의 시스템은 컨테이너 문서와 함께 사용할 하나 이상의 모듈을 식별하는 컨테이너 서버, 및 원격 서버로부터 데이터를 수신하고, 그러한 데이터로부터 모듈 상세를 식별하고, 상기 모듈 상세에 기반하여 모듈 데이터를 컨테이너 서버에 제공하는 수신 서버를 포함한다.

다른 예시적 실시 형태에 따라, 컨텐츠를 제공하는 하나의 방법은 컨테이너 문서와 함께 사용할 하나 이상의 모듈을 식별하는 단계, 원격 서버로부터 데이터를 수신하는 단계, 그러한 데이터로부터 모듈 상세를 식별하는 단계, 상기 모듈 상세를 기반으로 모듈 데이터를 컨테이너 문서에 제공하는 단계를 포함하며, 여기에서 컨테이너 서버는 모듈 데이터를 포함하는 컨테이너 문서를 제공한다.

다른 실시 형태가 고려될 수 있다.

본 발명의 예시적 실시 형태가 아래에 자세히 논의된다. 특정한 예시적 실시 형태가 논의되고 있지만, 이는 예시의 목적만을 위한다는 것이 강조된다. 관련 업계의 기술자는 다른 구성요소 및 구성이 본 발명의 사상과 범위에서 벗어나지 않게 사용될 수 있다는 것을 인식할 것이다.

개인화된 포털 사이트(예를 들어, My Yahoo!, start.com 또는 개인화된 구글 홈페이지(Google Personalized Homepage))에서 사용자는 개인화된 페이지상에 신규 이메일 알림, 현재 날씨 및/또는 교통 상태, 영화 시간표, 별점 등을 나타내기 위하여 단지 컨텐츠(예를 들어, 상호작용(interactive), 읽기 전용, 업데이팅, 데이터 공급 등)을 선택할 수 있다. 본 발명의 일 실시 형태에 따라, 이러한 다양한 모듈은 컨테이너에 포함하기 위해 개발된(예를 들어, 제 3의 개발자에 의함) 모듈과 함께 개인화된 포털 페이지(컨테이너 문서의 일례)에 포함될 수 있다.

다양한 실시 형태는 호스팅 측(예를 들어, 컨테이너 서버 시스템)과 모듈 서버(예를 들어, 사용자 또는 호스팅 측 이외의 존재에 의해 동작되는 것)간 통신을 위한 프로토콜, 모듈(어디에서 호스트 되던지 해당)의 기능을 서술하는 프로세스 명령, 고정된 모듈 데이터 및 코드 뿐만 아니라 사용자당 구성 정보 또는 사용자 선호(예를 들어, 날씨 맵핑 모듈, 사용자가 관심있는 우편 코드)를 포함할 수 있는 모듈 데이터 및 코드를 위한 구조화된 저장 시스템, 및 사이트에서 표적 사이트 데이터의 사용을 가능하게 하는 프락시(proxy) 시스템을 제공한다.

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

여기에 사용되는 용어, "모듈"은 컨테이너 문서에 사용하기 위하여 데이터를 만드는 소프트웨어 및/또는 하드웨어의 일부를 언급한다는 것이 강조된다. 모듈은 사용자 선호, 컨테이너 선호, 환경 또는 다른 입력의 선호에 개인화될 수 있다. 모듈 상세는 미리 규정되어온 요소를 사용하는 컨테이너 문서용 데이터를 만드는데 사용되는 명령의 집합을 포함한다는 것이 강조된다.

도 1은 본 발명의 다양한 실시 형태에 따른 전체 시스템 구조를 도시한다.

도 2는 본 발명의 일 실시 형태에 따른 도시적 컨테이너 문서를 제시한다.

도 3은 본 발명의 일 실시 형태에 따라 모듈을 컨테이너 문서에 추가하는 도시적 프로세스를 제시한다.

도 4는 본 발명의 일 실시 형태에 따라 모듈을 식별하기 위한 도시적 인터페이스를 제시한다.

도 5는 본 발명의 일 실시 형태에 따른 도시적 모듈 상세 포맷을 제시한다.

도 6은 본 발명의 일 실시 형태에 따라 모듈 상세를 포함하는 데이터의 일례를 제시한다.

도 6(b)는 본 발명의 일 실시 형태에 따라 변형된 모듈 상세를 포함하는 데이터의 일례를 제시한다.

도 7은 본 발명의 일 실시 형태에 따라 모듈로부터의 데이터를 컨테이너 문서에 편입하는 도시적 프로세스를 제시한다.

도 8은 본 발명의 일 실시 형태에 따라 모듈로부터 데이터를 발생하는 도시적 프로세스를 제시한다.

도 9는 본 발명의 일 실시 형태에 따라 모듈이 컨테이너 문서에서 인라인화 되도록 해주는 도시적 프로세스를 제시한다.

도 10은 본 발명의 일 실시 형태에 따라 저장될 수 있는 선호 정보의 종류의 도시적 목록을 제시한다.

도 11은 본 발명의 일 실시 형태에 따른 도시적 시스템 구조를 제시한다.

도 12는 본 발명의 일 실시 형태에 따라, 표적 서버 데이터를 모듈로부터 컨테이너 문서로 전달하는 도시적 프로세스를 제시한다.

도 13은 본 발명의 일 실시 형태에 따라 프락시 서버 모듈을 통해 발생된 출력과 함께 모듈을 포함하는 도시적 컨테이너 문서를 제시한다.

도 14는 본 발명의 일 실시 형태에 따라 신디케이션을 통한 모듈과 모듈에 포함된 광고를 일체화하는 제 3자 웹 사이트의 도시적 실시 형태를 제시한다.

개요 및 시스템 구조

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

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

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

모듈 서버(14)는 컨테이너 문서에 편입하기 위하여 모듈로부터의 데이터를 컨테이너 서버(12)에 제공할 수 있다. 일 실시 형태에서, 컨테이너 서버(12) 및 모듈 서버(14)는 둘 모두의 기능을 수행하는 단일 유닛을 구성할 수 있다. 모듈 서버(14)는 모듈과 관련된 모듈 상세의 명령을 해석하고 및/또는 파싱(parsing)함으로써 컨테이너 문서에 데이터를 제공할 수 있다. 일 실시 형태에 따라, 모듈 서버(14)는 브라우저 IFRAME을 사용하여 컨테이너 문서에 모듈 컨텐츠를 제공할 수 있다. IFRAME은 일반적으로 컨테이너 문서 내에서 독립적으로 동작되는 브라우저 윈도우 인스턴스(instance)로 이해된다. IFRAME의 한 이점은 IFRAME의 컨텐츠로부터 컨테이너 문서를 보호하고 그 역도 가능하다는 것이며, 예를 들어, 컨테이너 문서상의 JavaScript는 내부 IFRAME(CSS, DOM, 또는 쿠키 객체에도 적용됨)상의 임의의 JavaScript 코드로 접근하는 것이 허용되지 않을 수 있다.

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

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

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

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

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

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

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

광고(Ad) 서버(36)는 컨테이너에 모듈과 관련한 광고를 제공할 수 있다. 예를 들어, 광고는 데이터가 컨테이너 문서에 전달될 때 모듈 데이터에 편입될 수 있다. 광고(Ad) 서버(36)는 모듈에 대한 신디케이션 요청을 기반으로 광고를 신디케이션 수신인 서버(38)에 전달하는 신디케이션 서버(34)와 함께 동작할 수 있다. 광고는 컨테이너, 모듈, 컨테이너 내의 다른 모듈, 신디케이션 수신인 서버 정보, 금전적 요소의 컨텐츠 또는 이들의 정보 간의 관계/전술한 임의의 것 및/또는 그들의 조합과 관련한 관계들을 포함하지만 이들에 제한되지는 않는, 넓은 다양한 기준을 기반으로 광고(Ad) 서버(36)에 의해 선택될 수 있다. 광고(Ad) 서버(36)는 본 발명의 일 실시 형태에 따라 Google AdSense 시스템을 포함할 수 있다. 광고(Ad) 서버(36)는 여기에 전체로서 참조로 포함되는 하나 이상의 후술하는 특허 출원들에 서술된 바와 같이 동작할 수 있다. 보다 상세하게, 광고(Ad) 서버(36)는 모듈에 관한 둘 이상의 개념(concept)을 광고와 결합시키고, 전자 문서와 함께 광고를 제공하는 맥락에서 논의된 방식으로 비드(bid)를 집합적으로 둘 이상의 키워드와 결합시킨다. 상기 논의된 방식은 2003년 1월 10일 출원되고, 발명의 명칭이 "하나 이상의 광고들과 결합된 키워드 교차 가격"인 미국 특허 출원 번호 10/340,193에 개시되어 있다. 광고를 제시하고 광고 비용을 관리하는 부가적인 다른 예시는 2003년 1월 10일자로 출원되고 명칭이 "광고가 관련 선호에 이루어지는 시스템에서 사용하 기 위한 자동 비용 관리"인 미국 특허 출원 번호 10/340,543 및 2003년 1월 10일자로 출원되고 명칭이 "광고가 수행 정보 및 가격 정보를 바탕으로 관련 선호에 이루어지는 시스템에서 사용하기 위한 자동 비용 관리"인 미국 특허 출원 번호 10/340,542에 논의되며, 양 출원은 참조로서 본원에 포함된다.

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

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

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

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

일 실시 형태에서, 네트워크(26)는 인터넷을 포함할 수 있다. 다른 네트워크는 또한 다양한 시스템 및/또는 서버 각각을 접속하는데 이용될 수 있다.

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

모듈을 포함하는 예시적 컨테이너 문서

본 발명의 일 실시 형태에 따라, 시스템 및 방법은 모듈을 컨테이너 문서에 편입하기 위해 제공된다. 컨테이너 문서의 하나의 예시는 인터넷상의 구글 서비스의 사용자에 현재 가능한 구글 개인화된 홈페이지와 같은 개인화된 홈페이지일 수 있다. 사용자가 개인화된 홈페이지와 같은 컨테이너 문서에 포함할 수 있는 컨텐츠의 종류를 제한하지 않고, 본 발명의 하나 이상의 실시 형태들은 사용자가 컨테이 너 문서의 소스가 아닌 소스로부터 모듈을 선택하도록 해준다. 따라서, 예를 들어, 사용자는 그 또는 그녀의 개인화된 구글 홈페이지에 모듈을 포함하기 위해 구글과 관련없는 소스로부터 선택할 수 있다.

다양한 형태의 컨테이너 문서가 존재할 수 있지만 하나의 그러한 도시적 예시가 도 2에 제시되어 있다. 도 2는 컨테이너 문서에 편입되어온 다수의 모듈을 갖춘 컨테이너 페이지(100)를 도시한다. IFRAME 및 인라인 HTML 기술을 포함하는 다수의 편입 방법이 가능하다. 이러한 이슈는 아래에 더 자세히 논의될 것이다. 도 2는 사진 원격 모듈(101), 작업 목록 모듈(102), 게임 모듈(104), 주식 모듈(105), 맵 모듈(106), 원격 모듈(108), 원격 모듈(110), 원격 모듈(112) 및 원격 모듈(114)을 포함하는 다수의 모듈을 도시한다. 다양한 모듈에 대한 다른 포맷이 모듈의 생성자에 의해 제공되는 상세에 따라 존재할 수 있다. 도시된 바와 같이, 일부 모듈은 스크롤 바를 포함할 수 있고, 다른 모듈은 그것을 포함하지 않을 수 있다. 일부 모듈은 다른 모듈과 다른 사이즈 또는 모양일 수 있다. 부가하여, 일부 모듈은 사용자가 표시 선호 및/또는 모듈과 연관된 사용당(per-use) 데이터를 편집하도록 기회를 제공할 수 있다(예를 들어, 편집 링크를 제공하는 모듈(102, 104, 105, 106 및 110)). 예를 들어, 만약 모듈이 맵 모듈(106)에 관련되면, 사용자는 그 모듈에 맵핑된 주소 또는 주소들을 편집할 기회를 제공받을 수 있다. 일 실시 형태에서, 인라인된 모듈은 컨테이너 문서에 의해 자동으로 크기조절될 수 있고, 따라서 스크롤링, 높이 또는 스케일링 정보가 제공되지 않을 수 있다. 모듈 개발자가 모듈이 상기 실시 형태에서 이러한 특성을 가지도록 원한다면, 인라인된 모듈은 고정 사이즈 <DIV> 태그로 감싸지고 및 컨텐츠는 태그 내에 위치될 수 있다. 그 다음, 스크롤 바, 높이 및 다른 특징들은 인라인된 컨텐츠를 위하여 지정될 수 있다. 속성들 중 하나인 specifying scaling="..."에 의해 개발자는 컨테이너 문서 내 다른 배치 크기에 대하여 어떻게 모듈이 스케일 업 또는 다운될 수 있는지 지시할 수 있다.

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

다른 선택물이 도 4에 도시되어 있으며, 사용자는 인터페이스와 상호작용하여 섹션(403)에 사용 가능한 다수의 모듈이 지시된 섹션(402)의 카테고리별 모듈을 통하여 브라우즈하고 또는 검색 박스(406) 내에 정보를 넣고, 검색 버튼(408)을 선택하여 섹션(410)에 표시되는 결과를 가질 수 있는 검색 기능(404)을 활용할 수 있다. 이러한 검색 및 표시의 결과는 도 3 및 제공된 다른 서술을 참조로 하여 아래에 서술된 바와 같이, 모듈 및 컨테이너 문서를 통합하는데 사용하도록 데이터(예를 들어, XML 파일)의 위치 참조(예를 들어, URL)를 제공할 수 있다.

도 2 또는 4에서, 작성자 이름, 작성자 소속 및/또는 작성자 이메일의 미리보기 모듈이 제공될 수 있다. 이메일을 보호하기 위하여, 익명 이메일 전달 특징이 스패머-크롤러(spammer-crawlers)에 대해 보호하도록 돕는데에 사용될 수 있다. 표시는 또한 모듈이 무엇을 요구하는지 또는 어떤 모듈이 가장 잘 동작하는지에 대한 정보를, 모듈 선호(아래에 자세히 서술됨)로부터 May-Require 속성을 사용하여 제공할 수 있다. 여기에서 이 모듈은 단지 Firefox 브라우저에서 동작하고 따라서 그러한 정보가 제공된다. 지역(locality) 정보도 또한 제공될 수 있다. 여기에서 이러한 모듈은 미국에 대하여, 영어와 스페인어용으로 디자인된다.

또한, 모듈을 부가하고, 편집하고 또는 삭제함에 있어서, 그러한 동작들이 컨테이너 문서의 갱신 없이 발생하도록 하는 것이 요구될 수 있다. 이것을 달성하기 위한 하나의 예시적인 테크닉은 모듈이 컨테이너 문서에 컨테이너 문서 페이지의 갱신 없이 부가될 수 있는(아마도 새로운 컨테이너가 제시되는 IFRAME의 갱신이 유일함) AJAX의 사용, 또는 컨테이너 문서의 갱신없이 모듈을 제거하거나 개발자가 모듈을 개발하고 있을 때, 그 모듈이 있는 컨테이너 문서가 변경된 모듈을 편입하기 위해 페이지 생신을 하지 않고 모듈을 변경할 수 있는 AJAX의 사용을 포함할 수 있다.

도 14는 컨테이너의 다른 도시적인 예시를 제시한다. 이러한 컨테이너는 모듈 서버에 가입되지 않은 컨테이너 서버로부터 운영될 수 있다. 컨테이너(1400)는 부동산 목록 정보를 목록화하는 제 3의 웹사이트(여기에서는 조의 부동산 웹 페이지)일 수 있다. 원격 모듈(1401)은 모듈 서버로부터의 신디케이션을 통하여 편입될 수 있다. 여기에서, 원격 모듈은 방문자가 조의 부동산 웹 페이지가 유용함을 발견할 수 있는 저당 계산기를 포함할 수 있다. 이 모듈에 하나 이상의 광고들(1403)이 도시된 바와 같이 또한 제공될 수 있다.

도시적 방법들

도 3은 모듈을 컨테이너 문서에 부가하는데 사용되는 방법(300)을 예시한다. 일 실시 형태에 따라, 블록(302)에서, 컨테이너 문서는 새로운 모듈이 부가되도록 열릴 수 있다. 이것은 컨테이너 문서를 사용자에게 제시함으로써 또는 예를 들어 컨테이너 컨텐츠를 결정하기 위하여 컨테이너 문서를 여는 컴퓨터 소프트웨어 요소에 의해 수행될 수 있다. 블록(304)에서, 추가될 컨텐츠의 선택이 수신된다. 이러한 컨텐츠 선택은 도 2 또는 도 4를 참조로 하여 서술된 입력을 통하여, 또는 사용자가 컨테이너에 부가될 모듈의 표시를 제공할 수 있게 하는 일부 다른 메커니즘을 통하여 사용자로부터 수신될 수 있다. 부가하여, 블록(304)에서 모듈은 시스템이 다양한 입력을 기반으로 추가될 모듈을 결정하는 자동화된 프로세스를 통해 제공될 수 있다.

예를 들어, 컨테이너 페이지(100)의 모듈(103)을 통한 컨텐츠의 부가를 요청하는 사용자 입력의 경우에, 블록(308)에서 사용 가능한 모듈의 목록을 통해 또는 참조를 통해 사용자가 모듈의 부가를 요청하는지 결정될 수 있다. 사용자가 목록으로부터 입력을 제공한다면, 메뉴 선택으로부터 컨텐츠는 블록(310)에서 수신될 수 있다. 그것은 도 2 또는 도 4에 도시된 바와 같은 인터페이스와 사용자의 상호작용에 의해, 예를 들어, (124 또는 403)으로 제시된 하나 이상의 모듈들을 선택함으로써, 달성될 수 있다. 모듈의 선택을 수신하는 다른 방법이 또한 제공된다. 사용자가 참조로부터 모듈의 선택을 제공하고 있다면, 그러면 블록(312)에서, 위치 참조가 수신될 수 있다. 모듈에 대한 데이터를 사용자 용이하게 식별하도록, 선택적인 블록(313, 315)이 또한 제공될 수 있다. 블록(313)에서, 사용자의 원격 위치 식별자가 사용자가 검색될 위치에 있는 파일을 요청하는 예를 들어, 슬래시 또는 다른 지시자로 끝난다면, 그러면 블록(315)에서, 가능한 모듈의 목록이 표시될 수 있다. 블록(315)은 사용자에 의해 제공된 원격 위치 식별자를 취하고, 그 위치를 모듈 상세를 나타내는 파일 또는 데이터의 목록에 대하여 조회하고(query), 그 조회에 대해 수신된 응답을 사용자의 선택을 위해 목록으로 제시하는 것을 포함할 수 있다. 예를 들어, 사용자는 제공된 위치에서 모듈 상세 파일의 목록을 제공받을 수 있어 블록(317)에서 그러한 제시된 파일의 하나를 선택할 수 있다. 예를 들어, 사용자가 슬래시로 끝나는 URL을 제공하거나 일부 다른 불완전한 위치 참조를 제공한다면, 시스템은 블록(315)에서, URL의 위치에서 모듈 상세를 포함하는 모든 파일의 목록을 검색할 수 있어서 사용자가 블록(317)의 XML 파일 중 하나와 같이 하나의 파일을 선택할 수 있다. 다른 예시에서, 시스템은 컨텐츠로부터 자동으로 추측할 수 있고, 또는 아파치(Apache) 웹서버 디렉토리 콜 또는 IIS 디렉토리 콜과 같은 웹 서버 리소스를 사용하여 디렉토리 목록 또는 객체 목록을 제공할 수 있다(예를 들어, 데이터베이스 조회를 통함). 목록은 더 가능성있는 선택을 강조하는 것과 같이 선택을 쉽게 만드는 방식으로 포맷될 수 있다.

블록(314)에서, 시스템은 컨테이너 페이지가 업데이트 되기 전에 추가될 모듈의 선택을 선택적으로 사용자가 확인하게 해줄 수 있다. 블록(314)의 수행시 또는 확인 동작이 프로세스에 포함되지 않는다면, 블록(310 및/또는 312 및/또는 317)의 단계 후에, 선택적 승인 블록(318)이 발생할 수 있다.

본 발명의 다양한 실시 형태에 따라, 컨테이너 문서의 운영자는 컨테이너의 보안 뿐만 아니라 컨테이너와 상호작용하는 사용자 시스템의 보안을 보호하는 것을 요구할 수 있다. 따라서, 컨텐츠가 컨테이너에 편입되게 하기 전에 모듈이 승인되었는지 결정하도록 하나 이상의 동작들이 취해질 수 있다. 예를 들어, 컨텐츠의 평가는 신뢰된다고 결정된 예를 들어, HTML 태그 또는 다른 특성들이 없다면, 모듈이 신뢰할만한지 결정하기 위해 이루어질 수 있다. 이러한 동작들은 아래에 더 자세히 기술되어 있다. 만약 승인되지 않으면, 그 다음에 블록(320)에서, 하나 이상의 비승인 응답들이 분석 모듈(28)을 참조로 하여 상기에 기술된 바와 같이 발생할 수 있다.

만약 승인이 발생하면, 블록(322)에서, 업데이트된 컨테이너 문서가 사용자 에 또는 컨테이너에 부가할 모듈의 입력을 제공해온 자에 제시될 수 있다.

아래에 더 자세히 서술된 바와 같이, 본 발명에 따라, 상세는 호스트 서버 시스템(10)에 의해 컨테이너 문서에 편입되기 위하여 모듈이 활용하도록 제공될 수 있다. 도 5는 본 발명의 일 실시 형태에 따른 모듈 상세를 도시한다. 기초 레벨에서, 상세는 XML 버전 정보, 선택적인 모듈 선호, 선택적인 사용자 선호, 선택적인 컨텐츠 종류 지정자, 및 모듈을 위해 할당된 컨테이너의 부분을 존재시키기 위해 사용되는 컨텐츠 요소를 포함하는 다수의 요소를 갖는다. 컨텐츠가 다양한 형태의 코드, 일반적으로 제시를 위해 컨테이너를 발생할 때 사용자 시스템에 의해 해독가능한 코드로 지정될 수 있다는 것이 인식되어야 한다. 그러한 코드는 웹 페이지의 포맷을 도시하는데 사용될 수 있는 HTML, JavaScript, 또는 다른 형태의 코드를 포함할 수 있다.

본 발명의 다른 실시 형태에 따라, 모듈 상세는 하나 이상의 다른 파일들 또는 컴퓨터 명령들에 포함될 수 있다. 이 실시 형태에 따라, 모듈 서버(14)는 모듈을 발생하기 위해 데이터의 식별이 제공될 때, 데이터 내에 모듈 상세로 발견할 수 있다. 데이터의 형태 중 하나는 도 6의 도시적 예에 제시된 바와 같이 다른 HTML 파일일 수 있다. 이 예시에서, HTML 문서의 다른 코드들 중에서, 문서 상세는 도 6의 예시에 나타나는 바와 같이 제공될 수 있다. 이 예시는 모듈이 할당된 컨테이너의 일부 내에 단어, "Hello world!"를 도시하는 모듈의 간단한 형태이다. 도시된 바와 같이, 문서 상세는 다른 HTML 페이지에 포함되며 따라서 문서 상세가 위치된 파일은 .htm 또는 .html의 접미사를 가질 가능성이 많다. 다른 예시에서, "debut", "about"과 같은 컴퓨터 명령 또는 일부 다른 명령은 상세를 제공하는 것으로 식별될 수 있다. 따라서, 본 발명의 일 실시 형태에 따라, 문서 상세가 XML 종류 파일을 포함하더라도, 모듈 상세의 소스는 실질적으로 모듈 상세가 식별될 수 있는 다른 데이터의 형태 또는 파일 종류일 수 있다.

부가하여, 데이터의 저장소는 모듈 상세를 변경하고, 수정하고, 변화시키고, 또는 손상시킬 수 있다. 예를 들어, 많은 데이터 저장소는 그것이 소스로서 저장되거나 사용될 때, HTML 또는 XML 컨텐츠를 "회피한다(escape)". 그리고 일부 시스템은 제시를 위하여 소스 코드를 비회피(unescape)할 수 있다. 따라서, 회피된 데이터에 모듈 상세가 포함된다면, 모듈 서버 또는 상세 서버는 회피된 코드를 감지하고, 사용될 비회피 방식(예를 들어, 소스에 기반하거나, 사용된 코드의 종류 또는 다른 기술에 기반함)을 결정하고, 데이터를 원래 형태로 복귀시키도록 데이터를 비회피할 수 있다. 도 6(b)는 회피된 후 도 6의 실례의 파일을 도시한다. 이 예시에서, 기호 "<"는 "<"로 변경되고 기호 ">"는 "&gt"로 변경되고, 일부 다른 변경들이 행해진다.

유사하게, 모듈 상세에 대한 다른 변경 또는 수정에 의해, 모듈 서버 또는 상세 서버는 변경 또는 수정을 감지할 수 있고, 어떻게 변경 또는 수정을 되돌리는지 결정하고, 또는 모듈 상세를 그것의 의도된 형태로 출력할 수 있다.

모듈 취급의 도시적 방법

모듈이 컨테이너에 편입된 후, 컨테이너가 오픈되거나 갱신될 때에, 컨테이너에 포함시키기 위해 모듈로부터 데이터를 발생하는 하나의 방법이 수행될 수 있 다. 그렇게 하는 하나의 도시적 방법이 도 7의 프로세스(700)에 도시될 수 있다.

블록(702)에서, 모듈 참조는 컨테이너로부터 수신될 수 있다. 예를 들어, 사용자용 컨테이너는 편입될 다수의 다른 모듈을 지정할 수 있다. 모듈의 위치에 대한 참조에 의해 그러한 모듈을 나타낼 수 있다. 모듈이 URL 형태로서 지정되면, 모듈은 컨테이너의 서버로부터 잠재적으로 먼 곳에 위치된다. 본 발명의 일 실시 형태에 따라, 블록(704, 706)이 제공될 수 있다. 블록(704)에서, 원격 모듈의 상태는 예를 들어, 분석 모듈(28)에 의해 결정될 수 있다. 만약 원격 모듈이 블록(706)에서 승인되면, 프로세싱이 블록(710)으로 진행할 수 있다. 만약 승인되지 않으면, 하나 이상의 비승인 응답들이 블록(708)에서 취득될 수 있다. 블록(710)에서, 원격 모듈 참조와 관련한 서버는 호출될 수 있고 수신된 데이터는 평가될 수 있다. 본 발명의 다른 실시 형태에 따라, 블록(710)은 컨테이너 서버와 관련된 캐시로부터 원격 모듈을 검색하는 것을 포함할 수 있다. 선택적 블록(712)에서, 블록(704)과 관련된 하나 이상의 동작들은 원격 모듈이 승인되었는지 결정하기 위해 수행될 수 있다. 이것은 원격 모듈이 다른 존재(party)의 제어하에 있어서 이들이 빈도 기반(frequent basis)으로 가능한 변경에 노출되기 때문에 요구된다. 따라서, 모듈이 컨테이너에 포함되는 제 1 시간과 그것이 표시되는 제 2 시간 사이에 원격 모듈에 변화가 이루어져 원격 모듈이 비승인으로 될 수 있다.

블록(714)에서, 원격 모듈 참조로부터 검색된 데이터는 모듈 상세를 식별하기 위해 파싱된다. 상기에 논의된 바와 같이, 데이터는 단지 모듈 상세를 포함하는 파일을 포함할 수 있고, 따라서 단계(714)는 제공된 데이터로부터 모듈 상세를 추 출하기 위해 사용된다. 블록(716)에서, 모듈 상세는 어떻게 데이터를 발생하는지 결정하기 위해 분석되고, 블록(718)에서, 데이터는 컨테이너가 사용자 시스템 또는 컨테이너를 오프닝하는 다른 시스템에 의해 접근될 때 원격 모듈의 컨텐츠를 볼 수 있도록 컨테이너로 복귀된다. 모듈 상세를 분석하는 것과 관련된 다양한 동작(716)이 여기에 더 자세히 제공된다.

도 8은 블록(716)에 포함된 동작들을 상세히 도시한다. 특히 블록(802)에서, 파싱 동작은 모듈 상세의 지정된 컨텐츠 종류를 식별하고 상기 컨텐츠 종류에 기반하여 적절한 동작을 취할 수 있다. 예를 들어, HTML 컨텐츠 종류에 대하여, 모듈 데이터가 서버상에 존재한다. 블록(804)에서, 모듈 선호는 이용가능하다면 적용될 수 있다. 모듈 선호에 대한 더 자세한 사항과 그들이 어떻게 적용될 수 있는지가 아래에 제공된다. 블록(806)에서, 사용자 선호는 이용가능하다면 적용될 수 있다. 사용자 선호에 대한 더 자세한 사항이 아래에 더 자세히 제공된다. 블록(810)에서, 사용가능하다면 모듈 선호, 이용가능하다면 사용자 선호 및 모듈 상세의 컨텐츠 및 컨텐츠 종류를 기반으로 하여, 데이터는 컨테이너로의 전달을 위해 발생될 수 있다.

일 실시 형태에 따라, 모듈이 상세에 따라 생성될 수 있다. 모듈 상세는 요구되는 요소 및 선택적인 것을 지정할 수 있다. 일 실시 형태에서, 컨텐츠 종류 및 컨텐츠는 필수적이고, 사용자 선호 및 모듈 선호는 선택적일 수 있다. 다른 실시 형태는 필수 요소를 수반하지 않을 수 있다.

본 발명의 일 실시 형태에 따라, 모듈은 모듈 서버에 의해 발견될 수 있는 인터넷상에 임의의 곳에서 위치된 XML 파일에 의해 지정될 수 있다. 모듈을 지정하는 XML 파일은 어떻게 모듈을 프로세스하고, 모듈 서버에 의해 해석되도록 모듈을 만드는 명령을 포함하며, 모듈의 해설에 의해 데이터가 만들어진다. XML 파일은 모듈을 위한 모든 데이터 및 코드를 포함할 수 있고, 또는 나머지 요소들을 발견할 수 있는 장소로의 참조(예를 들어, URL)를 가질 수 있다.

다른 종류의 원격 모듈이 다수 존재할 수 있으며, 예로서, HTML, URL 및 XSLT, 또는 HTML 및 URL과 같은 미리 규정된 종류의 소규모 목록이 있다.

<Content type="html">에 대하여, <Content>의 바디는 html이고 호스트 서버 시스템(10)에 의해 호스트될 수 있다. 이것은 JavaScript를 포함하는 모듈에 유용할 수 있다. 일 실시 형태에서, 여기에 서술된 바와 같이, 컨테이너는 안전을 위하여 IFRAME 내에 신뢰되지 않은 HTML을 내장할 수 있다. 실시 형태는 또한 HTML 컨텐츠를 파싱하고 주변 IFRAME 없이 표시하는 것이 안전한지 결정할 수 있다.

<Content type="url" href=...>에 대하여, <Content>의 바디는 무시될 수 있고, 'IFRAME src='는 href 속성에서 지정된 url을 가르킨다. 이것은 서버측 동적 컨텐츠 발생에 대하여 유용한 컨텐츠 종류일 수 있다. 일 실시 형태에서, url 종류는 IFRAME 내에 제공될 수 있다. 이것에 의해 컨테이너 시스템은 URL에서 데이터를 제공하는 사이트로부터 쿠키를 얻고, 사용자 선호를 정확하게 파싱할 수 있으며, 또한 다른 이점들을 얻을 수 있다.

<Content type="xslt" frame=yes|no href=...>에 대하여, <Content>의 바디는 href=attribute에서 지정된 URL에 위치된 컨텐츠에 적용되는 XSLT 스타일시트일 수 있다. 또한, 이러한 종류의 모듈을 위한 디폴트(default)는 악의적 HTML/JavaScrip에 대하여 보호하는 하나의 방법으로서 IFRAME 표현이 될 수 있다.

하나의 예시적 HTML 모듈이 아래에 보여진다.

라인	설명
<?xml version="1.0" encoding="UTF-8"?>	XML 파일을 시작하는 기준 방식
<Module>	이 XML 파일이 컨테이너 문서와 함께 사용하기 위한 모듈을 포함한다는 것을 나타낸다.
<Content type="html"><![CDATA[	<Content 섹션의 바디가 HTML을 포함하는 것을 나타낸다.
Hello, world!	실제 HTML
]]></Content>	컨텐츠 섹션의 끝

일 실시 형태에 따라, 모듈은 아래에 보여지는 컨텐츠 섹션을 가질 수 있다.

<![CDATA[

... 모듈이 HTML(또는 다른 브라우저 인식가능 코드)을 생성하고 위치시키는 곳

]]>

</Content>

모듈 선호는 선호되는 크기, 명칭, 작성자 등과 같은 선택적인 모듈당 구성 정보일 수 있다. 예를 들어,

<ModulePrefs title="Today's place on the Internet Traffic"

title_url="http://www.placeoninternet.com/stats/" height="200" author="Robert Smith" author_email="rsmith@placeoninternet.com"/>

<Content...>

... content ...

</Content>

</Module>

모듈 선호 속성 <ModulePrefs...> 이름의 예시적 테이블이 다음을 포함할 수 있다:

이름	기술
title	모듈의 명칭을 제공하는 선택적인 스트링. 이러한 명칭은 사용자의 개인화된 홈페이지 상의 모듈 명칭 바에 표시된다.
title_url	모듈이 존재하는 곳을 나타내는 선택적인 스트링.
description	모듈을 기술하는 선택적인 스트링.
author	모듈의 작성자를 나열하는 선택적인 스트링.
author_email	모듈 작성자의 이메일 주소를 제공하는 선택적인 스트링.
author_affiliation	작성자를 위하여 하나 이상의 단체들을 지정하는 선택적인 스트링(예를 들어, Google 또는 Joe's Module Developer, Inc.)
height	모듈이 실행되는 영역의 높이를 지정하는 선택적인 양의 정수.
scaling	브라우저의 크기가 재조정될 때 모듈의 종횡 비율(높이대 넓이 비율)이 유지되는지 여부를 지정하는 선택적인 불린(boolean). 수직으로 자동적으로 크기조정할 수 있는 모듈은 이것을 트루(true)로 설정하도록 선택할 수 있으나, 고정된 높이를 가지는 모듈은 이것을 폴스(false)로 설정해야 한다. 디폴트는 트루이다.
scrolling	제공된 공간을 컨텐츠가 초과한다면 수직적 및/또는 수평적 스크롤바를 제공하는 선택적인 불린. 만약 폴스이면, 컨텐츠는 제공된 높이 및 넓이로 잘린다. 디폴트는 폴스이다.
render_inline	모듈이 인라인으로 표시되는지를 나타내는 선택적인 스트링.

또한 <ModulePrefs> 선호 속성 내에, <MayRequire...> 요소는 호환을 위한 정보를 지정할 수 있고 디렉토리 내에 표시될 수 있다. 이러한 정보는 또한 모듈의 속성 검색을 위해 또한 사용될 수 있다. 그것은 정보를 제공하는데 사용되거나 정확성을 위해 분석 모듈 내 소프트웨어에 의해 입증될 수 있다. 일 실시 형태에서, 이러한 속성은 검색 결과에 모듈을 제시하거나, 모듈 생성자가 의도한 방식으로 동 작하기 위해 모듈이 무엇을 필요로 하는지 사용자가 이해할 수 있도록 브라우징하는데 사용될 수 있다.

예를 들어, QuickTime, WINDOWS 플랫폼 및 Firefox 브라우저를 요구하는 하나의 모듈은 다음의 모듈 선호 속성 값을 제공할 수 있다.

<ModulePrefs...>

이것은 윈도우의 자세한 설명이다.

</MayRequire>

</ModulePrefs>

종류 및 값 속성을 위하여 미리 규정된 값이 지정될 수 있으며, 이는 부가적인 가능한 값을 포함하기 위하여 시간에 따라 업데이트될 수 있다. 'A type=other'는 캐치-올(catch-all)로서 제공될 수 있다.

다중 MayRequire 요소가 제공되면, 논리 OR은 같은 종류의 다중 속성을 해석하는데 사용될 수 있고, 논리 AND는 다른 종류의 다중 속성을 해석하는데 사용될 수 있다. 예를 들어, 다중 브라우저가 지정될 수 있고 해석기는 임의의 지정된 브라우저가 사용될 수 있다는 것을 이해한다. 브라우저 속성 및 플러그인 속성이 제공된다면, 해석기는 둘 모두가 예측됨(논리 AND)을 이해할 수 있다. 모듈이 함께 동작하지 않는 것을 지정하는 속성을 또한 사용할 수 있다.

또한 <ModulePrefs> 속성 내에서, <Locale ...> 요소에 의해 개발자는 모듈이 설계된 국가 및/또는 언어를 지정할 수 있다. 그것은 <Locale lang="..." country="...">로서 지정될 수 있다. 의미적으로, 이 언어를 선호하거나 지정된 나라에 위치한다고 지정한 사용자에게 모듈이 수용 가능함을 나타내는 것으로 해석될 수 있다. 이것은 컨테이너 서버가 법적인 규제를 따르는데 도울 수 있다. 예를 들어, 만약 국가가 판매를 위해 제공되는 것으로부터 소정 종류의 정보를 배제한다면, 판매 모듈은 아이템이 합법적인 국가에서만 판매하도록 그러한 아이템을 제시하는 지역적 선호를 검출할 수 있다. 그것은 또한 사용자 검출된 또는 지정된 지역에 기반하여 모듈을 숨기거나 계층화시키는 디렉토리 및 검색을 위해 사용될 수 있다. 부가하여, 코드에 대한 선택적 속성을 제공하는 것이 가능할 수 있고, 이러한 코드는 예를 들어, ISO 3166 코드와 같은 표준화된 코드의 상세를 허가할 수 있다. 이러한 변형에서, 그러한 특정 코드의 상세는 언어 및 국가 속성(만약 존재한다면)을 무시할 수 있다.

"lang" 및 "country" 값에 값을 제공하는 것은 선택적이다. 만약 하나가 빠진다면, 그것은 모든 값으로서 해석될 수 있다(즉, 지정된 국가에 대한 모든 언어 또는 지정된 언어에 대한 모든 국가).

일 실시 형태에서, 지역 데이터가 지정되지 않는다면, 해석기는 하나의 국가 및 언어(예를 들어, US 및 영어), 또는 국가들 및 언어들의 미리 규정된 집합을 가정할 수 있다. 단축 값은 국가들의 알려진 두 자리 값(예를 들어, 뉴질랜드에 대해 NZ, 멕시코에 대해 MX 등)과 같이 또한 사용될 수 있다. 국가의 목록은 또한 소정 지역의 특징인 소정의 단어, 스트링, 문자 등에 대하여 컨텐츠를 스캐닝하고, 작성자 정보 또는 다른 가능한 선택을 탐색함으로써 결정될 수 있다. 단축 값은 또한 국가의 알려진 ISO 두 글자 표현(예를 들어, 뉴질랜드에 대해 NZ, 멕시코에 대해 MX 등)으로서 사용될 수 있다.

reader_inline 속성은 선택적 선호일 수 있다. 일 실시 형태에서, 모듈이 적절하게 동작하도록 인라인 되어야 함을 의미하는 "필수적", 모듈이 인라인된다면 적절하게 동작하지 않음을 의미하는 "불가", 및 어느 방식으로든 동작함을 의미하는 "선택적"을 포함하는 미리 결정된 값이 제공될 수 있다.

일 실시 형태에서, 모듈 서버로부터 네트워크를 통하여 멀리 위치된 상세 서버로부터 일반적으로 얻을 수 있는 모듈 상세를 캐싱하는 것이 바람직할 수 있다. 예를 들어, 상세 서버가 느린 접속 상에 동작한다면, 모듈 상세의 전송은 컨테이너 문서용 데이터의 생성이 느려지거나 불가능하게 만들 수 있다.

따라서, 모듈 선호의 캐싱 요소는 적용될 캐싱 규칙을 나타내는 하나 이상의 속성들을 설정할 수 있다. 예를 들어, url 종류의 모듈에 대하여, 캐싱 규칙 선호는 크기 요소를 포함하는 속성을 지정할 수 있다(예를 들어, 스크린 크기가 동일할 때에만 모듈 컨텐츠를 캐싱하고, 이외에는 리로드함). 이것은 사용자 식별이 지정되는 것을 원하지 않는 모듈에 대한 디폴트 캐싱 행위일 수 있다. 다른 속성은 "사용자" 값에 기반할 수 있다(예를 들어, 임의의 크기에 대해, 사용자당 컨텐츠만을 캐싱함). 다른 속성은 "사용자, 크기" 값 조합(예를 들어, 주어진 사용자 및 주어진 스크린 크기에 대한 컨텐츠만을 캐싱함)에 기반할 수 있다. 이것은 url 종류이고 사용자 식별을 수용하는 모듈에 대한 디폴트 캐싱 행위이다. 또한, 시기(age) 속성은 모듈이 소정의 시간 기간 동안 캐싱될 수 있도록 지정될 수 있다. 이 속성의 값은 컨텐츠를 캐싱하는데 최대 초(second)일 수 있다. 이러한 숫자는 초에는 "s"를, 분에는 "m"을, 시에는 "h" 또는 날짜에는 "d"를 접미사로 붙일 수 있다. 예를 들어, <ModulePrefs CacheMaxAge=45d>는 45일 동안을 캐싱을 허용할 것이다. 예를 들어, <ModulePrefs CacheMaxAge=0>은 효과적으로 캐싱을 불가하게 한다. 디폴트 값은 무한대일 수 있고, 이는 "CacheMaxAge=infinite."로 명확히 지정될 수 있다.

모듈은 개인화된 홈페이지(들), HTML 이메일, 휴대 디지털 디바이스(PDA's), 전화, 휴대폰, 상호작용 매체 디바이스, 비디오 게임 콘솔, 텔레비전 오버레이(overlays) 등, 또는 포맷(예를 들어, HTML)을 기반으로 컨텐츠를 표시하도록 구성된 임의의 다른 디바이스와 같은 컨테이너에 적합한 어플리케이션의 "작은" 버전(version)을 포함할 수 있다. 스크린 크기가 작으면, 어플리케이션은 프로모션 및 광고 등으로 어지럽히지 않고 더욱 간결화되도록 적응될 수 있다. 다른 선호를 가지는 다른 출력 디바이스에서 크기 조절은, 모듈 선호를 통해서 또는 표시를 위해 데이터를 만드는 다른 출력 디바이스 상에서 어떻게 행위해야 하는지를 규정하는 모듈을 통해 달성될 수 있다.

예를 들어, 모듈을 그것이 주어진 윈도우의 크기로 맞추기 위하여, 모듈은 <ModulePrefs ... height="200">을 이용하여 높이(픽셀 단위로)를 지정할 수 있다. 또한, 모듈이 제공된 크기에 맞지 않는다면, 스크롤바는 <ModulePrefs ... scrolling="true">이면 자동으로 부가될 수 있다.

따라서 모듈 선호를 사용하여 모듈 생성자는 스크린 크기, 가시성 상태 -- 예를 들어, 전체, 최소화된-타이틀바-유일, 최소화된 가시성(예를 들어, 하부상 또는 툴바에 가시성 아이콘 있음), 최소화된 비가시성(예를 들어, 메뉴로부터 유일하게 이용 가능), 또는 닫힘 상태를 지정할 수 있다. 모든 가시성 상태에서, 이벤트(정기 이벤트 포함)에 반응할 수 있고, 시스템과 상호작용(그것의 상태 변경을 포함)할 수 있다는 견지에서 모듈은 여전히 사용자의 페이지 "상에" 있을 수 있다. 또한, 시스템, 최종 사용자(end user) 또는 모듈은 모듈의 가시성을, "디폴트" 가시성 또는 예를 들어, 상태를 "활성"으로 규정하는 다양한 환경하의 가시성으로 제어할 수 있다. 도시적인 예는 그들이 비정상적 또는 극한의 날씨일 때까지 최소로(일부 규정을 위하여) 유지되는 날씨 모듈을 포함한다. 교통 모듈은 관련된 교통 경보가 발생할 때까지 최소로 유지될 수 있다. 주식 모듈은 미리 결정된 비율보다 큰 변경을 가지는 주식만을 표시할 수 있다. 공상 축구 모듈은 주말에 또는 첫 번째 게임의 미리 정해진 기간 내에만 활성일 수 있다. 사용자는 예를 들어, 이러한 선호를 수동으로 무시하는 선택을 메뉴로부터 가질 수 있다. 또한, 다른 예로서, 이메일 모듈은 일부 기준에 의해 중요하다고 간주되는 이메일을 반영하여 스스로 크기를 조정할 수 있다.

많은 모듈은 인터넷상의 임의의 곳에서 호스트된 동적인 서비스 및 큰 데이터베이스에 접근하도록 선택할 수 있다. 보안을 위해서, 브라우저는 일반적으로 임의의 JavaScript가 그것이 검색하는 컨텐츠와 같은 호스트 "로부터 온다"는 것을 요구한다. 따라서, 그러한 기술을 사용하는 모듈은 JavaScript 소스 파일 및 JavaScript 코드가 접근하는 서비스를 같이 위치(co-locate)시킬 수 있다. 예를 들어, 여기에 Maps API를 사용하는 동작하는 Google Maps 모듈이 있다:

<![CDATA[

type="text/javascript"></script>

var prefs=new_IG_Prefs(_MODULE_ID_);

var map=new GMap(document.getElementById("map"));

map.addControl(new GSmallMapControl());

map.addControl(new GMapTypeControl());

//alert(prefs.getString("loc.lat")+" "+prefs.getString("loc.long"));

map.centerAndZoom(new GPoint(prefs.getString("loc.long"),

prefs.getString("loc.lat")), 6);

</script>

]]>

</Content>

</Module>

이 예시와 관련하여, 'userpref datatype=location'은 지오코드이어야 한다(즉, 스트링을 위도 및 경도에 변환함).

많은 모듈은 사용자 선호 정보를 수신할 수 있다 - 예를 들어, 날씨 모듈은 사용자가 보기를 원하는 우편 코드의 수신을 기대할 수 있다. 기대되는 사용자 선호를 갖는 예시적 모듈이 아래에 제시된다.

<?xml version="1.0" encoding="UTF-8" ?>

<ModulePrefs title="Weather Map" title_url=

"http://www.internetplace.com/weather-map.html" height="260" />

</Module>

사용자가 모듈 URL을 변경하던가 모듈 상세가 변경되면, 임의의 이전 사용자 값은 새로운 모듈 상세와 동기(sync)가 어긋날 수 있다. 이것을 해결하기 위하여, 서버는 선호 값을 어떠한 방법으로든 통과할 수 있도록 선택할 수 있다. 오래된 사 용자 선호는 삭제되고, 무시되고 또는 상세 서버가 오래된 사용자 선호들을 무시할 수 있는 곳을 따라 통과될 수 있다.

사용자 선호 속성 이름의 예시적 표는 다음을 포함한다.

이름	기술
name	분야의 "기호적" 이름; display_name이 규정되어있지 않다면 편집과정 동안 최종 사용자에 표시된다. 일 실시 형태에서, 분야 이름은 문자, 숫자 및 언더스코어, 즉, 일반적 표현 ^[a-zA-Z0-9_]+$ 만을 사용할 수 있다. 다른 실시 형태에서, 다른 지시기가 또한 사용될 수 있다.
display_name	편집 윈도우에서 사용자 선호와 함께 표시하는 선택적 스트링
urlparam	content type=url에 대하여 파라미터 이름으로서 전달하는 선택적 스트링 이름
datatype	이 분야의 데이터 종류를 나타내는 선택적 스트링 종류 이름(디폴트는 "스트링(string)"으로 함). 선택은 "스트링," "불(bool)" 및 "이넘(enum)"을 포함할 수 있다.
required	사용자 선호가 요구되는지 나타내는 선택적인 논리 인자(argument; "트루" 또는 "폴스")
default_value	사용자 선호의 디폴트 값으로서 제공하는 선택적 스트링 값
num_minval	사용자 선호를 위한 최소 허용 값을 나타내는 선택적 숫자 값
num_maxval	사용자 선호를 위한 최대 허용 값을 나타내는 선택적 숫자 값
cdata	각각의 스트링이 HTML인 반복되는 스트링 값. 선호 태그 간의 선택적 데이터를 제시할 수 있다.
str_maxlen	사용자 선호를 위한 최대 스트링 길이를 지정하는 선택적인 숫자 값

이러한 선호들 중에서, 일부 모듈은 데이터를 획득하기 위해 로그인 및 다른 인증을 가질 수 있다. 이러한 정보는 선호를 통하여 상세 서버에 보내질 수 있다. 소정의 모듈 생성자를 위해 특정한 사용자 선호를 생성하는 기능, 상세 서버에 보내지는 익명의 사용자 식별을 생성하는 기능, 상세 서버를 위해 IFRAME 내에 쿠키를 위치시키는 기능, 사용자당 로그인 스크린을 포함하는 기술, 및 다른 그러한 기술이 이러한 시스템을 돕기 위해 또한 사용될 수 있다.

JavaScript 선호 인터페이스는 전달되는 사용자 선호를 획득하기 위한 JavaScript-기반의 모듈에 포함될 수 있다. 이러한 인터페이스는 다음을 포함하는 다수의 JavaScript 함수들을 포함할 수 있다.

이름	기술
_Container_Prefs(moduleId)	선호 구성자. 모듈 ID를 인자로서 취한다. 예를 들어, var prefs = new _Container_Prefs(MODULE_ID);
getString(name)	이름으로 식별되는 사용자 선호를 스트링 값으로서 검색한다.
getInt(name)	이름으로 식별되는 사용자 선호를 정수 값으로서 검색한다.
getBool(name)	이름으로 식별되는 사용자 선호를 논리 값으로서 검색한다.
getModuleHeight()	현재 모듈 높이를 픽셀 단위로 검색한다.
getModuleWidth()	현재 모듈 넓이를 픽셀 단위로 검색한다.
getUserId()	사용자를 위한 유일한 userId를 검색한다.
dump()	디버깅을 위하여, 모든 사용가능한 선호를 표시하는 document.writeln()을 사용한다.

부가하여, 선호 프로토콜에 관한 정보가 또한 사용될 수 있다. 예를 들어, 컨테이너 선호, 모듈 선호, 사용자 선호, 신디케이션 수신인 시스템 선호 및 신디케이션 수신인 시스템의 사용자는 모듈에 적용할 수 있는 선호를 지정할 수 있다. 프로토콜은 상충이 존재하면 어떤 선호가 다른 것들에 대하여 우선하는지를 결정하도록 확립될 수 있다. 예를 들어, 만약 컨테이너가 모듈을 100 * 120 픽셀로 제한하고 모듈 선호가 모듈이 그것보다 더 커야 한다고 지시하면, 컨테이너 선호는 모듈 선호를 무시할 수 있다. 또는, 만약 다른 시간대가 컨테이너, 사용자 시스템 및 신디케이션 서버에 적용되면, 신디케이션 서버의 시간대가 사용자 선호를 무시할 수 있다. 다른 프로토콜도 또한 가능하다.

원격 모듈 XML 파일에서 컨텐츠 섹션은 모듈의 컨텐츠 종류에 대한 정보를 포함한다. 예를 들어:

<Content type="url" href="http://www.placeontheinternet.com/cgi-

bin/asah/modules/igstats.cgi" />

</Module>

JavaScript 예시:

<![CDATA[<script language="JavaScript" src="http://

www.placeontheinternet.com/igoogle/modules/clock/clock.js"></script>

]]>

</Content>

</Module>

컨텐츠 섹션은 또한 순수한 HTML을 포함할 수 있다. 모듈 선호 속성 이름의 예시적 표가 아래에 나타난다.

이름	기술
type	컨텐츠의 종류를 제공하는 선택적 스트링. 가능한 값은 예를 들어, "html,""javascript,""xslt," 및 "url"일 수 있다. 디폴트는 "html"이다.
href	목적지 URL을 제공하는 선택적인 스트링. 디폴트 값은 ""이다.
cdata	상세의 데이터 발생 부분이 따라오는 것을 나타내는 선택적 스트링.

많은 모듈이 다른 서비스에 대하여 CGI-기반 프론트-엔드(front-ends)일 수 있다. CGI 스크립트를 설정하기 위해, 사용자는 디렉토리를 생성하고, 디렉토리에 예시적 CGI 스크립트를 복사하고, CGI 스크립트를 테스트할 수 있다.

크기조절형 벡터 그래픽 객체(Scalable Vector Graphics objects; 예를 들어, 매크로미디어 플래시, MPEG4 등), 비디오 플레이어, 오디오 플레이어 등은 객체에 대한 코드를 그것을 참조하고 호출하는 HTML으로 포장함으로써 모듈의 일부가 될 수 있다. 모듈 서버는 이러한 정보를 확인하고 플래시 객체의 포함에 기반하여 신뢰되지 않는 모듈을 결정하고 따라서 그것을 IFRAME 내에 제공할 수 있다. 그러한 모듈은 안전하다고 간주되고 인라인화될 수 있다.

모듈 생성자는 모듈을 업데이트할 수 있다. 따라서, 모듈 생성자는 사용자가 새로운 버전의 모듈에 대하여 배우고 및/또는 그것을 사용하기 시작하게 하는 일부 선택을 가질 수 있다. 예를 들어, 모듈 생성자는 같은 위치에서 새로운 버전의 모듈을 제공할 수 있으며, 따라서 컨테이너가 그 위치의 참조를 포함할 때 새로운 버전으로 업그레이드하게 사용자를 강제한다. 호출이 그 위치 참조에서 모듈 상세를 검색하도록 만들어질 때, 새로운 버전의 상세가 검색될 수 있다. 만약 모듈 생성자 및/또는 사용자가 강제적인 새로운 버전을 갖기를 원하지 않는다면, 새로운 버전은 Module Prefs 내 다른 위치 참조에서 사용가능하게 만들어질 수 있다. 그 다음 새로운 버전이 사용가능하다고 다양한 메커니즘을 통해서 사용자에게 광고될 수 있고, 사용자는 컨테이너 문서 내의 새로운 버전의 모듈을 식별하는데 사용하기 위한 새로운 위치 참조(예를 들어, URL)를 제공할 수 있다. 예를 들어, 모듈 생성자는 새로운 버전을 새로운 참조 로케이터(예를 들어, URL)에 공표할 수 있고, 그 다음 사용자에게 업그레이드 공지를 제공하기 위하여 오래된 위치 참조(예를 들어, URL)를 수정할 수 있다.

부가하여, 다양한 실시 형태에서, 모듈 상세는 모듈 생성자가 새로운 버전의 모듈이 생성되었음을 지시하게 해주는 필드 또는 선호를 포함할 수 있다. 모듈 서버는 그 다음 파싱 프로세스 동안 새 버전이 사용 가능하다는 광고를 식별하고 모듈 데이터 출력을 수정할 수 있다(예를 들어, 모듈 타이틀바에 확인 윈도우로의 링크와 함께 "업그레이드 가능"과 같은 표시를 주석으로 달고, 그러한 확인시 컨테이너 문서 내 사용자의 모듈 위치 참조를 더 새로운 버전으로 업데이트 함). 도시적 목적으로, 도 2 내의 모듈(105)은 "업그레이드 가능"(105a)의 선택을 포함한다. 새로운 버전으로 업그레이드하는 사용자 선택과 관련한 입력을 광고하고 및/또는 수신하기 위해서 모듈 데이터 출력을 수정하는 다른 방법은 또한 모듈 상세 내로의 정보 포함을 기반으로 가능할 수 있다. 부가하여, 사용자가 이전 버전을 회복하게 하는 선택을 제공하는 것이 가능할 수 있다. 예를 들어, 일부 사용자는 업그레이드를 좋아하지 않을 수 있고 또는 업그레이드가 수행상의 문제(예를 들어, 버그 등)를 가질 수 있다. 따라서, 모듈 서버는 자동으로(또는 모듈 상세 내 입력에 기반하여) 사용자가 이전 버전을 회복하는 선택을 제시할 수 있다. 도시적 목적으로, 모듈(106)에 "업그레이드 취소" 선택(106a)이 제공되어있다. 이것은 다른 업그레이드가 가능할 때까지 또는 무한히 미리 결정된 기간의 시간 동안 행해질 수 있다. 또한, "업그레이드 취소"의 반복적 선택은 선택을 모듈의 더 이전의 일부 버전으로 회복시킬 수 있다.

더 이전 버전의 위치 참조와 관련한 정보는 그 다음 모듈 서버에 저장되고 접근가능할 수 있으며 및/또는 그러한 위치 참조가 사용될 수 있도록 모듈 상세에 저장될 수 있다.

다양한 실시 형태에서, 상세 서버(16)는 따라서 지역 웹 서버(예를 들어, 아파치 서버)를 실행시킬 수 있고 또는 일반적으로 더 빠른 접속 응답을 제공하는 관리된 호스팅 기능을 사용할 수 있다. 디폴트로, 모듈 컨텐츠는 컨테이너 서버의 도메인으로부터 분리된 도메인 상에 호스트된 IFRAME 내에 제시될 수 있다. 예를 들어, IFRAME는 같은 또는 다른 컨테이너 서버에 의해 호스트될 수 있지만, URL의 다른 호스트 이름(또는 IP 주소)으로부터 제공될 수 있다. 이것은 (예를 들어) 컨테이너 서버의 도메인과 관련한 임의의 쿠키를 "훔치는" 것을 시도할 수 있는 해로운 모듈로부터 사용자를 보호하도록 도울 수 있다.

호스트 서버 시스템은 사전 경고 없이 신뢰되지 않은 HTML 인라인을 포함하기를 원하지 않을 수 있다. 만약 만들어진 인라인이 쿠키를 읽거나 수정할 수 있다면, 해로운 모듈은 만들어진 인라인이 읽기 또는 수정 쿠키일 때, 인증 증명을 포함하여 호스트 서버 시스템에 의해 설정될 수 있다. 해로운 모듈은 또한 컨테이너를 읽거나 수정할 수 있다(예를 들어, 호스트 서버 시스템과 관련한 개인화된 홈페이지). 그것은 또한 피싱(phishing; 예를 들어, 로그인 박스를 위조함) 또는 전체 페이지를 개인화된 홈페이지와 같이 보이는 피싱 사이트로 대체(document.location을 통함)하는 코드를 사용할 수 있다. 그것은 또한 불필요한 팝-업(pop-ups), 대화 박스 또는 무한 루핑 코드를 사용할 수 있다. 해로운 모듈은 또한 정보를 IFRAME에 보낼 수 있으며, 이것은 IFRAME에서 임의의 선행 문제들을 발생시킬 수 있다.

따라서, 다양한 실시 형태에 따라, 컨텐츠는 IFRAME에 위치될 수 있다. 보안의 부가적인 레벨로서, IFRAME 내의 컨텐츠는 숫자의 IP 주소상에 제공될 수 있다.

다른 레벨의 보호는 사용자 선호를 컨테이너 내 출력 HTML에서 발행되는 것으로부터 숨기는 스크립트의 라이브러리를 사용하는 HTML 종류 모듈을 포함할 수 있다.

모듈의 데이터를 만들기 위한 IFRAME의 사용에 부가하여, 다른 보안 형태가 사용될 수 있다. 예를 들어, 컨테이너 페이지의 사용자는 신뢰되지 않은 모듈을 컨테이너 페이지에 부가할 때 위험을 승인하도록 요구될 수 있다. 또한, 신뢰되지 않은 모듈이 일부 방식(예를 들어, 색 있는 테두리와 같은 비주얼 경계)으로 표시될 수 있다. 부가하여, JavaScript alert(), confirm(), 및 prompt() 함수와 같은 다양한 함수가 일 실시 형태에서 실제 컨텐츠 전에 더미(dummy) 함수 정의(예를 들어, function alert() {;})을 삽입함으로써 IFRAME 내에서 기능을 하지 못할 수 있다. 컨텐츠 내 부가적인 IFRAME는 이러한 기능 불능을 우회하는데 사용될 수 있기 때문에, 컨테이너는 IFRAME을 포함하거나 JavaScript eval() 함수를 사용하는 모듈의 포함을 거부할 수 있다.

도시적 인라인 생성 프로세스

본 발명의 다양한 실시 형태에 따라, 모듈의 컨텐츠를 컨테이너의 인라인으로 제시하는 것이 바람직할 수 있다. 여기에 논의된 바와 같이 컨테이너에 컨텐츠를 인라이닝하는 것과 관련된 위험요소가 존재한다. 따라서, 시스템에 의해 "신뢰"되면 모듈이 인라인된 컨테이너가 되게 하는 것이 바람직할 수 있다.

모듈은 다양한 알려진 기술을 통하여 안전하다고 통계적으로 증명된 HTML 및 다른 코드를 사용하는지 여부를 포함하는 다양한 기술에 따라 신뢰된다고 간주될 수 있다.

시스템에 대한 충분한 레벨의 신뢰를 획득하기 위한 다른 방법은 디지털 서명을 기반으로 한 방법론을 포함할 수 있다. 하나의 도시적 예의 방법론이 도 9에 제시될 수 있다. 이 프로세스(900)는 수많은 하나 이상의 블록들을 포함할 수 있다. 블록(902)에서, 디지털 서명이 생성될 수 있다. 디지털 신호를 생성하기 위한 다양한 함수 및 기술이 알려져 있고 여기에 사용될 수 있다. 하나의 그러한 시스템은 입력으로서 다양한 데이터를 취하고, 이러한 입력에 근거하여, 특정한 목적(즉, 어떠한 두 사람도 같은 디지털 서명을 갖지 않음)을 위해 유일한 일련의 숫자를 임으로 발생할 수 있다.

디지털 서명은 모듈의 검증에 기반하여 컨테이너 서버 및/또는 호스트 서버 시스템에 의해 제공될 수 있다. 일 실시 형태에서, 모듈의 컨텐츠는 IFRAME과 또는 javascript "src=" 문장과 같은 임의의 외부 컨텐츠를 포함하지 않을 때에만 유효할 수 있다. 모듈을 유효화하거나 인증하는데 있어서, 모듈은 컨테이너 서버 및/또는 호스트 서버 시스템과 관련된 사람 또는 그러한 운영자에 의해 승인된 사람에 의해 수동으로 조사될 수 있다.

블록(904)에서, 모듈의 생성자는 그러한 디지털 신호를 모듈에 편입할 수 있다. 블록(906)에서, 모듈의 생성자는 모듈이 인라인 발생을 원함을 나타내는 코드로 그러한 모듈 설계 상세를 업데이트할 수 있다. 이러한 것이 발생할 때, 컨테이너 서버에 의해 만들어질 때 모듈은 컨테이너와 인라인으로 제시된다.

사용자 스크린상의 다른 모듈 인스턴스와 상충을 피하기 위해서, _MODULE_ID_ 는 모든 HTML 이름/IDs 및 모든 JavaScript 함수 및 글로벌 변수에 부가될 수 있다. 예를 들어, var myvariable=5는 var myvariable_MODULE_ID_=5가 된다. 실행 시간(run time)에, 모듈 컨텐츠 내의 모든 _MODULE_ID_ 스트링은 그 모듈에 대한 유일한 id로 실행 시간에 대체되고, 신뢰되지 않은 모듈이더라도 대체된다.

사용자 선호는 아래에 서술된 선호 인터페이스를 사용하는 인라인된 또는 IFRAME된 모듈로부터 접근될 수 있다.

// _MODULE_ID_token을 사용하여 구조화될 수 있다. 그것은

// 실행 시간에 원격 모듈의 실제 ID로 대체될 수 있다.

var prefs=new_Container_Prefs(_MODULE_ID_);

var someStringPref=prefs.getString("StringPrefName");

var someIntPref=prefs.getInt("IntPrefName");

var someBoolPref=prefs.getBool("BoolPrefName");

</script>

인라인된 모듈 및 IFRAME된 모듈 양자가 그들의 컨테이너 크기(크기 재조정 이벤트를 위함)를 얻기 위해 같은 인터페이스를 사용하도록 허가하기 위해서, 양자는 인위적 <div> 내에 위치될 수 있다.

도시적 선호 저장

본 발명의 다른 실시 형태에 따라, 데이터베이스(20)에 저장된 데이터 요소 들 중 하나는 선호를 포함할 수 있다. 특히, 개인화된 컨테이너 문서를 가지는 시스템의 사용자 각각에 대하여 선호가 저장될 수 있다. 부가하여, 선호는 사용자의 개인화된 컨테이너 내에 하나 이상의 모듈과 관련되어 저장될 수 있다. 일 실시 형태에 따라, 시스템은 사용자 선호에 대한 많은 양의 저장 공간을 할당할 수 있다.

도 10은 두 사용자에 대한 선호의 예를 도시한다. 이 예시에서, 실명이 아닌 사용자명이 밥 브라운인 한 명의 사용자는 그의 컨테이너 내에 포함을 위해 설계된 세 개의 모듈을 가진다. 각각의 모듈은 식별자(예를 들어, 숫자적 식별자 또는 데이터가 저장되는 데이터베이스로의 인덱스) 및 위치 참조에 의해 식별될 수 있다. 이러한 예시에서, 위치 참조는 인터넷상의 웹사이트에 위치된 XML 파일의 URL이다. 부가하여, 이러한 특정 모듈을 위하여, 다양한 선호가 저장될 수 있다. 이러한 예시에서, 선호는 다음과 같이 저장될 수 있다: 이름이 밥이고, 그의 선호 색은 파란색이고, 및 그의 가장 좋아하는 샌드위치는 루벤이다. 이러한 선호는 www.smith.com의 모듈을 위한 모듈 상세에 기반하여 저장될 수 있다. 보다 상세하게, smith.com 모듈은 선호가 이름, 주소 및 연령을 포함할 수 있다는 것을 지정할 수 있다. 일 실시 형태에서, 모듈 상세에 지정된 선호만이 선호 데이터베이스에 저장될 수 있다. 다른 실시 형태에서, 사용자가 제공한 모든 선호는 선호 데이터베이스 내에 이러한 모듈 엔트리(entry)와 관련되어 저장될 수 있다. 예를 들어, 만약 Smith.com 모듈 상세가 이름 및 색깔 선호 정보만을 요구하고 과거에 샌드위치 정보를 요구한 적이 있었다면, 이러한 모듈에 대한 선호 엔트리가 연령 정보를 저장하는 것이 가능하다. 그 정보가 모듈에 전달될 때, 그러한 선호 정보는 모듈에 의 해 사용되지 않기 때문에, 모듈은 그것을 단순히 무시할 수 있다. 또한, 시스템은 모듈과 관련된 선호를 추적할 수 있고, 모듈과 관련되어 저장되었지만 더 이상 관련없는 임의의 선호를 선호 데이터베이스로부터 제거할 수 있다.

도 10에 도시한 바와 같이, 엔트리는 개인화된 컨테이너를 수신하기 위해 시스템에 접근하는 개별 사용자에 제공될 수 있다. 부가하여, 이러한 도 10은 선호가 개별 모듈에 대하여 복제될 수 있다(예를 들어, 밥이라는 이름은 Mr. Bob Brown에 대한 세 모듈의 각각에 관련되어 저장된다)고 도시하지만, 선호는, 선호가 적용되는 모듈을 참조하여, 사용자와 관련된 글로벌 테이블에 저장될 수 있다. 사용자용 컨테이너 내에 포함될 다양한 모듈에 관련된 선호를 저장하는 임의의 다른 테크닉이 본 발명의 범위 내에서 또한 사용될 수 있다.

일 실시 형태에 따라, 다른 보안 특징이 선호 저장과 관련하여 구현될 수 있다. 특히, 사용자에 대한 선호 값이 다양한 모듈에 저장될 수 있기 때문에, 모듈은, 사용자 및/또는 모듈 생성자가 원하지 않는다면, 다른 모듈에 사용되는 선호를 수정할 수 없어야 하는 것이 중요하다(예를 들어, 통상 제공되는 사용자 우편 코드 선호에 기반한 거리 맵상에 날씨 맵을 중첩하여 표시하는 맵 모듈과 날씨 모듈과 같이 함께 동작하는 두 모듈).

따라서, 선호를 설정하기 위하여, 일 실시 형태에서 모듈 서버는 IFRAME 내에 토큰을 포함시키거나 또는 HTML 내에 모듈의 코드를 포함시킬 수 있다. 인라인 시스템을 위하여, 토큰은 모듈 및 사용자가 이미 신뢰되었다고 간주되기 때문에, 디지털 서명을 포함할 수 있다. 인라인된 모듈은 그 다음 다른 모듈, 컨테이너 또 는 그 자체를 수정할 수 있다.

덜 신뢰된 모듈상에 제공될 수 있는 IFRAME들을 위하여, IFRAME에는 컨테이너 서버와 관련된 쿠키 및 그 쿠키 내에 포함될 수 있는 임의의 관련 승인없이, 숫자의 IP 주소가 제공될 수 있다(이는 인라인 제시와 반대되는데, 인라인 제시에서는 컨테이너에 의해 설정된 모든 쿠키가 페이지 상에서 인라인으로 실행되는 모듈에 접근가능하며, 컨테이너 사용자 식별 및/또는 모듈 식별을 포함하는 쿠키도 포함한다).

따라서 IFRAME이 제시된 모듈에 대하여, 컨테이너 및/또는 모듈 및/또는 사용자에 대한 정보를 포함하는 토큰이 발생될 수 있다. 따라서, IFRAME에는 모듈 식별(예를 들어, 표시되는 모듈의 인덱스) 및/또는 컨테이너 사용자 식별(암호화될 수 있음)이 제공될 수 있다.

토큰은 IFRAME에 전달될 수 있고, 그러면 모듈은 선호를 수정하고 부가하고 또는 제거하는 임의의 요청과 함께 그 토큰을 되돌려주도록 기대될 수 있다. 토큰은 알려진 토큰 기술에 따라 발생될 수 있으나, 하나의 도시적 예시가 다음과 같이 계산된다. 여기에서 K1 및 K2 는 서버에 비공개인 영수(alphanumeric) 문자일 수 있다.

Data = Encrypt_K1(Compress(ContainerUserId + ModuleId + Timestamp))

Signature = HMAC_K2(Data + ModuleUrl)

Token = Data + Signature

선호를 수정하고, 부가하고 또는 제거하는 요청이 수신될 때, 모듈 서버는 데이터를 해독하고, 타임스템프가 미리 결정된 발행의 시간 기간(예를 들어, 15분)내에 있다는 것을 검증하고, 컨테이너 사용자 식별 및 모듈 식별을 찾고, 서명 및 암호화된 데이터를 계산하고, 그 다음, 모든 것이 일치하고 모든 요청된 업데이트 파라미터가 정확한 모듈 식별을 참조한다면 모듈 식별을 사용하여 선호를 업데이트할 수 있다. 모듈 식별은 또한 모듈의 개별 버전에 대하여 생성될 수 있다. 따라서, 모듈 위치 참조는 토큰에서 전달되지 않고, 암호화(예를 들어, HMAC 암호화)를 발생하는 계산에 사용될 수 있다.

타임스탬프는 부가적인 보안을 제공하기 위해 사용될 수 있다. 그것은 만약 비승인된 사용자가 특정 인스턴스상의 토큰을 해독할 수 있다면 발생될 수 있는 손상을 제한하기 위해 제공할 수 있다. 토큰 내의 모든 것은, 더 낮은 레벨의 보안이 또한 사용될 수 있음에도, 부가적인 보안을 위해 암호화될 수 있다.

예를 들어, 모듈 내의 JavaScript는 토큰 시스템의 사용을 통하여 사용자/모듈에 대한 선호 정보를 프로그램적으로 저장하기 위해 생성될 수 있다. 그러한 모듈은 사용자가 지시할 필요없이, 유효한 토큰으로(예를 들어, 허가된 타임 스탬프 범위 내에) 데이터를 선호 저장에 전달할 수 있다. 예를 들어, 사용자에게 작업을 제공하는 모듈은, 모듈을 통한 새로운 작업의 엔트리시 새롭게 부가된 작업을 선호 저장에 자동으로 업로드할 수 있다. 작업 목록은 그 다음 선호 저장에 저장될 수 있다.

다른 도시적 예시에 따라, 선호 정보는 하나 이상의 원격 모듈들로부터 데이터를 발생하는데 사용될 수 있고 그러한 정보는 그 다음 다른 원격 모듈에 제공될 수 있다. 예를 들어, 하나 이상의 지리학적 위치와 관련된 선호 정보가 저장될 수 있다. 그러한 하나 이상의 지리학적 위치는 맵 서버(39)에 제공될 수 있는 정보를 발생하도록 원격 모듈에 제공될 수 있다. 이후에 맵 서버(39)는 지리학적 위치 정보에 기반한 데이터가 중첩되고, 장소의 위치, 장소의 이미지 등을 포함하는 맵을 생성할 수 있다. 또한 맵 서버(39)는 이러한 정보를 획득하고 그것을 매핑 출력 또는 다른 출력을 발생할 수 있는 다른 원격 모듈에 제공할 수 있다.

하나의 특정한 예시에서, 캘리포니아의 샌프란시스코와 같은 스트링은 선호 정보 내에 제공될 수 있다. 그러한 스트링은 지오코드 서버(37)를 사용하여 지오코드 위치로 전환되고, 원격 모듈에 전달될 수 있다. 지오코드 위치는 위도 및 경도 값을 포함할 수 있다. 원격 모듈은 맵 서버가 캘리포니아의 샌프란시스코를 맵상에 강조한 세계 맵을 표시할 수 있도록 데이터를 발생할 수 있다. 만약 "식당"과 같은 다른 선호 정보가 제공되면, 샌프란시스코 근방의 식당 위치가 맵상에 표시될 수 있다. 많은 다른 예시들이 본 발명의 사상 범위 내에서 분명히 가능하다.

도시적 프락시 서버 수집 시스템

본 발명의 다른 실시 형태에 따라, 컨테이너 문서에 편입된 모듈을 활용하여, 표적 사이트로부터 데이터를 수집하고 그것을 사용자가 바라는 표시 방식으로 재포맷하는 방법이 실현될 수 있다. 예를 들어, 사용자가 골프의 열렬한 팬이고 정기적으로 골프 웹사이트에 간다고 가정해보자. 그러나 골퍼는 단지 골프를 어떻게 치는지에 대한 기사 및 정보에만 관심이 있고, PGA 투어에 관한 이벤트 및 다른 전 문적인 골프 이벤트에 대하여 관심이 없다. 모듈은 골프 사이트로부터 데이터를 수집하는 스크립트로 설계되고, 골프 웹사이트로부터 수집된 데이터를 수정하고 조작하는 코드를 적용하여 컨테이너 내 제시를 위한 데이터를 발생할 수 있다. 골프 웹사이트로부터 데이터를 수집하기 위해 모듈에 의해 사용되는 코드를, 골프 웹사이트는 로봇 또는 다른 비승인된 접근 방법으로서 볼 수 있다. 이것은 만약 요청이 골프 웹사이트와 익숙하지 않은 소스로부터 발생한다면 특히 사실일 수 있다. 예를 들어, 만약 그러한 모듈의 생성자가 웹사이트의 알려지지 않은 운영자라면, 이러한 요청은 골프 웹사이트에 의해 차단되거나 배제될 수 있다.

호스트 서버 시스템의 운영자는 개별 골프 사이트에 또는 큰 커뮤니티에 알려진 존재일 수 있다. 따라서, 이러한 사이트로부터의 데이터의 요청은 일반적으로 배제될 수 없다. 컨테이너 사이트와 관련된 신뢰를 활용하기 위해, 모듈 생성자 시스템을 대리하여 골프 사이트(예를 들어, 표적 수집 사이트)로부터 정보를, 호스트 서버 시스템(프락시 서버 주소)과 관련된 서버를 사용하여 요청하도록 프락시 서버가 사용될 수 있다. 그 다음 골프 사이트로부터의 정보는 모듈 생성자 시스템에 의해 수신될 수 있고, 모듈 생성자에 의해 요구되는 포맷으로 조작될 수 있다. 조작은 예를 들어, PGA 토너먼트와 관련된 모든 기사를 페이지상에서 제거하고, 아마추어 골핑에 대한 정보를 강조하고, 텍스트 내 용어의 이름을 모듈 생성자에 적합하도록 대체하고(7 아이언(iron)을 매시 니블릭(mashie niblick)으로 대체), 페이지 내 컨텐츠를 모듈 생성자에 적합하거나 또는 모듈 생성자가 표적 수집 사이트로부터의 데이터에 적용하기 원하는 임의의 다른 수정, 대체, 대치, 삭제, 추가 또는 동작에 적합하도록 재배열하는 것을 포함한다.

그러한 시스템의 하나의 도시적 실시 형태가 도 11에 제시되어 있다. 도 11은 도 1에 관련하여 기술된 요소간의 배치 및 관계가 도 11에 또한 적용해야 한다는 점에서 도 1과 관련하여 이해되어야 한다. 도 11에 나타나는 바와 같이, 프락시 서버(52)는 모듈 서버(32) 및 컨테이너 서버(12)와 연관하여 동작할 수 있도록 제공될 수 있다.

상세 서버(24)는 모듈 생성자 시스템(54)으로서 또한 동작할 수 있다. 부가하여, 표적 컨텐츠 서버(56)가 도시되어 있다. 상기에 논의된 바와 같이, 일 실시 형태에서, 모듈 상세는 상세 서버(24)에 접근 가능한 곳에 저장될 수 있다. 컨테이너가 컨테이너 서버(12)에 의해 오픈될 때, 표적 수집 모듈이 식별될 수 있다. 그 다음 모듈 서버(32)는 모듈에 데이터를 제공하기 위해 호출될 수 있다. 모듈 서버(32)는 상세 서버가 네트워크상에 상세 서버(24)의 위치에 위치되는 것을 결정할 수 있다. 표적 수집 모듈에 대한 코드는 상세 서버(24)로부터 모듈 서버(32)에 의해 검색될 수 있다. 그 다음 그러한 코드는 사용자에게 표시되도록 컨테이너 서버(12)에 전달된다. 사용자 시스템(22)은 모듈을 오픈할 수 있고, 모듈 데이터 내의 코드를 기반으로 프락시 서버(52)로부터 데이터의 요청을 전송하여 표적 컨텐츠 서버(36)로부터 데이터를 검색할 수 있다. 표적 컨텐츠 서버(56)로부터의 데이터는 프락시 서버(52)에 제공될 수 있고, 그 다음, 모듈 내의 부가 코드가 모듈 내 코드에 기반하여 그 데이터를 수정 및/또는 조작할 수 있는 사용자 시스템에 제공될 수 있다. 그 데이터에 대한 임의의 수정 또는 조작은 상세 서버(24)에서 발생할 수 있고, 그 다음, 데이터는 사용자에게 데이터를 발생시키는 컨테이너 서버(12)에 제공하기 위하여 모듈 서버(32)에 제공될 수 있다.

인터넷상의 많은 시스템이 선호하지 않는 오픈 프락시로서 사용되는 프락시를 피하기 위해서, 프락시 서버(52) 및 브라우저 시스템은, 선호의 업데이트와 관련하여 상기에 기술된 바와 같이 토큰의 사용과 같은 인증 기술을 택할 수 있다. 프락시 서버(52)는 지정되고 유효한 토큰이 사용자 시스템으로부터 전달될 때, 요청을 수행할 수 있는데, 토큰이 사용자 시스템에 제공된 모듈 코드의 일부이기 때문이다. 부가하여, 프락시 서버 및 사용자 시스템상에서의 캐싱은 데이터의 전달을 촉진하고 표적 사이트 서버에 대해 이루어지는 호출의 수를 줄이는 데에 사용될 수 있다.

프락시 서버(52)가 또한 인터넷을 통하여 다른 시스템에 접속할 수 있다는 것이 고려되어야 한다. 일 실시 형태에서, 프락시 서버(52)는 호스트 서버 시스템(10)에 관련한 어드레스 및/또는 호스트 서버 시스템(10)에 의해 승인되거나 인증되거나 확인된 주소를 활용하여 호스트 서버 시스템(10)의 명성을 이용함으로써 표적 컨텐츠 서버(56)가 데이터와 함께 응답하도록 한다.

도시적 프락시 방법(1200)이 도 12에 제시되어 있다. 블록(1202)에서, 컨테이너 문서가 오픈될 수 있다. 블록(1204)에서, 모듈은 표적 사이트로부터 데이터를 수집하는 코드를 포함하는 모듈이 식별될 수 있다. 블록(1206)에서, 모듈 컨텐츠는 모듈 서버(32)에 의해 HTML의 형태로 사용자에 전달된다. 블록(1208)에서, 사용자 시스템(예를 들어, 브라우저)은 표적 수집 사이트로부터 데이터를 수집하기 위한 코드(예를 들어, 데이터를 수집하고 조작하기 위한 JavaScript)를 포함하는 HTML을 해석한다. 블록(1210)에서, 사용자 시스템은 표적 사이트 데이터의 수집 요청을 프락시 서버에 전달한다. 많은 브라우저는 기반하는(underlying) HTML을 보내는 서버와 다른 서버를 호출하는 스크립팅 언어(예를 들어, JavaScript)상에 동작하지 않을 것이라는 점이 주목되어야 한다. 따라서, 프락시 서버 및 컨테이너 서버가 공통 서버와 관련될 수 있기 때문에, 브라우저는 요청을 처리한다.

블록(1212)에서, 프락시 서버는 표적 사이트로부터 데이터를 수집하고 그것을 사용자 시스템에 전달한다. 하나의 도시적 실시 형태에 따라, 트롤러(trawler)로서 언급되는 프로그램이 표적 사이트로부터 데이터를 수집하는데 사용될 수 있다. 그러한 서비스는 일반적으로 웹 검색 엔진에 의해 사용되는 웹 페이지 데이터를 캐싱하는데 사용되는 기술과 유사한 소위 로봇 배제 정보 및 호스트 로드 이슈(host load issue)를 존중한다. 블록(1214)에서 사용자 시스템은 표적 사이트로부터 수집된 데이터를 모듈 상세 내의 코드를 기반으로 조작하고 그렇게 조작된 표적 사이트 데이터를 기반으로 표시 데이터를 발생한다. 블록(1216)에서, 사용자 시스템은 모듈에 의해 지정된 포맷으로 조작된(선택적임 - 데이터는 조작없는 표적 사이트 데이터일 수 있음) 표적 사이트 데이터와 함께 컨테이너 문서를 표시한다.

다른 실시 형태에 따라, 프락시 서버(52)는 프락시 요청의 맥락에서 상기에 서술된 기능을 수행하는 분석 모듈(26)에 동작적으로 접속되거나 포함할 수 있다. 예를 들어, 프락시 서버(52) 및 분석 모듈(26)은 비승인된 사이트, 비승인된 동작, 비승인된 컨텐츠 등의 목록에 대하여 요청을 분석할 수 있다. 부가하여, 요청은 승 인된 사이트, 동작, 컨텐츠에 대하여 비교될 수 있다. 평가는 위치 참조(예를 들어, URL) 또는 표적 사이트, 요청의 포맷, 표적 사이트에 제공될 선호 값, 시간, 사용자 정보, 모듈 상세 소스, 요청 시스템 또는 임의의 다른 입력에 기반할 수 있다.

다른 실시 형태에 따라, 모듈 상세는 프락시 서버를 제어할 수 있는 명령을 제공할 수 있다. 프락시 서버(52)는 동작을 위해 그러한 명령을 사용할 수 있다. 하나의 명령은 캐시된 버전을 사용하는 대신 새로운 사본을 제공하는 것과 같이, 어떻게 프락시 서버가 표적 사이트로부터 데이터를 획득해야 하는지를 지시할 수 있다. 언제 캐시를 비우고 또는 캐시를 업데이트 하는지 지시하는 것을 포함하는 다른 명령은 캐시 및 그것의 동작을 제어할 수 있다.

다른 실시 형태에 따라, 표적 사이트는 프락시 서버 동작을 제어할 수 있고 또는 프락시 서버가 어떻게 동작하는 것을 선호하는지에 대한 지시를 적어도 제공할 수 있다. 프락시 서버가 어떻게 동작하는지 또는 프락시 서버가 데이터를 전혀 수집할 수 없다는 것을 지시하는 로봇 배제 파일(예를 들어, robts.txt)이 포함될 수 있다. 프락시 서버(52)는 표적 사이트에 의해 제공되는 명령을 존중할 수 있다. 메가 태그(Mega tags)는 또한 표적 사이트에 의해 제공될 수 있다. 명령을 제공하는 다른 방식이 또한 제공될 수 있다.

제공된 명령은 재생 속도(refresh rate), 언제 또는 무엇을 위하여 프락시 서버(52)가 컨텐츠를 수집할 수 있는지에 대한 속성(예를 들어, 사용자의 목록, 모듈 상세(URL 또는 표시된 다른것에 의함), 수집될 데이터의 종류 등)을 포함하는 많은 사항을 프락시 서버(52)에 지시할 수 있다.

다양한 실시 형태에 따라, 데이터의 수정은 다중 표적 사이트 소스로부터 데이터를 취하고 결과를 모듈 출력으로 통합하는 것을 포함할 수 있다. 예를 들어, 모듈은 뉴스 소스로부터 데이터 공급을 취하고 블로그로부터의 컨텐츠와 통합하여 단일 출력으로 할 수 있다. 예시는 RSS/Atom 데이터 공급(feed)을 HTML 출력으로 포맷팅하고, 전송하고 및/또는 리포매팅하는 것을 포함할 수 있다. 즉, 예를 들어, 프로토타이핑(prototyping)을 위한 모듈을 생성하기 위해 웹페이지 HTML을 수집하고, 다중 웹 페이지 및/또는 데이터 공급으로부터 컨텐츠를 "혼합(mashing up)"하고, 국제화(internationalization)를 컨텐츠에 적용하고, 컨텐츠를 트랜스코딩(transcoding)하고, 더 쉬운 제시를 위해 "바쁜(busy)" 컨텐츠를 비우고, 다른 형태 등에 멀티미디어 컨텐츠를 가입시키는 것을 포함한다. 특정한 도시적 예시는, 신문 소스로부터 RSS 공급을 취하고, 폰트를 바꾸고 신문의 로고를 부가(즉, 특정한 중요 단어 또는 구를 언급하는 헤드라인을 강조하고, 소설의 기사를 주기적으로 포함시킴)하는 것, 데이터 공급에서 장소 이름을 마우스-오버(mouse-over) 맵으로 변경하고, 상대적으로 활성인 웹 사이트로부터 데이터를 취하고, 사용자가 선택하는 필수 링크 및/또는 특징을 포함하는 모듈을 생성하는 것 등을 포함한다.

프락시 데이터의 수정을 통하여 발생된 데이터를 포함하는 컨테이너 문서의 하나의 도시적 예시가 도 13에 제시되어 있다. 점성(horoscope) RSS로부터 수집된 데이터를 포함하고 사용자에 대한 특정 텍스트로 수정되는 점성 모듈은 컨테이너 문서 내에 포함된다. 다른 프락시 서버의 예시는 뉴스, 날씨 및 맵이 포함될 수 있 는 "뉴스" 모듈 내에 도시된다. 여기에서, 뉴스 소스로부터의 텍스트가 수집되며, 수집으로 얻은 정보 중 용어 "조지 부시"가 강조된다.

설명된 바와 같이, 프락시 서버 및/또는 프로세스의 사용을 통하여, 다양한 이점이 실현될 수 있다. 모듈은 브라우저와 같은 사용자 시스템에 의해, 요구되는 다운로드 없이(소프트웨어의 다운로드가 본 발명의 범위 내에 분명히 가능함에도 불구함) 쉽게 사용할 수 있는 방식으로 사용자를 위해 발생될 수 있다. 사용자는 컨텐츠를 편입한 모듈의 분배 및 다양한 위치에서의 선전(promotion)을 통하여 컨텐츠를 발견하는 것이 가능하다. 프락시 기술을 사용하는 모듈은 시스템이 공표하는 툴의 세트를 통하여 쉽게 생성될 수 있다. 또한, 사용자 선호를 프락시하고 저장하기 위한 크기 조절이 가능한(scalable) 백엔드 서버의 제공은 또한 사용자에게 이러한 모듈의 이점을 제공한다.

다른 도시적 예시들

따라서, 본 발명의 다양한 실시 형태에서 호스트 서버 시스템에 대한 제 3자가 하나 이상의 호스트 서버 시스템에 의해 제공되거나 하나 이상의 호스트 서버 시스템에 의해 신디케이트되는 컨테이너상에 사용되는 모듈을 생성할 수 있다. 이러한 모듈은 이해하고 적용하기 쉬울 수 있는 상세에 따라 생성된다. 복잡한 모듈은 예를 들어, https, 인증, 크기 조절 지원, 장착 라이브러리로의 접근 등일 수 있고, 원격 컨텐츠 생성자는 소프트웨어 개발 키트(Software Development Kit; SDK)를 다운로딩하거나 익히지 않고 모듈을 개발하고 디버그할 수 있을 것이다. 일부 실시 형태에서, XML과 같은 표준화된 플랫폼이 사용될 수 있고, 따라서 사용되 는 실제 코드는, 모듈에 관한 데이터를 결국 표시하는 사용자 시스템에 의해 해석될 수 있는 임의의 코드가 될 수 있다. 예를 들어, JavaScript 및 더 많고 풍부한 라이브러리를 포함하는 다른 언어, 문서화, 예시적 모듈 및 더 나은 디버깅 기능에 대한 지원이 제공될 수 있다.

예를 들어, RSS/Atom 공급을 위하여 맞춤 만들기(custom rendering)를 수행하는 모듈을 위해 코드가 발생될 수 있다. RSS/Atom은 읽기 전용 컨텐츠를 웹에 공표하는 기술이고, 컨테이너 페이지상에 사용되는 많은 모듈은 종종 더 풍부한 상호작용을 제공하는 페이지로의 링크를 갖는 읽기 전용이다. 또한, 호스트 서버 시스템(10)은 모듈의 사용에 관한 리포팅을 가능하게 해주는, 모듈에 관한 데이터를 유지할 수 있다. 이 데이터는 모듈의 개별적 사용, 모듈의 이력, 모듈로의 수정, 모듈의 신디케이션, 금액에 관한 계좌 정보, 모듈에 관한 계약 및 모듈을 리포팅하는데 유용할 수 있는 많은 다른 종류의 정보 각각을 포함할 수 있다.

부가적인 모듈 종류가 XHTML 종류를 포함하여 또한 생성될 수 있고, 또는 다른 시스템으로부터의 모듈이 가능할 수 있다. 생성될 수 있는 부가적인 예시적 모듈은, RSS 정보를 취하고 그것을 예를 들어, 포토블로그로부터의 데이터를 포함하는 컨테이너 내에 포함시키기 위한 포맷으로 만드는 모듈을 포함한다. 다른 모듈은 Gmail, AOL Mail, MSN Hotmail 및 Yahoo! Mail과 같은 일반적인 웹-기반형 이메일 시스템을 위하여 이메일 리더(reader)를 포함할 수 있다. 모듈은 대화 데이터 및 인스턴트 메시징 데이터를 포함하도록 생성될 수 있다. 시계, 계산기, 노트패드 등의 간단한 애플릿이 모듈에 편입될 수 있다. 다른 모듈은 eBay, Amazon 및 다른 온 라인 시장과 같이, 상품의 구매자와 판매자를 위한 온라인 시장에 인터페이스로서 동작하도록 생성될 수 있다. 모듈은 또한 다양한 주체들(entities)에 대한 내부 데이터를 위해 생성될 수 있다. 예를 들어, 한 주체의 인트라넷 서비스는 컨테이너 내에 포함하기 위해 모듈로 만들어질 수 있다.

예를 들어, 검색 엔진, 이메일 등을 통하여 모듈 상세의 URL들을 교환하는 사용자들이 이러한 모듈을 사용할 수 있다. 부가하여, 인터페이스는 다른 페이지상 요청의 입력을 통하여, 다양한 특징이 컨테이너에 부가되도록 허가할 수 있다. 예를 들어, 골프 사이트에서, "모듈로서 컨테이너에 부가"를 표현하는 링크 또는 버튼이 존재할 수 있다. 컨테이너는 미리 지정될 수 있거나 사용자로부터 입력이 될 수 있다. 그러한 링크 또는 버튼은 코드에 기반하여 동작되고, 이 코드는 사용자가 그들의 개인화된 홈페이지와 같은 그들의 컨테이너상에 그러한 컨텐츠를 포함하도록 하는 수단으로서 기반(underlying) 페이지의 생성자에 의해 포함된다.

부가하여, 모듈의 인덱스는 검색 시스템으로 모듈 정보를 제공하는 것을 통해 생성될 수 있고 이러한 제공은 컨테이너 문서가 모듈 상세를 검색할 때 모듈 정보가 컨테이너 서버에 의해 검색 시스템으로 전달되어 달성된다.

또한, 모듈의 사용자, 컨테이너 문서 제공자, 표적 사이트 운영자, 시스템 및/또는 네트워크에 연관된 다른 주체에 의해 제공되는 정보를 포함하여, 피드백, 통계, 모듈에 관한 다른 데이터를 수집하는 피드백 모듈이 제공될 수 있다. 이러한 정보 및 데이터는 순위 모듈 또는 다른 모듈을 통하여 사용자에 제시될 수 있다. 순위 모듈은 피드백, 승인, 사용, 통계 또는 다른 기준에 기반하여 모듈을 순위 매 길 수 있고 사용자 또는 편집상의 주석을 기반으로 한 순위를 포함할 수 있다.

또한, 모듈은 사용자 또는 컨테이너 페이지에 관한 입력을 기반으로 제안될 수 있고, 입력은 검색 이력, 보여지는 문서 내의 중요 단어 등을 포함한다. 다른 기술이 또한 신디케이션을 위한 모듈을 촉진하는데 사용될 수 있다.

다른 도시적 예시에서, 모듈이 신뢰되었다는 결정에 기반하여, 사용자가 컨테이너 문서의 소정의 요소를 개인화하는 것(예를 들어, 사용자의 이름, 이미지, 특징, 로고 등을 추가함)을 허가하도록 컨테이너 문서를 수정하여 모듈을 생성할 수 있다. 다른 도시적 예의 모듈은 컨테이너 페이지와의 상호작용을 통하여 컨테이너 페이지상의 다른 모듈의 목록을 획득하고, 예를 들어, 모듈(들)을 수정하는 능력을 포함하여 모듈(들)에 대한 메타데이터(metadata)를 획득하고, 모듈(들)에 대한 사용자 선호를 획득할 수 있다. 개발자 모듈은 테스팅을 목적으로 다른 모듈, 갱신 모듈(예를 들어, 캐시를 플러시(flush) 또는 재개함) 및 다른 동작들을 인라인 또는 IFRAME하기 위해 개발될 수 있다.

본 공개는 여기에 서술된 특정 실시 형태에 의한 범위에서 제한되지 않는다. 또한, 본 공개의 다른 다양한 실시 형태 및 수정이 여기에 서술된 것들에 부가하여 전술한 서술 및 첨부 도면들로부터 당 업계의 일반적 기술자들에게 명백할 것이다. 따라서, 그러한 다른 실시 형태 및 수정은 본 발명의 범위 내에서 이루어지도록 의도된다. 또한, 본 발명이 여기에 특정한 목적을 위하여 특정한 환경에서 특정한 실시 형태의 맥락에서 서술되었지만, 당 업계의 일반적인 기술자들은 그것의 유용성이 거기에 제한되지 않고 본 공개가 임의의 수의 목적으로 임의의 수의 환경에서 유용하게 실시될 수 있다는 것을 인식할 것이다. 따라서, 아래의 청구항은 여기에 서술된 바와 같이 본 공개의 총 범위에서 구조화되어야 한다.

본 발명에 의하면 컨테이너 문서에 컨텐츠를 제공하기 위한 시스템 및 방법을 제공할 수 있다. 시스템은 컨테이너 문서를 사용하기 위해 하나 이상의 모듈을 식별하는 컨테이너 서버를 포함하고, 원격 서버로부터 모듈 상세를 수신하며, 그러한 모듈 상세에 기반하여 모듈 데이터를 포함하는 컨테이너 문서를 제공한다. 모듈 상세는 컨텐츠 요소 및 컨테이너 서버가 모듈을 선호하게 해주는 하나 이상의 선택적 선호 요소를 포함한다.

Claims

컨테이너 문서에 있는 컨텐츠를 제공하는 시스템으로서,

사용자와 연관된 컨테이너 문서에 포함시키기 위해 선택적으로 지정된 복수의 모듈을 식별하고, 상기 복수의 모듈을 위한 컨텐츠를 생성하는 데 사용하기 위한 모듈 데이터를 검색하기 위해 원격 서버에 요청들을 전송하는 컨테이너 서버 수단으로서, 상기 식별된 모듈들 각각은 프로세서 및 저장 디바이스를 포함하는 상기 원격 서버와 연관되어 있고, 상기 컨테이너 문서는 컨테이너 문서 디스플레이에서 복수의 모듈과 연관된 컨텐츠를 표시하기 위한 구성(organization)을 정의하고, 각 모듈에 있어서 상기 컨테이너 문서 디스플레이의 일부는 상기 각 모듈에 상응하는 컨텐츠의 표시를 위해 할당되는 상기 컨테이너 서버 수단; 및

원격 서버로부터 적어도 하나의 모듈 상세(module specification)를 수신하고, 상기 적어도 하나의 모듈 상세에 기초하여 상기 컨테이너 서버에 모듈 데이터를 제공하는 모듈 서버 수단으로서, 상기 모듈 데이터는 상기 컨테이너 문서 디스플레이에 표시하기 위해 상기 모듈을 위한 컨텐츠를 만들도록 원격 브라우저 클라이언트에 의한 실행을 위해 적응되는 컴퓨터-실행가능한 명령들을 포함하고, 상기 컴퓨터-실행가능한 명령들은 상기 컨테이너 문서에 의해 정의된 하나 이상의 파라미터들에 따라 생성되는 상기 모듈 서버 수단을 포함하고,

상기 컨테이너 서버 수단은 모듈 데이터를 가진 상기 컨테이너 문서를 상기 원격 브라우저 클라이언트에 제공하는 시스템.
청구항 1에 있어서,

상기 모듈 상세는 컨텐츠 요소 및 하나 이상의 선호 요소를 포함하고, 상기 컨테이너 서버는 적어도 부분적으로 상기 선호에 기반하여 모듈 데이터를 제공하게 하는 시스템.
청구항 2에 있어서,

상기 컨텐츠 요소는 모듈 데이터를 발생하는 코드가 발견되는 컨텐츠 위치 참조를 식별하는 값을 가지는 시스템.
청구항 1 내지 청구항 3 중 어느 한 항에 있어서,

상기 컨테이너 서버는 상기 모듈 상세의 변경을 식별하고, 변경되지 않은 모듈 상세에 상응하는 모듈 데이터를 갖는 상기 컨테이너 문서를 제공하는 시스템.
청구항 1 내지 청구항 3 중 어느 한 항에 있어서,

컨테이너 문서 내에 사용을 위해 모듈을 분석하는 분석 서버를 추가로 포함하는 시스템.
청구항 1 내지 청구항 3 중 어느 한 항에 있어서,

상기 컨테이너 문서는 웹 페이지의 적어도 일부분을 포함하는 시스템.
청구항 1 내지 청구항 3 중 어느 한 항에 있어서,

상기 컨테이너 문서는 사용자의 개인화된 홈페이지를 포함하는 시스템.
청구항 1 내지 청구항 3 중 어느 한 항에 있어서,

상기 모듈 상세는 디지털 서명 또는 토큰 중 적어도 하나를 포함하고, 상기 컨테이너 서버는 상기 디지털 서명 또는 상기 토큰 중 적어도 하나에 기반하여 상기 모듈 데이터를 인라인으로 표시하는 시스템.
청구항 1 내지 청구항 3 중 어느 한 항에 있어서,

순위 모듈 또는 피드백 모듈 중 적어도 하나를 추가로 포함하는 시스템.
청구항 1 내지 청구항 3 중 어느 한 항에 있어서,

사용자가 컨텐츠 종류, 컨텐츠, 하나 이상의 선호 및 상기 하나 이상의 선호에 대한 값을 지정하도록 하는 입력 서버; 및

상기 사용자 입력을 수신하고 컨테이너 문서와 함께 사용하기 위해 마크업(markup) 언어 포맷으로 모듈 상세를 발생하는 모듈 상세 생성 서버를 추가로 포함하는 시스템.
청구항 1 내지 청구항 3 중 어느 한 항에 있어서,

표적(target) 서버로부터 데이터를 수집하기 위한 요청을 수신하고, 상기 표적 서버로부터 데이터를 수집하고, 컨테이너 문서용 모듈 데이터를 발생하는데 사용하기 위해 상기 데이터를 전송하는 프락시 서버를 추가로 포함하는 시스템.
청구항 11에 있어서,

상기 프락시 서버는 상기 표적 서버로부터 수집된 데이터를 상기 수신 서버로 전송하는 시스템.
청구항 11에 있어서,

데이터를 수집하기 위한 상기 요청은 상기 프락시 서버에 대한 하나 이상의 명령들을 포함하고 상기 명령은 어떻게 상기 데이터를 표적 서버로부터 수집하는지에 대한 것인 시스템.
청구항 2에 있어서,

상기 선호 정보는 지리학적 위치를 식별하고, 상기 시스템은 상기 지리학적 정보에 기반하여 맵 출력을 발생하기 위해 맵 서버에 접근하는 매핑 모듈을 추가로 포함하는 시스템.
컨텐츠를 제공하는 방법으로서,

사용자와 연관된 컨테이너 문서에 포함시키기 위해 선택적으로 지정된 복수의 모듈을 컴퓨터의 동작에 의해 식별하는 단계로서, 상기 식별된 모듈들 각각은 원격 서버와 연관되고, 상기 컨테이너 문서는 컨테이너 문서 디스플레이에서 복수의 모듈과 연관된 컨텐츠를 표시하기 위한 구성을 정의하고, 각 모듈에 있어서 상기 컨테이너 문서 디스플레이의 일부는 상기 각 모듈에 상응하는 컨텐츠의 표시를 위해 할당되는 상기 식별하는 단계;

상기 복수의 모듈에 대한 컨텐츠를 생성하는데 사용하기 위한 모듈 데이터를 검색하기 위해 상기 원격 서버들에 요청들을 전송하는 단계;

상기 원격 서버들에 대한 요청들에 응답하여 상기 복수의 모듈 각각에 대한 모듈 데이터를 메모리에 수신하는 단계로서, 각 모듈에 대한 상기 수신된 모듈 데이터는 상기 컨테이너 문서 디스플레이에 표시하기 위해 상기 모듈에 대한 컨텐츠를 만들도록 원격 브라우저 클라이언트에 의한 실행을 위해 적응되는 컴퓨터-실행가능한 명령들을 포함하고, 상기 컴퓨터-실행가능한 명령들은 상기 컨테이너 문서에 의해 정의된 하나 이상의 파라미터에 따라 생성되는 상기 수신하는 단계; 및

상기 복수의 모듈의 모듈 데이터를 가진 컨테이너 문서를 상기 원격 브라우저 클라이언트에 제공하는 단계를 포함하는 방법.
청구항 15에 있어서,

컨테이너 문서와 함께 사용하기 위한 모듈과 관련된 사용자용 선호 정보를 상기 원격 서버로부터 수신된 상기 데이터로부터 식별하는 단계; 및

상기 선호 정보를 기반으로 맞춤화된(customized) 모듈 데이터를 제공하는 단계를 추가로 포함하는 컨텐츠를 제공하는 방법.
청구항 15 또는 청구항 16에 있어서,

사용자는 상기 컨테이너 문서와 함께 사용하기 위해 식별된 상기 모듈을 지정하는 컨텐츠를 제공하는 방법.
청구항 15 또는 청구항 16에 있어서,

표적 서버에 의해 수신된 발원 주소(originating address)를 사용하여 상기 표적 서버로부터 데이터를 수집하는 단계;

상기 표적 서버로부터 상기 데이터를 서버에 전송하는 단계로서, 상기 서버는 컨테이너 문서용 모듈 데이터를 발생하는데 상기 데이터를 사용하는 상기 전송하는 단계를 포함하는 컨텐츠를 제공하는 방법.
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제