KR102251844B1 - 제 3 자 애플리케이션 활동 데이터 수집을 위한 시스템 및 방법 - Google Patents

Abstract

시스템은 웹사이트 및 적어도 하나의 제 3 자 애플리케이션 사이에서 표준화된 포맷을 가지는 적어도 하나의 활동 메시지를 조정하는 적어도 하나의 허브, 그리고 적어도 하나의 활동 메시지를 청취하고 적어도 하나의 메시지로부터 추출되는 데이터를 식별된 컨택 및 익명의 컨택 중 적어도 하나와 연관되는 스트림에 적어도 추가하는 활동 조정기를 포함하고, 여기서 식별된 컨택 및 익명의 컨택 중 적어도 하나는 웹사이트의 사용자이다. 시스템은 또한 스트림으로부터 컨택 관련 정보를 검색하고 분석하고 그리고 컨택에 대한 이전에 보유된 정보를 강화하는 컨택 조정기 및 웹사이트에 의해 그리고 컨택에 의해 사용되도록 활동 스트림들 및 컨택 관련 정보를 저장하는 적어도 하나의 데이터베이스를 포함한다.

Description

제 3 자 애플리케이션 활동 데이터 수집을 위한 시스템 및 방법{SYSTEM AND METHOD FOR THIRD PARTY APPLICATION ACTIVITY DATA COLLECTION}

본 발명은 온라인 애플리케이션들 및 특히 포함되어 있는 제 3 자 애플리케이션에 의해 온라인 애플리케이션들을 사용하는 것에 관한 것이다.

관련 출원에 대한 교차 참조

본 출원은 2013년 12월 4일에 제출되고, 미국 예비 특허출원 번호 61/911,485로부터의 이점을 주장하고, 상기 출원은 이에 그 전체가 참조로서 통합되어 있다.

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

이 웹사이트 구축 시스템들은 인터넷에 접속되는 서버 또는 서버들 상에 호스팅(hosting)되고 하이퍼텍스트 전송 프로토콜(hypertext transfer protocol; HTTP)과 같은 인터넷 통신 프로토콜들을 사용하여 액세스되는 전 온라인(fully on-line) 웹사이트 구축 시스템들과 같이 상이한 구성들로 출시될 수 있다. 이 웹사이트 구축 시스템들의 생성, 편집 및 배치는 모두 서버들과 직접적으로 온-라인 작업으로 수행된다.

웹사이트 구축 시스템들은 또한 부분적으로 온라인이거나 때로는 심지어 전체가 오프라인(offline)일 수 있다. 부분 온라인 시스템의 경우, 웹사이트 편집은 사용자의 기계에서 국지적으로 수행되고 이후에 배치를 위해 중앙 서버 또는 서버들로 업로드된다. 일단 업로드되면, 이 웹사이트 구축 시스템들은 전 온라인 웹사이트 구축 시스템들과 동일한 방식으로 거동한다.

웹사이트 구축 시스템들은 시스템 내에 데이터 및 요소들을 조직하기 위하여 내부 데이터 아키텍처(architecture)를 가진다. 이 아키텍처는 사용자가 보는 바에 따른 해당 사이트의 외부 뷰(external view)와 상이할 수 있고 또한 전형적인 하이퍼텍스트 마크업 언어(hypertext markup language; HTML) 페이지들이 브라우저에 전송되는 방식과 상이할 수 있다. 예를 들어, 내부 데이터 아키텍처는 페이지 상의 각 요소(생성기(creator), 생성 시간, 액세스 허가들, 템플릿(template)들로의 링크들 등) 별로 웹사이트 구축 시스템 내의 사이트를 편집하고 관리유지하는 데 필수적인 추가 특성들을 포함할 수 있지만, 최종 사용자(또는 심지어 일부 편집 사용자들)가 외부에서 볼 수 없다. 웹사이트 구축 시스템 기반 사이트에 대한 전형적인 아키텍처는 구성요소들(예를 들어, 형상 구성요소들, 영상 구성요소들, 텍스트 구성요소들, 미니 페이지들을 포함하는 단일 및 다 페이지 컨테이너(container)들 등)을 포함하는 페이지들로 구성될 수 있다.

구성요소들은 어떠한 내부 컨텐츠(internal content)도 가지지 않는 별 형상(비록 그것이 컬러, 크기, 위치 및 어떤 다른 속성들을 가질지라도)과 같이 내용이 없을 수 있거나, 또는 텍스트 문단 구성요소와 같이 내부 컨텐츠를 가질 수 있으며, 이 내부 컨텐츠는 디스플레이되는 텍스트뿐만 아니라 폰트, 포맷팅(formatting) 및 레이아웃 정보를 포함한다. 이 내용은 물론 텍스트 문단 구성요소의 하나하나 사례별로 다양할 수 있다.

그와 같은 웹사이트 구축 시스템을 사용하는 설계자는 스크레치(scratch)(빈 화면으로 시작하는)로부터 새로운 창작물을 설계할 수 있거나, 또는 설계자 자신에 의해, 시스템 생성기에 의해 또는 설계자 커뮤니티에 의해 생성되는 사전 규정된 애플리케이션 템플릿들에 의존할 수 있다. 웹사이트 구축 시스템은 단순한 구성요소 집합체들인 템플릿들을 지원하고, 페이지들(또는 미니 페이지들) 또는 심지어 페이지들의 세트들을 완성하고 웹 사이트들을 완성할 수 있다.

애플리케이션 템플릿이 제공되면, 설계자는 이것을 자유로이 맞춤화(customize)할 수 있다- 자신의 템플릿의 버전을 생성하기 위해 템플릿의 모든 요소들을 추가, 제거 또는 수정하는 것 -. 그와 같은 맞춤화는 템플릿의 수정된 버전(템플릿과 구분되고 별개인)을 생성함으로써 구현될 수 있다. 대안으로, 웹사이트 구축 시스템은 원래의 템플릿과의 링크를 유지하고, 따라서 이후에 템플릿에 행해진 변경들을 반영할 상속 유형 메커니즘(inheritance-type mechanism)을 통해 맞춤화를 적용할 수 있다.

웹사이트 구축 시스템들은 또한 제 3 자 애플리케이션들 및 이들 내에 임베딩(embedding)되어 있는 구성요소들을 사용하여 확장될 수 있다. 그와 같은 제 3 자 애플리케이션들은 웹사이트 구축 시스템 설계 환경에 포함될 수 있거나 또는 다수의 배포 메커니즘들을 통해, 예를 들어, 웹사이트 구축 시스템 내에 통합되어 있는 애플리케이션 스토어(앱스토어(AppStore))로부터 또는 웹사이트 구축 시스템(website building system; WBS) 벤더(vendor)에 의해 또는 다른 실체에 의해 운용되는 별개의, 웹 기반 또는 독자형(standalone) 애플리케이션 리포지토리(application repository)(또는 앱스토어)로부터 별개로 구매(또는 다른 방식으로 획득)될 수 있다. 제 3 자 애플리케이션들은 또한 제 3 자 애플리케이션 벤더로부터 직접 획득될 수 있다(앱스토어를 통하거나 통하지 않고) - 이는 실제 설치 모듈을 제공하거나 또는 단지 활성화 코드(activation code) 또는 액세스 코드만을 제공할 것이다.

제 3 자 애플리케이션은 프론트 엔드(front-end)(디스플레이) 요소들 및 백 오피스(back-office) 요소들(비주얼 웹 사이트 디스플레이의 일부가 아닌)의 임의의 결합을 포함할 수 있다. 제 3 자 애플리케이션은 전적으로 백 오피스이거나(즉, 디스플레이 요소를 포함하지 않는다), 전적으로 프론트 엔드이거나(즉, 웹 사이트를 사용하는 상황 내에서만 활성화된다) 또는 이 둘의 결합일 수 있다.

제 3 자 애플리케이션의 백 오피스 요소는 데이터베이스 통신, 외부 업데이트 선택사양 등과 같은 기능들을 포함할 수 있다. 예를 들어, 블로그 제 3 자 애플리케이션은 업데이트들이 비 인간 소스(non-human source)들(예를 들어, 주요 뉴스 서비스로부터의 RSS 뉴스 피드(feed))뿐만 아니라 웹사이트와 관련되지 않은 인간 소스들(예를 들어, 블로그 엔트리(blog entry)들의 제출이 가능한 독자형 스마트폰 애플리케이션)로부터 수신되는 것을 가능하게 하는 백 오피스 요소를 포함할 수 있다.

제 3 자 애플리케이션의 시각 요소를 포함하는 웹 사이트에 통합하는 것은 다수의 방식으로 행해질 수 있다. 위젯(widget) 형 제 3 자 애플리케이션들은 웹 사이트 페이지 내에 구성요소로서 임베딩될 수 있는데 반해 섹션(section) 형 제 3 자 애플리케이션들은 웹 사이트에 추가 페이지 또는 페이지들로서 추가될 수 있다.

더욱이 제 3 자 애플리케이션들(위젯 및 섹션 모두)은 단일 페이지 제 3 자 애플리케이션들 또는 다 페이지 제 3 자 애플리케이션들(내부 URL 구조로서 표현되는 내부 미니 페이지들을 가지는)일 수 있다. 시스템은 네 개의 가능한 결합들(위젯 또는 섹션, 단일 페이지 또는 다 페이지) 중 임의의 결합 또는 모든 결합을 구현할 수 있다.

다 페이지 제 3 자 애플리케이션들은 통상적으로 개시 페이지, 특정 내부 미니 페이지(예를 들어, 블로그 제 3 자 애플리케이션에서의 가장 최근의 블로그 엔트리), 미니 페이지 선택 스크린 또는 어떤 다른 미니 페이지일 수 있는 디폴트(default) "랜딩(landing)" 미니 페이지를 제공한다.

웹사이트 구축 시스템 기반 웹 사이트들에서 제 3 자 애플리케이션들을 사용하는 것은 제 3 자 애플리케이션 인스턴스(application instance)들을 통하여 행해진다. 웹사이트 구축 시스템은 전체 웹 사이트에서 단일 제 3 자 애플리케이션 인스턴스를 가능하게 하고; 웹 사이트 내에서 다수의 제 3 자 애플리케이션들의 인스턴스들이 생성되는 것을 가능하게 하고(그러나 임의의 소정의 제 3 자 애플리케이션의 인스턴스가 하나보다 더 많지 않게) 그리고 다수의 제 3 자 애플리케이션들의 다수의 인스턴스들이 생성되지만 소정의 페이지당 하나보다 더 많은 인스턴스가 생성되지 않는 것을 가능하게 하는 것과 같이, 다수의 레벨들로 제 3 자 애플리케이션들에 대한 다수의 사용들을 지원할 수 있다. 이는 또한 구성요소 제 3 자 애플리케이션들의 페이지당 그러나 섹션 제 3 자 애플리케이션들의 페이지당이 아닌 다수의 인스턴스들을 가능하게 할 수 있고 또한 다수의 제 3 자 애플리케이션들의 다수의 인스턴스들이 제 3 자 애플리케이션 인스턴스들의 양, 다수성 또는 위치에 대한 어떠한 제한없이 생성되는 것을 가능하게 할 수 있다.

제 3 자 애플리케이션 인스턴스는 인스턴스에 특정한 컨텐츠를 가질 수 있다. 예를 들어, e-샵(e-Shop) 제 3 자 애플리케이션은 특정한 인스턴스와 연관되는 제품 데이터베이스를 가질 수 있는데, 이 제품 데이터베이스는 동일한 e-샵 제 3 자 애플리케이션(동일한 사이트 또는 다른 사이트들에 있는)의 다른 인스턴스들과 연관되는 제품 데이터베이스와 상이하다.

논의를 위해, 제 3 자 애플리케이션 및 이의 미니 페이지들 또는 요소들(즉, "랩퍼 페이지(wrapper page)")을 포함하는 웹 사이트 페이지(또는 미니 페이지)는 포함 웹 페이지(containing web page)로서 그리고 전체 웹 사이트에 주 사이트로서 공지될 것이다. 사용자에게 보여지는 통합 페이지- 주 페이지 및 임베딩된 제 3 자 애플리케이션(third party application; TPA) 미니 페이지/구성요소를 포함하는 -는 결합 페이지(combined page)로서 칭해질 것이다. 섹션 유형 제 3 자 애플리케이션들의 경우, 제 3 자 애플리케이션을 포함하는 "가상 페이지(virtual page)"는 포함 웹 페이지 역할을 할 것이다.

제 3 자 애플리케이션들은 통상적으로 웹사이트 구축 시스템 벤더 서버들에, 제 3 자 애플리케이션 벤더 서버에, 외부(제 4 자) 서버들에 또는 이들의 임의의 결합에 배치된다. 제 3 자 애플리케이션은 또한 정적 설치 브라우저 확장(browser extension)과 같이 실제로 최종 사용자 기계 상에서 가동되는 요소들을 포함하거나 이제 참조되는 도 1에 도시되는 바와 같이 웹사이트 구축 시스템 클라이언트 측 코드 내에서 가동되는 자바스크립트(JavaScript) 구성요소를 동적으로 가동할 수 있다.

웹사이트 구축 시스템 벤더의 서버들은 최종 사용자에 대한 컨택 포인트(contact point) 역할을 하고 요청들에 응답한다(가능하면 필요한 정보를 수신하기 위해 제 3 자 애플리케이션 벤더의 서버들에 접속된다). 웹사이트 구축 시스템은 예를 들어 비디오 스트리밍(video streaming)이 요구될 때 클라이언트 컴퓨터 및 제 3 자 애플리케이션 벤더의 서버들 사이의 직접 접속들(필요에 따라)을 생성할 수 있다.

포함되어 있는 제 3 자 애플리케이션 인스턴스들은 정규 구성요소들이 내부 컨텐츠를 포함하는 방식과 유사하게 자기 자신의 내부 컨텐츠를 가질 수 있다. 제 3 자 애플리케이션은 이제 참조되는 도 2에 도시되는 바와 같이 웹사이트 구축 시스템 및 웹사이트 구축 시스템을 사용하여 생성되는 웹사이트와 관계없이 이 컨텐츠를 관리할 수 있다. 다수의 제 3 자 애플리케이션 인스턴스들(단일 또는 다수의 제 3 자 애플리케이션들의)은 공유되는 컨텐츠를 가질 수 있는데, 예를 들어, 2개의 별개의 웹 사이트 페이지들에 있는 2개의 e-샵 인스턴스들은 동일한 제품 데이터베이스를 참고할 수 있다.

포함되는 제 3 자 애플리케이션들로부터의 출력은 포함 웹 페이지에 다음과 같은 다수의 방식들로 통합될 수 있다:

서버 측 프로세싱: 이제 참조되는 도 3에 도시되는 바와 같은 이 대안에서, 제 3 자 애플리케이션 [a](설계 및 디스플레이 요소들을 포함하는) 및 사용자 특정 제 3 자 애플리케이션 데이터 [b]는 제 3 자 애플리케이션 벤더들의 서버 [d] 상에서 가동 중인 제 3 자 애플리케이션 서버 코드 [c]에 의해 병합된다. 이것들은 통신 매체 [e]를 통해 웹사이트 구축 시스템 서버 코드 [f]로 송신되고 이 서버 코드 [f]는 이것들을 포함 웹 페이지 정보 [g]와 병합하고 그 후에 이것들을 사용자 클라이언트 스테이션(station) [h] 상에 디스플레이하기 위하여 송신한다.

클라이언트 측 프로세싱: 이제 참조되는 도 4에서 도시되는 바와 같은 이 대안에서, 제 3 자 애플리케이션 [a](설계 및 디스플레이 요소들을 포함하는) 및 사용자 특정 제 3 자 애플리케이션 데이터 [b]는 제 3 자 애플리케이션 벤더들의 서버 [d]에서 가동 중인 제 3 자 애플리케이션 서버 코드 [c]에 의해 병합된다. 이것들은 통신 매체 [e]를 통해 클라이언트 측 프로세싱 구성요소 [h]로 송신된다. 웹사이트 구축 시스템 서버 코드 [f]는 포함 웹 페이지 정보 [g]를 이 클라이언트 측 프로세싱 구성요소 [h]로 송신한다. 클라이언트 측 프로세싱 구성요소 [h]는 정보의 두 소스의 병합을 수행하고 통합된 애플리케이션을 브라우저(또는 다른 클라이언트 에이전트(client agent)) [i]에 제공한다.

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

본 발명의 목적은 온라인 애플리케이션들 및 특히 포함되어 있는 제 3 자 애플리케이션에 의해 온라인 애플리케이션들을 사용하는 것을 제공하는 것이다.

본 발명의 바람직한 실시예에 따라 적어도 하나의 프로세서를 가지는 클라이언트/서버 시스템을 통해 웹사이트 상에서 구현 가능한 시스템이 제공되고, 프로세서는 시스템을 규정하는 명령들을 프로세싱(processing)한다. 시스템은 웹 사이트 및 적어도 하나의 제 3 자 애플리케이션(third party application) 사이에서 적어도 하나의 활동 메시지를 조정하는 적어도 하나의 허브(hub)를 포함하고, 여기서 적어도 하나의 활동 메시지는 표준화된 포맷을 가진다. 시스템은 또한 적어도 하나의 활동 메시지를 청취하고 그리고 적어도 하나의 메시지로부터 추출되는 데이터를 식별된 컨택(contact) 및 익명의 컨택 중 적어도 하나와 연관되는 스트림(stream)에 적어도 추가하는 활동 조정기(activity coordinator)를 포함하고, 식별된 컨택 및 익명의 컨택 중 적어도 하나는 웹사이트의 사용자이다. 상기 시스템은 또한 스트림으로부터 컨택 관련 정보를 검색하고 분석하고 그리고 컨택에 대해 이전에 보유된 정보를 강화(enrich)하는 컨택 조정기 및 웹사이트에 의해 그리고 컨택에 의해 사용되기 위해 활동 스트림들 및 컨택 관련 정보를 저장하는 적어도 하나의 데이터베이스를 포함한다.

더욱이, 본 발명의 바람직한 실시예에 따르면, 적어도 하나의 허브는: 적어도 하나의 활동 메시지를 웹사이트 및 적어도 하나의 제 3 자 애플리케이션 사이에서 라우팅하고 추적하는 라우터 및 트랙커(router and tracker), 웹사이트 및 적어도 하나의 제 3 자 애플리케이션 사이에서 개인정보 보호 정책(privacy policy)을 시행하는 개인 정책 시행기, 웹사이트 및 적어도 하나의 제 3 자 애플리케이션 사이에서 사전 명시되는 적어도 하나의 메시지 변환 및 컨텐츠 적응 규칙들을 적용하는 변환기 및 어댑터(adapter), 개인 데이터 프록시(proxy) 및 개인 데이터 대체 중 적어도 하나를 구현하고 웹 사이트 및 적어도 하나의 제 3 자 애플리케이션 사이에서 사용자 허가 필드 제한들을 시행하는 개인 데이터 프록시 및 적어도 하나의 제 3 자 애플리케이션의 인입 키(incoming key)를 사용하여 적어도 하나의 활동 메시지의 서명을 검증하고, 내부 웹사이트 ID를 구비하는 적어도 하나의 활동 메시지와 연관되는 외부 ID를 변환하고 그리고 적어도 하나의 제 3 자 애플리케이션의 인출 키(outgoing key)를 사용하여 인출되는 적어도 하나의 활동 메시지를 서명하는 검증기 및 서명기 중 적어도 하나를 포함한다.

더욱이, 본 발명의 바람직한 실시예에 따르면 활동 조정기는: 적어도 하나의 활동 메시지와 연관되는 컨택을 식별하고 연관되는 컨택이 존재하지 않으면 데이터의 스트림을 생성하는 스트림 생성기, 적어도 하나의 활동 메시지로부터의 데이터를 기존의 스트림에 그리고 활동 스트림들 중 적어도 2개로부터의 데이터를 단일 스트림에 병합하는 스트림 병합기 및 활동 스트림으로부터의 활동 데이터를 적어도 하나의 데이터베이스 내로 로깅하는 로그 생성기(log creator) 중 적어도 하나를 포함한다.

더더욱이, 본 발명의 바람직한 실시예에 따르면, 컨택 조정기는: 적어도 하나의 활동 메시지, 스트림, 다른 컨택들 및 외부 소스들 중 적어도 하나로부터 컨택 관련 정보를 추출하는 데이터 추출기, 적어도 2개의 컨택 정보 기록들을 병합하고- 기록들은 동일한 식별된 컨택과 연관성을 가진다- 그리고 미리 규정된 병합 규칙들에 따라 추출된 컨택 관련 정보를 기존의 컨택에 대한 정보와 병합하는 데이터 병합기, 식별 가능한 새로운 컨택 및 익명의 컨택 중 적어도 하나를 생성하고 웹사이트의 세션 동안 컨택 활동을 추적하는 컨택 처리기 및 추출된 컨택 관련 정보의 프라이버시 보호 및 허가들을 처리하는 데이터 및 허가 처리기 중 적어도 하나를 포함한다.

추가로, 본 발명의 바람직한 실시예에 따르면, 라우터 및 트랙커는 적어도 하나의 제 3 자 애플리케이션이 명시하는 청취 질의들을 사용하여 적어도 하나의 활동 메시지의 라우팅을 지원한다.

게다가, 본 발명의 바람직한 실시예에 따르면, 스트림 병합기는 데이터를 식별된 컨택과 연관되는 스트림에 병합하는 활동-대-스트림 병합기 및 적어도 2개의 별개의 스트림들을 단일 스트림에 병합하는 스트림-대-스트림 병합기를 포함한다.

더욱이, 본 발명의 바람직한 실시예에 따르면, 스트림-대-스트림 병합기는 식별된 공통 컨택에 따라 적어도 2개의 별개의 스트림들을 병합하는 수평 스트림 병합기, 그리고 익명의 컨택에 대하여 생성되는 스트림 및 등록된 컨택 사용자와 연관되는 스트림을 연결시킬 수 있는 등록 또는 로그인 시에 익명의 컨택에 대하여 생성되는 스트림을 등록된 컨택 사용자와 연관되는 스트림과 병합하는 수직 스트림 병합기 중 적어도 하나를 포함한다.

더더욱이, 본 발명의 바람직한 실시예에 따르면, 데이터 병합기는: 컨택 정보 기록들 중 적어도 2개에서 동일한 1차 ID 필드 값들의 위치를 찾고, 정규화될 때 동일한 컨택 정보 기록들 중 적어도 2개에서 1차 키 필드 값들의 위치를 찾고, 쿠키를 사용하여 사이트 사용자들을 식별하고, 등록된 사용자들에 대한 사이트 로그인을 사용하여 사이트 사용자를 식별하고 그리고 소셜 네트워크와 연관되는 계정을 가지는 사이트 사용자들에 대한 소셜 로그인을 통해 사이트 사용자를 식별하는 것 중 적어도 하나를 행하는 컨택 식별기 중 적어도 하나를 포함한다. 데이터 병합기는 또한 언어, 구문, 텍스트 분석 및 외부 데이터 소스들 및 서비스들에 대한 참고(consultation) 중 적어도 하나를 사용하여 컨택 정보를 통합하는 통합기, 컨택 기록들 사이의 불일치들을 미리 규정된 규칙들에 따라 해소하는 불일치 해소기(contradiction resolver); 컨택 기록들 사이의 명확한 우선순위를 규정하기 위한 목록 값 필드들을 생성하는 목록 값 생성기, 검출되는 공통 1차 ID로 인하여 2개의 관련되지 않은 컨택들을 병합하는 수평 컨택 병합기 및 익명의 컨택 및 등록된 사용자와 연관되는 컨택을 연결시킬 수 있는 등록 또는 로그인 시에 익명의 컨택을 등록된 사용자와 연관되는 컨택과 병합하는 수직 컨택 병합기를 포함한다.

추가로, 본 발명에 따른 바람직한 실시예에 따르면, 수평 컨택 병합기는 적어도 2개의 컨택 기록들을 별개로 유지하고 적어도 2개의 컨택 기록들이 동일한 컨택을 표현하는 것으로 표기되도록 적어도 2개의 컨택 기록들을 서로 링크하는 가상 병합기를 포함한다.

게다가, 본 발명의 바람직한 실시예에 따르면, 수직 컨택 병합기는 익명의 컨택 및 등록된 사용자와 연관되는 컨택을 별개로 유지하고 익명의 컨택 및 등록된 사용자와 연관되는 컨택이 동일한 컨택을 표현하는 것으로 표기되도록 익명의 컨택 및 등록된 사용자와 연관되는 컨택을 서로 링크하는 가상 병합기를 포함한다.

더욱이, 본 발명의 바람직한 실시예에 따르면, 사용자 허가 필드는 결정된 웹사이트 및 결정된 웹사이트 소유자 중 적어도 하나이다.

더더욱이, 본 발명의 바람직한 실시예에 따르면, 표준화된 포맷은 미리 규정된 스키마(schema), 상속(inheritance), 콜백(call back) 링크에 의해 규정되고, 적어도 하나의 제 3 자 애플리케이션에 의해 또는 외부 정규 산업상 또는 사실상 표준에 기초하여 규정되고 인코딩되는 것 중 적어도 하나이다.

