KR20140009483A

KR20140009483A - 원격 모듈용 메시지 목록

Info

Publication number: KR20140009483A
Application number: KR1020137029897A
Authority: KR
Inventors: 크리스토퍼 에이치. 롤스; 아담 사; 딜란 파커; 제시카 린 그레이
Original assignee: 구글 인코포레이티드
Priority date: 2006-06-06
Filing date: 2007-06-06
Publication date: 2014-01-22
Also published as: WO2007145959A2; EP2033125A4; WO2007145959A3; EP2033125A2; KR20090016745A; KR20140065012A; US20070288488A1; KR101389969B1; US7730109B2; KR101444389B1; KR101477763B1

Abstract

원격 모듈들 내에 메시지 목록들을 통합시키는 시스템 및 방법이 제공된다. 이러한 시스템 및 방법은 컨테이너 서버를 포함하고, 컨테이너 서버는, 컨테이너 문서로 사용하기 위해 하나 이상의 모듈들을 식별하고, 원격 서버로부터 모듈 스펙을 수신하며, 모듈 스펙에 기반하여 모듈 데이터를 컨테이너 문서에게 제공하고, 이때, 상기 모듈 데이터는 메시지 목록을 식별하는 메시지 참조를 포함한다.

Description

원격 모듈용 메시지 목록{MESSAGE CATALOGS FOR REMOTE MODULES}

이 출원은 2006년 6월 6일 출원된 미합중국 특허출원번호 제11/422,429호를 우선권으로 주장하며, 본 명세서 내에 참조되어 본 발명의 일부를 이루고, 미합중국 특허출원번호 제11/422,429호는 2005년 12월 12일 출원된 "컨테이너 문서(container document)로의 원격 모듈 통합(Remote Module Incorporation Into a Container Document)"이라는 명칭의 미합중국 특허출원번호 제11/298,930호의 계속출원(CIP)이다.

본 발명의 실시예들은 원격 모듈(remote modules)용 메시지 목록(message catalogs)에 관한 것이다.

많은 웹사이트들은 홈페이지를 개인화할 수 있는 처리능력(capability)을 사용자들에게 제공한다. 통상적으로 이러한 웹사이트들은 웹사이트 운영자에 의해 설계되고 및 통합된 선택범위들로부터 선택된 미리 정해진 표시 형식으로 미리 정해진 정보 섹션(information section) 또는 데이터 섹션(data section)을 포함시킬 기회를 사용자에게 제공해오고 있다. 통상적으로 이러한 시스템들의 사용자는 상기 섹션 내에 컨텐츠를 개인화할 수 있는데, 예를 들면, 주식 가격을 보여주는 섹션에 포함시킬 특정 주식들을 선택할 수 있다. 이들 개인화된 홈페이지들은 매우 제한적인 호환성(limited flexibility)을 제공한다.

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

따라서 본 발명의 여러 바람직한 실시예들로서, 원격 모듈 내에서 메시지 목록과 통합하는 시스템 및 방법이 제공될 수 있다. 원격 모듈 시스템 및 방법은, 컨테이너 문서(container document)로 사용하기 위해 하나 이상의 모듈들을 식별하고, 원격 서버(remote server)로부터 모듈 스펙(module specification)을 수신하며, 상기 모듈 스펙에 기반하여 모듈 데이터(module data)를 상기 컨테이너 문서에 제공하는 컨테이너 서버(container server)를 포함하고, 상기 모듈 데이터는 메시지 목록을 식별하는 메시지 참조(message reference)를 포함한다.

다른 실시예에 따르면, 원격 모듈 시스템 및 방법은, 모듈(module)로 사용하기 위해서 특정하게 요청된 언어(requested language)의 메시지 목록(message catalog)에 대해서 요청자(requestor)로부터 요청을 수신하는 수신 서버(receiving server); 제1 언어로 메시지 목록을 검색하는 검색 서버(retrieving server); 상기 제1 언어가 상기 요청된 언어와 동일하지 않은 경우, 상기 메시지 목록을 상기 요청된 언어로 번역하는 번역기(translator); 및 상기 메시지 목록 또는 상기 메시지 목록의 메시지 참조를 상기 요청자에게 전송하는 전송 서버(transmitting server)를 포함할 수 있다.

다른 실시예에 따르면, 원격 모듈 시스템은, 컨테이너 문서(container document)에서 모듈 데이터(module data)를 생성할 때 사용하기 위해 원격 컨테이너 서버(remote container server)에 모듈 스펙(module specification)을 제공하는 모듈 스펙 서버(module specification server)를 포함할 수 있고, 상기 모듈 스펙 서버는 상기 모듈 스펙에 사용하기 위한 메시지 목록을 제공한다.

다른 실시예들이 고려될 수 있다.

도 1은 본 발명의 다양한 실시예들에 따른 전체적인 시스템 구조를 나타내는 도면이다.
도 2는 본 발명의 실시예에 따른 컨테이너 문서(container document)를 예시하는 도면이다.
도 3은 본 발명의 실시예에 따른 모듈(module)을 컨테이너(container)에 추가하는 동작흐름을 예시하는 도면이다.
도 4는 본 발명의 실시예에 따른 모듈을 식별하기 위한 인터페이스를 예시하는 도면이다.
도 5는 본 발명의 실시예에 따른 모듈 스펙 형식(module specification format)을 예시하는 도면이다.
도 6a는 본 발명의 실시예에 따른 모듈 스펙을 구비한 데이터의 예를 나타내는 도면이다.
도 6b는 본 발명의 실시예에 따른 대안적인 모듈 스펙을 구비한 데이터의 예를 나타내는 도면이다.
도 7은 본 발명의 실시예에 따른 데이터를 모듈로부터 컨테이너 문서에 통합하는 동작흐름을 예시하는 도면이다.
도 8은 본 발명의 실시예에 따른 모듈로부터 데이터를 생성하는 동작흐름을 예시하는 도면이다.
도 9는 본 발명의 실시예에 따른 컨테이너 문서 내에 인라인(inline)되도록 모듈을 인에이블시키는 동작흐름을 예시하는 도면이다.
도 10은 본 발명의 실시예에 따른 저장될 수 있는 우선순위 정보(preference information)의 종류의 목록을 예시하는 도면이다.
도 11은 본 발명의 실시예에 따른 시스템 구조를 예시하는 도면이다.
도 12는 본 발명의 실시예에 따른 모듈로부터 컨테이너 문서에 목표 서버 데이터(target server data)를 전달하는 동작흐름을 예시하는 도면이다.
도 13은 본 발명의 실시예에 따른 프록시 서버 모듈(proxy server module)을 통해 생성되는 출력을 갖는 모듈들을 구비하고 있는 컨테이너 문서를 예시하는 도면이다.
도 14는 본 발명의 실시예에 따른 배급(syndication)을 통해 모듈을 그 내부에 포함된 광고와 통합하는 써드파티(third party)의 웹사이트 실시예를 예시하는 도면이다.
도 15a는 본 발명의 실시예에 따른 메시지 목록으로부터 데이터를 통합하는 모듈 스펙을 구비하고 있는 모듈의 예를 나타내는 도면이다.
도 15b는 본 발명의 실시예에 따른 메시지 목록으로부터 데이터를 통합하는 모듈 스펙을 구비하고 있는 모듈의 예를 나타내는 도면이다.
도 16은 본 발명의 실시예에 따른 메시지 목록으로부터 데이터를 통합하는 모듈 스펙의 예를 나타내는 도면이다.
도 17a는 본 발명의 실시예에 따른 메시지 목록의 예를 나타내는 도면이다.
도 17b는 본 발명의 실시예에 따른 메시지 목록의 예를 나타내는 도면이다.
도 18은 본 발명의 실시예에 따른 메시지 목록을 내장한 모듈 스펙의 예를 나타내는 도면이다.

본 발명의 바람직한 실시예들이 이하 상세하게 설명된다. 특정한 바람직한 실시예들이 설명되지만, 이것은 단지 예시적인 목적을 위한 것임이 이해되어야 한다. 관련 기술이 속하는 분야의 숙련자는 다른 구성요소들 및 구성이 본 발명의 정신 및 범위를 벗어남이 없이 사용될 수 있다는 점을 인식할 것이다.

개인화된 포털 사이트(portal site)(예를 들면, My Yahoo!, start.com, 또는 Google Personalized Homepage)는, 신규 이-메일 알림, 현재 날씨 및/또는 교통 상황, 영화 상영시간, 운세(horoscope) 등과 같은, 개인화된 페이지(personalized page) 상에 디스플레이시키기 위해서 컨텐츠만을 (예를 들면, 인터랙티브(interactive), 읽기-전용, 갱신, 데이터 공급 등) 사용자에게 선택하게 할 수 있다. 본 발명의 실시예에 따르면, 이러한 여러 모듈들은 컨테이너(container) 내에 포함시키기 위해서 (예를 들면, 써드파티(third party) 개발자에 의해) 개발된 모듈들과 함께 개인화된 포털 페이지(컨테이너 문서의 일례) 내에 통합될 수 있다.

다양한 실시예들은, 호스팅 사이트(예를 들면, 컨테이너 서버 시스템) 및 모듈 서버(예를 들면, 사용자 또는 호스팅 사이트가 아닌 엔티티(entity)에 의해 운영되는 서버) 사이의 통신을 위한 프로토콜(protocol)을 제공하며, 또한, (호스트된 모든 곳에서) 모듈, 구조화된 저장소 시스템(structured repository system) 및 프록시 시스템(proxy system)의 기능(functionality)을 기술하는 인스트럭션들을 처리하며, 상기 구조화된 저장소 시스템은 사용자당 구성 정보 또는 사용자 우선순위(예를 들면, 날씨 지도 모듈에서, 사용자가 관계하고 있는 우편 번호)뿐만 아니라 고정된 모듈 데이터와 코드를 포함할 수 있고, 상기 프록시 시스템은 사이트에서 목표 사이트 데이터의 사용을 인에이블시킬 수 있다.

상기 모출원(parent application)은 배경(context)을 제공하지만, 본 출원은 메시지 목록들을 통합하도록 모듈들을 인에이블시키는 메커니즘 및 프로세스들의 부가적인 정보를 제공한다. 이러한 프로세스의 하나의 장점은 모듈들에 상이한 언어, 문자 베이스, 폰트 등에서 메시지(예를 들면, 텍스트)를 참조하도록 허용하는 것이다. 또한, 메시지 목록은 텍스트 교환(swapping), 신규 동작 생성, 버그 수정, 신규 기능 추가 등과 같은 다른 목적들을 위해 사용될 수 있다.

상기 시스템은 다수의 구성요소들을 포함할 수 있다. 상기 시스템은 컨테이너 문서(예를 들면, 개인화된 페이지)를 제공하는 컨테이너 서버를 포함할 수 있다. 상기 컨테이너 문서는 하나 이상의 원격 모듈들(remote modules)을 포함하는 하나 이상의 모듈들을 "포함(contains)"한다. 본 명세서에서 사용되는 용어인 "컨테이너 문서(container document)" 또는 "컨테이너(container)"는 웹사이트의 개인화된 홈페이지, 사이드바(sidebar), 이러한 하나 이상의 모듈들을 통합하는 툴바(toolbar) 구성요소, 사이트에 의해 호스트된 페이지, 및 모듈의 형식(예를 들면, XML)으로 모듈을 렌더링(rendering)할 수 있는 문서(예를 들면, HTML 코드 또는 XML 코드를 렌더링할 수 있는 임의의 문서)를 포함하는 것으로 이해되어야 한다. 또한, 컨테이너는 배급 시스템을 통해 상기 모듈들을 공급할 때 상기 모듈들을 통합하는 다른 엔티티의 웹사이트일 수 있다.

본 명세서에서 사용되는 용어인 "모듈(module)"은 컨테이너 문서에서 사용하기 위한 데이터를 제공하는 소프트웨어 및/또는 하드웨어를 적용하는 것으로 이해되어야 한다. 모듈들은 사용자 우선순위 컨테이너의 우선순위 주변 또는 기타 입력의 우선순위로 개인화될 수 있다. 모듈 스펙(Module specification)은 미리 정해진 구성요소들을 사용하여 상기 컨테이너 문서를 위한 데이터를 제공하는데 사용되는 인스트럭션 집합을 포함하는 것으로 이해될 수 있다.

개요 및 시스템 구조( Overview and System Architecture )

도 1은 본 발명의 일실시예에 따른 전체 시스템 구성을 나타내는 도면이다. 도시된 바와 같이, 도 1은 함께 결합될 수 있는 복수의 모듈들을 구비한 호스트 서버 시스템(host server system; 10)을 포함할 수 있다. 이러한 모듈들은 컨테이너 서버(container server; 12), 모듈 서버(module server; 14), 스펙 서버(specification server; 16), 백엔드 서버(back end server; 18), 분석 모듈(analysis module; 28), 모듈 생성 서버(module creation server; 32), 배급 서버(syndication server; 34), 광고 서버(advertisement server; 36), 지오코드 서버(geocode server; 37) 및 지도 서버(map server; 39)를 포함할 수 있다. 예시된 바와 같이, 개인화된 호스트 서버 시스템(10)은 네트워크(26)를 경유하여 복수의 시스템들에 연결될 수 있다.

네트워크에 연결된 다른 시스템들은 하나 이상의 사용자 시스템(22), 하나 이상의 원격 소스 시스템(24), 하나 이상의 모듈 개발자 시스템(30) 및 하나 이상의 배급 수령 서버(38)를 포함할 수 있다. 게다가, 하나 이상의 데이터베이스 시스템(20)은 호스트 서버 시스템(10)의 여러 모듈들과 연동하여 동작할 수 있다.

컨테이너 서버(12)는 네트워크(26)를 통해 사용자 시스템들(22)에 컨테이너 문서를 제공할 수 있다. 컨테이너 서버(12)는 웹 서버 또는 관련 서버 시스템들을 포함할 수 있고, 여기서, 웹 서버 또는 관련 서버 시스템들은 데이터 및/또는 인스트럭션들을 획득하고 상기 사용자 시스템(22)에세 네트워크를 통해 전송하기 위한 컨테이너를 형식화한다. 하지만, 컨테이너 서버(12)가 사용자 시스템(22) 상에 존재하여 네트워크 연결이 사용되지 않을 수 있다는 점이 인정되어야 한다. 컨테이너 문서가 워드 프로세싱 문서를 포함하는 것을 예를 들면, 컨테이너 서버(12)는 워드 프로세싱 모듈(word processing module)을 포함할 수 있다.

모듈 서버(14)는 컨테이너 문서로 통합하기 위해서 데이터를 모듈로부터 컨테이너 서버(12)에 제공할 수 있다. 일실시예에서, 컨테이너 서버(12) 및 모듈 서버(14)가 모든 기능들을 수행하는 하나의 유닛을 포함할 수 있다는 점이 인정되어야 한다. 모듈 서버(14)는 상기 모듈과 연관된 모듈 스펙에서 인스트럭션들을 번역(interpreting) 및/또는 구문분석(parsing)에 의해 상기 컨테이너 문서에 데이터를 제공할 수 있다. 일실시예에 따르면, 모듈 서버(14)는 브라우저의 아이프레임(IFRAME) 사용을 통해 상기 컨테이너 문서에 모듈 컨텐츠를 제공할 수 있다. 일반적으로 아이프레임은 상기 컨테이너 문서 내에서 독립적으로 동작하는 브라우저 윈도우 인스턴스(browser window instance)인 것으로 이해될 수 있다. 아이프레임의 장점은 아이프레임의 컨텐츠로부터 컨테이너 문서를 보호하거나 그 반대로 컨테이너 문서로부터 아이프레임의 컨텐츠를 보호하는 것이다. 예를 들면, 상기 컨테이너 문서상의 자바스크립트(JavaScript)는 (CSS(cascading style sheets), DOM(cascading style sheets) 또는 쿠키 객체와 같은) 내부의 아이프레임 내의 임의의 자바스크립트 코드에 접근하도록 허용되지 않을 수 있다.

