KR20190132573A - 제 3 자 애플리케이션 통신 에이피아이 - Google Patents

Abstract

웹사이트 구축 시스템용 디바이스. 상기 디바이스는 적어도 하나의 제 3 자 애플리케이션의 웹사이트 인스턴스를 보유하는 페이지를 생성하기 위한 페이지 작성기 및 상기 페이지와 상기 적어도 하나의 제 3 자 애플리케이션 사이의 또는 상기 적어도 하나의 제 3 자 애플리케이션과 적어도 하나의 다른 제 3 자 애플리케이션 사이의 양방향 통신 백채널을 형성하기 위한 구성기를 포함한다. 상기 디바이스는 상기 페이지가 뷰되거나 액세스되는 경우 상기 통신 백채널에 따라서 통신을 조율하기 위한 조율기를 더 포함한다.

Description

제 3 자 애플리케이션 통신 에이피아이{THIRD PARTY APPLICATION COMMUNICATION API}

본 발명은 온-라인 애플리케이션 및 특히 보유된 제 3 자 애플리케이션을 사용한 그들의 용법에 관한 것이다.

웹사이트 및 다른 온-라인 애플리케이션을 생성하고 편집하기 위하여 사용되는, 상업적으로 입수가능한 많은 웹사이트 구축 시스템 및 다른 대화형 애플리케이션 구축 툴이 존재한다. 최종 사용자는 정규의 개인용 컴퓨터, 스마트 폰, 태블릿 및 다른 데스크탑 또는 모바일 디바이스와 같은 다양한 상이한 플랫폼 상의 클라이언트 소프트웨어를 사용하여 이러한 웹사이트에 액세스할 수 있다.

이를테면 이러한 웹사이트 구축 시스템은, 인터넷에 연결되는 서버 또는 서버들 상에서 호스팅되고 하이퍼텍스트 전송 프로토콜(HTTP)과 같은 인터넷 통신 프로토콜을 사용하여 액세스되는 완전 온-라인 웹사이트 구축 시스템과 같이 상이한 구성에서 나타날 수 있다. 이러한 웹사이트 구축 시스템의 생성, 편집 및 배치는 모두 직접적으로 서버와 동작하면서 온-라인으로 수행된다.

웹사이트 구축 시스템은 또한 부분적으로 온라인이거나 가끔은 심지어 완전히 오프라인일 수 있다. 부분적 온라인 시스템에 대하여, 웹사이트 편집은 국지적으로 사용자의 머신에서 수행되고, 배치를 위하여 중앙 서버 또는 서버들로 추후에 업로드된다. 업로드되면, 이러한 웹사이트 구축 시스템은 풀 온-라인 웹사이트 구축 시스템과 동일한 방식으로 동작한다.

웹사이트 구축 시스템은 시스템 내의 데이터 및 엘리먼트를 조직화하기 위하여 내부 데이터 아키텍처를 가진다. 이러한 아키텍처는 사용자에 의하여 목격되는 바와 같은 문제의 사이트의 외부 뷰와는 상이할 수도 있고 또한 통상적인 하이퍼텍스트 마크업 언어(HTML) 페이지가 브라우저로 전송되는 방식과는 상이할 수도 있다. 예를 들어, 내부 데이터 아키텍처는, 웹사이트 구축 시스템 내에서 사이트를 편집하고 유지보수하기에 필수적이지만 외부적으로 말단-사용자에게(또는 심지어 일부 편집 사용자에게)는 보이지 않는, 페이지 상의 각각의 엘리먼트(생성기, 생성 시간, 액세스 허가, 템플릿으로의 링크 등)에 대한 추가적 속성을 보유할 수 있다. 웹사이트 구축 시스템 기초 사이트에 대한 통상적 아키텍처는 페이지 보유 컴포넌트(예를 들어 형상 컴포넌트, 픽쳐 컴포넌트, 텍스트 컴포넌트, 미니-페이지를 보유하는 단일- 및 멀티-페이지 컨테이너, 등)를 보유하는 페이지로 이루어질 수도 있다.

컴포넌트는 임의의 내부 콘텐츠를 가지지 않는(비록 이것은 컬러, 사이즈, 포지션 및 몇몇 다른 속성을 가질 수 있지만) 별-형상과 같은 무콘텐츠일 수도 있고, 또는 텍스트 문단 컴포넌트와 같은 내부 콘텐츠를 가질 수도 있는데, 이것의 내부 콘텐츠는 디스플레이된 텍스트, 및 폰트, 포매팅 및 레이아웃 정보를 포함한다. 물론, 이러한 콘텐츠는 텍스트 문단 컴포넌트의 인스턴스 별로 변동할 수도 있다.

이러한 웹사이트 구축 시스템을 사용하는 디자이너는 신규 생성을 스크래치 수준에서부터(빈 스크린으로부터 시작하여) 설계할 수도 있고, 또는 디자이너 자신에 의하여, 시스템 생성기에 의하여, 또는 디자이너 커뮤니티에 의하여 생성되는 선정의된 애플리케이션 템플릿에 의존할 수도 있다. 웹사이트 구축 시스템은 단순한 컴포넌트 콜렉션, 완전한 페이지(또는 미니 페이지) 또는 심지어 페이지 및 완전한 웹 사이트의 세트인 템플릿을 지원할 수도 있다.

애플리케이션 템플릿이 제공되는 경우, 디자이너는 이것을 임의로 맞춤화 - 템플릿의 모든 엘리먼트를 추가, 제거, 또는 수정하여 템플릿의 그의 또는 그녀의 버전을 생성할 수 있다. 이러한 맞춤화는 템플릿의 수정된 버전(템플릿과는 별개이고 이것과는 분리됨)을 생성함으로써 구현될 수도 있다. 대안적으로는, 웹사이트 구축 시스템은, 원래의 템플릿으로의 링크를 보유하고 따라서 그 템플릿에 이루어진 추후 변경을 반영할 유산-타입 메커니즘을 통해서 맞춤화를 적용할 수도 있다.

또한 웹사이트 구축 시스템은 그들 안에 임베딩된 제 3 자 애플리케이션 및 컴포넌트를 사용하여 확장될 수 있다. 이러한 제 3 자 애플리케이션은 웹사이트 구축 시스템 디자인 환경 내에 포함될 수도 있고 또는 다수 개의 분산 메커니즘을 통하여, 예컨대 웹사이트 구축 시스템에 통합되는 애플리케이션 스토어(앱스토어(AppStore))로부터, 또는 웹사이트 구축 시스템(website building systems; WBS) 벤더에 의하여 또는 다른 엔티티에 의하여 운영되는 별개의, 웹-기초 또는 독립형 애플리케이션 저장소(또는 앱스토어)로부터 개별적으로 구매(또는 다른 방식으로 획득)될 수도 있다. 제 3 자 애플리케이션은 또한 제 3 자 애플리케이션 벤더로부터 직접적으로(앱스토어를 거치거나 거치지 않고서) 획득될 수도 있다 - 이것은 실제 설치 모듈을, 또는 단지 활성화 또는 액세스 코드만을 제공할 것이다.

제 3 자 애플리케이션은 프론트-엔드(디스플레이) 엘리먼트의 백-오피스(back-office) 엘리먼트(시각적 웹 사이트 디스플레이의 부분이 아님)와의 임의의 조합을 포함할 수도 있다. 제 3 자 애플리케이션은 전체적으로 백-오피스이거나(즉 디스플레이 엘리먼트를 포함하지 않음), 전체적으로 프론트-엔드이거나(즉 오직 웹 사이트 사용의 콘텍스트 내에서만 활성화됨) 또는 두 개의 조합일 수도 있다.

제 3 자 애플리케이션의 백-오피스 엘리먼트는 데이터-베이스 통신, 외부 업데이트 옵션 등과 같은 기능을 포함할 수도 있다. 예를 들어, 블로그 제 3 자 애플리케이션은, 업데이트가 비-인위적 소스(예를 들어 메이저 뉴스 서비스로부터의 RSS 뉴스 피드)로부터, 그리고 그 웹 사이트에 관련되지 않은 인위적 소스(예를 들어 블로그 엔트리의 제출을 허용하는 독립형 스마트 폰 애플리케이션)로부터 수신되도록 하는 백-오피스 엘리먼트를 포함할 수도 있다.

제 3 자 애플리케이션의 시각적 엘리먼트를 보유하는 웹 사이트에 통합하는 것은 여러 방식으로 이루어질 수 있다. 위젯-타입 제 3 자 애플리케이션은 웹 사이트 페이지 내에 컴포넌트로서 임베딩될 수 있는 반면에 섹션-타입 제 3 자 애플리케이션은 웹 사이트에 추가적 페이지 또는 페이지들로서 추가될 수 있다.

더욱이 제 3 자 애플리케이션(위젯 및 섹션 모두)은 단일-페이지 제 3 자 애플리케이션 또는 멀티-페이지 제 3 자 애플리케이션(내부 URL 구조로서 표현된 내부 미니-페이지를 포함하는 것)일 수 있다. 시스템은 4 개의 가능한 조합(위젯 또는 섹션, 단일-페이지 또는 멀티-페이지) 중 임의의 것 또는 모든 것을 구현할 수도 있다.

멀티-페이지 제 3 자 애플리케이션은 보통 디폴트 "랜딩" 미니-페이지를 제공하는데, 이것은 오프닝 페이지, 특정 내부 미니-페이지(예를 들어 블로그 제 3 자 애플리케이션 내의 가장 최근의 블로그 엔트리), 미니-페이지 선택 스크린 또는 몇몇 다른 미니-페이지일 수 있다.

웹사이트 구축 시스템-기초 웹 사이트에서 제 3 자 애플리케이션을 사용하는 것은 제 3 자 애플리케이션 인스턴스를 통해서 이루어진다. 웹사이트 구축 시스템은 다수의 레벨에서의 제 3 자 애플리케이션의 다수의 사용을 지원할 수도 있고, 예컨대 전체 웹 사이트에서 단일 제 3 자 애플리케이션 인스턴스를 허용하는 것; 웹 사이트 내에서 다수의 제 3 자 애플리케이션의 인스턴스들이 생성되도록 허용하는 것(하지만 임의의 주어진 제 3 자 애플리케이션의 두 개 이상의 인스턴스는 허용하지 않음) 그리고 다수의 제 3 자 애플리케이션의 다수의 인스턴스가 생성되도록 허용하지만 주어진 페이지 당 두 개 이상의 인스턴스를 허용하지 않는 것을 지원할 수도 있다. 또한 이것은 컴포넌트 제 3 자 애플리케이션의 페이지 당 다수의 인스턴스를 허용하지만 섹션 제 3 자 애플리케이션은 허용하지 않을 수도 있고, 또한 다수의 제 3 자 애플리케이션의 다수의 인스턴스가 제 3 자 애플리케이션 인스턴스의 양, 중복(multiplicity) 또는 위치에 대한 임의의 제한사항이 없이 생성되도록 허용할 수도 있다.

제 3 자 애플리케이션 인스턴스는 인스턴스-특이적 콘텐츠를 가질 수도 있다. 예를 들어, e-상점 제 3 자 애플리케이션은, 동일한 e-상점 제 3 자 애플리케이션(동일한 사이트 또는 다른 사이트 내의)의 다른 인스턴스와 연관된 제품 데이터베이스와는 상이한, 특정한 인스턴스와 연관된 제품 데이터베이스를 가질 수도 있다.

논의를 위하여, 제 3 자 애플리케이션을 보유하는 웹 사이트 페이지(또는 미니-페이지) 및 이것의 미니-페이지 또는 엘리먼트(즉 "래퍼(wrapper) 페이지")는 보유하는(containing) 웹 페이지로서 그리고 전체 웹 사이트에 대해서는 메인 사이트로서 알려질 것이다. 사용자에게 표시되는 통합 페이지 - 메인 페이지 및 임베딩된 TPA 미니-페이지 / 컴포넌트를 포함 - 는 결합 페이지(combined page)라고 지칭될 것이다. 섹션 타입 제 3 자 애플리케이션에 대하여, 제 3 자 애플리케이션을 보유하는 "가상 페이지" 는 보유 웹 페이지로서의 역할을 할 것이다.

제 3 자 애플리케이션은 일반적으로 웹사이트 구축 시스템 벤더 서버 상에, 제 3 자 애플리케이션 벤더 서버 상에, 외부(제 4 자) 서버 상에, 또는 이들의 임의의 조합 중 하나에 배치된다. 제 3 자 애플리케이션은 또한 최종 사용자 머신에서 실제로 실행중인 엘리먼트, 예컨대 이제 참조할 도 1 에 도시되는 바와 같은 정적-설치 브라우저 확장 또는 웹사이트 구축 시스템 클라이언트측 코드 내에서 실행 중인 동적 실행 자바스크립트 컴포넌트를 포함할 수도 있다.

웹사이트 구축 시스템 벤더의 서버는 말단-사용자에 대한 콘택 포인트로서의 역할을 하고, 요청에 응답한다(가능하게는 요구된 정보를 수신하기 위하여 제 3 자 애플리케이션 벤더의 서버에 연결됨). 웹사이트 구축 시스템은, 예를 들어 비디오 스트리밍이 요구되는 경우 클라이언트 컴퓨터와 제 3 자 애플리케이션 벤더의 서버 사이에 직접 연결을 생성할 수도 있다(요구될 때).

포함된 제 3 자 애플리케이션 인스턴스는, 정규 컴포넌트가 내부 콘텐츠를 포함하는 방식과 유사하게 그들 스스로의 내부 콘텐츠를 가질 수도 있다. 제 3 자 애플리케이션은, 이제 참조할 도 2 에 예시되는 바와 같이 웹사이트 구축 시스템으로부터 그리고 웹사이트 구축 시스템을 사용하여 생성된 웹사이트로부터 독립적으로 이러한 콘텐츠를 관리할 수도 있다. 다수의 제 3 자 애플리케이션 인스턴스(단일 또는 다수의 제 3 자 애플리케이션의)는 콘텐츠를 공유했을 수도 있고, 예를 들어 두 개의 개별 웹 사이트 페이지 내의 두 개의 e-상점 인스턴스는 동일한 제품 데이터베이스를 참조할 수도 있다.

포함된 제 3 자 애플리케이션으로부터의 출력은 보유 웹 페이지에 다음과 같은 여러 방식으로 통합될 수도 있다:

* 서버 측 프로세스: 이제 참조할 도 3 에 도시되는 바와 같은 이러한 대안예에서, 제 3 자 애플리케이션[a](디자인 및 디스플레이 엘리먼트를 포함) 및 사용자-특이적 제 3 자 애플리케이션 데이터[b]는 제 3 자 애플리케이션 벤더의 서버[d]에서 실행 중인 제 3 자 애플리케이션 서버 코드[c]에 의하여 병합된다. 이들은 통신 매체[e]를 거쳐 웹사이트 구축 시스템 서버 코드[f]로 전송되는데, 이것은 이들을 보유 웹 페이지 정보[g]와 병합하고 그리고 이들을 사용자 클라이언트국[h] 상의 디스플레이를 위하여 전송한다.

클라이언트 측 프로세스: 이제 참조할 도 4 에 도시되는 바와 같은 이러한 대안예에서, 제 3 자 애플리케이션[a](디자인 및 디스플레이 엘리먼트를 포함) 및 사용자-특이적 제 3 자 애플리케이션 데이터[b]는 제 3 자 애플리케이션 벤더의 서버[d]에서 실행 중인 제 3 자 애플리케이션 서버 코드[c]에 의하여 병합된다. 이들은 통신 매체[e]를 거쳐 클라이언트측 처리 컴포넌트[h]로 전송된다. 웹사이트 구축 시스템 서버 코드[f]는 보유 웹 페이지 정보[g]를 이러한 클라이언트측 처리 컴포넌트[h]로 전송한다. 클라이언트측 처리 컴포넌트[h]는 두 개의 소스의 정보의 병합을 수행하고 통일된 애플리케이션을 브라우저(또는 다른 클라이언트 에이전트)[i]로 제공한다.

아이프레임 포함: 이제 참조할 도 5 에 도시되는 바와 같은 이러한 대안예에서, 제 3 자 애플리케이션[a](디자인 및 디스플레이 엘리먼트를 포함) 및 사용자-특이적 제 3 자 애플리케이션 데이터[b]은 제 3 자 애플리케이션 벤더의 서버[d]에서 실행 중인 제 3 자 애플리케이션 서버 코드[c] 에 의하여 병합된다. 이들은 통신 매체[e]를 거쳐 사용자 에이전트(예를 들어 웹 브라우저)[i] 내에서 실행 중인 브라우저-기초 애플리케이션[h] 로 전송된다. 웹사이트 구축 시스템 서버 코드[f]는 보유 웹 페이지 정보[g]를 이러한 브라우저-기초 애플리케이션[h]로 전송한다. 보유 웹 페이지는 제 3 자 애플리케이션 서버[d]로부터의 콘텐츠를 포함하는 하나 이상의 아이프레임 지령을 보유하는 웹 페이지로서 구현된다. 추가적 및 대안적 방법도 역시 적용가능할 수도 있다.