본 발명의 바람직한 실시예에 따르면 적어도 하나의 프로세서를 가지는 클라이언트/서버 시스템을 통해 웹사이트 상에서 구현 가능한 방법이 제공되고, 프로세서는 방법을 규정하는 명령들을 프로세싱한다. 상기 방법은 웹사이트 및 적어도 하나의 제 3 자 애플리케이션 사이에서 적어도 하나의 활동 메시지를 조정하는 단계로서, 적어도 하나의 활동 메시지는 표준화된 포맷을 가지는, 조정하는 단계, 적어도 하나의 활동 메시지를 청취하고 적어도 하나의 메시지로부터 추출되는 데이터를 식별된 컨택 및 익명의 컨택 중 적어도 하나와 연관되는 스트림에 적어도 추가하는 단계로서, 식별된 컨택 및 익명의 컨택 중 적어도 하나는 웹사이트의 사용자인, 청취 및 적어도 추가하는 단계를 포함한다. 상기 방법은 또한 스트림으로부터 컨택 관련 정보를 검색하고 분석하고 그리고 컨택에 대해 이전에 보유된 정보를 강화하는 단계 및 웹사이트에 의해 그리고 컨택에 의해 사용되기 위해 활동 스트림들 및 컨택 관련 정보를 저장하는 단계를 포함한다.

게다가, 본 발명의 바람직한 실시예에 따르면, 조정하는 단계는: 적어도 하나의 활동 메시지를 웹사이트 및 적어도 하나의 제 3 자 애플리케이션 사이에서 라우팅하고 추적하는 단계, 웹사이트 및 적어도 하나의 제 3 자 애플리케이션 사이에서 개인정보 보호 정책을 시행하는 단계, 웹사이트 및 적어도 하나의 제 3 자 애플리케이션 사이에서 사전 명시되는 적어도 하나의 메시지 변환 및 컨텐츠 적응 규칙들을 적용하는 단계, 개인 데이터 프록시 및 개인 데이터 대체 중 적어도 하나를 구현하고 웹 사이트 및 적어도 하나의 제 3 자 애플리케이션 사이에서 사용자 허가 필드 제한들을 시행하는 단계 및 적어도 하나의 제 3 자 애플리케이션의 인입 키를 사용하여 적어도 하나의 활동 메시지의 서명을 검증하고, 내부 웹사이트 ID를 구비하는 적어도 하나의 활동 메시지와 연관되는 외부 ID를 변환하고 그리고 적어도 하나의 제 3 자 애플리케이션의 인출 키를 사용하여 인출되는 적어도 하나의 활동 메시지를 서명하는 단계 중 적어도 하나를 포함한다.

게다가, 본 발명의 바람직한 실시예에 따르면, 청취 및 적어도 추가하는 단계는: 적어도 하나의 활동 메시지와 연관되는 컨택을 식별하고 연관되는 컨택이 존재하지 않으면 데이터의 스트림을 생성하는 단계, 적어도 하나의 활동 메시지로부터의 데이터를 기존의 스트림에 그리고 활동 스트림들 중 적어도 2개로부터의 데이터를 단일 스트림에 병합하는 단계 및 활동 스트림으로부터의 활동 데이터를 적어도 하나의 데이터베이스 내로 로깅하는 단계 중 적어도 하나를 포함한다.

더욱이, 본 발명의 바람직한 실시예에 따르면, 검색 및 분석하는 단계는: 적어도 하나의 활동 메시지, 스트림, 다른 컨택들 및 외부 소스들 중 적어도 하나로부터 컨택 관련 정보를 추출하는 단계; 적어도 2개의 컨택 정보 기록들을 병합하고- 기록들은 동일한 식별된 컨택과 연관성을 가진다- 그리고 미리 규정된 병합 규칙들에 따라 추출된 컨택 관련 정보를 기존의 컨택에 대한 정보와 병합하는 단계 중 적어도 하나를 포함한다. 검색 및 분석 단계는 또한 식별 가능한 새로운 컨택 및 익명의 컨택 중 적어도 하나를 생성하고 웹사이트의 세션 동안 컨택 활동을 추적하는 단계 및 추출된 컨택 관련 정보의 프라이버시 보호 및 허가들을 처리하는 단계를 포함한다.

더더욱이, 본 발명의 바람직한 실시예에 따르면, 라우팅 및 추적하는 단계는 적어도 하나의 제 3 자 애플리케이션이 명시하는 청취 질의들을 사용하여 적어도 하나의 활동 메시지의 라우팅을 지원한다.

추가로, 본 발명의 바람직한 실시예에 따르면, 병합하는 단계는 데이터를 식별된 컨택과 연관되는 스트림에 병합하는 단계 및 적어도 2개의 별개의 스트림들을 단일 스트림에 병합하는 단계를 포함한다.

게다가, 본 발명의 바람직한 실시예에 따르면, 데이터를 식별된 컨택과 연관되는 스트림에 병합하는 단계 및 적어도 2개의 별개의 스트림들을 단일 스트림에 병합하는 단계는 식별된 공통 컨택에 따라 적어도 2개의 별개의 스트림들을 수평으로 병합하는 단계 및 익명의 컨택에 대하여 생성되는 스트림 및 등록된 컨택 사용자와 연관되는 스트림을 연결시킬 수 있는 등록 또는 로그인 시에 익명의 컨택에 대하여 생성되는 스트림을 등록된 컨택 사용자와 연관되는 스트림과 수직으로 병합하는 단계 중 적어도 하나를 포함한다.

게다가, 본 발명의 바람직한 실시예에 따르면, 적어도 2개의 컨택 정보 기록들을 병합하는 단계는: 컨택 정보 기록들 중 적어도 2개에서 동일한 1차 ID 필드 값들의 위치를 찾고, 정규화될 때 동일한 컨택 정보 기록들 중 적어도 2개에서 1차 키 필드 값들의 위치를 찾고, 쿠키를 사용하여 사이트 사용자들을 식별하고, 등록된 사용자들에 대한 사이트 로그인을 사용하여 사이트 사용자를 식별하고 그리고 소셜 네트워크와 연관되는 계정을 가지는 사이트 사용자들에 대한 소셜 로그인을 통해 사이트 사용자를 식별하는 단계 중 적어도 하나를 포함한다. 적어도 2개의 컨택 정보 기록들을 병합하는 단계는 또한 언어, 구문, 텍스트 분석 및 외부 데이터 소스들 및 서비스들에 대한 참고 중 적어도 하나를 사용하여 컨택 정보를 통합하는 단계, 컨택 기록들 사이의 불일치들을 미리 규정된 규칙들에 따라 해소하는 단계, 컨택 기록들 사이의 명확한 우선순위를 규정하기 위한 목록 값 필드들을 생성하는 단계, 검출되는 공통 1차 ID로 인하여 2개의 관련되지 않은 컨택들을 수평으로 병합하는 단계 및 익명의 컨택 및 등록된 사용자와 연관되는 컨택을 연결시킬 수 있는 등록 또는 로그인 시에 익명의 컨택을 등록된 사용자와 연관되는 컨택과 수직으로 병합하는 단계를 포함한다.

더욱이, 본 발명의 바람직한 실시예에 따르면, 수평으로 병합하는 단계는 적어도 2개의 컨택 기록들을 별개로 유지하기 위해 가상 병합하고 적어도 2개의 컨택 기록들이 동일한 컨택을 표현하는 것으로 표기되도록 적어도 2개의 컨택 기록들을 서로 링크하는 단계를 포함한다.

더더욱이, 본 발명의 바람직한 실시예에 따르면, 수직으로 병합하는 단계는 익명의 컨택 및 등록된 사용자와 연관되는 컨택을 별개로 유지하기 위해 가상 병합하고 익명의 컨택 및 등록된 사용자와 연관되는 컨택이 동일한 컨택을 표현하는 것으로 표기되도록 익명의 컨택 및 등록된 사용자와 연관되는 컨택을 서로 링크하는 단계를 포함한다.

추가로, 본 발명의 바람직한 실시예에 따르면, 사용자 허가 필드는 결정된 웹사이트 및 결정된 웹사이트 소유자 중 적어도 하나이다.

게다가, 본 발명의 바람직한 실시예에 따르면, 표준화된 포맷은 미리 규정된 스키마, 상속, 콜백 링크에 의해 규정되고, 적어도 하나의 제 3 자 애플리케이션에 의해 또는 외부 정규 산업상 또는 사실상 표준에 기초하여 규정되고 인코딩되는 것 중 적어도 하나이다.

본 발명으로 간주되는 특허 대상이 특히 언급되고 명세서의 종결부분에 명확하게 청구된다. 그러나 본 발명은 조직 및 동작의 방법 모두 및 이에 더하여 본 발명의 대상들, 특징들 및 장점들에 관해서, 다음의 상세한 설명을 참조함으로써 첨부 도면들과 함께 판독될 때 가장 양호하게 이해될 수 있다:
도 1은 웹사이트 구축 시스템 및 제 3 자 애플리케이션 사이의 배치 구성들의 개략적인 도면;
도 2는 제 3 자 애플리케이션 내부 컨텐츠 관리에 대한 개략적인 도면;
도 3은 서버 측 프로세싱을 통한 포함 웹 페이지 내의 제 3 자 애플리케이션 내포에 대한 개략적인 도면;
도 4는 클라이언트 측 프로세싱을 통한 포함 웹 페이지 내의 제 3 자 애플리케이션 내포에 대한 개략적인 도면;
도 5는 아이프레임 내포를 통한 포함 웹 페이지 내의 제 3 자 애플리케이션 내포에 대한 개략적인 도면;
도 6은 페이지 레이아웃 변경 동안 기존의 그리고 비 최적인 제 3 자 애플리케이션 디스플레이들에 대한 개략적인 도면;
도 7a 및 도 7b는 본 발명에 따라 구성되고 동작하는 하나 이상의 제 3 자 애플리케이션들 및 웹사이트 구축 시스템을 통합하는 시스템에 대한 개략적인 도면들;
도 8은 구성요소 모델과 비교되는 문서 객체 모델에 대한 개략적인 도면;
도 9는 샘플 다 부분(multi-part) 블로그 제 3 자 애플리케이션에 대한 개략적인 도면;
도 10은 샘플 모듈식 판매 제 3 자 애플리케이션에 대한 개략적인 도면;
도 11a 및 도 11b는 본 발명에 따라 구성되고 동작하는 통신 허브의 상이한 구현들에 대한 개략적인 도면들;
도 11c는 본 발명에 따라 구성되고 동작하는 도 11a 및 도 11b의 통신 허브의 요소들에 대한 개략적인 도면;
도 12는 본 발명에 따라 구성되고 동작하는 도 11a 및 도 11b의 통신 허브에 의해 수행되는 통신 변환(communication translation) 시나리오에 대한 개략적인 도면;
도 13은 본 발명에 따라 구성되고 동작하는, 연관 템플릿을 가지는 제 3 자 애플리케이션을 처리하는 포함 웹 페이지에 대한 개략적인 도면; 및
도 14는 본 발명에 따라 구성되고 동작하는, 미니 페이지 내에 연관 템플릿을 가지는 제 3 자 애플리케이션을 포함하는 포함 웹 페이지에 대한 개략적인 도면.
도 15는 본 발명에 따라 구성되고 동작하는, 하나 이상의 임베딩된 제 3 자 애플리케이션들 및 웹사이트 구축 시스템 사이에서 교환되는 상이한 메시지들로부터 데이터를 조정하고 수집하는 시스템에 대한 개략적인 도면;
도 16a, 도 16b, 도 16c 및 도 16d는 본 발명에 따라 구성되고 동작하는, 도 15의 시스템의 요소들에 대한 개략적인 도면들;
도 17은 본 발명에 따라 구성되고 동작하는, 컨택과 연관되는 활동 스트림(activity stream)을 디스플레이하는 샘플 그래픽 사용자 인터페이스(graphical user interface)에 대한 개략적인 도면;
도 18은 클라이언트 측 및 서버 측 제 3 자 애플리케이션 활동 메시지 전달에 대한 개략적인 도면; 및
도 19는 사용자 웹사이트 세션(session) 동안 로그인/로그아웃을 처리하는 것에 대한 개략적인 도면.
설명의 간소화 및 명료화를 위해, 도면들에 도시되는 요소들은 반드시 축적대로 도시되지 않았음이 인정될 것이다. 예를 들어, 요소들 일부의 치수들은 명료성을 위해 다른 요소들에 대해 과장될 수 있다. 더욱이, 적절하다고 간주되면, 참조번호는 대응하거나 유사한 요소들을 표시하기 위해 도면들 사이에서 반복될 수 있다.

다음의 상세한 설명에서, 본 발명에 대한 철저한 이해를 제공하기 위해 많은 특정한 세부사항들이 열거된다. 그러나, 당업자에 의해 본 발명이 이 특정한 세부사항들 없이 실시될 수 있음이 이해될 것이다. 다른 경우들에서, 널리 공지되어 있는 방법들, 절차들 및 구성요소들은 본 발명을 모호하게 하지 않도록 상세하게 기술되지 않았다.

출원인들은 제 3 자 애플리케이션들이 전형적으로 웹사이트 구축 시스템들에 통합되는 방식에서 그리고 통합된 제 3 자 애플리케이션들 및 웹사이트 구축 시스템들이 상호 작용하는 방식에서 현재의 방법들에 대한 많은 제한들이 있음을 인식하였다.

이 제한들은 제 3 자 애플리케이션 디스플레이가 포함 웹 페이지 내의 단일 직사각형의 에어리어(area)로 제한되고, 이 에어리어는 아이프레임 내에 포함되는 것을 포함한다. 이 제한들은 또한 제 3 자 애플리케이션이 자기 자신의 윈도우의 크기 및 위치뿐만 아니라 실제 제 3 자 애플리케이션 디스플레이 윈도우 외부에 있는 시각 요소들(예를 들어, 제 3 자 애플리케이션 윈도우 주위의 특화된 디스플레이 프레임들)을 제어할 능력을 포함한다.

제 3 자 애플리케이션은 자기 자신의 디스플레이 스타일들(컬러 배색들, 폰트들, 문자 크기들 등)을 가질 수 있다. 이 스타일들은 일부 포함 웹 페이지들에는 좋을 수 있으나 다른 포함 웹 페이지들에게는 시각적으로 문제가 되거나 부조화될 수 있다.

다른 제한은 포함하는 사이트의 관점에서 제 3 자 애플리케이션 디스플레이의 경직성(rigidity)이다. 이 사이트가 시각적으로 수정되어야 하면(예를 들어, 상이한 화면 크기를 가지는 플랫폼으로의 배치로 인해 또는 동적 레이아웃 이벤트로 인해), 포함 웹 페이지는 제 3 자 애플리케이션에 할당되는 윈도우의 크기를 변경할 필요가 있을 수 있다. 그와 같은 경우에, 제 3 자 애플리케이션 디스플레이는 클립(clip)될 수 있고 제 3 자 애플리케이션 내의 상이한 하위 에어리어들에 도달하기 위해 스크롤 바(scroll bar)들을 통해 스크롤링을 할 필요가 있을 것이다. 이제 포함 웹 페이지 [a]가 크기 조정되고, e-샵 제 3 자 애플리케이션 [b]에 할당되는 에어리어가 감소되고 "구매" 버튼 [c]이 쇼핑 카트 [d]의 컨텐츠와 함께 보여질 수 없을 때- 구매를 완료하는 데에 다수의 스크롤 행위들을 요구하므로 구매가 실제로 완료될 가능성을 아주 적게 만든다- 일어날 수 있는 것에 대한 하나의 예를 도시하는 도 6가 참조된다.

제 3 자 애플리케이션은 포함 웹 페이지 내의 다른 구성요소와 상호 작용할 수 없고 그와 같은 상호 작용은 때로는 복잡한 기능을 달성하는데 필요한 것임이 인정될 것이다. 특히, 제 3 자 애플리케이션이 포함 웹 페이지 내의 구성요소들의 유형 및 컨텐츠에 따라 상이하게 수행될 방법이 없다. 이의 하나의 예는 온라인 요리 강좌를 스트리밍하는 웹사이트일 수 있다. 사용자는 자신의 영화를 시청하는 배경에서, 자신의 화면의 작은 에어리어가 뉴스 피드에 전용되고 자신의 화면의 다른 에어리어에서 날씨가 업데이트되게(CNN으로부터의 라이브 스트림과 같은) 하고자 희망할 수 있다. 사용자는 자신의 거주 지역에 대한 날씨 리포트가 시작될 때 자신의 학습 섹션을 자동으로 일시정지하고자 희망할 수 있다.

특히 다수의 제 3 자 애플리케이션들이 상이한 벤더들에 의해 제공되는 경우, 이것들이 서로 협력하는 명확한 표준 방법 또한 존재하지 않는다. 그러므로, 설계자들은 상이한 벤더들로부터의 다수의 제 3 자 애플리케이션들을 결합하는 명확한 방법을 가지지 않는다. 이에 대한 하나의 예는 전자 상거래 웹사이트가 제 3 자 주문 시스템(ordering system)으로부터의 모듈을 운영하고 출하 시스템(shipping system)에 대한 상이한 모듈을 운영하는 경우이다. 출하 스케줄 등에 따라 공급물들을 주문하는 것이 바람직할 수 있다.

출원인들은 웹사이트 구축 시스템 및 이것 내에 포함되는 제 3 자 애플리케이션 인스턴스들 사이에 그리고 동일한 포함 페이지 내에서 구현될 수 있는 상이한 제 3 자 애플리케이션 인스턴스들 사이에 구조화된 2-웨이 통신(two-way communication) 채널들을 사용함으로써 이 통합이 달성될 수 있음을 인식하였다. 이 채널들은 또한 레이아웃, 스타일 및 추가 정보에 관한 정보를 전송할 수 있다.

아래의 논의는 아이프레임 내포 방법에 초점을 맞추고, 이 방법이 아이프레임이 현대의 브라우저들 내에 구축되고 통합되어 특수한 통합 코드의 생성을 요구하지 않으므로 바람직한 방법임이 인식될 것이다. 아이프레임 내포는 또한 브라우저 지원 캡슐화(encapsulation) 및 샌드박싱(sandboxing)뿐만 아니라 악성의 제 3 자 애플리케이션들에 의해 사용될 수 있는 크로스 사이트 스크립팅(cross-site scripting) 공격과 같은 해킹 기술들에 대한 내재적 보호를 제공할 수 있다.

이제 본 발명의 하나의 실시예에 따라, 하나 이상의 제 3 자 애플리케이션들 및 웹사이트 구축 시스템을 통합하는 시스템(100)을 도시하는 도 7a 및 도 7b가 참조된다. 도 7a는 설계 단계에서의 시스템(100)을 도시하고 도 7b는 런타임에서의 시스템(100)을 도시한다. 도 7a에서 확인될 수 있는 바와 같이, 시스템(100)은 클라이언트(10), 웹사이트 구축 시스템(website building system; WBS) 서버(20) 상에 설치되는 웹사이트 구축 시스템(30) 및 하나 이상의 제 3 자 애플리케이션 서버들(50) 상에 설치되는 하나 이상의 제 3 자 애플리케이션들(40)을 포함한다. 웹사이트 구축 시스템(30)은 WBS 조정기(coordinator)(21), 애플리케이션 리포지토리(22), WBS 측 TPA 특성 시트(23), 제 3 자 애플리케이션(third party application; TPA) 조정기(24) 및 앱스토어(25)(탐색기(26)를 포함할 수 있는)를 포함한다. 클라이언트(10)는 페이지 구성기(page composer)(12) 및 TPA 특성 시트(23)의 클라이언트 측 뷰를 포함한다. 일부 실시예들에서 클라이언트(10)는 또한 앱스토어(25)의 클라이언트 측 뷰를 포함할 수 있다. 페이지 구성기(12)는 본원 아래에서 더 상세하게 기술되는 링커(linker)(13)를 포함한다. 제 3 자 서버(50)는 제 3 자 애플리케이션(40), 외부 TPA 조정기(51) 및 사용을 위해 제 3 자 애플리케이션(40) 구성요소, 템플릿들 등을 저장하는 TPA 데이터베이스(52)를 포함한다. 시스템(100)은 다수의 제 3 자 애플리케이션(40) 벤더들에 속하는 다수의 제 3 자 서버들(50)을 포함할 수 있음이 주지된다.

속성들이 소정의 제 3 자 애플리케이션(40) 인스턴스에 대해 명시될 때 TPA 특성 시트(23)가 호출(invoking)될 수 있음이 인정될 것이다. 호출될 때, TPA 특성 시트(23)는 클라이언트(10) 상에 TPA 특성 시트(23)의 클라이언트 측 뷰로서 나타날 수 있음이 더 인정될 것이다. 또한 오프라인 실시예가 자신의 속성 시트를 설치된 클라이언트 소프트웨어의 일부로서 가질 수 있으므로 TPA 특성 시트(23) 또는 이의 리포지토리가 없을 수 있음이 더 인정될 것이다.

클라이언트(10) 측에 있는 설계자 또는 최종 사용자(5)는 웹사이트 페이지들 및 상호작용들(페이지 간(inter-page) 뿐만 아니라 페이지 내(intra-page))을 생성하기 위해 페이지 구성기(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)는 또한 포함되어 있는 제 3 자 애플리케이션들(40) 사이에 임의의 통신 채널들을 수동으로 지정하기 위하여(필요한 경우) 링커(13)를 사용할 수 있다. 링커(13)는 또한 설계자(5)가 구축되어 있는 포함 웹 페이지 그리고 본원에서 상술된 바와 같이 동시에 보이는 영화 및 CNN 뉴스 리포트와 같은 포함되어 있는 제 3 자 애플리케이션(40) 인스턴스들 사이의 임의의 특정한 통신 접속 및 규칙들을 명시하는 것을 가능하게 하는 것이 또한 인정될 것이다. 링커(13)에 의해 생성되는 링크는 웹 사이트 존속 기간을 통해 수정될 수 있음이 인정될 것이다.

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

링커(13)가 잠재적인 통신 채널들을 셋업(setup)할 능력을 제공하기 위하여, 제 3 자 애플리케이션(40)은 포함 웹 페이지(203) 내의 구성요소들(제 3 자 애플리케이션이 통신하고자 하는)- 다른 제 3 자 애플리케이션(40) 인스턴스들을 포함하는-을 적절하게 인식하고 식별할 필요가 있음이 인정될 것이다. 연관되는 템플릿(본원 아래에서 더 상세하게 기술되는)에 기초하는 구성요소들에 대해서는, 제 3 자 애플리케이션(40) 벤더에 의해 식별이 미리 수행된다. 연관되는 템플릿들 내의 구성요소들은 특정한 참조 ID들을 제공받을 수 있고 이 ID들은 이 구성요소들과 통신할 때 제 3 자 애플리케이션(40)에 의해 사용될 수 있다.

다 부분 제 3 자 애플리케이션(40)(본원에서 아래에서 더 상세하게 기술된다), 즉 다수의 아이프레임들에 걸쳐 펼쳐져 있는 단일 제 3 자 애플리케이션(40)의 경우, 다수의 부분들은 서로 통신하는 방법을 자동으로 인지할 수 있음이 더 인정될 것이다.

연관되는 템플릿에 포함되지 않는 포함 웹사이트 페이지 구성요소의 경우(본원 아래에서 더 상세하게 기술되는 바와 같이), 제 3 자 애플리케이션(40)은 자신이 기능할 수 있도록 존재해야만 하는 필요한 (강제적이고 선택적인) 포함 웹 페이지(203) 구성요소들의 목록을 포함할 수 있다. 이 목록은 특성 시트(23) 내에 저장되고 고유 ID들, 기술(description) 및 구성요소 세부사항들(예를 들어, 텍스트 구성요소이어야만 하는지, 블로그 토크백(talkback) 라벨로서 사용될 것인지)을 포함할 수 있다. 목록은 제 3 자 애플리케이션(40)이 앱스토어(25)에 진입한 것으로 세부화될 수 있고, 설계자(5)는 제 3 자 애플리케이션(40) 요건들에 부합하는 포함 웹 페이지(203)에 구성요소들(필드(field)들)을 명시하기 위하여 링커(13)를 사용할 수 있다. 웹사이트 구축 시스템(30)은 제 3 자 애플리케이션(40) 인스턴스가 생성될 때 빠진 포함 웹 페이지(203) 구성요소들을 동적으로 생성할 수 있고, 설계자(5)가 이후에 이것들을 이동하고, 크기 조정하고 그리고 충분히 명시하는 것을 가능하게 할 수 있음이 인정될 것이다.

대안으로, 웹사이트 구축 시스템(30)은 포함 웹 페이지(203)의 전체 또는 부분 구성요소 모델을 포함 웹 페이지(203)에 포함되는 제 3 자 애플리케이션(40)에 노출할 수 있다. 이는 구성요소 모델일 수 있고 포함 웹 페이지(203)의 문서 객체 모델(Document Object Model; DOM)이 아닐 수 있음이 인정될 것이다. 포함 웹 페이지(203) DOM은 구성요소 모델보다 훨씬 더 복잡하고 세분화되어 있을 수 있는데, 왜냐하면 실제 포함 웹 페이지(203)는 웹사이트 구축 시스템(30) 기반구조의 일부이거나 포함 웹 페이지(203) 구성요소들을 지원하는 수많은 HTML 요소들-숨겨져 있고 볼 수 있는 것 모두-을 포함할 수 있다. 구성요소 모델은 그러므로 아주 더 간단할 것이다.