컨테이너 문서의 디스플레이를 촉진시키기 위해서, 모듈들은 컨테이너 문서 내에 인라인(inline)으로 디스플레이될 수 있다. 인라인 디스플레이는 다른 문서 구성요소들과 함께 디스플레이되는 것으로 이해될 수 있다. HTML 규격에 따라 바디(body) 내 HTML용 코드로부터 생성된 디스플레이를 일례로 들 수 있다. 일실시예로서, 모듈 서버(14) 또는 일부 다른 구성요소는, 인라인 모듈이 생성할 수 있는 다양한 보안 문제들의 위험으로 인해서 컨테이너 문서 내에 이것을 인라인으로 포함시키기 전에 신뢰받을 수 있는지 여부를 결정할 수 있다. 일실시예에 따르면, 상기 모듈은 컨테이너 모듈에 의해 발행된 승인 색인(예를 들면, 디지털 인증서) 및 이하 상세하게 기술하는 바와 같은 컨테이너 모듈과 연관된 엔티티를 통합할 수 있다. 상기 승인 색인이 존재하는 경우, 모듈 서버(14)는 컨테이너 문서 내의 인라인 표시를 위해서 데이터를 모듈로부터 제공할 수 있다.

스펙 서버(16)는 모듈 서버(14)에 모듈 스펙 파일(module specification file)을 제공한다. 모듈 스펙은 모듈 서버(14) 및/또는 스펙 서버(16)에 접근할 수 있는 데이터베이스 내에 일시 기억(cache)되고 저장될 수 있으며, 또는 이후에 상세하게 기술할 스펙과 연관된 위치로부터 검색될 수 있다. 예를 들면, 스펙 서버(16)는 원격 소스 시스템(24) 상에 존재할 수 있다. 또한, 스펙 서버(16)는 스펙 서버(16)에 접근할 수 있는 네트워크상의 다른 위치에 위치하고 있는 모듈 스펙으로 네트워크를 통해 모듈 서버에 연결될 수 있다.

백엔드 서버(18)는 하나 이상의 데이터베이스(예를 들면, 대형 또는 동적인 정보 데이터베이스)와의 상호작용을 제공할 수 있다. 예를 들면, 빈번한 갱신을 획득하고 데이터 흐름을 요구하는 신규 모듈에 대해서, (예를 들면, RSS(Really Simple Syndication) 피드(feed)로부터), 백엔드 서버(18)는 컨테이너를 위한 HTML로 상기 데이터를 포맷할 수 있다.

구체적인 예로서, 사용자는, 캘리포니아주의 마운틴 뷰(Mountain View)시의 도심지의 지도를 디스플레이시키도록 모듈을 생성하는 기존의 지도 프로그램에 애플리케이션 프로그램 인터페이스(API)를 사용하는 것과 같이, 모듈(예를 들면, 지도 모듈)을 생성할 수 있다. 상기 모듈은 스펙 서버 상에 저장된 XML 스펙 파일 또는 모듈 스펙 파일을 포함할 수 있다. 스펙 서버는 임의의 서버를 포함할 수 있으며, 컨테이너 페이지가 호스트되는 사이트 또는 임의의 다른 사이트상의 서버를 포함한다. 이후, 사용자 또는 다른 사람은 개인화된 홈페이지(컨테이너 문서) 상에 이러한 신규 모듈을 포함할 수 있다. 상기 컨테이너 문서를 제공하는 서버는 모듈 서버로 동작할 수 있고 그 API로부터 질의(inquiry)를 통해 지도 데이터를 생성하는 서버는 상기 백엔드 서버인 것으로 간주될 수 있다.

본 발명의 일실시예에 따르면, 분석 모듈(28)은 여러 시간별로 (예를 들면, 상기 모듈이 사용자에 의해 먼저 선택될 때, 포함을 위한 컨테이너에 의해 모듈이 호출되는 각각의 시간, 안전 및 보안을 위해 유익하다고 결정되는 임의의 다른 시간에) 모듈들을 분석할 수 있다. 분석 모듈(28)은 불허 리스트와 상기 목록을 비교하는 동작, 위험한 모듈들과 상기 목록을 비교하는 동작, 또는 승인된 모듈 리스트와 상기 목록을 비교하는 동작을 포함하는 다수의 동작들을 수행할 수 있다. 상기 비교는, 명칭 또는 위치(예를 들면, URL)에 의해 정합되는 정확(exact) 또는 문자열(substring)(예를 들면, 접두어, 접미어 및 정규 표시), 스펙의 컨텐츠, 상기 스펙이 존재하는 위치의 컨텐츠, 또는 모듈에 대해서 확인될 수 있는 정보를 포함할 수 있다. 분석 모듈(28)은 상기 모듈이 불허되거나 위험하다는 것을 결정하는 것에 응답하는 하나 이상의 동작을 수행할 수 있는데, 예를 들면, 요청을 조용히 차단하는 것(즉, 일반적인 오류를 제공하는 것), 차단된 이유를 설명하는 오류로 상기 요청을 차단하는 것, 또는 안전하다고 결정되고 불허된 모듈과 관련된 것으로 결정된 (예를 들면, 제1 사이트가 불허된 지도 사이트였던 경우라면 지도와 관련된 다른 모듈, 또는 불허된 모듈이 "농구(basketball)" 모듈이었던 경우라면 농구인 키워드를 포함하는 모듈) 상이한 모듈 스펙으로 상기 요청을 재지정하는 것을 포함할 수 있다. 예를 들면, 재지정(redirection)을 통해, 원래 모듈의 URL이 "안전(safe)" 모듈에 전달될 수 있다. 이후, 상기 안전 모듈은, 이하 설명되는 바와 같이, 프록시 서버를 사용하여 상기 원래 URL 컨텐츠를 검색할 수 있다. 이후, 개발자들은 원래 모듈 내의 작은 버그들을 수정하도록 오류 핸들러(error handler)를 대체하여 상기 원래 모듈의 컨텐츠를 디스플레이시킬 수 있다. 다른 실시예로서, 분석 모듈(28)은 모듈 컨텐츠를 구문분석(parse)하여 이것이 안전한지 여부를 결정할 수 있는데, 예를 들면, 상기 모듈 내에 포함된 자바스크립트 또는 다른 스크립트를 컴파일링함으로써 상기 모듈이 수행할 수 있는 불안전한 또는 원하지 않는 동작들을 식별할 수 있다.

하나 이상의 모듈 생성 서버(32)가 제공될 수 있다. 이 서버는 모듈 생성 서버(32)에 의해 제어되는 인터랙티브 프로세스를 통해서 모듈을 생성하도록 모듈 생성자(module creators)를 인에이블시키는 "마법사(wizard)"로 동작할 수 있다. 예를 들면, 모듈 생성 서버(32)는 모듈 스펙을 자동으로 발생시키기 위해서 상기 모듈 생성자에 의해 나중에 사용되는 입력들을 제공하도록 상기 모듈 생성자를 인에이블시키는 일련의 사용자 인터페이스들을 제공할 수 있다. 예를 들면, 다양한 모듈 스펙 템플릿(module specification templates)은 상응하는 입력들이 제공될 수 있다. 이후, 모듈 생성 서버(32)는 모듈 생성자에 의해 제공되는 입력들을 획득하고, 상기 템플릿 내에 이 입력들을 삽입하며, 이후 상기 모듈을 위한 모듈 스펙을 발생시킬 수 있다. 또한, 미리보기, 검사 및 디버깅 기능이 이러한 "마법사"의 일부로서 제공될 수 있다. 이 모듈은 또한 다운로드가 가능하므로 네트워크상의 임의의 노드에서 설치 및 동작될 수 있다.