본 발명의 바람직한 실시예에 따르면, 웹사이트 구축 시스템용 디바이스가 제공된다. 상기 디바이스는 적어도 하나의 제 3 자 애플리케이션의 웹사이트 인스턴스를 보유하는 페이지를 생성하기 위한 페이지 작성기 및 상기 페이지와 상기 적어도 하나의 제 3 자 애플리케이션 사이의 또는 상기 적어도 하나의 제 3 자 애플리케이션과 적어도 하나의 다른 제 3 자 애플리케이션 사이의 양방향 통신 백채널을 형성하기 위한 구성기를 포함한다. 상기 디바이스는 상기 페이지가 뷰되거나 액세스되는 경우 상기 통신 백채널에 따라서 통신을 조율하기 위한 조율기를 더 포함한다.

더욱이, 본 발명의 바람직한 실시예에 따르면, 상기 디바이스는 클라이언트 상에서 구현가능하다.

더 나아가, 본 발명의 바람직한 실시예에 따르면, 디바이스는 서버 상에서 구현가능하다.

더 나아가, 본 발명의 바람직한 실시예에 따르면, 상기 통신 백채널은 HTML5(Hypertext Markup Language 5) 포스트메시지(PostMessage), 메시지에 대한 URL 프래그먼트 식별자, 전용 통신 웹 서비스, HTML5 로컬 스토리지, HTML5 로컬 파일 시스템 액세스 API 및 전용 브라우저 플러그인 중 적어도 하나이다.

추가적으로, 본 발명의 바람직한 실시예에 따르면, 조율기는 아이프레임을 사용하여 페이지 내에 임베딩된다.

더욱이, 본 발명의 바람직한 실시예에 따르면, 적어도 하나의 제 3 자 애플리케이션이 아이프레임을 사용하여 페이지 내에 임베딩된다.

더 나아가, 본 발명의 바람직한 실시예에 따르면, 적어도 하나의 제 3 자 애플리케이션은 멀티-파트 제 3 자 애플리케이션 및 모듈식 제 3 자 애플리케이션 중 적어도 하나이다.

더 나아가, 본 발명의 바람직한 실시예에 따르면, 조율기는 선정의된 적어도 하나의 제 3 자 애플리케이션 인스턴스를 모니터링하기 위한 구성 관리자를 포함한다.

추가적으로, 본 발명의 바람직한 실시예에 따르면, 상기 조율기는 상기 통신의 소스 또는 타겟의 심볼식(symbolic) 어드레스 및 절대 어드레스를 식별 및 전환하기 위한 스마트 식별기 및 어드레서(addresser)를 포함한다.

더욱이, 본 발명의 바람직한 실시예에 따르면, 상기 조율기는 상기 웹사이트 구축 시스템과 상기 적어도 하나의 제 3 자 애플리케이션 사이에서 통신 정책을 실행하기 위한 통신 정책 실행기를 포함한다.

더 나아가, 본 발명의 바람직한 실시예에 따르면, 조율기 상기 조율기는 통신 메시지를 상기 웹사이트 구축 시스템 내에서 상기 적어도 하나의 제 3 자 애플리케이션으로 그리고 제 3 자 애플리케이션으로부터 리라우팅하기 위한 리디렉터를 포함한다.

더 나아가, 본 발명의 바람직한 실시예에 따르면, 조율기는 상기 조율기는 상기 적어도 하나의 제 3 자 애플리케이션으로부터의 인입하는 메시지의 진정성을 검증하기 위한 발신자 검증기를 포함한다.

추가적으로, 본 발명의 바람직한 실시예에 따르면, 상기 조율기는 상기 웹사이트 구축 시스템과 상기 적어도 하나의 제 3 자 애플리케이션 사이에서 그리고 상기 제 3 자 애플리케이션과 상기 적어도 하나의 다른 제 3 자 애플리케이션 사이에서 프로토콜 호환성 이슈를 해소하기 위한 프로토콜 전환기를 포함한다.

더욱이, 본 발명의 바람직한 실시예에 따르면, 상기 조율기는 상기 페이지 중 적어도 하나와 상기 적어도 하나의 제 3 자 애플리케이션 사이, 상기 적어도 하나의 제 3 자 애플리케이션과 상기 페이지 사이 및 상기 적어도 하나의 제 3 자 애플리케이션과 상기 적어도 하나의 다른 제 3 자 애플리케이션 사이의 동적 레이아웃 변경을 업데이트하기 위한 동적 레이아웃 업데이터를 포함한다.

더 나아가, 본 발명의 바람직한 실시예에 따르면, 상기 조율기는 상기 웹사이트 구축 시스템의 글로벌 속성, 상기 적어도 하나의 제 3 자 애플리케이션의 제어 허가 및 상기 페이지의 엘리먼트의 레이아웃, 스타일 및 콘텐츠 중 적어도 하나를 업데이트하기 위한 업데이터를 포함한다.

본 발명의 바람직한 실시예에 따르면, 웹사이트 구축 시스템용 디바이스가 제공되는데, 상기 디바이스는 적어도 하나의 상기 웹사이트 구축 시스템 템플릿을 외부 소스로부터 수신하기 위한 제 3 자 애플리케이션 수신기를 포함하고, 제 3 자 애플리케이션은 상기 적어도 하나의 상기 웹사이트 구축 시스템 템플릿과 연관된다. 상기 디바이스는 상기 적어도 하나의 제 3 자 애플리케이션의 인스턴스가 상기 페이지 내에서 생성되는 경우 상기 템플릿을 웹사이트 페이지 내에 인스톨하기 위한 인스톨러를 더 포함한다.

더욱이, 본 발명의 바람직한 실시예에 따르면, 상기 디바이스는 서버 및 클라이언트 중 적어도 하나 상에서 구현가능하다.

더 나아가, 본 발명의 바람직한 실시예에 따르면, 템플릿은 편집가능하다.

더 나아가, 본 발명의 바람직한 실시예에 따르면, 템플릿은 웹사이트 구축 시스템 컴포넌트 및 멀티파트 제 3 자 애플리케이션 중 적어도 하나를 보유한다.

추가적으로, 본 발명의 바람직한 실시예에 따르면, 웹사이트 페이지는 현존 페이지, 현존 미니-페이지, 신규 생성 페이지 및 신규 생성 미니-페이지 중 적어도 하나이다.

더욱이, 본 발명의 바람직한 실시예에 따르면, 수신기는 참조 무결성을 보존하고 적어도 하나의 제 3 자 애플리케이션과 페이지 사이에서 인터페이스 결정을 수행한다.

본 발명의 바람직한 실시예에 따르면, 웹사이트 구축 시스템용 방법이 제공된다. 상기 방법은 적어도 하나의 제 3 자 애플리케이션의 웹사이트 인스턴스를 보유하는 페이지를 생성하는 단계 및 상기 페이지와 상기 적어도 하나의 제 3 자 애플리케이션 사이에 또는 상기 적어도 하나의 제 3 자 애플리케이션과 적어도 하나의 다른 제 3 자 애플리케이션 사이에 양방향 통신 백채널을 형성하는 단계를 포함한다. 상기 방법은 상기 페이지가 뷰되거나 액세스되는 경우 상기 통신 백채널에 따라서 통신을 조율하는 조율 단계를 더 포함한다.

더욱이, 본 발명의 바람직한 실시예에 따르면, 적어도 하나의 제 3 자 애플리케이션은 멀티-파트 제 3 자 애플리케이션 및 모듈식 제 3 자 애플리케이션 중 적어도 하나이다.

더 나아가, 본 발명의 바람직한 실시예에 따르면, 상기 조율 단계는, 선정의된 상기 적어도 하나의 제 3 자 애플리케이션 인스턴스를 모니터링하는 단계를 포함한다.

더 나아가, 본 발명의 바람직한 실시예에 따르면, 상기 조율 단계는, 상기 통신의 소스 또는 타겟의 심볼식 어드레스 및 절대 어드레스를 식별하고 및 전환하는 단계를 포함한다.

추가적으로, 본 발명의 바람직한 실시예에 따르면, 상기 조율 단계는, 상기 웹사이트 구축 시스템과 상기 적어도 하나의 제 3 자 애플리케이션 사이에서 통신 정책을 실행하는 단계를 포함한다.

더욱이, 본 발명의 바람직한 실시예에 따르면, 상기 조율 단계는, 통신 메시지를 상기 웹사이트 구축 시스템 내에서 상기 적어도 하나의 제 3 자 애플리케이션으로 그리고 제 3 자 애플리케이션으로부터 리라우팅하는 단계를 포함한다.

더 나아가, 본 발명의 바람직한 실시예에 따르면, 상기 조율 단계는, 상기 적어도 하나의 제 3 자 애플리케이션으로부터의 인입하는 메시지의 진정성을 검증하는 단계를 포함한다.

더 나아가, 본 발명의 바람직한 실시예에 따르면, 상기 조율 단계는, 상기 웹사이트 구축 시스템과 상기 적어도 하나의 제 3 자 애플리케이션 사이에서 그리고 상기 제 3 자 애플리케이션과 상기 적어도 하나의 다른 제 3 자 애플리케이션 사이에서 프로토콜 호환성 이슈를 해소하는 단계를 포함한다.

추가적으로, 본 발명의 바람직한 실시예에 따르면, 상기 조율 단계는, 상기 페이지 중 적어도 하나와 상기 적어도 하나의 제 3 자 애플리케이션 사이, 상기 적어도 하나의 제 3 자 애플리케이션과 상기 페이지 사이 및 상기 적어도 하나의 제 3 자 애플리케이션과 상기 적어도 하나의 다른 제 3 자 애플리케이션 사이의 변경의 동적 레이아웃 업데이트 단계를 포함한다.

더욱이, 본 발명의 바람직한 실시예에 따르면, 상기 조율 단계는, 상기 웹사이트 구축 시스템의 글로벌 속성, 상기 적어도 하나의 제 3 자 애플리케이션의 제어 허가 및 상기 페이지의 엘리먼트의 레이아웃, 스타일 및 콘텐츠 중 적어도 하나를 업데이트하는 단계를 포함한다.

더 나아가, 본 발명의 바람직한 실시예에 따르면, 상기 업데이트하는 단계는 스타일 시트들을 케스케이딩하는 단계를 포함한다.

본 발명의 바람직한 실시예에 따르면, 웹사이트 구축 시스템용 방법이 제공된다. 상기 방법은 적어도 하나의 상기 웹사이트 구축 시스템 템플릿을 외부 소스로부터 수신하는 단계로서, 제 3 자 애플리케이션은 상기 적어도 하나의 상기 웹사이트 구축 시스템 템플릿과 연관되는, 수신 단계를 포함한다. 상기 방법은 상기 적어도 하나의 제 3 자 애플리케이션의 인스턴스가 상기 페이지 내에서 생성되는 경우 상기 템플릿을 웹사이트 페이지 내에 설치하는 단계를 포함한다.

더욱이, 본 발명의 바람직한 실시예에 따르면, 템플릿은 편집가능하다.

더 나아가, 본 발명의 바람직한 실시예에 따르면, 템플릿은 웹사이트 구축 시스템 컴포넌트 및 멀티파트 제 3 자 애플리케이션 중 적어도 하나를 보유한다.

더 나아가, 본 발명의 바람직한 실시예에 따르면, 웹사이트 페이지는 현존 페이지, 현존 미니-페이지, 신규 생성 페이지 및 신규 생성 미니-페이지 중 적어도 하나이다.

추가적으로, 본 발명의 바람직한 실시예에 따르면, 상기 수신 단계는 참조 무결성을 보존하고 적어도 하나의 제 3 자 애플리케이션과 페이지 사이에서 인터페이스 결정을 수행한다.

본 발명이라고 간주되는 기술 요지는 본 명세서의 결론부에서 특히 지적되고 명확하게 청구된다. 그러나, 그것의 목적, 특징, 및 장점과 함께 조직체(organization) 및 동작의 방법 모두로서의 본 발명은 첨부 도면과 함께 읽을 때에 후속하는 발명을 실시하기 위한 구체적인 내용을 참조함으로써 가장 잘 이해될 수도 있다:
도 1 은 웹사이트 구축 시스템과 제 3 자 애플리케이션 사이의 배치 구성의 개략적 예시이다;
도 2 는 제 3 자 애플리케이션 내부 콘텐츠 관리의 개략적 예시이다;
도 3 은 서버측 처리를 통하여 보유 웹 페이지 내로 제 3 자 애플리케이션이 포함된 것의 개략적 예시이다;
도 4 는 클라이언트측 처리를 통하여 보유 웹 페이지 내로 제 3 자 애플리케이션이 포함된 것의 개략적 예시이다;
도 5 는 아이프레임 포함을 통하여 보유 웹 페이지 내로 제 3 자 애플리케이션이 포함된 것의 개략적 예시이다;
도 6 은 페이지 레이아웃 변경 도중의 현존하는 비-최적 제 3 자 애플리케이션 디스플레이의 개략적인 예시이다;
도 7a 및 도 7b 는, 본 발명에 따라서 구성되고 동작하는, 웹사이트 구축 시스템 및 하나 이상의 제 3 자 애플리케이션을 통합시키기 위한 시스템의 개략적인 예시이다;
도 8 은 컴포넌트 모델과 비교되는 문서 오브젝트 모델의 개략적인 예시이다;
도 9 는 샘플 멀티-파트 블로그 제 3 자 애플리케이션의 개략적인 예시이다;
도 10 은 샘플 모듈식 판매 제 3 자 애플리케이션의 개략적인 예시이다;
도 11a 및 도 11b 는 본 발명에 따라서 구성되고 동작하는 통신 허브의 상이한 구현형태의 개략적인 예시이다;
도 11c 는 본 발명에 따라서 구성되고 동작하는, 도 11a 및 도 11b 의 통신 허브의 엘리먼트의 개략적인 예시이다;
도 12 는 본 발명에 따라서 구성되고 동작하는, 도 11a 및 도 11b 의 통신 허브에 의하여 수행되는 통신 전환 시나리오의 개략적인 예시이다;
도 13 은 본 발명에 따라서 구성되고 동작하는, 연관된 템플릿을 가지는 제 3 자 애플리케이션을 관리하는 보유 웹 페이지의 개략적인 예시이다; 그리고
도 14 는 본 발명에 따라서 구성되고 동작하는, 미니-페이지 내에 연관된 템플릿을 가지는 제 3 자 애플리케이션을 포함하는 보유 웹 페이지의 개략적인 예시이다.
간결성 및 설명의 명확화를 위하여, 도면에 도시된 엘리먼트들이 반드시 척도에 맞게 그려진 것은 아니라는 것이 인정될 것이다. 예를 들어, 엘리먼트들 중 일부의 치수는 명확화를 위하여 다른 엘리먼트에 상대적으로 과장될 수도 있다. 더 나아가, 적합하다고 여겨지는 경우, 참조 번호는 대응하거나 유사한 엘리먼트를 표시하기 위하여 도면에서 반복될 수도 있다.

다음의 상세한 설명에서, 다수의 특정 세부사항들이 본 발명의 완전한 이해를 제공하기 위하여 언급된다. 그러나, 본 발명이 이들 특정 세부사항들 없이 실시될 수도 있다는 것은 이 기술의 통상의 지식을 가진 자들에 의해 이해될 것이다. 다른 사례들에서 주지의 방법, 프로시저들 및 구성요소들은 본 발명의 양태들을 불필요하게 모호하도록 하지 않기 위해서 상세히 설명되고 있지 않다.

출원인은, 제 3 자 애플리케이션이 통상적으로 웹사이트 구축 시스템으로 통합되는 방식 그리고 통합된 제 3 자 애플리케이션 및 웹사이트 구축 시스템이 상호작용하는 방식에 있어서 현재의 방법의 다수의 제한사항이 존재한다는 것을 깨달았다.

이러한 제한사항은 제 3 자 애플리케이션 디스플레이가 아이프레임 내에 포함되는 영역인 보유 웹 페이지 내의 단일 사각형 영역으로 한정된다는 것을 포함한다. 이들은 제 3 자 애플리케이션이 자신의 윈도우의 사이즈 및 포지션, 및 또한 실제 제 3 자 애플리케이션 디스플레이 윈도우 외부의 시각적 엘리먼트(예를 들어 제 3 자 애플리케이션 윈도우 주위의 전문화된 디스플레이 프레임)를 제어할 능력을 더 포함한다.

제 3 자 애플리케이션은 자기 자신의 디스플레이 스타일(컬러 방식, 폰트, 문자 사이즈, 등)을 가질 수도 있다. 이러한 스타일은 몇몇 보유 웹 페이지에 대해서는 양호할 수도 있는데, 하지만 다른 보유 웹 페이지와는 시각적으로 문제가 있거나 조화를 이루지 않을 수도 있다.

다른 제한사항은 보유 사이트의 뷰 포인트로부터의 제 3 자 애플리케이션 디스플레이의 견고함이다. 사이트가 시각적으로 수정되어야 한다면(예를 들어 상이한 스크린 사이즈를 가진 플랫폼으로의 배치에 기인하거나 동적 레이아웃 이벤트에 기인하여), 보유 웹 페이지는 제 3 자 애플리케이션에 할당된 윈도우의 사이즈를 변경하도록 요구될 수도 있다. 이러한 경우에, 제 3 자 애플리케이션 디스플레이는 잘려질 것이고 제 3 자 애플리케이션 내의 상이한 서브-영역에 도달하기 위해서 스크롤 바를 통한 스크롤을 요구할 것이다. 이제 보유 웹 페이지[a]가 리사이징되고, e-상점 제 3 자 애플리케이션에 할당된 영역[b]이 감소되고, "구매" 버튼[c]이 쇼핑 카트[d]와 함께 관찰될 수 없는 경우에 - 구매를 완료하기 위해서는 다수의 스크롤 액션을 요구하고 이는 구매가 실질적으로 완료될 가능성을 매우 낮게 만든다 - 어떤 일이 발생할 수도 있는지의 일 예를 도시하는 도 6 을 참조한다.