이제 텍스트 구성요소 [a]가 다수의 HTML 구성(construct)들(외함(enclosing) div 태그 [b], 내부 div 태그 [c], 프레임 "미니 위젯들" [d1]..[d5] 등과 같은)을 사용하여 어떻게 구현될 수 있는가를 도시하는 도 8이 참조된다. 포함 웹 페이지(203)에 대한 DOM 모델 [e]는 이 하위 요소들의 각각의 요소별로 별개의 DOM 트리 노드(tree node)들을 포함할 수 있다. 구성요소 모델 [f]은 훨씬 더 간단하여, 단지 단일 구성요소 노드 [g]만을 포함할 수 있다.

시스템(100)이 또한 선택 구성요소 노출을 지원할 수 있음을- 설계자(5)가 링커(13)를 통해 어떤 구성요소들이 제 3 자 애플리케이션(40)에 노출되어야 하는지를 지정할 수 있고, 단지 이 구성요소들만이(가능하다면 이것들로 이어지는 "포함 경로(containment path)"를 포함하는) 제 3 자 애플리케이션(40)에 보일 수 있는 간소화된 구성요소 모델 내에 포함될 수 있음이 인정될 것이다. 이 상술한 바는 자신들의 유형 또는 임의의 다른 웹사이트 구축 시스템(30) 속성에 따라, 포함되는 구성요소들을 명시적으로 표기함으로써 수행될 수 있다. 제 3 자 애플리케이션(40)은 그 후에 포함 웹 페이지(203) 구성요소 모델을 검토하고 필요한 구성요소들의 위치를 찾아낼 수 있다.

포함 웹 페이지(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)으로부터 도출되는 인스턴스들)을 디스플레이하기 위하여 다수의 뷰 포트(view port)들(202)을 포함할 수 있음이 인정될 것이다. 클라이언트(10)는 또한 통신 허브(205)를 포함하여 통신을 증진시키고 그리고 관련된 포함 웹 페이지(203)에 어떠한 접속도 없이 호스팅된 제 3 자 애플리케이션들(40) 사이에 필요한 임의의 통신과 함께 포함 웹 페이지(203) 및 이것이 호스팅하고 있는 임의의 제 3 자 애플리케이션들(40) 사이에 백 채널(back channel)을 제공한다. 허브(205)의 기능은 본원 아래에서 더 상세하게 기술될 것이다.

허브(205)는 포함 웹 페이지(203) 및 임의의 제 3 자 애플리케이션(40) 내포들 모두가 볼 수 있는 웹 사이트의 상호 작용 부분들이고 이들의 통신은 클라이언트-서버 왕복에 의해 지연되지 않아야 하므로 클라이언트(10)에서 구현될 수 있음이 인정될 것이다. 대안의 실시예에서, 허브(205)는 제 3 자 애플리케이션 서버들(40)이 많은 데이터를 교환할 필요가 있고 이것들을 클라이언트(10)를 통해 라우팅(routing)하지 않는 것이 더 바람직한 경우에 웹사이트 구축 시스템 서버(20)에서 구현될 수 있다.

통신 허브(205)는 웹사이트 구축 시스템(30) 및 하나 이상의 제 3 자 애플리케이션들(40) 사이뿐만 아니라 다수의 제 3 자 애플리케이션들(40) 사이에서의 통신의 상이한 결합들을 지원할 수 있음이 인정될 것이다. 예를 들어, 허브(205)는 제 3 자 애플리케이션(40)이 웹사이트 구축 시스템(30)에게 주 사이트 내의 다른 페이지로 전환할 것을 요청하는 것을 가능하게 할 수 있다. 통신 허브(205)는 또한 제 3 자 애플리케이션(40)이 가능하면 포함 페이지의 레이아웃에 영향을 미치는 자기 자신의 윈도우의 크기를 조정할 것을 요청하는 것을 가능하게 할 수 있다. 이는 본원 아래에서 더 상세하게 기술되는 동적 레이아웃 처리를 통해 행해질 수 있다. 대안으로, 포함 웹 페이지(203)는 (예를 들어) 디스플레이에서 변경을 수용하기 위하여 상이한 버전으로의 전환이 필요하면 제 3 자 애플리케이션(40)이 상이한 버전으로 전환할 것을 요청할 수 있다. 이 2-웨이 통신은 또한 본원에서 상술한 바와 같이 제 3 자 애플리케이션(40) 구성요소 및 추가 정보를 디스플레이하는 제 3 자 애플리케이션(40)과 관련되는 웹사이트 구축 시스템(30) 구성요소 사이의 통신뿐만 아니라 다 부분 제 3 자 애플리케이션들(40) 및 모듈식 제 3 자 애플리케이션들의 요소들 사이의 통신이 개시되도록 할 수 있음이 인정될 것이다.

시스템(100)은 또한 온라인 및 오프라인 웹사이트 구축 시스템(30) 모두를 사용하여 구현될 수 있고 이는 클라이언트 측 요소들, 웹사이트 구축 시스템(30) 벤더 서버들, 제 3 자 애플리케이션(40) 벤더 서버들 및 다른 제 4 자 서버들과 같이, 호스팅 방법들의 임의의 결합을 사용할 수 있음이 더 인정될 것이다. 오프라인 실시예의 경우 본원에서 상술한 바와 같이 서버는 여전히 시스템(100)을 구현할 필요가 있을 수 있음이 인정될 것이다.

시스템(100)은 또한 큰 조직에 대한 사설 사이트 호스팅 배열과 같이 상이한 서버 세트(웹사이트 구축 시스템 벤더에 의해 운영되지 않는) 상에 호스팅될 수 있다.

시스템(100)은 또한 본원에서 상술한 바와 같이 제 3 자 애플리케이션(40)으로부터 제 3 자 애플리케이션(40) 인스턴스 포함 선택사양의 전체 색역(gamut)을 지원할 수 있다. 그러나, 시스템(100)은 또한 단지 이 선택사양들의 하위 세트를 지원할 수 있거나 또는 제 3 자 애플리케이션(40) 인스턴스 내포 가능성들에 대해 제한을 둘 수 있다.

시스템(100)은 또한 다 부분 제 3 자 애플리케이션들(40)을 구현할 수 있다. 다 부분 제 3 자 애플리케이션(40)은 다수의 디스플레이 영역들을 포함할 수 있고, 이 영역들의 각각은 별개의 아이프레임을 사용하여 처리된다. 이 영역들은 또한 본원에서 아래에 더 상세하게 기술되는 바와 같이 통신 허브(205)를 통해 협력할 수 있다(필요에 따라).

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

상술한 기능은 제 3 자 애플리케이션(40) 요소 디스플레이에 대해 아이프레임들을 사용함으로써 구현되어 아이프레임 기반 아키텍처의 캡슐화 및 보안 장점들을 획득할 수 있음이 인정될 것이다.

다 부분 제 3 자 애플리케이션들(40)의 구현에는 제 3 자 애플리케이션들(40)(자체의 아이프레임들 내부의)이 다양한 아이프레임들의 디스플레이를 제어할(예를 들어, 이것들의 시인성(visibility), 크기 및 위치) 수 있을 필요가 있음이 더 추가될 것이다. 통신 허브(205)는 본원 아래에서 더 상세하게 기술되는 바와 같이 이 디스플레이를 가능하게 할 수 있음이 더 인정될 것이다.

심지어 다 부분 제 3 자 애플리케이션(40)이 다수의 요소들 및 영역들로 구성(시각적으로)될 때에도, 이것은 여전히 구매(예를 들어, 앱스토어(25)에서), 설치, 구성 등의 측면에서 단일 제 3 자 애플리케이션(40)으로 간주되는 것 또한 인정될 것이다.

기존의 시스템들에서, 각각의 제 3 자 애플리케이션(40)은 별개의 실체로 간주될 수 있고 2개의 제 3 자 애플리케이션들(40)(동일한 벤더로부터 또는 이와는 달리 협력하는 벤더들로부터의) 사이의 임의의 협력은 개별 케이스를 기반으로 하여 즉석으로 전개되어야 한다. 시스템(100)은 또한 개별적으로 구매 및 설치될 수 있는 다수의 협력 하위 모듈들로 구성되는 모듈식 제 3 자 애플리케이션들(40)을 지원할 수 있음이 인정될 것이다.

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

제 3 자 애플리케이션(40) 모듈은 필요한 인터페이스를 강제적인 것으로(즉, 모듈은 이것들 없이 작업하지 않을 것이다) 또는 선택적인 것으로(즉, 모듈은 작업할 것이지만 감소하거나 수정된 기능을 제공할 수 있다) 지정할 수 있다. 그러므로, 각 인터페이스에 제공되는 파라미터들은: 인터페이스 고유 명칭; 인터페이스 기술(interface description) - 설계자(5)에게 보임으로써 이 설계자가 (예를 들어) 빠진 인터페이스들에 의해 처리되는 기능을 인지할 것이다; 강제/선택 상태; 인터페이스 파라미터 목록 및 유형이다. 각각의 제 3 자 애플리케이션 모듈은 여전히 별개의 아이프레임(또는 아이프레임들의 세트)에 상주하는 것이 인정될 것이다. 인터페이스의 동작은 본원 아래에서 더 상세하게 기술되는 통신 채널들에 기초한다.

제 3 자 애플리케이션(40) 모듈들은 웹사이트 설계 단계 동안 조립될 수 있음이 인정될 것이다. 웹사이트 구축 시스템(30)은 추가 제 3 자 애플리케이션(40) 모듈들이 추가될 때 인터페이스 참조변수(interface reference)들을 리졸빙(resolving)할 수 있고 - 여기서 새로운 제 3 자 애플리케이션(40) 모듈들은 기존의 필요한 인터페이스들을 리졸빙하고 가능하면 새로운 (리졸빙되지 않은) 필요한 인터페이스들을 추가한다.

설계자(5)는 강제적(및 선택적) 인터페이스들이 여전히 리졸빙되지 않은 동안에 완성된 웹 사이트를 편집 및 운영할 수 있음이 또한 인정될 것이다. 그러나, 설계자(5)는 모든 강제적 인터페이스들이 리졸빙될 때까지 생성되는 웹 사이트를 발행하지 않을 수 있고 그리고 이 설계자는 허브(205)가 여전히 리졸빙되지 않은 강제적 인터페이스들을 가지는 제 3 자 애플리케이션 모듈을 활성화하는데 필요할 수 있는 기능을 시도하면 이 설계자에게 프롬프트(prompt)가 행해질 것이다.

앱스토어(25)는 필요한 제 3 자 애플리케이션 모듈 인터페이스들을 리졸빙하는 제 3 자 애플리케이션 모듈들의 위치를 찾을 수 있는 탐색기(26)를 포함할 수 있음이 더 인정될 것이다. 탐색기(26)는 리졸빙되지 않은 인터페이스들에 기초하여 특정한 제 3 자 애플리케이션 모듈(들)을 탐색하거나 모든 제 3 자 애플리케이션 모듈들을 탐색할 수 있다. 탐색기(26)는 또한 현재 리졸빙되지 않은 인터페이스들에 대하여 또는 심지어 이미 리졸빙된 인터페이스들에 대하여 탐색할 뿐만 아니라 강제적, 선택적 또는 이 둘 모두의 유형들의 인터페이스들에 대하여 탐색할 수 있다. 탐색기(26)는 또한 특정한 제 3 자 애플리케이션이 리졸빙하지 않은 인터페이스들을 리졸빙하고 제한되고 특정한 제 3 자 애플리케이션 벤더들을 탐색하는 것으로 제한될 수 있음이 인정될 것이다. 탐색기(26)는 제 1 레벨 탐색을 수행하거나(즉, 모듈들은 현재 리졸빙되지 않은 인터페이스들을 만족시킨다) 또는 다중 레벨 탐색을(즉, 반복적인 탐색을 수행하여, 또한 이전 탐색 차례에 의해 발견된 제 3 자 애플리케이션 모듈들을 고려할 때 추가되는 리졸빙되지 않은 인터페이스들을 만족시키는 모듈들을 찾는) 수행할 수 있다.

시스템(100)은 어떤 빠진 인터페이스들을 진행하는 것에 대한 중요성에 대하여 설계자(5)에게 정보를 제공하기 위하여 인터페이스 기술들을 사용할 수 있다. 허브(205)는 여전히 통신할 필요가 있는 비호환 제 3 자 애플리케이션들 사이의 인터페이스 변환을 제공할 수 있다. 이는 웹사이트 구축 시스템(30) 제공자에 의해 또는 소정의 필요한 인터페이스를 상이한 포맷으로 적응시키는 외부 당사자에 의해 추가되는 어댑터 모듈(adapter module)에 의해 행해질 수 있다.

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

당업계에 공지되어 있는 표준 교차 도메인 통신 방법들이 교차 도메인 통신을 용이하게 하는 데 사용될 수 있음이 인정될 것이다. 이 방법들은 다음을 포함할 수 있다:

HTML5 PostMessage : 이는 안전한 교차 도메인 메시지를 제공하는 데 사용될 수 있는 표준 HTML5 특징이다. HTML5 Windows.Postmessage를 사용하면, 메시지들은 심지어 상이한 도메인들에 속할 때조차도, 윈도우들, 아이프레임들 및 주 HTML 문서 사이에서 안전하게 송신될 수 있다. PostMessage는 메시지가 송신될 도메인을 명시하기 위하여 송신 아이프레임에 대한 툴을 그리고 메시지가 송신되었던 도메인을 검증하기 위해 수신 아이프레임에 대한 툴을 제공한다.

메시지들에 대한 URL 부위 식별자(fragment identifier) : 이 방법은 하나의 종단점으로부터 다른 종단점으로 메시지 데이터를 송신하기 위하여 URL 부위 식별자를 사용하는 것에 의존한다. 데이터는 평이한 텍스트로 인코딩되고 목표 종단점 도메인 상에서 서비스를 또는 목표 종단점 아이프레임 내의 숨겨진 아이프레임을 호출하는 데 사용되는 URL에 추가된다(부위 식별자로서). 부위 식별자는 그 후에 목표 서비스 또는 아이프레임에서 코드에 의해 디코딩된다.

특화된 통신 웹 서비스 : 웹사이트 구축 시스템(30)은 웹사이트 구축 시스템 서버(20) 상에 호스팅되는 특화된 웹을 제공한다. 다양한 통신 종단점들은 이 서버에 접속되어 - 메시지를 송신하거나 또는 대기하고 있는 메시지들을 체크한다. 이는 기술들의 사전-HTML5 코멧 세트(Comet set),HTML5-기반 웹소켓(WebSocket)들 또는 임의의 다른 큐잉(queuing), 폴링(polling), 서버 푸쉬(server push) 또는 유사한 기술과 같이 당업계에 공지되어 있는 방법들을 통해 행해질 수 있다.

HTML5 로컬 스토리지(local storage) : HTML5는 큐잉된 메시지들을 저장하는 데 사용될 수 있는 구조화된 로컬 스토리지(local storage) 설비를 제공한다. 그러나, 로컬 스토리지는 단지 저장 아이프레임과 동일한 도메인에 속하는 웹 컨텐츠에 의해서만 액세스될 수 있다. 당업계에서는, 도메인-특정 로컬 스토리지가 외국 도메인에 기반하는 아이프레임들로부터 액세스되는 것이 가능하도록 하는 필요한 중간 아이프레임을 생성하기 위하여 작은 서버가 지원을 제공하는 Meebo XAuth 제품-현재 Google Inc.이 소유함-에 의해서 사용되는 기저의 기술과 같은 해법들이 개발되어 왔다.

HTML5 로컬 파일 시스템 액세스 애플리케이션 프로그래밍 인터페이스(Application Programming Interface; API)들 : 상술한 로컬 스토리지의 사용과 유사하게, 교차 아이프레임 통신 채널은 HTML5 파일 액세스 API들(File API, FileWirter API 및 FileReader API)을 통해 액세스되는 사용자 에이전트의 로컬 스토리지에 있는 로컬 파일들을 사용하여 구성될 수 있다. 그러나 HTML5 파일 시스템 액세스 API들에 의해 생성되는 샌드박싱된 로컬 파일 시스템은 여전히 개인-출처(origin-private)이므로 중간 아이프레임/서버 구성요소는 출처가 동일한 한계를 메우는 데 필요할 것임이 주지된다.

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

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

허브(205)는 또한 스마트 어드레싱 및 식별을 용이하게 하고, 통신 출처들을 검증하고, 통신 정책을 실시하고, 제 3 자 애플리케이션(40) 비 호환성 문제들을 해소하고 또한 제 3 자 애플리케이션(40)으로부터 구성요소들로 재시향시킬 수 있음이 또한 인정될 것이다. 허브(205)는 또한 본원 아래에서 더 상세하게 기술되는 바와 같이 포함 웹 페이지(203)에 행해지는 변경들에 기초하여 제 3 자 애플리케이션(40) 내의 레이아웃의 동적 업데이트들을 가능하게 할 수 있다.

이제 허브(205)의 상이한 구현 실시예들을 도시하는 도 11a 및 도 11b 및 허브의 상이한 요소들의 기능을 도시하는 도 11c가 참조된다.

허브(205)는 스마트 식별기(smart identifer) 및 어드레서(addresser)(310), 발신자 검증기(320), 통신 정책 시행기(330), 프로토콜 변환기(340), 재지향기(350), 동적 레이아웃 업데이터(360), 구성 관리자(370), 일반 업데이터(380) 및 호스팅식 애플리케이션 프로그래밍 인터페이스(API) 랩퍼(390)를 포함할 수 있다. 이 요소들의 기능은 본원 아래에서 상세하게 기술될 것이다. 모든 기능들은 제 3 자 애플리케이션(40) 대 웹사이트 구축 시스템(30) 채널 및 제 3 자 애플리케이션(40) 대 다른 제 3 자 애플리케이션(40)과 같이 모든 교차 도메인 통신 채널들에 적용 가능한 것이 인정될 것이다.

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

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

본원에서 상술한 바와 같이, 본원에서 상술한 모든 교차 통신 방법들에서, 아이프레임 어드레싱은 아이프레임의 출처(소스 도메인, 프로토콜 및 포트를 포함하는, 즉 메시지(수신자를 명시하는)를 송신할 때뿐만 아니라 메시지(수신자에 제공되는 송신자의 명칭으로서)를 수신할 때 직접 제 3 자 애플리케이션(40) 어드레싱을 사용하는)에 기초한다. 게다가 메시지 송신은 송신자가 목표 아이프레임 윈도우를 명시할 것을 요구한다(JavaScript의 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)의 다수의 인스턴스들을 포함할 수 있다. 예를 들어, 제품 지원 웹 사이트 내의 단일 페이지는 2개의 챗(chat) 제 3 자 애플리케이션(40) 인스턴스들-하나는 사용자 대 사용자 챗 및 포럼을 위한 것이고 하나는 구입 가능할 때 벤더의 지원부서 사람과 대화하는 데 사용되는 것-을 포함할 수 있다.

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

런타임 중에, 제 3 자 애플리케이션들(40)은 단지 허브(205)와만 통신하므로 단지 허브(205)의 직접 주소(direct address)를 알 필요가 있으며 어떤 다른 제 3 자 애플리케이션(40)의 직접 주소를 알 필요가 없음이 인정될 것이다. 이 하나의 직접 주소는 웹사이트 구축 시스템(30)에 의해 제 3 자 애플리케이션(40) 제공자에게 제공되는 통신 API 랩퍼(도 11a에 도시되는 바와 같이 통신 모듈들(f 및 g) 및 도 11b에 도시되는 바와 같이 통신 모듈들(a 및 b))에 의해 캡슐화될 수 있다. 호출하는 제 3 자 애플리케이션(40)은 애플리케이션 인지 제 3 자 애플리케이션(40) 기술 주소(descriptive address)들을 제공할 수 있고(상술한 바와 같이) 스마트 식별기 및 어드레서(310)는 이것들을 직접 제 3 자 애플리케이션(40) 주소들로 변환하고 라우팅을 수행할 수 있다. 이 방식에서, 제 3 자 애플리케이션(40)은 자신이 통신하는 모든 가능한 제 3 자 애플리케이션들(40)의 절대 주소들의 표를 유지할 필요가 없다.

메시지 발신자(originator) 검증은 매우 중요한데 그렇지 않으면 수신하는 제 3 자 애플리케이션(40)이 적대적인 제 3 자 애플리케이션(40)으로부터 메시지를 수신할 수 있음이 인정될 것이다. 모든 통신이 허브(205)를 통해 발생할 수 있으므로, 발신자 검증기(320)는 제 3 자 애플리케이션들로부터의 모든 인입하는 메시지들의 인증성(authenticity)을 체크할 수 있다. 발신자 검증기(320)는 또한 메시지에 추가될 수 있고 추가 검증에 사용될 수 있는 추가 정보를 제공할 수 있다. 웹사이트 구축 시스템(30)에는 앱스토어(25)에 포함되고 시스템(100)에 의해 사용되는 모든 제 3 자 애플리케이션(40)이 등록되므로, 허브(205)는 웹사이트 구축 시스템(30)에 의해 메시지에 포함될 수 있는 고유 발신자 ID가 메시지 출처(도메인, 포트 등)와 정합하는지를 검증할 수 있음이 인정될 것이다.

제 3 자 애플리케이션(40)은 외부 정보, 포함 웹 페이지(203) 정보 등에 좌우될 수 있는 일반 통신 정책을 규정할 수 있다. 통신 정책 시행기(330)는 해당 통신 정책이 비부합 통신을 처리할 필요 없이 시행되는 것을 보장할 수 있다. 예를 들어, 분류된 정보 처리 웹 사이트에서, 제 3 자 애플리케이션들은 자신들의 프로파일에 분류 레벨 필드로 태그(tag)될 수 있다. 분류 레벨 X로 인증되는 백-엔드(back-end) 이벤트 로깅 데이터베이스를 제공하는 제 3 자 애플리케이션(40)은 X보다 더 큰 분류 레벨을 가지는 로깅에 대한 이벤트들을 수용하지 않을 정책을 규정할 수 있다. 통신 정책 시행기(330)는 그와 같은 상황에서, 필요한 예비 필터링을 수행하고, 상위로 분류되는 메시지들이 심지어 더 낮은 분류 애플리케이션에 도달하는 것을 방지할 수 있다.

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

제 3 자 애플리케이션(40)이 메시지들을 송신하거나 다른 제 3 자 애플리케이션(40)(상술한 e-샵/과금 제 3 자 애플리케이션(40) 쌍)으로부터 메시지를 수신할 것을 요구하는 어떤 능력들을 가지는 것이 더 인정될 것이다. 그러나, 이 해법의 일부가 누락될 수 있는 일부 경우들에서, 상기 예에서, 정합하거나 적절한 주문 처리 제 3 자 애플리케이션(40)이 존재하지 않는 것이 발생할 수 있다. 그와 같은 경우에, 재지향기(350)는 설계자(5)가 소정의 메시지들이 포함 웹 페이지(203) 구성요소로 또는 포함 웹 페이지(203) 구성요소로부터 라우팅될 수 있고 그리고 정합 능력들이 포함 웹 페이지(203) 구성요소 및 구성요소들이 제공할 수 있는 기능에 의해 해소될 수 있음을 명시하는 것을 가능하게 할 수 있다. 이것은 특수목적의 제 3 자 애플리케이션(40)의 구성을 요구하지 않고 전체 웹 사이트를 구성하는 것을 가능하게 할 것이다. 그러므로, 트랜잭션(transaction)들은 트랜잭션을 데이터베이스로 로깅하는 것을 수행할 수 있는 웹사이트 구축 시스템(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)은 통신할 구성요소들을 다수의 방식들로: 연관되는 템플릿들에 기초하여 구성요소들에 대해 직접적으로(본원 아래에서 더 상세하게 기술됨); 설계자(5)에 의해 특정한 포함 웹 페이지(203) 구성요소들에 명시적으로 제공되는 액세스 ID를 통해; 포함 웹 페이지(203)에 의해 제 3 자 애플리케이션(40)에 제공되는 (가능하면 선택할 수 있는) 구성요소 모델을 고찰함으로써 식별할 수 있다.

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

업데이터(380)는 또한 웹사이트 구축 시스템(30) 구성요소들이 행할 수 있는 액세스의 유형을 이 구성요소들이 명시하는 것을 용이하게 할 수 있다- 액세스 허가 비트들 또는 액세스 제어 목록(access control list; ACL)들이 현대의 운영 시스템들에서 파일의 보호를 위해 기능하는 방식과 유사하다. 그와 같은 허가들은 모든 제 3 자 애플리케이션들(40)에 대해, 특정한 벤더들로부터 또는 특정한 제 3 자 애플리케이션들(40)에 대해 적용하도록 각 구성요소 별로 규정될 수 있다. 예를 들어, 제 3 자 애플리케이션(40)은 제 3 자 애플리케이션(40) 외부의 포함 웹 페이지(203)의 일부인 텍스트 필드에 액세스하는 것이 허용될 수 있다. 이 텍스트 필드는 블로그 엔트리를 블로그 제 3 자 애플리케이션(40)에 대하여 편집하여 블로그 제 3 자 애플리케이션(40) 에어리어 자체 내에 제공될 수 있는 것보다 더 많은 스크린 실면적을 제공하는 데 사용될 수 있다. 다 페이지 컨테이너 내의 특정한 미니 페이지들로 임베딩되는 제 3 자 애플리케이션들(40)의 경우에는, 웹사이트 구축 시스템(30)이 제 3 자 애플리케이션(40)의 액세스를 특정한 미니 페이지에만 있는 구성요소들로 제한할 수 있음이 인정될 것이다.