배급 서버(34)는 모듈들과 관련된 하나 이상의 배급 수납 서버(38)에 전송하기 위한 데이터를 마련할 수 있다. 배급 서버(34)는 모듈 및/또는 모듈 컨텐츠를 위한 요청을 수신하고, 해당 모듈 또는 컨텐츠를 네트워크(26) 상의 배급 수납 서버(38)에 전달할 수 있다. 배급 서버(34)는 호스트 서버 시스템(10)에 또는 네트워크상의 다른 위치에 존재할 수 있다. 예를 들면, 스포츠 웹사이트(예를 들면, 배급 수납 시스템(38)의 운영자는 원격 소스 시스템(24)에 의해 생성된 지도 모듈을 포함하도록 설계한 경우, 배급 서버(34)로의 요청을 통해 이를 수행할 수 있다. 이후, 배급 서버(34)는 모듈 서버(14)와 연동하여 상기 컨테이너 문서(여기서는 상기 배급 수납 시스템(38)의 스포츠 웹사이트 페이지)를 위한 데이터를 발생시킬 수 있다. 이것은 원격 소스 시스템(24)로부터 모듈 스펙을 검색하는 것, 배급 수납 서버(38)로부터 수신되는 우선순위(예를 들면, 디스플레이되고 있는 페이지의 스포츠 팀에 대한 도시 정보)를 공급하는 것, 및/또는 컨테이너를 위한 데이터를 발생시키는 것을 포함할 수 있다. 또한, 데이터는 배급 수납 서버(38)에서 아이프레임 또는 인라인으로 그 컨테이너 문서 내에 제공될 수 있는 것도 가능하다. 따라서 배급 서버(34)는 이것에 접근할 수 있는 모듈들을 배급할 수 있다. 이것이 결정하는 특정 모듈들 또는 다른 기준들(예를 들면, 컨텐츠 접합, 키워드 정합, 모듈들과 연관된 통화 값들 및/또는 배급 요청자 등)을 위한 요청들에 기반하여 이것들을 수행할 수 있다.

광고 서버(36)는 모듈과 연관된 광고들을 컨테이너에 제공할 수 있다. 예를 들면, 데이터가 컨테이너 문서에 전달될 때, 광고는 모듈 데이터와 통합될 수 있다. 광고 서버(36)는 모듈을 위한 배급 요청에 기반하여 광고들을 배급 수납 서버(38)에 전달할 수 있도록 배급 서버(34)와 함께 동작할 수 있다. 광고들은 다양한 범위의 기준에 기반하여 광고 서버(36)에 의해 선택될 수 있고, 컨텐츠 사이의 관계 또는 전술한 어느 것 및/또는 그 조합들과 관련된 컨테이너, 모듈, 컨테이너 내의 다른 모듈들, 배급 수납 서버 정보, 통화 구성요소/관계들에 관한 정보를 포함하지만 이에 국한되는 것은 아니다. 본 발명의 일실시예에 따른 광고 서버(36)는 Google AdSense system을 포함할 수 있다. 광고 서버(36)는 후술하는 하나 이상의 특허출원들에 기재된 바와 같이 동작할 수 있고, 그 주요 내용들은 본 명세서 내에 참조되어 본 발명의 일부를 이룬다. 구체적으로, 광고 서버(36)는 광고를 구비한 모듈과 관련된 2개 이상의 개념들을 결함시킴으로써, 그리고 입찰(bid)을 집합적으로 연관시킴으로써 온라인 광고를 관리할 수 있는데, 광고들을 전자 문서로 제공하는 배경에 설명된 방식으로 2개 이상의 키워드들을 가지며, 그 내용은 2003년 1월 10일에 출원된 미합중국 특허출원번호 제10/340,193호에는 "하나 이상의 광고들과 연동하는 키워드들에 대한 가격설정(Pricing Across Keywords Associated with One or More Advertisements)"이라는 명칭의 발명에 개시되어 잇고, 본 명세서 내에 참조되어 본 발명의 일부를 이룬다. 광고들을 게재하는 것 및 광고비용을 관리하는 것들의 추가적인 예들로서, 2003년 1월 10일에 출원된 미합중국 특허출원번호 제10/340,543호에는 "광고들이 관련된 우선순위들로 제공되는 시스템에 사용하기 위한 자동화된 가격 관리(Automated Price Maintenance for Use With a System in which Advertisements are Rendered with Relative Preferences)"라는 명칭의 발명이 개시되어 있고, 2003년 1월 10일에 출원된 미합중국 특허출원번호 제10/340,542호에는 "성능 정보 및 가격 정보에 기반하여 관련 우선순위로 광고들이 제공되는 시스템에 사용하기 위한 자동화된 가격 관리(Automated Price Maintenance for Use With a System in Which Advertisements are Rendered with Relative Preference Based on Performance Information and Price Information)"라는 명칭의 발명이 개시되어 있으며, 본 명세서 내에 참조되어 본 발명의 일부를 이룬다.

지오코드 서버(37)는 종래기술로 알려진 바와 같이 위치 설명들로부터 지오코드 정보를 발생시키도록 제공될 수 있다. 지오코드 서버(37)는 지리적 위치들로부터 위도 및 경도 수치 값을 발생시킬 수 있다.

지도 서버(39)는 지도 출력을 발생시킬 수 있다. Google Maps 및 Google Earth와 같은 지도 시스템들은 이러한 데이터를 발생시키는데 사용될 수 있다.

하나 이상의 데이터베이스 시스템(20)이 제공되어, 컨테이너 정보, 모듈 스펙 및/또는 관련 정보, 포맷 데이터, 사용자당 모듈당 우선순위 데이터, 원격 모듈 ID 데이터, 원격 모듈 위치 참조 데이터, 광고 데이터, 광고주 데이터, 컨텐츠/통화 데이터, 배급 수납 데이터, 모듈용 템플릿, 모듈용 입력들, 신뢰 및 불신 모듈들의 리스트, 승인 기준 및 관련 정보 및/또는 본 명세서에 기술된 바와 같이 동작하도록 상기 모듈들에 의해 사용되는 임의의 기타 정보가 여러 가지 방식으로 저장할 수 있다. 단일 데이터베이스 구조가 도시되었지만, 그 데이터가 다수의 위치들에서 그리고 하나 이상의 시스템들 내에 저장될 수 있다는 점이 용이하게 이해된다.

하나의 구성이 도 1에 도시되었지만, 다양한 모듈들의 다른 구성이 또한 가능하다는 점이 본 발명이 속하는 기술분야의 당업자에 의해 인정되어야 한다. 예를 들면, 호스트 서버 시스템(10) 내에 기재된 다양한 모듈들은 네트워크(26) 주변의 다양한 위치들에 또는 여러 네트워크들 상의 다양한 지점들에 배치될 수 있다. 또한, 단일 호스트 서버 시스템(10)이 기재되었지만, 도 1에 기재된 임의 숫자의 모듈들 각각이 네트워크(26)를 포함하여 제공될 수 있다는 점이 인정되어야 한다.

일실시예로서, 네트워크(26)는 인터넷을 포함할 수 있다. 또한, 다른 네트워크들은 다양한 시스템들 및/또는 서비스들의 각각을 연결하는데 사용될 수 있다.

게다가, 사용자 시스템(22)으로 도시된 것은 또한 원격 소스 시스템(24) 및/또는 모듈 개발자 시스템(30)으로 동작할 수 있다. 달리 말하면, 하나의 컴퓨터 시스템은 상이한 처리능력으로, 즉, 사용자 시스템으로, 원격 소스 시스템으로, 배급 서버로, 대상 컨텐츠 서버로, 및/또는 모듈 개발자 시스템으로 동작할 수 있다. 또한, 이하 상세하게 설명되는 바와 같이, 호스트 서버 시스템(10) 내에 기재된 모듈들 각각은 사용자 시스템(22), 원격 소스 시스템(24) 도는 모듈 개발자 시스템(30)에 배치될 수 있다. 마찬가지로, 데이터베이스(20)는 원하는 구성에 의존하는 도 1 내에 기재된 모듈들 각각과 연관될 수 있다.

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

본 발명의 일실시예에 따르면, 모듈들을 컨테이너 문서 내에 통합하기 위한 시스템들 및 방법이 제공된다. 일례로, 컨테이너 문서는 인터넷 상의 구글 서비스의 사용자에게 현재 이용할 수 있는 Google Personalized Homepage와 같은 개인화된 홈페이지일 수 있다. 사용자가 개인화된 홈페이지와 같은 컨테이너 문서에 포함시킬 수 있는 컨텐츠의 종류를 제한하는 대신에, 본 발명의 하나 이상의 실시예들은 사용자에게 컨테이너 문서의 소스가 아닌 소스들로부터 모듈들을 선택하게 할 수 있다. 따라서 예를 들면, 사용자는 구글과 연관되지 않은 소스로부터 자신의 개인화된 구글 홈페이지에 모듈을 포함시키도록 선택할 수 있다.

컨테이너 문서의 다양한 형식이 존재할 수 있지만 도 2에 개시된 예시적인 예가 존재하는 점이 인정되어야 한다. 도 2는 컨테이너 문서로 통합된 복수의 모듈들을 구비한 컨테이너 페이지(100)를 예시하는 도면이다. 아이프레임(IFRAME) 및 인라인 HTML 기술들을 사용하는 것을 포함하여 복수의 통합 방법이 가능하다.

이러한 점들이 이하 보다 상세하게 설명될 것이다. 도 2는 사진 원격 모듈(10), 업무리스트 모듈(102) 게임 모듈(104), 주식 모듈(105), 지도 모듈(106), 제1 원격 모듈(108), 제2 원격 모듈(110), 제3 원격 모듈(112) 및 제4 원격 모듈(114)을 포함하는 복수의 모듈들을 나타내는 도면이다. 다양한 모듈들의 상이한 형식들이 모듈의 생성자에 의해 제공되는 스펙(specifications)에 의존하여 존재할 수 있다. 도시된 바와 같이, 일부 모듈들은 스크롤바를 제공할 수 있고, 다른 모듈들은 제공하지 않을 수 있다. 일부 모듈들은 다른 모듈들보다 상이한 크기 또는 형상을 가질 수 있다. 게다가, 일부 모듈들은 사용자가 디스플레이 우선순위 및/또는 모듈과 연관된 사용자당 데이터를 편집하는 기회를 제공할 수 있다(예를 들면, 편집 링크를 제공하는 모듈들(102, 104, 105, 106, 110)을 참조한다). 예를 들면, 모듈은 지도 모듈(106)과 관련된 경우, 사용자에게 해당 모듈 내의 도시되는 주소 또는 주소들을 편집할 기회가 주어질 수 있다. 일실시예로, 인라인 모듈들은 컨테이너 문서에 의해 자동으로 크기가 조정되므로 스크롤, 높이 또는 축적 정보가 제공되지 않을 수 있다. 모듈 개발자는 상기 모듈이 이러한 실시예에서 이들 특성들을 갖기를 원하는 경우, 인라인 모듈이 고정된 크기 <DIV> 태그 및 상기 태그 내에 놓인 컨텐츠로 구비될 수 있다. 이후 상기 스크롤바(scroll bar), 높이 및 기타 특성들은 인라인 컨텐츠를 위해 특정될 수 있다. 속성들(attributes)중 하나는 상기 모듈이 컨테이너 문서 내의 상이한 배치 크기에 대해 확대 또는 축소 축적될 수 있는 방법을 개발자에게 나타내도록 축적(scaling) = "…" 로 특정하는 것을 허용한다.

이러한 컨테이너 문서(100)의 예를 제공하는 기능들(functions)중 하나는 컨텐츠 추가 구성요소(103)를 선택함으로써 컨테이너 페이지에 컨텐츠를 추가할 기회를 제공한다. "컨텐츠 추가(add content)" 구성요소(103)를 선택하면, 시스템은 사용자에게 컨테이너 페이지 내에 포함될 추가적인 구성요소들을 대화식으로(interactively) 나타낼 기회를 제공할 수 있다. 해당 입력을 수신하는 인터페이스의 다양한 형식들이 제공될 수 있다. 하나의 예시적인 형식이 도 2에서 섹션(120) 내 페이지의 하부쪽에 도시된다. 해당 섹션에서, 계층 구조로 정렬될 브라우징 가능한 모듈 리스트로부터 선택하도록 인터페이스 구성요소로 사용자에게 제공될 수 있다. 입력 섹션(120)의 다른 섹션은 컨테이너 문서에 통합될 모듈에 대한 위치로 참조(reference)를 사용자에게 특정하게 할 수 있다. 이러한 섹션은 제출 구성요소(submit element; 128)를 갖는 입력 박스(126)를 통해 개시되는 것일 수 있다. 하나의 예시적인 예로서, 사용자는, 통합될 모듈과 관련된 데이터가 존재하는 위치 참조(location reference)(예를 들면, uniform resource locator(URL))를 특정할 수 있다. 이하 구체적으로 설명되는 바와 같이, 데이터의 일례로서, 컨테이너 문서 시스템(10) 운영자의 스크립트 우선순위를 만족하는 XML-기반 파일이 있다.

다른 선택사항이 도 4에 개시되는데, 사용자는 402 섹션의 카테고리에 의해서 모듈들을 통해 브라우징 하도록 사용자에게 허용하는 인터페이스와 상호작용할 수 있고, 402 섹션은 403 섹션 내의 나타낸 복수의 이용할 수 있는 모듈들을 구비하며, 또는 검색 박스(406)에 정보를 기입하고 검색 버튼(408)을 선택하고 410 섹션에 그 결과가 디스플레이되는 검색 기능(404)을 사용자가 이용할 수 있게 한다. 이러한 검색 및 디스플레이의 결과들은, 도 3 및 제공되는 다른 설명들을 참조하여 이하 기술되는 바와 같이 모듈과 컨테이너 문서를 통합할 때 사용하기 위한 데이터(예를 들면, XML 파일)의 위치 참조(예를 들면, URL)를 제공할 수 있다.

도 2 또는 4에서, 모듈 미리보기, 저작자명, 저작자 제휴 및/또는 저작자 이-메일이 제공될 수 있다. 이-메일의 보호를 제공하도록, 익명의 이-메일 전송 특성이 스패머-크롤러(spammer-crawlers)에 대한 보호를 지원하는데 사용될 수 있다. 또한, 디스플레이는 (이하 보다 상세하게 기술되는 바와 같이) 모듈 우선순위로부터 May-Require 속을 사용하여 어떤 모듈이 필요하고 최선으로 동작하는지에 대한 정보를 제공할 수 있다. 여기서, 상기 모듈은 파이어폭스 브라우저(Firefox browser)만을 가지고 동작하고 정보가 제공된다. 또한, 위치 정보(Locality information)가 제공될 수 있다. 여기서, 이 모듈은 미합중국, 영국 및 스페인용으로 설계된다.

상이한 언어들로 모듈들이 제공하는 다른 실시예가 도 15a 및 도 15b에 개시된다. 도 15a는 영어 텍스트를 포함하는 샘플 모듈(1501)을 나타낸다. 도 15b는 도 15a와 동일한 구문을 갖는 샘플 모듈을 나타내지만 불어 텍스트를 포함하는 샘플 모듈(1502)을 나타낸다. 일실시예로, 예를 들면, 영어 모듈을 불어 모듈로 번역하는 것은 2개의 별도 모듈 스펙을 제공함으로써 달성될 수 있는데, 모듈 스펙 중 하나는 영어 텍스트 데이터를 포함하고 다른 하나는 불어 텍스트 데이터를 포함한다. 다른 실시예로서, 번역은 하나의 모듈 스펙으로 달성될 수 있다. 여기서, 모듈 스펙은 예를 들면, 영어 또는 불어일 수 있는 메시지 목록(또는 번들) 파일에 대한 메시지 참조(Message reference)를 포함할 수 있고, 그 결과로 메시지 목록으로부터의 텍스트는 모듈과 함께 표시될 수 있다. 메시지 목록의 텍스트는 임의 언어의 텍스트를 포함할 수 있고 유용한 "번역(translating)" 모듈 방식을 제공할 수 있다. 메시지 목록에 대한 메시지 참조는 URL을 포함할 수 있다. 상기 메시지 목록 파일은 XML 파일, JSON 파일 또는 임의의 소유 텍스트 또는 이진 포맷과 같은 임의의 데이터 구조형 파일을 포함할 수 있다. 다른 실시예로서, 메시지 목록은 상기 모듈 스펙 내에 또한 내장될 수 있다. 추가적인 언어들, 파일 종류 및 번역 실시가 또한 고려될 수 있다.

상이한 언어들에 대해 이러한 기술을 사용하는 것에 추가하여, 상이한 문체, 폰트 우선순위, 색조, 모양 등에 대해 이용될 수 있다. 예를 들면, 모듈이 치수(measurements)와 관련된 경우, 하나의 메시지 목록은 계량 단위에서의 정보를 제공할 수 있고, 다른 메시지 목록은 영어 단위(예를 들면, 처방 모듈 또는 방향/매핑 모듈 등)에서의 정보를 제공할 수 있다. 많은 다른 메시지 목록들이 또한 제공될 수 있다.

게다가, 모듈들을 추가하고 편집하며 삭제할 때, 그 동작들이 컨테이너 문서의 리프레시 없이 발생하기를 원할 수 있다. 이것을 달성하기 위한 하나의 예시적인 기술로서, 아약스(AJAX)의 사용을 포함함으로써 모듈이 컨테이너 문서 페이지의 리프레시(아마도 신규 컨테이너가 표시되는 아이프레임의 리프레시) 없이 컨테이너 문서에 추가될 수 있고, 또는 리프레시되는 컨테이너 문서 없이 모듈을 제거하도록 아약스가 사용될 수 있으며, 또는 개발자가 모듈을 개발할 때, 페이지를 리프레시 시켜서 전달되는 컨테이너 문서 없이 모듈들을 변경하여 컨테이너 모듈과 통합할 수 있다.

도 14는 컨테이너의 다른 예를 예시하는 도면이다. 이러한 컨테이너는 모듈 서버와 제휴되지 않는 컨테이너 서버로부터 동작될 수 있다. 상기 컨테이너(1400)는 부동산 목록 정보를 열람하는 써드파티 웹사이트(여기서는 Joe의 부동산 웹사이트)일 수 있다. 원격 모듈(1401)은 모듈 서버로부터 배급을 통해 통합될 수 있다. 여기서, 원격 모듈은 Joe의 부동산 웹사이트가 방문자가 그 사이트를 유용하게 발견할 수 있도록 모기지 계산기(mortgage calculator) 모듈을 포함할 수 있다. 상기 모듈을 사용하여, 하나 이상의 광고(1403)가 예시된 바와 같이 또한 제공될 수 있다.

방법의 예시( Illustrative Methods )

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

예를 들면, 컨테이너 페이지(100)의 모듈(103)을 통해 컨텐츠를 추가하도록 요청하는 사용자 입력인 경우, 308 단계 블록에서, 이용 가능한 모듈들의 리스트를 통해 또는 참조를 통해 모듈의 추가를 요청하고 있는지 여부를 사용자가 결정할 수 있다. 사용자가 리스트로부터 입력을 제공하는 경우, 메뉴 선택으로부터 컨텐츠가 310 단계 블록에서 수신될 수 있다. 이러한 수신은 도 2 또는 도 4에 나타낸 바와 같은 인터페이스를 가지고 사용자와 상호작용에 의해 달성될 수 있는데, 예를 들면, 124 또는 403에서의 모듈들과 같은 표시된 하나 이상의 모듈들을 선택함으로써 달성될 수 있다. 모듈의 선택을 수신하는 다른 방법이 또한 제공될 수 있다. 만일 사용자가 참조로부터 모듈의 선택을 제공하고 있는 경우, 이후 312 단계 블록에서 위치 참조가 수신될 수 있다. 모듈에 대한 데이터를 식별하는 사용자의 능력을 용이하게 하도록, 선택적인 313 및 315 단계 블록들이 또한 제공될 수 있다. 313 단계 블록에서, 예를 들면, 사용자의 원격 위치 식별자가 슬래시(/)로 끝나는 경우, 또는 검색되는 위치에서 사용자가 파일들을 요청하고 있는 다른 지시자로 끝나는 경우, 이후, 315 단계 블록에서, 가능한 모듈들의 리스트가 디스플레이될 수 있다. 315 단계 블록은 사용자에 의해 제공되는 원격 위치 식별자를 획득하는 것, 모듈 스펙을 나타내고 있는 파일들 또는 데이터의 기재사항에 대한 위치를 질의하는 것, 및 선택할 사용자를 위한 리스트에서 해당 질의에 대해 수신된 응답을 제공하는 것을 포함할 수 있다. 예를 들면, 317 단계 블록에서 표시된 파일들 중에서 하나를 사용자가 선택할 수 있는 것에 의해서 제공된 위치에서 모듈 스펙의 파일 리스트가 사용자에게 제공될 수 있다. 예를 들면, 사용자는 슬래시로 끝나는 URL을 제공하거나 또는 일부 다른 불완전한 위치 참조를 제공하는 경우, 상기 시스템은, 317 단계 블록에서 XML 파일들 중 하나와 같이 파일들 중에서 하나를 사용자가 선택할 수 있는 것에 의해서 URL 위치에서 모듈 스펙을 구비하는 모든 파일들의 기재사항을 315 단계 블록에서 검색할 수 있다. 다른 예로서, 상기 시스템은 컨텐츠로부터 자동으로 추정할 수 있거나, 또는 아파치 웹서버(Apache web server) 디렉터리 호출 또는 IIS(Internet Information Service) 디렉터리 호출과 같은 웹서버 자원들을 사용하여 (예를 들면, 데이터베이스 질의를 통해서) 디렉터리 기재사항 또는 객체 기재사항을 제공할 수 있다. 상기 리스트는 보다 용이하게 선택할 수 있도록 강조함으로써 그것이 쉽게 선택될 수 있는 방식으로 포맷될 수 있다.

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

본 발명의 다양한 실시예에 따르면, 컨테이너 문서의 운영자는 컨테이너의 안전뿐만 아니라 상기 컨테이너와 상호작용하는 사용자 시스템들의 안정을 보호하기를 원할 수 있다. 따라서 컨텐츠가 컨테이너 내에 통합될 수 있도록 하기 전에 모듈이 승인되는지 여부를 결정하기 위해서 하나 이상의 동작들이 수행될 수 있다. 예를 들면, 컨텐츠의 평가는 모듈이 신뢰할 수 있는지 여부를 결정하도록 발생할 수 있는데, 예를 들면, 신뢰할 수 있는 것으로 결정하기 위한 HTML 태그가 없거나 다른 문자들이 없는 경우에 수행된다. 이러한 동작들인 이하 구체적으로 설명된다. 만일 승인이 없는 경우, 이후, 320 단계 블록에서, 분석 모듈(28)을 참조하여 전술한 바와 같이 하나 이상의 불허 대응들이 발생할 수 있다.

승인이 발생한 경우, 322 단계 블록에서 갱신된 컨테이너 문서가 사용자에게 표시되거나 또는 컨테이너에 추가될 모듈의 입력을 제공하는 누군가에게 표시될 수 있다.

이하 보다 구체적으로 설명되는 바와 같이, 본 발명에 따르면, 호스트 서버 시스템(10)에 의해 컨테이너 문서로 통합되는데 이용될 수 있는 모듈을 위해 스펙(specification)이 제공될 수 있다. 도 5는 본 발명의 일실시예에 따른 모듈 스펙을 나타내는 도면이다. 기본 레벨에서, 스펙은, XML 버전 정보, 선택사항일 수 있는 모듈 우선순위, 선택사항일 수 있는 사용자 우선순위, 컨텐츠 종류 지정자, 및 모듈을 위해 할당된 컨테이너의 일부를 전달하는데 사용되는 컨텐츠 구성요소를 포함하는 복수의 구성요소들을 포함할 수 있다. 상기 컨텐츠는 다양한 코드 형식으로 특정될 수 있는데, 통상적으로 이러한 코드는 표시를 위한 컨테이너를 생성할 때 사용자 시스템에 의해 해석될 수 있다는 점이 인정되어야 한다. 이러한 코드는 HTML, 자바스크립트 또는 웹페이지의 형식을 나타내는데 사용될 수 있는 다른 코드 형식을 포함할 수 있다.

본 발명의 다른 실시예에 따르면, 모듈 스펙은 하나 이상의 다른 파일들 또는 컴퓨터 인스트럭션들 내에 내장될 수 있다. 이러한 실시예에 따르면, 모듈 서버(14)는 모듈을 생성하기 위한 데이터의 식별자가 제공될 때 상기 데이터 내의 모듈 스펙을 조사할 수 있다. 데이터의 형식들 중 하나는 도 6a의 예시적인 예에서 나타낸 바와 같은 다른 HTML 파일일 수 있다. 이 예에서, HTML 문서의 다른 코드들 중에서, 문서 스펙은 예를 들어 도 6a에 도시된 바와 같이 제공될 수 있다. 이것은 할당된 컨테이너의 일부분에 "Hello world!"와 같은 단어들을 나타내는 모듈의 간단한 형식을 예시한다. 도시된 바와 같이, 문서 스펙은 다른 HTML 페이지 내에 포함되며, 따라서 문서 스펙이 위치하고 있을 것 같은 파일은 .htm 또는 .html의 접미어를 갖는다. 다른 예로서, "debut", "about" 또는 일부 다른 인스트럭션과 같은 컴퓨터 인스트럭션은 상기 스펙을 제공하도록 식별될 수 있다. 따라서 본 발명의 일실시예에 따르면, 문서 스펙이 XML 종류 파일을 포함할 수 있지만, 실제로 모듈 스펙의 소스는 상기 모듈 스펙이 식별될 수 있는 데이터 또는 파일 종류의 다른 형식일 수 있다.

게다가, 데이터의 저장소는 모듈 스펙을 변경하고, 변형하며, 변환하고 또는 훼손시킬 수 있다. 예를 들면, 많은 데이터 저장소들은 소스로서 저장되고 사용될 때 HTML 또는 XML 컨텐츠를 이스케이프(escape)한다. 이후, 일부 시스템은 표시를 위한 소스 코드를 언이스케이프(unescape)할 수 있다. 이에 따라, 모듈 스펙이 벗어난 데이터 내에 포함된 경우, 모듈 서버 또는 스펙 서버는 코드가 이스케이프된 것을 검출하고, (예를 들면, 소스에 기반하여, 사용된 코드 종류 또는 다른 기술들에 기반하여) 사용되는 언이스케이프(unescape) 방식을 결정하며, 이후 그 원래 형식으로 복귀하도록 상기 데이터를 언이스케이프(unescape)할 수 있다. 도 6b는 도 6a의 파일이 확장된 이후를 예시하는 도면이다. 이 예에서, 기호 "<"는 "<" 로 변경되고, 기호 ">"는 ">"로 변경되며, 일부 다른 변경들이 이루어질 수 있다.

마찬가지로, 모듈 스펙의 다른 변경(alteration) 또는 수정(modification)으로서, 모듈 서버 또는 스펙 서버는 변경 또는 수정을 검출하고, 상기 변경 또는 수정이 어떻게 전환되는지를 결정하며, 또는 그렇지 않으면 모듈 스펙을 그 의도하는 형식으로 출력시킬 수 있다.

모듈 핸들링 방법의 예시

일단 모듈이 컨테이너와 통합되면, 상기 컨테이너가 열리거나 리프레시될 때, 컨테이너 내에 포함시키기 위한 모듈로부터 데이터를 생성하기 위한 방법이 수행될 수 있다. 이것을 수행하는 하나의 방법이 도 7에서 프로세스(700)로 예시할 수 있다.

702 단계 블록에서, 모듈 참조는 컨테이너로부터 수신될 수 있다. 예를 들면, 사용자를 위한 컨테이너는 통합될 복수의 상이한 모듈들을 특정할 수 있다. 이것은 상기 모듈의 위치에 대한 참조에 의해 이들 모듈들을 지시할 수 있다. 상기 모듈이 URL 종류로 특정된 경우, 이후 상기 모듈은 컨테이너의 서버로부터 잠재적으로 원격 지점에 위치하게 된다. 본 발명의 일실시예에 따르면, 704 및 706 단계 블록이 제공될 수 있다. 704 단계 블록에서, 원격 모듈의 상태가 예를 들면 분석 모듈(28)에 의해 결정될 수 있다. 만일 원격 모듈이 706 단계 블록에서 승인된 경우, 이후 710 단계 블록으로 진행할 수 있다. 만일 승인되지 않은 경우, 이후 하나 이상의 불허 대응이 708 단계 블록에서 수행될 수 있다. 710 단계 블록에서, 원격 모듈 참조와 연관된 서버가 호출될 수 있고, 수신된 데이터가 평가될 수 있다. 본 발명의 다른 실시예에 따르면, 710 단계 블록은 컨테이너 서버와 연관된 캐시(Cache)로부터 원격 모듈을 검색하는 것을 포함할 수 있다. 선택적인 712 단계 블록에서, 704 단계 블록과 연관된 하나 이상의 동작들이 수행되어 원격 모듈이 승인되는지 여부를 결정할 수 있다. 이는 원격 모듈들이 다른 써드파티의 제어하에 있을 때, 원격 모듈들에 대해 빈번하게 변경을 가할 수 있기 때문에 바람직하다. 따라서 모듈이 컨테이너에 처음으로 포함되는 시간과 이것이 두 번째로 디스플레이되는 시간 사이에서, 원격 모듈에 대해 원격 모듈을 불승인하는 변경이 이루어질 수 있다.

714 단계 블록에서, 원격 모듈 참조로부터 검색된 데이터는 모듈 스펙을 식별하기 위해 구문 분석된다. 전술한 바와 같이, 상기 데이터는 단지 상기 모듈 스펙을 포함하는 파일을 포함할 수 있고, 이에 따라 제공된 데이터로부터 상기 모듈 스펙을 추출하는데 714 단계 블록이 사용된다. 716 단계 블록에서, 모듈 스펙은 어떻게 데이터를 생성하는지 결정하도록 구문 분석되고, 718 단계 블록에서, 사용자 시스템 또는 컨테이너를 열기 위한 다른 시스템에 의해 접근될 때, 상기 컨테이너가 상기 원격 모듈의 컨텐츠를 볼 수 있는 것에 의해 상기 컨테이너로 데이터가 반환된다. 모듈 스펙을 구문 분석하는 것(716)과 연관된 여러 동작들이 본 명세서에서 보다 상세하게 제공된다.

도 8은 716 단계 블록에 포함된 동작들에 따른 보다 세부적인 사항을 나타내는 도면이다. 특히, 802 단계 블록에서, 구문 분석 동작은 상기 모듈 스펙 내에 특정된 컨텐츠 종류를 식별하고, 상기 컨텐츠 종류에 기반하여 적합한 동작을 취할 수 있다. 예를 들면, HTML 컨텐츠 종류에 대해서, 모듈 데이터는 서버 상에 존재한다. 802 단계 블록에서, 이용 가능한 모듈 우선순위가 적용될 수 있다. 모듈 우선순위에 따른 보다 세부적인 사항 및 이들이 적용되는 방법이 이하 제공된다. 807 단계 블록에서, 이용 가능한 사용자 우선순위가 적용될 수 있다. 사용자 우선순위에 대한 보다 세부적인 사항이 이하 보다 구체적으로 제공된다. 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= 속성에서 특정되는 URL에 위치하는 컨텐츠에 적용되는 XSLT 스타일 시트(style sheet)일 수 있다. 다시, 이러한 모듈 종류에 대한 디폴트값은 부당한 HTML/JavaScript에 대해 보호하는 한 방식으로 아이프레임 표시일 수 있다.

HTML 모듈의 한 예가 다음과 같이 도시된다:

일실시예에 따르면, 하나의 모듈은 이하 도시되는 바와 같이 컨텐츠 섹션을 구비할 수 있다:

모듈 우선순위는 바람직한 크기, 타이틀, 저작자 등과 같은 선택적인 모듈당 구성 정보일 수 있다. 예를 들면,

모듈 우선순위 속성인 <ModulePrefs …> 명칭들의 테이블은 다음과 같이 예시된다:

또한, <ModulePrefs> 우선순위 속성 내에서, <MayRequire…> 구성요소는 호환을 위한 정보를 특정하고, 디렉터리에서 디스플레이될 수 있다. 이것은 또한 모듈들의 속성 검색을 위해 사용될 수 있다. 이것은 정보를 제공하는데 사용될 수 있고, 정확을 위한 분석 모듈 내의 소프트웨어에 의해 유효화될 수 있다. 일실시예로서, 이러한 속성은, 검색 결과로 모듈들을 표시할 때 또는 모듈 생성자를 의도대로 동작시키는데 어떤 모듈이 필요한지를 사용자에게 이해시키기 위해 브라우징 할 때 사용될 수 있다.

예를 들면, QuickTime을 요구하는 하나의 모듈, 윈도우즈 플랫폼(WINDOWS platform) 및 파이어폭스 브라우저가 이하의 모듈 우선순위 속성 값들을 제공할 수 있다:

종류 및 값 속성들에 대해 미리 정해진 값들이 특정될 수 있는데, 추가적인 가능한 값들을 포함하도록 시간에 따라 갱신될 수 있다. type=other는 캐치-올(catch-all)로서 제공될 수 있다.

다중의 MayRequire 구성요소들이 제공되는 경우, 논리적 OR가 동일 종류의 다중 속성들을 번역하는데 사용될 수 있고, 논리적 AND는 상이한 종류의 다중 속성들을 번역하는데 사용될 수 있다. 예를 들면, 다중 브라우저가 특정될 수 있고, 임의의 특정된 브라우저가 사용될 수 있는 것을 번역기가 이해한다. 브라우저 속성 및 플러그인(plugin) 속성이 제공되는 경우, 번역기는 둘 모두 기대될 수 있는 것(논리적 AND)으로 이해한다. 또한, 어떤 모듈이 동작하지 않게 되는지를 특정하는 속성을 사용하는 것이 가능하다.

또한, <ModulePrefs> 속성 내에서, <Locale …> 구성요소는 모듈이 설계되는 국가 및/또는 언어를 특정하도록 개발자에게 허용할 수 있다. 이것은 <Locale lang = "…" country = "…">로 특정될 수 있다. 구문적으로, 이것이 번역됨으로써, 사용자들이 이러한 언어를 선호하고 및/또는 특정 국가에 위치하는 것을 특정하고 있는 사용자들에 대해 상기 모듈이 받아들일 수 있다는 것을 나타낼 수 있다. 이것은 컨테이너 서버 법적 제한사항에 따르는 컨테이너 서버를 보조할 수 있다. 예를 들면, 국가가 어떤 유형의 정보가 판매를 위해 제공되는 것을 배제한다면, 판매 모듈(sale module)은 법적으로 정당한 국가들에서만 판매하는 항목들을 표시하도록 지역 우선순위(locale preference)를 검출할 수 있다. 또한, 이것은 사용자 검출된 또는 특정된 지역에 기반하여 모듈들을 숨기거나 정렬하도록 디렉터리들 및 검색들을 위해 사용될 수 있다. 게다가, 코드에 대한 선택적인 속성을 제공하는 것이 가능하며, ISO 3166 코드와 같은 표준화된 코드의 스펙을 허용할 수 있다. 이러한 변경상황에서, 이러한 특정 코드의 스펙은 존재한다면 언어 및 국가 속성들을 무시할 수 있다.

또한, <Locale…> 구성요소는 모듈을 "번역(translating"할 때 유용할 수 있다. 일실시예로서, 메시지 참조는, 도 18에 도시된 바와 같이, 특정 언어로 모듈을 제공하기 위해서 모듈 스펙의 <Locale…> 구성요소 내에 내장되는 메시지 목록을 특정할 수 있다. 다른 실시예로서, 메시지 참조는 별도 파일로 존재하는 메시지 목록을 특정할 수 있다. 전술한 바와 같이, 도 15a 및 도 15b는 실질적으로 동일한 모듈들이지만 상이한 언어들로 구현되는 것을 예시한다. 도 16은 본 발명의 실시예에 따른 모듈 스펙을 예시하는 도면이다. 이 예에서, 모듈 스펙의 모듈 참조 섹션은 <Locale…> 다음과 같은 3개의 구성요소를 포함한다:

여기서, 불어에 대해서는 lang = "fr"이고, 캐나다에 대해서는 country = "CA"로 표시된다. 다양한 언어들 및 국가 코드들이 또한 고려될 수 있다. 더욱이, 메시지 목록을 특정하는 메시지 참조 또는 코드(즉, messages = "…")는 URL을 포함할 수 있다. 상기 URL은 http://somefrenchdude.com/fr_CA.xml이다. 이러한 URL은 XML-코드 메시지 목록 파일을 포함할 수 있고, 또는 JSON이나 임의의 전용 텍스트(proprietary text) 또는 이진 형식과 같은 다른 데이터 구조형 포맷을 포함할 수 있으며, 예를 들면, 모듈로 통합하기 위해서 미리 번역된 불어 텍스트를 포함한다. 따라서 영어 모듈은, 텍스트 위치지정자(placeholder)를 이용함으로써 그리고 교체를 위해 번역된 데이터를 갖는 XML 파일을 포함하는 메시지 참조 URL을 특정함으로써, 불어 모듈로 번역될 수 있다. 위치지정자는 언더스코어형(underscore-type) 위치지정자 또는 자바스크립트 위치지정자를 포함할 수 있다.

도 17a는 영어로 표시된 메시지 목록을 예시하는 도면이다. 도 17b는 불어로 표시된 메시지 목록을 예시하는 도면이다. 일실시예로서, 메시지들은 텍스트형 위치지정자, 예를 들면 이중 밑줄(double underscore)과 같이 잘 알려진 텍스트 시퀀스로 식별될 수 있다. 예를 들면, 도 16의 "__MSG_foo_title__"은 도 17b에서 "foo_title"라는 명칭을 갖는 메시지를 참고하여 메시지 위치지정자로서 사용될 수 있다. 여기서, 텍스트형 위치지정자는 메시지 목록의 미리 번역된 텍스트가 통합될 수 있는 곳에 위치할 수 있다. "__MSG_…__" 메시지들은 HTML-이스케이프될 수 있지만, JS API는 이들을 JS-이스케이프시킬 수 있다. 또한, 예에서, 도 16은 <ModulePrefs title= "<b>__MSG_foo_title__(__UP_someuserpref__)<b>"인 것을 제공한다. http://somefrenchdude.com/fr_CA.xml인 URL이 도 17b에 도시된 메시지 목록을 호스트한 경우, 상기 모듈은 도 15b의 모듈에 도시된 것과 유사하게 "LE FOO MODULE: JOE"로 기재되는 불어 타이틀로 나타나게 된다. 만일 도 17a가 URL에 의해 참조되는 메시지 목록인 경우, 이후 상기 모듈은 도 15a에 도시된 것과 유사하게 "THE FOO MODULE: JOE"로 기재되는 영어 타이틀로 나타나게 된다. 따라서 모듈 번역은 모든 상이한 언어에 대해 전체 모듈 스펙을 중복함이 없이 달성될 수 있다. 대신에, 메시지 목록의 텍스트를 번역하고 상기 모듈 스펙 내의 위치지정자를 갖는 텍스트를 식별하는 것은 모듈 번역에 대해 간단한 해결책을 제공할 수 있다. 적당한 이스케이프화(escapification)에 추가하여, 텍스트 위치지정자 교체의 다른 중요한 특징은 메타데이터 필드(metadata field), 예를 들면, 디렉터리가 보이는 국가 또는 언어로 국한될 수 있는 타이틀을 갖는 모듈 디렉터리의 동적 분석을 허용하게 할 수 있다. 또한, 메시지들은 특별 데이터(extra data), 즉, "The temperature is…%s"에 대한 특별한 구문(syntax)을 구비할 수 있다. 여기서, 데이터 위치지정자인 "%s"는 특별 데이터에 대해 특별한 구문을 상기 메시지들에게 제공할 수 있다.

도 15a 내지 17b에 한 가지 구성이 예시되었지만, 다른 구성들이 또한 가능할 수 있다는 점은 종래 기술이 속하는 분야의 당업자에 의해 인정되어야만 한다. 예를 들면, 다양한 모듈들, 모듈 스펙들 및 메시지 목록들이 제공될 수 있다. 또한, 다양한 언어들이 지원될 수 있다. 일실시예로서, 메시지 목록들은 데이터베이스 내에 저장될 수 있고, 웹사이트 또는 임의의 원격 소스와 같은 서버에 의해 호스트될 수 있다. 다른 실시예로서, 내부 또는 외부 메시지 목록들은 또한 메시지 번들을 공유하는 것을 용이하게 할 수 있다. 다른 실시예로서, 메시지 목록들을 위치시키기 위해 검색 툴(search tool)이 제공될 수 있다. 이것은 모듈-특정 목록을 위치시키는데 특히 유용할 수 있다. 일실시예로서, 메시지가 특정 프랑스계 캐나다인(French-Canadian) 목록과 같은 특정 메시지 목록에서 발견되지 않으면, 서버는 보다 일반적인 캐나다인 목록 또는 보다 일반적인 프랑스 목록을 사용할 수 있다. 이에 따라, 주어진 국가 또는 언어에 대해 하나 이상의 메시지 목록이 존재할 수 있다.

다른 실시예로서, 개발자는 호스트 또는 원격 서버를 통해 메시지 목록 번역을 요청할 수 있다. 메시지 목록들이 요청된 언어에 존재하지 않는 경우, 호스트 서버는 이러한 요청에 대해 메시지 목록을 번역할 수 있고, 개발자의 모듈로 통합하기 위해 요청자에게 번역된 메시지 파일을 반환할 수 있다. 일실시예로서, 호스트는 기계 번역기 또는 유사한 장치를 통해 자동으로 메시지 목록을 번역할 수 있다. 다른 실시예로서, 저작자 및 개발자는 그 자신의 목록을 번역하거나 또는 독립적인 번역 서비스를 이용할 수 있다. 일실시예로서, 자발적 번역 서비스가 제공될 수 있다. 대안적인 메시지 목록이 사용되고 있는 경우, 최종 사용자, 개발자 또는 저작자에게 예를 들면, 번역된 텍스트 주변에 붉은색 괄호(brackets), 모듈 윈도우의 상부 근처에서 동작하는 파이어폭스-스타일의 경고, 모듈 타이들에서의 별표(asterisks) 등에 의해서 통지될 수 있다. 일실시예로서, 특정 메시지 번역이 양호한지 양호하지 않은지에 대한 "투표(voting)" 에 의해 대안적으로 번역된 메시지 목록의 사용을 제어하는 선택사항을 사용자는 구비할 수 있다. 게다가, 사용자는 메시지들이 양호("good")한지 불량("not good")인지 또는 그 중간인지를 식별한 후, 투표 결과(vote-tallying) 구성요소가 데이터베이스에 이 정보를 저장할 수 있다. 예를 들면, "good" 메시지는 제공된 모듈에서 "not good" 메시지의 것보다는 상이한 사용자 인터페이스 처리를 수신할 수 있다. 다른 실시예로서, 사용자는 자신의 번역을 개인적으로 사용하거나 또는 공동체와 공유하는 선택사항을 구비할 수 있다. 다른 실시예로서, 이러한 정보를 저장하는 데이터베이스는 집중되거나, 다중 서버들 중에서 분배되거나, 최종 사용자에게 분배되거나 또는 이들의 조합일 수 있다. 다른 실시예로서, 투표 정보는 또한 정산되지 않은 투표수(raw votes), 투표수의 평균 또는 투표들로부터 비롯된 일부 결론을 포함할 수 있다. 다른 다양한 실시예들이 또한 고려될 수 있다.

또한, 메시지 목록들은 최적 우선순위 및 신속한 접근성을 위해 임시 저장될 수 있다. 일실시예로서, 메시지 목록은 하나의 모듈에서 사용하기 위해 서버에 의해 다운로드되고, 저장되며 호스트될 수 있다. 다른 실시예로서, 메시지 목록은 서버에 의해 임시 저장될 수 있다. 다른 실시예로서, 한 모듈로 사용하기 위해, 모듈의 페이지뷰당(per-page)으로 또는 페이지뷰를 통해 추가로 재사용하기 위하여 상기 메시지 목록은 클라이언트 애플리케이션(예를 들면 웹 브라우저)에게 전부 또는 일부가 다운로드될 수 있다. 여기서, 메시지 목록의 작용은, 최종 사용자(또는 클라이언트 소프트웨어), 모듈 생성자/저작자(그리고 모듈 및/또는 메시지 목록을 호스팅하는 서비스), 및 모듈에게 제공하는 서버의 협조에 의해 결정될 수 있다. 다른 실시예로서, 애플리케이션이 부당한 컨텐츠와 관련된 디렉터리 내에서 메타데이터를 변경시키는 것을 전혀 원하지 않는 경우, 국부적으로 외부 참조를 호스트된 참조들로 대체시키도록 상기 메시지 목록은 서버로 다운로드되고 호스트될 수 있다. 다른 실시예로서, 동적 애플리케이션이 사용되는 경우, 메시지 목록은 호스팅 서버와 중첩되는 것을 피하기 위해 시간대별로 임시 저장될 수 있다. 다른 실시예로서, 메시지 목록의 부분집합의 사용은 또한 다른 임시저장 모드가 최선이 아닌 경우에 제공될 수 있다.

일실시예로서, 메시지 목록은 모듈의 디렉터리, 사용자 우선순위(userprefs) 편집기 및 다른 위치의 제공에서와 같이 모듈의 배급에 또한 사용될 수 있다. 각각의 사용시, 메시지 목록 평가의 최선의 형태가 또한 결정될 수 있다. 예를 들면, 이것은 전술한 바와 같이 부당한 컨텐츠(objectionable content)를 고려하는 디렉터리들을 포함할 수 있다.

추가적인 선택사항들이 메시지 목록에 대해 또한 존재할 수 있다. 일실시예로서, 메시지 목록들은 모듈-특정(module-specific)될 수 있다. 여기서, 상기 파일은 특정 모듈에서 사용하기 위해 대부분이 번역된 텍스트를 갖는 크기가 작은 파일일 수 있다. 다른 실시예로서, 메시지 목록은 다수의 모듈들에서 사용하기 위해 번역된 메시지 데이터를 구비한 크기가 크고 광범위한 파일일 수 있다. 다른 실시예로서, 상기 파일이 네트워크 또는 이-메일을 통해 전송되기에는 너무 큰 경우, 상기 메시지 목록은 호스트 서버 시스템으로부터 직접 접근될 수 있다.

"lang" 및 "country" 값들에 대한 값들을 제공하는 것은 선택사항일 수 있다. 하나가 잘못된 경우, 이것은 ALL 값(즉, 특정된 국가에 대한 모든 언어들 또는 특정된 언어에 대한 모든 국가들)으로 번역될 수 있다.

일실시예로서, 지역 데이터가 특정되지 않은 경우, 이후 번역기는 하나의 국가 및 언어(예를 들면, 미합중국 및 영어) 또는 미리 정해진 국가들 및 언어들의 집합을 추정할 수 있다. 국가들에 대해 알려진 두 자리 값들(예를 들면, 뉴질랜드에 대해서는 NZ, 멕시코에 대해서는 MX 등)과 같이 단축 값들이 또한 사용될 수 있다. 또한, 임의의 단어들, 문자열, 문자들 등에 대한 컨텐츠를 스캐닝 함으로써 국가 리스트가 결정될 수 있다. 마찬가지로, 잘 알려진 국가들의 ISO 2문자 표시(예를 들면, 뉴질랜드에 대해서는 NZ, 멕시코에 대해서는 MX 등)와 같이 단축 값들이 사용될 수 있다.

reader_inline 속성은 선택적인 우선순위일 수 있다. 일실시예로서, 상기 모듈이 적당하게 동작하도록 인라인 되어야 하는 것을 의미하는 "required", 인라인된 경우 모듈이 적당하게 동작하지 않는 것을 의미하는 "never", 및 어느 한 방식으로 동작하는 것을 의미하는 "optional"을 포함하는 미리 정해진 값들이 제공될 수 있다.

다른 실시예들로서, 모듈 서버부터 네트워크에 걸쳐 원격으로 위치하고 있는 스펙 서버로부터 통상적으로 이용할 수 있는 모듈 스펙을 일시 저장하는 것이 바람직할 수 있다. 예를 들면, 스펙 서버가 저속 연결로 동작하고 있는 경우, 모듈 스펙의 전송은 컨테이너 문서를 위한 데이터 생성이 저속이 되거나 또는 이용할 수 없게 될 수 있다.

이에 따라, 모듈 우선순위 내의 임시저장 구성요소는 상기 임시저장 규칙이 적용되고 있는 것을 나타내는 하나 이상의 속성들을 설정할 수 있다. 예를 들면, URL 타입의 모듈에 대해서, 임시저장 규칙 우선순위는 크기 구성요소(예를 들면, 화면 크기가 동일한 경우에만 모듈 컨텐츠를 임시저장하고, 그렇지 않은 경우에는 reload한다)를 포함하는 속성들을 특정할 수 있다. 이것은 사용자 식별이 특정되는 것을 원하지 않는 모듈에 대한 디폴트 임시저장 동작일 수 있다. 다른 속성들이 "user" 값에 기반할 수 있다(예를 들면, 임의의 렌더링 치수들에 대해 사용자당의 컨텐츠만을 임시저장한다). 다른 속성들이 "user,size" 값 조합에 기반할 수 있다(예를 들면, 임의의 주어진 사용자에 대한 컨텐츠 및 주어진 화면 크기들에 대한 컨텐츠만을 임시저장한다). 이것은 URL 타입의 모듈들에 대한 디폴트 임시저장 작용일 수 있고, 사용자 식별을 받아들인다. 또한, 모듈들이 임의의 시간대에 대해 임시저장될 수 있도록 나이 속성(age attribute)이 특정될 수 있다. 이러한 속성 값은 컨텐츠를 임시저장하도록 최대 초 숫자일 수 있다. 이 숫자는 초에 대해서 "s"로, 분에 대해서는 "m"으로, 시간에 대해서는 "h"로, 또는 일에 대해서는 "d"로 덧붙여질 수 있다. 예를 들면, <ModulePrefs CacheMaxAge = 45d>는 45일에 대한 임시저장을 허용하게 된다. 예를 들면, <ModulePrefs CacheMaxAge = 0>는 임시저장을 유효하게 불능화한다. 디폴트값은 무한대일 수 있는데, "CacheMaxAge=infinite로 외연적으로 특정될 수 있다.

모듈들은 개인화된 홈페이지, HTML 이-메일, PDA, 전화기, 휴대폰, 양방향 미디어 장치, 비디오 게임 컨솔, 텔레비전 오버레이 등 또는 한 형식(예를 들면, HTML)에 기반하여 컨텐츠를 디스플레이시키도록 수성된 임의의 다른 장치와 같은, 컨테이너에 적합한 작은 크기의 애플리케이션들을 포함할 수 있다. 작은 화면 크기를 갖는 애플리케이션은 판촉물 및 광고 등이 보다 간결하고 덜 혼란스럽도록 적용될 수 있다. 크기 조정은 모듈 우선순위를 통해 달성될 수 있는데, 예를 들면, 상이한 우선순위를 갖는 상이한 출력장치들로, 또는 디스플레이될 데이터를 제공하는 상이한 출력 장치들 상에서 어떻게 동작하는지를 특정하는 모듈로 달성될 수 있다.

예를 들면, 주어진 모듈을 윈도우 크기에 맞추기 위해서, 상기 모듈은 <ModulePrefs ... height="200">을 사용하여 (픽셀들에서) 높이를 특정할 수 있다. 또한, 상기 모듈이 제공된 크기로 맞추지 못한 경우, <ModulePrefs ... scrolling = "true">일 때, 스크롤바들이 자동으로 추가될 수 있다.

따라서 모듈 우선순위는 모듈 생성자에게 화면 크기들 및 가시 상태를 특정하게 하는데 사용될 수 있는데, 예를 들면, 가시 상태는 전체, 최소화된 타이틀바(title bar), 최소화로 가시화된 상태(예를 들면, 하부에서 또는 툴바에서 가시 아이콘 상태), 최소화로 감추어진 상태(예를 들면, 메뉴로부터만 이용할 수 있는 상태) 또는 닫힌 상태일 수 있다. 모든 가시 상태에서, 상기 모듈은, (시간지정 이벤트를 포함하는) 이벤트에 대응할 수 있고 시스템과 상호작용(예를 들면, 그 상태 변경을 포함함)할 수 있는 감각으로 사용자의 페이지를 "on" 상태를 유지할 수 있다. 또한, 시스템, 최종 사용자 또는 모듈은 상기 모듈의 가시성을 제어할 수 있는데, "default" 가시성 또는 다양한 환경 하의 가시성, 예를 들면 "active"와 같은 상태를 정의할 수 있다. 예시적인 예들은 비정상적인 또는 극한의 날씨가 될 때까지 (어떤 정의에 대해) 최소화된 상태를 유지하는 날씨 모듈을 포함한다. 교통 모듈은 관련된 교통 경보가 발생할 때까지 최소화된 상태를 유지할 수 있다. 주식 모듈은 기설정된 백분율보다 큰 변동량을 갖는 주식들만을 디스플레이할 수 있다. 가상 축구 모듈은 주말에만 활성화되거나 또는 기설정된 첫 번째 게임 시간대 내에 활성화될 수 있다. 사용자는 이들 우선순위들을 예를 들면, 메뉴로부터 수동으로 재지정할 수 있다. 또한, 다른 예로서, 이-메일 모듈은 일부 기준에 의해 중요하다고 간주되는 이-메일을 반영하도록 그 자신의 크기를 지정할 수 있다.

많은 모듈들은 인터넷 상의 어딘가에 호스트된 대형 데이터베이스 및 동적 서비스를 접근하도록 선택할 수 있다. 보안 목적을 위해, 브라우저는 통상적으로 컨텐츠가 그것을 검색하는 것과 동일한 호스트에서 임의의 자바스크립트가 "come from"(<script src=...>) 하는 것을 필요로 한다. 따라서 이러한 기술을 사용하는 모듈은 자바스크립트 소스 파일들 및 자바스크립트 코드가 접근하는 서비스들을 함께 위치시킬 수 있다. 자바스크립트 코드 접근의 일례로서, 모듈 번역을 포함할 수 있다.

전술한 바와 같이, 언더스코어형 또는 HTML-이스케이프 교체, 예를 들면, "__MSG_…,"는 메시지 목록의 텍스트에 접근하도록 모듈 스펙에서 사용될 수 있다. 다른 실시예로서, 자바스크립트 코딩이 유사한 텍스트 교체를 제공할 수 있다. 예를 들면, 도 16은 <Content…> 구성요소 내에 내장되는 자바스크립트 코드를 나타내는 도면이다:

여기서, 상기 .get("hello_world")은 예를 들면, 도 17b에 도시된 바와 같이, http://somefrenchdude.com상에 위치하고 있는 불어 메시지 목록에 접근할 수 있다. 이후, 결과적인 모듈은 "Hello world"와 동등한 불어로 보이게 될 수 있다. 온도가 53인 경우, 상기 모듈의 바디에서 "Bonjour monde. La temperature est 53."일 수 있다. 전술한 바와 같이, 데이터 위치지정자 "%1"은 선택적인 메시지 선택사항을 제공하도록 메시지 목록 내에 사용될 수 있다. 하나의 예로서, 메시지들에 대한 위치 인수(positional arguments)가 있을 수 있다. "The temperature is 53"의 다른 언어로의 최선의 번역이, 예를 들면, 단어순서는 바뀌고 데이터 값이 요구되는 "53 is the temperature"인 경우, 데이터 위치지정자는 이러한 특정 번역에서 보다 큰 호환성 및 구현성을 제공할 수 있다. 여기서, <ph name = "number"><ex>10</ex>…</ph>는, 숫자가 실제 문자열로 교체되게 하는 메시지 목록 번역자 또는 개발자를 나타낼 수 있다. 이 경우, 도 16의 "53"은 "temperature_is" 및 메시지 데이터 위치지정자 "%1"을 대체할 수 있다. 위치 인수에 대한 여러 다른 실시예들이 또한 제공될 수 있다.

자바스크립트 접근을 구비하는 것은 메시지 목록들이 크거나 서버 측에서 호스트된 경우, 특히 유용할 수 있다. 게다가, 자바스크립트 코딩은 모다 복잡한 모듈들을 번역할 때 개발자들 위해 호환성을 제공하고 용이하게 사용될 수 있게 한다. 예를 들면, 전술한 바와 같이 메시지 목록의 부분집합(subset)이 생성될 수 있다. 여기서, 모듈 스펙은 메시지 목록 내의 메시지들이 사용될 것인지를 결정하도록 분석될 수 있다. 결국, 대형 메시지 목록에서 필요하지 않은 메시지들은, 예를 들면, 출력되지 않을 수 있다. 이것은 모듈을 시청할 때 임의의 불필요한 지연을 단축시킬 수 있기 때문에 JS API 교체에 대해 특히 유익하다.

자바스크립트 코드 접근의 다른 예로서, Maps API(Application Program Interface)을 사용하고 있는 운영중인 구글 지도 모듈(Google Maps module)이 있다:

이러한 예와 관련하여, userpref datatype = 위치는 지오코드(즉, 문자열을 경도 및 위도로 바꾸는) 이어야 한다.

많은 모듈들이 사용자 우선순위 정보를 받아들일 수 있는데, 예를 들면, 날씨 모듈은 사용자가 시청하기를 원하는 우편번호의 수신을 기대할 수 있다. 기대되는 사용자 우선순위를 갖는 모듈이 이하 예시된다:

사용자가 모듈 URL 또는 모듈 스펙을 변경하는 경우, 임의의 이전 사용자 값들은 신규 모듈 스펙으로 동기 이탈(out-of-sync)될 수 있다. 이를 해결하기 위해서, 서버는 우선순위 값들을 어떤 식으로든 전달하기 위해서 선택할 수 있다. 구 사용자 우선순위들(Old user preferences )은 삭제되거나, 무시되거나 또한 스펙 서버가 이들을 무시할 수 있는 곳으로 전달될 수 있다.

사용자 우선순위 속성을 나타내는 테이블의 예가 다음과 같이 주어진다:

이들 우선순위들 중에서, 일부 모듈들은 데이터를 획득하기 위해 로그인 및 다른 인증을 구비할 수 있다. 이러한 정보는 우선수위들을 통해 스펙 서버에게 전달될 수 있다. 또한, 이들 시스템들을 돕기 위해서 다른 기술들이 사용될 수 있는데, 어떤 모듈 생성자에 대한 특별한 사용자 우선순위들을 생성하는 것, 스펙 서버에게 전달되는 익명의 사용자 식별자를 포함하며, 스펙 서버, 사용자당 로그인 화면 및 기타 이러한 기술들에 대해 아이프레임에 쿠키를 배치하는 것을 포함한다.

전달되는 사용자 우선순위를 획득하기 위해 자바스크립트-기반 모듈을 구비하는 자바스크립트 우선순위 인터페이스가 구비될 수 있다. 이러한 인터페이스는 다음과 같은 기능들이 포함된 복수의 자바스크립트 기능들을 포함할 수 있다:

게다가, 우선수위 프로토콜들과 관련된 정보가 또한 사용될 수 있다. 예를 들면, 컨테이너 우선순위, 모듈 우선순위, 사용자 우선순위, 배급 수납 우선순위 및 배급 수납 시스템의 사용자들은 모듈에 적용될 수 있는 우선순위들을 특정할 수 있다. 프로토콜이 설정될 수 있는데, 프로토콜은 우선순위가 다른 것에 대해 충돌이 존재하는 경우 우선권을 취하는 것을 결정한다. 예를 들면, 만일 컨테이너가 모듈을 100 x 120 픽셀들로 제한하고, 모듈 우선순위가 상기 모듈이 해당된 것보다 커야하는 것을 시하는 경우, 컨테이너 우선순위는 모듈 우선순위를 무시할 수 있다. 즉, 상이한 시간대들이 컨테이너, 사용자 시스템 및 배급 서버에 적용되는 경우, 배급 서버의 시간대는 사용자 우선순위를 무시할 수 있다. 기타 프로토콜들이 또한 가능하다.

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

상기 컨텐츠 섹션은 순수한 HTML을 또한 포함할 수 있다. 모듈 우선순위 속성을 나타내는 테이블이 이하 도시된 바와 같이 예시된다:

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

(예를 들면, Macromedia FLASH, MPEG4, 등) 축척 가능한 벡터 그래픽 객체(Scalable Vector Graphics objects), 비디오 플레이어, 오디오 플레이어 등은 그것을 참조하고 호출하는 HTML을 갖는 객체에 대한 코드를 포함함으로써 모듈의 일부가 될 수 있다. 상기 모듈 서버는 이 정보를 확인하고, 플래시 객체의 포함에 기반하여 신뢰받지 못하는 모듈을 결정하며, 이에 따라 아이프레임 내에 이것을 제공할 수 있다. 또한, 이러한 모듈들이 안전한 것으로 간주되고 인라인으로 제공될 수 있는 것이 가능하다.

모듈 생성자들은 모듈들을 갱신할 수 있다. 따라서 상기 모듈 생성자는 신규 버전의 모듈을 사용하여 익히고 및/또는 시작하기 위해서 사용자에 대한 여러 선택사항들을 구비할 수 있다. 예를 들면, 모듈 생성자는 동일 위치에서 신규 버전의 모듈을 제공할 수 있고, 이에 따라 컨테이너가 해당 위치에 대한 참조를 포함할 때 사용자에게 신규 버전으로 갱신할 수 있다. 호출이 해당 위치 참조에서 모듈 스펙을 검색하게 될 때, 신규 버전의 스펙이 검색될 수 있다. 모듈 생성자 및/또는 사용자가 사용자에 대한 신규 버전 수임을 원하지 않는 경우, 이후 신규 버전은 Module Prefs 내의 상이한 위치 참조에서 이용될 수 있다. 이후, 신규 버전이 이용할 수 있는 것이 여러 메커니즘을 통해 사용자들에게 인식되고, 이들에게 신규 위치 참조(예를 들면, URL)를 제공하여 컨테이너 문서에서 모듈의 신규 버전을 식별할 때 이용할 수 있다. 예를 들면, 모듈 생성자는 신규 참조 위치(예를 들면, URL)에 신규 버전을 발행할 수 있고, 이후 구 위치 참조(예를 들면, URL)를 변경하여 업그레이드의 사용자에게 통지할 수 있다.

게다가, 여러 실시예들에서, 모듈 스펙은, 모듈 생성자에게 모듈의 신규 버전이 생성된 것을 지시하게 하는 필드 또는 우선순위를 포함할 수 있다. 이후, 모듈 서버는 구문분석 동안에 신규 버전이 이용할 수 있는 지시를 식별하고, 모듈 데이터 출력을 변경할 수 있다(예를 들면, 확인 윈도우와 링크되어 있는 "업그레이드 가능(upgrade available)"과 같은 지시를 갖는 모듈 타이틀바를 지정하고, 컨테이너 문서 내 사용자의 모듈 위치 참조가 신규 버전으로 업그레이드하는 것을 확인할 수 있다). 예시적인 목적으로, 도 2의 모듈(105)은 "업그레이드 가능(upgrade available)"(105) 선택을 포함할 수 있다. 신규 버전으로 업그레이드를 위해 사용자 선택과 관련된 입력을 인식 및/또는 수락하도록 모듈 데이터 출력을 변경하는 다른 방법들은 또한 모듈 스펙 내의 정보를 포함시키는 것에 기반하여 가능할 수 있다. 게다가, 사용자에게 이전 버전으로 복귀하게 하는 선택을 제공하는 것이 가능할 수 있다. 예를 들면, 일부 사용자는 업그레이드를 좋아하지 않을 수 있거나 또는 업그레이드가 성능 문제(예를 들면, 버드 등)를 발생시킬 수 있다. 따라서 모듈 서버는 사용자에게 이전 버전으로 복귀하게 하는 선택사항을 자동으로(또는 모듈 스펙 내의 입력에 기반하여) 표시할 수 있다. 예시적인 목적으로, 모듈(106)에게 업그레이드 선택(106)이 제공된다. 이것은 다른 업그레이드가 이용되거나 무기 연기될 때까지 기설정된 시간대 동안 수행될 수 있다. 실제로, "undo upgrade"의 반복적인 선택은 모듈의 여러 버전들 중 처음으로 선택을 복귀시킬 수 있다.

이후, 이전 버전의 위치 참조와 관련된 정보는 모듈 서버에 저장되고 접근될 수 있고, 및/또는 위치 참조들이 사용될 수 있게 하는 모듈 참조에 저장될 수 있다.

따라서 여러 실시예들에서, 스펙 서버(16)는 로컬 웹서버(예를 들면, 아파치 서버)를 운영하거나 또는 통상적으로 빠른 연결 응답을 제공하는 관리된 호스팅 설비를 사용할 수 있다. 디폴트로서, 모듈 컨텐츠는 컨테이너 서버의 도메인으로부터 분리된 도메인 상에서 호스트된 아이플레임에 표시될 수 있다. 예를 들면, 아이프레임은 동일하거나 상이한 컨테이너 서버에 의해 호스트될 수 있지만, URL에서 상이한 호스트 명칭(또는 IP 주소)으로 작용하게 된다. 이것은 (예를 들면) 컨테이너 서버의 도메인과 연관된 임의의 쿠키를 훔치도록("steal") 시도할 수 있는 부당한 모듈들로부터 사용자들을 보호하는 것을 도울 수 있다.

호스트 서버 시스템은 예방조처 없이 신뢰받지 못한 HTML을 인라인으로 포함하는 것을 원하지 않을 수 있다. 인라인으로 제공되는 경우 부당한 모듈은 호스트 서버 시스템에 의해 설정된 인증 자격(authentication credentials)을 포함하는 쿠키들을 읽거나 변형시킬 수 있다. 부당한 모듈은 또한 컨테이너(예를 들면, 호스트 서버 시스템과 연관된 개인화된 홈페이지)를 읽거나 변형시킬 수 있다. 또한, 부당한 모듈은 개인화된 홈페이지를 찾는 피싱 사이트로 (document.location을 통해) 전체 페이지를 교체시키는 피싱(phishing)(예를 들면, 로그인 박스의 모조) 또는 코드를 사용할 수 있다. 또한, 부당한 모듈은 원하지 않는 팝업, 대화창 또는 무한 루프 코드를 사용할 수 있다. 또한, 부당한 모듈은 아이프레임에게 정보를 전달할 수 있는데, 이후 이것은 아이프레임 내의 임의의 장래 문제점들을 발생시킬 수 있다.

이에 따라, 다양한 실시예들에 따르면, 컨텐츠는 아이프레임 내에 배치될 수 있다. 추가적인 안전 레벨로서, 아이프레임 내의 컨텐츠는 수치 IP 주소 상에 제공될 수 있다.

다른 보호 레벨은, 사용자 우선순위가 컨테이너 내의 출력 HTML에서 생성되는 것을 감추는 스크립트 라이브러리를 사용하는 HTML형 모듈들을 포함할 수 있다.

모듈의 데이터를 제공하도록 아이프레임의 사용에 추가하여, 다른 보안 특징들이 사용될 수 있다. 예를 들면, 컨테이너 페이지의 사용자들은 신뢰받지 못한 모듈들을 컨테이너 페이지에 추가할 때 위험을 인식하도록 요청받을 수 있다. 또한, 신뢰받지 못한 모듈들은 일부 방식(예를 들면, 색상 경계와 같은 비주얼 경계 설정)으로 지적될 수 있다. 게다가, JavaScript alert(), confirm() 및 prompt() 함수와 같은 다양한 함수들이 아이프레임에서 억지될 수 있는데, 이것은 일실시예에서 더미 함수 정의들(예를 들면, 실제 컨텐츠 앞의 function alert() { ; })을 삽입함으로써 달성될 수 있다. 컨텐츠 내의 추가 아이프레임은 이것이 억지되는 것을 우회하는데 사용될 수 있기 때문에, 컨테이너는 아이프레임을 포함하거나 또는 JavaScript eval() 함수를 사용하는 모듈을 포함하는 것을 거부할 수 있다.

인라인 생성 프로세스의 예시( Illustrative Inline Generation Process )

본 발명의 여러 실시예들에 따르면, 컨테이너의 모듈 인라인의 컨텐츠를 표시하는 것이 바람직할 수 있다. 본 명세서 내에 기재된 바와 같이 컨테이너 내에 컨텐츠를 인라인 시키는 것과 연관된 위험들이 존재한다. 따라서 시스템에 의해 "신뢰받게(trusted)"되면, 모듈이 컨테이너를 인라인 시키는 것이 바람직할 수 있다.

모듈이 여러 알려진 기술들을 통해 정적으로(statically ) 안전하다고 증명된 HTML 및 기타 코드들을 사용하는 경우를 포함하여 다양한 기술들에 따라 모듈은 신뢰할만한 것으로 여겨질 수 있다.

시스템에 대해 충분한 신뢰 수준을 얻는 다른 방법은 디지털 서명에 기반하는 방법론(methodology)을 포함할 수 있다. 한 예시적인 방법론이 도 9에 도시될 수 있다. 이러한 과정(900)은 하나 이상의 단계 블록들을 포함할 수 있다. 902 단계 블록에서, 디지털 사명이 생성될 수 있다. 디지털 서명을 생성하는 다양한 기능들 및 기술들이 알려져 있고 본 명세서 내에 사용될 수 있다. 이러한 시스템이 하나의 입력으로 여러 데이터를 획득하고 특정 목적을 위해 고유한(즉, 들면 2사람은 동일한 서명을 갖지 않는다) 일련의 숫자들을 그 입력에 기반하여 랜덤하게 생성한다.

상기 디지털 서명은 모듈의 유효성에 기반하여 컨테이너 서버 및/또는 호스트 서버 시스템에 의해 제공될 수 있다. 일실시예로서, 모듈의 컨텐츠는 아이프레임의 또는 자바스크립트의 "src=" 표시와 같은 임의의 외부 컨텐츠를 포함하지 않는 경우에만 유효화될 수 있다. 모듈을 무효화하거나 또는 인증할 때, 컨테이너 서버 및/또는 호스트 서버 시스템과 연관된 사람 또는 운영자들에 의해 승인된 사람에 의해 수동으로 검사받을 수 있다.

904 단계 블록에서, 모듈의 생성자는 해당 디지털 서명을 모듈 내에 통합할 수 있다. 906 단계 블록에서, 모듈의 생성자는 모듈 이 인라인 생성을 지원하는 것을 나타내는 코드를 구비하는 모듈 설계 스펙을 갱신할 수 있다. 이것이 발생하면, 컨테이너 서버에 의해 제공될 때 상기 모듈은 컨테이너와 인라인으로 표시된다.

사용자 화면상의 모듈의 다른 인스턴스들과 충돌을 피하기 위해서, __MODULE_ID__가 모든 HTML 명칭/ID에 그리고 모든 자바 함수들 및 전역 변수들(global variables)에 추가될 수 있다. 예를 들면, var myvariable이 5가 되면, var myvariable__MODULE_ID__ = 5가 된다. 런타임에서, 모듈 컨텐츠 내의 모든 __MODULE_ID__ 문자열들은, 불신되는 모듈에서 조차 해당 모듈에 대해 고유한 ID로 런타임에서 교체된다.

사용자 우선순위들은 이하 설명되는 우선순위 인터페이스를 사용하여 아이프레임 모듈 또는 인라인 모듈로부터 접근될 수 있다:

인라인 모듈 및 아이프레임 모듈 모두가 (크기 재지정 이벤트에 대해) 그 컨테이너 크기를 구하도록 동일한 인터페이스를 사용하는 것을 허용하기 위해서, 2개 모두 인위적인 <div> 내에 배치될 수 있다.

우선순위 저장의 예시( Illustrative Preference Storage )

본 발명의 다른 실시예에 따르면, 데이터베이스(20) 내에 저장된 데이터 구성요소들 중하나는 우선순위를 포함할 수 있다. 특히, 개인화된 컨테이너 문서를 구비한 시스템의 사용자 각각에 대해, 우선순위들이 저장될 수 있다. 또한, 우선순위들은 사용자의 개인화된 컨테이너 내의 하나 이상의 모듈들과 연관되어 저장될 수 있다. 일실시예에 따르면, 시스템은 사용자들에 대한 우선순위들에 대해서 큰 크기의 저장부를 할당할 수 있다.

도 10은 2명의 사용자들에 대한 우선순위들을 예시하는 도면이다. 이 예에서, 실명이 아닌 사용자명일 수 있는 한 명의 사용자인 Bob Brown은 그 컨테이너 내에 포함시키기 위해 설계된 3개의 모듈들을 구비한다. 각각의 모듈은 식별자(예를 들면, 데이터가 저장되는 데이터베이스에 대한 수치 식별자 또는 색인) 및 위치 참조에 의해 식별될 수 있다. 이러한 인스턴스에서, 위치 참조는 인터넷 상의 웹사이트에 위치하는 XML 파일의 URL이다. 게다가, 이러한 특정 모듈에 대해서, 다양한 우선순위들이 저장될 수 있다. 이러한 인스턴스에서, 우선순위는 다음과 같이 저장된다: 자신의 이름은 Bob, 자신이 선호하는 색은 청색, 그리고 자신이 선호하는 샌드위치는 루벤(reuben)이다. 이들 우선순위는 www.smith.com에서 모듈에 대한 모듈 스펙에 기반하여 저장될 수 있다. 구체적으로, smith.com 모듈은 우선순위가 이름, 주소 및 나이를 포함할 수 있는 것을 특정할 수 있다. 일실시예로, 모듈 스펙 내에서 특정된 우선순위만이 우선순위 데이터베이스에 저장될 수 있다. 다른 실시예로서, 사용자가 제공하는 모든 우선순위들은 우선순위 데이터베이스 내의 이러한 모듈 엔트리와 연관하여 저장될 수 있다. 예를 들면, Smith.com 모듈 스펙은 샌드위치 정보를 또한 요구하는데 사용되는 이름 및 색 우선순위 정보를 단지 요구할 수 있는 경우, 이러한 모듈의 우선순위 엔트리는 나이 정보를 저장할 수 있는 것이 가능하다. 해당 정보가 모듈에게 전달될 때, 상기 모듈은 이것이 모듈에 의해 사용되지 않기 때문에 우선순위 정보를 단순하게 무시할 수 있다. 또한, 상기 시스템은 상기 모듈과 연관된 우선순위를 추적할 수 있고, 더 이상 적절하지 않은 우선순위 데이터베이스로부터 해당 모듈과 연관되어 저장된 임의의 우선순위를 삭제할 수 있다.

도 10에 예시된 바와 같이, 엔트리들은 개인화된 컨테이너를 수신하도록 시스템에 접근하는 사용자 각각에게 제공될 수 있다. 또한, 이러한 도 10이 우선순위가 각각의 모듈에 대해 중복될 수 있다는 것(예를 들면, Bob라는 이름이 Mr. Bob Brown에 대한 3개의 모듈들 각각과 연관되어 저장된다)을 예시하는 반면, 또한 이들이 적용되는 모듈들에게 만들어진 우선순위를 가지고 사용자와 연관된 전체 테이블에 우순선위가 저장될 수 있는 것이 가능하다. 사용자에 대해 컨테이너에 포함될 여러 모듈들과 연관되어 우선순위를 저장하는 임의의 다른 기술들이 또한 본 발명의 범위 내에서 사용될 수 있다.

일실시예에 따르면, 또 다른 보안 특징이 우선순위 저장과 관련되어 구현될 수 있다. 특히, 사용자들에 대한 우선순위 값들은 다양한 모듈들에 대해 저장될 수 있기 때문에, 사용자들 및/또는 모듈 생성자들에 의해 요구되는 것이 아니라면, 하나의 모듈은 다른 모듈들(예를 들면, 공통적으로 제공되는 사용자 우편번호 우선순위에 기반하여 스트리트 지도상에 부가되는 날씨 지도를 보여주는 지도 모듈 및 날씨 모듈과 같이 함께 동작하는 2개의 모듈)에 대해 사용된 우선순위를 수정할 수 없다는 점이 중요하다.

이에 따라, 일실시예에서 우선순위를 설정하기 위해서, 모듈 서버는 HTML 내 모듈의 아이프레임 또는 코드 내에 토큰(Token)을 포함할 수 있다. 인라인 시스템에 대해서, 모듈 및 사용자가 이미 신뢰할 만한 것이라고 여겨졌기 때문에 상기 토큰은 디지털 서명(digital signature)을 포함할 수 있다. 이후, 인라인 모듈들(Inlined modules)은 다른 모듈, 컨테이너 또는 자신을 수정할 수 있다.

덜 신뢰받는 모듈들 상에 제공될 수 있는 아이프레임에 대해서, 상기 아이프레임은 컨테이너 서버와 연관된 쿠키들 없이 그리고 (컨테이너 사용자 식별 및/또는 모듈 식별을 포함할 수 있는 쿠키들을 포함하는, 상기 컨테이너에 의해 설정된 임의의 쿠키들이 해당 페이지 상에서 인라인으로 운영되는 모듈들에 접근할 수 있는 인라인 표시와 대비하여) 쿠키 내에 포함될 수 있는 임의의 연관된 자격(credentials) 없이 수치 IP 주소 역할을 할 수 있다.

이에 따라, 아이프레임 표시 모듈에 대해서, 토큰이 생성될 수 있는데, 컨테이너 및/또는 모듈 및/또는 사용자에 대한 정보를 포함한다. 따라서 모듈 식별(예를 들면, 디스플레이되는 모듈의 색인) 및 (암호화될 수 있는) 컨테이너 사용자 식별이 아이프레임에 제공될 수 있다.

토큰은 아이프레임에 전달될 수 있고, 이후 상기 모듈은 우선순위를 변형하고, 추가하거나 삭제하는 임의의 요구로 해당 토큰을 뒤로 전달하는 것을 기대할 수 있다. 상기 토큰은 이미 알려진 토큰 기술들에 따라 생성될 수 있지만, 예시적인 예가 다음과 같이 구해지며, 여기서 K1 및 K2는 서버에 대해 영숫자 문자들을 비밀로 할 수 있다:

우선순위를 변경하고나 추가하거나 삭제하는 요청이 수신된 경우, 모듈 서버는 데이터를 해독하고, 타임스탬프(timestamp)가 기설정된 허용 시간대(예를 들면, 15분) 내에 있는 것을 확인하며, 컨테이너 사용자 식별 및 모듈 식별을 조사하고, 서명 및 암호화된 데이터를 계산하고, 이후 모든 것이 부합되고 모든 요청된 갱신 파라미터들이 정확한 모듈 식별을 참조한다면, 우선순위들을 갱신하도록 모듈 스펙을 이용할 수 있다. 모듈 식별은 또한 모듈의 버전 각각에 대해 생성될 수 있다. 따라서 모듈 위치 참조는 토큰 내에 전달되지 않지만, 암호(예를 들면, HMAC 암호)를 생성하도록 계산하는데 사용될 수 있다.

타임스탬프가 추가적인 보안을 제공하는데 사용될 수 있다. 이것은 비인증된 사용자가 특정 인스턴스 상에서 토큰을 부호화할 수 있었다면 발생할 수 있는 손상을 제한시키는 역할을 할 수 있다. 보다 낮은 보안 레벨이 또한 사용될 수 있지만 상기 토큰 내의 모든 것은 추가적인 안전을 위해 암호화될 수 있다.

예를 들면, 토큰 시스템의 사용을 통해 사용자/모듈에 대한 우선순위 정보를 프로그램적으로 저장하도록 모듈 내에 자바스크립트가 생성될 수 있다. 유효한 토큰(예를 들면, 허용된 타임스탬프 범위)을 갖는 이러한 모듈은 지시해야 할 사용자 없이 우순순위 저장소에 데이터를 전달할 수 있다. 예를 들면, 사용자에 대한 업무를 제공하는 모듈은 모듈을 통해 신규 업무의 진입시 우선순위 저장소에 신규로 추가된 업무를 자동으로 업로드할 수 있다. 이후, 상기 업무 리스트는 우선순위 저장소에 저장될 수 있다.

다른 예시적인 예에 따르면, 우선순위 정보는 하나 이상의 원격 모듈드로부터 데이터를 생성하는데 사용될 수 있고, 이후 해당 정보는 다른 원격 모듈에게 제공될 수 있다. 예를 들면, 하나 이상의 지리적 위치들과 관련된 우선순위 정보가 저장될 수 있다. 이들 하나 이상의 지리적 위치들은 지도 서버(39)에 공급될 수 있는 정보를 생성하기 위해서 원격 모듈에게 제공될 수 있다. 지도 서버(39)는 이후 장소들의 위치, 장소들의 영상 등을 포함하는 지리적 위치 정보에 기반하여 데이터와 중첩되는 지도를 생성할 수 있다. 또한, 지도 서버(39)는 이러한 정보를 획득할 수 있고, 지도출력 또는 다른 출력을 생성할 수 있는 다른 원격 모듈에게 이것을 제공할 수 있다.

한 구체적인 예로서, San Francisco, CA와 같은 문자열이 우선순위 정보로 제공될 수 있다. 해당 문자열은 지오코드 서버(37)를 사용하여 지오코드 이치로 변환되고 원격 모듈에게 전달될 수 있다. 상기 지오코드 위치는 위도 및 경도 값을 포함할 수 있다. 원격 모듈은 지동 상에서 San Francisco, CA를 강조하는 세계지도를 디스플레이하도록 지도 서버용 데이터를 생성할 수 있다. "restaurants"와 같은 다른 우순순위 정보가 제공되는 경우, 이후 샌프란시스코 근처의 레스토랑 위치가 지도상에 도시될 수 있다. 많은 다른 예들이 본 발명의 범위 내에서 확실하게 가능하다.

프록시 서버 수집 시스템의 예시( Illustrative Proxy Server Collection System)

본 발명의 다른 실시예에 따르면, 컨테이너 문사에 통합되는 모듈을 사용함으로써, 목표 사이트로부터 데이터를 수집하고, 사용자에 의해 디스플레이되길 원하는 방식으로 이것을 재변환하는(reformatting) 방법이 구현될 수 있다. 예를 들면, 사용자가 골프의 열광팬이고 규칙적으로 골프 웹사이트에 접속한다고 가정한다. 하지만, 골퍼는 골프를 플레이하는 방법에 대한 기사 및 정보에 관심이 있지만 PGA 투어 및 다른 전문적인 골프 이벤트와 관련된 이벤트들에 대해서는 관심이 없다. 모듈은 골프 사이트 적용 코드로부터 데이터를 수집하는 스크립트를 갖도록 설계될 수 있는데, 상기 코드는 컨테이너에 표시하기 위한 데이터를 생성하도록 골프 웹사이트로부터 수집된 데이터를 변형하고 처리한다. 골프 웹사이트로부터 데이터를 수집하도록 모듈에 의해 사용되는 코드는 로봇처럼 골프 웹사이트에 의해 또는 다른 불허된 접근 방법으로 시청될 수 있다. 이것은 요청자가 골프 웹사이트에 익숙하지 않은 소스로부터 기인한 것인 경우 특히 사실일 수 있다. 예를 들면, 이러한 모듈의 생성자가 미지의 웹사이트 운영자인 경우, 이러한 요청은 골프 웹사이트에 의해 차단되거나 아니면 배제당할 수 있다.

호스트 서버 시스템의 운영자는 개별적인 골프 사이트에 대해 또는 큰 커뮤니티에 대해 이미 알려진 엔티티(entity)일 수 있다. 따라서 이러한 사이트로부터 데이터에 대한 요청은 대개는 배척되지 않게 된다. 컨테이너 사이트와 연관된 신뢰를 이용하기 위해서, 호스트 서버 시스템(프록시 서버 주소)과 연관된 서버를 사용하여 골프 사이트(예를 들면, 대상 수집 사이트)로부터 정보를 요청하도록 상기 모듈 생성자 시스템 대신에 작용하는데 프록시 서버가 사용될 수 있다. 이후, 골프 사이트로부터의 정보는 모듈 생성자 시스템에 의해 수신될 수 있고, 해당 모듈 생성자에 의해 원하는 형식으로 처리될 수 있는데, 예를 들면, PGA 토너먼트와 관련된 페이지 상의 기사를 제거하고, 아마추어 골프에 대한 정보를 강조하며, 모듈 생성자에 적합하도록 텍스트 내의 용어 이름들을 바꾸고(mashie niblik 대신에 7번 아이언(iron)으로 바꾸는 것), 모듈 생성자에게 적합하도록 페이지 내의 컨텐츠를 재정렬하며, 또는 모듈 생성자가 상기 대상 수집 시스템으로부터 데이터에 적용하기를 원하는 임의의 변경, 대체, 교환, 삭제, 추가 또는 동작이 이루어질 수 있다.

이러한 시스템의 일례가 도 11에 예시된다. 도 11은 도 1과 관련되어 기재된 바와 같은 구성요소들 사이의 배치 및 관계가 도 11에 마찬가지로 적용된다는 점이 도 1과 관련하여 이해되어야 한다. 도 11에 도시된 바와 같이, 모듈 서버(32) 및 컨테이너 서버(12)와 연동하여 동작할 수 있는 프록시 서버(52)가 제공될 수 있다.

스펙 서버(24)는 모듈 생성자 시스템(54)과 마찬가지로 동작할 수 있다. 또한, 대상 컨텐츠 서버(56)가 도시되어 있다. 전술한 바와 같이, 일실시예로서, 모듈 스펙은 스펙 서버(24)에 접근할 수 있는 장소에 저장될 수 있다. 컨테이너가 컨테이너 서버(12)에 의해 열리면, 대상 수집 모듈이 식별될 수 있다. 이후, 모듈 서버(32)는 상기 모듈에 대한 데이터를 제공하도록 호출될 수 있다. 모듈 서버(32)는 스펙 서버가 네트워크상의 스펙 서버(24)의 위치에 있는지를 결정할 수 있다. 대상 수집 모듈에 대한 코드는 스펙 서버(24)로부터 모듈 서버(32)에 의해 검색될 수 있다. 이후 해당 코드는 사용자에게 디스플레이되도록 컨테이너 서버(12)에게 전달될 수 있다. 사용자 시스템(22)은 모듈을 열고, 모듈 데이터내의 코드에 기반하여 대상 컨텐츠 서버(56)로부터 데이터를 검색하도록 프록시 서버(52)로부터 데이터에 대한 요구를 전송할 수 있다. 대상 컨텐츠 서버(56)로부터의 데이터는 프록시 서버(56)에게 전달되고, 이후 사용자 시스템에게 제공되는데, 여기서, 모듈 내의 추가적인 코드가 모듈 내의 코드에 기반하여 해당 데이터를 변형하고 및/또는 처리할 수 있다. 해당 데이터에 대한 임의의 변형 및 처리는 스펙 서버(24)에서 발생할 수 있고, 이후, 해당 데이터는 컨테이너 서버(12)에게 제공되는 모듈 서버(32)에게 제공되어 사용자가 데이터를 생성할 수 있게 된다.

인터넷 상의 많은 시스템들이 싫어하는 개방형 프록시(open proxy)로 사용되고 있는 프록시를 회피하기 위해서, 프록시 서버(52) 및 브라우저 시스템은, 우선순위의 갱신과 관련하여 전술한 바와 같이 토큰의 사용과 같은 인증 기술을 사용할 수 있다. 특정된 유효 토큰이 사용자 시스템으로부터 전달되는 경우, 프록시 서버(52)는 요청을 수행할 수 있는데, 이것은 사용자 시스템에게 제공되는 모듈 코드의 일부이기 때문이다. 게다가, 프록시 서버 및 사용자 시스템 모두에 임시저장하는 것은 데이터의 전달을 촉진시키는데 사용될 수 있고, 대상 사이트 서버에서 이루어진 호출 수를 줄일 수 있다.

프록시 서버(52)가 또한 인터넷을 통해 다른 시스템들에게 연결될 수 있다는 점이 인정되어야 한다. 일실시예로서, 프록시 서버(52)는, 호스트 서버 시스템(10)의 평판을 도입하기 위해 호스트 서버 시스템(10)과 연관된 및/또는 호스트 서버 시스템(10)에 의해 승인되거나, 인증되거나 또는 자격이 주어진 주소를 사용함으로써, 대상 컨텐츠 서버(56)가 데이터에 응답할 수 있게 된다.

도 12에 프록시 방법(1200)이 예시된다. 1202 단계 블록에서, 컨테이너 문서가 열릴 수 있다. 1204 단계 블록에서, 대상 사이트로부터 데이터를 수집하기 위해 코드를 포함하는 모듈이 식별될 수 있다. 1206 단계 블록에서, 모듈 컨텐츠는 모듈 서버(32)에 의해 사용자에게 HTML로 전송된다. 1208 단계 블록에서, 대상 수집 사이트로부터 데이터를 수집하기 위해서, 사용자 시스템(예를 들면 브라우저)은 코드(예를 들면, 데이터를 수집하고 처리하는 자바스크립트)를 포함하는 HTML을 번역한다. 1210 단계 블록에서, 사용자 시스템은 프록시 서버에게 목표 사이트 데이터의 수집의 요청을 전달한다. 많은 브라우저들은 강조하는 HTML을 전송하는 서버와 다른 서버를 호출하는 스크립트 언어(예를 들면, 자바스크립트)로 동작하지 않는다는 점에 주의해야 한다. 따라서 프록시 서버 및 컨테이너 서버가 공통 소스로 연관될 수 있기 때문에 브라우저는 요청을 처리하게 된다.

1210 단계 블록에서, 프록시 서버는 대상 사이트로부터 데이터를 수집하고 이것을 사용자 시스템에게 전달한다. 예시적인 일실시예에 따르면, 트롤러(trawler)로서 참조되는 프로그램은 대상 사이트로부터 데이터를 수집하는데 사용될 수 있다. 이러한 서비스는 통상적으로, 웹 검색 엔진에 의해 사용되는 웹 페이지 데이터를 임시저장하기 위한 기술들과 유사하게, 이른바 로봇 배제 정보(robot exclusion information) 및 호스트 로드(host load) 문제를 고려하게 된다. 1214 단계 블록에서, 사용자 시스템은 모듈 스펙 내의 코드에 기반하여 대상 사이트로부터 수집된 데이터를 처리하고, 처리된 대상 사이트 데이터에 기반하여 디스플레이 데이터를 생성한다. 1216 단계 블록에서, 사용자 시스템은 모듈에 의해 특정된 형식으로 처리된 대상 사이트 데이터(선택사항으로서, 데이터는 처리 없이 대상 사이트 데이터가 될 수 있다)를 갖는 컨테이너 문서를 디스플레이한다.

다른 실시예에 따르면, 프록시 서버(52)는 프록시 요청의 배경에서 전술한 기능을 수행하는 분석 모듈(26)과 선택적으로 연결되고 포함할 수 있다. 예를 들면, 프록시 서버(52) 및 분석 서버(26)는 불허된 사이트들, 불허된 동작들, 불허된 컨텐츠 등의 리스트에 대한 요청들을 분석할 수 있다. 게다가, 요청들은 승인된 사이트, 동작들, 컨텐츠들에 대해 비교될 수 있다. 그 평가는 위치 참조(예를 들면, URL) 또는 대상 사이트, 요청의 형식, 대상 사이트에 제공되는 우선순위 값, 시간, 사용자 정보, 모듈 스펙 소스, 요청 시스템 또는 임의의 다른 입력에 기반하여 이루어질 수 있다.

다른 실시예들에 따르면, 모듈 스펙은 프록시 서버를 제어할 수 있는 인스트럭션들을 제공할 수 있다. 프록시 서버(52)는 동작을 위해 이들 인스트럭션들을 사용할 수 있다. 한 인스트럭션은 임시저장된 버전을 사용하는 것이 아니라 신규 복사본을 제공함으로써 대상 사이트로부터 데이터를 프록시 서버가 수집하는 방법을 지시할 수 있다. 다른 인스트럭션은 캐시 및 그 동작을 제어할 수 있는데, 캐시를 비우거나 캐시를 업그레이드할 때를 지시하는 것을 포함한다.

다른 실시예에 따르면, 대상 사이트들은 프록시 서버 동작들을 제어할 수 있거나 또는 프록시 서버가 바람직하게 동작하는 방법에 대한 지시를 적어도 제공할 수 있다. 로봇 배제 파일(예를 들면, robots.txt)은 프록시 서버가 동작할 수 있는 방법 및 프록시 서버가 전혀 데이터를 수집하지 않는 것을 지시하는 것을 포함할 수 있다. 프록시 서버(52)는 대상 사이트에 의해 제공되는 인스트럭션들을 고려할 수 있다. 메가 태그(Mega tag)가 또한 대상 사이트에 의해 제공될 수 있다. 인스트럭션들을 제공하는 다른 방법들이 또한 제공될 수 있다.

제공되는 인스트럭션들은 프록시 서버(52)에게 다수의 작업들을 지시할 수 있는데, 리프레시 속도, 프록시 서버(52)가 컨텐츠(예를 들면, 사용자, 모듈 스펙(URL에 의해 또는 달리 지정된), 수집될 데이터의 종류 등)를 수집할 수 있는 경우 및 해당자에 대한 속성들을 포함한다.

여러 실시예들에 따르면, 데이터의 변형은 모듈 출력에 결과를 병합하기 위해서 다중 대상 사이트 소스로부터 데이터를 획득하는 것을 포함할 수 있다. 예를 들면, 모듈은 신규 소스로부터 데이터 공급을 획득하고, 블로그로부터의 출력을 갖는 데이터를 단일 출력과 병합할 수 있다. 예들로서, RSS/Atom 데이터 공급을 HTML 출력으로 포맷하기, 변환하기 및/또는 재포맷하기를 포함할 수 있다; 예를 들면, 원형(prototyping)의 모듈을 생성하도록 웹사이트 HTML을 수집하기, 다중 웹 페이지들 및/또는 데이터 공급으로부터 컨텐츠를 혼합하기("mashing up"), 컨텐츠를 변환하기, 보다 용이한 표시를 위해 사용중("busy") 컨텐츠를 비우기, 및 다른 형식의 멀티미디어 컨텐츠 등을 포함하기 등을 예로 들 수 있다. 특정하게 예시적인 예들로서, 신문 소스로부터 RSS 공급을 획득하는 것, 폰트를 추가하는 것 및 신문의 로고를 추가하는 것을 포함할 수 있다; 특정 키워드 또는 어구를 언급하는 헤드라인을 굵게 하기, 허구 기사를 주기적으로 포함하는 것, 데이터 공급시 장소-명칭을 마우스-오버( mouse-over) 지도로 바꾸는 것, 상대적으로 능동적인 웹사이트로부터 데이터를 획득하는 것, 사용자가 선택한 필수적인 링크 및/또는 특징들을 갖는 모듈들을 생성하는 것 그리고 보다 많은 것을 포함한다.

프록시 데이터의 변형을 통해 생성되는 데이터를 포함하는 컨테이너 문서의 예가 도 13에 예시된다. 운세 모듈(horoscope module)이 운세 RSS로부터 수집되는 데이터를 포함하는 컨테이너 문서 내에 포함되며, 이후 사용자에게 특정되는 텍스트로 변형된다. 뉴스, 날씨 및 지도가 포함될 수 있는 신규 모듈 내에 다른 프록시 서버의 예가 도시되어 있다. 여기서, 뉴스 소스로부터의 텍스트는 결과적으로 수집되는 정보 내에서 강조된 "George Bush" 라는 용어로 수집된다.

프록시 서버의 사용 및/또는 전술한 프로세스를 통해, 여러 장점들이 구현될 수 있다. (소프트웨어의 다운로드가 본 발명의 범위 내에서 틀림없이 가능하지만) 요구되는 다운로드 없이 브라우저와 같은 사용자 시스템에 의해 용이하게 사용될 수 있는 방식으로 사용자를 위한 모듈들이 생성될 수 있다. 사용자들은 모듈들을 통합하고 여러 위치들에서 모듈들을 촉진시키는 모듈들의 분배를 통해서 컨텐츠를 발표할 수 있다. 프록시 기술들을 이용하여 모듈을 생성하는 것은 시스템이 사용할 수 있는 일군의 툴들을 통해 용이하게 이루어질 수 있다. 또한, 사용자 우선순위를 프록시하고 저장하기 위해서 축척 가능한 백엔드 서버를 제공하는 것은 또한 이들 모듈들의 장점을 사용자들에게 제공한다.

기타 예들의 예시( Other Illustrative Examples )

따라서 본 발명의 여러 실시예들은 하나 이상의 호스트 서버 시스템들에 의해 제공되거나 하나 이상의 호스트 서버 시스템에 의해 배급된 컨테이너 상에서 사용되는 모듈들을 호스트 서버 시스템에 대한 서드 파티가 생성하게 한다. 이들 모듈은 용이하게 이해하고 적용할 수 있는 스펙에 따라 생성된다. 복잡함 모듈들은 예를 들면, https, 인증, 크기 조정에 대한 지원, 빌트인 라이브러리 등이 가능할 수 있고, 원격 컨텐츠 생성자들은 소프트웨어 개발 키트(SDK)를 다운로드하거나 습득함이 없이 모듈들을 개발하고 디버깅할 수 있다. 일부 실시예들에서, XML과 같은 표준 플랫폼이 사용될 수 있고, 이에 따라 사용되는 실제 코드는 모듈과 관련된 데이터를 결국 디스플레이할 사용자 시스템에 의해 번역될 수 있는 임의의 코드일 수 있다. 예를 들면, 보다 많고 풍부한 라이브러리, 문서 및 예시 모듈들을 포함하는 자바스크립트 및 다른 언어들에 대한 지원 및 보다 양호한 디버깅 능력이 제공될 수 있다.

예를 들면, 코드는 RSS/Atom 공급에 대해 커스텀 렌더링(custom rendering)을 수행하는 모듈들에 대해 생성될 수 있다. RSS/Atom은 웹에게 읽기전용 컨텐츠를 발행하는 기술이고, 컨테이너 페이지 상에 사용되는 많은 모듈들은 풍부한 양방향성을 제공하는 페이지들과 링크되는 흔히 읽기 전용이다. 게다가, 호스트 서버 시스템(10)은 그 사용을 기록하게 할 수 있는 모듈들에 대한 데이터를 유지할 수 있다. 이것은 모듈의 개별적인 사용 각각에 대한 정보, 모듈의 이력, 모듈에 대한 변형, 모듈의 배급, 통화 값과 관련된 회계 정보 및 모듈과 관련된 계약들 그리고 상기 모듈에 대한 기록을 위해 사용될 수 있는 다른 종류의 정보를 포함할 수 있다.

XHTML 종류를 포함하는 추가적인 모듈 종류들이 또한 생성될 수 있고, 또는 다른 시스템으로부터의 모듈이 가능할 수 있다. 생성될 수 있는 추가적인 모듈의 예는 RSS 정보를 획득하고 예를 들면, 사진 블로그로부터의 데이터를 포함하는 컨테이너에 이것을 포함시킬 수 있는 형식으로 제공하는 모듈을 포함한다. 다른 모듈들은, Gmail, AOL Mail, MSN Hotmail 및 Yahoo! Mail과 같은 대중적인 웹-기반 이-메일 시스템을 위한 이-메일 리더(email reader)를 포함할 수 있다. 모듈은 채팅 데이터 및 인스턴스 메시징 데이터를 통합하도록 생성될 수 있다. 간단한 애플릿(applet)이 시계, 계산기, 노트패드 등과 같은 모듈들과 통합될 수 있다. eBay, Amazon 및 다른 온라인 시장과 같은 상품의 구매자 및 판매자를 위한 온라인 시장들로의 인터페이스로 동작하는 다른 모듈들이 생성될 수 있다. 모듈들은 또한 다양한 엔티티들에 대한 내부 데이터용으로 생성될 수 있다. 예를 들면, 엔티티의 인트라넷 서비스들이 컨테이너에 포함시키기 위한 모듈들에게 제공될 수 있다.

이러한 모듈들의 사용은, 예를 들면, 검색 엔진들, 이-메일 등을 통해 모듈 스펙의 URL을 거래하는 사용자들을 고려할 수 있다. 게다가, 다른 페이지 상의 요청 입력을 통해 컨테이너에게 추가되는 여러 특징들을 허용할 수 있는 인터페이스가 가능하다. 예를 들면, 골프 사이트상에, "컨테이너에 모듈로서 추가*add as a module to a container)" 라고 표시된 링크 또는 버튼이 있을 수 있다. 컨테이너는 미리 특정될 수 있거나 또는 사용자로부터 입력될 수 있다. 해당 링크 또는 버튼은, 그 개인화된 홈페이지와 같은 컨테이너상의 컨텐츠를 사용자가 포함할 수 있게 하는 방식으로서 강조하는 페이지의 생성자에 의해 포함되는 코드에 기반하여 동작된다.

또한, 검색 시스템에게 모듈 정보의 제공을 통해서 모듈의 색인이 생성될 수 있는데, 컨테이너 문서가 모듈 스펙을 검색할 때, 검색 시스템에게 상기 컨테이너 서버에 의해 전달될 수 있다.

또한, 피드백 모듈이 피드백, 통계 및 기타 모듈 관련 데이터를 수집하게 위해 제공될 수 있는데, 모듈의 사용자, 컨테이너 문서 제공자, 대상 사이트 운영자 및 기타 시스템 및/또는 네트워크와 관련된 다른 관계자에 의해 제공되는 정보를 포함한다. 이러한 정보 및 데이터는 랭킹 모듈(ranking module) 또는 다른 모듈을 통해 사용자에게 표시될 수 있다. 랭킹 모듈은 피드백, 승인, 사용, 통계 또는 다른 기준에 기반하여 모듈들에게 순위를 매길 수 있고, 사용자 또는 편집 비평(editorial commentary)에 기반하는 랭킹을 포함할 수 있다.

또한, 모듈들이 사용자 또는 컨테이너 페이지에 대한 입력에 기반하여 제안될 수 있는데, 검색 이력, 시청된 문서의 키워드 등을 포함할 수 있다. 다른 기술들이 배급을 위한 모듈들을 촉진시키는데 또한 사용될 수 있다.

다른 예시적인 예로서, 신뢰받을 수 있는지에 대한 결정에 기반하여, (예를 들면, 사용자 이름, 이미지, 특징, 로고 등을 추가함으로써) 컨테이너 문서의 임의 구성요소를 사용자가 개인화하게 하는 컨테이너 문서를 변형하는 모듈이 생성될 수 있다. 다른 예시적인 모듈은, 컨테이너 페이지와의 상호작용을 통해 컨테이너 페이지상의 다른 모듈들의 리스트를 획득할 수 있고, 예를 들면, 모듈들을 변형시키는 능력을 포함하는 모듈들에 대한 메타데이터를 획득할 수 있고, 모듈들에 대한 사용자 우선순위들을 획득할 수 있다. 시험 목적을 위한 다른 모듈들, 리프레시 모듈들(예를 들면, 플러시 캐시 또는 갱신 캐시) 및 다른 동작들을 인라인 또는 아이프레임을 위해 개발자 모듈이 개발될 수 있다.

본 발명은 본 명세서에 개시된 특정 실시예들에 의해 범위가 국한되지 않는다. 실제로, 본 명세서 내에 개시된 것들에 추가하여 다른 여러 실시예들 및 변경들이 전술한 발명의 상세한 설명 및 첨부된 도면으로부터 본 발명이 속하는 분야의 당업자에게 명백하게 이해될 것이다. 따라서 이러한 다른 실시예들 및 변경들이 본 발명의 범위 내에 있게 된다. 또한, 본 발명이 특정한 목적을 위해 특정한 환경에서 특정한 구현으로 본 명세서 내에 설명되었지만, 본 발명이 속하는 분야의 당업자는 그 사용이 이에 국한되는 것이 아니고 본 발명이 임의의 수의 목적들을 위해 임의의 수의 환경에서 유용하게 구현될 수 있다는 점을 인정할 것이다. 따라서 이하 개시되는 청구범위들은 본 명세서 내에 설명된 본 발명의 완전한 이해 및 정신의 관점에서 해석되어야 한다.

Claims

모듈(module)에 사용하기 위해서 특정하게 요청된 언어(requested language)의 메시지 목록(message catalog)에 대해서 요청자(requestor)로부터 요청을 수신하는 수신 서버(receiving server);
제1 언어로 메시지 목록을 검색하는 검색 서버(retrieving server);
상기 제1 언어가 상기 요청된 언어와 동일하지 않은 경우, 상기 메시지 목록을 상기 요청된 언어로 번역하는 번역기(translator); 및
상기 메시지 목록 또는 상기 메시지 목록의 메시지 참조를 상기 요청자에게 전송하는 전송 서버(transmitting server)를 포함하는 시스템.
모듈(module)에 사용하기 위한 특정하게 요청된 언어(requested language)의 메시지 목록(message catalog)에 대해서 요청자(requestor)로부터 요청을 수신하는 단계;
제1 언어로 메시지 목록을 검색하는 단계;
상기 제1 언어가 상기 요청된 언어와 동일하지 않은 경우, 상기 메시지 목록을 상기 요청된 언어로 번역하는 단계; 및
상기 메시지 목록 또는 상기 메시지 목록의 메시지 참조를 상기 요청자에게 전송하는 단계를 포함하는 것을 특징으로 하는 방법.
제 2 항에 있어서,
상기 제1 언어로 메시지 목록을 검색하는 단계는, 언어 및 국가에 기반하여 상기 모듈에 대한 적합한 메시지 목록을 식별하는 단계를 더 포함하는 방법.
제 2 항에 있어서,
메시지 교체를 수행하는 단계를 추가로 포함하는 방법.
제 2 항에 있어서,
상기 메시지 목록으로부터 메시지를 출력시키는 단계를 추가로 포함하는 방법.
제 2 항에 있어서,
상기 메시지 목록으로부터 메시지의 부분집합(subset)을 형성하도록 모듈을 분석하는 단계를 추가로 포함하는 방법.