제 3 자 애플리케이션이 보유 웹페이지 내의 다른 컴포넌트와 상호작용할 수 없다는 것 및 이러한 상호작용이 복잡한 기능성을 획득하기 위해서 가끔 요구된다는 것이 인정될 것이다. 특히, 제 3 자 애플리케이션이 보유 웹 페이지 내의 컴포넌트의 타입 및 콘텐츠에 따라서 상이하게 동작할 방법이 없다. 이것의 일 예는 온라인 요리 강좌를 스트리밍하는 웹사이트일 수도 있다. 사용자는 배경에서 그의 영화를 보려고 할 수도 있고, 그의 스크린의 작은 영역이 뉴스가 있는 피드 전용이고, 날씨 업데이트(예컨대, CNN으로부터의 생방송)가 그의 스크린의 다른 영역에 있을 수 있다. 그는 그의 거주 영역에 대한 날씨 보고가 시작될 때에 그의 학습 세션을 자동적으로 일시중지하고자 할 수도 있다.

또한, 다수의 제 3 자 애플리케이션이, 특히 이들이 상이한 벤더들에 의하여 제공되는 경우 서로 협동하기 위한 명확한 표준 방법이 존재하지 않는다. 따라서, 디자이너는 상이한 벤더로부터의 다수의 제 3 자 애플리케이션을 통합하기 위한 명확한 방법을 가지지 않는다. 이것의 일 예는 제 3 자 주문 시스템으로부터의 모듈 및 배송 시스템에 대한 상이한 모듈을 실행하고 있는 전자상거래 웹사이트에 대한 것일 수도 있다. 배송 스케줄 등에 따라 공급량을 주문하는 것이 바람직할 수도 있다.

출원인은, 이러한 통합이 웹사이트 구축 시스템과 그 안에 포함되는 제 3 자 애플리케이션 인스턴스 사이의 그리고 동일한 보유 페이지 내에서 구현될 수도 있는 상이한 제 3 자 애플리케이션 인스턴스들 사이의 구조화된 양-방향 통신 채널을 사용함으로써 획득될 수도 있다는 것을 발견했다. 이러한 채널은 또한 레이아웃, 스타일 및 추가적 정보에 관련된 정보를 전송할 수도 있다.

아래의 논의가, 최근의 브라우저 내에 탑재되고 이와 통합되며 특수 통합 코드의 생성을 요구하지 않기 때문에 바람직한 방법인 아이프레임 포함 방법(iframe inclusion method)에 초점을 맞추고 있다는 것이 인정될 것이다. 아이프레임은 또한, 브라우저-지지 캡슐화 및 샌드박싱(sandboxing) 그리고 악의적인 제 3 자 애플리케이션에 의하여 채용될 수도 있는 교차-사이트 스크립팅 공격과 같은 해킹 기법에 대한 내재적 보호 수단을 제공한다.

이제, 본 발명의 일 실시예에 따르는 웹사이트 구축 시스템 및 하나 이상의 제 3 자 애플리케이션을 통합하기 위한 시스템(100)을 도시하는 도 7a 및 도 7b 를 참조한다. 도 7a 는 디자인 스테이지에서의 시스템(100)을 도시하고 도 7b 는 런타임에서의 시스템(100)을 도시한다. 도 7a 에서 알 수 있는 바와 같이, 시스템(100)은 클라이언트(10), 웹사이트 구축 시스템(WBS) 서버(20)에 설치된 웹사이트 구축 시스템(30) 및 하나 이상의 제 3 자 애플리케이션 서버(50)에 설치된 하나 이상의 제 3 자 애플리케이션(40)을 포함한다. 웹사이트 구축 시스템(30)은 WBS 조율기(21), 애플리케이션 저장소(22), WBS측 TPA 속성 시트(23), 제 3 자 애플리케이션(TPA) 조율기(24) 및 앱스토어(25)(검색기(26)를 보유할 수 있음)를 포함한다. 클라이언트(10)는 페이지 작성기(12) 및 TPA 속성 시트(23)의 클라이언트측 뷰를 포함한다. 몇 가지 실시예들에서 클라이언트(10)는 앱스토어(25)의 클라이언트측 뷰를 더 포함할 수도 있다. 페이지 작성기(12)는 본 명세서에서 아래에 좀 더 상세하게 설명되는 링커(13)를 포함한다. 제 3 자 서버(50)는 제 3 자 애플리케이션(40), 외부 TPA 조율기(51) 및 사용할 제 3 자 애플리케이션(40) 컴포넌트, 템플릿 등을 저장하는 TPA 데이터베이스(52)를 포함한다. 시스템(100)이 다수의 제 3 자 애플리케이션(40) 벤더에 속하는 다수의 제 3 자 서버(50)를 포함할 수도 있다는 점에 주의한다.

TPA 속성 시트(23)가 속성들이 주어진 제 3 자 애플리케이션(40) 인스턴스에 대하여 특정되는 경우 호출될 수도 있다는 것이 인정될 것이다. 호출되는 경우, TPA 속성 시트(23)가 클라이언트(10)에 TPA 속성 시트(23)의 클라이언트측 뷰로서 나타날 수도 있다는 것이 역시 인정될 것이다. 또한 오프라인 실시예가 자신의 속성 시트를 설치된 클라이언트 소프트웨어의 일부로서 가질 수도 있고, 따라서 그것의 TPA 속성 시트(23) 또는 저장소가 없게 될 것이라는 것이 더욱 인정될 것이다.

클라이언트(10)에 위치하고 있는 디자이너 또는 말단-사용자(5)가 자신의 웹사이트(또는 임의의 다른 온라인 애플리케이션)를 페이지 작성기(12)를 사용하여 생성하여, 웹사이트 페이지 및 상호작용(페이지 사이와 페이지 내)을 생성할 수도 있다는 것이 인정될 것이다. 디자이너(5)는 WBS 조율기(21)를 통해서 애플리케이션 저장소(22) 내에 저장되는 웹사이트 구축 시스템(30)의 일부인 컴포넌트, 템플릿 등을 선택할 수도 있다. 디자이너(5)는 또한, 선구매될 수도 있고 그것의 템플릿, 컴포넌트 등이 애플리케이션 저장소(22)에 저장될 수도 있는, 제 3 자 애플리케이션(40)으로부터의 제 3 자 애플리케이션(40) 인스턴스를 임베딩하는 보유 웹 페이지(203)를 생성할 수도 있다. 대안적인 실시예에서, 구매된 템플릿, 컴포넌트 등은 TPA 데이터베이스(52)에 저장되고 외부 TPA 조율기(51)를 통해서 액세스될 수도 있다. 또 다른 실시예에서, 제 3 자 애플리케이션(40) 템플릿, 컴포넌트 등은 앱스토어(25)를 통해서 수요에 따라서 구매될 수도 있다. 본 명세서에서 아래에 좀 더 상세하게 설명되는 바와 같이, 속성 시트(23)는 디자이너(5)에 의하여 특정될 수도 있고 허가, 설치 명령, 지불 등과 같이 구매된 제 3 자 애플리케이션(40) 인스턴스에 관련된 정보를 유지할 수도 있다. 디자이너(5)는 또한 링커(23)를 사용하여 보유된 제 3 자 애플리케이션들(40) 사이에 임의의 통신 채널(요구된다면)을 수동으로 지정할 수도 있다. 또한 링커(23)가 디자이너(5)가 구축되는 중인 보유 웹페이지와 본 명세서에서 위에서 설명된 바와 같이 동시에 보여지는 영화 및 CNN 뉴스 보고와 같은 보유되는 중인 제 3 자 애플리케이션(40) 인스턴스 사이에 임의의 특정 통신 연결 및 규칙을 특정하게 할 수도 있다는 것이 역시 인정될 것이다. 링커(23)에 의하여 생성되는 링크(linkage)가 웹 사이트 수명 동안에 수정될 수도 있다는 것이 인정될 것이다.

디자이너(5)가 제 3 자 애플리케이션(40)을, 제 3 자 애플리케이션(40) 벤더 또는 외부 당사자에 의하여 운영되는 외부 앱스토어와 같은 앱스토어(25) 외부의 채널을 통해서 획득할 수도 있다는 것이 인정될 것이다. 이러한 경우에서, 웹사이트 구축 시스템(30)은 제 3 자 애플리케이션(40) 및 이것의 구성 데이터를, 웹사이트 구축 시스템(30)을 통해서 디자이너(5)에 의하여 생성되는 웹 사이트 내에 제 3 자 애플리케이션(40)이 처음 설치될 때에 등록할 수도 있다.

링커(23)가 잠재적 통신 채널을 셋업할 능력을 제공하기 위하여, 제 3 자 애플리케이션(40)은 보유 웹 페이지(203)(이것이 통신하고자 하는 것) 내의 컴포넌트 - 다른 제 3 자 애플리케이션(40) 인스턴스를 포함 - 를 적합하게 인식 및 식별할 수 있어야 한다는 것이 인정될 것이다. 연관된 템플릿(본 명세서에서 아래에 좀 더 상세하게 설명됨)에 기초하는 컴포넌트에 대하여, 제 3 자 애플리케이션(40) 벤더에 의하여 사전에 식별 동작이 수행된다. 연관된 템플릿 내의 컴포넌트에는 특정한 참조 ID들이 주어질 수도 있고, 이러한 ID들은 그들과 통신할 때에 제 3 자 애플리케이션(40)에 의하여 사용될 수도 있다.

멀티-파트 제 3 자 애플리케이션(40)(본 명세서에서 아래에 좀 더 상세하게 설명됨), 즉 다수의 아이프레임들에 걸쳐 분포되는 단일 제 3 자 애플리케이션(40)에 대하여, 다수의 부분들이 서로 어떻게 통신할지를 자동적으로 알 수도 있다는 것이 더욱 인정될 것이다.

연관된 템플릿 내에 포함되지 않은 보유 웹사이트 페이지 컴포넌트(본 명세서에서 아래에 좀 더 상세하게 설명되는 바와 같음)에 대하여, 제 3 자 애플리케이션(40)은 이것이 동작할 수도 있도록 존재해야만 하는 요구된(강제적인 및 선택적인) 보유 웹 페이지(203) 컴포넌트를 포함할 수도 있다. 목록은 속성 시트(23) 내에 저장될 수도 있고 고유한 ID, 설명 및 컴포넌트 세부사항(예를 들어 텍스트 컴포넌트여야 함, 블로그 톡백 라벨)을 포함할 수도 있다. 목록은 앱스토어(25) 내로의 제 3 자 애플리케이션(40) 엔트리 내에서 구체화될 수도 있고, 디자이너(5)는 링커(23)를 사용하여 제 3 자 애플리케이션(40) 요구 사항에 따르는 보유 웹 페이지(203) 내의 컴포넌트(필드)를 특정할 수도 있다. 웹사이트 구축 시스템(30)이, 제 3 자 애플리케이션(40) 인스턴스가 생성될 때에 누락된 보유 웹 페이지(203) 컴포넌트를 동적으로 생성할 수도 있다는 것 그리고 디자이너(5)가 이들을 이동, 리사이징 및 완전하게 특정할 수도 있다는 것이 인정될 것이다.

대안적으로는, 웹사이트 구축 시스템(30)은 보유 웹 페이지(203)의 풀 또는 부분적인 컴포넌트 모델을 보유 웹 페이지(203) 내에 포함된 제 3 자 애플리케이션(40)으로 노출시킬 수도 있다. 이것은 보유 웹 페이지(203)의 컴포넌트 모델이지 문서 오브젝트 모델(DOM)이 아닐 수도 있다는 것이 인정될 것이다. 보유 웹 페이지(203) DOM은 컴포넌트 모델보다 훨씬 더 복잡하고 상세할 수도 있는데, 이는 실제 보유 웹 페이지(203)가 웹사이트 구축 시스템(30) 기반구조의 일부이거나 보유 웹 페이지(203) 컴포넌트를 지원하는 다수의 HTML 엘리먼트 - 감춰진 것과 보이는 것 모두 - 를 보유할 수도 있기 때문이다. 따라서 컴포넌트 모델이 훨씬 더 간단할 것이다.

이제 텍스트 컴포넌트[a]가 어떻게 다수 개의 HTML 구조(인클로징 div 태그[b], 내부 div 태그[c], 프레임 "미니 위젯"[d1]..[d5] 등과 같음)를 사용하여 구현될 수도 있는지를 예시하는 도 8 을 참조한다. 보유 웹 페이지(203)에 대한 DOM 모델[e]은 이러한 서브-엘리먼트 각각에 대한 별개의 DOM 트리 노드를 보유할 수도 있다. 컴포넌트 모델[f]은 오직 단일 컴포넌트 노드[g]만을 포함하며 훨씬 더 간단할 수도 있다.