업데이터(380)는 제 3 자 애플리케이션(40)이 사이트 전역 요소들에 영향을 미치는 것이 가능하게 할 수 있음이 또한 인정될 것이다. 이것은 사이트 내의 현재의 페이지, 제 3 자 애플리케이션(40)을 포함하는 컨테이너 내의 현재의 미니 페이지 및 페이지 이력과 같은 속성들을 획득하고 세팅하는 것을 포함할 수 있다. 업데이터(380)는 또한 그와 같은 요청들을 필터링하거나 제한할 수 있다.

업데이터(380)는 또한 웹사이트 구축 시스템(30)이 제 3 자 애플리케이션(40)의 스타일 및 디스플레이에 영향을 미치는 것을 가능하게 할 수 있다. 업데이터(380)는 웹사이트 구축 시스템(30)이 제 3 자 애플리케이션(40)에 포맷팅 및 스타일 가이드라인을 제공할 수 있는 호출들을 구현할 수 있다. 이것들은 컬러들 및 컬러 스킴(color scheme)들; 폰트들, 문자 크기들; 투명도; 애니메이션 및 특수 효과들(예를 들어, 블러링(blurring))과 같은 특성들을 포함할 수 있다. 컬러 스킴은 특히 일반 컬러 스킴(예를 들어 다음의 x 컬러들의 사용) 또는 고레벨 컬러(예를 들어, 텍스트에 대해 컬러 x를 사용하고 프레임들에 대해 컬러 y를 사용)를 포함할 수 있다.

복잡한 스타일 정보를 표현하는 하나의 바람직한 방법은 폰트들, 크기들, 컬러들 등을 포함하는 다수의 스타일 지시들의 결합을 표현할 수 있는 연속형 스타일 시트(Cascading Style Sheet; CSS)들을 사용하는 것임이 인정될 것이다. 업데이터(380)는 그와 같은 CSS-기반 메시지들을 제 3 자 애플리케이션(40)에 송신할 수 있다. 스타일 시트들은 사실상 포괄적일 수 있거나 또는 웹사이트 구축 시스템(30)이 제 3 자 애플리케이션(40)에 더 양호한 가이드라인들을 제공할 수 있도록(예를 들어, 스타일 시트가 특정한 제 3 자 애플리케이션(40) 요소들을 언급하고 이들에 대한 가이드라인들을 제공할 수 있도록) 제 3 자 애플리케이션(40)에 의해 규정되는 특정한 스타일 명칭들을 포함할 수 있다.

제 3 자 애플리케이션(40)은 그 후에 자기 자신의 룩 앤 필(look and feel)을 포함 웹 페이지(203)에 더 양호하게 적응되도록 만들기 위해 이 가이드라인들을 사용한다. 이는 동일한 사이트(위에서 언급된 바와 같이 다 포트 내포) 내에 있는 다수의 포함 웹 페이지들(203)로부터 볼 수 있거나 포함되는 제 3 자 애플리케이션들(40)에 대해 특히 중요하다. 다수의 포함 페이지들은 상이한 컬러 스킴 또는 일반 설계를 이용한다. 제 3 자 애플리케이션(40)은 이 스타일 메시지들을 통해 자신에게 제공되는 정보를 사용하고 자기 자신의 디스플레이 컬러들 및 스타일을 각 포함 페이지에 더 양호하게 맞도록 적응시키고 그리고 포함 페이지와 비교해서 부조화하는 컬러 스킴들 또는 룩 앤 필을 디스플레이하는 것을 방지할 수 있다.

동적 레이아웃(dynamic layout, DL) 업데이터(360)는 동적 레이아웃 이벤트로부터 기인하는 디스플레이 변경들을 처리하는 데 웹사이트 구축 시스템(30)/제 3 자 애플리케이션(40) 또는 제 3 자 애플리케이션(40) 및 2차 제 3 자 애플리케이션을 협력하게 하는 것이 가능할 수 있음이 인정될 것이다. 웹사이트 구축 시스템(30)은 페이지 내의 구성요소들 중 일부를 변경하는 이벤트들 하에서 페이지 설계를 보존하기 위하여 페이지 내의 구성요소들의 크기 및 위치를 변경할 수 있다. 이 동적 레이아웃 이벤트들은 예를 들어: 상이한 크기들을 가지는 스크린들 상에서 웹사이트를 보고; 세로 및 가로 모드 사이에서 디스플레이 디바이스를 회전시키고; 구성요소들의 일부의 크기 또는 위치를 변경시키고 그리고 소정의 구성요소들의 컨텐츠를 변경시키는(구성요소들이 자신들의 크기를 변경할 필요가 있는 방식으로) 것을 포함할 수 있다. 동적 레이아웃 이벤트는 또한 서버 기반 컨텐츠 업데이트로부터 기인하거나 또는 동일한 웹사이트의 다른 동시 사용자들에 의한 컨텐츠 변경에 의한 구성요소 업데이트를 포함할 수 있다 - 예를 들어, 데이터 피드(data feed)로부터의 정보를 디스플레이하는 구성요소에서. 동적 레이아웃 이벤트들은 설계 환경뿐만 아니라 런타임 환경에서 발생할 수 있음이 또한 인정될 것이다. 특히 일부 구성요소들 및 제 3 자 애플리케이션들(40)은 런타임 동안 구성요소 컨텐츠 변경 또는 크기/위치 변경이 가능하다(최종 사용자에 의해, 그리고 단지 설계자들에 의해서만이 아닌).

동적 레이아웃 이벤트는 또한 제 3 자 애플리케이션(40)에 의해 발생될 수 있음이 또한 인정될 것이다. 예를 들어, e-샵 제 3 자 애플리케이션(40)은 사용자가 제품 카탈로그 뷰로부터 쇼핑 카트 뷰(상이한 크기를 가지는)로 이동할 때 크기 변경을 요구할 수 있다. 다른 예로서, 제품 카탈로그 제 3 자 애플리케이션(40)은 제품을 강조하는 선택사양을 포함할 수 있고, 이것은 그것들로 하여금 더 많은 컨텐츠를 포함하는 더 큰 카탈로그 페이지를 디스플레이하도록 할 것이다. 제 3 예는 추가 영역들을 디스플레이하기 시작하거나 중단할 수 있는 다 영역 제 3 자 애플리케이션(40)이다.

기존 시스템은 이제 다시 참조되는 도 6에 도시되는 바와 같이, 전형적으로 제 3 자 애플리케이션 디스플레이를 클립하거나, 스크롤 바들을 디스플레이에 추가하거나 또는 단지 디스플레이를 다른 페이지 구성요소들을 숨기는 팝업 창으로서 크기 조정함으로써 그와 같은 상황들을 처리한다(조금이라도). 동적 레이아웃 업데이터(360)는 웹사이트 구축 시스템(30) 및 제 3 자 애플리케이션들(40)이 동적 레이아웃을 수행하는 데 협력하고 포함 웹 페이지(203)의 기본 설계를 유지하는 협력 동적 레이아웃을 구현할 수 있다. 동적 레이아웃의 기능은 2013년 2월 20일에 제출되고 본 발명의 공동 양수인들에게 양도되어 있는 미국 특허출원 13/771,119에 더 기술되어 있다. 그러나, 협력 동적 레이아웃 지원 시스템에서조차도, 포함 웹 페이지(203)에서의 동적 레이아웃 메커니즘은 제 3 자 애플리케이션(40)의 내부 레이아웃 전체를 제어하지 않는다. 더욱이, 웹사이트 구축 시스템(30) 위젯(widget)들은 이것들이 어떤 임의의 크기(소정의 범위 내의)로 크기 조정될 수 있도록 설계될 수 있지만, 제 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)에 기초하여, 동적 레이아웃 프로세싱을 계속할 수 있다.

포함 웹 페이지(203) 내에 다수의 제 3 자 애플리케이션들(40)(또는 다 영역 제 3 자 애플리케이션들(40))이 있으면 특히 다른 실시예가 또한 적용 가능하다는 것이 인정될 것이다. 이 실시예에서 포함 웹 페이지(203)는 임베딩된 제 3 자 애플리케이션들(40)이 다수의 제 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들에 대하여 그 결과들을 Xfinal[i]/Yfinal[i]에 저장하고

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)는 또한 웹사이트 구축 시스템(30) 자체, 특정한 포함 웹 페이지(203) 또는 2차 제 3 자 애플리케이션(40)이 제 3 자 애플리케이션(40)에 영향을 미칠 수 있는 추가의 제 3 자 애플리케이션(40) 클래스 특정 또는 제 3 자 애플리케이션 특정 메시지들을 구현할 수 있음이 인정될 것이다. 예를 들어, 블로그 제 3 자 애플리케이션(40)은 새로운 블로그 엔트리 또는 새로운 토크-백을 현재의 블로그 엔트리에 포스팅할 수 있는 인입 메시지를 규정할 수 있다. 그와 같은 메시지는 포함 웹 페이지(203)에 의해 사용될 수 있다(예를 들어, 큰 편집 필드로부터의 블로그 엔트리들을 제 3 자 애플리케이션 에어리어의 외부에 포스팅하는 방식으로서). 이는 또한 더 상위 레벨의 애플리케이션 대 애플리케이션 링크에 사용되어, 예를 들어, 지원 제 3 자 애플리케이션이 블로그 엔트리들을 블로그 제 3 자 애플리케이션에 포스팅하는 것이 가능해질 수 있다.

제 3 자 애플리케이션들(40)은 흔히 광범위한 복합 서비스들을 필요로 하는 것이 인정될 것이다 - 제 3 자 애플리케이션(40) 내부 사용을 위해 또는 자신들의 사이트들에서 제 3 자 애플리케이션(40)을 사용하는 설계자들에 의해 다운스트림에서의 사용을 위해. 그와 같은 서비스들은 사용자 관리, 과금 및 출하 관리를 포함할 수 있다. 웹사이트 구축 시스템(30) 벤더는 그와 같은 서비스들을 웹사이트 구축 시스템의 일부로서 제공하는 것이 가능하지 않을 수 있다(예를 들어, 기술적 또는 사업적인 고려사항들로 인해). 더욱이, 이 서비스들은 자신들만으로 제 3 자 애플리케이션(40)으로서 "패키지화"하는 데 적합하지 않을 수 있다. 게다가, 제 3 자 애플리케이션(40) 벤더는 제 3 자 애플리케이션(40)을 사용하는 설계자들에게 다수의 그와 같은 서비스들(예를 들어, 다수의 제 3 자 과금 API들)을 제공하고 - 그리고 설계자(5)가 자신이 사용하는 데 적합한 것을 선택하는 것을 가능하게 하는 선택사양을 필요로 할 수 있다.

예를 들어, Paypal^TM이 호스팅하는 API는 웹사이트 구축 시스템(30) 내에 제공될 수 있고 제 3 자 애플리케이션(40)에 의해 직접 사용될 수 있거나 이를 사용하여 제 3 자 애플리케이션(40)에 의해 설계자들(5)에게 제공될 수 있다. 제 3 자 애플리케이션(40)은 또한 자기 자신의 선택사양들의 세트를 제공하고(즉, 일시불, 반복 또는 세입 교부와 같은 특정한 과금 유형을 사용), 그리고 호스팅된 Paypal API를 호출함으로써 이 선택사양들을 구현할 수 있다.

그러므로, 웹사이트 구축 시스템(30)을 사용하는 설계자(5)는 진화된 과금을 사용하는 특정한 오퍼링(offering)(노래-판매 e-스토어와 같은)을 개발할 수 있다. 개발자(5)는 호스팅되는 과금 API를 사용함으로써 과금 API 제공자와 특정한 승인 또는 가맹점 계약을 협상해야 하는 것을 피할 수 있다- 직접적으로 또는 추가 추상 레벨(abstraction level)(또는 층(layer))을 제공하는 제 3 자 애플리케이션(40)을 통해. 이 의미에서, 웹사이트 구축 시스템(30)은 호스팅된 API 벤더들에 대한 배포자가 될 수 있다.

호스팅된 API 랩퍼(390)는 시스템의 상이한 부분들(예를 들어, 웹사이트 구축 시스템(30), 호스팅된 API 코드 및 포함되는 제 3 자 애플리케이션들(40)) 사이의 이 통신을 용이하게 할 수 있다. API 랩퍼 층 및 실제 API 구현은 웹사이트 구축 시스템(30) 자체 또는 다른 제 3 자 애플리케이션(40) 내에 상주할 수 있음이 인정될 것이다. 제 3 자 애플리케이션(40) 벤더(또는 설계자(5))는 실제 기저의 API가 구현되는 방식을 인지하지 않고 호스팅된 API 랩퍼(390)를 통해 호스팅된 API를 사용할 수 있다.

본 발명의 대안 및 상보적인 실시예에서, 출원인들은 또한 웹사이트 구축 시스템(30) 및 하나 이상의 제 3 자 애플리케이션들(40) 사이에서의 스마트 통합이 또한 추가 웹사이트 구축 시스템 테블릿들 및 구성요소들이 앱스토어(25)의 레벨에 있는 제 3 자 애플리케이션들 뿐만 아니라 관련되는 제 3 자 애플리케이션 인스턴스들과 연관되는 통합 모델을 사용함으로써 달성될 수 있음을 인식하였다. 제 3 자 애플리케이션(40)은 또한 데이터 및 제어 메시지들을 교환하기 위하여 이 구성요소들(뿐만 아니라 비연관된 구성요소들)과 통신할 수 있다. 본원에서 상술한 바와 같이, 포함 웹 페이지(203) 내의 제 3 자 애플리케이션 영역들(40)은 자체의 컨텐츠가 별개의 도메인들(제 3 자 애플리케이션 벤더들 또는 기타)-주 사이트가 호스팅되는 도메인과 상이한-에 호스팅되는 별개의 아이프레임들이다. 그러므로, 상이한 아이프레임들 사이의 통신은 브라우저의 "동일한 원래의 정책"의 대상이 되고 본원에서 상술한 바와 같은 기술들을 사용할 것을 요구한다.

기존 시스템들은 제 3 자 애플리케이션들(40)을 포함 웹 페이지(203)에 포함되거나 그렇지 않으면 포함 웹 페이지(203) 자체의 룩 앤 필에 영향을 미치지 않은 강성 객체(rigid object)들인, 모노리식(monolithic)으로 구현한다. 제 3 자(40) 인스턴스는 (전형적으로 직사각형인) 에어리어 내에 배치되고 이 에어리어 내에서 자체의 활동들 모두를 수행한다.

출원인들은 이 개념이 본 발명의 하나의 실시예에 따르면 연관 템플릿으로 칭해지는, 제 3 자 애플리케이션(40)과 연관되는 (선택사양인) 추가 웹사이트 구축 시스템(30) 템플릿을 가짐으로써 확장될 수 있음을 또한 인식하였다. 이 연관은 제 3 자 애플리케이션(40)의 개발 및 발행 중에 수행될 수 있고 설계자(5)에게 제 3 자 애플리케이션(40) 선택/구매 프로세서(앱스토어(25)로부터의) 및 제 3 자 애플리케이션(40) 인스턴스 생성의 일부로서 제공될 수 있음이 인정될 것이다. 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)가 이를 오버라이딩(overriding)할 수 있도록 한다.

설계자(5)는 템플릿 [c]로부터 상속되는 구성요소들 [d] 및 [e]의 [f]의 인스턴스들을 수정할 수 있음이 더 인정될 것이다. 변경들은 단지 [f] (및 가능한 경우 페이지 간 상속을 지원하는 웹사이트 구축 시스템(30)으로부터 상속되는 페이지들) 내의 [d] 및 [e]의 사용에만 적용될 수 있으나 앱스토어 [b]에 있는 제 3 자 애플리케이션 [a]와 연관되는 "원" 템플릿 [c]에 영향을 미치지 않을 수 있다.

위의 [d] 및 [e] 인스턴스들에 대한 변경들은: 특히 특정한 컨텐츠(텍스트, 이미지들 등)를 필드 인스턴스들에 할당하는 것을-이뿐만 아니라 정규 속성 변경들- 포함할 수 있음이 인정될 것이다. 제 3 자 애플리케이션(40)이 미니 페이지 내부에 포함되면, 연관 템플릿은 제 3 자 애플리케이션(40)이 이제 참조되는 도 14에 도시되는 바와 같이 포함되는 특정한 미니 페이지에 적용되는 것이 더 인정될 것이다. 도시되는 바와 같이, 제 3 자 애플리케이션(40)은 미니 페이지 [x] 내에 포함되므로 구성요소들 [d] 및 [e]는 [x]에 추가되지만 동일한 다 페이지 컨테이너 [g]의 추가 미니 페이지들 [y] 및 [z]에 추가되지 않는다.

섹션 형 미니 페이지들의 경우, 연관 템플릿(만일 있다면)이 제 3 자 애플리케이션(40)을 포함하도록 생성되는 가상(및 비어 있는(empty)) 포함 웹 페이지(203)에 적용되는 것이 더 인정될 것이다.

대안의 실시에에서, 미리 생성되어 있는 연관 템플릿은 포함하고 있는 포함 웹 페이지(203)에 "병렬인" 새로 생성되는 페이지 또는 미니 페이지에 적용될 수 있다. 이 새로 생성되는 페이지 또는 미니 페이지는 템플릿으로 초기화될 수 있고, 이는 그 후에 원하는 바에 따라 수정될 수 있다.

웹사이트 구축 시스템(30)은 또한 다 포트 내포를 가능하게 할 수 있다 - 여기서 동일한 제 3 자 애플리케이션(40) 인스턴스는 주 사이트의 다수의 페이지들로부터 보일 수 있고 이 다수의 페이지들에 "상주한다". 이것은 주 사이트에서의 소정의 제 3 자 애플리케이션(40)의 다수의 내포-제 3 자 애플리케이션(40)의 다수의 인스턴스들을 생성하는-와 상이할 수 있다. 제 3 자 애플리케이션(40) 컨텐츠-인스턴스에 특정한-는 그러므로 동일한 다 포트 제 3 자 애플리케이션(40)의 다수의 뷰들 사이에서 공유된다.

그와 같은 다 포트 내포에서, 연관 템플릿은 제 3 자 애플리케이션(40) 인스턴스가 추가되는 페이지들 및 미니 페이지의 각각에 별개로 적용될 수 있다.

본원에서 상술한 바와 같이, 시스템(100)은 포함 웹 페이지(203) 내의 구성요소들과 제 3 자 애플리케이션(40) 사이에 2-웨이 통신 링크를 제공할 수 있다. 이것은 제 3 자 애플리케이션으로부터의 연관 템플릿의 병합으로부터 발생되는 포함 웹 페이지(203) 구성요소들뿐만 아니라 어떠한 그러한 연관 템플릿과도 관련없는 구성요소들을 포함하는 것이 인정될 것이다.

그러므로, 제 3 자 애플리케이션(40) 벤더가 전형적으로 벤더에 의해 제작되는 제 3 자 애플리케이션들(40)과 연관되는 다수의 템플릿들을 생성할 수 있음이 인정될 것이다. 이 템플릿들은 실제로 배포되고 있는(즉, 현재 배포되어 있는 제 3 자 애플리케이션 버전들과 연관되어 있는) 템플릿들 외에 테스트, 개발 및 다른 템플릿들을 포함할 수 있다.

본원에서 상술한 바와 같이, 제 3 자 애플리케이션(40)은 앱스토어(25)를 통해 배포될 수 있고 또한 웹사이트 구축 시스템(30) 벤더와 관련되지 않거나 이 벤더에 의해 관리되는 대안의 채널들을 통해 배포될 수 있다. 그러나, 제 3 자 애플리케이션(40)으로 배포되는 연관 템플릿들은 애플리케이션 리포지토리(22)와 고도로 관련되거나 이 리포지토리와 결합될 수 있는데, 왜냐하면 그것들은 웹사이트 구축 시스템(30)에 의해 관리되는 구성요소들, 베이스 템플릿들 및 다른 요소들을 사용하여 구축되기 때문이다.

더욱이, 그와 같이 별개로 배포되는 연관 템플릿의 기저를 이루는 웹사이트 구축 시스템(30) 요소들은 수정 또는 삭제되어야만 할 수 있다 - 가능하다면, 연관 템플릿을 "깬다". 이 문제를 해소하기 위하여, 시스템(100)은 이 연관 템플릿들을 애플리케이션 리포지토리(22) 내부의 별개의 에어리어(가능하다면 제 3 자 애플리케이션(40) 벤더 당)에 구현할 수 있다. 웹사이트 구축 시스템(30)은 다른 웹사이트 구축 시스템(30) 템플릿들과 동일한 방식으로 이 템플릿들을 관리할 수 있다.

제 3 자 애플리케이션(40) 벤더에게는 생성되는 각 템플릿 별로 고유 ID(개발 ID)가 제공될 수 있고 이 제 3 자 애플리케이션(40)은 제 3 자 애플리케이션(40) 개발 및 테스트 프로세스 동안 이 ID를 사용할 수 있음이 또한 인정될 것이다. 일단 제 3 자 애플리케이션(40)이 발행/배포될 수 있으면, 제 3 자 애플리케이션(40) 벤더는 대안의 고유 ID(발행 ID)를 신청하고 수신할 필요가 있고 발행된 제 3 자 애플리케이션(40)에서 이를 참조할 수 있다. 일단 발행 ID가 제공되면, 별개의 잠긴 템플릿의 카피(locked copy)가 생성된다. 이것은 제 3 자 애플리케이션(40)에 의해 참조되고 제 3 자 애플리케이션(40)의 인스턴스들을 생성할 때 사용되는 카피이다. 이 방식에서, 제 3 자 애플리케이션(40) 벤더는 "기능을 하는(live)" 제 3 자 애플리케이션(40)(설계자들에 의해 포함되어 있는)과 연관되는 템플릿을 실수로 수정할 수 없고 참조 온정성(integrity)이 보전된다. 더욱이, 시스템(100)은 그와 같은 잠긴 템플릿들 및 기저의 구성요소들 및 베이스 템플릿들 사이의 관계를 상호 참조할 수 있다. 이 상호 참조는 예를 들어, 그와 같이 잠겨 있는 템플릿에 포함되는 베이스 템플릿 또는 웹사이트 구축 시스템(30) 구성요소가 수정되어야 하는 경우(그리고 그와 같은 수정이 어떤 방식으로 템플릿 또는 제 3 자 애플리케이션(40)을 깰 수 있는 경우) 웹사이트 구축 시스템(30) 스태프에 경고를 제공하는 데 사용될 수 있다.

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

본원에서 상술한 바와 같이, 통신 허브(205)는 통신을 증진시킬 수 있고 포함 웹 페이지 및 임의의 제 3 자 애플리케이션들(40) 사이의 백 채널(back channel)을 제공할 수 있다. 출원인들은 포함 웹 페이지 및 임의의 제 3 자 애플리케이션들(40) 사이에서 역방향으로 그리고 순방향으로 흐르고 있는 데이터가 일단 수집되고, 프로세싱되고 통합되면 유용할 수 있음을 더 인식하였다.

예를 들어, 웹 사이트 소유자들은 관련 웹사이트 구축 시스템(30)의 등록된 사용자 베이스와 구분될 수 있는 자신들의 사이트당 사용자 집단(population) 또는 회원들을 관리할 필요가 있다. 웹 사이트 사용자들은 등록될 수 있거나 아닐 수 있고(익명) 웹사이트는 상이한 레벨들의 사용자들에 상이한 레벨들의 능력들을 제공할 수 있다. 더욱이, 사용자들은 흔히 자신들이 사이트 소유자와 컨택하기 위하여 인스턴트 메신저 소프트웨어를 활성화할 때 또는 자신들이 사이트와 협업하는 것의 일부로서 소셜 네트워크에 접속할 때 데이터와 같은 개인 또는 컨택 정보(심지어 익명의 사용자들과 같은)를 컨택 폼으로 제공할 수 있다. 이 정보는 생성되는 사이트 내로 직접 입력될 수 있거나 사이트 내에 임베딩되는 제 3 자 애플리케이션들(40)과의 상호 작용의 일부로서 이용 가능하게 만들어질 수 있음이 인정될 것이다.

이 정보 부분들은 비조직화되고, 비상관되고, 잠재적으로 불일치되고 여러 번 전혀 저장되지 않을 수 있음이 더 인정될 것이다. 예를 들어, 단일의 소정의 사용자는 자신의 개인 이메일을 컨택 폼(contact form)(사이트에 의해 직접 운영되는)에 입력하고 자신의 업무용 이메일을 동일한 세션 내의 별개의 구독 폼(subscription form)(제 3 자 애플리케이션(40)에 의해 운영되는)에 입력할 수 있다.

더욱이, 상기 정보의 "유동적인" 부분들은 자체의 사용을 위하여 상이한 허가들을 포함할 수 있다. 예를 들어, 구독 폼(subscription form)에 자신들의 이메일 주소를 채우는 사용자들은 자신들이 구독했던 이메일 기반 구독 및 가능하다면 관련 이메일 뉴스레터들을 수신할 것을 전적으로 기대한다. 한편, 이메일 주소를 등록 ID로서 공급하는 사용자는 자신의 계정 처리, 보안 경보 등과 관련되는 이메일들을 제외하고 자신의 등록 주소에 어떠한 이메일들도 수신하는 것을 희망하지 않을 수 있다.

이제 웹사이트 구축 시스템(30) 및 하나 이상의 임베딩된 제 3 자 애플리케이션들(40) 사이에서 교환되는 상이한 메시지들로부터의 데이터를 조정하고 수집하는 시스템(200)을 도시하는 도 15가 참조된다. 시스템(200)은 클라이언트(220)에 설치되는 클라이언트 허브(210) 및 서버(260)에 설치되는 서버 허브(230), 컨택 조정기(240), 활동 조정기(250), 컨택 데이터베이스(245) 및 활동 스트림 데이터베이스(255)를 포함한다. 허브들(210 및 230)이 웹사이트 구축 시스템(30) 및 서버들(270)에 설치되는 다수의 제 3 자 애플리케이션들(40) 사이 그리고 허브(205)와 관련하여 본원에서 상술한 바와 같이 상이한 제 3 자 애플리케이션들(40) 사이의 통신을 용이하게 할 수 있음이 인정될 것이다. 컨택 데이터베이스(245) 및 활동 스트림 데이터베이스(255)는 본원 아래에서 더 상세하게 기술되는 바와 같이 메시지 스트림들로 추출되는 정보 및 컨택/활성 정보를 보유할 수 있다.

이제 클라이언트 허브(210)의 요소들을 도시하는 도 16a 및 서버 허브(230), 컨택 조정기(240) 및 활동 조정기(250)의 요소들을 도시하는 도 16b가 참조된다. 클라이언트 허브(210)는 라우터(211), 변환기 및 어댑터(212) 및 개인정보 보호 정책 시행기(213)를 포함한다. 서버 허브(230)는 라우터 및 트랙커(231), 변환기 및 어댑터(232), 개인정보 보호 정책 시행기(233), 개인 데이터 프록시(234) 및 검증기 및 서명기(235)를 포함한다. 컨택 조정기(240)는 데이터 추출기(241), 컨택 처리기(242), 데이터 병합기(243) 및 데이터 및 허가 처리기(244)를 포함한다. 활동 조정기(250)는 스트림 생성기(251), 스트림 병합기(252) 및 로그 생성기(253)를 포함한다. 이 요소들의 기능은 본원 아래에서 더 상세하게 기술된다.

이제 스트림 병합기(252)의 요소들을 도시하는 도 16c 및 데이터 병합기(243)의 요소들을 도시하는 도 16d가 참조된다. 스트림 병합기(252)는 활동-대-스트림 병합기(261) 및 스트림-대-스트림 병합기(262)를 포함한다. 스트림-대-스트림 병합기(262)는 수평 스트림 병합기(263) 및 수직 스트림 병합기(264)를 더 포함한다. 데이터 병합기(243)는 컨택 식별기(272), 통합기(273), 불일치 해소기(274), 목록 값 생성기(275), 수직 컨택 병합기(276) 및 수평 컨택 병합기(277)를 포함한다. 수평 컨택 병합기(277)는 가상 수평 병합기(278)를 더 포함한다. 수직 컨택 병합기(276)는 가상 수직 병합기(279)를 더 포함한다. 이 요소들의 기능은 본원 아래에서 더 상세하게 기술된다.

시스템(200)은 본원 아래에서 상세하게 기술되는 바와 같이 스트림들에 의한 활동 메시지 조직, 활동 메시지 이력들의 저장, 다중레벨 활동 메시지 전달, 활동 메시지들에 대한 측 채널들의 사용, 활동 메시지 변환 및 컨텐츠 적응, 활동 메시지 검증 및 서명 및 청취자 질의들을 사용하는 동적 활동 메시지 라우팅을 포함하는 다양한 능력들을 제공하면서 시스템(200) 및 다수의 제 3 자 애플리케이션들(40) 사이에서 메시지를 전달하는 것이 가능할 수 있음이 인정될 것이다.

더욱이, 시스템(200)은 사용자 관련 정보를 추출하고 이를 병합할 수 있다- 다수의 소스들로부터의 정보뿐만 아니라 시스템(200)에 이미 존재하고 있는 정보를 통합. 이는 이종의(disparate) 그리고 가능하면 불일치 정보를 조화(reconcile)시키는 병합 규칙들을 통해 행해질 수 있다. 통합된 정보는 컨택 데이터베이스(245)에 저장될 수 있다. 이 정보는 또한 본원 아래에서 더 상세하게 설명되는 바와 같이 수집된 정보의 허용된 사용을 제어하는 사용 허가 필드들을 포함할 수 있다.

본 발명에 대한 대안의 실시예들에서, 클라이언트 허브(210) 및 서버 허브(230) 이 둘 모두만이 서버들(270)에 설치되는 다수의 제 3 자 애플리케이션들(40)과 통신하는 데 사용될 수 있다. 클라이언트 허브(210)만이 사용되는 상황에서, 컨택 조정기(240), 활동 조정기(250)는 데이터베이스들(245 및 255)과 함께 관련 클라이언트에 국지적으로 설치될 수 있음이 인정될 것이다.

시스템(200)은 사용자들 자신에 의해 세팅되는 사용 제한들을 시행하면서 제 3 자 애플리케이션들(40)이 사용자가 컨택하는 활동들(예를 들어, 뉴스레터들의 대량 메일링(mailing))을 관리하는 것을 가능하게 하는 추가의 구성요소들을 포함할 수 있음이 더 인정될 것이다. 그와 같은 구성요소들은 심지어 사용자 개인 데이터를 제 3 자 애플리케이션들(40)로부터 격리할 수 있다 - 제 3 자 애플리케이션들(40)이 개인 사용자 데이터에 실제로 액세스하지 않고 자신들의 행동들을 수행할 수 있도록. 그와 같은 능력은 예를 들어, 본원 아래에서 더 상세하게 기술되는 바와 같이 개인 데이터 프록시(234)를 사용하여 구현될 수 있다.

컨택 데이터베이스(245)는 각각의 사이트에 특정될 수 있음이 또한 인정될 것이다. 그러나, 웹사이트 구축 시스템(30)은 웹 사이트들(동일한 사이트 소유자에 의해 소유되는)의 모음(collection)을 담고 있는 메타 사이트(meta site)/프로젝트(project) 레벨을 규정하고 단일 사이트 레벨보다는 오히려 메타 사이트 레벨에서 컨택들이 저장되고, 처리되고 병합되는 것을 명시하는 것이 가능할 수 있다. 다른 사이트 요소들(포함되어 있는 제 3 자 애플리케이션들(40)과 같은)은 또한 사이트 레벨보다는 오히려 메타 사이트에서 규정될 수 있다. 메타 사이트 지원 이외에, 시스템(200)은 전형적으로 컨택들을 공유하지 않거나(아래에서 기술되는 바를 예외로 하고) 또는 상이한 사이트들 또는 상이한 사이트 소유자들 사이의 컨택 정보를 통합하지 않을 수 있다(소정의 최종 사용자에 의해 하나의 사이트에 제공되는 데이터가 다른 사이트에 누출되지 않도록).

본원에서 상술되는 바와 같이, 시스템(200)은 웹사이트 구축 시스템(30) 및 하나 이상의 제 3 자 애플리케이션들(40) 사이의 다수의 상호 작용들을 지원할 수 있다. 그와 같은 상호 작용들은 구매를 행하고, 아이템을 쇼핑 카트에 추가하고, 컨택 정보를 채우는 것 등과 같은 미리 규정된 활동들일 수 있다. 제 3 자 애플리케이션(40)은 자신이 어떤 활동들을 지원할지를 명시할 수 있고 다른 제 3 자 애플리케이션들(40)은 특정한 활동들을 "청취"할 수 있고 수신된 활동들 및 이들과 연관되는 정보에 근거하여 행동할 수 있다. 소정의 제 3 자 애플리케이션(40)에 대해 청취되는 활동들의 목록들은 본원 아래에서 더 상세하게 기술되는 바와 같이 하나 이상의 활동들에 명시적으로 세팅될 수 있거나 활동 청취 질의에 의해 결정될 수 있음이 인정될 것이다.

각각의 활동이 메시지로서 간주될 수 있고 각각의 메시지가 활동 데이터 구조를 포함할 수 있음이 인정될 것이다. 활동 데이터 구조들은 미리 규정되는 데이터 유형들이지만, 이것들 사이의 상속을 통해 그리고 필드들을 추가함으로써 이것들을 확장할 선택사양을 가질 수 있는 제 3 자 애플리케이션들(40)을 통해 규정될 수 있다. 이것들은 시스템에 특정할 수 있거나, 표준화된 데이터 구조들에 기초하거나 이 표준화된 데이터 구조들을 포함할 수 있다. 이것들은 또한 XML, JSON 데이터와 같은 일부 방식으로 또는 이진 객체 인코딩 방식을 사용하여 인코딩될 수 있다.

활동 데이터 구조는 또한 "기술" 필드(description field)에 제공되는 제 3 자 애플리케이션(40)을 포함할 수 있다. 이는 활동의 제 3 자 애플리케이션(40) 기반 기술이다(웹사이트 구축 시스템(30)에 공지되어 있는 것보다 더 상세화될 수 있는). 예를 들어, VOIP 통신 제 3 자 애플리케이션(40)은 "999-555-1234로 John Smith에 호출 01:15"의 활동 기술 텍스트를 제공할 수 있다.

활동 데이터 구조는 활동 데이터 구조에 복귀되는 콜백 링크, 예를 들어, "더 많은 정보"를 더 포함할 수 있다. 이것은: 전자상거래 활동 구조에 대해: 전체 순서 추적 정보, 순서들의 이력 등; 챗 활동 데이터 구조에 대해: 전체 챗 트랜스크립트(transcript) 그리고 전화 활동 데이터 구조에 대해: 호출의 기록과 같은 추가의 실질 정보를 제공하는 데 사용될 수 있다. 그러므로, 샘플 완료 활동 데이터 구조는 다음의 필드들을 담고 있을 수 있다: 생성 타임스탬프; 활동 유형; 활동의 소스(제 3 자 애플리케이션(40)/구성요소 ID); 활동 스트림 ID; 활동 유형 특정 정보(활동 유형에 좌우되는); 생성 사이트 ID; 사이트 회원 데이터베이스 ID; 활동이 발생했던 사이트 페이지의 ID/URL; 제 3 자 애플리케이션(40)에 의해 제공되는 활동 기술; 제 3 자 애플리케이션(40)에 의해 사용되는 더 많은 정보 링크 및 캡처되는 사용자 세부사항들 등.

활동 조정기(250)는 로깅 요소(logging element)로 간주될 수 있고 허브(230)로부터의 전달 메시지로부터 데이터를 수신할 수 있다. 스트림 생성기(251)는 로그 또는 체인 형 구조로 간주될 수 있는 초기 스트림을 생성할 수 있고 스트림 병합기(252)는 이 스트림에 임의의 추가의 인입 활동을 더할 수 있고, 여기서 각각의 스트림은 컨택에 고유하다. 스트림 생성기(251)는 상이한 메시지들에 포함되는 개별 활동 별로 새로운 스트림을 생성하지 않을 수 있음이 인정될 것이다. 스트림 내에 포함되는 활동들이 시퀀스를 벗어날 수 있음이(예를 들어, 제 3 자 애플리케이션(40)이 활동을 보고하는 데 지연될 수 있다) 더 인정될 것이다. 스트림 병합기(252)는 스트림들이 동일한 단일 컨택에 속하면 동작 중에 이 스트림들을 병합할 수 있고 로그 생성기(253)는 모든 이전에 생성된 활동 스트림들의 활동 스트림 데이터베이스(255)에 로그 파일을 저장할 수 있다.

도 16c와 관련하여 본원에서 상술한 바와 같이, 스트림 병합기(252)는 활동-대-스트림 병합기(261) 및 스트림-대-스트림 병합기(262)를 포함한다. 활동-대-스트림 병합기(261)는 활동을 식별되는 컨택와 연관되는 스트림 내로 연관시킬 수 있고 스트림-대-스트림 병합기(262)는 2개의 별개의 스트림들을 단일 스트림으로 변환할 수 있다. 수평 스트림 병합기(263)는 검출되는 공통 1차 ID로 인하여 2개의 관련되지 않은 스트림들을 병합할 수 있고 수직 스트림 병합기(264)는 익명의 컨택에 대하여 생성되는 스트림 및 등록된 사용자와 연관되는 스트림을 연결시킬 수 있는 등록 또는 로그인 시에 이 둘을 병합할 수 있다. 스트림 병합기(252)가 필요할 때 활동 스트림 데이터베이스(255)로부터 이전에 생성된 스트림들에 액세스할 수 있음이 인정될 것이다.

예를 들어, 익명의 사용자는 사이트에 컨택 폼을 채운다. 스트림 생성기(251)는 새로운 활동 스트림(ID "anon 1"을 가지는)을 생성하고 컨택 처리기(242)는 새 컨택(본원 아래에서 더 상세하게 기술되는 바와 같이 ID "anon 1"을 가지는)을 생성할 수 있다. 동일한 사용자는 그 후에 사이트 소유자와 채팅할 수 있다. 스트림 병합기(252)는 그 후에 이 활동을 "anon 1" 활동 스트림에 병합하고 컨택 "anon 1"이 업데이트된다(본원 아래에서 더 상세하게 기술되는 바와 같이). 사용자는 상이한 브라우저를 사용하여, 그 후에 스케줄 폼을 채운다. 원래의 사용자에 대하여 상관이 존재하지 않으므로, 스트림 생성기(251)는 ID "anon 2"를 가지는 새로운 활동 스트림을 생성할 수 있고 컨택 처리기(242)는 ID "anon 2"를 가지는 새로운 컨택을 생성할 수 있다.

사용자는 그 후에 사이트로부터 어떤 것을 구매한다. 스트림 병합기(252)는 새로운 활동을 "anon 2" 활동 스트림에 병합하고 컨택 "anon 2"는 업데이트될 수 있다(예를 들어, "고객" 태그로).

사용자는 또 다른 브라우저를 사용하여, 사이트에 등록한다. 등록될 때, 모든 사용자들은 사이트의 회원 처리기로부터 "user x" ID를 수신한다. 이 시점에서, 스트림 생성기(251)는 새로운 활동 스트림(ID "user x"를 가지는)을 생성할 수 있고 컨택 처리기(242)는 새로운 컨택(동일한 ID "user x"를 가지는)을 생성할 수 있다.

이후에, 사용자는 다른 브라우저로 복귀하여 사이트 소유자와 채팅한다. 웹사이트가 쿠키를 가지지 않으므로, 스트림 생성기(251)는 또 다른 새로운 스트림 ID "anon 3"을 생성할 수 있고 컨택 처리기(242)는 새로운 컨택 "anon 3"을 생성할 수 있다.

이제, 사용자는 웹사이트에 로그인한다. 이때, "anon 3" ID 및 "user x" ID에 의한 컨택이 있다. 데이터 병합기(243)는 "user x" 스트림에서의 로그인 활동 및 컨택 "user x"에 대한 로그인 활동 모두가 활동 스트림들 "user x" 및 "anon 3"를 가리키도록, 컨택들 "anon 3"을 "user x"에 병합할 수 있다. 스트림 병합기(252)는 이 세션에서 사용자에 의해 수행되는 임의의 추가 행위들을 "user x" 활동 스트림에 병합할 수 있다. 로그 생성기(253)는 스트림들로부터의 모든 활동 데이터를 로깅하고 로그의 카피를 활동 데이터베이스(255)에 저장할 수 있다.

사이트 소유자는 이제 참조되는 도 17에 도시되는 바와 같이 웹사이트 구축 시스템(30)에 의해 제공되는 관련 사용자 인터페이스를 통해 소정의 컨택에 대한 활동 스트림의 이력에 액세스할 수 있음이 인정될 것이다. 단일 컨택 "Dani Bronstein"의 경우, 이 사람의 웹사이트 사용 이력에 용이하게 액세스될 수 있다. 웹사이트 구축 시스템(30) 또는 제 3 자 애플리케이션(40)은 또한 로그 정보에 액세스하기 위하여 API를 제공할 수 있음이 또한 인정될 것이다. 활동 로그는 최적화, 사용자 인터페이스 개선, 광고 타깃팅 등을 위해 사용될 수 있음이 인정될 것이다.

동시에, 컨택 조정기(240)는 해당 사용자의 컨택 프로파일을 증강시키기 위해 활동 스트림들(메시지들)에 의해 제공되는 데이터로부터 정보를 모을 수 있음이 더 인정될 것이다. 데이터 추출기(241)는 활동 메시지들 및 스트림들로부터 데이터를 추출할 수 있고, 데이터 병합기(243)는 관련 데이터를 자체의 세부사항들이 저장되고 컨택 데이터베이스(245)로부터 액세스될 수 있는 특정한 컨택에 병합할 수 있다. 컨택 처리기(242)는 새로운 컨택들을 생성하고, 사이트 사용자 신원, 익명의 사용자들 등을 처리할 수 있고 데이터 및 허가 처리기(244)는 관련 데이터의 프라이버시 보호 및 허가들을 처리할 수 있다. 본원에서 상술한 바와 같이, 데이터 병합기(243)는 수평 컨택 병합기(277) 및 수직 컨택 병합기(276)를 포함할 수 있다. 수평 컨택 병합기(277)는 검출되는 공통 1차 ID로 인하여 2개의 관련되지 않은 컨택들을 병합할 수 있고 수직 컨택 병합기(276)는 익명의 컨택 및 등록된 사용자와 연관되는 컨택을 연결시킬 수 있는 등록 또는 로그인 시에 이 둘을 병합할 수 있다. 수평 컨택 병합기(277)는 또한 2개의 컨택들을 별개로 유지하지만 이것들이 동일한 컨택을 표현하는 것으로 표기되도록 이것들을 서로 링크시키는 가상 수평 병합기(278)를 포함할 수 있다- 실제 컨택 정보를 병합하거나 병합하지 않고 -. 수직 컨택 병합기(276)는 또한 익명의 컨택 및 등록된 사용자와 연관되는 컨택을 별개로 유지하지만 이것들이 동일한 컨택을 표현하는 것으로 표기되도록 이것들을 서로 링크시킬 수 있도록 수직 가상 병합기(279)를 포함할 수 있다 - 실제 컨택 정보를 병합하거나 병합하지 않고 -. 데이터 병합기(243)는 또한 컨택 정보(전형적으로 데이터 추출기(241)에 의해 추출되는)를 기존의 컨택에 병합할 수 있다. 컨택 식별기(272)가 쿠키들을 사용하여 사용자 신원들을 추적할 수 있고 본원 아래에서 더 상세하게 논의되는 바와 같이 병합되어야 할 컨택들을 인식할 수 있음이 인정될 것이다.

다시 도 15, 16a 및 16b를 참조하면, 메시지 전달은 클라이언트(220), 서버(260) 또는 이 둘 모두에서 수행될 수 있다. 제 3 자 애플리케이션들(40)은 전형적으로 클라이언트 측 요소를 가질 뿐만 아니라 서버 측 요소를 가지거나 또는 적어도 제 3 자 애플리케이션(40) 제공자 서버(270)로의 서버 측 접속을 가질 수 있음이 인정될 것이다. 허브(210)는 클라이언트(220) 및 제 3 자 애플리케이션들(40) 사이의 임의의 메시지들 및 서버(260) 및 제 3 자 애플리케이션들(40) 사이의 허브(230)를 프로세싱할 수 있다. 허브(210)에 의해 수신되는 데이터는 프로세싱되고 본원 아래에서 더 상세하게 기술되는 바와 같이 추가 프로세싱을 위해 허브(230)로 전송될 수 있음이 인정될 것이다.

이제 상이한 플랫폼들 사이의 메시지 전달 시나리오를 도시하는 도 18이 참조된다. 사용자 클라이언트 기계(X)는 서버(Y) 상의 웹사이트 구축 시스템(30)에 접속될 수 있다. 웹사이트 구축 시스템(30)은 웹사이트 구축 시스템(30) 클라이언트 구성요소(A') 및 웹사이트 구축 시스템(30) 서버 구성요소(A)를 사용하여 구현될 수 있다. 생성되는 사이트가 디스플레이되면, 이는 클라이언트 측 요소들(데이터/코드)(B') 및 서버 측 요소(B)를 포함할 수 있다. 생성되는 사이트는 또한 3개의 제 3 자 애플리케이션들(40)-TPA1, TPA2 및 ETPA3를 포함할 수 있다.

TPA1은 클라이언트 측 구성요소(D') 및 TPA1 벤더 서버(H)와 접속되는 서버 측 구성요소(D)로 구현될 수 있다. TPA2는 클라이언트 측 구성요소(E') 및 TPA2 벤더 서버(I)와 접속되는 서버 측 구성요소(E)로 구현될 수 있다. 그러나, ETPA3는 웹사이트 구축 시스템(30) 제 3 자 애플리케이션(40) 지원 백엔드(F)에 접속되는 서버 측 구성요소(G)에 의해 구현되는 서버 측에 유일한 제 3 자 애플리케이션(40)일 수 있다. 이 2개는 제 3 자 애플리케이션(40) 벤더 서버(J)와 통신할 수 있다.

TPA1 및 TPA2는 클라이언트에(구성요소들(D' 및 E') 사이의), 서버에(구성요소들(D 및 E) 사이에) 또는 이 둘 모두에서 메시지들을 교환할 수 있음이 인정될 것이다. 그러나, ETPA3과의 어떠한 통신도 단지 서버에서 수행되어야만 한다. 어느 방법을 사용하든지 장점과 단점이 있음이 더 인정될 것이다. 클라이언트 측 활동 메시지 송신은 더 상호적일 수 있고 더 빠른 사용자 응답을 제공한다. 서버 측 활동 메시지 송신은 더 강하고, 더 신뢰성이 있고(예를 들어, 사용자는 프로세싱 도중에 브라우저 윈도우를 닫을 수 없다), 정확한 메시지 수신 순서를 더 양호하게 보장할 수 있고 또한 활동 메시지들이 백엔드 또는 애플리케이션 대시보드(dashboard)에 설치되어 있는 백엔드 제 3 자 애플리케이션들(40)에 송신되는 것을 가능하게 할 수 있다. 이 백엔드 제 3 자 애플리케이션들(40)이 클라이언트 측에 표시되지 않는 것이 인정될 것이다.

다수의 제 3 자 애플리케이션들(40)을 사용하는 경우의 하나의 예는 사용자가 제 3 자 애플리케이션(A)(활동 유형은 "카트 변경"이다)에서 제품을 쇼핑 카트에 추가하는 예이다. 제 3 자 애플리케이션(A)은 그 후에 추가된 제품이 있는 활동 메시지를 웹사이트 구축 시스템(30)에 송신할 수 있다. 웹사이트 구축 시스템(30)은 그 후에 이 활동을 카트 변경들에 등록된 모든 제 3 자 애플리케이션들(40)에 전송할 수 있다. 제 3 자 애플리케이션(B)이 등록되어 있으므로 이는 활동을 수신한다. 제 3 자 애플리케이션(B)은 그 후에 "당신이 또한 제품 X를 추가하면, 당신은 할인을 받을 것입니다" 또는 "할인 받으려면 이 사이트를 공유하세요"와 같은 메시지를 사용자에게 디스플레이할 수 있다.

다른 예는 제 3 자 애플리케이션(A)에서 사용자 "좋아요"(예를 들어, Facebook을 통해)와 같은 것이다. 제 3 자 애플리케이션(A)은 그 후에 활동 유형 "Facebook 좋아요"가 있는 활동 메시지를 웹사이트 구축 시스템(30)에 송신할 수 있다. 웹사이트 구축 시스템(30)은 그 후에 활동을 "좋아요" 활동들에 등록되어 있는 모든 제 3 자 애플리케이션들(40)에 전송할 수 있다. 제 3 자 애플리케이션(B)이 등록되어 있으므로 이는 활동을 수신한다. 제 3 자 애플리케이션(B)은 사용자에게 재참여 위젯을 보여주고 "당신이 이 사이트를 좋아하면, 사이트 소유자에 연락하는 것은 어때요?" 또는 "당신은 할인 쿠폰을 원하나요?"와 같은 메시지를 디스플레이할 수 있다.

본원에서 상술한 바와 같이, 모든 통신은 허브들(210 및 230)을 통해 발생할 수 있다.

라우터(211)는 클라이언트 측 메시지들을 웹사이트 및 임의의 제 3 자 애플리케이션들(40) 사이에서 라우팅할 수 있다. 라우터(211)는 또한 본원 아래에서 더 상세하게 기술되는 바와 같은 추가 프로세싱을 위해 메시지를 허브(210) 및 허브(230) 사이에서 라우팅할 수 있다.

라우터 및 트랙커(231)는 메시지들을 웹사이트 및 임의의 제 3 자 애플리케이션들(40) 사이에서 라우팅할 수 있고 또한 메시지들을 추적할 수 있다. 제 3 자 애플리케이션들(40)은 또한 클라이언트 및 서버 모두에서 메시지들을 청취할 수 있음이 인정될 것이다. 제 3 자 애플리케이션(40)이 자신이 청취, 예를 들어, 모든 "쇼핑 카트 - 아이템 추가" 활동들을 청취하는 하는 하나 이상의 활동들을 분명히 명시할 수 있음이 더 인정될 것이다. 제 3 자 애플리케이션(40)은 또한 자신이 청취, 예를 들어, 모든 Facebook 관련 활동들을 청취하는 활동 클래스들을 명시할 수 있다. 더욱이, 제 3 자 애플리케이션은 활동이 제 3 자 애플리케이션에 송신되어야 하는지를 결정하는 데 사용되는 와일드카드(wild-card) 표현(활동 명칭들에 적용되는)을 포함할 수 있다.