시스템(100)이 선택적 컴포넌트 노출을 역시 지원할 수도 있다는 것이 인정될 것이다 - 디자이너(5)는 링커(23)를 통해서 어떤 컴포넌트가 제 3 자 애플리케이션(40)으로 노출되어야 하는지를 지정할 수도 있고, 오직 이러한 컴포넌트(이들로 도달하는 보유 경로"를 포함할 수 있음)만이 제 3 자 애플리케이션(40)에 가시적인 단순화된 컴포넌트 모델 내에 포함될 수도 있다는 것이 인정될 것이다. 특정은 그들의 타입 또는 임의의 다른 웹사이트 구축 시스템(30) 속성에 따라서 포함된 컴포넌트를 명백하게 마크함으로써 수행될 수도 있다. 그러면 제 3 자 애플리케이션(40)은 보유 웹 페이지(203) 컴포넌트 모델을 횡단하고(traverse) 요구된 컴포넌트의 위치를 결정할 수도 있다.

보유 웹 페이지(203)와 제 3 자 애플리케이션(40) 인스턴스 사이의 링크도 역시 제 3 자 애플리케이션(40)이 런타임 도중에 통신을 전송하여 특정 이벤트를 기록하는 브로드캐스트 링킹(broadcast linking)과 같이 자동적으로 생성될 수도 있다는 것이 역시 인정될 것이다. 이러한 통신은 선택적이거나 강제적일 수도 있다(즉 제 3 자 애플리케이션(40)은 이러한 메시지를 수신하도록 링크된 바 있는 매칭하는 제 3 자 애플리케이션(40)이 존재하지 않을 경우 동작하지 않거나 설치되지 않을 수도 있다). 예를 들어, 제 3 자 애플리케이션(40)은 이것이 수행하는 동작들에 대한 정보 패킷을 브로드캐스트할 수도 있고, 임의의 설치된 로깅(logging) 제 3 자 애플리케이션(40)이 이러한 정보 패킷을 수신할 수도 있다.

이제 셋팅이 완료된 신규 생성 페이지가 본 명세서에서 아래에 좀 더 상세하게 설명되는 바와 같이 런-타임에서 호출되도록 애플리케이션 저장소(22) 내에 저장될 수도 있다(WBS 조율기(21)를 통하여).

이제 다시 도 7b 를 참조한다. 이러한 실시예에서 엘리먼트는 클라이언트(10)의 엘리먼트를 제외하고는 도 7a 에 있는 것들과 동일하다. 런타임 도중에, 클라이언트(10)는 보유 웹 페이지(203)를 디스플레이하기 위한 뷰어(201)를 포함한다. 뷰어(201)가, 각각 제 3 자 애플리케이션(40)의 상이한 인스턴스(하나 이상의 제 3 자 애플리케이션(40)으로부터 유도된 인스턴스)를 디스플레이하기 위한 다수의 뷰 포트(202)를 포함할 수도 있다는 것이 인정될 것이다. 클라이언트(10)는 또한, 통신을 촉진하고 보유 웹 페이지(203)와 이것이 호스팅하는 임의의 제 3 자 애플리케이션(40) 사이의 백 채널을 적절한 보유 웹 페이지(203)로의 임의의 연결이 없는 호스팅된 제 3 자 애플리케이션들(40) 사이에서 요구되는 임의의 통신과 함께 제공하기 위한 통신 허브(205)를 포함할 수도 있다. 허브(205)의 기능성은 본 명세서에서 아래에 좀 더 상세하게 설명될 것이다.

보유 웹 페이지(203) 및 임의의 제 3 자 애플리케이션(40) 포함(inclusions)이 모두 가시 웹 사이트의 대화형 부분들이고 그들의 통신이 클라이언트-서버 라운드-트립에 의하여 지연되어서는 안 되기 때문에, 허브(205)가 클라이언트(10)에 구현될 수도 있다는 것이 인정될 것이다. 대안적인 실시예에서, 제 3 자 애플리케이션 서버(40)가 많은 양의 데이터를 교환할 필요가 있고, 이들을 클라이언트(10)를 통해서 라우팅하지 않는 것이 바람직한 경우에는 허브(205)가 웹사이트 구축 시스템 서버(20)에 구현될 수도 있다.

통신 허브(205)는 웹사이트 구축 시스템(30)과 하나 이상의 제 3 자 애플리케이션(40) 사이의 그리고 다수의 제 3 자 애플리케이션들(40) 사이의 상이한 조합의 통신을 지원할 수도 있다는 것이 인정될 것이다. 예를 들어, 허브(205)는 웹사이트 구축 시스템(30)이 메인 사이트 내의 다른 페이지로 스위칭하도록 제 3 자 애플리케이션(40)이 요청하게 할 수도 있다. 통신 허브(205)는 또한 제 3 자 애플리케이션(40)이 자기 자신의 윈도우를 리사이징하여 가능하게는 보유 페이지의 레이아웃에 영향을 주도록 요청하게 할 수도 있다. 이것은 본 명세서에서 아래에 좀 더 상세하게 설명되는 동적 레이아웃 핸들링을 통해서 행해질 수도 있다. 대안적으로는, 보유 웹 페이지(203)는(예를 들어) 디스플레이에서의 변경을 수용하기 위하여 요구되는 경우 제 3 자 애플리케이션(40) 스위치가 상이한 버전으로 스위칭하도록 요청할 수도 있다. 이러한 양방향 통신이 제 3 자 애플리케이션(40) 컴포넌트와, 제 3 자 애플리케이션(40)에 관련되고 추가적 정보 및 본 명세서에서 위에서 설명된 바와 같이 멀티-파트 제 3 자 애플리케이션(40)과 모듈식 제 3 자 애플리케이션 사이의 통신을 디스플레이하는, 제 3 자 애플리케이션(40)에 관련된 웹사이트 구축 시스템(30) 컴포넌트 사이에서 개시될 수도 있다는 것이 인정될 것이다.

시스템(100)이 또한 온-라인 및 오프라인 웹사이트 구축 시스템(30) 모두를 사용하여 구현될 수도 있다는 것, 그리고 이것이 임의의 조합의 호스팅 방법, 예컨대 클라이언트측 엘리먼트, 웹사이트 구축 시스템(30) 벤더 서버, 제 3 자 애플리케이션(40) 벤더 서버 및 다른 제 4 당사자 서버를 사용할 수도 있다는 것이 역시 인정될 것이다. 본 명세서에서 위에서 설명된 바와 같은 오프라인 실시예에서 서버는 여전히 시스템(100)을 구현하도록 요구될 수도 있다는 것이 인정될 것이다.

시스템(100)은 또한 큰 기관을 위한 사설 사이트 호스팅 장치와 같은 상이한 서버 세트(웹사이트 구축 시스템 벤더에 의하여 운용되지 않는)에 호스팅될 수도 있다.

시스템(100)은 또한 본 명세서에서 위에 논의된 바와 같이 제 3 자 애플리케이션(40)으로부터의 제 3 자 애플리케이션(40) 인스턴스 포함 옵션의 전체를 지원할 수도 있다. 그러나, 시스템(100)은 또한 이러한 옵션의 서브세트만을 지원할 수도 있고 또는 제 3 자 애플리케이션(40) 인스턴스 포함 가능성에 한정을 할 수도 있다.

시스템(100)은 멀티-파트 제 3 자 애플리케이션(40)도 역시 구현할 수도 있다. 멀티-파트 제 3 자 애플리케이션(40)은 다수의 디스플레이된 영역을 포함할 수도 있는데, 이들 각각은 별개의 아이프레임을 사용하여 다뤄진다. 또한 이러한 영역들은 본 명세서에서 아래에 좀 더 상세하게 설명되는 바와 같이(필요한 바에 따라) 통신 허브(205)를 통해서 상호동작할 수도 있다.

이제 멀티-파트 제 3 자 애플리케이션(40)의 일 예를 도시하는 도 9 를 참조한다. 도시된 바와 같이, 앱스토어[b]로부터 획득된 블로그 제 3 자 애플리케이션[a]은 보유 웹 페이지(203)[c] 내에 배치된다. 블로그 제 3 자 애플리케이션[a]은 다음: 블로그 엔트리 영역[d]; 태그 클라우드 영역[e]; 뉴스 업데이트 영역[f]과 같은 3 개의 영역을 포함한다. 멀티-파트 제 3 자 애플리케이션이 자신의 다수의 영역을, 위의 블로그 예에서와 같이 단일 애플리케이션의 다수의 동시에-상주하는 부분으로서, 또는 언제나 보이는 여러 영역 및 선택적이고 요구될 때에만 디스플레이되는 여러 영역이 있는 단일 애플리케이션의 다수의 선택적으로-상주하는 부분으로서 포함하는 여러 방식으로 사용할 수도 있다는 것이 인정될 것이다. 선택적인 영역의 디스플레이는 제 3 자 애플리케이션(40)에 의하여, 또는 디자이너(5)(이것을 포함할 경우 제 3 자 애플리케이션을 어떻게 구성할지를 결정하는 사람)에 의하여 제어될 수도 있다. 디스플레이는 또한 기능성 지원 영역, 예컨대 구성 또는 엑스트라 대화 영역으로서; 멀티-버전 제 3 자 애플리케이션에 대한 대체 디스플레이로서(예를 들어 제 3 자 애플리케이션의 작거나 큰 버전을 가지거나, 또는 제 3 자 애플리케이션의 세로 및 가로 버전을 가짐) 제어될 수도 있다.

위에서 언급된 기능성이 제 3 자 애플리케이션(40) 엘리먼트 디스플레이에 대하여 아이프레임을 사용하여 구현되어, 아이프레임-기초 아키텍처의 캡슐화 및 보안 장점을 획득할 수도 있다는 것이 인정될 것이다.

멀티-파트 제 3 자 애플리케이션(40)의 구현형태가, 제 3 자 애플리케이션(40)(그들의 아이프레임 내)이 다양한 아이프레임의 디스플레이(예를 들어 그들의 가시성, 사이즈 및 포지션)를 제어할 수도 있게 요구한다는 것이 더욱 인정될 것이다. 통신 허브(205)가 이러한 디스플레이를 본 명세서에서 아래에 좀 더 상세하게 설명되는 바와 같이 가능하게 할 수도 있다는 것이 역시 인정될 것이다.

멀티-파트 제 3 자 애플리케이션(40)이 다수의 엘리먼트 및 영으로 이루어지는 경우(시각적으로)에도, 이것은 구매(예를 들어 앱스토어(25)), 설치, 구성 및 기타 등등의 관점에서는 단일 제 3 자 애플리케이션(40)으로서 간주된다는 것이 역시 인정될 것이다.

현존 시스템에서, 각각의 제 3 자 애플리케이션(40)은 개별 엔티티라고 간주될 수도 있고 두 개의 제 3 자 애플리케이션들(40)(동일한 벤더 또는 그렇지 않으면 협력 벤더로부터의) 사이의 임의의 협력은 케이스 별로 발전된 애드-혹이어야 한다. 시스템(100)이 개별적으로 구매되고 설치될 수 있는 다수의 협력하는 서브-모듈로 이루어지는 모듈식 제 3 자 애플리케이션(40)을 역시 지원할 수도 있다는 것이 인정될 것이다.

이제 모듈식 판매 관리 제 3 자 애플리케이션[a]이 다음 서브-모듈: CRM 모듈[b]; 리드 관리 모듈[c] 및 e-상거래 모듈[d]을 포함할 수도 있는지를 예시하는 도 10 을 참조하는데; 단일 제 3 자 애플리케이션 벤더는 모든 요구된 제 3 자 애플리케이션 모듈을 제공할 수도 있다. 대안적으로는, 제 3 자 애플리케이션 벤더는 제 3 자 애플리케이션(40) 모듈(및 기능성)의 서브세트를 제공하고 디자이너가 동일한 또는 추가적 제 3 자 애플리케이션 벤더로부터 상보적 제 3 자 애플리케이션 모듈을 구매 / 설치하도록 할 수도 있다. 멀티-파트 제 3 자 애플리케이션이 단일 벤더로부터의 단일 제 3 자 애플리케이션으로서 획득되고 설치되어 다수의 스크린 영역을 차지하게 되는 반면에, 모듈식 제 3 자 애플리케이션이 개별적으로 획득되고 설치될 수도 있는 다수의 모듈을 포함할 수 있고, 가능하게는 다수의 제 3 자 애플리케이션 벤더로부터의 모듈들을 포함할 수도 있다는 것이 인정될 것이다. 다수의 벤더로부터의 다수의 제 3 자 애플리케이션 모듈을 통합시키는 기능을 제공하기 위하여, 각각의 제 3 자 애플리케이션 모듈은 이것이 요구하는 인터페이스 / 기능의 그리고 이것이 제공하는 인터페이스 / 기능의 목록을 제공해야 한다. 이것은, 예를 들어 계층적 점구분(dot-separated) 명명법(예를 들어 My_CRM_TPA.NewClient.GetInfo) 및 인터페이스 파라미터 사양에 기초하여 인터페이스 명칭의 목록을 사용하여 수행될 수 있다.

제 3 자 애플리케이션(40) 모듈은 요구된 인터페이스를 강제적인 것으로(즉 모듈은 이들이 없으면 동작하지 않음) 또는 선택적인 것으로(즉 모듈이 동작을 하지만 감소되거나 수정된 기능성을 제공할 수도 있음) 지정할 수도 있다. 따라서, 각각의 인터페이스에 대하여 제공되는 파라미터는: 인터페이스 고유 명칭; 인터페이스 설명 - 그 또는 그녀가(예를 들어) 누락된 인터페이스에 의하여 다뤄지는 기능성에 대하여 알도록 디자이너(5)에게 보여짐; 강제적 / 선택적 상태; 인터페이스 파라미터 목록 및 타입이다. 각각의 제 3 자 애플리케이션 모듈이 여전히 별개의 아이프레임(또는 아이프레임의 세트) 내에 상주한다는 것이 인정될 것이다. 인터페이스의 동작은 본 명세서에서 아래에 좀 더 상세하게 설명되는 통신 채널에 기초한다.

제 3 자 애플리케이션(40) 모듈이 웹사이트 디자인 스테이지 도중에 조합될 수도 있다는 것이 인정될 것이다. 웹사이트 구축 시스템(30)은 추가적 제 3 자 애플리케이션(40) 모듈이 추가될 때에 인터페이스 참조(interface references)를 결정(resolve)할 수도 있다 - 새로운 제 3 자 애플리케이션(40) 모듈이 현존하는 요구된 인터페이스를 결정하지만 새로운(미결정된) 요구된 인터페이스를 추가하는 것도 가능하다.

디자이너(5)가 강제적인(및 선택적인) 인터페이스가 여전히 미결정인 동안에 완전한 웹 사이트를 편집하고 실행할 수도 있다는 것이 역시 인정될 것이다. 그러나, 디자이너(5)는 모든 강제적인 인터페이스가 결정될 때까지 생성된 웹 사이트를 공개하지 않을 수도 있고, 허브(205)가 여전히 미결정된 강제적인 인터페이스를 가지는 제 3 자 애플리케이션 모듈을 활성화하도록 요구할 수도 있는 기능을 시도하고 있다면 그렇게 하도록 촉진될 것이다.

요구된 제 3 자 애플리케이션 모듈 인터페이스를 결정하는 제 3 자 애플리케이션 모듈의 위치를 결정하려고 시도할 수도 있는 검색기(26)를 앱스토어(25)가 포함할 수도 있다는 것이 역시 인정될 것이다. 검색기(26)는 미결정 인터페이스에 기초하여 특정 제 3 자 애플리케이션 모듈(들)에 대해 또는 모든 제 3 자 애플리케이션 모듈에 대해 검색할 수도 있다. 검색기(26)는 또한 현재 미결정 인터페이스에서 또는 심지어 이미 결정된 인터페이스에서 검색할 수도 있고 강제적인, 선택적인 또는 양자 모두의 타입의 인터페이스에서 검색할 수도 있다. 검색기(26)가 또한 특정 제 3 자 애플리케이션 미결정 인터페이스를 결정하는 것 그리고 특정 제 3 자 애플리케이션 벤더에 대하여 검색하는 것으로 한정될 수도 있다는 것이 인정될 것이다. 검색기(26)는 제 1 레벨 검색(즉 현재 미결정 인터페이스를 만족하는 모듈) 또는 멀티-레벨 검색을 수행할 수도 있다(즉, 이전의 검색 라운드에 의하여 발견된 제 3 자 애플리케이션 모듈을 고려할 경우 추가되는 미결정 인터페이스를 만족하는 모듈을 검색하면서 반복된 검색을 수행함).

시스템(100)은 인터페이스 설명을 사용하여 몇몇 누락 인터페이스를 가지고 진행하는 것의 중요도에 대한 정보를 디자이너(5)에게 제공할 수도 있다. 허브(205)는 여전히 통신할 필요가 있는 비-호환가능 제 3 자 애플리케이션들 사이의 인터페이스 전환을 제공할 수도 있다. 이것은 웹사이트 구축 시스템(30) 제공자에 의하여 또는 주어진 요구된 인터페이스를 상이한 포맷으로 적응시키는 외부 당사자에 의하여 수행될 수 있다.

시스템(100)은 또한 온-라인 애플리케이션 편집 시스템으로 적용될 수도 있는데, 이것은 인터넷(또는 임의의 다른 네트워크 연결))을 사용하고 생성된 온-라인 애플리케이션을 관찰하기 위하여 비-브라우저 클라이언트측 소프트웨어를 사용한다. 이러한 시스템은 정규 웹 기반구조에 의하여 사용 중인 특정 기술(예를 들어 IP 통신, HTTP, HTML 등)을 사용할 필요가 없다.

당업계에 공지된 표준 교차 도메인 통신 방법 이 교차-도메인 통신을 용이화하기 위하여 사용될 수도 있다는 것이 인정될 것이다. 이러한 방법은 다음을 포함할 수도 있다:

HTML5 PostMessage. 이것은 안전한 교차-도메인 메시징을 제공하기 위하여 사용될 수 있는 표준 HTML5 피쳐이다. HTML5 Windows.Postmessage를 사용하면, 상이한 도메인에 상주하고 있는 경우에도 메시지는 윈도우, 아이프레임 및 메인 HTML 문서 사이에서 안전하게 전송될 수 있다. PostMessage는 아이프레임을 전송하여 메시지가 전송될 목적지인 특정 도메인을 특정하기 위한, 그리고 아이프레임을 수신하여 메시지가 전송되는 소스인 도메인을 검증하기 위한 툴을 제공한다.

메시지에 대한 URL 프래그먼트 식별자: 이러한 방법은 메시지 데이터를 하나의 종단점으로부터 다른 종단점으로 전송하기 위하여 URL 프래그먼트 식별자를 사용하는 것에 의존한다. 데이터는 플레인 텍스트로 인코딩되고 타겟 종단점 도메인 상의 서비스 또는 타겟 종단점 아이프레임 내부의 숨은 아이프레임을 호출하기 위하여 사용되는 URL로 추가된다. 그러면 프래그먼트 식별자는 타겟 서비스 또는 아이프레임 내의 코드에 의하여 디코딩된다.

전용 통신 웹 서비스 웹사이트 구축 시스템(30)은 웹사이트 구축 시스템 서버(20) 상에 호스팅되는 전문화된 웹을 제공한다. 다양한 통신 종단점들이 메시지를 전송하거나 대기 메시지를 점검하기 위하여 이러한 서버에 연결된다. 이것은 기술의 선-HTML5 코넷(Comet) 세트, HTML5-기초 웹소켓(WebSockets), 또는 임의의 다른 큐잉(queuing), 폴링(polling), 서버 푸시 또는 유사한 기법과 같은 당업계에 공지된 방법을 통해서 수행될 수 있다.

HTML5 로컬 스토리지: HTML5는 구성된 로컬 스토리지 설비를 제공하는데, 이는 큐잉된 메시지를 저장하기 위하여 사용될 수 있다. 그러나, 로컬 스토리지는 저장 아이프레임과 동일한 도메인에 속하는 웹 콘텐츠에 의해서만 액세스될 수 있다. 미보(Meebo) 엑스오쓰(XAuth) 제품에 의하여 사용되는 - 이제 구글 아이앤씨에 의하여 소유되는 - 하재 기법(underlying technique)과 같은 솔루션들이 당업계에서 발전되어 왔는데, 여기에서 작은 서버가 요구된 중간 아이프레임을 생성하는 것에 대한 지원을 제공하고, 이것이 도메인-특정 로컬 스토리지가 외부 도메인 내에 기초된 아이프레임으로부터 액세스되게 한다.

HTML5 로컬 파일 시스템 액세스 애플리케이션 프로그래밍 인터페이스(APIs). 위에서 설명된 로컬 스토리지의 사용과 유사하게, 교차-아이프레임 통신 채널이 HTML5 파일 액세스 API들(파일 API, 파일라이터(FileWriter) API 및 파일리더(FileReader) API)을 통해서 액세스되는 사용자 에이전트의 로컬 스토리지 상의 로컬 파일을 사용하여 구성될 수도 있다. 그러나 HTML5 파일 시스템 액세스 API들에 의하여 생성된 샌드박스된(sandboxed) 로컬 파일 시스템이 여전히 개별적인 발신지를 가지고(origin-private), 따라서 동일한-발신지 제한사항을 브리징(bridge)하기 위해서는 중간 아이프레임 / 서버 컴포넌트가 요구할 것이라는 점에 주의한다.

전용 브라우저 플러그인: 전문화된 브라우저(또는 다른 사용자 에이전트) 플러그-인이 교차-아이프레임 메시지 큐를 관리하기 위하여 생성될 수 있다. 이러한 플러그-인은 웹사이트 구축 시스템(30)(모든 레벨에서)의 사용자에 의하여 설치되어야 할 것이고, 필요한 서비스를 모든 아이프레임 및 메인 웹사이트 구축 시스템(30) 페이지로 제공할 것이다.

통신 허브(205)가 본 명세서에서 위에 논의되는 전송 방법들 중 임의의 것을 사용하여 모든 아이프레임간 통신에 대한 브로커로서의 역할을 할 수 있다는 것이 인정될 것이다. 허브(205)가 제 3 자 애플리케이션(40) 벤더에 의하여 제공되고 속성 시트(23) 내에 저장되는 바와 같은 보유 웹 페이지(203) 구조 및 제 3 자 애플리케이션(40) 세부사항에 대하여 완전히 알고 있을 수도 있다는 것이 역시 인정될 것이다. 제 3 자 애플리케이션(40)은 또한 상이한 애플리케이션 내에 포함될 경우 그리고 동일한 애플리케이션 내의 포함의 상이한 인스턴스에 대하여 상이한 파라미터를 가질 수도 있다(본 명세서에서 위에서 설명된 바와 같이). 이러한 파라미터는 스마트 어드레싱(본 명세서에서 아래에 좀 더 상세하게 설명됨)을 위하여 사용될 수도 있는 고유한 인스턴스 명칭을 포함할 수도 있다. 허브(205)가 속성 시트(23) 내에 저장되지 않을 수도 있는 추가적 제 3 자 애플리케이션(40) 세부사항에 대하여 역시 알고 있을 수도 있다는 것이 역시 인정될 것이다.

또한 허브(205)가 스마트 어드레싱 및 식별을 가능하게 하고, 통신 발신지를 검증하며, 통신 정책을 실행하고, 제 3 자 애플리케이션(40) 비 호환성 이슈를 해소하며, 또한 제 3 자 애플리케이션(40)으로부터 컴포넌트들로의 리디렉팅을 할 수도 있다는 것이 역시 인정될 것이다. 또한 허브(205)는 본 명세서에서 아래에 좀 더 상세하게 설명되는 바와 같이 보유 웹 페이지(203)에 생긴 변경에 기초하여 제 3 자 애플리케이션(40) 내의 레이아웃의 동적 업데이트를 가능하게 할 수도 있다.

이제 허브(205)의 상이한 구현 실시예를 도시하는 도 11a 및 도 11b 및 이것의 상이한 엘리먼트의 기능을 예시하는 도 11c 를 참조한다.

허브(205)는 스마트 식별기 및 어드레서(310), 발신자 검증기(320), 통신 정책 실행기(330), 프로토콜 전환기(340), 리디렉터(350), 동적 레이아웃 업데이터(360), 구성 관리자(370), 일반적 업데이터(380) 및 호스팅된 애플리케이션 프로그래밍 인터페이스 API 래퍼(390)를 포함할 수도 있다. 이러한 엘리먼트의 기능이 본 명세서에서 아래에 자세하게 설명된다. 모든 기능이 모든 교차-도메인 통신 채널, 예컨대 웹사이트 구축 시스템(30) 채널로의 제 3 자 애플리케이션(40) 및 다른 제 3 자 애플리케이션(40)으로의 제 3 자 애플리케이션(40)에 적용가능하다는 것이 인정될 것이다.

참조되는 도 11a 는 이제 웹사이트 구축 시스템(30)에 접속하기 위하여 내부 통신 애플리케이션 프로그래밍 인터페이스(API)를 사용하는 중간 아이프레임[a]을 통한 허브(205)에 대한 통상적 실시예를 도시한다. 이러한 방법으로(예를 들어) TPA[d]로부터 TPA[e]로(각각 통신 API 모듈[f] 및 [g]를 사용함) 전송되는 메시지[c]가 분석되거나, 검증되거나, 또는 애플리케이션-특이적 지식을 적용하는 방식으로 수정된다.

지금 참조가 이루어지는 도 11b 에 도시된 바와 같은 대안적 실시예는 중간 아이프레임을 사용하지 않고, 오히려 통신 API 모듈[a] 및 [b](제 3 자 애플리케이션[c] 및 [d]에 각각 임베딩됨) 중 하나 또는 모두에서 교차-도메인 통신을 사용한다. 모듈[a] 및 [b] 는 직접적으로 웹사이트 구축 시스템(30)과 상호작용하여 애플리케이션-특이적 지식을 수신하고, 이것을 통신 메시지[f]를 처리할 때 사용한다. 이러한 실시예는 많은 양의 웹사이트 구축 시스템(30) 레벨 정보가 제 3 자 애플리케이션 내에 포함된 모듈 내에서 처리될 수도 있고, 이러한 정보가 악의적인 제 3 자 애플리케이션에 의하여 액세스(또는 심지어 수정)될 수도 있다는 점에서 단점(도 11a 에 도시되는 실시예와 비교할 때)을 가진다.

본 명세서에서 위에 논의된 바와 같이, 본 명세서에서 위에 설명되는 모든 교차-통신 방법에서, 아이프레임 어드레싱은, 메시지를(특정 수신자에게) 전송할 때에 그리고 메시지를 수신할 때에(수신자에게 제공된 전송자의 명칭과 같이) 아이프레임의 발신지(소스 도메인, 프로토콜 및 포트를 포함)에 기초하고 직접적 제 3 자 애플리케이션(40) 어드레싱을 사용한다. 추가적으로, 메시지 전송을 하려면 전송자가 타겟 아이프레임 윈도우를 특정하여야 한다(자바스크립트의 document.getElementById("...").contentWindow 호 또는 임의의 다른 방법을 사용함). 따라서, 현존 시스템에서, 각각의 제 3 자 애플리케이션(40)은 이것이 통신하는데 사용할 수도 있는 임의의 다른 제 3 자 애플리케이션(40)의 전체 그리고 특정 세부사항(도메인, 프로토콜, 포트 및 아이프레임 ID를 사용)을 보유해야 한다.

이러한 타입의 직접적 어드레싱이 시스템(100)의 환경에서 불편할 수도 있다는 것이 인정될 것이다. 디자이너(5)가 다수의 비-조율된 제 3 자 애플리케이션(40) 벤더로부터의 제 3 자 애플리케이션(40)을 통합할 수도 있는 경우에도, 제 3 자 애플리케이션(40) 벤더는 주어진 도메인에서 호스팅되지만 추후에 상이한 도메인 또는 서브-도메인으로 이동되는 제 3 자 애플리케이션(40)을 공급할 수도 있다. 제 3 자 애플리케이션(40) 벤더는 임의의 주어진 제 3 자 애플리케이션에 접속하기 위하여 사용되는 프로토콜 또는 포트를 변경할 수도 있다. 디자이너(5)는 제 3 자 애플리케이션(40)을 보유하는 보유 웹 페이지(203)의 디자인을 수정하도록 요구될 수도 있다. 이러한 것들 모두는 동작하고 있으며 다수의 사용자로부터 액세스되는 중인 웹 사이트 내에서 사용되는 제 3 자 애플리케이션(40)에서 발생할 수도 있다. 추가적으로, 단일 보유 웹 페이지(203)는 상이한 기능을 수행할 수도 있는 하나의 제 3 자 애플리케이션(40)의 다수의 인스턴스를 포함할 수도 있다. 예를 들어, 제품 지원 웹 사이트 내의 단일 페이지는 두 개의 채팅 제 3 자 애플리케이션(40) 인스턴스를 보유할 수도 있다 - 하나는 사용자-사용자 채팅 및 포럼을 위한 것이고, 하나는 이용가능한 경우 벤더의 지원 인력과 대화하기 위한 것이다.

어드레서 및 식별자(310)가 보유 웹 페이지(203)의 구조 및 제 3 자 애플리케이션(40)(웹사이트 구축 시스템(30)으로 제 3 자 애플리케이션(40) 벤더에 의하여 제공된 바와 같음)의 세부사항에 대하여 완전히 알고 있을 수도 있다는 것이 인정될 것이다. 어드레서 및 식별기(310)는, 다음 중 임의의 것을 사용하여 소스 또는 타겟 제 3 자 애플리케이션(40)의 서로에 대한 어드레싱을 제공할 수도 있다: 제 3 자 애플리케이션(40) 고유 명칭(앱스토어(25)에 등록된 바와 같음); 보유 웹 페이지(203) 내의 각각의 제 3 자 애플리케이션(40) 인스턴스에 추가되어 동일한 제 3 자 애플리케이션(40)의 다수의 인스턴스를 가능하게 하는 제 3 자 애플리케이션(40) 인스턴스 기술(descriptive) ID; 요구된 제 3 자 애플리케이션 타입 / 클래스에 대한 일반적인 식별자(예를 들어 "메시지 <x>를 보유 웹 페이지(203) 내의 임의의 이벤트 로깅 제 3 자 애플리케이션(40) 인스턴스로 전송하기를 원함"). 이러한 식별자는 또한 제 3 자 애플리케이션(40)에 의하여 지원되어야 하는 특정한 서비스를 기술할 수도 있다. 어드레서 및 식별자(310)는 또한 버전 표시, 예를 들어: "트랜잭션 <x> 를 이것이 버전 <z>의 것인 경우에만 회계 패키지 <y> 로 전송하기를 원함"을 사용할 수도 있다.

런타임 도중에, 제 3 자 애플리케이션(40)은 오직 허브(205)와만 통신하고, 그러므로 허브(205)의 직접적 어드레스만 필요하지 임의의 다른 제 3 자 애플리케이션(40)의 어드레스는 요구하지 않는다는 것이 인정될 것이다. 이러한 하나의 직접적 어드레스는 웹사이트 구축 시스템(30)에 의하여 제 3 자 애플리케이션(40) 제공자로 제공되는 통신 API 래퍼(예컨대 도 11a 에 도시되는 바와 같은 통신 모듈 f 및 g 및 도 11b 에 도시된 바와 같은 통신 모듈 및 b)에 의하여 캡슐화될 수도 있다. 제 3 자 애플리케이션(40)을 호출하면 애플리케이션-인식 제 3 자 애플리케이션(40) 기술(descriptive) 어드레스를 제공할 수도 있고(위에서 설명된 바와 같이) 및 어드레서 및 식별자(310)는 이것을 직접적 제 3 자 애플리케이션(40) 어드레스로 전환하고 라우팅을 수행할 수도 있다. 이러한 방법으로, 제 3 자 애플리케이션(40)은 통신하는 모든 가능한 제 3 자 애플리케이션(40)의 절대 어드레스의 테이블을 유지하고 있을 필요가 없다.

메시지 발신자 검증이 중요하며, 그렇지 않으면 수신하는 제 3 자 애플리케이션(40)이 적대적 제 3 자 애플리케이션(40)으로부터 메시지를 수신할 수도 있다는 것이 인정될 것이다. 모든 통신이 허브(205)를 통해서 발생할 수도 있기 때문에, 발신자 검증기(320)는 제 3 자 애플리케이션으로부터의 모든 인입하는 메시지의 진정성을 검사할 수도 있다. 발신자 검증기(320)는 또한 메시지로 추가될 수도 있고 추가적 검증을 위하여 사용될 수도 있는 추가적 정보를 제공할 수도 있다. 앱스토어(25) 내에 포함되고 시스템(100)에 의하여 사용되는 모든 제 3 자 애플리케이션(40)이 웹사이트 구축 시스템(30)에 등록되기 때문에, 허브(205)는 웹사이트 구축 시스템(30)과 함께 메시지 내에 포함될 수도 있는 고유한 발신자 ID가 메시지 발신지(도메인, 포트, 등)와 정합되는지 여부를 검증할 수도 있다는 것이 인정될 것이다.

제 3 자 애플리케이션(40)은 웹 페이지(203) 정보 등을 보유하는 외부 정보에 의존할 수도 있는 일반적 통신 정책을 형성할 수도 있다. 통신 실행기(330)는 문제가 되는 통신 정책이 비-호환(conforming) 통신을 다룰 필요가 없이 실행된다는 것을 보장할 수도 있다. 예를 들어, 분류 정보 핸들링 웹 사이트에서, 제 3 자 애플리케이션에는 그들의 프로파일 내에 분류 레벨 필드가 태깅될 수도 있다. 분류 레벨 X에 대하여 검증된 백-엔드 이벤트 로깅 데이터베이스를 제공하는 제 3 자 애플리케이션(40)은 정책을 규정할 수도 있고, 이를 통하여 X 보다 더 큰 분류 레벨을 가지는 로깅에 대한 이벤트를 수락하지 않을 것이다. 통신 실행기(330)가 이러한 상황에 있고, 요구된 예비 필터링을 수행하며, 높다고 분류된 메시지가 하위 분류 애플리케이션에 도달하는 것조차 하지 못하게 방지할 수도 있다.

디자이너(5)가 동일한 생성된 웹-사이트 내에, 협동하는 것이 가능하지만 일부 프로토콜 호환성 이슈 때문에 실제로는 협동하지 않는 두 개의(또는 그 이상) 제 3 자 애플리케이션을 포함하기를 희망할 수도 있다는 것이 역시 인정될 것이다. 예를 들어, 이제 참조할 도 12 에 도시되는 바와 같이, e-상점 제 3 자 애플리케이션[a]은 구매 주문 메시지를 제 3 자 애플리케이션[b](상이한 벤더에 의하여 제공됨)으로 포스팅하는 능력을 가질 수도 있다. 그러나, 제 3 자 애플리케이션[a]에 의하여 제공되는 정보는 제 3 자 애플리케이션[b]에 의하여 요구되는 몇몇 필드를 포함하지 않을 수도 있다. 이러한 상황은 통상적으로 수반된 제 3 자 애플리케이션의 제 3 자 애플리케이션 벤더에 의하여 해소되어야 하는데, 하지만 몇 가지 경우들에서 이러한 해소는 가능하지 않다(예를 들어 두 제 3 자 애플리케이션 중 하나가 몇몇 이유에 의하여 현재는 업데이트될 수 없다). 프로토콜 전환기(340)는 관련된 메시지를[a]로부터[b]로 전환할 수도 있다(예를 들어 추가 요구 필드를 제공함으로써). 이러한 전환은 프로토콜 전환기(340)에 의하여 수행될 수도 있고, 또는 가능하게는 임베딩된 웹 사이트 및 보유 웹 페이지(203)와의 몇몇 상호작용을 수반할 수도 있다(예를 들어 추가적 정보가 필요하다면).

제 3 자 애플리케이션(40)이 메시지를 전송하고 다른 제 3 자 애플리케이션(40)으로부터 수신하는 몇몇 기능을 가질 수도 있다(위에서 설명된 e-상점 / 실행 제 3 자 애플리케이션(40) 쌍)는 것이 역시 인정될 것이다. 그러나, 몇 가지 경우에서 솔루션의 일부가 누락될 수도 있고, 상기 예에서, 정합되는 것이 없거나 적합한 실행 제 3 자 애플리케이션(40)이 존재하지 않는 경우가 발생할 수도 있다. 이러한 경우에, 리디렉터(350)는 디자이너(5)가, 주어진 메시지가 보유 웹 페이지(203) 컴포넌트로 또는 그로부터 라우팅될 수도 있다는 것과 정합하는 능력이 보유 웹 페이지(203) 컴포넌트 및 그 컴포넌트가 제공할 수도 있는 기능성에 의하여 해소될 수도 있다는 것을 특정하게 할 수도 있다. 이것은 특수-목적 제 3 자 애플리케이션(40)의 구성을 요구하지 않고 풀 웹 사이트의 구성을 허용할 수도 있다. 그러므로 거래가 데이터베이스로의 거래의 로깅을 수행할 수 있는 웹사이트 구축 시스템(30) 컴포넌트로 포스팅될 수도 있고, 데이터베이스는 오프라인 실행 및 배송을 수행하기 위하여 추후에 사용(별개의 프로그램에 의하여) 될 수도 있다.

제 3 자 애플리케이션(40)은, 동일한 코드 베이스를 가지지만 상이한 가능을 가지는, 상이한 성능을 가지는 다수의 구성을 제공할 수도 있다. 예를 들어, 제 3 자 애플리케이션(40)은 무료 버전을 통한 기본적인 기능성, 및 구매된 프리미엄 버전, 다수의 구입된 버전 또는 추가적 구매된 제 3 자 애플리케이션(40) 피쳐를 통한 추가적 기능성을 제공할 수도 있다.

시스템(100)이 사용자당(또는 사실상 디자이너당) 제 3 자 애플리케이션(40) 구매 상태의 웹사이트 구축 시스템(30) 기초 관리를 포함할 수도 있다는 것이 인정될 것이다. 디자이너가 모두 등록된 웹사이트 구축 시스템(30) 사용자이고 따라서 웹사이트 구축 시스템(30)이 각각의 디자이너(5)에 대한 제 3 자 애플리케이션(40) 구매의 데이터베이스를 관리할 수 있다는 것이 역시 인정될 것이다. 이러한 정보는 디자인 페이즈 동안에 TPA 조율기(24)에 의하여 그리고 런타임 도중에 구성 관리자(370)에 의하여 속성 시트(23) 내에 저장될 수도 있다. 예를 들어, 제 3 자 애플리케이션(40)은 웹사이트 구축 시스템(30) 클라이언트측 엘리먼트 버전 질의 메시지를 전송할 수도 있다. 웹사이트 구축 시스템(30) 클라이언트측 엘리먼트는 저장소(22) 또는 그것의 국지적으로 캐싱된 복제본을 참조하고, 응답 메시지를 이것이 제공해야 하는 성능에 대한 정보와 함께 제 3 자 애플리케이션(40)으로 반환할 수도 있다.

대안적 구현형태에서, 웹사이트 구축 시스템(30)은, 이전의 질의 메시지를 요구하지 않고, 제 3 자 애플리케이션(40)에게 암호화된 아이프레임 파라미터와 같은 요구된 제 3 자 애플리케이션(40) 구성 정보를 대안적 채널을 통해서 제공할 수도 있다.