제 3 자 애플리케이션(40)이 활동 청취자 질의를 사용할 수 있음이 또한 인정될 것이다. 그와 같은 질의는 사용자 속성들(예를 들어, 단지 등록된 사용자들, 단지 유럽 사용자들 등), 웹 사이트 속성들 또는 구조(예를 들어, 단지 소정의 페이지 템플릿으로부터 도출되는 페이지들 상에서의 소정의 활동만을 청취), 사용자 이력(예를 들어, 단지 사용자가 과거에 총액 X를 초과하여 구매했을 경우 카트 체크아웃 활동을 청취) 등과 같은 제 3 자 애플리케이션 자체가 정상적으로 이용 할 수 없는 정보를 포함하는 추가 시스템 정보를 언급할 수 있다. 그와 같은 질의는 제 3 자 애플리케이션(40)에 의해 명시될 수 있지만, 또한 설계자에 의해 편집 가능할 수 있다.

그러므로 라우터 및 트랙커(231)는 또한 제 3 자 애플리케이션(40)에 의해 청취되고 있는 메시지들을 추적할 수 있다. 그와 같은 활동 청취자 질의 아키텍처는 제 3 자 애플리케이션들(40)이 고도로 프로그램화되고 사용자 커스터마이징(customizing)될 것을 요구하지 않고 웹 사이트 설계자가 맞춤화 및 사용자 정의를 수행하는 것을 가능하게 할 수 있으므로, 활동 라우팅 레벨에서 가장 양호하게 구현될 수 있음(제 3 자 애플리케이션(40) 내부에서의 API 호출에 의해 수행되는 대신)이 인정될 것이다. 라우터 및 트랙커(231)는 또한 사용자 개인정보를 보존하는 것을 도울 수 있는 데, 왜냐하면 웹 사이트 설계자는 추가 정보(라우팅 결정에 필요한)를 수반되는 제 3 자 애플리케이션들(40)에 제공할 필요가 없기 때문이다. 이는 또한 흔히 개별 서버들에 호스팅되는 제 3 자 애플리케이션들(40)과 통신하는 불필요한 호출(invocation)들을 절약할 수 있다.

웹사이트를 방문하고 등록하고 웹사이트에 정보를 제공하는 것은 사용자(웹사이트 방문자)임이 인정될 것이다. 사용자는 실제로 자신이 액세스하고 있는 웹사이트가 웹사이트 구축 시스템(30), 구성요소들, 구성되는 웹사이트들 및 제 3 자 애플리케이션들(40)의 결합을 사용하여 구축되는 것을 인지할 수 없다. 그러므로, 사용자 프라이버시에 대한 책임은 궁극적으로 웹사이트 소유자에 있다(또한 자신의 웹사이트에 포함되는 제 3 자 애플리케이션들(40)에 의해 착수되는 활동들을 책임지는).

사용자 프로파일 정보는 웹사이트 구축 시스템(30)에 의해 규정되는 프라이버시 규칙들에 기초하고 웹사이트 구축 시스템(30)에 의해 제공되는 API를 통해 제 3 자 애플리케이션들(40)(및 다른 웹사이트 구축 시스템(30) 구성요소들)에 의해 액세스될 수 있음이 더 인정될 것이다. 더욱이, 포함하는 사이트뿐만 아니라 그 안에 포함되는 제 3 자 애플리케이션들(40)은 사용자와 통신하기 위하여(이메일 또는 다른 방법을 통해) 컨택 정보를 사용할 수 있다.

3개의 주요한 프라이버시 관련 문제들이 있을 수 있음이 인정될 것이다. 첫번째는 웹사이트 및 웹사이트 구축 시스템(30)의 제 3 자 애플리케이션(40) 제공자와의 상호 작용이다. 웹사이트(및 웹사이트 구축 시스템(30))는 제 3 자 애플리케이션(40)이 자신의 사용자 데이터를 사용하는 것을 완전히 신뢰하지 않을 수 있는데, 예를 들어, 제 3 자 애플리케이션(40)이 대용량 메일을 보지 않거나(사이트 제공 사용자 이메일들을 사용하여), 메일을 보내지 않을 것을 요청한 사용자들에게 스팸메일을 보내지 않거나 사용자 개인 정보를 제 4 자에게 전송하지 않을 것임을 완전히 신뢰하지 않을 수 있다. 그러나, 이것은 다음의 방식들로 해소될 수 있다:

웹사이트 구축 시스템(30) 벤더는 제 3 자 애플리케이션(40) 제공자들을 웹사이트 구축 시스템(30) 애플리케이션 시장에 추가할 때 이 제공자들이 사용 조건들(Terms of Use; ToU) 합의에 서명할 것을 요구할 수 있다. 그와 같은 합의는 제 3 자 애플리케이션(40)(및 제 3 자 애플리케이션(40) 벤더)이 사용자의 정보를 오용하거나 추가로 개시하지 않을 것임을 명시한다. 웹사이트 구축 시스템(30) 벤더는 그 후에 만일 제 3 자 애플리케이션이 정보를 오용하면 제 3 자 애플리케이션 제공자에게 벌칙을 가할 수 있다(예를 들어, 제 3 자 애플리케이션(40)의 불능화, 제 3 자 애플리케이션(40)을 웹사이트 구축 시스템(30) 애플리케이션 시장에서 퇴출 등). 개인 정책 시행기들(213 및 233) 및 개인 데이터 프록시(234)는 본원 아래에서 더 상세하게 기술되는 바와 같이 제 3 자 애플리케이션들(40)에서 개인정보 보호 정책을 시행할 수 있다.

두번째 프라이버시 관련 문제는 웹사이트 및 웹사이트 구축 시스템(30)의 사용자(사이트 방문자)와의 상호 작용이다. 웹사이트는 사용자에게 사용자 자신의 개인 데이터가 어떻게 사용되는지에 대한 명확한 이해를 제공하고, 사용자로부터 합의를 수신하고, 사용자가 합의한 사용 조건들을 준수해야 한다. 웹사이트 구축 시스템(30)은 모든 발행되는 사이트들이 사용자에게 속하는 개인 정보의 허용되는 사용을 규정하는 ToU 문서를 사용자에게 제공할 것을 요구하고 사용자는 상기 문서에 전자 서명할 것을 요청받는다. 사이트는 그 후에 이 사용 조건들 및 허용되는 사용을 준수해야만 한다. 웹사이트 구축 시스템(30)은 또한 자신이 제공하는 각 웹사이트 템플릿에 샘플 ToU 페이지를 포함할 수 있다. 개인 정책 시행기들(213 및 233)은 ToU 문서의 사용의 조건들이 지켜지는 것을 보장할 수 있다. 개인 정책 시행기들(213 및 233)은 또한 관련 데이터를 삭제하거나 재배열함으로써 허용된 정보만이 TPA에 제공되는 것을 보장할 수 있다.

세번째 프라이버시 관련 문제는 구독 취소 요청(unsubscribe request)들의 지원이다. 사이트는 사용자에게 임의의 마케팅 이메일들로부터 구독 취소할 선택사양을 제공해야만 한다. 이는 본원 아래에서 더 상세하게 기술되는 데이터 및 허가 처리기(244)에 의해 처리될 수 있다.

데이터 및 허가 처리기(244)는 또한 본원 아래에서 더 상세하게 기술되는 바와 같이 상이한 사용자들에 의해 세팅되는 상이한 사용자 허가들을 처리할 수 있다.

개인 데이터 프록시(234)는 웹사이트 구축 시스템(30)(및 웹사이트 구축 시스템(30) 내에 구축되는 웹 사이트들)이 모든 또는 일부 개인 데이터를 웹사이트 구축 시스템(30)에 의해 관리되는 안전한 리포지토리에 보관하는 것을 가능하게 할 수 있고 감춰져 있는 개인 데이터를 검색하기 위해 웹사이트 구축 시스템(30)에 의해 사용될 수 있는 대안의 고유 ID들(개인 데이터 대신)을 제 3 자 애플리케이션에 제공할 수 있다. 예를 들어, 이메일 주소는, 제 3 자 애플리케이션(40)이 실제 이메일 주소에 액세스할 수 없도록 제 3 자 애플리케이션(40)에 제공되는 대안의 "이메일 주소 ID"로 대체된다.

개인 데이터 프록시(234)는 또한 제 3 자 애플리케이션(40)이 실제로 사용자와 연관되는 개인 데이터에 액세스하지 않고 메시지들을 사용자에게 컨택하고/송신하기 위하여 제 3 자 애플리케이션(40)에 의해 사용될 수 있는 다양한 통신 방법들(예를 들어, 이메일, 소셜 네트워크 메시징 등)에 대한 인터페이스들의 세트를 제공할 수 있다. 그와 같은 개인 데이터는 (예를 들어) 이름, 주소, 이메일, 전화(SMS/MMS를 포함하는), 통합 통신 ID(Skype 등) 및 소셜 네트워크 ID을 포함하여, 사용자가 컨택될 수 있는 모든 식별 세부사항들을 포함할 수 있다.

개인 데이터 프록시(234)는 그러므로 사용자 허가 필드 제한들을 시행하고, 사용자 구독 취소 요청들을 시행하고 사용자 메시지 송신을 스로틀링(throttling)하는, 예를 들어, 소정의 사이트에 대하여 작동하는 소정의 제 3 자 애플리케이션(40)에 대해 하루당 단지 100개의 이메일들만을 허용할 수 있다. 개인 데이터 프록시(234)는 프록시 파라미터들을 규정하고 제 3 자 애플리케이션에 어떤 개인 데이터를 드러낼 수 있고 어떤 것을 감출 수 있는지를-제 3 자 애플리케이션(40) 별로 - 규정할 수 있고, 이것들을 필드 하나하나에 기초하여 세팅할 수 있다.

웹사이트 구축 시스템(30) 서버들에 호스팅되는 제 3 자 애플리케이션들(40)의 경우, 개인 데이터 프록시(234)는 원래의 개인 데이터와 형태가 유사한 대안의 고유 ID를 제공(예를 들어, 원래의 개인 사용자 이메일 대신에 대안의 더미(dummy) 이메일을 제공)하고 나서 이 정보를 사용하고 이메일을 정확한 주소로 전송하기 위해 (이 예에서) 호출을 "캡처(capture)"할 수 있다. 이것은 또한 자신의 허가된 특권들을 초과하는 임의의 제 3 자 애플리케이션들(40)을 검출하는 데 사용될 수 있다.

웹사이트 소유자는 제한되거나 수정된 정보를 임의의 특정한 제 3 자 애플리케이션(40)에 제공하는 것을 희망할 수 있음이 인정될 것이다. 이것은 예를 들어, 일반적인 보안 관련 문제들, 사용자의 데이터의 임의의 요소들에 관한 특정한 프라이버시 위탁 또는 특정한 산업 또는 애플리케이션에 특유한 규제 요건에 의할 수 있다. 개인 정책 시행기들(213 및 233)은 웹사이트 소유자에 의해 행해지는 임의의 그와 같은 변경들을 구현하고 현재의 세팅들을 중복 쓰기(overwrite)할 수 있다.

하나의 예는 의료 정보를 처리하는 웹사이트일 것이고, 이 웹사이트는 의료 정보를 일반 지리적 사용자 분포 분석 제 3 자 애플리케이션(40)에 넘겨줄 때 컨택 정보로부터 일부 개인 세부사항들을 차단하는 데 관심이 있을 수 있다. 다른 예에서, 제 3 자 애플리케이션(40)은 특정한 유형들의 컨택 정보를 처리하는 데 문제가 있을 수 있다. 제 3 자 애플리케이션(40)을 사용하는 것을 계속하고자 하는(공지되어 있는 버그에도 불구하고) 웹사이트 소유자는 공지되어 있는 문제를 일으키는 컨택들을 걸러내거나 문제를 일으키지 않도록 데이터를 수정하고자 원할 수 있다.

변환기 및 어댑터들(212 및 232)은 사전 명시된 메시지 변환 및 컨텐츠 적응 규칙들을 적용할 수 있다. 각각의 그와 같은 규칙은 이 규칙이 어떤 제 3 자 애플리케이션(들)(40)에 적용되는지와 같은 조건들, 이 규칙이 어떤 메시지들에 적용되어야 하는지를 선택하는 필터링 기준, 변환 규칙(소정의 메시지를 폐기하는 것과 같은(관련 제 3 자 애플리케이션(40)에 관한 한)) 또는 활동 데이터 구조에서의 소정의 필드 또는 필드들에 적용될 변환을 포함할 수 있다.

이 방식에서, 허브들(210 및 230)은 활동 데이터 구조들의 상이한 버전들을 상이한 제 3 자 애플리케이션들(40)에 전달할 수 있다(또는 전혀 전달하지 않을 수 있다) - 사이트 소유자에 의해 만들어진 사양들에 따라.

관련된 웹사이트 구축 시스템(30)은 또한 메시지들의 검증 및 서명을 지원하여 고장 및 침입 시도들(제 3 자 애플리케이션(40) 메시지 페이로드 데이터를 수정하는 것을 목적으로 하는 중간자 공격(man-in-the-middle attack)과 같은)에 대하여 시스템을 강화할 수 있다. 그러므로, 웹사이트 구축 시스템(30)에 등록된 각각의 제 3 자 애플리케이션(40)은 개인/공개 키들의 2개의 세트들을 가질 수 있다: 하나는 제 3 자 애플리케이션(40)으로부터 웹사이트 구축 시스템(30)으로 송신되는 메시지들을 디코딩하는 데 사용되는 키(인입 키)이고 하나는 웹사이트 구축 시스템(30)으로부터 제 3 자 애플리케이션(40)으로 송신되는 메시지들을 인코딩하는 데 사용되는 키(인출 키)이다.

예를 들어, 제 3 자 애플리케이션(A)은 웹사이트 구축 시스템(30)에 메시지를 송신할 수 있다. 메시지는 사이트에 대한 제 3 자 애플리케이션 ID-제 3 자 애플리케이션 외부 ID(제 3 자 애플리케이션 범위를 가지는)-를 가지고 송신될 수 있고 이는 제 3 자 애플리케이션에 의해 서명될 수 있다. 웹사이트 구축 시스템(30)은 메시지를 수신할 수 있다. 검증기 및 서명기(235)는 제 3 자 애플리케이션(A)의 인입 키를 사용하여 서명을 검증할 수 있다. 상기 검증이 실패하면, 검증기 및 서명기(235)는 인입 메시지를 무효인 것으로 보고할 수 있고 메시지는 더 전송되지 않는다.

검증기 및 서명기(235)는 내부 사이트 ID를 가지는 메시지와 연관되는 외부 ID를 변환할 수 있다. 검증기 및 서명기(235)는 어떤 제 3 자 애플리케이션(들)(40)이 메시지를 획득해야만 하는지를 확인할 수 있다.

예를 들어, 각 제 3 자 애플리케이션(B1..Bn) 별로, 검증기 및 서명기(235)는 제 3 자 애플리케이션(B)의 외부 ID를 찾을 수 있다. 검증기 및 서명기(235)는 그 후에 제 3 자 애플리케이션(B)으로의 메시지를 생성하고 변환기 및 어댑터들(212/232)에 본원에서 상술한 바와 같은 임의의 적용 가능한 필터링 및 변환 규칙들을 적용할 것을 지시할 수 있다. 검증기 및 서명기(235)는 그 후에 제 3 자 애플리케이션(B)에 대한 인출 키를 가지는 메시지에 서명하고 이 메시지를 라우터 및 트랙커(231)(또는 라우터(211))를 통해 제 3 자 애플리케이션(B)에 송신할 수 있다. 제 3 자 애플리케이션(B)은 그 후에 메시지를 수신하고 서명을 검증할 수 있다. 현재의 검증이 실패하면, 메시지는 무효인 것으로 보고되고 더 프로세싱되지 않는다. 검증기 및 서명기(235)는 비밀 검증 데이터가 신뢰되지 않은 클라이언트에게 송신되지 않는 것을 보장하기 위해 단지 서버 측 프로세싱만을 수행할 수 있고 클라이언트 측 프로세싱을 수행하지 않을 수 있음이 인정될 것이다.

본원에서 상술한 바와 같이, 시스템(200)은 웹사이트 구축 시스템(30) 및 제 3 자 애플리케이션들(40) 사이에서 다수의 유형들의 통신을 사용할 수 있다. 이 유형들은 예를 들어 제어 통신, 예를 들어, 웹사이트 구축 시스템(30)이 제 3 자 애플리케이션(40)에 셧다운(shut down)을 명령하는 것, 기능 통신, 예를 들어, 쇼핑 카트 제 3 자 애플리케이션(40)이 본 출원에서 논의되는 예인 결제 또는 활동 통신에 영향을 미치도록 웹사이트 구축 시스템(30)을 통해 과금 제 3 자 애플리케이션(40)에 총 구매량을 송신하는 것을 포함할 수 있다. 이 상이한 유형들의 통신이 예를 들어, 송신되는 메시지들의 양, 우선순위, 견고성(robustness), 응답 시간 요건들 등에 관하여 상이한 프로파일들 및 요건들을 가지는 것이 인정될 것이다.

특히, 시스템(200)은 매우 빈번한(예를 들어, 제 3 자 애플리케이션(40) 그래픽 사용자 인터페이스(graphical user interface; GUI) 이벤트들이 보고되는 제 3 자 애플리케이션(40) 활동들로 개조되는 경우) 활동 리포트들을 포함할 수 있다. 그와 같은 많은 활동 리포트들은 더 많은 크리티컬 메시지(critical message)들을 처리하는 시스템의 부분들을 압도할 수 있다. 그러므로, 시스템(200)은 메시지들의 각각의 클래스가 별개의 채널을 통해 송신되도록 다수의 통신 채널들을 구현할 수 있다(예를 들어, 상이한 포트들, 다수의 동시 세션들 등을 사용하여). 이 방식에서, 활동 리포팅은 부 채널(side channel)을 사용하고 명령 및 기능 통신과 병렬이지만 이 명령 및 기능 통신을 방해하지 않는다.

본원에서 상술한 바와 같이, 시스템(200)은 컨택 조정기(240) 및 활동 조정기(250)를 통해 컨택 정보를 생성하고 강화할 뿐만 아니라 특정한 컨택과 연관되는 활동 이벤트들을 분석하기 위하여 활동 정보를 수집할 수 있다. 허브들(210 및 230)을 통해 라우팅되는 각 활동 메시지별로, 컨택 조정기(240) 및 활동 조정기(250)는 정보를 프로세싱할 수 있다. 스트림 생성기(251)는 활동 메시지들로부터 컨택 특정 데이터 스트림들을 생성할 수 있고 컨택 조정기(240)의 요소들은 데이터를 추출하고 이것을 컨택 데이터베이스(245) 상에 저장하기 전에 이것을 프로세싱할 수 있다.

그러므로 각각의 활동 스트림은 자신과 연관되고 데이터 스트림 하에서 수행되는 활동들로부터 추출되는 데이터에 의해 점차 강화될 수 있는 구성 컨택을 가질 수 있다. 컨택 조정기(240)는 또한 관련 컨택들의 존재- 동일한 사람을 기술하는 것으로 발견되는 다수의 컨택 기록들-를 인식할 수 있음이 인정될 것이다. 컨택 식별기(272)는 이메일, 전화번호, 사회 보장 번호, 페이스북 ID 등과 같은 1차 ID 필드를 정합함으로써 그와 같은 기록들을 인식할 수 있다. 일부 1차 ID 필드들은 다중 값 필드들이고(예를 들어, 한 사람은 다수의 식별 이메일을 가질 수 있다) 반면에 일부는 전적으로 단일한 값 필드들(예를 들어, 사회 보장 번호)인 것이 인정될 것이다.

그러므로 데이터 병합기(243)는 새로운 활동으로부터 추출되는 컨택 필드들을 현재의 구성 컨택에 병합할 수 있고 일단 익명의 사용자가 로그인 동작을 수행했고 식별된 사용자가 되었으면 자체의 웹사이트의 사용 중에 이 익명의 사용자에 대하여 구성되는 구성 컨택을 미리 규정된 저장된 컨택에 병합할 수 있다(이것은 "수직" 병합으로 공지될 수 있다). 수평 컨택 병합기(277)는 또한 자신이 동일한 사용자를 언급하는 관련된 컨택들이 있음을 검출하면 2개의 상이한 컨택들(구성 컨택 또는 저장 컨택들)의 "수평" 병합을 수행할 수 있다. 본원에서 상술한 바와 같이, 그와 같은 병합은 실제 병합(즉, 2개의 별개의 컨택들을 단일 컨택으로 전환)에 의해 수행되거나, 하나의 컨택을 다른 컨택에 병합하거나 또는 가상 병합을 통해(즉, 2개의 컨택들을 별개의 컨택들로 유지하지만 이것들이 동일한 사용자를 표현하는 것으로 표기되도록 이것들을 서로 링크시킨다 - 실제 컨택 정보 및 활동 스트림들을 병합하거나 병합하지 않고) 수행될 수 있다. 심지어 가상의 병합에서도 더 추가되는 정보가 다수의 링크된 가상 병합 컨택들에 추가될 수 있음이 또한 인정될 것이다.

그러므로, 데이터 추출기(241)는 관련 데이터 활동 구조로부터 컨택형 정보를 추출할 수 있고 데이터 병합기(243)는 컨택형 정보를 활동 스트림들과 연관되는 컨택에(익명 또는 식별된) 통합할 수 있다. 컨택형 정보(I)가 1차 ID 필드를 포함하면, 데이터 병합기(243)는 1차 ID 필드 값에 기초하여 관련 컨택들에 대해 체크할 수 있고, 만일 발견되면, 이 컨택들을 병합할 수 있다. 데이터 병합기(243)는 또한 활동이 사이트에서 사용자의 신원을 설정하는지를 체크할 수 있고(예를 들어, 사이트 로그인 활동) 만일 그렇다면, 익명의 컨택을 사용자에 대하여 저장되어 있는 기존의 컨택 기록과 병합하고, 이를 이제부터 식별된 컨택으로 만들 수 있다.

컨택 식별기(272)는 예를 들어, 단일 익명의 사용자(사이트에 로그인하지 않았던)에 의한 세션을 추적하기 위하여 쿠키를 사용하거나, 등록된 사용자들에 대한 사이트 로그인을 사용하거나, 자신의 계정이 소셜 네트워크와 연관되는 사이트 사용자들에 대한 소셜 로그인을 통하거나 또는 동일한 사용자를 기술하는 2개의 사용자 프로파일들을 식별하기 위하여 1차 ID 필드들(이메일/전화와 같은)을 정합시킴으로써 사이트 사용자들을 식별하는 다수의 방법들을 구현할 수 있음이 인정될 것이다.

자신의 세부사항들이 컨택 데이터베이스(245)에 저장되어 있는 사이트 사용자들이 사이트에 등록하지 않은 익명의 사용자들; 등록된 사용자들 및 잠재적 사용자들-아직 공식적으로 사이트에 등록되지 않은 잠재적 사용자들의 기록들(외부 소스들로부터 임포팅(importing)된)-로서 분류될 수 있음이 더 인정될 것이다.

관련 웹사이트는 세션에서 세션으로 지속되는 영구적 쿠키들을 설치할 수 있으므로, 동일한 컴퓨터 상에서 동일한 브라우저로 실행될 수 있는 다수의 익명의 세션들은 정보를 동일한 컨택 기록에 공여하는 것을 계속할 수 있다. 그러므로, 심지어 익명의 사용자라도 상당한 컨택스트 및 컨택 정보를 가질 수 있다.

등록된 사용자들은 특정 사이트에 고유한 ID를 제공해야만 한다. 별개의 사이트 특정 ID(예를 들어, 사용자이름), 이메일, 전화번호 또는 사회 보장 번호와 같은 외부 식별자 또는 소셜 네트워크 ID, 구글 ID, OpenID 식별과 같이 상이한 시스템에 의해 제공되는 외부 식별자 등과 같이, 다수의 ID의 유형들이 사용될 수 있다.

소셜 네트워크 로그인을 통하여 등록한 사용자는 사이트가 동일한 사용자의 사이트 프로파일을 채우기 위해 소셜 네트워크 내에서 이용 가능한 개인 정보를 사용하는 것을 가능하게 할 수 있다. 데이터 추출기(241)는 또한 이 개인 정보에 대한 임의으 변경을 검출하고, 가능하면 사이트 사용자 프로파일을 업데이트하기 위하여 소셜 네트워크 프로파일을 재방문할 수 있다.