본 명세서에서 위에 논의된 바와 같이, 제 3 자 애플리케이션(40)은 특정한 보유 웹 페이지(203) 컴포넌트와 직접적으로 통신할 수도 있다. 제 3 자 애플리케이션(40)은 통신할 컴포넌트를 여러 방법으로 식별할 수도 있다: 연관된 템플릿에 기초하는 컴포넌트에 대하여 직접적으로(본 명세서에서 아래에 좀 더 상세하게 설명됨); 특정한 보유 웹 페이지(203) 컴포넌트로 디자이너(5)에 의하여 명백하게 제공된 액세스 ID; 보유 웹 페이지(203)에 의하여 제공되는(선택적일 수 있는) 컴포넌트 모델 가로질러 제 3 자 애플리케이션(40)으로 향함.

런타임 도중에, 업데이터(380)가 보유 웹 페이지(203) 컴포넌트와 제 3 자 애플리케이션(40) 사이에 메시지 및 응답을 구현할 수도 있다는 것이 인정될 것이다. 예를 들어 제 3 자 애플리케이션(40)은 보유 웹 페이지(203) 컴포넌트의 시각적 및 디스플레이 속성(예컨대, 그들의 포지션, 사이즈, 컬러, 투명도 등)에 영향을 주거나 질의할 수도 있다. 업데이터(380)는 또한 제 3 자 애플리케이션(40)이 보유 웹 페이지(203) 컴포넌트의 콘텐츠를 판독하거나 기록하게 할 수도 있고, 또한 제 3 자 애플리케이션(40)이 미디어 기능을 수행하는, 예를 들어 주어진 오디오 또는 비디오 세그먼트를 미디어 플레이어 컴포넌트로 포스팅하거나 이것이 주어진 기간 동안 동작을 일시중지하도록 요구하는 컴포넌트에 지시를 내리도록 할 수도 있다.

또한 업데이터(380)는 웹사이트 구축 시스템(30) 컴포넌트가 그들이 제 3 자 애플리케이션(40)이 가지게 하는 액세스의 타입을 특정 하는 것을 가능하게 할 수도 있다- 현대 운영 체제의 파일의 보호를 위한 액세스 허가 비트 또는 액세스 제어 목록(ACL의) 기능과 유사함. 이러한 허가는 특정한 벤더로부터의 모든 제 3 자 애플리케이션(40)에 대하여, 또는 특정한 제 3 자 애플리케이션(40)에 대하여 적용하기 위하여 각각의 컴포넌트에 대하여 정의될 수도 있다. 예를 들어, 제 3 자 애플리케이션(40)이 제 3 자 애플리케이션(40)의 보유 웹 페이지(203)의 일부인 텍스트 필드에 액세스하도록 허용될 수도 있다. 이러한 텍스트 필드는 블로그 제 3 자 애플리케이션(40)에 대한 블로그 엔트리를 편집하기 위하여 사용되어, 블로그 제 3 자 애플리케이션(40) 영역 자체 내에 제공될 수 있는 것보다 더 많은 스크린 실 개체(real estate)를 제공할 수도 있다. 멀티-페이지 컨테이너 내의 특정 미니-페이지 내로 임베딩된 제 3 자 애플리케이션(40)에 대하여, 웹사이트 구축 시스템(30)은 제 3 자 애플리케이션(40)의 액세스를 특정한 미니-페이지에만 속해 있는 컴포넌트로 제한할 수도 있다는 것이 인정될 것이다.

업데이터(380)가 제 3 자 애플리케이션(40)이 사이트-글로벌 엘리먼트에 영향을 주도록 허용할 수도 있다는 것이 역시 인정될 것이다. 이것은, 사이트 내의 현재의 페이지, 제 3 자 애플리케이션(40) 및 페이지 이력을 보유하는 컨테이너 내의 현재의 미니 페이지와 같은 속성을 획득하고 설정하는 것을 포함할 수도 있다. 업데이터(380)는 또한 이러한 요청들을 필터링하거나 한정할 수도 있다.

업데이터(380)는 또한 웹사이트 구축 시스템(30)이 제 3 자 애플리케이션(40)의 스타일 및 디스플레이에 영향을 주게 할 수도 있다. 업데이터(380)는 웹사이트 구축 시스템(30)이 포매팅 및 스타일 가이드라인을 제 3 자 애플리케이션(40)으로 제공할 수도 있는 수단이 되는 호(call)를 구현할 수도 있다. 이것은 컬러 및 컬러 방식; 폰트; 문자 사이즈; 투명도; 에니메이션 및 특수 효과(예를 들어 블러링(blurring))과 같은 속성을 포함할 수도 있다. 특히, 컬러 스킴(scheme)은 일반적인 컬러 스킴(예를 들어 후속하는 x 컬러를 사용함)을 포함하거나 고-레벨 컬러와 같을 수도 있다(예를 들어 텍스트에 대하여 컬러 x를 사용하고, 프레임에 대해서 컬러 y를 사용함).

복잡한 스타일 정보를 표현하는 하나의 바람직한 방법은, 케스케이딩 스타일 시트(CSS)를 사용하는 것이라는 것이 인정될 것인데, 이것은 폰트, 사이즈, 컬러 등을 포함하는 다수의 스타일 지령을 표현할 수 있다는 것이 인정될 것이다. 업데이터(380)는 이러한 CSS-기초 메시지를 제 3 자 애플리케이션(40)으로 전송할 수도 있다. 스타일 시트는 속성에 있어서 일반적이거나, 제 3 자 애플리케이션(40)에 의하여 정의되는 특정한 스타일 명칭을 포함함으로써, 웹사이트 구축 시스템(30)이 더 양호한 가이드라인을 제 3 자 애플리케이션(40)으로 제공할 수도 있게 할 수도 있다(예를 들어 스타일 시트는 특정한 제 3 자 애플리케이션(40) 엘리먼트를 가리키고 그들에 대한 가이드라인을 제공할 수도 있음).

그러면 제 3 자 애플리케이션(40)은 이러한 가이드라인을 사용하여 이것의 외관 및 느낌을 생성하게 하고 보유 웹 페이지(203)에 더 잘 적응되도록 할 수도 있다. 이것은 포함되거나 동일한 사이트 내의 다수의 보유 웹 페이지(203)(위에서 언급된 바와 같은 멀티-포트 포함)로부터 보여지는 제 3 자 애플리케이션(40)에 대해서 특히 중요하다. 다수의 보유 페이지는 상이한 컬러 스킴 또는 일반적 디자인을 채용할 수도 있다. 제 3 자 애플리케이션(40)은 이러한 스타일 메시지를 통해서 자신에게 제공된 정보를 사용하고, 각각의 보유 페이지에 더 양호하게 맞춤되도록 자신만의 디스플레이 컬러 및 스타일을 적응시키며, 보유 페이지와 비교할 때 조화되지 않는 컬러 스킴, 외관 및 느낌을 보여주는 것을 피할 수도 있다.

동적 레이아웃 업데이터(360)가 동적 레이아웃 이벤트로부터 초래되는 디스플레이 변경을 처리할 때에 웹사이트 구축 시스템(30) /제 3 자 애플리케이션(40) 또는 제 3 자 애플리케이션(40) 및 이차 제 3 자 애플리케이션 협동을 가능하게 할 수도 있다는 것이 인정될 것이다. 웹사이트 구축 시스템(30)은 페이지 내의 컴포넌트의 일부를 변경시키는 이벤트가 발생할 때에 페이지 디자인을 보존하기 위하여, 페이지 내의 컴포넌트들의 사이즈 및 포지션을 변경할 수도 있다. 이러한 동적 레이아웃 이벤트는, 예를 들어: 상이한 사이즈를 가지는 스크린에서 웹 사이트를 보는 것; 세로 및 가로 모드 사이에서 디스플레이 디바이스를 회전시키는 것; 컴포넌트의 일부의 사이즈 또는 포지션을 변경시키는 것 및 주어진 컴포넌트의 콘텐츠를 변경시키는 것(그들의 사이즈를 변경시키도록 요구하는 방식으로)을 포함할 수도 있다. 동적 레이아웃 이벤트는 서버-기초 콘텐츠 업데이트 - 예를 들어 데이터 피드로부터의 컴포넌트 디스플레이 정보에서의, 또는 동일한 웹 사이트의 다른 동시 사용자에 의한 콘텐츠 변경에 기인하는 것으로부터 초래되는 컴포넌트 업데이트를 더 포함할 수도 있다. 동적 레이아웃 이벤트가 디자인 환경 및 런-타임 환경에서 발생할 수도 있다는 것이 역시 인정될 것이다. 특히 몇몇 컴포넌트 및 제 3 자 애플리케이션(40)은 런-타임 도중에(즉 말단-사용자에 의한), 그리고 디자이너만에 의한 것이 아닌 컴포넌트 콘텐츠 변경 또는 사이즈/포지션 변경을 허용할 수도 있다.

동적 레이아웃 이벤트가 제 3 자 애플리케이션(40)에 의해서도 야기될 수도 있다는 것이 역시 인정될 것이다. 예를 들어, e-상점 제 3 자 애플리케이션(40)은 사용자가 제품 카탈로그 뷰로부터 쇼핑 카트 뷰(상이한 사이즈를 가짐)로 이동할 경우 사이즈 변경을 요구할 수도 있다. 다른 예로서, 제품 카탈로그 제 3 자 애플리케이션(40)은 제품을 강조하기 위한 옵션을 포함할 수도 있는데, 이것은 더 많은 콘텐츠를 포함하는 더 큰 카탈로그 페이지를 디스플레이하도록 할 것이다. 세 번째 예는 추가적 영역을 디스플레이하는 것을 시작하고 중지할 수도 있는 멀티-영역 제 3 자 애플리케이션(40)이다.