등록된 사용자는 시스템이 "본 시스템에 접속을 유지할 것" 선택사양을 제공할지라도, 일반적으로 자신의 신원을 설정하기 위해 시스템 내에 로그인해야 한다. 그와 같은 로그인 절차는 명시적일 수 있거나-사용자가 로그인 다이얼로그를 호출하는- 암시적일 수 있거나-사용자가 예를 들어, 토크백을 블로그에 추가할 때 어떤 식별 세부사항들을 제공할 필요가 있는-, 또는 외부 로그인 기반일 수 있다-시스템이 소셜 네트워크 로그인 또는 OpenID 로그인과 같이, 상이한 시스템과 연관되는 로그인 절차를 호출한다-. 로그인 절차는 또한 물리적 디바이스(예를 들어, 시스템에 직접 또는 무선 인터페이스를 통해 접속되는 보안 토큰(security token))를 통해 또는 생물 측정 정보 사용을 통해(사용자의 생물 측정 파라미터들, 예를 들어, 지문 또는 홍채 스캔뿐만 아니라 타이핑 패턴 검출과 같은 사용자의 행동 검출 모두를 포함하는) 또는 상술한 방법들의 임의의 결합을 통해 영향을 받을 수 있다.

소셜 로그인 절차는 양 방향 모두로의 정규 로그인과 상호 작용할 수 있음이 또한 인정될 것이다. 예를 들어, 소셜 ID는 소셜 로그인이 사이트 로그인을 함축하도록 사이트 회원 ID와 연관될 수 있거나 또는 사이트 회원 ID는 사이트 로그인이 사용자를 하나 이상의 소셜 네트워크들에 또한 식별할 수 있도록 하나 이상의 소셜 네트워크 ID들과 연관될 수 있다.

사용자가 명시적인 로그아웃을 수행할 때, 컨택 처리기(242)는 새로운 익명의 사용자 쿠키를 발생시키고 그러므로 자신의 활동들이 이 새로운 익명의 컨택 하에서 저장될 새로운 익명의 세션(또는 세션 시리즈)를 개방할 수 있다. 이 새로운 익명의 컨택은 가능하면 추가 로그인 시에 이후 식별되는 컨택과 병합될 수 있다.

이제 익명의 사용자의 로그인 및 로그아웃 프로세스를 도시하는 도 19가 참조된다. 사용자는 시스템을 익명으로 사용하기 시작할 수 있다. 컨택 처리기(242)는 컨택을 생성할 수 있고 스트림 생성기(251)는 사용자가 1차 제 3 자 애플리케이션 행위(act1)를 수행할 때 활동 스트림(anon 1)을 자동으로 생성할 수 있다. 스트림 병합기(252)는 act1으로부터의 정보 및 다음의 활동들(act2 및 act3)으로부터의 정보를 사용자 anon1에 병합할 수 있다.

일단 동일한 사용자가 사용자 X로서 로그인을 수행했으면, 데이터 병합기(243)는 anon1 컨택(및 활동 스트림으로부터 검색되는 임의의 다른 관련 컨택 데이터)을 사용자 X의 컨택 정보에 병합할 수 있다. 스트림 병합기(252)는 또한 추가 행위들(act4 및 act5)로부터 추출되는 정보를 단일 스트림에 병합할 수 있고 데이터 추출기(241)는 그 후에 사용자 X의 컨택 정보를 추출할 수 있음이 인정될 것이다. 사용자 X가 로그아웃을 수행하면, 컨택 처리기(242)는 새로운 쿠키를 생성하고, 추가 활동들을 사용자 X로부터 분리할 수 있다. 그러므로, 새로운 활동(act6)이 수행되면, 컨택 처리기(242)는 새로운 익명의 컨택 anon2을 생성할 수 있고 데이터 추출기(241)는 이의 추출된 컨택 세부사항들(및 활동들)을 새로 생성되는 익명의 컨택 anon2 하에 저장할 수 있다.

(시나리오 A에서와 같이) 사용자 anon2가 사용자 Y로서 2번째 로그인을 수행하면, 데이터 병합기(243)는 사용자 anon2에 대한 컨택 정보(act6 및 act7에 의해 업데이트된 바에 따른)를 임의의 추가 활동과 함께 사용자 X에 대한 컨택 세부사항들(act1 내지 act5를 반영하기 위해 이미 업데이트된)에 병합할 수 있다.

활동들과 연관되는 활동 데이터 구조가 또한 컨택 세부사항들을 포함할 수 있음이 인정될 것이다. 데이터 추출기(241)는 이 정보를 추출하고 이를 데이터 병합기(243)로 전송할 수 있고 데이터 병합기(243)는 이 정보를 컨택 데이터베이스(245) 내의 기존 컨택 정보와 통합하여 가능하면 이를 강화시킬 수 있다. 데이터 추출기(241)는 본원 아래에서 더 상세하게 서술되는 바와 같이 특정한 활동 메시지들로부터, 전체 스트림들로부터, 다른 컨택들로부터 또는 지리적 주소 변환 서비스들로의 IP와 같은 외부 소스로부터 세부사항들을 추출할 수 있음이 더 인정될 것이다. 본원에서 상술한 바와 같이, 컨택 데이터베이스(245) 내의 컨택들은 또한 사용자에 의해 등록 또는 가입 프로세스의 일부로서 웹사이트에 명시적으로 제공되거나, 웹사이트에 가입할 때(소셜 로그인/등록 특징을 통해) 사용자에 의해 사용되는 소셜 네트워킹 계정으로부터 추출되거나 또는 자신의 사용자 프로파일을 업데이트할 때 사용자에 의해 제공되는 컨택 세부사항들을 포함할 수 있다. 데이터 추출기(241)는 또한 외부 소스로부터 컨택 정보를 검색할 수 있다(예를 들어, 사용자가 단지 US 집 코드(zip code)만을 명시할 때, 그리고 이것이 웹 서비스를 디코딩하는 외부 집 코드로부터 전체 주소 정보를 검색하기 위해서 사이트에 의해 사용될 때).

본원에서 상술한 바와 같이, 컨택 식별기(272)는 사용자 이름, 이메일 또는 전화번호와 같은 주 ID 필드에 기초하여 2개의 컨택들을 관련되는 것으로 인식할 수 있다. 일단 컨택들(A(새 것) 및 B(기존의 것))이 관련되어 있는 것으로 밝혀지면, 데이터 병합기(243)는 A를 B에 병합할 수 있다(B는 마스터(master)이다). 이것은 다음과 같이 필드 병합 규칙들을 사용하여 행해진다:

B1 = B or A("B∥A"에서와 같은); B를 취하고 B가 0이거나 비어 있으면 A를 취함;

B1 = math-func(A, B); 중요한 개인적인 경우들은:

B1 = A + B; 예를 들어, 방문수, 총 구매들;

B1 = min(A, B); 예를 들어 - 사이트 가입 일자;

B1 = max(A, B); 예를 들어, 최종 활동 일자;

B1 = list-unite(B, A); B 끝에 목록 A를 연결하고, B 내의 요소들에 대해 중복할 수 있는 A 내의 요소들을 제거한다(즉, B1 = B & (A-B)). 데이터 병합기(243)는 다음의 규칙들에 따라 목록 회원들 사이의 복제들을 결정할 수 있다:

정규 값(regular value)들(즉, 스칼라들)로 구성되는 목록들에 대하여, 정규 값 비교를 사용;

구조들로 구성되는 목록들에 대하여, 구조의 특정한 하위 필드를 비교 키로서 사용. 예를 들어, 다수의 주소들을 지원하는 웹사이트 구축 시스템(30)에서의 주소 유형(가정, 사업, 배달,...);

정규화된 값 비교. (예를 들어) 아래 전화번호들의 처리를 참조할 것:

구조 A가 구조 B의 더 상세화된 버전이면 A를 B에 통합(본원 아래에서 더 상세하게 기술) 그리고

상위의 확실성 점수(certainty score)- 값은 자신에게 부여되는 확실성 점수를 가질 수 있다(예를 들어, 사용자에 의해 직접 제공되는 정보 대 사용자에 대하여 추론되는 정보에 대한 상이한 확실성 점수를 가지는). 데이터 병합기(243)는 상위의 확실성 점수를 가지는 값을 선택할 수 있다.

일부 필드 유형들이 정규화된 포맷을 가지는 것이 인정될 것이다. 예를 들어, 전화번호들은 정규화된 US 포맷(예를 들어, (999)555-1234) 또는 국제 포맷(예를 들어, +1-999-555-1234)으로 정규화될 수 있다. 데이터 병합기(243)는 1차 컨택 키들(전화번호와 같은)을 비교할 때 그리고 병합된 목록들에서 복제들을 체크할 때와 같이, 비교를 위해 필드 값을 정규화된 포맷으로 전환할 수 있다.

데이터 병합기(243)는 동일한 기저의 구조를 가지는 2개의 구조화된 값들을 비교할 수 있다-예를 들어, 다수의 하위 필드들(국가, 주, 집 코드, 거리, 번호 등)로 구성되는 주소 값. X에서 비어 있지 않은 필드들의 각각이 Y에 있는 동일한 필드의 각각과 동일한 값을 가지면, 즉 Y가 X의 모든 비어있지 않은 필드 값들을 포함하고 그리고 가능하면 일부 추가 필드 값들을 포함하면, 구조 Y는 구조 X의 상세화된 버전이다. 그러므로 데이터 병합기(243)는 A가 B의 상세화된 버전이고 A가 B와 동일하지 않으면 A를 B에 통합할 수 있다.

데이터 추출기(241)가 활동이 기원했던 IP 주소로부터 컨택 주소를 추론할 수 있음이 인정될 것이다. 이것은 활동이 브라우저 세션으로부터 도달했고 사용자가 주소를 가지고 있지 않은 경우에만 사용된다. 그러므로 데이터 추출기(241)는 IP 주소의 지리적 정보에 따라 주/국가 정보를 추출할 수 있다. 이 경우에, 주소는 "추정된 지리적 IP 주소"로서 표기된다. 이것은 향후의 주소 병합을 방해-주소 필드가 IP 매핑(mapping)에 기초하여 기존(및 아마도 부정확한) 주소를 포함하고, 이는 컨택 데이터베이스(245)에 저장될 이후의 상세한(그러나 기본적으로 상이한) 주소를 방해할 수 있으므로-하지 않게 하는데 필요하다.

데이터 병합기(243)는 또한 병합된 목록들에 대한 태그 충돌을 처리할 수 있다. 목록들을 병합하는 경우에, 2개의 실체들, 즉, 컨택 A로부터의 실체, 상이하나 동일한 태그를 가지는 컨택 B로부터의 두번째 실체가 존재하는 상황에 처하는 것이 가능하다는 것이 인정될 것이다. 이 시나리오에서, 데이터 병합기(243)는 동일한 태그를 가지는 양 실체들을 목록 내로 불러들임으로써 목록을 병합할 수 있다.

그러므로 [{태그:"가정", 이메일:"a@b.com"}] + [{태그:"가정", 이메일:"c@d.com"}] 결합은 [{태그:"가정", 이메일:"a@b.com"},{tag:"가정", 이메일:"c@d.com"}]을 생성할 수 있다. 이것은 병합되는 필드들이 "허용되는 비 고유 목록 태그들"로서 표기되는 경우에 사용될 것이다.

데이터 병합기(243)는 또한 컨택 정보를 통합하려고 시도할 때 언어, 구문 또는 다른 텍스트 분석 방법뿐만 아니라 외부 데이터 소스들 또는 서비스들에 대한 참고를 사용할 수 있다. 예를 들어, 사용자는 자신의 집주소 거리 명을 2개의 활동 기록들에 2개의 상이한 방식들로-그러나 동일한 집 전화번호, 도시 및 집 코드로 명시되는- 기재했었을 수 있다. 통합기(273)는 2개의 엔트리들을 비교할 때 텍스트 분석(예를 들어, 사운덱스 알고리즘(soundex algorithm))을 적용할 수 있고, 또한 거리명의 2개의 버전들을 소정의 도시 및 집 코드에 대한 거리 명들의 외부 소스와 비교할 수 있다. 이와 같은 경우에, 통합기(273)는 양 주소들이 정통 거리 명과 유사하고(그러나 아마도 동일하지 않은) 모든 다른 주소 데이터 필드들이 적절한 값을 가지면 이 정통 거리 명을 선택할 수 있다.

데이터 병합기(243)는 또한 로그인/세션 정보에 따라 컨택 정보를 병합할 수 있다. 사용자는 로그인 또는 등록을 수행하지 않고 사이트를 사용하고, 세션을 시작하고, 일부 활동들을 이 세션의 일부 및 이후의 등록 또는 로그인으로서 수행-그러므로 세션을 새로 생성되거나 기존의 등록된 사용자 프로파일(컨택 정보를 포함하는)과 연관시키는-할 수 있다.

일단 사용자가 세션을 시작하면(익명으로서), 컨택 식별기(272)는 세션 동안 사용자를 추적할 수 있고(쿠키들, 세션 ID 등을 사용하여) 컨택 처리기(242)는 익명의 세션 동안 사용자에 의해 수행되는 활동들에 기초하여 특정한 익명의 사용자에 대한 구성 컨택을 생성할 수 있다. 라우터 및 트랙커(231)는 또한 동일한 컴퓨터로부터의 다수의 세션들에 걸쳐 익명의 사용자를 추적하는 것을 계속할 수 있다. 이것은 지속성 쿠키(persistent cookie)(세션 쿠키(session cookie)보다는 오히려)를 사용함으로써 행해질 수 있다.

사용자가 등록하면, 데이터 병합기(243)는 초기에 사용자 프로파일을 채우기 위하여 구성 컨택 정보를 사용할 수 있다. 사용자들이 로그인하면, 데이터 병합기(243)는 구성 컨택 정보를 초기에 기존 사용자 프로파일과 통합할 수 있다. 구성 컨택 정보는 데이터 병합기(243)가 병합을 위해 구성 컨택에서 사용하기 위한 임의의 다른 1차 ID(이메일 등)를 가지고 있지 않을 수 있으므로, 사용자의 사이트 ID에 따라 병합되는 것이 인정될 것이다. 임의의 그와 같은 병합은 수집된 정보에서의 불일치들을 노출할 수 있음이 또한 인정될 것이다. 익명의 구성 컨택을 기존 프로파일 데이터와 병합할 때, 불일치들이 발생할 수 있고 불가피할 수 있다. 예를 들어, 익명의 사용자는 John Smith의 명 하에서 데이터 폼(어떤 제 3 자 애플리케이션(40)에 의해 디스플레이되는)을 채우고 나서 그 후에 이름 Jane Doe 하에서 계정 내로 로그인한다(동일한 또는 별개의 브라우저 세션들을 사용하여). (예를 들어) 이후의 로그인이 동일한 컴퓨터를 사용하는 2번째 사람에 의해 실제로 행해졌거나 또는 사용자가 자신의 프라이버시를 보호하기 위해 컨택 폼 내에 가명을 사용한 것이 가능하다. 데이터 병합기(243)가 다수의 익명의 구성 컨택들을 병합할 때에도 동일한 것이 적용될 수 있다.

불일치 해소기(274)는 대부분의 필드들이(이메일 및 전화와 같은 1차 키 필드들을 포함하는) 다수의 값들을 포함할 수 있는 목록 필드들이므로, 전형적으로 불일치들을 자동으로 처리할 수 있다. 이것은 동일한 기저의 사이트의 다수의 사용들에만 적용될 수 있다. 해소될 수 없는(예를 들어, 다수의 값들을 목록 값에 병합함으로써) 임의의 그와 같은 불일치는 사이트 소유자에 의한, 최종 사용자(어떤 값을 사용할지를 결정할 수 있는)에 의한 또는 다른 기술들을 사용한 가능한 수동 처리를 위하여 플래깅(flagging)될 수 있다.

그러므로, 구성 컨택 정보는 단일 사람을 반영할 뿐만 아니라 동일한 컴퓨터를 통해 동일한 사이트에 액세스하는 사용자의 결합 세트를 반영할 수 있는 것이 가능하다.

본원에서 상술한 바와 같이, 데이터 병합기(243)는 전형적으로 컨택들이 생성되거나 수정될 때마다 1차 ID 필드들(이메일 및 전화번호들과 같은)에 따라 컨택들을 병합한다.

입력은 하나 이상의 값들을 가지는 하나 이상의 1차 ID 필드(들)를 가지는 컨택 기록(입력 컨택(C))(예를 들어, 2개의 이메일들 및 3개의 전화번호들이 있는 컨택 기록)이다. 다수의 1차 ID 필드들은 사용자가 (예를 들어) 가정/직장/셀룰러 전화번호 및 가정/직장 이메일들을 가질 수 있을 때- 그리고 사용자가 이것들 중 임의의 하나를 컨택 폼에서 상호 교환 가능하게 사용할 수 있을 때- 필요할 수 있다.

데이터 병합기(243)는 1차 키 값들을 정규화하고 정규화된 1차 키 값들, 예를 들어 "(전화=P1 또는 전화=P2) 또는 (이메일=E1 또는 이메일=E2)" 중 임의의 값을 포함하는 컨택 기록에 대한 질의를 생성할 수 있다. 데이터 병합기(243)는 부가적으로 질의를 특정 사이트에 대한 컨택 데이터베이스(245)로 제한할 수 있다. 데이터 병합기(243)는 컨택 데이터베이스(245)를 질의하고 정합하는 컨택 목록(L)(입력 컨택(C)을 포함하는)을 검색할 수 있다.

입력 컨택이 등록된 사이트 회원(특정한 사이트의)이면, 데이터 병합기(243)는 목록(L)으로부터 컨택(C)을 제거하고 목록(L) 내의 모든 남은 컨택들을 컨택(C)에 병합할 수 있다. 데이터 병합기(243)는 그 후에 업데이트된 컨택(C)을 컨택 데이터베이스(245)에 다시 저장하고 컨택 데이터베이스(245)로부터 목록(L) 내의 모든 남은 컨택들을 제거할 수 있다. 본원에서 상술한 바와 같이, 데이터 병합기(234)는 대안으로 가상 병합하고, 모든 컨택 정보를 통합하고(즉, 모든 이용 가능한 정보를 포함하기 위하여 모든 컨택 기록들을 업데이트) 그리고 정합되는 컨택 기록들을 동일한 사람에 속하는 것으로 표기하는 것을("복제" 컨택 기록들의 삭제하는 대신) 수행할 수 있다. 이것은 예를 들어, 제 3 자 애플리케이션들(40)이 컨택 기록들에 특정한 내부 ID들을 저장하거나 사용하면 필요할 수 있고, 그러므로 컨택 기록들을 삭제하는 것은 이 제 3 자 애플리케이션(40)을 실패하게 만들 것이다. 동일한 처리(즉, 컨택들을 삭제하는 것보다는 컨택들을 관련되는 것으로 표기하는 것)는 본원 아래에서 더 상세하게 논의되는 다른 경우들에 적용될 수 있다.

입력 컨택이 등록된 사이트 회원이 아니면, 데이터 병합기(243)는 얼마나 많은 사이트 회원 컨택들이 목록(L) 내에 있는지를 알아보기 위해 체크할 수 있다. 0명의 사이트 회원들이 있으면, 이는 목록(L)으로부터 컨택(C)을 제거할 수 있고 목록(L) 내의 모든 남은 컨택들을 컨택(C)에 병합할 수 있다. 데이터 병합기(243)는 그 후에 업데이트된 컨택(C)을 컨택 데이터베이스(245)에 다시 저장하고 컨택 데이터베이스(245)로부터 목록(L) 내의 모든 남은 컨택들을 제거할 수 있다.

1명의 사이트 회원이 있으면(컨택(D)), 데이터 병합기(243)는 목록(L)으로부터 컨택(D)을 제거하고 L 내의 모든 남은 컨택들을(컨택(C)을 포함하는) 컨택(D)에 병합할 수 있다. 데이터 병합기(243)는 그 후에 업데이트된 컨택(D)을 컨택 데이터베이스(245)에 다시 저장하고 컨택 데이터베이스(245)로부터 목록(L) 내의 모든 남은 컨택들을 제거할 수 있다.

둘 이상의 사이트 회원 컨택들(D, D1, D2,...)이 있으면, 데이터 병합기(243)는 발견되는 사이트 회원 컨택들(D, D1, D2,...)로부터 컨택(D)을 선택하고 목록(L)으로부터 컨택(D)을 제거할 수 있다. 데이터 병합기(243)는 그 후에 사이트 회원들이 아닌 목록(L) 내의 컨택들을 포함하는, 목록(L)으로부터 하위 목록(LL)을 생성할 수 있다. 데이터 병합기(243)는 그 후에 목록(LL) 상의 모든 남은 컨택들을 컨택(D)에 병합할 수 있다. 데이터 병합기(243)는 그 후에 업데이트된 컨택(D)을 컨택 데이터베이스(245)에 다시 저장하고 컨택 데이터베이스(245)로부터 목록(LL) 내의 모든 남은 컨택들을 제거할 수 있다.

본원에서 로그인 병합에 대하여 상술한 바와 같이, 데이터에서 불일치들이 발생할 수 있다. 그러나, 목록 값 생성기(275)가 목록 값 필드들(다수의 값들을 가지는)을 생성할 수 있고 컨택들 사이에 명확한 선행(precedence)을 규정할 수 있으므로, 문제는 대부분의 경우 발생하지 않을 수 있다.

예를 들어, 데이터 병합기(243)는 다음의 컨택들을 병합한다:

컨택1 = [전화1, 이메일1];

컨택2 = [전화1, 이메일2];

컨택3 = [전화2, 이메일2];

이는 결합된 컨택을 발생시킬 수 있다:

결합 - 컨택 = [전화 = [전화1, 전화2], 이메일 = [이메일1, 이메일2]].

컨택 데이터베이스(245)는 다수의 소스들로부터의, 그리고 이의 사용을 위해 상이한 허가들의 레벨들을 가지는 컨택 정보를 포함할 수 있음이 인정될 것이다. 다음의 논의는 이메일들을 언급하는데; 그러나 이 논의 및 기술은 위에 언급되는 바와 같이 사용자에게 컨택하는 데 사용되는 임의의 유형의 정보에 적용된다(전화, 팩스, Skype ID, 인스턴트 메시징 ID, 소셜 네트워크 ID 등).

예를 들어, 이메일 주소가 사이트에 제공되었던 방식은 자체의 사용을 위하여 상이한 허가들을 표시할 수 있다. 이메일 주소들에 대한 일부 가능한 소스들은 등록 ID; 컨택 폼, 뉴스레터 가입 및 구독 취소 요청이다. 이메일 주소들은 사용자에 의해 전자적으로 서명된 "허용된 사용자 합의"의 면에서 더 상이할 수 있다.

웹사이트 구축 시스템(30)이 전형적으로 소정의 이메일에 대한 허용된 사용들에 관한 정보를 가지고 있는 것이 인정될 것이다. 그러나, 웹사이트 소유자는 예를 들어, 사이트 내의 상이한 가입 폼들의 성격으로 인해 또는 시스템 내의 컨택들이 웹사이트에 의해 추가 사용 허가 정보를 포함하는 상이한 소스로부터 임포팅되는 것으로 인해 상이하거나, 별개이거나 또는 추가의 정보를 가질 수 있다.

데이터 및 허가 처리기(244)는 웹사이트 소유자가 이 정보를 관리하는 것을 보조하기 위하여 사이트에서 사용되는 제 3 자 애플리케이션들(40)에서 권한 사용자 정책을 시행할 수 있다.

그러므로 관련 컨택에 대한 컨택 기록은 정보의 2개의 필드들을 포함할 수 있다. 제 1 필드는 웹사이트에 의해 사용자 활동으로부터 계산되는 도출 또는 제안된 허가들을 포함하는 웹사이트 허가 필드이다. 컨택 폼은 단지 기능 이메일을 함축하고 반면에 가입자 폼은 반복 이메일(recurring email)들을 함축할 수 있다. 제 2 필드는 웹사이트 허가 필드 값에 기초하는 사이트 소유자 허가 필드이다. 사이트 소유자는 웹사이트 권장사항들을 변경할 수 있고 자신이 좋아하는 것은 무엇이든지 할 수 있지만, 자신은 웹사이트 허가 필드에 의해 규정되는 허가들을 초과하는 어떠한 사용에도 책임을 진다.

웹사이트 허가 필드 값이 사용자들의 의도에 대한 웹사이트의 최상의 정보를 표현하는 것임이 인정될 것이다. 사이트 소유자 허가 값은 웹사이트에 의해 할당되고 제 3 자 애플리케이션(40) 및 시스템의 다른 부분들에 의해(예를 들어, 뉴스레터 송신을 제공하는 제 3 자 애플리케이션(40)에 의해) 사용되는 값이다.

데이터 및 허가 처리기(244)는 다수의 방식들로 허가들을 규정하기 위해 이 허가 필드들을 사용할 수 있다. 예를 들어, 데이터 및 허가 처리기(244)는 다음의 코드들 또는 결합들 및 이의 변형들 중 어떤 것을 구현할 수 있다(이메일뿐만 아니라 다른 컨택 ID들에 대해서).

미지 - 이메일은 미지의 소스들로부터 추출되었고 어떠한 이메일 송신에도 사용될 수 없다.

이메일 ID - 등록 목적들을 위해 제공되는 이메일. 이는 등록 확인, 기억이 나지 않는 패스워드 및 의심되는 보안 위반 통지와 같은 등록 관련 문제들을 제외하고 어떠한 이메일 송신에도 사용될 수 없다.

기능 이메일 - 특정 기능을 위해 제공되고 1회성 이메일들을 허용한다. 예를 들어, 구매 확인 이메일 또는 특정한 컨택 폼에 대하여 제공되는 이메일.

반복 이메일 - 다수의 그리고 주기적 구독들 및 광고들이 특정한 웹사이트에 의해 송신되는 것을 허용한다. 이것은 명시적 구독/승인을 필요로 한다.