현존 시스템은 제 3 자 애플리케이션 디스플레이를 잘라내거나, 스크롤 바를 거기에 추가하거나, 또는 이것을 단지, 다시 참조되는 도 6 에 도시된 바와 같이 다른 페이지 컴포넌트를 감추는 팝업 윈도우로서 리사이징함으로써 이러한 상황(발생한다면)을 처리한다. 동적 레이아웃 업데이터(360)는 웹사이트 구축 시스템(30) 및 제 3 자 애플리케이션(40)이 동적 레이아웃을 실행하고 보유 웹 페이지(203)의 기본적인 디자인을 유지하는 협동적 동적 레이아웃을 구현할 수도 있다. 동적 레이아웃의 기능성은 2013 년 2 월 20 일에 출원되고 본 발명의 공동 양수인에게 양도된 미국 특허 출원 제 13/(771,119 호에 더 상세하게 설명된다. 그러나, 협동적 동적 레이아웃 지지 시스템에서도, 보유 웹 페이지(203) 내의 동적 레이아웃 메커니즘은 제 3 자 애플리케이션(40)의 내부 레이아웃의 전체 제어를 가지지 않는다. 더욱이, 웹사이트 구축 시스템(30) 위젯은, 그들이 임의의 사이즈(주어진 범위 내의)로 리사이징될 수 있도록 설계될 수도 있는데, 제 3 자 애플리케이션(40)은 임의의 리사이징을 지원하지 않을 수도 있다. 제 3 자 애플리케이션(40)은, 예를 들어 다음: 상이한 사이즈를 가지는 다수 개의 디스플레이 구성(예를 들어 더 많거나 또는 더 적은 세부사항을 디스플레이함); 자신의 내부 엘리먼트 중 일부를 리사이징하는 능력 및 자신의 내부 텍스트 엘리먼트를 다수의 폰트 사이즈를 사용하여 디스플레이하는 능력의 임의의 조합을 제공할 수도 있다.

제 3 자 애플리케이션(40)은 제한된 개수의 가능한 디스플레이 사이즈를 여전히 제공할 수도 있고, 가능한 사이즈의 전체 범위를 가질 수도 있다. 그러므로,[보유 웹 페이지(203) -> 제 3 자 애플리케이션(40)] 리사이징 요청은 가장 가까운 가능한 사이즈로 스위칭하는 제 3 자 애플리케이션(40)에 의하여, 또는 가능한 제 3 자 애플리케이션(40) 사이즈의 목록을 제공함으로써(그리고 웹사이트 구축 시스템(30)이 사용할 가장 적당한 하나를 선택하도록 함으로써) 해결될 수도 있다.

동적 레이아웃 업데이터(360)는 [보유 웹 페이지(203) ->제 3 자 애플리케이션 40] 후속하는 시퀀스를 사용하여 협동 동적 레이아웃을 구현할 수도 있다:

예를 들어, 보유 웹 페이지(203) 내에 임베딩된 제 3 자 애플리케이션(40)은 주어진 원하는 사이즈(예를 들어 X1*Y1 픽셀)로 리사이징될 필요가 있을 수도 있다. 동적 레이아웃 업데이터(360)는 제 3 자 애플리케이션(40)에게 제 3 자 애플리케이션(40)이 자신의 콘텐츠를 주어진 원하는 사이즈(X1*Y1)로 리사이징하도록 요청하는 메시지를 전송할 수도 있다. 제 3 자 애플리케이션(40)은 대안적 디스플레이 구성, 내부 리사이징, 내부 동적 레이아웃 처리 또는 임의의 다른 수단을 사용하여 그 사이즈로 조절할 수도 있다. 보유 웹 페이지(203)가 제 3 자 애플리케이션(40)을 보유하는 외부 아이프레임 윈도우를 새 사이즈(X1*Y1)로 리사이징할 수도 있다는 것이 역시 인정될 것이다.

제 3 자 애플리케이션(40)이 리사이징을 제한된 세트의 가능한 사이즈들(예를 들어 특정한 사용자 인터페이스 구성)로만 허용할 수도 있다는 것이 역시 인정될 것이다. 따라서, 동적 레이아웃 업데이터(360)는 제 3 자 애플리케이션(40)이 가능한 사이즈의 세트를 제공하게 하는 후속하는 대안적 알고리즘을 사용할 수도 있다.

보유 웹 페이지(203)는 리사이징되고, 동적 레이아웃 업데이터(360)는 제 3 자 애플리케이션(40)에게 제 3 자 애플리케이션(40)이 자신의 콘텐츠를 주어진 원하는 사이즈(X1*Y1)로 리사이징하도록 요청하는 메시지를 전송한다. 그러면 제 3 자 애플리케이션(40)은 가장 가까운 가능한 사이즈(예를 들어 X2*Y2 픽셀)를 결정하고 대안적 디스플레이 구성, 내부 리사이징, 내부 동적 레이아웃 처리 또는 임의의 다른 수단을 사용하여 이에 상응하게 리사이징할 수도 있다. 그러면 업데이터(380)는 보유 웹 페이지(203)에게 리사이징을 확정하는 응답 메시지를 전송하고 실제 새로운 사이즈(X2*Y2)를 제공할 수도 있다. 보유 웹 페이지(203)는 제 3 자 애플리케이션(40)을 보유하는 외부 아이프레임 윈도우를 실제 새로운 사이즈(X2*Y2)로 리사이징할 수도 있다. 보유 웹 페이지(203)는 실제 새로운 사이즈(X2*Y2)에 기초하여 동적 레이아웃 처리를 계속할 수도 있다.

특히 다수의 제 3 자 애플리케이션(40)이 보유 웹 페이지(203) 내에 있다면(또는 멀티-영역 다수의 제 3 자 애플리케이션(40)) 다른 실시예가 또한 적용가능하다는 것이 인정될 것이다. 이러한 실시예에서 보유 웹 페이지(203)는 임베딩된 제 3 자 애플리케이션(40)이 디스플레이 사이즈의 목록을 획득하도록 질의함으로써, 이들이 다수의 제 3 자 애플리케이션(40)에 대한 다수의 옵션을 고려하면서 회관 및 느낌을 최적화하도록 시도할 수도 있게 할 수도 있다. 이러한 실시예는 또한 다수의 영역에 걸쳐 디스플레이되는 제 3 자 애플리케이션(40)의 경우에 관련될 수도 있다.

보유 웹 페이지(203)는 동적 레이아웃 처리를 처리하여, 하나 이상의 제 3 자 애플리케이션(40)(TPA[1] 내지 TPA[n])이 보유 웹 페이지(203) 내에 임베딩되고 후속하는 알고리즘을 사용하여 리사이징되어야 한다는 것을 발견할 수도 있다:

i가 1부터 n까지 반복함:

각각의 TPA[i]에 대하여 다음을 결정함

최소 사이즈 Xmin[i] * Ymin[i];

최대 사이즈 Xmax[i] * Ymax[i];

최적 Xopt[i] * Yopt[i];

동적 레이아웃 업데이터(360)는 위의 최소/최대/선택 사이즈를 구체화하는 메시지를 TPA[i]로 전송하고, 가능한 제 3 자 애플리케이션(40) 사이즈에 대한 정보를 요청할 수도 있다.

제 3 자 애플리케이션(40)은 동적 업데이터(380)에게 이것이 취할 수도 있는 가능한 사이즈 옵션의 세트 Xposs[i][j] * Yposs[i][j]를 제공할 수도 있다.

위에서 수집된 Xposs[][]/Yposs[][] 정보에 기초하여, 보유 웹 페이지(203)는(예를 들어) 모든 가능한 제 3 자 애플리케이션 사이즈 조합, 선형 프로그래밍 기법 또는 동적 레이아웃 알고리즘에 의하여 사용되는 임의의 다른 기법의 전체적인 평가를 사용함으로써 솔루션에 대한 솔루션을 계산할 수도 있다.

결과를 모든 TPA에 대하여 저장한다.

i가 1부터 n까지 반복함:

그러면 보유 웹 페이지(203)는 리사이징 메시지를 Xfinal[i]/Yfinal[i]를 가진 TPA[i]로 전송할 수도 있다;

보유 웹 페이지(203)는 TPA[i]를 보유하는 외부 아이프레임 윈도우를 Xfinal[i]/Yfinal[i]로 리사이징한다;

보유 웹 페이지(203)는 실제 새로운 사이즈에 기초하여 동적 레이아웃 처리를 계속한다.

동적 레이아웃 처리가 통상적으로 제 3 자 애플리케이션(40)을 이동시키는 것을 요구하고 이들을 리사이징할 것을 요구하지 않을 것이라는 것이 인정될 것이다. 그러나, 제 3 자 애플리케이션(40)은 보유 웹 페이지(203) 내의 이것의 프레임의 정확한 위치에 대해서는 불변이어야 한다.

본 명세서에서 위에 논의된 바와 같이, 제 3 자 애플리케이션(40)은 또한 자신의 디스플레이 윈도우 사이즈를 때때로 변경할 필요가 있을 수도 있다. 아이프레임을 디스플레이하는 윈도우의 사이즈가 호스팅 페이지(즉 보유 웹 페이지(203))에 의하여 관리되기 때문에, 제 3 자 애플리케이션(40) 윈도우 사이즈 변경은 보유 웹 페이지(203)에 의하여 수행되어야 한다 - 제 3 자 애플리케이션(40)이 보유 웹 페이지(203)로부터 윈도우 사이즈를 변경하도록 요구함(동적 레이아웃 업데이터(360)를 통하여).

제 3 자 애플리케이션(40)이 또한 보유 웹 페이지(203) 내의 자신의 포지션을 변경하도록 요청(동적 레이아웃 업데이터(360)를 통하여)할 수도 있다는 것이 역시 인정될 것이다. 이것은 내부적으로 제 3 자 애플리케이션(40)에(사이즈 변경이 그러하듯이) 영향을 주지 않을 수도 있고, 반면에 보유 웹 페이지(203) 내의 디스플레이 변경을 요구한다. 동적 레이아웃 업데이터(360)는 이러한 요청을 동적 레이아웃과 통합할 수도 있다. 보유 웹 페이지(203)는 제 3 자 애플리케이션(40) 윈도우 사이즈(및 가능하게는 이것의 위치)를 변경하고 제 3 자 애플리케이션(40)으로의 사이즈 및 포지션 변경을 확정하도록 동적 레이아웃 업데이터(360)를 활성화할 수도 있다.

또한, 허브(205)가 추가적 제 3 자 애플리케이션(40) 클래스-특이적 또는 제 3 자 애플리케이션 특이적 메시지를 구현할 수도 있고, 이를 통해서 웹사이트 구축 시스템(30) 자체, 특정 보유 웹 페이지(203) 또는 이차 제 3 자 애플리케이션(40)이 제 3 자 애플리케이션(40)에 영향을 줄 수도 있다는 것이 인정될 것이다. 예를 들어, 블로그 제 3 자 애플리케이션(40)은 새 블로그 엔트리, 또는 새 톡백(talk-back)을 현재의 블로그 엔트리로 포스팅할 수도 있다는 인입하는 메시지를 정의할 수도 있다. 이러한 메시지는 보유 웹 페이지(203)에 의하여(예를 들어 제 3 자 애플리케이션 영역 외부의 큰 편집 필드로부터의 블로그 엔트리를 포스팅하기 위한 방법으로서) 사용될 수도 있다. 이것은 또한, 예를 들어 지원 제 3 자 애플리케이션이 블로그 엔트리를 블로그 제 3 자 애플리케이션으로 포스팅하도록 허용하는 더 높은-레벨 애플리케이션-애플리케이션 링크에 대하여 사용될 수 있다.

제 3 자 애플리케이션(40)이 흔히 매우 다양한 복잡한 서비스를 제 3 자 애플리케이션(40) 내부 사용을 위하여 또는 그들의 사이트 내에서 제 3 자 애플리케이션(40)을 사용하는 디자이너에 의한 다운스트림 사용을 위하여 요구한다는 것이 인정될 것이다. 이러한 서비스는 사용자 관리, 청구 및 배송 관리를 포함할 수도 있다. 웹사이트 구축 시스템(30) 벤더는 이러한 서비스를 웹사이트 구축 시스템의 일부로서 제공할 수 없을 수도 있다(예를 들어 기술적 또는 비즈니스 고려사항에 기인하여). 더욱이, 이러한 서비스는 그 자체로 제 3 자 애플리케이션(40)으로서의 "패키징" 에 대하여 적합하지 않을 수도 있다. 추가적으로, 제 3 자 애플리케이션(40) 벤더는 제 3 자 애플리케이션(40)(예를 들어 다수의 제 3자 청구 API)을 사용하는 디자이너에 대한 다수의 이러한 서비스를 제공하고 디자이너(5)가 그 또는 그녀의 사용에 적합한 하나를 선택하게 하는 옵션을 필요로 할 수도 있다.

예를 들어, 페이팰(Paypal™) 호스팅된 API가 웹사이트 구축 시스템(30) 내에 제공될 수도 있고 제 3 자 애플리케이션(40)에 의하여 직접적으로 사용될 수도 있으며 또는 제 3 자 애플리케이션(40)에 의하여 이것을 사용하는 디자이너(5)에게 제공될 수도 있다. 제 3 자 애플리케이션(40)은 또한 자기 자신의 옵션의 세트를 제공하고(즉 특정 청구 타입, 예컨대 일시불, 할부 또는 수입 공유식), 호스팅된 Paypal API를 호출함으로써 이러한 옵션을 구현할 수도 있다.

따라서, 웹사이트 구축 시스템(30)을 사용하는 디자이너(5)는 진보된 청구 기법을 사용하는 특정한 제공자(예컨대, 음악을 판매하는 e-상점)를 개발할 수도 있다. 디자이너(5)는 특정한 청산(clearing) 또는 상인간 협약(merchant agreement)을 청구 API 제공자와 협상해야 하는 것을 호스팅된 청구 API를 직접적으로 또는 추가적 추상화 레벨(또는 계층)을 제공하는 제 3 자 애플리케이션(40)을 통해서 사용함으로써 회피할 수도 있다. 이러한 의미에서, 웹사이트 구축 시스템(30)은 호스팅된 API 벤더에 대한 배포자가 될 수도 있다.

호스팅된 API 래퍼(390)는 시스템의 상이한 부분들(예를 들어 웹사이트 구축 시스템(30), 호스팅된 API 코드 및 포함된 제 3 자 애플리케이션(40)) 사이의 이러한 통신을 용이화할 수도 있다. API 래퍼 계층, 및 실제 API 구현형태가 웹사이트 구축 시스템(30) 자체 또는 다른 제 3 자 애플리케이션(40) 내에서 상주할 수도 있다는 것이 인정될 것이다. 제 3 자 애플리케이션(40) 벤더(또는 디자이너(5))는 호스팅된 API를 실제 하재(下在) API가 구현되는 방식에 대해서 알지 못하면서 호스팅된 API 래퍼(390)를 통해서 사용할 수도 있다.

본 발명에 대한 대안적이고 상보적인 실시예에서, 출원인은 또한, 웹사이트 구축 시스템(30)과 하나 이상의 제 3 자 애플리케이션(40) 사이의 스마트 통합이 통합 모델을 사용함으로써 획득될 수도 있고, 이러한 모델에서 추가적 웹사이트 구축 시스템 템플릿 및 컴포넌트가 앱스토어(25)의 레벨에 있는 제 3 자 애플리케이션과 그리고 관련된 제 3 자 애플리케이션 인스턴스와 관련된다는 것을 깨달았다. 제 3 자 애플리케이션(40)은 또한 이러한 컴포넌트와(그리고 비-연관된 컴포넌트와) 통신하여 데이터 및 제어 메시지를 교환할 수도 있다. 본 명세서에서 위에 논의된 바와 같이, 보유 웹 페이지(203) 내의 제 3 자 애플리케이션 영역(40)은, 그의 콘텐츠가 메인 사이트가 호스팅되는 도메인과는 달리 별개의 도메인(제 3 자 애플리케이션 벤더의 것이거나 다른 것의 도메인) 내에 호스팅되는 별개의 아이프레임이다. 따라서, 상이한 아이프레임들 사이의 통신은 브라우저의 "동일한 발신지 정책"에 따르게 되고, 명세서에서 위에서 설명된 바와 같은 기법의 사용을 요구한다.

현존 시스템은 제 3 자 애플리케이션(40)을 보유 웹 페이지(203) 내에 포함되지만 그렇지 않으면 보유 웹 페이지(203) 자체의 외관 및 느낌에 영향을 주지 않는 모놀리식(monolithic) 강성 오브젝트로서 구현한다. 제 3 자(40) 인스턴스는(통상적으로 사각형) 영역 내에 배치되고, 자신의 활동 모두를 이러한 영역 내에서 수행한다.

출원인은 또한 이러한 의견이, 본 발명의 일 실시예에 따르는, 연관된 템플릿 이라고 지칭되는 제 3 자 애플리케이션(40)과 연관된(선택적인) 추가적 웹사이트 구축 시스템(30) 템플릿을 가짐으로써 확장될 수도 있다는 것을 깨달았다. 이러한 연관이 제 3 자 애플리케이션(40)의 개발 및 공개(publishing) 도중에 수행될 수도 있고 제 3 자 애플리케이션(40) 선택/구매 프로세스(앱스토어(25)로부터의) 및 제 3 자 애플리케이션(40) 인스턴스 생성의 일부로서 디자이너(5)에게 제공될 수도 있다는 것이 인정될 것이다. TPA 조율기(24)는 제 3 자 애플리케이션(40)(앱스토어(25)에 의하여 관리되거나 그렇지 않으면 제 3 자 애플리케이션(40) 벤더에 의하여 제공되는 것의 일부로서)과 연관되는 템플릿을 취출할 수도 있고 템플릿을 본 명세서에서 위에서 설명된 바와 같은 추후 사용을 위하여 저장소(22) 내에 저장할 수도 있다.

시스템(100)이 다수의 연관된 템플릿과 함께 제 3 자 애플리케이션(40)의 공개를 지원하여 디자이너(5)가 그의 또는 그녀의 요구에 가장 맞는 템플릿을 선택하게 할 수도 있다는 것이 인정될 것이다.

임의의 보유 웹 페이지(203) 내에 제 3 자 애플리케이션(40)의 인스턴스를 생성하는 경우, 연관된 템플릿 내의 컴포넌트가 보유 웹 페이지(203)와 병합될 수도 있고 보유 웹 페이지(203) 내에서 임의의 다른 컴포넌트와 함께 디스플레이될 수도 있다는 것이 인정될 것이다.

이제 본 발명의 일 실시예에 따르는 연관된 템플릿의 사용의 일 예를 예시하는 도 13 을 참조한다. 도시된 바와 같이, 제 3 자 애플리케이션[a]은 컴포넌트[d] 및 [e]를 포함하는 연관된 템플릿[c]과 함께 앱스토어[b] 내에 배치된다. 제 3 자 애플리케이션[a]이 보유 웹 페이지(203)[f] 내에 포함되는 경우, 제 3 자 애플리케이션[a]은 페이지[f] 내의 자신의 지정된 영역[g] 내에 디스플레이될 수도 있고 컴포넌트[d] 및 [e]의 인스턴스[d'] 및 [e'] 는 기존의 컴포넌트[h] 및 [j]와 함께 페이지[f]에 디스플레이될 수도 있다는 것이 인정될 것이다.

시스템(100)이 연관된 템플릿 컴포넌트 인스턴스(예를 들어 위의[d'] 및 [e'])가 보유 웹 페이지(203)[f] 내에 포지셔닝되는 다수의 방법을 지원할 수도 있다는 것이 인정될 것이다. 이것은: 절대적 배치(즉 원래의[d] 및 [e]에 대한 연관된 템플릿[c] 내에 특정된 사이즈 및 포지션을 사용함); 타겟-상대적 배치(즉 보유 웹 페이지(203)[f]에 따르는 새로운 인스턴스[d'] 및 [e'] 의 사이즈 및 포지션을 조절함); 및 제 3 자 애플리케이션(40) 상대적 배치(즉 새로운 인스턴스[d'] 및 [e'] 의 사이즈 및 포지션을 보유 웹 페이지(203)[f] 내의 제 3 자 애플리케이션 인스턴스[g]의 사이즈 및 포지션에 상대적으로 조절함)를 포함할 수도 있다. 특정한 배치 방법을 결정하는 것은 연관된 템플릿[c] 내에 포함된 설정에 기초하여 행해짐으로써 가능하게는 디자이너(5)가 이것을 덮어쓰기 하도록 할 수도 있다.

디자이너(5)가 템플릿[c]로부터 유래된 컴포넌트[d] 및 [e] 의[f] 내의 인스턴스를 수정할 수도 있게 하는 것이 역시 인정될 것이다. 이러한 변경은 오직[f] 내의[d] 및 [e]의 사용에만 적용될 수도 있고(그리고 가능하게는 페이지간 유래(inheritance)를 지원하는 웹사이트 구축 시스템(30) 내로부터 유래되는 페이지에만), 앱스토어[b] 내의 제 3 자 애플리케이션[a]과 연관된 "원래의" 템플릿[c]에 영향을 주지 않을 수도 있다.

위의[d] 및 [e] 인스턴스에 변경을 가하는 것은, 특히, 특정 콘텐츠(텍스트, 이미지, 등)를 필드 인스턴스에 지정하는 것 및 정규 속성 변경을 포함할 수도 있다는 것이 인정될 것이다. 제 3 자 애플리케이션(40)이 미니-페이지 내에 포함된다면, 연관된 템플릿이, 그 안에 참조되는 도 14 에 도시되는 바와 같이 제 3 자 애플리케이션(40)이 포함되는 특정한 미니-페이지에 적용된다는 것이 역시 인정될 것이다. 도시된 바와 같이, 제 3 자 애플리케이션(40)은 미니-페이지[x] 내에 포함되고, 따라서 컴포넌트[c] 및 [d]는[x]에 추가되지만 동일한 멀티-페이지 컨테이너[g]의 추가적 미니-페이지[y] 및 [z] 로는 추가되지 않는다.

섹션-타입 미니-페이지에 대하여, 연관된 템플릿(존재한다면)이 제 3 자 애플리케이션(40)을 보유하기 위하여 생성된 가상의(그리고 빈) 보유 웹 페이지(203)에 적용된다는 것이 역시 인정될 것이다.

대안적인 실시예에서, 선-생성된 연관된 템플릿은 신규 생성 페이지 또는 미니-페이지에 적용될 수도 있고, 이것은 보유 웹 페이지(203)를 포함하는 것과 "병렬적"이다. 이러한 신규 생성 페이지 또는 미니-페이지는 템플릿으로써 초기화될 수도 있고, 이것은 이제 원할 경우 수정될 수 있다.

웹사이트 구축 시스템(30)은 또한 멀티-포트 포함을 허용할 수도 있다 - 여기서는 동일한 제 3 자 애플리케이션(40) 인스턴스가 메인 사이트의 다수의 페이지로부터 가시적이고 그 안에 "상주"한다. 이것은 메인 사이트 내의 주어진 제 3 자 애플리케이션(40)의 다수의 포함과는 상이하다- 이것은 제 3 자 애플리케이션(40)의 다수의 인스턴스를 생성한다. 따라서 제 3 자 애플리케이션(40) 콘텐츠 - 인스턴스-특이적임 -는 동일한 멀티-포트 제 3 자 애플리케이션(40)의 다수의 뷰들 사이에서 공유된다.

이러한 멀티-포트 포함에서, 연관된 템플릿은 개별적으로 제 3 자 애플리케이션(40) 인스턴스가 추가되는 페이지 및 미니-페이지의 각각에 적용될 수도 있다.

본 명세서에서 위에 논의된 바와 같이, 시스템(100)은 제 3 자 애플리케이션(40)과 보유 웹 페이지(203) 내의 컴포넌트 사이에 양방향 통신 링크를 제공할 수도 있다. 이것은 제 3 자 애플리케이션으로부터의 연관된 템플릿의 병합으로부터 초래되는 보유 웹 페이지(203) 컴포넌트, 및 임의의 이러한 연관된 템플릿과 관련되지 않은 컴포넌트를 포함한다는 것이 인정될 것이다.

따라서 제 3 자 애플리케이션(40) 벤더가 벤더에 의하여 생성된 제 3 자 애플리케이션(40)과 연관될 다수 개의 템플릿을 통상적으로 생성할 수도 있다는 것이 인정될 것이다. 이러한 템플릿은 실제로 배포되고 있는 템플릿(즉 현재 배포된 제 3 자 애플리케이션 버전과 연관된 템플릿)에 추가하여 테스트, 개발 및 다른 템플릿을 포함할 수도 있다.

본 명세서에서 위에 논의된 바와 같이, 제 3 자 애플리케이션(40)은 앱스토어(25)를 통해서 배포될 수도 있고, 또한 웹사이트 구축 시스템(30) 벤더와 관련되거나 이에 의하여 관리되지 않는 대안적 채널을 통해서 배포될 수도 있다. 그러나, 제 3 자 애플리케이션(40)과 함께 배포되는 연관된 템플릿은 애플리케이션 저장소(22)와 매우 관련되고 이와 커플링될 수도 있는데, 이는 이들이 웹사이트 구축 시스템(30)에 의하여 관리되는 컴포넌트, 베이스 템플릿 및 다른 엘리먼트에 의하여 구축되기 때문이다.

더욱이, 이러한 개별적으로-배포되는 연관된 템플릿에 하재(underlying)하는 웹사이트 구축 시스템(30) 엘리먼트는 수정되거나 삭제되어, 가능하게는 연관된 템플릿을 "분해(breaking)"해야할 수도 있다. 이러한 문제를 해소하기 위하여, 시스템(100)은 이러한 연관된 템플릿을 애플리케이션 저장소(22) 내의 별개의 영역(가능하게는 제 3 자 애플리케이션(40) 벤더당) 내에 구현할 수도 있다. 웹사이트 구축 시스템(30)은 이러한 템플릿을 다른 웹사이트 구축 시스템(30) 템플릿과 동일한 방식으로 관리할 수도 있다.

제 3 자 애플리케이션(40) 벤더에게 생성된 각각의 템플릿에 대하여 고유한 ID(개발 ID)가 제공될 수도 있고, 이것은 이러한 ID를 제 3 자 애플리케이션(40) 개발 및 테스팅 프로세스 도중에 사용할 수도 있다는 것이 역시 인정될 것이다. 제 3 자 애플리케이션(40)이 공개/ 배포되어야 한다면, 제 3 자 애플리케이션(40) 벤더는 대안적인 고유 ID(공개 ID)를 신청하고 수신하도록 요구될 수도 있고, 공개된 제 3 자 애플리케이션(40) 내에서 이것을 참조할 수도 있다. 공개 ID가 제공되면, 템플릿의 별개의 잠금된 복제본이 생성된다. 이것은 제 3 자 애플리케이션(40)에 의하여 참조되고 제 3 자 애플리케이션(40)의 인스턴스를 생성할 경우 사용되는 복제본이다. 이러한 방식으로, 제 3 자 애플리케이션(40) 벤더는 "실(live)" 제 3 자 애플리케이션(40)(디자이너에 의하여 포함되고 있는 것)과 연관된 템플릿을 잘못하여 수정할 수 없게 되며, 참조 무결성이 보존된다. 더욱이, 시스템(100)은 이러한 잠금된 템플릿과 하재 컴포넌트 및 베이스 템플릿 사이의 관련성을 교차-참조할 수도 있다. 이러한 교차-참조는, 예를 들어 이러한 잠금된 템플릿 내에 포함된 웹사이트 구축 시스템(30) 컴포넌트 또는 베이스 템플릿이 수정되어야 한다면(그리고 이러한 수정이 템플릿 또는 제 3 자 애플리케이션(40)을 몇몇 방식으로 분해할 수도 있다면) 웹사이트 구축 시스템(30) 스태프에게 경고를 제공하기 위하여 사용될 수 있다.

그러므로 시스템(100)은 제 3 자 애플리케이션(40), 보유 웹 페이지(203) 내의 컴포넌트와 웹사이트 구축 시스템(30) 사이에 양방향성 통신 채널을 제공할 수도 있다. 보유 웹 페이지(203) 컴포넌트는 제 3 자 애플리케이션과 연관된 템플릿(들)에 기초하거나, 다른 웹사이트 구축 시스템(30) 템플릿에 기초하거나, 또는 임의의 템플릿에 관련되지 않을 수도 있다.

본 명세서에서 제공되는 프로세스 및 디스플레이는 내재적으로 임의의 특정 컴퓨터 또는 다른 장치에 관련되지 않는다. 다양한 범용 시스템이 본 명세서의 교시 내용에 따르는 프로그램과 함께 사용될 수도 있고, 또는 원하는 방법을 수행하기 위하여 더 전문화된 장치를 구성하는 것이 편리하다고 밝혀질 수도 있다. 이러한 다양한 시스템에 대한 원하는 구조가 위의 설명으로부터 명백해질 것이다. 추가적으로, 본 발명의 실시예는 임의의 특정 프로그래밍 언어를 참조하여 설명되지 않는다. 다양한 프로그래밍 언어가 본 명세서에서 설명된 바와 같은 본 발명의 교시를 구현하기 위하여 사용될 수도 있다는 것이 인정될 것이다.

구체적으로 그렇지 않다고 진술되지 않으면, 앞선 논의로부터 명백한 것과 같이, 명세서 전체에 걸쳐서, "처리," "컴퓨팅," "계산," "결정," 또는 기타 등등과 같은 용어를 사용한 논의는, 컴퓨팅 시스템의 레지스터 및/또는 메모리 내에서 물리적, 예컨대 전자적, 양으로서 표현되는 데이터의, 컴퓨팅 시스템의 메모리, 레지스터 또는 다른 이러한 정보 저장, 송신 또는 디스플레이 디바이스 내의 물리량으로서 이와 유사하게 표현되는 다른 데이터로 조작 및/또는 변환하는 컴퓨터, 컴퓨팅 시스템, 또는 유사한 전자적 컴퓨팅 디바이스의 액션 및/또는 프로세스를 지칭한다는 것이 인정될 것이다.

본 발명의 실시예는 본 명세서의 동작들을 수행하기 위한 장치를 포함할 수도 있다. 이러한 장치는 원하는 목적을 위하여 특별하게 구성될 수도 있고, 또는 이것은 컴퓨터 내에 저장된 컴퓨터 프로그램에 의하여 선택적으로 활성화되거나 재구성되는 범용 컴퓨터를 포함할 수도 있다. 이러한 컴퓨터 프로그램은 컴퓨터 판독가능 저장 매체, 예컨대, 플로피 디스크, 광학적 디스크, 자기적-광학적 디스크, 판독-전용 메모리(ROMs), 콤팩트 디스크 판독-전용 메모리(CD-ROMs), 랜덤 액세스 메모리(RAMs), 전기적으로 프로그래밍가능한 판독-전용 메모리(EPROMs), 전기적으로 소거가능하고 프로그래밍가능한 판독 전용 메모리(EEPROMs), 자기적 또는 광학적 카드, 플래시 메모리, 또는 전자적 명령을 저장하기에 적합하고 컴퓨터 시스템 버스에 연결될 수 있는 임의의 다른 타입의 미디어를 포함하지만 이들로 한정되는 것은 아닌 임의의 타입의 디스크에 저장될 수도 있다.

본 발명의 특징들이 본 명세서에서 예시되었고 설명되었지만, 많은 변경, 치환, 수정, 및 균등물이 이제 당업자들에게 떠오를 것이다. 그러므로, 첨부된 청구항이 본 발명의 참 사상에 속하는 모든 이러한 변경 및 변화를 커버하도록 의도된다는 것이 이해되어야 한다.

Claims (25)

1. 웹사이트 구축 시스템용 디바이스로서,
   메모리;
   프로세서;
   다수의 웹사이트 구축 시스템 컴포넌트를 갖는 웹사이트의 페이지를 디자이너가 생성할 수 있게 하는 페이지 작성기 - 상기 컴포넌트는 개개의 스타일을 정의하는 시각 및 디스플레이 속성을 가지며, 상기 페이지는 적어도 하나의 제 3 자 애플리케이션의 웹사이트 인스턴스를 보유함 -;
   상기 페이지가 열람 또는 액세스될 때,
   상기 웹사이트 구축 시스템과 상기 페이지,
   상기 페이지와 상기 적어도 하나의 제 3 자 애플리케이션,
   상기 웹사이트 구축 시스템과 상기 적어도 하나의 제 3 자 애플리케이션, 및
   상기 적어도 하나의 제 3 자 애플리케이션과 제2 의 제 3 자 애플리케이션
   사이의 양방향 통신 백채널(2-way communication backchannel)을 제공하기 위한, 상기 페이지에 내장된 통신 허브 - 상기 백채널은, 상기 웹사이트 구축 시스템, 상기 페이지, 상기 적어도 하나의 제 3 자 애플리케이션, 및 상기 제2 의 제 3 자 애플리케이션에 있어서의 상기 컴포넌트의 상기 속성에 대해 적어도 포매팅 및 스타일 가이드라인에 관한 통신을 지원함 -; 및
   상기 통신에 있어서 상기 포매팅 및 스타일 가이드라인에 따라 상기 컴포넌트의 디스플레이 컬러 및 스타일 속성을 적어도 적응시키기 위한 업데이터를 포함하고,
   상기 메모리 및 상기 프로세서는 상기 페이지 작성기, 상기 통신 허브, 및 상기 업데이터를 구현(embody)하는,
   웹사이트 구축 시스템용 디바이스.
2. 제 1 항에 있어서,
   상기 디바이스는 클라이언트 상에서 구현가능한, 웹사이트 구축 시스템용 디바이스.
3. 제 1 항에 있어서,
   상기 디바이스는 서버 상에서 구현가능한, 웹사이트 구축 시스템용 디바이스.
4. 제 1 항에 있어서,
   상기 통신 백채널은 HTML5(Hypertext Markup Language 5) 포스트메시지(PostMessage), 메시지에 대한 URL 프래그먼트 식별자, 전용 통신 웹 서비스, HTML5 로컬 스토리지, HTML5 로컬 파일 시스템 액세스 API 및 전용 브라우저 플러그인 중 적어도 하나인, 웹사이트 구축 시스템용 디바이스.
5. 제 1 항에 있어서,
   상기 적어도 하나의 제 3 자 애플리케이션은 아이프레임을 사용하여 상기 페이지 내에 임베딩되는, 웹사이트 구축 시스템용 디바이스.
6. 제 1 항에 있어서,
   상기 적어도 하나의 제 3 자 애플리케이션은 멀티-파트(multi-part) 제 3 자 애플리케이션 및 모듈식(modular) 제 3 자 애플리케이션 중 적어도 하나인, 웹사이트 구축 시스템용 디바이스.
7. 제 1 항에 있어서,
   상기 통신 허브는 선정의된 상기 적어도 하나의 제 3 자 애플리케이션 인스턴스를 모니터링하기 위한 구성 관리자를 포함하는, 웹사이트 구축 시스템용 디바이스.
8. 제 1 항에 있어서,
   상기 통신 허브는 상기 통신의 소스 또는 타겟의 심볼식(symbolic) 어드레스 및 절대 어드레스를 식별 및 전환하기 위한 스마트 식별기 및 어드레서(addresser)를 포함하는, 웹사이트 구축 시스템용 디바이스.
9. 제 1 항에 있어서,
   상기 통신 허브는 상기 웹사이트 구축 시스템과 상기 적어도 하나의 제 3 자 애플리케이션 사이에서 통신 정책을 실행하기 위한 통신 정책 실행기를 포함하는, 웹사이트 구축 시스템용 디바이스.
10. 제 1 항에 있어서,
    상기 통신 허브는 통신 메시지를 상기 웹사이트 구축 시스템 내에서 상기 적어도 하나의 제 3 자 애플리케이션으로 그리고 제 3 자 애플리케이션으로부터 리라우팅하기 위한 리디렉터(redirector)를 포함하는, 웹사이트 구축 시스템용 디바이스.
11. 제 1 항에 있어서,
    상기 통신 허브는 상기 적어도 하나의 제 3 자 애플리케이션으로부터의 인입하는 메시지의 진정성(authenticity)을 검증하기 위한 발신자 검증기를 포함하는, 웹사이트 구축 시스템용 디바이스.
12. 제 1 항에 있어서,
    상기 통신 허브는 상기 웹사이트 구축 시스템과 상기 적어도 하나의 제 3 자 애플리케이션 사이에서 그리고 상기 제 3 자 애플리케이션과 상기 제2 의 제 3 자 애플리케이션 사이에서 프로토콜 호환성 이슈를 해소하기 위한 프로토콜 전환기(translator)를 포함하는, 웹사이트 구축 시스템용 디바이스.
13. 제 1 항에 있어서,
    상기 통신 허브는,
    상기 페이지와 상기 적어도 하나의 제 3 자 애플리케이션,
    상기 적어도 하나의 제 3 자 애플리케이션과 상기 페이지, 및
    상기 적어도 하나의 제 3 자 애플리케이션과 적어도 하나의 다른 제 3 자 애플리케이션
    중 적어도 하나 사이의 동적 레이아웃 변경을 업데이트하기 위한 동적 레이아웃 업데이터(dynamic layout updater)를 포함하는, 웹사이트 구축 시스템용 디바이스.
14. 제 1 항에 있어서,
    상기 업데이터는, 상기 웹사이트 구축 시스템의 글로벌 속성 및 상기 적어도 하나의 제 3 자 애플리케이션의 제어 허가 중 적어도 하나를 업데이트하도록 구성되는, 웹사이트 구축 시스템용 디바이스.
15. 웹사이트 구축 시스템용 방법으로서,
    다수의 웹사이트 구축 시스템 컴포넌트를 갖는 페이지를 디자이너가 생성할 수 있게 하는 단계 - 상기 컴포넌트는 개개의 스타일을 정의하는 속성을 가지며, 상기 페이지는 적어도 하나의 제 3 자 애플리케이션의 웹사이트 인스턴스를 보유함 -;
    상기 페이지가 열람 또는 액세스될 때,
    상기 웹사이트 구축 시스템과 상기 페이지,
    상기 페이지와 상기 적어도 하나의 제 3 자 애플리케이션,
    상기 웹사이트 구축 시스템과 상기 적어도 하나의 제 3 자 애플리케이션, 및
    상기 적어도 하나의 제 3 자 애플리케이션과 제2 의 제 3 자 애플리케이션
    사이의 양방향 통신 백채널을 제공하는 단계 - 상기 백채널은 상기 웹사이트 구축 시스템, 상기 페이지, 상기 적어도 하나의 제 3 자 애플리케이션, 및 상기 제2 의 제 3 자 애플리케이션에 있어서의 상기 컴포넌트의 상기 속성에 대해 적어도 포매팅 및 스타일 가이드라인에 관한 통신을 지원함 -; 및
    상기 통신에 있어서 상기 포매팅 및 스타일 가이드라인에 따라 상기 컴포넌트의 디스플레이 컬러 및 스타일 속성을 적응시키는 단계
    를 포함하는, 웹사이트 구축 시스템용 방법.
16. 제 15 항에 있어서,
    상기 적어도 하나의 제 3 자 애플리케이션은 멀티-파티(multi-party) 제 3 자 애플리케이션 및 모듈식 제 3 자 애플리케이션 중 적어도 하나인, 웹사이트 구축 시스템용 방법.
17. 제 15 항에 있어서,
    상기 제공하는 단계는, 선정의된 상기 적어도 하나의 제 3 자 애플리케이션 인스턴스를 모니터링하는 단계를 포함하는, 웹사이트 구축 시스템용 방법.
18. 제 15 항에 있어서,
    상기 제공하는 단계는, 상기 통신의 소스 또는 타겟의 심볼식 어드레스 및 절대 어드레스를 식별하고 전환하는 단계를 포함하는, 웹사이트 구축 시스템용 방법.
19. 제 15 항에 있어서,
    상기 제공하는 단계는, 상기 웹사이트 구축 시스템과 상기 적어도 하나의 제 3 자 애플리케이션 사이에서 통신 정책을 실행하는 단계를 포함하는, 웹사이트 구축 시스템용 방법.
20. 제 15 항에 있어서,
    상기 제공하는 단계는, 통신 메시지를 상기 웹사이트 구축 시스템 내에서 상기 적어도 하나의 제 3 자 애플리케이션으로 그리고 제 3 자 애플리케이션으로부터 리라우팅하는 단계를 포함하는, 웹사이트 구축 시스템용 방법.
21. 제 15 항에 있어서,
    상기 제공하는 단계는, 상기 적어도 하나의 제 3 자 애플리케이션으로부터의 인입하는 메시지의 진정성을 검증하는 단계를 포함하는, 웹사이트 구축 시스템용 방법.
22. 제 15 항에 있어서,
    상기 제공하는 단계는, 상기 웹사이트 구축 시스템과 상기 적어도 하나의 제 3 자 애플리케이션 사이에서 그리고 상기 제 3 자 애플리케이션과 상기 적어도 하나의 다른 제 3 자 애플리케이션 사이에서 프로토콜 호환성 이슈를 해소하는 단계를 포함하는, 웹사이트 구축 시스템용 방법.
23. 제 15 항에 있어서,
    상기 제공하는 단계는,
    상기 페이지와 상기 적어도 하나의 제 3 자 애플리케이션; 상기 적어도 하나의 제 3 자 애플리케이션과 상기 페이지; 및 상기 적어도 하나의 제 3 자 애플리케이션과 상기 제2 의 제 3 자 애플리케이션
    중 적어도 하나 사이의 변경을 동적 레이아웃 업데이트하는 단계를 포함하는, 웹사이트 구축 시스템용 방법.
24. 제 15 항에 있어서,
    상기 제공하는 단계는, 웹사이트 구축 시스템의 글로벌 속성, 상기 적어도 하나의 제 3 자 애플리케이션의 제어 허가 및 상기 페이지의 엘리먼트의 레이아웃, 스타일 및 콘텐츠 중 적어도 하나를 업데이트하는 단계를 더 포함하는, 웹사이트 구축 시스템용 방법.
25. 제 24 항에 있어서,
    상기 업데이트하는 단계는 스타일 시트들을 케스케이딩(cascading)하는 단계를 포함하는, 웹사이트 구축 시스템용 방법.

Images