공유 가능 이메일 - 다수의 그리고 주기적인 구독들 및 광고들이 웹사이트뿐만 아니라 이의 파트너들(제 3 자 애플리케이션들(40), 제 4 자들)에 의해 송신되는 것을 허용한다. 이것은 명시적인 구독/승인을 필요로 하고 허용된 공유에 대한 상세한 정보를 포함할 수 있다.

기피(opt out) - 사용자는 명백히 구독 취소하였다. 어떠한 이메일들도 사용자에게 송신될 수 없다(가능하면 기피 통지를 제외하고).

데이터 및 허가 처리기(244)는 허가 비트 마스크(UNIX 및 리눅스 시스템들에서 사용되는 것과 유사한) 또는 액세스 제어 목록(Access Control List; ACL) 메커니즘과 같은 대안의 방법들을 사용할 수 있음이 인정될 것이다. 데이터 및 허가 처리기(244)는 또한 컨택 정보의 별개의 부분들에 대해 별개의 허가 필드들을 구현할 수 있다(예를 들어, 이메일, 인스턴트 메신저 주소, 소셜 네트워크 ID 등).

전형적인 사용 시나리오는 컨택 데이터베이스(245)가 컨택 폼들로부터 수집되는 이메일들의 제 1 세트 및 구독 요청들로부터의 이메일들의 제 2 세트를 포함하는 시나리오이다. 웹사이트는 뉴스레터 송신 제 3 자 애플리케이션(40)을 호출하여, 제 3 자 애플리케이션(40)이 이메일들을 단지 사용자의 제 2 세트(구독 요청들을 송신한 사용자들)에 속하는 사용자들에게만 송신할 것임을 인지할 수 있다.

그와 같은 시스템의 장점들은 사용자들에 대한 비본질적인 스팸 메일 송신 또는 개인 정보 오용으로부터의 더 양호한 보호(기술 및 법적인 것 모두)- 웹사이트 및 웹사이트 소유자 모두에 대해-를 포함할 뿐만 아니라 본원에서 상술한 바와 같이 개인 데이터 프록시(234)와 함께 사용될 때 개인정보 보호 정책을 실제로 시행하는 능력을 포함한다. 이는 또한 구독 취소 요청들이 더 엄격하게 시행되는 것을 보장할 수 있다.

그러므로 사용자는 관련 웹사이트 구축 시스템(30) 및 임의의 관련된 제 3 자 애플리케이션들(40) 사이의 활동들의 스트림을 발생시킬 수 있다. 이 스트림들은 활동 스트림들로 공지될 수 있다. 각각의 활동 스트림은 단일 컨택에 대한 정보원(informatin source)으로서 사용될 수 있다. 개별 스트림들의 활동 데이터 구조는 또한 상이한 활동 스트림들이 동일한 소스에서 나온 것임이 결정될 수 있으면 컨택을 형성하기 위해 병합될 수 있다. 예를 들어, 단일 사용자는 모바일 디바이스 및 개인용 컴퓨터와 같은 2개의 디바이스들을 통해 익명으로 작업할 수 있다. 그와 같은 사용자는 메시지가 저장될 수 있는 2개의 익명의 스트림들을 생성할 수 있다. 일단 스트림들이 동일한 사용자와 연관되는 것으로 식별되었으면, 이것들을 병합될 수 있다.

본원에서 제시되는 프로세스들 및 디스플레이들은 내재적으로 임의의 특정한 컴퓨터 또는 다른 장치와 관련되지 않는다. 다양한 범용 시스템들은 본원에서의 내용들에 따라 프로그램들과 함께 사용될 수 있거나 더 특수한 장치들을 구성하여 원하는 방법을 수행하는 것이 편리한 것임이 판명될 수 있다. 상기 설명으로부터 다양한 이 시스템들에 대한 원하는 구조가 등장할 것이다. 게다가, 본 발명의 실시예들은 임의의 특정한 프로그래밍 언어를 참고하여 기술되지 않는다. 본원에서 기술되는 바와 같은 본 발명의 내용을 구현하는 데 다양한 프로그래밍 언어들이 사용될 수 있음이 인정될 것이다.

앞서의 논의들에서부터 명백한 바와 같이, 구체적으로 달리 진술되지 않으면, 명세서 전체에 걸쳐, "프로세싱하는", "컴퓨팅하는", "계산하는", "결정하는" 등과 같은 용어들을 활용하는 논의들은 전자와 같이 컴퓨팅 시스템의 레지스터들 및/또는 메모리들 내에서 물리적인 양으로 표현되는 데이터를 조작하고/조작하거나 이 데이터를 컴퓨팅 시스템의 메모리들, 레지스터들 또는 다른 그와 같은 정보 저장, 전송 또는 디스플레이 디바이스들 내의 물리적인 양들로 유사하게 표현되는 다른 데이터로 변환하는 컴퓨터, 컴퓨팅 시스템 또는 유사한 전자 컴퓨팅 디바이스의 행위 및/또는 프로세스들을 칭하는 것임이 인정될 것이다.

본 발명의 실시예들은 본원에서의 동작들을 수행하는 장치를 포함할 수 있다. 이 장치는 원하는 목적들을 위해 특수하게 구성될 수 있거나, 또는 이는 컴퓨터에 저장되는 컴퓨터 프로그램에 의해 선택적으로 활성화되거나 재구성되는 범용 컴퓨터를 포함할 수 있다. 그와 같은 컴퓨터 프로그램은 컴퓨터 판독 가능 저장 매체, 예를 들어, 플로피 디스크들, 광 디스크들, 자기 광 디스크들을 포함하는 임의의 유형의 디스크, 판독 전용 메모리(read-only memory; ROM)들, 컴팩트 디스크 판독 전용 메모리(compact disc ROM; CD-ROM)들, 랜덤 액세스 메모리(random access memory; RAM)들, 전기적 프로그램 가능 판독 전용 메모리(electrically programmable ROM; EPROM)들, 전기적 소거 가능 및 프로그램 가능 판독 전용 메모리(electrically erasable and programmable ROM; EPPROM)들, 자기 또는 광 카드들, 플래시 메모리 또는 전자 명령들을 저장하는데 적합하고 컴퓨터 시스템 버스에 결합될 수 있는 임의의 다른 유형의 매체에 저장될 수 있으나 이로 제한되지 않는다.

본 발명의 특정 특징들이 본원에서 설명되고 기술되었을지라도, 이제 당업자에게는 많은 수정들, 대체들, 변경들 및 등가들이 착상될 수 있다. 그러므로 첨부된 청구항들이 본 발명의 진정한 사상 내에 해당하는 모든 그와 같은 수정들 및 변경들을 포괄하도록 의도되는 것이 이해되어야 한다.

Claims (24)

1. 적어도 하나의 프로세서를 가지는 클라이언트/서버 시스템을 통해 웹사이트 상에서 구현 가능한 시스템으로서, 상기 프로세서는 상기 시스템을 규정하는 명령들을 프로세싱(processing)하고, 상기 시스템은:
   상기 웹사이트와 상기 웹사이트에 내장된 적어도 하나의 제 3 자 애플리케이션(third party application) 사이의 그리고 상기 적어도 하나의 제 3 자 애플리케이션과 컨택 정보(contact information) 강화를 위해 상기 웹사이트에 내장된 제2 의 제 3 자 애플리케이션 사이의 적어도 하나의 활동 메시지로부터 데이터를 조정하고 수집하기 위한 유닛으로서, 상기 적어도 하나의 활동 메시지는 표준화된 포맷을 가지는, 유닛을 포함하고,
   상기 유닛은,
   상기 유닛을 통해 수집된 상기 적어도 하나의 활동 메시지를 청취(listen)하고 그리고 식별된 컨택(contact) 및 익명의 컨택 중 적어도 하나와 연관되는 활동 스트림(activity stream)에 상기 적어도 하나의 활동 메시지로부터 추출되는 데이터를 추가하는 활동 조정기(activity coordinator)로서, 상기 식별된 컨택 및 익명의 컨택 중 적어도 하나는 상기 웹사이트의 사용자인, 활동 조정기;
   상기 활동 스트림으로부터 컨택 관련 정보를 검색하고 분석하며, 상기 컨택에 대해 이전에 보유된 정보를 강화(enrich)하는 컨택 조정기; 및
   상기 웹사이트에 의해 그리고 상기 컨택에 의해 사용되도록 상기 활동 스트림 및 상기 컨택 관련 정보를 저장하는 적어도 하나의 데이터베이스
   를 포함하는 시스템.
2. 제 1 항에 있어서,
   상기 유닛은:
   상기 웹사이트와 상기 적어도 하나의 제 3 자 애플리케이션 사이의 그리고 상기 적어도 하나의 제 3 자 애플리케이션과 제2 의 제 3 자 애플리케이션 사이의 상기 적어도 하나의 활동 메시지를 라우팅하고 추적하는 라우터 및 트랙커(router and tracker);
   상기 웹사이트와 상기 적어도 하나의 제 3 자 애플리케이션 사이에서 개인정보 합의(privacy agreement)의 조건들을 시행하기 위한 개인 정책(private policy) 시행기(enforcer);
   상기 웹사이트와 상기 적어도 하나의 제 3 자 애플리케이션 사이에서 사전 명시되는 적어도 하나의 메시지 변환 및 컨텐츠 적응 규칙들을 적용하는 변환기 및 어댑터(tranlator and adapter);
   개인 데이터 프록시(proxy) 및 개인 데이터 대체 중 적어도 하나를 구현하고 상기 웹 사이트와 상기 적어도 하나의 제 3 자 애플리케이션 사이에서 사용자 허가 제한들을 시행하는 개인 데이터 프록시; 및
   상기 적어도 하나의 제 3 자 애플리케이션의 인입 키(incoming key)를 사용하여 상기 적어도 하나의 활동 메시지의 서명을 검증하고, 상기 웹사이트의 내부 ID를 구비하는 상기 적어도 하나의 활동 메시지와 연관되는 외부 ID를 변환하며, 상기 적어도 하나의 제 3 자 애플리케이션의 인출 키(outgoing key)를 사용하여 인출되는 상기 적어도 하나의 활동 메시지를 서명하는 검증기 및 서명기
   중 적어도 하나를 포함하는 시스템.
3. 제 1 항에 있어서,
   상기 활동 조정기는:
   상기 적어도 하나의 활동 메시지와 연관되는 상기 컨택을 식별하고 연관되는 컨택이 존재하지 않으면 데이터의 상기 활동 스트림을 생성하는 스트림 생성기;
   상기 적어도 하나의 활동 메시지로부터의 데이터를 기존의 활동 스트림에 그리고 상기 활동 스트림들 중 적어도 2개로부터의 데이터를 단일 활동 스트림으로 병합하는 스트림 병합기; 및
   상기 활동 스트림으로부터의 활동 데이터를 상기 적어도 하나의 데이터베이스에 로깅하는 로그 생성기(log creator)
   중 적어도 하나를 포함하는 시스템.
4. 제 1 항에 있어서,
   상기 컨택 조정기는:
   상기 적어도 하나의 활동 메시지, 상기 활동 스트림, 다른 컨택들 및 외부 소스들 중 적어도 하나로부터 컨택 관련 정보를 추출하는 데이터 추출기;
   적어도 2개의 컨택 기록들을 병합하고- 상기 적어도 2개의 컨택 기록들은 동일한 식별된 컨택과 연관성을 가짐- 그리고 미리 규정된 병합 규칙들에 따라 상기 추출된 컨택 관련 정보를 기존의 컨택에 대한 정보와 병합하는 데이터 병합기;
   식별 가능한 새로운 컨택 및 익명의 컨택 중 적어도 하나를 생성하고 상기 웹사이트의 세션 동안 컨택 활동을 추적하는 컨택 처리기; 및
   추출된 컨택 관련 정보의 프라이버시 보호 및 허가들을 처리하는 데이터 및 허가 처리기
   중 적어도 하나를 포함하는 시스템.
5. 제 2 항에 있어서,
   상기 라우터 및 트랙커는 상기 적어도 하나의 제 3 자 애플리케이션에 대한 명시된 청취 질의들을 사용하여 상기 적어도 하나의 활동 메시지의 라우팅을 지원하는 시스템.
6. 제 3 항에 있어서,
   상기 스트림 병합기는, 상기 데이터를 상기 식별된 컨택과 연관되는 상기 활동 스트림에 병합하는 활동-대-스트림 병합기 및 적어도 2개의 별개의 활동 스트림들을 단일 활동 스트림으로 병합하는 스트림-대-스트림 병합기를 포함하는 시스템.
7. 제 6 항에 있어서,
   상기 스트림-대-스트림 병합기는, 식별된 공통 컨택에 따라 상기 적어도 2개의 별개의 활동 스트림들을 병합하는 수평 스트림 병합기, 그리고 익명의 컨택에 대하여 생성되는 활동 스트림과 등록된 컨택 사용자와 연관되는 활동 스트림을 연결시킬 수 있는 등록 또는 로그인 시에 상기 익명의 컨택에 대하여 생성되는 활동 스트림을 상기 등록된 컨택 사용자와 연관되는 활동 스트림과 병합하는 수직 스트림 병합기 중 적어도 하나를 포함하는 시스템.
8. 제 4 항에 있어서,
   상기 데이터 병합기는:
   상기 적어도 2개의 컨택 기록들에서 동일한 1차 ID 필드 값들의 위치를 찾는 것, 정규화될 때 동일한 상기 적어도 2개의 컨택 기록들 내에서 1차 키 필드 값들의 위치를 찾는 것, 쿠키를 사용하여 사이트 사용자들을 식별하는 것, 등록된 사용자들에 대한 사이트 로그인을 사용하여 사이트 사용자를 식별하는 것, 및 소셜 네트워크와 연관되는 계정을 가지는 사이트 사용자들에 대한 소셜 로그인을 통해 사이트 사용자를 식별하는 것 중 적어도 하나를 행하는 컨택 식별기;
   언어, 구문, 텍스트 분석 및 외부 데이터 소스들 및 서비스들에 대한 참고(consultation) 중 적어도 하나를 사용하여 컨택 정보를 통합하는 통합기;
   컨택 기록들 사이의 불일치들을 미리 규정된 규칙들에 따라 해소하는 불일치 해소기(contradiction resolver);
   상기 불일치들을 방지하기 위해 상기 컨택 기록들 사이의 목록 값 필드들을 생성하는 목록 값 생성기;
   검출되는 공통 1차 ID로 인하여 2개의 관련되지 않은 컨택들을 병합하는 수평 컨택 병합기; 및
   익명의 컨택과 등록된 사용자와 연관되는 컨택을 연결시킬 수 있는 등록 또는 로그인 시에 상기 익명의 컨택을 상기 등록된 사용자와 연관되는 컨택과 병합하는 수직 컨택 병합기
   중 적어도 하나를 포함하는 시스템.
9. 제 8 항에 있어서,
   상기 수평 컨택 병합기는 상기 적어도 2개의 컨택 기록들을 별개로 유지하고 상기 적어도 2개의 컨택 기록들이 동일한 컨택을 표현하는 것으로 표기되도록 상기 적어도 2개의 컨택 기록들을 서로 링크하는 가상 병합기를 포함하는 시스템.
10. 제 8 항에 있어서,
    상기 수직 컨택 병합기는, 익명의 컨택 및 등록된 사용자와 연관되는 컨택을 별개로 유지하고 상기 익명의 컨택 및 상기 등록된 사용자와 연관되는 컨택이 동일한 컨택을 표현하는 것으로 표기되도록 상기 익명의 컨택 및 상기 등록된 사용자와 연관되는 컨택을 서로 링크하는 가상 병합기를 포함하는 시스템.
11. 적어도 하나의 프로세서를 가지는 클라이언트/서버 시스템을 통해 웹사이트 상에서 구현 가능한 방법으로서, 상기 프로세서는 상기 방법을 규정하는 명령들을 프로세싱하고, 상기 방법은:
    상기 웹사이트와 상기 웹사이트에 내장된 적어도 하나의 제 3 자 애플리케이션 사이의 그리고 상기 적어도 하나의 제 3 자 애플리케이션과 컨택 정보 강화를 위해 상기 웹사이트에 내장된 제2 의 제 3 자 애플리케이션 사이의 적어도 하나의 활동 메시지로부터 데이터를 조정하고 수집하는 단계 - 상기 적어도 하나의 활동 메시지는 표준화된 포맷을 가짐-를 포함하고,
    상기 데이터를 조정하고 수집하는 단계는,
    상기 데이터를 조정하고 수집하는 단계를 통해 수집된 상기 적어도 하나의 활동 메시지를 청취하고 식별된 컨택과 익명의 컨택 중 적어도 하나와 연관되는 활동 스트림에 상기 적어도 하나의 활동 메시지로부터 추출되는 데이터를 추가하는 단계로서, 상기 식별된 컨택 및 익명의 컨택 중 적어도 하나는 상기 웹사이트의 사용자인, 청취하고 추가하는 단계;
    상기 활동 스트림으로부터 컨택 관련 정보를 검색하고 분석하며, 상기 컨택에 대해 이전에 보유된 정보를 강화하는 단계; 및
    상기 웹사이트에 의해 그리고 상기 컨택에 의해 사용되도록 활동 스트림 및 상기 컨택 관련 정보를 저장하는 단계를 포함하는 방법.
12. 제11항에 있어서,
    상기 데이터를 조정하고 수집하는 단계는:
    상기 웹사이트와 상기 적어도 하나의 제 3 자 애플리케이션 사이의 그리고 상기 적어도 하나의 제 3 자 애플리케이션과 상기 제2 의 제 3 자 애플리케이션 사이의 상기 적어도 하나의 활동 메시지를 라우팅하고 추적하는 단계;
    상기 웹사이트와 상기 적어도 하나의 제 3 자 애플리케이션 사이에서 개인정보 합의의 조건들을 시행하는 단계;
    상기 웹사이트와 상기 적어도 하나의 제 3 자 애플리케이션 사이에서 사전 명시되는 적어도 하나의 메시지 변환 및 컨텐츠 적응 규칙들을 적용하는 단계;
    개인 데이터 프록시 및 개인 데이터 대체 중 적어도 하나를 구현하고 상기 웹 사이트와 상기 적어도 하나의 제 3 자 애플리케이션 사이에서 사용자 허가 제한들을 시행하는 단계; 및
    상기 적어도 하나의 제 3 자 애플리케이션의 인입 키를 사용하여 상기 적어도 하나의 활동 메시지의 서명을 검증하고, 상기 웹사이트의 내부 ID를 구비하는 상기 적어도 하나의 활동 메시지와 연관되는 외부 ID를 변환하고, 상기 적어도 하나의 제 3 자 애플리케이션의 인출 키를 사용하여 인출되는 상기 적어도 하나의 활동 메시지를 서명하는 단계
    중 적어도 하나를 포함하는 방법.
13. 제 11 항에 있어서,
    상기 청취하고 추가하는 단계는:
    상기 적어도 하나의 활동 메시지와 연관되는 상기 컨택을 식별하고 연관되는 컨택이 존재하지 않으면 데이터의 상기 활동 스트림을 생성하는 단계;
    상기 적어도 하나의 활동 메시지로부터의 데이터를 기존의 활동 스트림에 그리고 상기 활동 스트림들 중 적어도 2개로부터의 데이터를 단일 활동 스트림으로 병합하는 단계; 및
    상기 활동 스트림으로부터의 활동 데이터를 상기 적어도 하나의 데이터베이스에 로깅하는 단계
    중 적어도 하나를 포함하는 방법.
14. 제 11 항에 있어서,
    상기 검색하고 분석하는 것은:
    상기 적어도 하나의 활동 메시지, 상기 활동 스트림, 다른 컨택들 및 외부 소스들 중 적어도 하나로부터 컨택 관련 정보를 추출하는 단계;
    적어도 2개의 컨택 기록들을 병합하고- 상기 적어도 2개의 컨택 기록들은 동일한 식별된 컨택과 연관성을 가짐- 그리고 미리 규정된 병합 규칙들에 따라 상기 추출된 컨택 관련 정보를 기존의 컨택에 대한 정보와 병합하는 단계;
    식별 가능한 새로운 컨택 및 익명의 컨택 중 적어도 하나를 생성하고 상기 웹사이트의 세션 동안 컨택 활동을 추적하는 단계; 및
    추출된 컨택 관련 정보의 프라이버시 보호 및 허가들을 처리하는 단계
    중 적어도 하나를 포함하는 방법.
15. 제 12 항에 있어서,
    상기 라우팅하고 추적하는 단계는 상기 적어도 하나의 제 3 자 애플리케이션에 대한 명시된 청취 질의들을 사용하여 상기 적어도 하나의 활동 메시지의 라우팅을 지원하는 방법.
16. 제 13 항에 있어서,
    상기 병합하는 단계는 상기 데이터를 상기 식별된 컨택과 연관되는 상기 활동 스트림에 병합하는 단계 및 적어도 2개의 별개의 활동 스트림들을 단일 활동 스트림으로 병합하는 단계를 포함하는 방법.
17. 제 16 항에 있어서,
    상기 데이터를 상기 활동 스트림에 병합하는 단계는 상기 식별된 컨택과 연관되고, 및 상기 적어도 2개의 별개의 활동 스트림들을 단일 활동 스트림으로 병합하는 단계는, 식별된 공통 컨택에 따라 상기 적어도 2개의 별개의 활동 스트림들을 수평으로 병합하는 단계 및 익명의 컨택에 대하여 생성되는 활동 스트림과 등록된 컨택 사용자와 연관되는 활동 스트림을 연결시킬 수 있는 등록 또는 로그인 시에 상기 익명의 컨택에 대하여 생성되는 활동 스트림을 상기 등록된 컨택 사용자와 연관되는 활동 스트림과 수직으로 병합하는 단계 중 적어도 하나를 포함하는 방법.
18. 제 14 항에 있어서,
    상기 적어도 2개의 컨택 기록들을 병합하는 단계는:
    상기 적어도 2개의 컨택 기록들에서 동일한 1차 ID 필드 값들의 위치를 찾고, 정규화될 때 동일한 상기 적어도 2개의 컨택 기록들 중 1차 키 필드 값들의 위치를 찾고, 쿠키를 사용하여 사이트 사용자들을 식별하고, 등록된 사용자들에 대한 사이트 로그인을 사용하여 사이트 사용자를 식별하고, 소셜 네트워크와 연관되는 계정을 가지는 사이트 사용자들에 대한 소셜 로그인을 통해 사이트 사용자를 식별하는 단계;
    언어, 구문, 텍스트 분석 및 외부 데이터 소스들 및 서비스들에 대한 참고 중 적어도 하나를 사용하여 컨택 정보를 통합하는 단계;
    컨택 기록들 사이의 불일치들을 미리 규정된 규칙들에 따라 해소하는 단계;
    상기 불일치들을 방지하기 위해 상기 컨택 기록들 사이의 목록 값 필드들을 생성하는 단계;
    검출되는 공통 1차 ID로 인하여 2개의 관련되지 않은 컨택들을 수평으로 병합하는 단계; 및
    익명의 컨택과 등록된 사용자와 연관되는 컨택을 연결시킬 수 있는 등록 또는 로그인 시에 상기 익명의 컨택을 상기 등록된 사용자와 연관되는 컨택과 수직으로 병합하는 단계
    중 적어도 하나를 포함하는 방법.
19. 제 18 항에 있어서,
    상기 수평으로 병합하는 단계는, 상기 적어도 2개의 컨택 기록들을 별개로 유지하기 위해 가상 병합하고 상기 적어도 2개의 컨택 기록들이 동일한 컨택을 표현하는 것으로 표기되도록 상기 적어도 2개의 컨택 기록들을 서로 링크하는 단계를 포함하는 방법.
20. 제 18 항에 있어서,
    상기 수직으로 병합하는 단계는, 익명의 컨택 및 등록된 사용자와 연관되는 컨택을 별개로 유지하기 위해 가상 병합하고 상기 익명의 컨택 및 상기 등록된 사용자와 연관되는 컨택이 동일한 컨택을 표현하는 것으로 표기되도록 상기 익명의 컨택 및 상기 등록된 사용자와 연관되는 컨택을 서로 링크하는 단계를 포함하는 방법.
21. 제 2 항에 있어서,
    상기 사용자 허가는 결정된 상기 웹사이트 및 결정된 상기 웹사이트의 소유자 중 적어도 하나인 시스템.
22. 제 12 항에 있어서,
    상기 사용자 허가는 결정된 상기 웹사이트 및 결정된 상기 웹사이트의 소유자 중 적어도 하나인 방법.
23. 제 1 항에 있어서,
    상기 표준화된 포맷은, 미리 규정된 스키마(schema), 상속(inheritance), 콜백(call back) 링크에 의해 규정되는 것, 상기 적어도 하나의 제 3 자 애플리케이션에 의해, 또는 외부 정규 산업상 또는 사실상 표준에 기초하여 인코딩되고 규정되는 것 중 적어도 하나인 것인, 시스템.
24. 제 11 항에 있어서,
    상기 표준화된 포맷은, 미리 규정된 스키마, 상속, 콜백 링크에 의해 규정되고, 상기 적어도 하나의 제 3 자 애플리케이션에 의해 또는 외부 정규 산업상 또는 사실상 표준에 기초하여 규정되고 인코딩되는 것 중 적어도 하나인 것인, 방법.

Images