KR102283274B1 - 콘텐트 큐레이션을 위한 애플리케이션 프로그래밍 인터페이스 - Google Patents

Abstract

위치 식별자를 통해 식별되는 문서 내의 콘텐트의 블록을 위한 어드레스를 생성하기 위한 애플리케이션 프로그래밍 인터페이스(Application Programming Interface: API)는 물론 생성된 어드레스로부터 콘텐트를 검색하고 콘텐트를 생성된 어드레스로 도로 푸시하거나 병합하기 위한 API에 의해 콘텐트 큐레이션(content curation)이 가능하게 될 수 있다. 변환 및 병합 서비스를 포함하는 액세스 서비스는 다양한 클라이언트를 위해 적합한 포맷으로 콘텐트 블록을 제공하기 위해 이용될 수 있다. 적어도 두 개의 URL(Uniform Resource Locator)를 이용하여 콘텐트 블록들이 검색될 수 있더라도 복수의 콘텐트 블록이 단일 문서로서 제시되는 문서 뷰가 기술된다.

Description

콘텐트 큐레이션을 위한 애플리케이션 프로그래밍 인터페이스{APPLICATION PROGRAMMING INTERFACES FOR CONTENT CURATION}

협업 소프트웨어(collaboration software)가 개선됨에 따라 협업 및 파일 공유가 쉬워지고 있다. 그러나, 모든 디바이스(device)가 공동 저작(co-authoring)과 협업을 지원할 수 있는 것은 아니다. 몇몇 디바이스는 협업을 위한 준비가 되어있지(collaboration-ready) 않거나 디지털 콘텐트를 액세스하고 수정하는 모든 시스템이 동일한 프로그램을 실행하고 있을 것을 요구한다. 디지털 콘텐트를 액세스, 공유 및 공동 저작하는 사람의 역량은, 부분적으로는, 디지털 콘텐트의 포맷을 인식하는 적절한 소프트웨어 프로그램 및 다른 사람(또는 다른 플랫폼 상에서 동일한 사람)에 의해 액세스되는 경우 디지털 콘텐트가 보여지고(viewed), 수정되며, 그 수정이 전파되어 디지털 콘텐트의 일부로서 반영될 수 있도록 프로그램을 실행시킬 수 있는 디바이스를 그 사람이 가지고 있는지에 의존적이다.

상이한 플래폼을 사용하는 디바이스들이 급증함에 따라, 상이한 포맷을 액세스하고 디스플레이하는 것만 가능하거나 특징의 더 이른 버전(version)으로써 콘텐트를 편집하는 것만 가능한 프로그램을 실행하는 디바이스로써 하나의 포맷의 콘텐트를 공유하고 액세스하고 편집하는 것은 도전적인 일일 수 있다. 추가로, 어떤 애플리케이션의 새로운 버전에 새로운 특징들이 추가됨에 따라, 새로운 버전은 역방향 호환가능성(backwards compatibility)을 지원해야 하고/하거나 향후 버전을 지원하기 위해 내장된 확장가능성(extensibility)을 가져야 한다. 나아가, 그 일부는 상이한 파일 포맷 또는 버전으로 된 것일 수 있는 다수의 파일들로부터 콘텐트를 조합하는 것이 요망될 수 있다.

애플리케이션 프로그래밍 인터페이스 및 액세스 서비스가 제공되는데 여기서는 하나 이상의 리소스로부터의 콘텐트(content)가 단일 문서(document)로서 사용자에게 제시될 수 있다. 이 문서, 또는 뷰(view)는 별도로 어드레스가능(addressable)하고 액세스 서비스를 통해 액세스될 수 있는 콘텐트의 애플리케이션(가령, 뷰어(viewer), 에디터(editor)) 정의된 블록들 또는 콘텐트의 사용자 정의된 블록들을 포함할 수 있다. 콘텐트 큐레이션(content curation)은 보다 대규모의 문서 프레임워크(document framework) 내의 콘텐트의 어드레스가능한 블록의 생성 및 콘텐트의 어드레스가능한 블록의 콘텐트 검색(content retrieval)을 가능하게 하는 애플리케이션 프로그래밍 인터페이스(Application Programming Interfaces: API)들을 통해 용이하게 될 수 있다.

일 실시예에 따르면, 변환 및 병합 서비스들을 수행하는 시스템에 의해 클라이언트에게 제공되는 문서는 한 세트(set)의 경험 및 그것의 내부의 콘텐트이다. 문서 또는 문서의 콘텐트의 선택된 블록은 시스템에 의해 검색 가능한 위치에 제1 파일 포맷으로 마스터 문서(master document)로서 저장될 수 있으며, 클라이언트에 의해 요청되는 경우 문서는 적절한 파일 포맷으로 변환되어 클라이언트에게 제공될 수 있다. 제공된 문서는 클라이언트에서 지원되는 특징의 버전을 고려할 수도 있다.

제공된 문서는 클라이언트 디바이스에 디스플레이될 수 있다. 서비스는 문서의 도달범위(reach)를 (변경되는 플랫폼을 가로질러 디바이스들로) 확장하고 클라이언트 디바이스에 적합한 그 문서를 위한 경험을 생성한다. 문서는 각각의 클라이언트 상에서 정확히 동일하게 보일 필요는 없다. 대신, 문서는 사용자의 경험을 위해 그리고 디바이스에 적합하도록 맞춤화될(customized) 수 있다. 클라이언트 디바이스에서 디스플레이되면, 사용자는 문서를 국부적으로(locally) 수정할 수 있다. 그 수정은 콘텐트에 대해서만 아니라 문서와 연관된 데이터에 대한 수정을 포함할 수 있다. 예를 들어, 주석, 코멘트, 텍스트 편집, 이미지 편집 및 다른 수정이 행해질 수 있다. 그리고 사용자는 그 수정을 도로 서버에 저장할 수 있다. 서버는 사용자가 수정한 문서가 상이한 파일 포맷으로 된 것이거나 특징의 상이한 버전을 포함하는 경우에도 수정을 병합할(merge) 수 있다.

마스터 문서 내에 수정을 병합하는 것에 더하여, 클라이언트 디바이스에 디스플레이된 문서의 전부 또는 식별된 부분은 다른 마스터 문서로서 저장되고 어드레스 서비스(address service)에 의해 어드레스(address)를 할당받을 수 있다.

일 구현에 따르면, 제1 문서의 제1 뷰가 디스플레이될 수 있다. 제1 문서는 제1 어드레스로부터 검색되고 필요하다면 적절한 포맷 또는 특징 버전으로 변환되어 클라이언트에게 제공될 수 있다. 클라이언트에 디스플레이된 문서 뷰 내에서 작업하는 사용자는 편집 또는 다른 추가 행동(action)을 위한 콘텐트의 서브세트(subset)를 선택할 수 있다. 선택된 부분은 식별된 콘텐트(identified content)일 수 있다. 식별된 콘텐트는 단락 식별자(paragraph identifier), 라인 식별자(line identifier), 문자 식별자(character identifier), 범위(range), 부분 식별자(part identifier) 또는 이 식별자들의 조합과 같은 위치 식별자(location identifier)를 이용하여 식별될 수 있다. 어드레스 서비스는 식별된 콘텐트를 위한 제2 어드레스를 획득하기 위해 기동될(invoked) 수 있다. 그리고 콘텐트의 이 서브세트는 제2 어드레스를 통해 액세스가능하고 별도로 수정가능할 수 있다.

다른 구현에 따르면, 적어도 두 개의 리소스들로부터의 콘텐트를 포함하는 문서 뷰는 클라이언트에게 제공될 수 있다. 예를 들어, 액세스 서비스는 적어도 제1 어드레스로부터의 콘텐트의 제1 블록 및 제2 어드레스로부터의 콘텐트의 제2 블록을 위한 요청으로 기동될 수 있다. 콘텐트의 제1 블록과 콘텐트의 제2 블록은 조합될 수 있다. 조합된 콘텐트 블록은 위치 식별자를 포함하는데, 이는 새로운 어드레스를 생성하는 데에 이용될 수 있다.

위치 식별자들 및 적어도 2개의 URL(Uniform Resource Locator: URL)을 이용하여 검색된 콘텐트를 구비한 복수의 블록을 포함하는 문서 뷰가 공급(또는 제공)될 수 있다. 하나 이상의 블록은 (그리고 콘텐트 블록의 서브세트도) 새로운 URL을 할당하는 것을 위해 선택가능하고 이 새로운 URL을 통해 별도로 액세스가능할 수 있다.

이 개요는 상세한 설명에서 추가적으로 후술되는 개념들 중 선택된 것을 단순화된 형태로 소개하기 위해 제공된다. 이 개요는 청구된 대상(claimed subject matter)의 주요 특징 또는 필수적인 특징을 식별하고자 의도된 것이 아니고, 청구된 대상의 범주를 한정하기 위해 사용되도록 의도된 것도 아니다.

도 1은 실시예들이 수행될 수 있는 동작 환경(operating environment)의 다이어그램(diagram)을 보여준다.
도 2는 발명의 일 실시예에 따라 종단점(endpoint)을 위한 동작 환경을 보여준다.
도 3은 발명의 일 실시예에 따른 컴퓨팅 환경(computing environment)을 보여준다.
도 4는 발명의 일 실시예에 따른 변환 및 병합 서비스(conversion and merge service)를 위한 예시적 절차 흐름을 보여준다.
도 5a 내지 도 5d는 변환 및 병합 서비스의 예시적 시나리오들을 도시한다.
도 6은 발명의 일 실시예에 따라 에디터에 의해 수행되는 절차의 다이어그램을 보여준다.
도 7은 발명의 일 실시예에 따라 다양한 에디터를 이용하여 문서에 대해 협업하기 위한 방법의 절차 흐름 다이어그램을 보여준다.
도 8은 몇몇 실시예에서 사용되는 컴퓨팅 디바이스의 요소를 도시한 블록 다이어그램을 보여준다.
도 9는 발명의 일 실시예에 따라 어드레스가능한 콘텐트 블록들을 갖는 문서 뷰의 다이어그램을 보여준다.
도 10은 발명의 일 실시예에 따른 콘텐트 큐레이션을 위한 시스템의 다이어그램을 보여준다.
도 11은 문서의 콘텐트의 서브세트를 위한 새로운 어드레스를 생성하는 예시적 시나리오를 도시한 것이다.
도 12는 문서로부터 생성된 콘텐트의 서브세트를 이용하여 협업하는 방법의 절차 흐름 다이어그램을 보여준다.
도 13은 예시적 실시예를 도시하는 동작 환경의 다이어그램을 보여준다.
도 14는 큐레이션된(curated) 콘텐트를 액세스하기 위한 방법의 절차 흐름 다이어그램을 보여준다.

애플리케이션 프로그래밍 인터페이스 및 액세스 서비스가 제공되는데 여기서는 하나 이상의 리소스로부터의 콘텐트가 단일 문서로서 사용자에게 제시될 수 있다. 이 문서, 또는 뷰는 별도로 어드레스가능하고 액세스 서비스를 통해 액세스될 수 있는 콘텐트의 애플리케이션(가령, 뷰어, 에디터) 정의된 블록들 또는 콘텐트의 사용자 정의된 블록들을 포함할 수 있다. 콘텐트 큐레이션(그리고 보급(dissemination))은 문서의 식별가능한 영역을 위한 어드레스를 생성하고 생성된 어드레스로부터 콘텐트를 검색하기 위한 애플리케이션 프로그래밍 인터페이스(Application Programming Interface: API)를 통해 용이하게 될 수 있다.

콘텐트 큐레이션은 다양한 소스로부터의 콘텐트의 편제(organization) 및 제시(또는 공유)이다.

콘텐트의 어떤 단편(piece)들이 서로로부터 분리되어 위치되고 서로 상이한 포맷으로 저장될 수도 있더라도 콘텐트의 이 단편들은 리더(reader), 에디터 또는 다른 클라이언트에 의해 결합적 단편(cohesive piece)으로서 보여질 수 있는 단일 문서로서 조합될 수 있다.

이는 콘텐트의 각 정의된 블록을 위한 어드레스를 가짐으로써 성취될 수 있다. 액세스 서비스는 하나 이상의 콘텐트 블록 어드레스를 포함하는 요청을 취하고, 하나 이상의 콘텐트 블록 어드레스로부터 다양한 콘텐트 블록을 검색하며, 조합된 콘텐트를 클라이언트에게 제공할 수 있다. 문서 뷰 내에서, 블록의 경계는 클라이언트가 블록들을 조합하거나 나눌 수 있을 정도로 동적(dynamic)일 수 있다. 예를 들면, 클라이언트는 본래 하나의 블록(이는 단일 어드레스를 가지며 문서를 이루는 요소들은 그 단일 어드레스를 통해 액세스될 수 있음)으로 형성된 문서의 뷰를 제시할 수 있다.

문서를 보는 동안, 사용자는 다른 문서나 애플리케이션에서의 사용을 위해 콘텐트의 적어도 하나의 양상(aspect)을 캡쳐(capture)하기를 원할 수 있다. 이 시나리오에서, 사용자는 문서의 식별된 부분을 위한 어드레스를 요청할 수 있다. 그 부분은 위치 식별자를 사용하여 콘텐트의 블록으로서 식별될 수 있다. 새로운 어드레스가 생성되는 경우, 다른 클라이언트(또는 서버)는 어드레스 위치로부터의 콘텐트를 얻음으로써 그 식별된 부분을 사용하여 생성된 어드레스를 갖는 블록을 액세스할 수 있다. 몇몇 경우에 문서는 복수의 이 상이한 블록들로부터 생성될 수 있다. 몇몇 경우에, 블록이 업데이트되는 경우, 문서가 업데이트된다. 단일 어드레스는 다수의 저장 디바이스 및 분산 컴퓨팅 환경(distributed computing environment)을 수반하는 리소스를 나타낼 수 있음이 이해되어야 한다.

전자 문서는 일반적으로 종이 문서의 디지털 균등물로 이해되는데, 여기서 문서 에디터는 콘텐트의 생성, 주석(annotation), 수정, 그리고 최근에는 공유 및 협업을 용이하게 한다.

그 수정은 콘텐트에 대한 것뿐만 아니라 문서와 연관된 데이터에 대한 수정을 포함한다. 예를 들어, 코멘트, 텍스트 편집, 이미지 편집 및 다른 수정이 행해질 수 있다. 파일에 대한 수정은 가산적(additive), 감산적(subtractive)인 행동, 추가적 콘텐트, 리치 콘텐트(rich content)를 제공하는 행동, 코멘트를 추가하는 행동, 그리고 이미지 에디터 내에서 이미지를 수정하는 행동을 포함할 수 있다.

발명의 어떤 실시예는 문서에 새로운 특징을 부가한다 - 서비스로서의 문서(document as a service), 여기서 문서는 경험의 세트 및 그것의 내부의 콘텐트를 제공한다. 경험의 세트는 변환 및 병합 서비스의 콘텐트 액세스 서비스를 포함하는 서비스의 세트에 대응한다. 변환 서비스는 문서의 콘텐트로 하여금 문서가 보여지는 각 클라이언트에 대해 맞춤화될 수 있게 하고 병합 서비스는 문서에 대한 수정으로 하여금 마스터 문서와 재통합될(re-integrated) 수 있게 한다. 마스터 문서는 콘텐트, 메타데이터 및 문서에 행해진 수정(콘텐트에 대한 수정 및 메타데이터에 대한 수정을 포함함)의 집합체(aggregation)일 수 있다. 몇몇 경우에, 마스터 문서는 가장 높은 충실도(fidelity) 문서로 나타날 수 있다.

그러므로, 더 낮은 충실도 에디터 내로부터 행해진 수정 또는 특징의 더 이른 버전을 사용하는 수정이 마스터문서 내에 재통합되는 경우, 서비스는 충실도 복원(fidelity rehydration)을 수행할 수 있다.

충실도 복원은 특징의 더 이른 버전 - 또는 더 적은 기능을 구비한 에디터를 갖는 파일 포맷 - 에 의해 수정된 콘텐트의 취득(taking), 그리고 콘텐트를 완전한 기능의, 최신 특징 버전으로 복귀시키는 것을 나타낸다. 일 예로서, 그래프 특징(graph feature)의 두 버전 - (3D 차트들과 같은) 리치 차트(rich chart)들을 갖는 제1 버전 및 정적 이미지(static image)들로서 그 차트들을 해석할 수 있을 뿐인 제2 버전 - 이 주어지면 제2 버전을 지원하는 에디터 내에서 콘텐트가 편집된 후, 정적 이미지들은 제1 버전을 지원하는 에디터에서 보기(viewing)/편집하기를 위해 도로 3D 차트인 것으로 복원될 수 있다. 제1 버전은 그 특징의 향후 또는 추후의 버전일 수 있으며 제2 버전은 해당 특징의 이전 또는 더 이른 버전일 수 있다. 다른 경우에, 양 버전 모두 동일한 시간에 배포될(released) 수 있으나, 이용가능한 기능성에서의 의도적인 차이를 가질 수 있다.

마스터 문서가 문서로서 지칭되기는 하나, 마스터 문서는 콘텐트 및 최신의 편집 특징을 추적하기(tracking)에 적합한 임의의 포맷으로 저장될 수 있다.

이들 서비스를 통해, 소비자 디바이스는 클라이언트 측 소프트웨어나 소비 디바이스에 복잡성을 부가함 없이 다양한 플랫폼에 걸쳐 콘텐트를 액세스하고 수정할 수 있다.

문서 보기의 유연성(flexibility)을 진척시키기 위해, 문서의 블록(사용자 또는 애플리케이션 정의된 부분)은 독립적인 사용 또는 도로 마스터 문서로 병합하는 것을 위해 별도로 액세스되고 보여지며 수정될 수 있다.

(문서 또는 다른 콘텐트 및 관련된 정보를 위한) 파일 포맷은 파일(그리고, 몇몇 경우에는, 연관된 정보)의 콘텐트와 관련된 정보가 컴퓨터 판독가능 매체(computer-readable medium) 상에 인코딩되고 저장되는 방식을 나타낸다. 파일 유형은 파일 포맷과 상호교환가능하게 사용될 수 있으나, 일반적으로 파일 포맷의 분류를 나타낸다. 예를 들어, 파일 유형은 문서 파일 유형일 수 있는데, 이는 하이퍼텍스트 마크업 언어(HyperText Markup Language: HTML), ADOBE 포터블 문서 포맷(Portable Document Format: PDF), 마이크로소프트 워드(MICROSOFT WORD) 문서 (DOC), 오피스 오픈 확장가능 마크업 언어(Office Open Extensible Markup Language: OOXML) 포맷(DOCX) 및 유사한 것의 파일 포맷을 포함한다. MICROSOFT WORD는 마이크로소프트 사(MICROSOFT Corp.)의 등록된 상표이고; ADOBE PDF는 ㅇ어어도비 시스템즈 사(Adobe Systems, Inc.)의 등록된 상표이다.

본 문서에서 사용되는 바와 같이 "소비용 포맷"(consumption format)은 특정 디바이스 또는 소프트웨어 프로그램에 의해 지원되는 파일 포맷(가령, "지원되는 파일 포맷")을 나타낸다. 지원되는 파일 포맷인 것뿐만 아니라, 소비용 포맷은 어떻게 디바이스(또는 프로그램)가 다채로운 사용자 경험을 지원할 수 있는지에 관한 파일 크기, 기능 및 유사한 것에 관련된 특징을 포함할 수 있다.

서비스로서의 문서 패러다임(document-as-a-service paradigm)으로 돌아와서, 변환 및 병합 서비스를 포함하는 콘텐트 액세스 서비스는 클라우드 서비스 경험(cloud service experience)의 일부로서 제공될 수 있다. 이런 방식으로, 콘텐트는 하나의 포맷으로 생성되며 이후에는 콘텐트의 소비자에게 무결절의 경험(seamless experience)을 제공할 수 있는 방식으로 임의의 플랫폼에 걸쳐 액세스가능하고 편집가능할 수 있다.

도 1은 어떤 실시예가 수행될 수 있는 동작 환경의 다이어그램을 보여준다.

도 1을 참조하면, 동작 환경은 하나 이상의 클라우드 또는 웹 서비스를 포함할 수 있다. 본 문서에서 기술된 콘텐트 액세스 서비스(100)는 클라우드 서비스 또는 웹 서비스일 수 있다.

클라우드 서비스는 일반적으로 스케일가능한(scalable) 처리 및 저장 능력을 제공하는 호스팅되는(hosted) 서비스를 나타낸다. 클라우드 컴퓨팅(cloud computing)은 흔히 가상화된 리소스를 포함할 수 있다. 클라우드 컴퓨팅에 의해 제시되는 리소스는 그 자체로는 서비스로서 제공되는데, 여기서 클라우드 컴퓨팅 소비자는 물리적 인프라스트럭처를 소유한 제3자 제공자(third-party provider)로부터 리소스의 사용을 빌린다(rent).

웹 서비스는 (가령, 대규모(large-scale) 분산 컴퓨팅 환경의 일부로서) 클라우드 서비스에 의해 제공되고/되거나 호스팅될 수 있다. 웹 서비스는 네트워크 상에서 상호운용가능한 머신 대 머신 상호작용(machine-to-machine interaction)을 지원하고 소프트웨어로 하여금 다른 소프트웨어 애플리케이션에 연결할 수 있게 하는 소프트웨어 시스템이다.

웹 서비스는 기술적 표준 및 프로토콜의 모음(collection)을 제공한다. 예를 들어, 웹 서비스는 메시지를 송신하고 수신하는 소프트웨어 또는 하드웨어 에이전트에 의해 실행될 수 있는 기능을 제공한다(가령, 특정 서비스를 요청하고 제공하는 컴퓨팅 플랫폼). 애플리케이션은 하이퍼텍스트 전송 프로토콜(HyperText Transfer Protocol: HTTP), 확장가능 마크업 언어(eXtensible Markup Language: XML), 웹 서비스 서술 언어(Web Services Description Language: WSDL), 자바스크립트 오브젝트 표기(JavaScript Object Notation: JSON) 및 SOAP(본래 단순 오브젝트 액세스 프로토콜(Simple Object Access Protocol)에 대한 두문자어(acronym))와 같은 유비쿼터스 웹 프로토콜 및 데이터 포맷을 통해 웹 서비스를 액세스 할 수 있다.

표현적 상태 전이(Representational State Transfer: REST) 프로토콜은 지명된 리소스를 액세스하는 경우 유용하며 발명의 어떤 실시예에서 사용될 수 있다. 발명의 다른 실시예에서는 SOAP가 활용될 수 있다. 몇몇 경우에, 마이크로소프트 사로부터의 HTTP 상의 SOAP를 통한 파일 동기화 서비스(File Synchronization Service via SOAP over HTTP: FSSHTTP)가 사용될 수 있다.

콘텐트 액세스 서비스(100)는 네트워크 상에서 통신하는 하나 이상의 물리 및/또는 가상 서버를 이용하여 구현될 수 있다. 네트워크는 셀룰러 네트워크(cellular network)(가령, 무선 전화), 점대점 다이얼 업 연결(point-to-point dial up connection), 위성 네트워크, 인터넷, 로컬 영역 네트워크(Local Area Network: LAN), 광역 네트워크(Wide Area Network: WAN), 와이파이 네트워크(WiFi network), 애드혹 네트워크(ad hoc network) 또는 이들의 조합을 포함할 수 있으나, 이에 한정되지는 않는다. 그러한 네트워크는 허브, 브릿지, 라우터, 스위치, 서버 및 게이트웨이와 같은 다양한 유형의 네트워크 요소들을 연결하는 데에 널리 사용된다. 그 네트워크는 인터넷과 같은 공용 네트워크 및/또는 보안용 기업 사설 네트워크(secure enterprise private network)와 같은 사설 네트워크를 포함하는 g하나 이상의 연결된 네트워크(가령, 다중 네트워크 환경(multi-network environment))를 포함할 수 있다. 네트워크에 대한 액세스는 당업자에 의해 이해될 바와 같이 하나 이상의 유선 또는 무선 액세스 네트워크를 통해 제공될 수 있다.

콘텐트 액세스 서비스(100)는 이입/변환 부분(import/convert portion)(102) 및 렌더링/변환 부분(render/convert portion)(104)을 포함할 수 있다. 다양한 소스(106)로부터의 문서는 콘텐트 액세스 서비스(100)로 이입될(imported) 수 있다. 이입/변환 부분(102)은 콘텐트를 리더에 의해 요구되는 특정 포맷으로 하는 것에 대한 제약을 줄이거나 제거하여 자기 출판(self-publishing)을 용이하게 할 수 있다. 예를 들어, 서점(bookstore) 또는 다른 저장소(repository) 또는 스토어(store)로의 자기 출판은 지정된 파일 포맷 내에서 창작자(creator)가 작업할 것을 요구하는 것 없이 성취될 수 있다. 창작자들이 그들의 작품을 발행하는 것을 더욱 쉽게 함으로써, 리더 사용자들이 더 많은 콘텐트에 대한 액세스를 가질 수 있다.

"리더"는 주로 전자 책(이북) 및/또는 다른 전자 콘텐트를 읽는 것을 위해 설계된 소프트웨어 애플리케이션 및/또는 전자 디바이스를 나타낸다. 리더는 흔히 주석달기(annotating), 하이라이팅(highlighting), 북마킹(bookmarking) 및 선긋기(scribing)와 같은 적어도 몇몇 기본적인 편집 기능을 포함한다.

예시적인 소프트웨어 이북 리더(software ebook reader)(또는 e-리더)들은 구글 사(Google Inc.)로부터의 구글 리더(GOOGLE READER) 애플리케이션, 애플 사(Apple Inc.)로부터의 애플 아이북(APPLE IBOOKS) 애플리케이션, 어도비 시스템즈 사(Adobe Systems Inc.)로부터의 어도비 아크로뱃 이북 리더(ADOBE ACROBAT EBOOK READER) 애플리케이션, 그리고 마이크로소프트 사(Microsoft Corp.)로부터의 마이크로소프트 리더(MICROSOFT READER) 애플리케이션을 포함한다. 예시적인 하드웨어 이북 리더(hardware ebook reader)(또는 e-리더)들은 아마존닷컴 사(Amazon.com Inc.)로부터의 아마존 킨들(AMAZON KINDLE) 브랜드의 e-리더 및 반즈 앤드 노블 사(Barnes & Noble Inc.)로부터 이용가능한 반즈 앤드 노블 누크(BARNES AND NOBLE NOOK) 브랜드의 e-리더 태블릿을 포함한다. 이북은 이북 리더(ebook reader) 상에서 판독될 수 있는 디지털 형태의 텍스트 및/또는 이미지 기반 발행이다. 전자 출판(electronic publication: ePub), HTML, PDF, 프린터 명령 언어(Printer Command Language: PCL) 및 확장가능 마크업 언어(eXtensible Markup Language: XML)와 같은, 콘텐트를 만들어 출판하는 데 사용되는 다양한 이북 및 다른 디지털 콘텐트 포맷들이 있다.

몇몇 경우에, 이입된 문서(가령, 불러오기/변환 부분(102)을 통해서임)는 클라우드의 일부(108)로서 (주소 또는 URI(Uniform Resource Identifier)가 저장되어 있음으로써) 저장되거나 저장된 것으로 나타날 수 있다. 콘텐트 액세스 서비스(100)는 스토리지(storage)(108) 상의 동작들로 분해되거나(resolve) 어떤 동작들을 (스토리지(108)를 직접적으로 또는 간접적으로 액세스할 수 있는) 다른 서비스에 위임할 수 있다.

문서 파일은 콘텐트 액세스 서비스(100)로부터 이출될(exported) 수 있다. 이출되기 전에, 이입된 문서들 중 하나와 같은 문서 파일은 리더(110), 프린터(112), 제3자 사이트(114) 및 이차적 변환 서비스(116)와 같은 종단점에 의한 소비(가령, 디스플레이를 위한 렌더링, 상호작용, 수정, 또는 프린팅과 추가적인 변환을 포함하는 추가적 행동)를 위해 다양한 포맷으로 변환될 수 있다.

종단점은 소비자가 서비스 - 상호작용을 위한 진입 지점(entry point) - 를액세스하는 수단을 나타낸다. 다양한 실시예에 따르면, 도달범위를 확장하고 디바이스에 기반하여 콘텐트가 소비되는 방식을 변화시키는 종단점 맞춤화(endpoint customization)가 제공된다.

종단점은 하나 이상의 소비자 디바이스일 수 있다.

소비자 디바이스는 서비스 또는 소스로부터 검색되거나 구매된 데이터 또는 문서를 소비(즉 보기/판독하기, 편집, 또는 주석 달기를 위해 사용)하는 데 사용되는 컴퓨팅 디바이스를 나타낸다. 소비자 디바이스는 전자 책을 읽기 위해 사용되는 주로 단일한 목적의 컴퓨팅 디바이스(primarily single purpose computing device)(흔히 리더로 지칭됨)이거나 전자 책 또는 다른 전자/디지털 콘텐트를 판독하기 위한 리더 또는 뷰어 소프트웨어가 제공될 수 있는 다목적 컴퓨팅 디바이스(multi-purpose computing device)일 수 있다.

"뷰어"는 특정 프로그램과 연관된 포맷 또는 파일 유형의 문서 또는 데이터를 디스플레이하거나 디스플레이하는 것으로 나타날 수 있는 소프트웨어 또는 하드웨어 애플리케이션을 나타낸다. 특정 파일 포맷을 위한 뷰어는 특정 파일 포맷을 이해하고 파일의 시각화를 제시할 수 있다. 전형적으로, 파일 포맷의 "뷰어"는 저자의 본래의 의도를 유지하면서, 높은 신뢰성으로 그 파일 포맷을 시각적으로 제시할 수 있다고 가정된다. "리더"는 동영상으로 된 페이지 넘김(animated page turns)을 제공하기, 최근 읽은 위치를 기억하기, 단어를 찾기 위한 사전을 제공하기 등등과 같은 "읽기" 경험과 주로 연관된 기능을 포함하는 뷰어의 유형이다.

서비스는 문서의 도달범위를 (다양한 플랫폼에 걸쳐 디바이스로) 확장하며 클라이언트 디바이스에 적합한 그 문서를 위한 경험을 만들어낸다. 문서는 각각의 클라이언트 상에서 정확히 동일하게 보일 필요는 없다. 대신, 문서는 사용자의 경험 위해서 그리고 디바이스에 적합하도록 맞춤화될 수 있다.

제3자는 추가적인 사용자 경험을 만들어내기 위하여 문서를 사용할 수 있다.

디바이스를 인지함으로써, 시스템(가령, 서비스(100)을 통해서임)은 맞춤화된 파일 포맷화를 제공할 수 있다. 예시적 시나리오로서, 누크(NOOK) 리더 또는 킨들(KINDLE) 리더 사용자는 읽고자 하는 이용가능한 콘텐트를 훑어보기 위해 그 디바이스를 사용할 수 있다. 서비스(100)는 어떤 디바이스가 사용되고 있고 콘텐트의 제시를 적절하게 조정하는지(tailor) 결정할 수 있다. 예를 들어, ePub2 또는 ePub3 포맷은 누크(NOOK) 리더에 보내질 수 있으며 AZW 포맷은 킨들(KINDLE) 리더로 보내질 수 있다.

맞춤화된 파일이 디바이스에 보내지면, 파일은 도로 서버에 (서비스(100)를 통해) 세이브될(saved) 수 있다. 예를 들어, 특정한 액션(누크(NOOK) 리더, 킨들(KINDLE) 리더, 또는 편집 애플리케이션을 실행하는 태블릿 내에서 편집하기 또는 주석 달기와 같은 수정)은 클라이언트에게 제공되는 파일에 대해 취해질 수 있고, 이 수정들은 파일을 위한 마스터 문서에 병합될 수 있다.

발명의 어떤 실시예는 변경된 블록(들)이 마스터 문서와의 병합 없이 독립적인 액세스를 위한 별개의 어드레스를 할당받을 수 있게 한다.

추가 실시예에서, 사용자를 또한 인지하는 것에 의해(예를 들어, 사용자가 디바이스로부터 그들의 계정으로 로그인하는 경우와 같이 사용자로부터 식별자를 수신하는 것에 의해), 시스템은 (가령, 서비스(100)를 통해) 그들의 디바이스가 다룰 수 있는 버전 또는 파일 포맷에 사용자가 관심을 가질 필요 없이 사용자로 하여금 많은 디바이스 상에서 네트워크를 넘어 그들 자신의 파일을 액세스할 수 있게 할 수도 있다. 사용자가 그들 자신의 파일을 액세스할 수 있도록 하는 것에 더하여, 사용자를 인지함에 의해, 시스템은 사용자와 연관된 작업에 관련된 문서 내에 특정 콘텐트를 제시하도록 파일을 맞춤화할 수 있다. 예를 들어, 사용자가 단락을 검토하는 일을 맡게 되는 경우, 그 단락은 그 문서에 대한 액세스를 가질 수 있는 모든 사용자 대신에 그 식별된 그 사용자에게 제공될 수 있다. 하나의 실시예에서, 이는 그 특정 사용자에게 그 단락 블록으로의 링크 또는 어드레스를 제공함으로써 성취될 수 있다

종단점은 서비스(100)와의 통신의 두 가지 일반적인 카테고리를 가질 수 있다. 하나는 쌍방향의 풍성한 경험(two-way rich experience)이고, 다른 하나는 더욱 제한된 경험이다. 두 경우 모두에서, 발명의 실시예를 사용하여, 종단점은 파일 포맷 변환을 다루거나, 모든 포맷을 랜더링하는 것이 가능하거나, 콘텐트의 공동 저작을 위한 계층(layer)을 포함할 것이 요구되지 않는다.

다양한 풍성함(richness)의 종단점은 발명의 다양한 실시예에 의해 지원될 수 있다. 본 문서에서 사용된 바와 같이, "풍성함"은 애플리케이션 및 그것이 사용자에게 특정 콘텐트와 기능을 제시하는 능력에 따른 이용가능한 경험의 스펙트럼을 나타낸다. 예를 들어, 가장 풍성한 소비 경험은 전 특징의(full-featured) 애플리케이션(여기에서는 콘텐트의 편집 및 조작이 이용가능함)(가령, 종단점 에디터(118))을 지원하는 디바이스를 통해 이용가능할 수 있다. 더 제한적인 경험은 미소한 크기의(bite-sized) 저작 도구(여기에서는 콘텐트의 편집 및 조작을 위한 약간의 기능이 유지됨)(가령, 제한된 종단점 에디터(120))를 포함한다. 더 제한된 경험(또는 "단출한 편집"(light-weight editing)) 및 전 특징의 에디터(또는 "묵직한 편집(heavy editing)")의 차이는 단출한 편집이 주석달기와 코멘트하기(commenting)만 지원할 수 있다는 것이다.

콘텐트가 보여질 수 있는 리더(가령, 소비자 디바이스(122))는 다양한 지원되는 풍성함을 가질 수 있다. 모든 에디터 유형은 물론 특징의 버전이 지원될 수 있다.

액세스 서비스(100)에 의해 제공되는 변환 및 병합 서비스는 클라이언트 디바이스 또는 다른 서버(가령, 리더(110) 또는 소비 디바이스(122), 종단점 에디터(118) 또는 소비 및 제한된 종단점 에디터(120))에 의해 직접적으로 요청될 수 있다. 몇몇 실시예에서, (도 2에 관하여 기술된 것과 같은) 서버 또는 제3자 사이트(가령, 114) 또는 이차적 변환 서비스(가령, 116)는 클라이언트 디바이스를 위하여 서비스(100)를 액세스할 수 있다. 프린터(112)가 변환 및 병합 서비스(100)로부터 직접적으로든 또는 다른 클라이언트 디바이스를 통해서든 콘텐트를 수신할 수도 있다.

하나의 프레임워크(framework)(이에 의해 종단점 에디터(118)는 웹 서비스(가령, 서비스(100))와 통신할 수 있음)는, FSSHTTP 애플리케이션 프로그래밍 인터페이스(Application Programming Interface: API)를 사용하여 마이크로소프트 쉐어포인트(MICRO SHAREPOINT) 웹 애플리케이션 플랫폼과 같은 서버 상에서 실행되는 문서 및 파일 관리 및 협업 프로그램(document and file management and collaboration program)에 클라이언트 애플리케이션이 변화를 효율적으로 동기화하도록 하는 프레임워크를 통해서이다. FSSHTTP 프로토콜의 클라이언트 측은 통과지점(pass-through)이다. 예를 들어, 애플리케이션 계층과 같은 더 상위 계층의 프로토콜(higher-layer protocol)에 의해 행해진 콜(call)들은 직접적으로 전송 계층(transport layer)에 넘겨지고, 전송 계층에 의해 반환된 결과는 도로 더 상위 계층의 프로토콜 또는 애플리케이션에 직접적으로 넘겨진다.

API는 일반적으로 프로그래밍 명령어 및 표준(둘 이상의 애플리케이션이 서로 통신할 수 있도록 함)의 세트이며, 보통 HTTP 요청 메시지 및 지정된 포맷 또는 구조(응답 메시지를 위한 것)의 세트로서 구현된다. 그 메시지는 정보 리소스(information resource)를 포함할 수 있다. 리소스(resource)는 URI(Uniform Resource Identifier)에 의해 식별될 수 있는 정보이며, 파일, 동적으로 생성된 질의 결과(dynamically-generated query result), 공통 게이트웨이 인터페이스(Common Gateway Interface: CGI) 스크립트의 출력, 몇몇 언어에서 이용가능한 문서, 그리고 유사한 것일 수 있다.

몇몇 실시예에 따르면, API는 리소스를 액세스하기 위한 어드레스를 생성하기 위해 제공될 수 있다. API는 리소스를 액세스하기 위해 생성된 어드레스에서 콘텐트를 요청하기 위해 또한 제공될 수 있다. 콘텐트에 대한 요청은 콘텐트를 위한 특정한 포맷에 대한 요청을 포함할 수 있다. API는 콘텐트로 하여금 그 어드레스에 되돌려질(put back)(또는 "푸시(push)") 수 있게 하기 위해 또한 제공될 수 있다. 푸시는 병합 또는 덮어쓰기(overwrite)를 포함할 수 있다.

변환 및 병합 서비스(100)는 웹 애플리케이션 컴포넌트(Web Application Component: WAC)(132)뿐만 아니라 더 폭넓은 클라우드 서비스(130)에 연관될 수 있다. WAC는 사용자가 브라우저 내에서 문서를 보고 편집할 수 있도록 하는 컴포넌트이다. WAC는 콘텐트를 소비하고 편집하는 것에 의해 종단점으로서도 그리고 어떤 병합 및 변환 서비스 기능을 제공하는 것에 의해 서비스로서도 기능할 수 있다. 그러한 실시예에서, 사용자는 인프라스트럭처 및 플랫폼을 관리하는 클라우드 상의 애플리케이션 소프트웨어 또는 데이터베이스에 대한 액세스를 갖는다. 최종 사용자(end user)들은 브라우저 또는 앱(스마트폰 및 태블릿과 같은 모바일 디바이스를 위해 설계된 애플리케이션)을 통해 클라우스 상에서 호스팅되는 소프트웨어 애플리케이션을 액세스한다. 일 예가 도 2에 관해 기술된다.

도 2는 발명의 일 실시예에 따른 종단점을 위한 동작 환경을 보여준다. 도 2를 참조하면, 클라이언트(210) 및 서버(220)는 네트워크(230)를 통해 통신한다.

네트워크(230)는 인터넷, 인트라넷(intranet) 또는 엑스트라넷(extranet)일 수 있으며, 셀룰러(가령, 무선 전화) 네트워크, 인터넷, 로컬 영역 네트워크(Local Area Network: LAN), 광역 네트워크(Wide Area Network: WAN), 와이파이 네트워크, 애드혹 네트워크, 또는 이들의 조합을 포함하나, 이에 한정되지는 않는 임의의 적합한 통신 네트워크일 수 있다.

앞서 기술된 바와 같이, 그러한 네트워크는 허브, 브릿지, 라우터, 스위치, 서버 및 게이트웨이와 같은 네트워크 요소의 연결을 수반할 수 있다. 네트워크(230)는 인터넷과 같은 공용 네트워크, 그리고/또는 보안용 기업 사설 네트워크와 같은 사설 네트워크를 포함하는 하나 이상의 연결된 네트워크(가령, 다중 네트워크 환경)를 포함할 수 있다. 네트워크(230)로의 액세스는, 당업자에 의해 이해될 바와 같이, 하나 이상의 유선 또는 무선 액세스 네트워크(도시되지 않음)를 통해 제공될 수 있다.

클라이언트(210) 및 서버(220)는 하나 이상의 중앙 처리 유닛(Central Processing Unit: CPU), 메모리, 대용량 스토리지(mass storage), 및 I/O 디바이스(가령, 네트워크 인터페이스, 사용자 입력 디바이스)로써 구성된 컴퓨팅 시스템을 수반할 수 있다. 컴퓨팅 시스템의 요소들은 버스(bus)를 통해 서로 통신할 수 있다. 컴퓨팅 시스템의 하드웨어 플랫폼은 개인용 컴퓨터(personal computer), 서버 컴퓨터(server computer), 핸드헬드(hand-held) 또는 랩톱(laptop) 디바이스, 멀티프로세서 시스템(multiprocessor system), 마이크로프로세서 기반 시스템(microprocessor-based system), 프로그래밍가능한 소비자 전자기기, 그리고 위의 시스템 또는 디바이스 중 임의의 것을 포함하는 분산 컴퓨팅 환경(가령, 클라우드 기반 컴퓨팅 시스템)(그리고 애플리케이션 기능, 메모리, 데이터 스토리지 및 검색 그리고 다양한 처리 기능이 인터넷 또는 인트라넷과 같은 분산 컴퓨팅 네트워크 상에서 서로로부터 원격으로 동작될 수 있는 경우)를 포함하나 이에 한정되지는 않는 여러 형태로 구현화될 수 있다.

어떤 실시예에서, 클라이언트(210)는 개인용 컴퓨터, 태블릿, 리더, 모바일 디바이스, 개인용 디지털 보조기기(Personal Digital Assistant: PDA), 스마트폰, 랩톱(또는 노트북 또는 넷북) 컴퓨터, 게이밍(gaiming) 디바이스 또는 콘솔, 데스크톱 컴퓨터, 또는 스마트 텔레비전을 포함하나 이에 한정되지는 않는 컴퓨팅 디바이스로서 구현화될 수 있다.

어떤 실시예에서, 서버(220)는 서버 컴퓨터, 엔터프라이즈 컴퓨터(enterprise computer), 개인용 컴퓨터, 멀티프로세서 시스템, 마이크로프로세서 기반 시스템 및 이들의 조합을 포함하나 이에 한정되지는 않는 컴퓨팅 디바이스로서 구현화될 수 있다. 클라이언트 컴퓨팅 디바이스 및 서버 컴퓨팅 디바이스의 목록화(listing)는 한정적이도록 의도된 것이 아니라는 점 및 클라이언트 및 서버가 동일 또는 상이한 형태로 구현화될 수 있다는 점이 이해되어야 한다.

클라이언트 컴퓨팅 디바이스(210)는 운영 체제(Operating System)(211) 및 (예시된 실시예에서는, 워드 프로세싱 또는 에디터 애플리케이션(212), 웹 브라우저 애플리케이션(213) 및/또는 하나 이상의 다른 애플리케이션과 같은) 하나 이상의 애플리케이션 프로그램을 실행하도록 구성된다.

운영 체제(211)는 클라이언트 컴퓨팅 디바이스(210)의 동작을 제어하기 위한 컴퓨터 프로그램이다. 애플리케이션 프로그램은 본 문서에서 기술된 바와 같은 다양한 기능을 제공하기 위해 운영체제(211)의 상부에서 실행되도록 구성된 실행가능한 프로그램이다. 워드 프로세싱 애플리케이션은 일반적으로 타이핑(typing), 편집, 포맷화(formatting), 세이브하기, 프린팅 및 코멘트하기를 가능하게 하도록 구성된 애플리케이션 프로그램이다. 에디터 애플리케이션은 편집 또는 주석달기 도구를 제공하는 임의의 애플리케이션일 수 있으며 워드 프로세싱 애플리케이션 또는 다른 생산성 애플리케이션(예컨대 마이크로소프트 사(Microsoft Corp.)로부터 이용가능한 MICROSOFT OFFICE, 구글 사(Google Inc.)로부터 이용가능한 GOOGLE DOCS, 아파치 소프트웨어 파운데이션(Apache Software Foundation)으로부터 이용가능한 APACHE OPENOFFICE, 또는 조호 사(Zoho Corporation)로부터 이용가능한 ZOHO OFFICE)일 수 있다.

생산성 애플리케이션은 워드프로세싱 프로그램, 협업 프로그램, 프리젠테이션 프로그램, 스프레드시트 프로그램 및 스토리텔링(storytelling)/필기(note-taking) 프로그램을 포함하나 이에 한정되는 것은 아니다.

웹 브라우저 애플리케이션(213)은 월드 와이드 웹(World Wide Web)("웹"(the Web)) 상의 정보 리소스뿐만 아니라 사설 네트워크 내의 웹 서버에 의해 제공되는 리소스들을 네트워크(230)을 통하여 검색하고 거쳐가는 것(traversing) 및 사용자에게 정보 리소스를 제시하는 것(가령, 디스플레이를 위한 렌더링)을 위한 애플리케이션 프로그램이다. 더욱이, 웹 브라우저 애플리케이션(213)은 사용자로 하여금 서버에 의해 제공되는 정보 및 다양한 기능을 액세스하게 한다.

예시된 서버 컴퓨터(220)는 서버 운영 체제(221), 서버 워드 프로세싱 또는 에디터 애플리케이션(222)과 같은 하나 이상의 애플리케이션 프로그램, 그리고/또는 하나 이상의 다른 애플리케이션을 실행하도록 구성된다. 서버(220)는 또한 서비스를 호스팅(하고 도 1에 기술된 바와 같은 WAC(132)를 포함)하고 있을 수 있다.

서버 운영 체제(221)는 서버 컴퓨터(220)의 동작을 제어하기 위한 컴퓨터 프로그램이며, 애플리케이션 프로그램은 본 문서에서 기술된 다양한 기능을 제공하기 위해 서버 운영 체제(221)의 상부에서 실행되도록 구성된 실행가능한 프로그램이다. 서버 워드프로세싱 또는 에디터 애플리케이션(222)은, 몇몇 실시에에서, 앞서 기술된 워드프로세싱 또는 에디터 애플리케이션(212)과 유사하게 구성된 웹 기반 애플리케이션 프로그램이다. 서버 워드프로세싱 또는 에디터 애플리케이션(222)은 워드프로세싱 또는 에디터 애플리케이션(212)과 동일한 기능을 제공할 수 있다.

몇몇 실시예에서, 서버 컴퓨터(220)는 서버 워드 프로세싱 또는 에디터 애플리케이션(222)을 실행하도록 구성되고 클라이언트 컴퓨팅 디바이스(210)는 클라이언트/서버 구성에서 서버 워드프로세싱 또는 에디터 애플리케이션(222)과 상호작용하기 위해 서버 컴퓨터(220)를 액세스하도록 구성된다.

클라이언트-서버 관계 내의 컴퓨팅 디바이스들 간의 통신은 특정 리소스에 대한 액세스 또는 수행되어야 할 특정 작업을 요구하는 요청을 서버에 송신하는 클라이언트에 의해 시작될 수 있다. 이후 서버는 요청된 행동을 수행하고 클라이언트에 응답을 회신할 수 있다.

하나의 실시예에서, 클라이언트 웹 브라우저 애플리케이션(213)은 웹 기반 워드프로세싱 또는 에디터 애플리케이션(122)을 액세스하기 위해, 서버(예컨대 서버(220))와 연결하는 데에 사용될 수 있다.

클라이언트(210) 및 서버(220)는 네트워크(230) 상에서 변환 및 병합 서비스(240)를 액세스할 수 있다. 클라이언트(210) 및 서버(220) 상에서 실행되는 애플리케이션은 HTTP, XML, JSON 및 SOAP와 같은 유비쿼터스(ubiquitous) 웹 프로토콜 또는 데이터 포맷을 통해 또는 FSSHTTP 프로토콜을 통해 서비스(240)를 액세스할 수 있다.

도 3은 발명의 일 실시예에 따른 컴퓨팅 환경을 보여준다. 도 3에 도시된 바와 같이, 사용자(300)를 위한 컴퓨팅 환경은 다수의 클라이언트(310)(예컨대 데스크톱(311), 랩톱(312), 스마트폰(313), 태블릿(314), 리더(도시되지 않음), 게임 콘솔(도시되지 않음), 스마트 텔레비전(도시되지 않음) 및 유사한 것), 그리고 네트워크(330)를 통해 연결된 서버(320)를 포함할 수 있다.

도 2의 네트워크(230)에 관해 앞서 기술된 바와 같이, 네트워크(330)는 인터넷, 인트라넷 또는 엑스트라넷일 수 있으며, 셀룰러(가령, 무선전화) 네트워크, 인터넷, 로컬 영역 네트워크(Local Area Network: LAN), 광역 네트워크(Wide Area Network: WAN), 와이파이 네트워크, 애드혹 네트워크 또는 이들의 조합을 포함하나 이에 한정되지는 않는 임의의 적합한 통신 네트워크일 수 있다.

클라이언트(들)(310) 및 서버(320)는 클라이언트(220) 및 서버(230)에 관해 기술된 바와 같이 구성된 컴퓨팅 시스템을 수반할 수 있다.

각각의 클라이언트(310)는 콘텐트 액세스 서비스를 통해 서버(320)에 의해 제공되는 문서(및 그것의 콘텐트)(340)를 보기 및 편집(그리고/또는 주석달기)하기 위한 소프트웨어 애플리케이션을 포함할 수 있다.

사용자(300)는 다수의 클라이언트(310)(가령, 사무실 내의 데스크톱 컴퓨터(311), 가정에서의 랩톱(312), 그리고 모바일 전화/스마트폰(313))를 가질 수 있으며, 이북 및 서버(320)에서 검색된 다른 디지털 콘텐트를 읽는 것뿐만 아니라 콘텐트를 편집하고/하거나 주석하기 위해 이들 클라이언트(310) 상에서 실행되는 소프트웨어 이북 리더 또는 문서 뷰어 또는 에디터를 사용할 수 있다.

서버(320)는 (콘텐트 액세스 서비스의 일부로서) 변환 서비스 및 병합 서비스를 제공하도록 구성된 하드웨어 디바이스 및/또는 소프트웨어 프로그램이다. 변환 서비스는 사용자로 하여금 사용자가 콘텐트를 액세스하기 위해 사용하고 있는 특정 클라이언트(310)에 의해 직접 지원되지 않는 파일 포맷일 수 있는 콘텐트(사용자 자신의 콘텐트조차)를 액세스할 수 있게 하고; 병합 서비스는 데이터베이스(350) 내에 저장된 마스터 문서(345)에 대해 사용자(300)에 의해 행해진 변경을 재통합한다.

서버(320)에 의해 제공되는 서비스(또는 기능) 중 하나 이상은 클라우드 컴퓨팅 환경에서 실행될 수 있다. 추가로, 서버(320)는 API를 통해 적출되는(exposed) (서비스를 호스팅하고/하거나) 애플리케이션을 포함할 수 있다.

어떤 실시예에 따르면, 서버(320)을 수반하는 시스템은 클라이언트(310) 또는 (데이터베이스(350)과 같은) 데이터베이스로부터 문서를 이입할(import) 수 있다. 이입된 문서는 마스터 문서(345)로 간주될 수 있거나, 마스터 문서(345)는 이입된 문서로부터 생성되고 예컨대 서버(320)와 연관된 데이터베이스(350) 내에 저장될 수 있다.

하나의 실시예에서, 문서를 "이입하는"(importing) 경우, 어드레스 또는 URL(Uniform Resource Locator)가 그 문서를 위해 생성될 수 있다. 그리고, 클라이언트(또는 소비자 디바이스)가 (생성된 어드레스에 위치된) 문서를 요청하는 경우, 문서는 검색되어 소비자 디바이스에 제공될 수 있다. 어떤 실시예에 따르면, 어드레서 생성은 문서의 전부 또는 일부를 위해 수행될 수 있다. 추가 실시예에서, 어드레스 생성은 API를 통해 적출될 수 있다.

서버(320)는 소비자 디바이스(가령, 데스크톱(311), 랩톱(312), 스마트폰(313), 태블릿(314), 리더(도시되지 않음), 게임 콘솔(도시되지 않음) 및 유사한 것)에 적합한 포맷으로 문서(345)를 변환할 수 있다.

사용자(300)는 각각의 디바이스(가령, 311, 312, 313, 314)에 걸쳐 (가령, 문서(340)의 형태인) 마스터 문서(345)의 적합한 버전에 대한 액세스를 가질 수 있다. 예를 들어, 문서(340)는 임의의 디바이스 및 플래폼에 걸쳐 나타날 수 있다. 하나의 프로그램 내에서 문서(340) 상에서 작업하는, 예컨대 랩탑(312) 상의 사용자(300)는 해당 변경과 함께 문서를 세이브할 수 있다. 문서를 세이브하는 것은 병합 서비스를 기동시킬 수 있다. 예를 들어, 도 5b 내지 도 5d에 도시된 바와 같이, 전체 문서(도 5b), 변경(델타(delta))(도 5c), 또는 특정한 수정(도 5d)는 마스터 문서와의 병합을 위해 서버로 반환될 수 있다.

실제의 물리적 파일은 클라우드(데이터베이스(350)과 같은 - 클라우드 스토리지의 일부로서) 내에 저장될 수 있거나 저장되지 않을 수 있다. 그 파일은 서버 또는 컴퓨터 또는 네트워크 상에서 서비스에 의해 액세스될 수 있는 임의의 스토리지 위치 상에 저장될 수 있다. 마스터 문서(또는 다른 이입된 파일)은 요청 시에 이입되고 변환될 수 있는 어드레스가능한 파일의 모음으로서 서버(320)에 저장될 수 있다. 도 11과 관련하여 기술되는 바와 같이, 어드레스는 문서 내의 콘텐트의 서브-세트를 위해 생성될 수 있고, 이들 어드레스 각각은 조합되거나 요청 시에 별도로 이입되고/되거나 변환될 수 있는 새로운 "마스터 문서"를 획득하는 데에 사용된다(도 9 참고).

(랩톱(316)과 같은) 클라이언트 디바이스 상의 다른 사용자(360), 또는 태블릿(314)과 같은 제2 디바이스의 제1 사용자(300)는 문서(340)을 열 수 있고, 그들의 경험은 문서(340)가 디바이스(316)(또는 제1 사용자(300)가 문서를 액세스하고 있는 제2 디바이스(314)) 내에서 작업가능한 문서라는 것이다. 그리고 디바이스(316)를 가진 제2 사용자(360)(또는 제2 디바이스 상의 제1 사용자(300))는 편집 후에 문서를 세이브할 수 있고 서비스는 변경사항을 병합할 것이다.

실시예에 따르면, 각 클라이언트(310)는 그 클라이언트를 위해 적합한 포맷으로 저장된 파일을 가진 것으로 여긴다. 파일을 열고 데이터를 액세스하기 위해 클라이언트에서 파일을 변경할 필요가 없다. 예를 들어, 애플리케이션은 예상되는 바와 같이 여전히 문서를 열 수 있고 - 서버는 클라이언트가 적합한 파일 포맷을 수신하는지에 주의한다. 클라이언트(310)에서, 사용자(300, 360)는 예상된 절차에 따라 문서를 열고, 변경하고, 세이브한다. 서버는 종단점의 한계를 이해하고, 디바이스에게 적절한 포맷을 제공한다.

서버(320) 및 소비자/클라이언트 디바이스(310)는 시스템이 클라이언트(310) 상에서 어떤 유형의 디바이스 또는 소프트웨어가 이용가능한지 인지하고 이에 따라 사용자의 경험을 조정하도록 통신한다.

서버(320)는 종단점에서 사용자 에이전트/클라이언트 특성을 식별하도록 구성될 수 있다. 그 식별은 종단점(가령, 클라이언트(310))으로부터 서버(320)에 송신된 능동적(active) 또는 묵시적(implicit) 통지에 기반할 수 있다. 서버(320)는 클라이언트 경험뿐만 아니라 지속되는 경험(가령, 마스터 문서의 저장된 카피(copy))을 조정하도록 또한 구성될 수 있다.

어떤 실시예에 따르면, 제공된 문서(340)는 더 작은(또는 더 큰) 디스플레이 크기에 적응하기(accommodate) 위해 리플로우(reflow)될 뿐만 아니라, 추가적인 적응이 행해질 수 있다.

리플로우하기는 제한된 디스플레이 또는 윈도우를 위한 콘텐트 보기의 적응을 나타내는데, 이미지가 한눈에 보여질 수 있도록 크기가 감소하는 동안 텍스트는 읽기의 편의를 위해 원래의 크기를 유지할 수 있다.

추가적인 적응의 예로서, 고해상도 디바이스(high resolution device)는 고해상도 콘텐트를 제공받을 수 있는 반면(더 높은 형태 인자(form factor)는 더 많은 오브젝트들을 수신할 수 있음), 전화는 (예를 들어, 문서 내의 그림의 12 메가픽셀(megapixel) 버전 대신) 더 낮은 해상도의 이미지를 수신할 수 있다. 추가로, 터치 가능형 디바이스(touch enabled device)는 문서에 부가된 터치 응답성 특징을 가질 수 있다. 추가로 맞춤화된 종단점 서비스가 제공(가령, API를 통해 적출)될 수도 있는데, 문서 상에 코멘트하기 및 (해야 할 항목들(to-do items)과 같은) 작업-흐름 요소를 부가하기를 가능하게 하는 것을 포함하나 이에 한정되지는 않는다. 보안 설정 및 권한 관리는 또한 클라이언트에게 조정될 수 있다. 예를 들어, 더 오래된 버전 또는 어떤 파일 포맷이 클라이언트에게 제공되는 경우, 문서는 더 낮은 충실도 버전으로 세이브하는 것의 파괴성(destructiveness)을 최소화하되, 문서가 (마스터와는 상이한 카피로서) 세이브되게 하기 위해 판독 전용(read-only)으로 기능하도록 제공될 수 있다.

몇몇 실시예에서, 클라이언트는 어드레스 생성 API(create address API)를 사용하여 어드레스를 요청하는 것에 의해 낮은 충실도(또는 상이한 포맷 또는 특징 버전)를 세이브할 수 있다.

제공된 문서(340)는 특정 소비자 디바이스에 의한 렌더링에 적합한 (또는 맞춤화된) 포맷으로 된 것일 뿐만 아니라, 문서(340)에 대한 수정이 마스터 문서(345)와 재통합될 수도 있다. 서버(320)는 어떠한 유형의 디바이스 및/또는 소프트웨어가 클라이언트에서 이용가능한지를 인지함에 의해 수정을 재통합할 수 있다. 예를 들어, 클라이언트 디바이스가 상이한 플래폼(및 파일 포맷)을 사용하는 경우, 서버(320)는 변환에서 손실될 수 있는 충실도를 알고 임의의 변경을 도로 서버 상에 재구성할 수 있다.

유사하게, 클라이언트 디바이스가 특징의 상이한 버전을 사용하는 경우, 서버(340)는 사용된 버전을 인지하고 이에 따라 조절할 수 있다. 특징은 텍스트, 차트, 수식, 텍스트 효과, 그리고 그래픽(MICROSOFT SMARTART 그래픽을 포함함), 디지털 콘텐트(비디오를 포함함), 참고문헌 스타일, 스레드된 코멘트하기((threaded commenting), 철자 점검, 사전, 언어를 조작하고 편집하는 유틸리티 및 그래픽을 조작하고 편집하는 유틸리티를 포함하나 이에 한정되는 것은 아니다.

서비스는 역방향 및 순방향 호환가능성을 제공할 수 있다.

예를 들어, MICROSOFT WORD의 최근 버전의 문서는 MICROSOFT WORD의 더 이른 버전을 실행하는 클라이언트에게 클라이언트가 더 이른 버전으로의 변환을 수행할 필요 없이 제공될 수 있다. 나아가, (더 낮은 충실도 버전으로 도로 세이브하는 것의 문제를 피하기 위해) 판독 전용 버전을 제공하는 것 대신에 더 이른 버전을 실행하는 클라이언트는 문서를 편집할 수 있는데, 서버는 어떻게 더 이른 버전이 완전한 충실도 버전(그리고 높은 충실도 콘텐트를 대체하는 이미지가 나타내는 것)에 대해 파괴적인지 인지하고 있어 데이터를 도로 서버 상에 재구성할 수 있기 때문이다.

그 파일이 특정 파일 포맷이나 그 파일에 대해 수행될 수 있는 특정한 제약 및 행동뿐만 아니라 어떤 형태를 콘텐트가 제공받았는지를 서버는 인지하므로 충실도 복원은 서버에서 수행될 수 있다.

도 4는 발명의 일 실시예에 따른 변환 및 병합 서비스를 위한 예시적 절차 흐름을 보여준다. 도 4를 참조하면, 동작(402)에서, 서버가 병합 요청을 수신하는 경우, 그 요청 및 문서가 제공될 수 있다. 서버는 문서가 새로운 문서인지 또는 시스템(404) 상에 존재하는지를 판정할 수 있다. 만일 문서가 새로운 문서(또는 새로운 카피)인 경우, 시스템은 그 문서로부터 마스터를 생성할 수 있다(406). 마스터는 (동일한 포맷 및 특징 버전을 사용하는) 문서일 수 있거나 마스터 문서는 특정 파일 포맷 및 특징 버전으로 문서를 변환하는 것에 의해 생성될 수 있다.

마스터 문서를 생성하는 것에 의해, 어떤 실시예는 사용자를 위한 서비스로서의 문서 경험을 생성할 수 있다. 특히, 마스터 문서는 생성자 및 타인이 문서에 대해 취할 수 있는 액션의 세트와 더불어 마스터 문서를 이루는 콘텐트를 포함한다. 맞춤화된 경험이 소비자에게 제공될 수 있고 콘텐트를 편집하는 능력은 서비스의 일부로서 드러내어질 수 있다.

일 구현에서, 마스터 문서를 생성하는 것은 어드레스를 생성하는 것을 수반한다(이는 전역화된 고유 식별자(Globalized Unique IDentifier: GUID)를 생성하는 것을 수반할 수 있음). 서비스에 의한 어드레스의 이러한 생성은 다른 서비스 또는 애플리케이션이 어드레스를 생성하는 서비스일 수 있다는 점에서 확장가능할 수 있다.

동작(404)으로 돌아와, 만일 (예컨대, 마스터 문서가 이미 시스템 상에 존재하기 때문에) 문서가 새로운 문서가 아닌 것으로 판정되는 경우, 서버는 문서가 마스터 문서와 동일한 파일 포맷인지 또는 상이한 파일 포맷인지를 판정할 수 있다(408). 파일 포맷이 상이하다는 판정에 응답하여, 서버는 문서의 파일 포맷을 마스터 문서의 파일 포맷 또는 시스템(410)에 의해 이해되는 어떤 다른 포맷으로 변환하고 이후에는 문서와 마스터 문서 간의 차이를 자동적으로 판정하고(412) 그 차이(델타)를 병합하여 마스터를 업데이트할 수 있다(414). 델타를 마스터 문서 내에 병합하는 것은 하나의 디바이스의 사용자로 하여금 문서에 무엇인가를 하고 그 문서와 연관된 변경을 가져 문서를 액세스하는 다음 사람(또는 제2 디바이스 상의 동일한 사람)이 제2 사람(또는 제2 디바이스)이 수신하는 문서 상에 반영된 해당 변경을 보도록 할 수 있다.

동작(408)로 돌아와서, 만일 파일 포맷이 동일한 경우, 문서에 의해 지원되는 특징 버전이 마스터(416)에 의해 지원되는 특징 버전과 동일한지에 대한 판정이 행해질 수 있다. 특징 버전이 상이하다는 판정에 응답하여, 서버는 문서와 마스터 간의 비-특징 관련 차이(델타)를 판정하고(418) 판정된 델타를 사용하여 충실도를 잃지 않고 마스터를 업데이트할 수 있다(420).

파일 포맷 및/또는 특정 버전을 판정하는 것에 의해, 전체로서의 파일 및 파일 내의 콘텐트는 하나의 문서를 다른 문서로 변환하거나 콘텐트를 하나의 버전에서 다른 버전으로 변환하기 위해 분석될 수 있다. 마스터와 문서 간 특징 버전과 파일 포맷 간 차이가 없는 경우, 차이는 자동적으로 마스터에 업데이트될 수 있거나(422) 마스터가 문서에 의해 대체될 수 있다.

도 5a 내지 도 5d는 변환 및 병합 서비스의 예시적 시나리오를 도시한다. 도 5a를 참조하면, 변환 서비스(505)는 데이터베이스(510)로부터의 문서를 액세스하고, 예컨대 디스플레이된 문서(520)로서, 지원되는 파일 포맷으로 클라이언트에게 문서를 제공할 수 있다. (데이터베이스(510) 내에 저장된 바와 같은) 디스플레이된 문서(520)의 콘텐트를 위한 실제 포맷은 PDF, DOC, DOCX 및 ePub을 포함할 수 있으나 이에 한정되지는 않고; 다만, 변환 서비스(505)는 클라이언트에 의해 지원되고 종단점을 위해 맞춤화도 된 포맷으로 콘텐트를 제공할 수 있다.

데이터베이스로부터의 문서를 액세스하기 위해, 서비스는 문서의 어드레스 또는 리소스 식별자를 수신하고 그 어드레스 위치에서 해당 문서를 검색하거나 요청한다.

실시예는 문서가 마치 그것이 특정 클라이언트를 위해 필요한 포맷인 것처럼 - 사용자가 보기(또는 변집)을 위한 문서를 선택하는 때까지 문서가 실제로는 해당 포맷 또는 버전으로 존재하지 않더라도 - 사용자에게 제시되는 시스템을 제공한다. 서버 상에 저장된 모든 파일을 매 유형의 파일 포맷으로 사전변환하는 것 대신에, 문서를 위한 특정 포맷이 사용자의 요청에 따라 전달된다.

실시예는 콘텐트가 소비될 수 있고 콘텐트가 제공되는 디바이스(또는 클라이언트)에 적합한 해당 콘텐트를 위한 경험을 생성할 수 있는 도달범위를 확장할 수 있다. 서비스는 특정 디바이스 상에서 콘텐트를 보기 위한 원하는 또는 적합한 방식이 무엇인지 판정하기 위해 디바이스 및 능력을 해석할 수 있다. 서비스가 고려할 수 있는 특징은 디스플레이의 규모(dimension), 디바이스의 사용자 입력 능력, 네트워크 연결의 속도 및/또는 대역폭뿐만 아니라 운영 체제 및 애플리케이션 제약을 포함하나 이에 한정되지 않는다.

예를 들어, 몇몇 문서는 랩톱 상에서 디스플레이되어 크게 보일 수 있으나, 전화나 태블릿과 같은 더 작은 스크린 상에서 꽤 유용하지는 않다. 클라이언트가 무엇인가를 판정하는 것(예컨대 클라이언트에 적절한 소비 포맷을 판정하는 것)에 의해, 서비스는 디바이스(또는 소프트웨어)에 기반하여 소비 경험을 수정한다.

클라이언트에서, 서비스(510)에 의하여 제공되는 문서(520)는 편집될 수 있다. 금번 실시예에서, 편집된 문서(525)는 상이한 에디터 및 특징 버전에 걸쳐 협업을 가능하게 하기 위해 도로 마스터 문서로 병합될 수 있다. 병합 서비스를 제공하기 위하여, 협업 및 병합 서비스를 위한 일반적인 API 또는 복수의 API가 사용될 수 있다. API는 클라이언트로 하여금 변경사항을 복수의 플랫폼에 걸쳐 문서에 병합할 수 있도록 한다. 추가로, 인식가능한 파일 포맷으로의 중간 변환(intermediary conversion)이 발생하는(예컨대 전유(proprietary) 또는 새로운 포맷이 개발된) 상황에 따라서 서비스는 제3자 어댑터(third party adapter)로의 확장가능할 수 있다.

도 5b 내지 도 5d는 편집된 문서(525)를 도로 마스터 문서에 병합하는 다양한 시나리오를 보여준다.

도 5b는 수정(530)이 있는 전체 문서가 병합 서비스(540)에 제공되는 경우를 보여준다. 도 5b를 참조하면, 일반적인 API가 사용될 수 있다. 하나의 실시예에서, 클라이언트는 (문서(530)로서) 변경사항과 함께 전 문서를 서버(가령, 서비스(540))까지 송신할 수 있다. 서비스(530)는 문서(530)를 해석하고, 차이를 판정하고, 이후 자동으로 병합한다. 병합은 편집된 문서가 마스터 문서와 상이한 파일 포맷인 경우에도 수행될 수 있다. 문서(530)는 병합을 가능하게 하기 위해 서비스(540)에 의해 특정한 포맷으로 변환될 수 있다.

도 5c는 문서(520)와 편집된 문서(525) 간의 차이(델타(550))가 병합 서비스(560)에 (일반적인 API를 통하여) 제공되는 경우를 보여준다. 서비스(560)는 델타(550)를 해석하고 자동으로 병합한다. 병합은 편집된 문서가 마스터 문서와 상이한 파일 포맷인 경우에도 수행될 수 있다.

도 5d는 복수의 API가 사용되는 경우를 보여준다. 그 API들은 콘텐트를 병합하기 위한 단촐한 옵션(lightweight option)의 일부로서 결속될(bundled) 수 있다. 그 API들은 개별적인 수정 기능일 수 있고 하이라이팅 API, 폰트 API, 단락 API, 스타일 API, 번역 API, 수식 API, 표 생성 또는 편집 API; 이미지 삽입, 생성 또는 편집 API; 컬러 API, 코멘트 API, 및 유사한 것을 포함할 수 있으나 이에 한정되지는 않는다. 그 API들 중 하나 이상은 특정 클라이언트에게 이용가능할 수 있다.

예를 들어, 클라이언트가 하이라이팅 API를 호출(call)하고 단락 식별자 또는 텍스트를 쭉 넘길 수 있고 서비스는 하이라이팅을 수행한다. 클라이언트가 코멘트 API를 호출하여 문장, 단락, 또는 단어를 제공할 수 있는데 여기서 코멘트는 코멘트로서 삽입할 텍스트와 함께 삽입될 것이다. 디바이스가 문서의 파일 포맷을 이해할 필요는 없다. 예를 들어, 문서는 DOCX 파일로서 저장될 수 있으나, 클라이언트는 PDF 파일 또는 ePub 파일로서 문서를 볼 수(그리고 편집할 수) 있다.

다른 실시예에 따르면, 클라이언트는 코멘팅 서비스를 제공할 수 있는 코멘트 API를 호출할 수 있다. (예컨대 코멘트 API를 통한) 코멘팅 서비스는 제한된 종단점으로 하여금 문서의 일부에 대한 코멘트를 전체 문서 내에 병합하기 위한 서비스 내에 송신할 수 있게 할 수 있다. 코멘팅 서비스는 코멘트 및 코멘트와 문서의 어떤 부분이 연관되는지에 대한 표시를 수신하고 이후 코멘트를 포함하도록 전체 문서를 수정할 수 있다.

추가 실시예에서, 코멘트 자체는 어드레스를 할당받고 이후 다른 클라이언트에 의해, 예컨대 가입 시나리오(subscribe scenario)(여기서 클라이언트 또는 서버는 언제 누군가가 포스트, 메시지 또는 다른 문서에 코멘트하는지 및/또는 코멘트를 획득할 수 있거나 수신하는지의 알림(notice)을 수신함)에서 사용될 수 있다.

도 5d에 도시된 예에서, 편집된 문서는 제1 단락의 하이라이팅, 제3 단락 내의 텍스트에 대한 정정, 그리고 문서와 연관된 메타데이터에 부가된 서명(signature)을 포함한다. 하이라이팅 API에 대해, 클라이언트는 하이라이트 API를 기동시키고 단락 식별자(570)를 하이라이트 서비스(575)에 전할 수 있다. 오타를 정정하기 위하여, 클라이언트는 위치 식별자(가령, 제3 단락, 제1 문장) 및 대체 텍스트(580)를 텍스트 편집 서비스(585)에 전할 수 있다. 서명을 부가하기 위하여, 클라이언트는 위치 식별자(가령, 메타데이터) 및 서명(590)을 서명 서비스(595)에 전할 수 있다.

위치 식별자는 문서 내의 단락을 식별하는 단락 식별자, 문서 내의 라인을 식별하는 라인 식별자, 문서 내의 기호를 식별하는 기호 식별자, 그리고 문서의 부분을 식별하는 부분 식별자를 포함할 수 있으나 이에 한정되는 것은 아니다. 부분 식별자는 문서 콘텐트, 코멘트 콘텐트, 스타일 콘텐트 등등과 같은 문서의 부분들 사이를 구별하는 위치 식별을 제공할 수 있다. 부분 식별자에 의해 식별된 문서의 부분은 문서 내의 구조적으로 서술된 콘텐트(structurally delineated content)일 수도 있다. 하나의 실시예에서, 부분 식별자는 연관된 메타데이터와 함께 구조적인 마크업(markup)을 통해 수정되는 문서의 부분을 식별한다. 구조적으로 서술된 콘텐트의 일 예는 다음과 같다.

This is a paragraph.

<fill-in region> Here is some content that a user may edit

and then send back to the server to merge</fill-in region>

Following paragraph.

콘텐트 제어의 외양을 갖는 위의 예에서, 사용자에 의해 수정될 수 있는 콘텐트는 식별되는 "fill-in region" 마크업 사이의 단락 내에 위치된다. 몇몇 실시예에서, 수정이 발생할 문서의 부분은, 예컨대 "fill-in region"과 같은, 문서 내의 구조적인 마크업을 통해 식별될 수 있다.

몇몇 실시예에서, 평문 파일 포맷(plain text file format)을 지원하는 클라이언트로부터의 콘텐트는 텍스트를 쭉 넘기는 것 및 텍스트를 취하고 지정된 포맷화를 부가할 수 있는 API를 호출하는 것에 의해 서비스를 통해 파일에 리치 콘텐트를 부가할 수 있다. 유사하게, 콘텐트는 메타데이터에 콘텐트를 부가하는 서비스를 기동시키는 것에 의해 메타데이터에 부가될 수 있다.

도 6은 발명의 일 실시예에 따라 에디터에 의해 수행되는 절차의 다이어그램을 보여준다. 에디터는 텍스트, 이미지, 또는 사운드를 편집하기 위한 도구를 포함하는 클라이언트(하드웨어 또는 소프트웨어)를 나타낸다. 에디터는 워드프로세싱 애플리케이션을 포함하는 생산성 애플리케이션일 수 있다.

도 6을 참조하면, 동작(602)에서, 에디터는 문서를 요청할 수 있다. 그 요청은 클라우드 데이터베이스(604) 상에 위치된 파일을 여는 것일 수 있다. 그 문서가 에디터에 의해 지원되는 것과 동일한 파일 포맷로 된 것이 아닐 수 있기 때문에, 그 문서에 대한 요청은 변환 서비스를 제공하는 액세스 서비스(608)을 기동시킬 수 있다. 액세스 서비스(608)는 데이터베이스(604)로부터 문서를 검색하고 에디터를 위한 적합한 파일 포맷으로 문서를 변환할 수 있다. 동작(608)에서, 에디터는 액세스 서비스(606)로부터 변환된 문서를 수신하고 디스플레이를 위해 수신된 문서를 렌더링할 수 있다.

데이터베이스(604)로부터 검색된 문서는 마스터 문서일 수 있다. 에디터를 사용하는 도중에, 사용자는 수신된 문서를 수정할 수 있다. 수신된 문서(610)에 대한 수정이 행해진 경우, 그 수정은 병합 서비스(612)를 기동시키는 것에 의해 마스터 문서로 병합될 수 있다.

병합 서비스(612)를 기동시키는 것은 액세스 서비스(614)의 병합 서비스를 호출한다. 병합 서비스의 기동은 사용자로부터 세이브 명령(save command)을 수신하는 것에 대한 응답으로서 일어날 수 있다. 다른 실시예에서, 병합 서비스의 기동은 작업흐름의 일부로서 일어날 수 있다. 예를 들어, 병합 서비스의 기동은 시스템으로부터의 자동 저장(automatic save)과 같은 어떤 이벤트에 의해 트리거될(triggered) 수 있다.

선택적으로, 사용자의 식별에 근거하여 문서에 대한 액세스 및/또는 액세스 서비스를 제공하기 위해 확인 절차(616, 618)가 포함될 수 있다. 예를 들어, OATH 토큰이 액세스 서비스(606, 614)에 대하여 서명된(signed-in) 사용자를 확인하기(validate) 위해 사용될 수 있다. 사용자가 인증될(authenticated) 수 있고 문서가 액세스될 수 있도록 토큰은 에디터에 의해 클라우드 데이터베이스 및/또는 액세스 서비스에 송신될 수 있다.

추가 실시예는 사용자가 누구인지 그리고 어떤 문서에 사용자가 관심을 갖는지를 인지하는 서비스를 가능하게 하기 위해 신원 관리자(identity manager)를 활용할 수 있다. 사용자의 신원을 인지하는 것에 의해, 그 서비스는 다수의 디바이스(가령, 사용자의 컴퓨터, 랩톱, 태블릿, 스마트폰, 이북 리더 및 유사한 것) 및 서비스(가령, 드롭박스 사(Dropbox Inc.)로부터의 DROPBOX 서비스 및 마이크로소프트 사(Microsoft Corp.)로부터의 MICROSOFT SKYDRIVE 서비스와 같은 파일 호스팅 서비스)에 걸쳐 사용자의 콘텐트(가령, 문서)를 - 사용자를 위해 대신 검색할 수 있다.

추가로, 문서가 제공될 클라이언트를 인지하는 것에 의해, 시스템은 하나의 포맷의 문서를 취하여 사용자에 의해 사용되고 있는 클라이언트를 위한 맞춤화된 포맷으로 문서를 변환할 수 있다. 예를 들어, 사용자는 MICROSOFT WORD의 문서에 대해 작업하고 있을 수 있고 그의 이북 리더 상에서 문서를 액세스하고자 한다. 하나의 그러한 경우에서, 사용자가 그의 이북 리더로부터 이용가능한 파일을 브라우징하는 (가령, 그리하여 사용자가 이북 리더 상에서 그것을 읽을 수 있는) 경우, 서비스는 사용자에게 문서를 제시할 수 있다. 이는 (문서가 적절한 포맷으로 변환되도록 하기 위해) 사용자가 문서를 이북 리더로 송신하기 위해 현재 취하는 단계를 제거할 수 있다.

파일은 리더 디바이스 상의 앱을 열 때 이용가능할 수 있다. 앱은 리더 상에서 실행될 수 있는 문서의 연관된 허브(hub)를 가질 수 있다. 다른 실시예에서, 킨들 리더를 위해 Amazon.com에 의해 제공되는 것과 같은, 리더에 의해 제공되는 서비스는 발명의 어떤 실시예의 액세스 서비스로부터의 문서를 사용자가 액세스하기 위해 확장가능성 계층을 통해 사용자의 경험을 통합할 수 있다.

일 실시예에 따르면, 사용자는 단지 문서에 대해 작업하고, 문서(또는 문서의 어드레스)를 세이브하며, 파일을 닫을 수 있다. 사용자가 누구인지 그리고 어떤 플랫폼에 대해 문서가 이용가능하게 될 것인지 신원 관리자가 인지하는 것에 의해, 동일하거나 상이한 클라이언트에 의해 다시 액세스되는 경우 문서는 적절한 포맷으로 사용자를 위해 있을 것이다.

도 7은 발명의 일 실시예에 따른 다수의 에디터를 사용하여 문서에 대해 협업하기 위한 방법의 절차 흐름 다이어그램을 보여준다. 협업 방법은 액세스 서비스에 의해 관리되는 마스터 문서(700)에 기반할 수 있다. 제1 에디터(에디터 1)는, 동작(710)에서, 문서(700)를 액세스 서비스로부터 요청할 수 있다. 마스터 문서(700)는 액세스 서비스와 연관된 데이터베이스 내에 저장되거나 액세스 서비스에 의해 알려진 위치로부터 검색될 수 있다. 이 예에서, 제1 에디터는 ePub 포맷을 지원하는 리더일 수 있고, 마스터 문서는 DOCX 포맷으로 되어 있다. 액세스 서비스는 제1 에디터를 위한 적절한 포맷을 판정하고(715) 제1 에디터에게 문서를 제공할 수 있다(720). 제1 에디터가 ePub 포맷을 지원하나 마스터 문서의 DOCX 포맷은 지원하지 않기 때문에, 서비스는 제1 에디터에게 ePub 포맷으로 문서를 제공할 수 있다.

제1 에디터는 ePub 포맷 문서를 수신하고(725) 문서를 디스플레이할 수 있다(730). 제1 에디터의 사용자는 ePub 문서를 (예를 들어, 코멘트를 포함시킴으로써) 수정할 수 있다(730). 세이브 명령(또는 다른 특정 상황)이 발생한 경우, 제1 에디터는 액세스 서비스에 병합을 요청할 수 있다(740). 요청은 수정과 함께 전체 ePub 문서(가령, 문서 및 코멘트) 또는 수정을 위한 위치 식별자 및 수정(가령 코멘트를 위한 위치 및 코멘트로서 부가될 텍스트)을 포함할 수 있다.

액세스 서비스는 병합 요청을 수신하고(745) 수정을 마스터 문서에 병합하는 동작을 수행할 수 있다(750). 마스터 문서는 그것의 원래 포맷 및 버전으로 남아 있을 수 있다.

제2 에디터는 액세스 서비스에 문서를 요청할 수 있다(755). 이 예에서, 제2 에디터는 DOCX 파일 확장자를 지원하는 컴퓨팅 디바이스일 수 있으나, 마스터 문서와는 상이한 특징 버전에 있을 수 있다. 설명적인 예로서, 마스터 문서는 버전 5이나, 제2 에디터는 버전 1일 수 있다. 동작(760)으로 이동하여, 액세스 서비스는 제2 에디터를 위한 적절한 포맷을 판정하고, 제2 에디터에 문서를 제공할 수 있다(765). 제2 에디터는 DOCX(특징 버전 1) 포맷 문서를 수신하고(770) 문서를 디스플레이할 수 있다(775). 제2 에디터의 사용자는 문서를 수정할 수 있다(780). 세이브 명령어(또는 다른 특정 상황)이 발생한 경우, 제1 에디터는 액세스 서비스에 병합을 요청할 수 있다(785).

액세스 서비스는 병합 요청을 수신하고(790) 마스터 문서에 수정을 병합하기 위한 동작을 수행할 수 있다(795). 수정은 양 버전 모두에 의해 지원되는 특징을 사용하는 콘텐트의 부분에 대한 것일 수 있다. 제2 에디터가 DOCX의 더 오래된 버전은 지원하나 더 새로운 버전은 지원하지 않는 까닭에, 더 새로운 버전으로의 충실도 복원이 서비스를 사용함으로써 달성될 수 있고 - 새로운 특징을 사용하는 콘텐트는 병합에 의해 파괴되지 않을 것이다.

수정이 양 버전 모두에 의해 지원되는 것은 아닌 특징을 사용하는 콘텐트의 부분에 대한 것인 경우, 충돌은 사용자를 대신하여 행해진 변경 및 사용자에 의한 결정에 응답하여 행해진 변경을 포함하는 임의의 적합한 방식에 의해 해결될 수 있다. 예를 들어, 몇몇 경우에, 서비스에 의한 결정은 어떻게 수정을 포함시킬지, 어디에 수정을 포함시킬지 및 수정을 포함시킬지 여부에 관해 행해질 수 있다. 결정이 결정을 행할 수 없(거나 행하도록 설정되지 않)는 경우, 서비스는 모든 충돌 및 가능성을 보기 위한 옵션을 하나 이상의 디바이스에 제공할 수 있다. 그리고 사용자는 충돌을 해결하기 위해 옵션을 택할 수 있다.

액세스 서비스는 다수의 에디터가 동일한 파일을 보고 편집할 수 있도록 한다. 또한, 제2 에디터 및 제1 에디터는, 양자 모두 마스터 문서를 액세스하는 동안, 상이한 플랫폼에 걸쳐 문서를 액세스하고 있다.

실시예에 따르면, 파일은 사용자가 콘텐트로서 볼 수 있고 개별적으로 어드레스가능한 부분(본 문서에서 "블록"으로 지칭됨)을 포함하는 "문서"일 수 있다. 개별적으로 어드레스가능한 블록은 텍스트, 단락, 단락의 모음, 테이블, 오브젝트, 픽처, 차트, 오디오, 이미지, 그리고 다양한 다른 유닛 및 모음을 포함할 수 있다. 어떤 실시예에 따르면, 각 블록 및/또는 블록의 모음은 개별적으로 어드레스가능할 수 있다. 또한, 문서의 각각의 개별적으로 어드레스가능한 블록은 변환 및 병합 서비스를 이용하여 변환되고 병합될 수 있다. 몇몇 경우에 이는 사용자가 문서가 저장될 방식과는 상이할 수 있는 포맷으로 문서의 부분을 편집하는 경우 도움이 될 수 있다.

하나 이상의 텍스트 블록(포맷화로부터 분리되거나 이와 조합됨) 및/또는 이미지는 조합되어 문서 뷰 내에서 사용자에게 제시될 수 있다.

도 9는 발명의 일 실시예에 따른 어드레스가능한 콘텐트 블록을 갖는 문서 뷰의 다이어그램을 보여준다. 도 9에 예시된 바와 같이, 사용자는 (B1(901), B2(902), 및 B3(903)와 같은) 콘텐트 블록들로 이루어진 단일 문서 - "문서(900)"를 본다. 콘텐트 블록은 컴포넌트들 중 적어도 두 개가 상이한 서비스 또는 리소스 위치로부터 획득될 수 있더라도 결합적 문서로서 나타나는 것 내에 조합될 수 있다.

도 9에 도시된 예에서, 문서 뷰(900)는 텍스트(910), 이미지(920) 및 테이블(930)을 포함할 수 있다. 문서 뷰(900) 내의 콘텐트 중 일부는 별도로 어드레스가능할 수 있(고 문서를 제공하는 액세스 서비스 또는 다른 서비스에 의해 상이한 서비스 또는 리소스 위치로부터 획득되었을 수 있)다. 예를 들어, 문서 뷰(900) 내의 문장 또는 단락은 어드레스가능한 콘텐트 블록 B1(901)으로부터의 콘텐트를 포함할 수 있고; 테이블(930)은 하나 이상의 독립적으로 어드레스가능한 셀(cell)(이 안에 콘텐트 블록 B2 및 B3(902, 903)의 콘텐트가 포함될 수 있음)을 포함할 수 있다.

어떤 구현에서, 문서 뷰는 공유된 블록 뷰(여기서 문서 뷰를 이루는 서브블록은 문서 뷰 내에서 시각화될 수 있음)를 포함할 수 있다. 시각화는 하이라이팅, 폰트 색, 코멘트, 또는 다른 차별점을 통해 나타내어질 수 있는데 이에 의하여 사용자는 문서 뷰의 부분이 공유된 블록으로부터 획득되었거나 상이한 어드레스로부터 획득되었는지 판정할 수 있다.

도 10은 발명의 일 실시예에 따른 콘텐트 큐레이션을 위한 시스템의 다이어그램을 보여준다. 도 10을 참조하면, 사용자는 콘텐트 액세스 서비스에 의해 복수의 리소스 및/또는 서비스(1001, 1002, 1003)로부터 검색된 콘텐트를 결합적인 단일 문서(1000)로서 볼 수 있다. 일 실시예에 따르면, 사용자는 사용자의 디바이스를 위한 적절한 포맷의 이용가능한 단일 문서로서 문서(1000)를 제시하는 액세스 서비스를 사용하여 문서(1000)를 액세스할 수 있다. 문서(1000)을 제시하는 경우, 액세스 서비스는 문서 스토어(document store)(1010)로부터 다수의 콤포넌트들을 검색할 수 있다.

예를 들어, 클라이언트는 다수의 리소스들로부터 검색될 콘텐트를 포함하는 문서를 요청할 수 있다. 그러한 경우에, 콘텐트의 단편들을 검색하기 위한 상응하는 API 호출은 상이한 리소스(또는 서비스)에 대해 행해질 수 있다. 사용자가 제1 콘텐트 블록 C1(1021), 제2 콘텐트 블록(1022) 및 제3 콘텐트 블록(1023)을 단일 문서(1000)로서 "본다" 하더라도, 클라우드(또는 문서 스토어)는 API1(1031), API2(1032), 및 API3(1033)을 통해 각자의 리소스 또는 서비스(1001, 1002 및 1003)로부터 검색되는 세 개의 서브컴포턴트를 "본다".

액세스 서비스는 문서 스토어(1010)로부터 적절한 서브컴포넌트 C1(1021), C2(1022) 및 C3(1023)를 획득하고 서브 컴포넌트들을 클라이언트에서 보기 위한 적절한 포맷으로 배열함(arranging)으로써 문서에 대한 요청을 수신하는 것에 응답할 수 있다.

문서의 부분들은 개별적으로 어드레스가능할 수 있다. 다른 사람이 문서의 오직 한 부분을 검토하거나 코멘트하는 경우 그 다른 사람에게 문서를 이메일링(emailing)하거나 전체 문서를 제공하는 것 대신, 사용자는 검토되거나 코멘트될 문서의 특정 부분에 대한 링크를 그 사람에게 송신할 수 있다. 서비스는 문서의 특정 부분을 위한 어드레스(및 URL)을 요청하기 위해 사용될 수 있고; 사용자가 어드레스를 수신하면, 사용자는 그 다른 사람에게 어드레스를 송신할 수 있다. 문서의 뷰 내에서 작업하는 경우, 사용자는 섹션(section)을 선택하고 생성될 어드레스를 요청할 수 있다.

하나의 실시예에서, 어드레스가 획득되면, 예를 들어 URL의 형태로, 데이터를 되찾기 위해 사람들 및 시스템에 회람될 수 있는 것은 이 어드레스이다.

몇몇 실시예에서, 어드레스는 링크 또는 다른 형태(블록을 위한 URL을 제시함)로 클라이언트에게 반환될 수 있다. 다양한 실시예들에 따르면, 어드레스 서비스는 하나 이상의 서버 상에 구현화되고 하나 이상의 데이터베이스 및/또는 데이터 창고(data warehouse)를 액세스할 수 있다. 어드레스 서비스는 SOAP API를 구비한 XML 웹 서비스로서 구현될 수 있다.

어떤 실시예에 따르면, URL은 서비스에 의해서 생성된 어드레스에서 콘텐트에 대한 액세스를 가능하게 하기 위해 생성될 수 있다. 콘텐트 블록을 반환하는 URL은 블록을 위한 GUID를 포함할 수 있다. 몇몇 실시예에서, 블록이 저장되는 포맷을 나타내기 위해 출력 파일 유형이 포함될 수 있다.

예를 들어 GET HTTP request를 통해, URL을 액세스함으로써, 그 어드레스에서의 데이터가 획득될 수 있다. URL은 가입자에게 어떤 콘텐트를 제공하기 위해 제3자 서비스에 의해 사용될 수 있다.

어드레스가 생성되면, 데이터는 그 어드레스를 사용하여 검색될 수 있다. 데이터는 네이티브(native) XML, 정규(canonical) HTML 또는 텍스트로 되어 있을 수 있다. "정규"(canonical) 링크는 리소스의 선호되는 버전을 나타낸다. 정규 링크 관계는 선호되는 국제화된 리소스 식별자(Internationalized Resource Identifier: IRI)(즉, 복제 콘텐트의 리소스보다 선호되는 IRI)를 리소스의 세트(복제된(duplicated) 형태로 콘텍스트(context) IRI의 콘텐트를 반환함)로부터 지정한다.

도 11은 문서 콘텐트의 서브세트를 위한 새로운 어드레스를 생성하는 예시적 시나리오를 도시한 것이다. 도 11을 참조하면, 어드레스 생성 API(1100)는, 예를 들어 위치 식별자를 통해 식별되는 문서 뷰(1110)의 콘텐트 블록을 위한 어드레스(가령, GUID)를 생성하기 위해 호출될 수 있다. 위치 식별자는 문서의 단락을 식별하는 단락 식별자, 문서의 라인을 식별하는 라인 식별자, 문서의 기호를 식별하는 기호 식별자, 그리고 문서의 부분을 식별하는 부분 식별자를 포함할 수 있으나 이에 한정되는 것은 아니다. 부분 식별자는 문서 콘텐트, 코멘트 콘텐트, 스타일 콘텐트 등등과 같은 문서의 부분들 사이를 구별하는 위치 식별을 제공할 수 있다. 부분 식별자에 의해 식별되는 문서의 부분은 문서 내의 구조적으로 기술된 콘텐트일 수도 있다.

어드레스 생성 서비스가 GUID를 생성하면, GUID는 콘텐트 블록과 연관된 메타데이터로서 클라이언트에게 반환될 수 있다.

GUID를 전하는 URL은 이 콘텐트 블록을 액세스하는 데 사용될 수 있다. 몇몇 경우에, 문서 뷰는 문서의 콘텐트를 디스플레이하는 경우 이 새로운 콘텐트 블록 어드레스를 활용할 수 있다.

콘텐트 블록이 하나의 클라이언트에 의해 업데이트되는 경우, 이 블록으로 형성되고 다른 클라이언트가 보는 문서가 업데이트될 수 있다. 몇몇 시나리오에서, 그 업데이트는 콘텐트 블록이 하나의 클라이언트에서 업데이트되므로, 해당 어드레스가능 콘텐트 블록을 포함하는 문서를 보는 다른 클라이언트는 그 변경을 마치 국부적으로 수행되고 있는 것처럼 볼 수 있다는 점에서 동시적인 것으로 나타날 수 있다. 몇몇 다른 시나리오에서, 사용자는 업데이트된 블록이 공유(되고 해당 어드레스가능 콘텐트를 액세스하는 타인에게 이용가능한) 때를 제어할 수 있다. 이것은, 예를 들어, URL에 버전을 저장하고 문서의 특정 버전에 대한 포인터를 송신함으로써 성취될 수 있다. 예를 들어, 사용자는 검토를 위한 드래프트 버전(draft version)을 송신하고 최신 버전 상에서의 작업을 유지할 수 있다. 드래프트 버전을 수신한 사람들은 업데이트된 포인터를 송신하는 것을 통해 최신 버전이 공유될 때까지 변경사항을 보지 않을 것이다.

하나의 예에서, 클라이언트는 어드레스 생성 API(1100)를 호출하고 단락 식별자(1112) 또는 범위(그리고 몇몇 경우에 텍스트 또는 이미지)를 쭉 넘길 수 있으며, 서비스는 단락 또는 범위를 위한 GUID-1(1114)를 생성(및 저장)한다. 몇몇 경우에, 텍스트 또는 이미지가 제공되는 경우, 서비스는 마치 단락 식별자 또는 범위가 제출된 것처럼 어드레스를 생성할 수 있다.

다른 예로서, 클라이언트는 어드레스 생성 API(1100)를 호출하고 테이블(1122)의 하나 이상의 셀들을 쭉 넘겨서 서비스가 테이블의 하나 이상의 셀들을 위한 어드레스(가령, GUID-2(1124))를 생성(및 저장)하도록 할 수 있다. 하나의 시나리오에서, 그러한 콘텐트 블록은 계산에서의 사용을 위해 스프레드시트 클라이언트에 의해 액세스될 수 있다. 다른 시나리오에서, (스프레드시트 애플리케이션에 의해 생성되는 것과 같은) 그래프 또는 수학적 함수 합계를 갖는 셀 콘텐트 블록에 특유한 어드레스는 블로그(blog) 내에 또는 워드 프로세싱 또는 프리젠테이션 문서의 일부로서 이 콘텐트를 제공하는 데에 사용될 수 있다.

또 다른 예로서, 클라이언트는 어드레스 생성 API(1100)를 호출하고 메타데이터(1132)를 쭉 넘겨서 메타데이터를 위해 특유한 어드레스(가령, GUID-3(1134))를 획득할 수 있다. 물론, 메타데이터는 다른 위치 식별된 콘텐트의 하나 이상의 블록 내에 포함될 수 있다. 독립적인 어드레스를 통해 액세스되는 경우 메타데이터가 유용할 수 있는 하나의 시나리오는 버전 정보 또는 서명 정보를 위한 것이다. 이 메타데이터는 문서의 협업 이력을 보여주기 위해 나중에 액세스될 수 있다. 몇몇 구현에서, 나중에 액세스되는 경우, 이력 데이터는 URL에 의해 식별되는 블록을 위한 버전의 리스트 및 특정 버전과 연관된 콘텐트를 포함할 수 있다.

권한 관리는 어드레스가능한 블록을 위해 구현될 수도 있다. 예를 들어, 클라이언트가 어드레스 생성 API를 호출하는 경우, 누가 액세스하고 편집하고 보고 공유할 수 있는지에 관한 정보는 요청과 함께 넘겨질 수 있고 그러한 정보는, 예컨대 메타데이터로서, 그 어드레스에서의 콘텐트가 액세스되는 경우에 대비하여 점검되도록 서버에 의해 저장될 수 있다. 이는 범위 또는 문서의 다른 식별 가능한 부분에 대한 액세스 또는 허가를 제어하기 위해 사용될 수 있다. 하나의 시나리오에서 블록은 특정 유저 또는 (예를 들어 권한 관리 시스템에 의해 할당된 것과 같은) 역할에 의한 액세스를 위한 제어를 포함할 수 있다. 다른 시나리오에서 블록은 부분이 판독 전용인지 여부와 같은 허가를 포함할 수 있다. 추가 시나리오에서, 액세스와 허가 모두는 다양한 역할을 갖는 사용자가 다양한 대응하는 허가를 가질 수 있도록 포함될 수 있다.

도 12는 문서로부터 생성된 콘텐트의 서브세트를 사용하여 협업하기 위한 방법의 절차 흐름 다이어그램을 보여준다. 도 12를 참조하면, 마스터 문서(1200)는 액세스 서비스에 의해 관리될 수 있다. 제1 클라이언트(사용자 1)은, 동작(1210)에서, 액세스 서비스에 문서(1200)를 요청할 수 있다. 마스터 문서(1200)는 액세스 서비스와 연관된 데이터베이스에 저장되거나 액세스 서비스에 의해 알려진 위치로부터 검색될 수 있다. 제1 클라이언트로부터의 요청에 응답하여, 액세스 서비스는 적합한 포맷으로 제1 클라이언트에 문서를 제공할 수 있다(1215).

제1 클라이언트는 문서를 수신하고 디스플레이할 수 있다(1220). 제1 클라이언트의 사용자는, 예컨대 텍스트 라인 내의 오타를 교체하는 것, 코멘트를 부가하는 것, 또는 어떤 다른 편집 기능을 수행하는 것에 의해, 선택적으로 문서를 수정할 수 있다(1225). 문서를 보는 동안, 사용자는 하나 이상의 콘텐트 블록을 선택하고(1230) 액세스 서비스에게서 선택을 위한 어드레스를 요청할 수 있다(1235). 요청은 위치 식별자 및/또는 사용자에 의해 선택된 콘텐트를 포함할 수 있다.

액세스 서비스는 어드레스 요청을 수신하고 선택을 위한 어드레스를 생성할 수 있다(1240). 선택된 블록(들)(또는 그것의 위치)은 클라이언트에게 제공되는 블록(들)을 위한 어드레스 및 액세스 서비스에 의해 데이터 스토어(data store)에 저장될 수 있다. 클라이언트는 어드레스를 수신하며(1245), 문서의 메타데이터 내의 블록을 위한 어드레스를 포함할 수 있다. 새로이 할당된 어드레스를 갖는 섹션을 포함하는 문서에 대해 수정(1250)이 행히질 수 있고 블록 내의 데이터(수정이 있다면 이와 함께)은 도로 서버 상으로 푸시되어 액세스 서비스에 의해 어드레스 B1에 저장될 수 있다(1255). 비록 도시되지는 않았으나, 원래의 문서(그리고/또는 그 문서에 대한 수정)는 도로 마스터 문서(1200)로 병합될 수도 있는데 마스터 문서는 원래의 포맷 및 버전으로 남아 있다.

(생성된 콘텐트 블록 B1에 관한 정보가 주어질 수 있는) 제2 클라이언트(사용자 2)는 어드레스 B1에서의 콘텐트를 요청할 수 있다(1260). 액세스 서비스에 대한 요청은 어드레스뿐만 아니라 콘텐트를 위한 원하는 포맷도 포함될 수 있다. 몇몇 경우에, 액세스 서비스는 다른 방법들에 의해 콘텐트를 위한 포맷을 판정할 수 있다. 액세스 서비스는 적합한 포맷으로 제2 클라이언트에게 콘텐트 블록 B1을 제공할 수 있다(1265). 제2 클라이언트는 B1 콘텐트를 수신하고 문서 뷰 내의 콘텐트를 디스플레이할 수 있다(1270). 제2 클라이언트는, 단독으로, 콘텐트 블록을 액세스 서비스에 의해 또한 액세스된 다른 더 큰 문서의 일부로서 또는 제2 클라이언트에 의해 생성되거나 만들어진 다른 더 큰 문서의 일부로서 디스플레이 할 수 있다. 제2 클라이언트의 사용자는 B1으로부터의 콘텐트 블록을 포함하는 문서를 수정할 수 있다(1275). 세이브 명령(또는 다른 특정 상황)이 발생하는 경우, 제2 클라이언트는 액세스 서비스에 병합을 요청할 수 있다(1280).

액세스 서비스는 병합 요청을 수신하고(1285) 어드레스 B1에서의 콘텐트 블록에 수정을 병합하기 위한 동작을 수행할 수 있다(1290).

도 13은 예시적 실시예를 도시한 동작 환경의 다이어그램을 보여준다. 콘텐트 액세스 서비스(1300)는 (제2 서비스의) 제3자 (또는 동일한 당사자) 제공자가 그들의 사용자의 경험 내에 통합할 수 있는 클라우드 상의 확장가능성 계층을 제공할 수 있다.

예를 들어, 제2 서비스(1305)는 특정 파일 부분에 대한 요청(1312)과 함께 콘텐트 액세스 서비스(1300)를 호출할 수 있다. 파일 부분은 콘텐트 액세스 서버(1300)에 의해 액세스가능한 문서 스토어(1320)로부터 검색되거나 클라우드 상에서 호스팅될 수 있다. 요청(1312)을 수신하는 것에 응답하여, 콘텐트 액세스 서비스(1300)는 제2 서비스(1305)를 위해 적합한 포맷으로 제2 서비스(1305)로 데이터의 문서 블록을 반환할 수 있다. 데이터의 포맷은 콘텐트 액세스 서비스(1300)에 의해 변환되거나 제2 서비스(1305)에게 있는 그대로 제공될 수 있다. 제2 서비스(1305)는 클라이언트(1310)에게 콘텐트를 제공할 수 있다. 몇몇 실시예에서, 요청은 다양한 요청들 및/또는 리소스를 포함할 수 있다. 데이터가 제2 서비스(1305)에 의해 수신되면, 데이터는 조합되어 임의의 적합한 방법으로 사용자(1310)에게 제공될 수 있다.

예를 들어, 제2 서비스(1305)는 사용자에 의해 또는 다른 이에 의해 큐레이션된 콘텐트를 포함하는 콘텐트를 수신하기 위하여 사용자가 가입하거나 어떤 다른 방식으로 활용하는 콘텐트 액세스 서비스일 수 있다.

도 14는 큐레이션된 콘텐트를 액세스하는 방법의 절차 흐름 다이어그램을 보여준다. 콘텐트 블록(1400)은 액세스 서비스에 의해 관리될 수 있다. 콘텐트 블록(1400)은 액세스 서비스와 연관된 데이터베이스 내에 저장되거나 액세스 서비스에 의해 알려진 위치로부터 검색될 수 있다. 클라이언트(사용자 3)는, 동작(1410)에서, 가입 서비스(sscription service)일 수 있는 제2 서비스에 발행/문서를 요청할 수 있다. 이 발행/문서는 큐레이션된 콘텐트를 포함할 수 있다. 제2 서비스는 가입자 요청(1415)을 수신하고 이후, 동작(1420)에서 다음 액세스 서비스에 콘텐트 블록(1400)을 요청할 수 있다. 액세스 서비스는 적절한 포맷으로 제2 서비스로 문서를 제공할 수 있다(1425). 제2 서비스가 콘텐트 블록을 수신하면(1430), 콘텐트 블록 B1은 제2 서비스에 의해서 요청되거나 생성될 수 있는 다른 데이터와 조합될 수 있다(1435). 발행/문서는 클라이언트에 의해 수신될 수 있다(1440).

통지 서비스는 가입자에게 콘텐트에 대한 업데이트를 푸시하기 위하여 활용될 수 있다. 대안적으로, 콘텐트는 주기적으로 리프레시되거나(refreshed) 변경이 행해졌다는 통지의 수신 시에 리프레시될 수 있다.

콘텐트 블록을 위한 어드레스를 생성하는 것(가령, 어드레스가능한 개체 또는 오브젝트를 생성하는 것)에 의해, 서버로부터 지명된 오브젝트(들)을 얻고, 지명된 오브젝트(들)의 맞춤화된 뷰를 보고/보거나 편집하고, 병합 및 변환 문제를 다루기 위해 서비스를 활용하는 것이 가능하다.

다음의 예시적 시나리오들은 본 발명의 어떤 실시예와 그것의 많은 이점에 대한 더욱 큰 이해를 제공하기 위해 제시된 것이다. 다음의 예시적 시나리오들은 단지 발명의 실시예의 응용 및 변형 중 몇몇을 예시하도록 의도된 것이다. 물론, 그것들은 어떤 식으로든 발명을 한정하는 것으로 고려되어서는 안 된다.

예시적 시나리오 A:

KINDLE 리더 또는 NOOK 리더의 사용자가 문서를 읽고 있고, - 코멘트하기, 오타를 정정하기, 하이라이팅, 또는 어떤 다른 수정 또는 주석 달기를 수행하는 것에 의해 문서에 기여하고자 한다. 리더가 주로 에디터는 아니더라도 - 이 리더들은 몇몇 편집 능력을 갖는다. 따라서, 발명의 어떤 실시예는 사용자가 리더의 능력, 예를 들어 주석 달기 및 편집 능력을 활용하고, 이후 해당 수정을 도로 문서내에 병합하게 한다. 공동 집필 능력(co-authoring capabilities)을 포함해야 하는 각각의 디바이스 또는 애플리케이션 대신, "서비스로서의 문서" 병합 서비스는 - 이질적인 플랫폼으로부터도 편집/콘텐트를 도로 문서로 자동으로 병합할 수 있다.

하나의 실시예에서, 리더가 (사용자로 하여금 다다르게 되는 가장 먼 위치로부터 디지털 콘텐트를 골라내면서 다수의 디바이스에 걸쳐 디지털 콘텐트를 판독할 수 있도록 하기 위해 사용되는 것과 같은) 동기 동작(synching operation)을 수행하는 경우 병합이 달성될 수 있다. 하나의 그러한 경우, 동기화하는 서비스(synchronizing service)로 위치를 업데이트하기 위한 호출 중에, 문서에 대한 수정이 발명의 일 실시예의 변환 및 병합 서비스에 보내질 수 있다.

다른 실시예에서, 리더는 사용자에 의한 능동적 단계 시에, 예컨대 사용자가 문서를 세이브하기로 선택하는 경우, 변환 및 병합 서비스를 호출할 수 있다. 또 다른 실시예에서, 자동 저장 특징은 변경을 세이브하는 데 사용될 수 있다.

클라이언트가 공동 집필을 이해하고 수행할 수 있는 계층을 포함할 것이 요구되지 않으므로, 디바이스는 "더머"(dumber)이거나 디바이스 리소스를 다른 애플리케이션 및 함수 상에 집중시킬 수 있다.

예시적 시나리오 B:

문서는 마이크로소프트 사(Microsoft Corp.)로부터 이용가능한 MICROSOFT WORD 문서와 워드 프로세싱 소프트웨어의 최근 버전을 위한 DOCX 형식으로 생성될 수 있지만, 저자는 ePub 파일 포맷을 사용할 수 있는 NOOK 리더 또는 전유 AZW 및 KF8 포맷을 사용할 수 있는 AMAZON KINDLE 리더와 같은 리더 상에서 문서를 보고, 아마도 코멘트하거나 편집하고 싶어한다. 서비스를 사용하여, 그 사람은 NOOK 리더 또는 KINDLE 리더를 위한 적절한 포맷의 문서를 액세스하고 이후, 예컨대 몇몇 코멘트를 부가함으로써, 문서에 대한 변경을 행할 수 있다. 코멘트는 이 경우에는 DOCX 파일 포맷인 마스터 파일로 도로 세이브될 수 있다.

예시적 시나리오 C:

현재, 문서를 생성하는 데 사용되는 것과 상이한 버전의 MICROSOFT WORD 문서 파일을 여는 것은 문서가 모든 특징을 디스플레이하지 않는 것을 초래할 수 있다. 예를 들어, 어떤 폰트 또는 포맷화가 변경될 수 있고 리치 또는 복잡한 특징이 사라질 수 있다(예컨대 각주 기능과 일부 매크로). 몇몇 경우에, (DOC 파일 포맷 확장자를 사용하는) MICROSOFT WORD 97 및 (DOCX 파일 포맷 확장자를 사용하는) MICROSOFT WORD 2010의 경우에서와 같이, 버전의 변경은 또한 파일 포맷의 변경이다. 다른 경우에, MICROSOFT WORD 2007 및 MICROSOFT WORD 2010의 경우와 같이 버전의 변경은 추가적인 기능 및/또는 특징을 제공한다.

문서가 더 오래된 버전에서 생산되고 이후 더 새로운 버전에서 열릴 경우 문제가 더 적게 일어날 수 있으나, 특징이 사라지거나 또는 더 최근의 버전에서 충분히 지원되지 않는 경우 여전히 오차가 있을 수 있다. 문서를 여는 데 사용된 것과 상이한 버전에서 생성된 문서를 디스플레이하는 것에서의 문제 외에, 더 최근의 버전에서 생성된 문서가 더 이른 버전에서 열리고 세이브되는 경우, - 문서가 더 최근의 버전에서 다시 열리는 경우에도 더 최근의 버전 특징들은 유실될 수 있다. 예를 들어, MICROSOFT WORD 2010 워드 프로세싱 애플리케이션은 그래픽을 생성하고 조작하기 위한 특징을 포함한다. 만일 문서가 MICROSOFT WORD 2010에서 화려한 그래픽과 함께 생성되었으나, 문서의 첫 번째 페이지 상의 어떤 텍스트 내의 오타를 정정하기 위해 MICROSOFT WORD 97에서 열리고 이후 세이브되는 경우, 세이브된 문서는 화려한 그래픽을 상실한 (파일 포맷 확장자 DOC를 갖는) 더 오래된 버전으로 돌아간다. 단지 하나의 단어가 변경되기 때문에, 전체 문서는 그래픽 이미지의 더 오래된 버전으로 돌아간다.

어떤 실시예에 따르면, 더 오래된 버전에서의 사용자의 의도적인 변경은 인식되고 더욱 새로운 특징을 간직하는 방식으로 새로운 버전에 의해 지원되는 문서로 병합될 수 있다.

예시적 시나리오 D:

콘텐트 액세스 서비스를 사용하여, 콘텐트는 기존 제품의 더 오래된 버전으로 조정될 수 있다. 예를 들어, (최신 프로그램을 실행하고 그 반대로도 그러한) 사용자가 수신할 파일이 종단점에 기반하여 조정될 수 있기 때문에 더 오래된/더 새로운 파일 포맷 확장자를 판독하기 위해 사용자는 소프트웨어 애플리케이션의 최신 버전으로 업그레이드하기를 지연하는 것 또는 다음 버전이 역방향 호환가능하라고 요청하는 것이 가능할 수 있다.

예를 들어, MICROSOFT WORD 2013을 실행하는 클라이언트는 모든 이용가능한 특징을 갖는 온전한 뷰를 수신할 수 있으나, 동일한 문서가 MICROSOFT WORD 2007을 실행하는 클라이언트에서 열리는 경우 서비스는 소비용 뷰를 위한 (그러나 MICROSOFT WORD 2007에 최적화된) 콘텐트를 패키징할 수 있다. 그 최적화는 어떤 특징을 적절한 충실도를 갖는 것으로써 대체하는 것을 포함할 수 있다. 일 예로서, 하나의 버전에서 제공되는 수식 에디터는 역방향 호환가능하지 않을 수 있다. 따라서, 서비스는 문서 패키지 내의 수식을 수식의 이미지로 또는 문서가 제공되는 버전에 적합한 수식 에디터에서 편집가능한 형태로 대체할 수 있다.

유사한 경험이 워드 프로세싱 애플리케이션을 포함하는 다른 생산성 애플리케이션에 제공될 수 있다. 예를 들어, MICROSOFT WORD 2013을 실행하는 클라이언트는 이용가능한 모든 특징을 갖는 온전한 뷰를 수신할 수 있으나, 동일한 문서가 구글 사(Google Inc.)로부터 이용 가능한 GOOGLE DOCS, 아파치 소프트웨어 파운데이션(Apach Software Foundation)으로부터 이용 가능한 APACHE OPENOFFICE, 조호 코포레이션(Zoho Corporation)으로부터 이용 가능한 ZOHO OFFICE와 같은 다른 생산성 애플리케이션을 실행하는 클라이언트로부터 열리는 경우, 서비스는 소비용 뷰를 위한 (그러나 GOOGLE DOCS, OPENOFFICE, 또는 ZOHO OFFICE에 대해 최적화된) 콘텐트를 패키징할 수 있다.

예시적 시나리오 E:

마스터 파일은 최고 충실도 포맷으로 저장될 수 있다. 예를 들어, 마스터 문서는 MICROSOFT WORD의 최신 버전으로 저장될 수 있다. 더 이른 버전의 MICROSOFT WORD를 실행하는 클라이언트는 DOCX 포맷 대신 DOC 포맷의 파일을 제공받을 수 있다. 사용자가 DOC 문서에 대한 변경을 행하고 (자동 저장의 일부로서든 아니면 능동적인 단계에 의해서든) 문서를 저장하는 경우, DOC 문서에 대한 변경은 DOCX 포맷으로 도로 마스터 파일에 세이브된다. 하나의 실시예에서, 전체 DOC 문서는 서버에서 DOCX 포맷으로 복원될 수 있다. 다른 실시예에서, 사용자에 의해 수정된 부분만(그리고 단순히 클라이언트에 DOC 파일을 제공하는 경우 콘텐트에 대해 만들어진 차이의 부분은 아님) 세이브 시에 서버에 반환된다. 그리고 이 부분은 온전한 충실도 문서와 재연관될 수 있다.

예시적 시나리오 F:

실시예는 동일한 제품의 상이한 버전 간 순방향 및 역방향 호환가능성을 가능하게 할 수 있다. 현재, MICROSOFT WORD 프로그램으로 세이브된 파일이 다수의 타겟을 위해 세이브된다. 예를 들어, 수식을 위한 업데이트된 특징 버전이 파일에서 사용되고 그 파일이 세이브되는 경우, 고유의 수식 데이터가 (편집을 위해 적절한 충실도를 갖고 도로 판독될 수 있도록) 세이브되고 수식의 픽처가 - 비록 수식 에디터가 지원되지 않더라도 이전 버전의 워드프로세서가 수식이 무엇처럼 보이는지 디스플레이할 수 있도록 세이브된다. 더 오래된 버전에는 더 새로운 버전이 어떻게 그것의 온전한 충실도를 되찾게 할지에 대한 정보가 들어 있을 수 있다. 예를 들어, 더 오래된 버전은 디스플레이 모드 내에 있고 편집을 허용하지 않을 수 있다.

워드 프로세서의 각 버전에는 향후 버전이 그것의 온전한 충실도를 되찾을 수 있도록 어떤 특징을 왕복(round-trip)시킬지에 대한 정보가 들어 있다. 왕복은 문서가 하나의 버전에서 다른 버전으로 가고, 이후 다시 원래의 버전으로 돌아오는 것을 나타낸다. 예를 들어, 특징 A는 버전 X에 있을 수 있으나, 버전 Y에서 특징 A는 특징 A-프라임(prime)으로 표현될 수 있다. 특징 A 프라임이 버전 X에서 보여지거나 액세스되는 경우, 특징은 A로 되돌아간다. 이러한 구성은 어떻게 더 이른 버전이 특징뿐만 아니라 세이브될 잠재적으로 요구하는 추가적인 데이터를 왕복시킬 수 있을지에 기반하여 다운-레벨 호환가능성을 생성하도록 향후 버전에 압박을 가한다.

발명의 실시예는 어떻게 다양한 특징을 왕복시킬 뿐만 아니라 다수의 버전을 지원하기 위해 세이브되는 데이터의 양을 감소시킬지를 버전이 알게 하는 것에 대한 압박을 제거하거나 최소화한다. 실시예는 제품의 더 오래된 버전이 제품의 새로운 버전으로부터 콘텐트를 판독하고 보존할 수 있도록 한다.

예시적 시나리오 G:

리치 텍스트 포맷(Rich Text Format: RTF)은 많은 워드 프로세싱 애플리케이션에 적합한 교차-플랫폼 문서 상호교환으로서의 사용을 위한 다양한 문서, 텍스트 및 그래픽 포맷화 속성을 인코딩하는 파일 포맷이다. 현재, RFT 파일이 파일의 잠재적인 클라이언트/소비자를 지원하기 위한 파일 내에 픽처의 다수의 개별 버전을 세이브한다. 예를 들어, 하나의 파일이 픽처의 현재 버전을 제공하고, 제2 (또는 그 이상의) 파일이 픽처의 하나 이상의 이전 버전을 제공하고, 다른 파일이 WORD 2.0 버전을 제공하며, 또 다른 파일은 WORDPAD 버전을 제공한다. 변환 및 병합 서비스를 제공함으로써, 워드 프로세싱 애플리케이션은 많은 파일 포맷을 지원하거나 동일한 콘텐트의 다수의 파일을 가질 필요가 없다.

예시적 시나리오 H:

병합 서비스는 이메일로 보내진 문서 내에 변경사항을 자동으로 병합하기 위해 적용될 수 있다. 그러한 경우에, 이메일 서비스 또는 서버는 병합 서비스와 통신할 수 있다. 병합 서비스는 마치 이메일 서비스(또는 이메일 서버)가 에디터인 것처럼 병합을 관리할 수 있다.

예를 들어, 사람들의 그룹이 문서 상에서 협업할 수 있다. 그룹의 한 사람은 그 사람이 오프라인에서 만든 변경을 다른 이에게 이메일에 대한 첨부로서 이메일보내기를 할 수 있다. 서비스 및 시스템은 문서를 위한 식별자를 인지하는바, 수신인(그의 이메일 서비스 또는 이메일 서비스는 병합 서비스와 통신하도록 구성됨)에게 이메일을 보내는 행동에 의해 자동으로 사용자를 대신하여 변경사항을 마스터 문서에 병합할 수 있다.

다른 예에서, 사람들의 그룹 중 한 사람은 제1 이메일 서비스와 연관된 이메일 계정을 사용하여 다른 이에게 이메일을 보내고 문서를 첨부할 수 있다. 수신인들 중 몇몇은 제1 이메일 서비스에 연결되지 않은 제2 이메일 서비스를 사용하고 있을 수 있다. 예를 들어, 제1 이메일 서비스는 마이크로소프트 사(Microsoft Corp.)의 HOTMAIL 이메일 서비스일 수 있고 제2 이메일 서비스는 구글 사(Google Inc.)의 GMAIL 이메일 서비스일 수 있다.

제1 이메일 서비스로부터 연결해제된 제2 이메일 서비스의 사용자 중 하나가 문서를 편집하고 편집된 문서가 첨부된 회신을 하는 경우, 제1 이메일 서비스는 (오프라인으로 만들어진) 변경을 도로 마스터 문서 내에 병합할 수 있다. 제1 이메일 서비스가 첨부를 수신하고 문서(및 문서의 계보)를 식별하는 경우, 제1 이메일 서비스는 병합 서비스와의 통신을 시작할 수 있다. 병합 서비스는 제1 이메일 서비스가 에디터인 것처럼 병합을 관리할 수 있다.

예시적 시나리오 I:

사용자는 제한된 컴퓨팅 파워 및 제한된 대역폭(예를 들어, 지연시간(latency)에 기인함)을 가질 수 있는 (전화와 같은) 디바이스를 사용하는 검토를 위해 문서를 수신할 수 있다. 현재, 사용자가 이 환경에서 문서에 대해 코멘트를 하고자 한다면 - 단일 코멘트 또는 변경이라도 전체 문서가 도로 서버로 송신되는 것을 초래한다. 하나의 실시예에 따르면, 액세스 서비스는 사용자의 디바이스의 제한을 위한 적응을 제공하고 변경이 승인된다는 코멘트 체크박스(예 또는 아니요)를 포함할 수 있다. 그리고, 단지 체크박스 응답의 표시(indication)가 서버에게 반환될 수 있다. 이 방식으로, 디바이스는 그것이 필요로 한 데이터를 서비스로부터 얻었고 승인된 코멘트를 업데이트하기 위해 서비스를 다시 호출할 수 있다. 서비스는 그 표시를 취하여 높은 충실도 수정 및/또는 코멘트 삽입을 수행할 수 있다. 제한된 디바이스의 사용자는 그/그녀가 모든 공동 집필 경험을 (전체 공동 집필 소프트웨어/기술을 디바이스에 전달하는 것에 대한 대가 없이도) 가진 것으로 여긴다.

예시적 시나리오 J:

소비자 디바이스를 위한 콘텐트의 적응의 일 예는 소비자 디바이스가 터치 가능형 디바이스이나, 문서가 터치 가능형 준비가 되지(touch-enabled ready) 않은 경우이다. 서비스는 예컨대 줌하기(zooming) 또는 확대된 특징을 제공함으로써 문서를 더욱 터치 가능형 준비가 되게 하기 위해 문서를 증강시킬(augment) 수 있다. 설명적인 예로서, 원래 큰 스크린 디바이스에서 생성되었지만 작은 스크린 디바이스에 렌더링하기 위해 제공되고 있는 문서 내의 테이블은 그 테이블이 (보기를 위해) 줌인되게(zoomed in) 하는 터치 양상이 부가되어 있을 수 있다.

대안적으로, 또는 추가로, 작은 디바이스의 규모를 고려하여, 서비스는 3 열 테이블(three-column table) 중에서 오직 하나의 열을 위한 공간만 있음을 판정할 수 있고, 작은 스크린에 적합한 형태로 테이블을 제시할 것이다. 이는 줌하기 특징부가하는 것 또는 한 번에 하나의 열을 디스플레이할 뿐인 것을 포함할 수 있다.

예시적 시나리오 K:

사용자는 어드레스 생성 API를 사용하여 어드레스가능한 부분을 지정할 수 있다. 예시적 시나리오에서, 테이블은 스프레드시트 애플리케이션에서 액세스되고, 보여지고, 수정될 수 있다. 이 테이블은 워드프로세싱 애플리케이션(이로부터 테이블이 생성되어 어드레스가능한 영역 내로 됨)에서 획득될 수 있다. 스프레드시트 애플리케이션에서 변경이 행해지면, 테이블은 도로 워드 프로세싱 문서로 송신되고 (필요한 경우 변환되어) 병합될 수 있다. 테이블은 다수의 문서에 들어갈 수 있는데 - 오브젝트가 정의되(고 어드레스를 제공받으)면 도로 서버로 푸시되는 오브젝트에 대한 변경은 전체 중의 일부로서 (해당 어드레스와 함께) 해당 오브젝트를 사용하는 모든 "문서" 내에서 가시적(visible)일 수 있다.

사용자는 콘텐트의 버전을 해당 버전을 위한 별도의 어드레스를 생성함으로써 "동결"(freeze)할 수 있다. 몇몇 경우에, 추가적인 허가는 동결된 버전에 대한 액세스와 연관될 수 있다.

사용자는 콘텐트 블록에 대한 변경이 사용자가 택한 바와 같이 업데이트되도록 그 블록을 편집하는 동안 일시적인 버전을 제공할 수도 있다. 하나의 구현에서, 이는 사용자가 블록에 대한 변경을 일시적으로 세이브하고 있음을 클라이언트에서 사용자가 식별하는 별도의 푸시 능력을 가짐으로써 성취될 수 있다. 하나의 그러한 경우에, 서비스는 이전 버전이든 일시적 변경이든 어느 하나를 포인터와 연관시킬 수 있다.

예시적 시나리오 L:

하나의 예시적 시나리오에서, 에디터는 html로 된 문서를 요청할 수 있다. HTML로 제공된 문서를 보기 및/또는 편집하는 동안, 서비스는 어드레스가능한 서브-부분을 생성하기 위해 기동될 수 있다. 즉, 어드레스 서비스는 (연관된 메타데이터를 포함할 수 있거나 포함하지 아니할 수 있는) 콘텐트의 블록을 위한 어드레스를 생성할 수 있다. 예를 들어, 보기 페이지를 위한 어드레스에 대한 요청 및 보기 페이지 내에 디스플레이되는 데이터가 요청될 수 있다. 예를 들어, 그 요청은 영역을 보기 페이지로서 정의할 수 있고 그 보기 페이지 내의 데이터는 새로 생성된 어드레스로 저장(되거나 이와 연관)될 수 있다. 실시예에 따르면, 보기 페이지는 추가로 하위-분할될(sub-divided) 수 있고 특정 영역을 위해 어드레스가 생성될 수 있다. 어느 경우든, 보기 페이지의 부분을 캡처하도록 요청하는 클라이언트는 보여지는 문서에 대해 행해진 수정으로 인한 데이터 크기의 변경을 다룰 수 있을 것이 요구되지 않는다. 대신, 클라이언트는 병합 및 변환 문제를 다루는 어드레스 생성 API를 기동시킬 수 있다.

예를 들어, 에디터/뷰어에 의해 수신되는 문서의 버전은 200 문자 스트링(character string)의 문자 55 내지 문자 75의 범위 사이의 콘텐트를 제시할 수 있다. 그러나, 만일 (그 범위 내이거나 아니거나) 문서에 대한 수정이 행해지는 경우, 보기를 위해 검색되는 범위는 사용자가 원하는 섹션을 포섭하지(cover) 아니할 수 있다.

그 범위 내의 텍스트를 위한 어드레스를 생성함으로써, 만일 동일한 어드레스와 연관된 텍스트의 변경으로 인해 그 범위가 변경되는 경우, 변경된 범위의 문제는 그 변경이 모든 콘텐트를 검색하는 데 사용될 수 있는 어드레스와 연관될 수 있기 때문에 문제가 안 된다. 몇몇 경우에, 특정 범위 내의 텍스트를 클라이언트에게 주기 위해 요청이 행해지는 경우 어드레스가 요청되었다는 어드레스 생성 API에 의한 묵시적인 이해가 있을 수 있다.

범위는 HTML 문서의 콘텐트의 부분을 나타내며, 임의의 지점에서 시작되고 끝날 수 있다. 일반적으로, 범위 오브젝트는 범위의 시작점과 종료점을 포함하며, 범위 내의 (텍스트 또는 HTML 요소와 같은) 콘텐트의 카피하기, 삭제하기 및 대체하기를 가능하게 한다. 별칭(moniker)은 하나 이상의 오브젝트를 식별하고 위치 찾는 데에 사용될 수 있는 별명 또는 이름을 나타낸다. HTML은 앵커(anchor) 및 지명된 영역을 포함할 수도 있는데, 이는 어드레스 서비스를 통해 어드레스가능하게 될 수 있다.

예시적 시나리오 M:

(제2 서비스의 또는 웹 실재(web presence)를 갖는) 제3자(또는 동일 당사자) 제공자는 자기 자신의 애플리케이션을 제공하기 위해 어드레스 생성 서비스를 사용할 수 있다. 예를 들어, 대출 회사(mortgage company)(또는 다른 벤더(vender))는 그들의 웹 애플리케이션의 사용자가 대출을 얻기 위한 상이한 옵션을 시도할 수 있도록 하는 웹 애플리케이션을 제공하기 위해서 어드레스 생성 서비스를 사용할 수 있다. 대출 조건에 대해 사용자에 의해 조절될 수 있을 변수는 기간(가령, 30년, 15년, 7년), 포인트, 총량, 월별 지불액 및 유사한 것을 포함할 수 있다. 로직(logic)의 이 유형은 스프레드시트 애플리케이션을 사용하여 구현될 수 있다. 만일 대출 회사가 단지 스프레드시트를 소비자에게 제공하는 경우, 그러한 프로그램을 구현하는 스프레드시트 애플리케이션의 워크시트의 제어는 쉽게 유실될 수 있다. 그러한 프로그램을 구현하는 데 사용될 수 있는 다른 옵션은 대출 회사(또는 벤더)가 그들 자신의 웹 애플리케이션 및 계산 엔진을 만들었는지일 것이다.

스프레드시트를 제공하거나 새로운 웹 애플리케이션을 구축하는 것 대신, 대출 회사는 할부상환(amortization) 또는 다른 대출 시나리오 옵션을 제공하기 위해 여기에서 서술된 서비스 중 하나 이상을 활용해 볼 수 있다. 예시적 구현에 따르면, 스프레드시트 애플리케이션의 워크시트는 대출 회사에 의해 생성될 수 있고, 어떤 셀들은 사용자에 대한 맞춤화된 뷰의 일부로서 소비자에게 이용가능하게 될 수 있다. 예를 들어, 웹 애플리케이션(또는 웹페이지)은 스프레드시트 문서를 액세스 하고 대출 회사가 어드레스가능하게 한 부분에 기반하여 사용자에게 뷰를 제시할 수 있다. 하나의 구현에서, 대출 회사는 소비자로부터 정보를 수집하고, 스프레드시트를 생성하며, 소비자로부터 수집된 정보로써 스프레드시트를 채우는(populate) 웹 애플리케이션을 생성할 수 있다. "스프레드시트"는 (가령, 범위 부가 API(add range API) 또는 범위 수정/업데이트 API(modify/update range API)를 통해) 워크시트를 생성하고 스프레드시트에 범위를 부가하며 워크시트(또는 셀 또는 범위)에 대한 업데이트를 가능하게 하는 스프레드시트 API를 통해 호출될 수 있다.

스프레드시트가 생성되면, 대출 회사의 애플리케이션은 사용자로 하여금 특별히 생성된 사용자 인터페이스에서 데이터를 보고 조작하게 하는 스프레드시트를 개시하거나(launch) 아니면 (예컨대 독립적으로 어드레스가능한 총량 셀로부터) 정보를 제시할 수 있다. 스프레드시트 뷰 또는 특별히 생성된 사용자 인터페이스 뷰는 사용자로부터 입력을 수신하고 이후 (가령, 병합 후 셀로부터 데이터를 얻기 위한 호출 또는 계산 API를 통해) 계산을 수행하고/하거나 결과를 업데이트하기 위한 서비스를 호출할 수 있다.

추가 구현에서, 데이터 입력 및 계산 결과 중 어떤 것과 연관된 스프레드시트의 셀은 (어드레스 생성 서비스를 사용함으로써) 별도로 어드레스가능할 수 있고, 예컨대 대출 애플리케이션의 일부로서 사용될 수 있는 문서 뷰를 생성하기 위해 워드 프로세싱 또는 다른 애플리케이션에 의해 액세스될 수 있다.

도 8은 몇몇 실시예에서 사용되는 컴퓨팅 디바이스의 컴포넌트를 예시하는 블록 다이어그램을 도시한다. 예를 들어, 시스템(800)은 하나 이상의 애플리케이션을 실행할 수 있는 데스크톱 또는 노트북 컴퓨터 또는 태블릿 또는 스마트폰 또는 유사한 것의 형태로 클라이언트 디바이스, 에디터 또는 리더를 구현하는 데에서 사용될 수 있다. 몇몇 실시예에서, 시스템(800)은 통합된 PDA 및 무선 전화와 같은 통합된 컴퓨팅 디바이스이다. 본 문서에서 기술된 시스템의 양상은 모바일 및 전통적인 데스크톱 컴퓨터 양자 모두는 물론, 서버 컴퓨터 및 다른 컴퓨터 시스템에 적용가능하다는 점이 이해되어야 한다. 예를 들어, 터치 스크린 또는 터치 가능형(touch-enabled) 디바이스(터치 가능형 트랙 패드 또는 마우스를 포함하나 이에 한정되지 않음)가 모바일 및 데스크톱 디바이스 양자 모두에 적용가능할 수 있다.

시스템(800)은 하나 이상의 애플리케이션 프로그램(810), 그리고/또는 운영 체제(820)의 명령어에 따라 데이터를 처리하는 프로세서(805)를 포함한다. 프로세서(805)는 센서(가령, 자기계(magnetometer), 주변광 센서(ambient light sensor), 근접 센서(proximity sensor), 가속도계(accelerometer), 자이로스코프(gyroscope), 전역 측위 시스템(Global Positioning System) 센서, 온도 센서, 충격 센서) 및 네트워크 연결성 컴포넌트(가령, 무선/네트워크 인터페이스(Radio/network interface)(835)를 포함함)와 같은 하나 이상의 다른 컴포넌트와 함께 있는 시스템 온 칩(System-on-Chip: SoC)일 수 있거나 이에 포함된다.

하나 이상의 애플리케이션 프로그램(810)은 메모리(815) 내로 로드되어(loaded) 운영 체제(820) 상에서 또는 이와 연관되어 실행될 수 있다. 애플리케이션 프로그램의 예는 전화 걸기(phone dialer) 프로그램, 이메일 프로그램, PIM 프로그램, 워드 프로세싱 프로그램, 스프레드시트 프로그램, 인터넷 브라우저 프로그램, 메시징 프로그램, 게임 프로그램 및 유사한 것을 포함한다. 다른 애플리케이션 프로그램이 메모리(815) 내에 로드되어 디바이스 상에서 실행될 수 있는데, 다양한 클라이언트 및 서버 애플리케이션들을 포함한다.

메모리(815)는 통합된 메모리 컴포넌트 및 탈착가능한(removable) 메모리 컴포넌트를 포함하는 하나 이상의 메모리 컴포넌트를 수반할 수 있다는 점 및 메모리 컴포넌트 중 하나 이상이 운영 체제를 저장할 수 있다는 점이 이해될 수 있다. 다양한 실시예에 따르면, 운영 체제는 심비안 사(Symbian Ltd.)로부터의 SYMBIAN OS, 마이크로소프트 사(Microsoft Corporation)로부터의 WINDOWS MOBILE OS, 마이크로소프트 사로부터의 WINDOWS PHONE OS, 마이크로소프트 사로부터의 WINDOWS, 휴렛 패커드 사(Hewlett-Packard Company)로부터의 PALM WEBOS, 리서치 인 모션 사(Research In Motion Limited)로부터의 BLACKBERRY OS, 애플 사(Apple Inc.)로부터의 APPLE IOS, 그리고 구글 사(Google Inc.)로부터의 GOOGLE ANDROID OS를 포함하나 이에 한정되지 않는다. 다른 운영 체제가 고려된다.

시스템(800)은 또한 메모리(815) 내의 비휘발성 스토리지(non-volatile storage)(825)를 포함한다. 비휘발성 스토리지(825)는 시스템(800)의 전력이 다운된(powered down) 경우 유실되지 않아야 할 지속적 정보를 저장하는 데에 사용될 수 있다. 애플리케이션 프로그램(810)은 생산성 애플리케이션(productivity application) 및 유사한 것 내의 콘텐트의 생성 또는 수정 중에 실행되는 명령의 레코드(record)와 같은, 비휘발성 스토리지(825) 내 정보를 사용하고 저장할 수 있다. 동기화 애플리케이션(synchronization application)은 비휘발성 스토리지(825) 내에 저장된 정보를 (서버와 같은) 호스트 컴퓨터 시스템에 저장된 대응하는 정보와 동기화되게 유지하도록 호스트 컴퓨터 시스템 상의 대응하는 동기화 애플리케이션과 상호작용하기 위해 애플리케이션 프로그램(810)의 일부로서 포함되거나 상주할(reside) 수도 있다.

시스템(800)은 전력 공급부(power supply)(830)를 가지는데, 이는 하나 이상의 배터리 및/또는 에너지 수집기(energy harvester)(주변 방사(ambient-radiation), 광전지(photovoltaic), 압전기(piezoelectric), 열전기(thermoelectric), 정전기(electrostatic) 및 유사한 것)으로서 구현될 수 있다. 전력 공급부(830)는 배터리를 보충하거나 재충전하는 전동 도킹 받침대(powered docking cradle) 또는 AC 어댑터와 같은 외부 전력원(power source)을 더 포함할 수 있다.

시스템(800)은 또한 무선 주파수 통신을 송신 및 수신하는 기능을 수행하는 무선/네트워크 인터페이스(835)를 포함할 수 있다. 무선/네트워크 인터페이스(835)는 통신 서비스사 또는 서비스 제공자를 통한, 시스템(800)과 "외부 세계" 간의 무선 연결성(wireless connectivity)을 가능하게 한다. 무선/네트워크 인터페이스(835)로의 및 이로부터의 송신은 무선/네트워크 인터페이스(835)에 의해 수신된 통신을 애플리케이션(810)으로 전파하거나 이와 반대로 하는 운영 체제(820)의 제어 하에 행해진다.

무선/네트워크 인터페이스(835)는 시스템(800)으로 하여금 서버 컴퓨팅 디바이스 및 다른 클라이언트 디바이스를 포함하는 다른 컴퓨팅 디바이스와 네트워크 상에서 통신하게 한다.

가청(audible) 신호를 사용자에게 제공하고 가청 신호를 사용자로부터 수신하기 위해 오디오 인터페이스(840)가 사용될 수 있다. 예를 들어, 오디오 인터페이스(840)는 가청 출력을 제공하는 스피커(speaker) 및 가청 입력을 수신하는 마이크(microphone)에, 가령 통화(telephone conversation)를 가능하게 하기 위해 커플링될(coupled) 수 있다. 사용자가 음성 명령을 통해 컴퓨팅 디바이스와 상호작용할 수 있도록 스피커가 포함될 수도 있다.

시스템(800)은 정지 이미지, 비디오 스트림 및 유사한 것을 기록하기 위한 선택적인 카메라(도시되지 않음)의 동작을 가능하게 하는 비디오 인터페이스(845)를 더 포함할 수 있다. 컴퓨팅 디바이스와 상호작용하기 위해 사용되는 제스처를 포착하기(capture) 위해 카메라가 사용될 수도 있다.

시각적 출력이 디스플레이(855)를 통해 제공될 수 있다. 디스플레이(855)는 터치 스크린 디스플레이일 수 있다. 몇몇 경우에, 디스플레이는 터치 스크린이 아닐 수 있고 디스플레이(855) 상의 그래픽 사용자 인터페이스(graphical user interface)의 일부로서 디스플레이되는 아이템을 선택하기 위해 버튼, 키, 롤러 휠(roller wheel) 및 유사한 것과 같은 사용자 입력 구성요소가 사용된다.

키패드(860)가 사용자 입력을 위해 포함될 수도 있다. 키패드(860)는 물리적 키패드이거나 터치 스크린 디스플레이(855) 상에 생성된 소프트 키패드(soft keypad)일 수 있다. 몇몇 실시예에서, 디스플레이 및 키패드는 조합된다. 몇몇 실시예에서는 오디오 인터페이스(840) 및 비디오 인터페이스(845)를 포함하는 둘 이상의 입력/출력(Input/Output: I/O) 컴포넌트가 조합될 수 있다. 개별적인(discrete) 프로세서들이 I/O 컴포넌트와 함께 포함될 수 있거나 처리 기능이 프로세서(805)에 내장될(built-in) 수 있다.

디스플레이(855)는 그래픽 사용자 인터페이스("GUI") 요소, 예측적이고 콘텍스트적인 툴바 사용자 인터페이스(predictive contextual toolbar user interface), 텍스트, 이미지, 비디오, 통지, 가상 버튼, 가상 키보드, 메시징 데이터, 인터넷 콘텐트, 디바이스 상태, 시간, 날짜, 달력 데이터, 선호사항, 지도 정보, 위치 정보, 그리고 시각적 형태로 제시될 수 있는 임의의 다른 정보를 제시할 수 있다. 몇몇 실시예에서, 디스플레이(855)는 임의의 능동 또는 수동 매트릭스 기술 및 임의의 백라이팅(backlighting) 기술(사용되는 경우)를 활용하는 액정 디스플레이(liquid crystal display)("LCD")이다. 몇몇 실시예에서, 디스플레이(855)는 유기 발광 다이오드(organic light emitting diode)("OLED") 디스플레이이다. 물론, 다른 디스플레이 유형이 고려된다.

(디스플레이와 연관될 수 있는) 터치스크린은 터치의 존재 및 위치를 검출하도록 구성된 입력 디바이스이다. 터치스크린은 저항성 터치스크린(resistive touchscreen), 용량성 터치스크린(capacitive touchscreen), 표면 음파 터치스크린(surface acoustic wave touchscreen), 적외선 터치스크린(infrared touchscreen), 광학 촬상 터치스크린(optical imaging touchscreen), 분산 신호 터치스크린(dispersive signal touchscreen), 음향 펄스 인식 터치스크린(acoustic pulse recognition touchscreen)일 수 있거나, 임의의 다른 터치스크린 기술을 활용할 수 있다. 몇몇 실시예에서, 터치스크린은 사용자로 하여금 디스플레이 상에 제시된 객체 또는 다른 정보와 상호작용하기 위해 하나 이상의 터치를 사용할 수 있게 하기 위해 투명층으로서 디스플레이의 상부에 포함된다.

다른 실시예에서, 디스플레이를 포함하지 않는 컴퓨팅 디바이스의 표면 상에 터치 패드가 포함될 수 있다. 예를 들어, 컴퓨팅 디바이스는 디스플레이의 상부에 포함된 터치스크린 및 디스플레이의 맞은편의 표면 상의 터치 패드를 가질 수 있다.

몇몇 실시예에서, 터치스크린은 단일터치(single-touch) 터치스크린이다. 다른 실시예에서, 터치스크린은 다중터치(multi-touch) 터치스크린이다. 몇몇 실시예에서, 터치스크린은 개별적인 터치, 단일 터치 제스처 및/또는 멀티터치 제스처를 검출하도록 구성된다. 이들은 편의상 제스처로 본 문서에서 집합적으로 지칭된다. 여러 제스처가 이제 기술될 것이다. 이 제스처들은 예시적이고 부기된 청구항의 범주를 한정하도록 의도된 것이 아니라는 점이 이해되어야 한다. 또한, 기술된 제스처, 추가적인 제스처 및/또는 대안적인 제스처는 터치스크린과의 사용을 위한 소프트웨어로 구현될 수 있다. 따라서, 개발자는 특정 애플리케이션 프로그램에 특유한 제스처를 만들어낼 수 있다.

몇몇 실시예에서, 터치스크린은 사용자가 디스플레이 상에 제시된 아이템 상에서 터치스크린을 한 번 톡 치는 탭 제스처(tap gesture)를 지원한다. 탭 제스처는 다양한 이유(사용자가 톡 치는 것은 무엇이든 열거나 개시하기(launching)를 포함하나 이에 한정되지 않음)로 사용될 수 있다. 몇몇 실시예에서, 터치스크린은 사용자가 디스플레이 상에 제시된 아이템 상에서 터치스크린을 두 번 톡 치는 더블 탭 제스처(double tap gesture)를 지원한다. 더블 탭 제스처는 다양한 이유(단계적으로 줌인하기(zooming in) 또는 줌아웃하기(zooming out) 그리고 텍스트의 글마디(word)를 선택하기를 포함하나 이에 한정되지 않음)로 사용될 수 있다. 몇몇 실시예에서 터치스크린은 사용자가 터치스크린을 톡 치고 적어도 사전정의된 시간 동안 접촉(contact)을 유지하는 탭 및 홀드 제스처(tap and hold gesture)를 지원한다. 탭 및 홀드 제스처는 다양한 이유(콘텍스트 특정 메뉴(context-specific menu)를 열기를 포함하나 이에 한정되지 않음)로 사용될 수 있다.

몇몇 실시예에서, 터치스크린은 사용자가 터치스크린 상에 손가락을 두고 터치스크린 상에서 손가락을 움직이면서 터치스크린과의 접촉을 유지하는 팬 제스처(pan gesture)를 지원한다. 팬 제스처는 다양한 이유(제어된 속도(controlled rate)로 스크린, 이미지 또는 메뉴를 쭉 움직이기를 포함하나 이에 한정되지 않음)로 사용될 수 있다. 여러 손가락 팬 제스처도 고려된다. 몇몇 실시예에서, 터치스크린은 사용자가 스크린이 이동하기를 원하는 방향으로 사용자가 손가락을 휙 가져다 대는(swipe) 플릭 제스처(flick gesture)를 지원한다. 플릭 제스처는 다양한 이유(메뉴 또는 페이지를 쭉 수평으로 또는 수직으로 스크롤하기(scrolling)를 포함하나 이에 한정되지 않음)로 사용될 수 있다. 몇몇 실시예에서, 터치스크린은 사용자가 터치 스크린 상에서 두 손가락(가령, 엄지와 검지)으로 꼭 집는 움직임(pinching motion)을 행하거나 두 손가락을 서로 떨어지게 움직이는 핀치 및 스트레치 제스처(pinch and stretch gesture)를 지원한다. 핀치 및 스트레치 제스처는 다양한 이유(웹사이트, 지도 또는 픽처를 점진적으로 줌인하기 또는 줌아웃하기를 포함하나 이에 한정되지 않음)로 사용될 수 있다.

위 제스처들은 그 제스처를 수행하기 위한 하나 이상의 손가락의 사용을 참조하여 기술되었으나, 터치스크린과 상호작용하기 위해 다른 부속물(가령 발가락, 코, 턱, 또는 스타일러스와 같은 객체)이 사용될 수 있다. 따라서, 위 제스처들은 예시적인 것으로 이해되어야 하고 어떤 식으로든 한정적인 것으로 해석되어서는 안 된다.

시스템(800)을 구현하는 임의의 모바일 또는 데스크톱 컴퓨팅 디바이스는 기술된 것보다 더 많거나 더 적은 특징 또는 기능을 가질 수 있고 본 문서에서 기술된 구성에 한정되지 않는다는 점이 이해되어야 한다.

예를 들어, 몇몇 실시예에서, 다양한 유형의 사용자 인터페이스 및 정보가 투영된 벽면(wall surface) 상에서 다양한 유형의 사용자 인터페이스 및 정보가 디스플레이되고 상호작용될 수 있다.

다양한 구현에서, 시스템(800)을 통해 저장된 데이터/정보는 디바이스 상에 국부적으로(locally) 저장된 데이터 캐시를 포함할 수 있거나 데이터는 디바이스 및 디바이스와 연관된 별도의 컴퓨팅 디바이스, 예컨대 인터넷과 같은 분산 컴퓨팅 네트워크(distributed computing network) 내의 서버 컴퓨터 간의 유선 연결을 통해 또는 무선/네트워크 인터페이스(835)를 통해 디바이스에 의해 액세스될 수 있는 임의의 개수의 저장 매체 상에 저장될 수 있다. 인식되어야 하는 바와 같이 그러한 데이터/정보는 무선 인터페이스(835) 또는 분산 컴퓨팅 네트워크를 거쳐 디바이스를 통해 액세스될 수 있다. 유사하게, 그러한 데이터/정보는 전자 메일 및 협력적 데이터/정보 공유 시스템을 포함하는 잘 알려진 데이터/정보 전송 및 저장 수단에 따라 저장 및 사용을 위해 컴퓨팅 디바이스들 간에 용이하게 전송될 수 있다.

본 문서에 개진된 어떤 기법은 하나 이상의 컴퓨팅 디바이스에 의해 실행되는 컴퓨터 실행가능 명령어(가령 프로그램 모듈)의 일반적인 콘텍스트에서 기술될 수 있다. 일반적으로, 프로그램 모듈은 루틴, 프로그램, 오브젝트, 컴포넌트 및 데이터 구조(특정한 태스크를 수행하거나 특정한 추상적(abstract) 데이터 유형을 구현함)를 포함한다.

실시예는 컴퓨터 프로세스, 컴퓨팅 시스템, 또는 제조품(article of manufacture)(가령 컴퓨터 프로그램 제품 또는 컴퓨터 판독가능 매체)으로서 구현될 수 있다. 본 문서에서 기술된 어떤 방법 및 프로세스는 코드 및/또는 데이터(이는 하나 이상의 컴퓨터 판독가능 매체 상에 저장될 수 있음)로서 구현화될 수 있다. 발명의 어떤 실시예는 컴퓨터 시스템(그 안에서 명령어의 세트는 실행되는 경우 그 시스템으로 하여금 앞서 논의된 방법론 중 임의의 하나 이상의 방법론을 수행하게 할 수 있음)의 형태로 된 머신의 사용을 고려한다. 어떤 컴퓨터 프로그램 제품은 컴퓨터 시스템에 의해 판독가능하고 컴퓨터 프로세스를 실행하기 위한 명령어의 컴퓨터 프로그램을 인코딩하는 하나 이상의 컴퓨터 판독가능 저장 매체일 수 있다.

컴퓨터 판독가능 매체는 임의의 이용가능한 컴퓨터 판독가능 저장 매체 또는 통신 매체(컴퓨터 시스템에 의해 액세스될 수 있음)일 수 있다.

통신 매체는, 매체로서 이에 의해 예컨대 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 다른 데이터를 포함하는 통신 신호가 하나의 시스템으로부터 다른 시스템으로 전송되는 매체를 포함한다. 통신 매체는 케이블 및 배선(가령, 광섬유, 동축 및 유사한 것)과 같은 유도형 송신(guided transmission) 매체, 그리고 음향, 전자기, RF, 마이크로파 및 적외선과 같은, 에너지 파동을 전파할 수 있는 무선 (비유도형 송신) 매체를 포함할 수 있다. 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 다른 데이터는 예컨대 반송파 또는 유사한 메커니즘(확산 스펙트럼 기법의 일부로서 이용되는 것과 같은 것)과 같은 무선 매체 내의 변조된 데이터 신호로서 구현화될 수 있다. "변조된 데이터 신호"라는 용어는 그것의 특성 중 하나 이상이 그 신호 내에 정보를 인코딩하는 것과 같은 방식으로 변경되거나 설정되는 신호를 나타낸다. 변조는 아날로그, 디지털 또는 혼합된 변조 기법일 수 있다. 통신 매체, 특히 반송파 및 다른 전파 신호(컴퓨터 시스템에 의해 사용가능한 데이터를 포함할 수 있음)는 컴퓨터 판독가능 저장 매체로서 포함된 것은 아니다.

한정이 아니라 예로서, 컴퓨터 판독가능 저장 매체들은 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 다른 데이터와 같은 정보의 저장을 위해 임의의 방법 또는 기술로 구현된 휘발성 및 비휘발성, 탈착가능 및 비탈착가능(non-removable) 매체들을 포함할 수 있다. 예를 들어, 컴퓨터 판독가능 매체는 랜덤 액세스 메모리(RAM, DRAM, SRAM)와 같은 휘발성 메모리; 플래시 메모리, 다양한 판독전용 메모리(ROM, PROM, EPROM, EEPROM), 자기(magnetic) 및 강자성(ferromagnetic)/강유전성(ferroelectric) 메모리(MRAM, FeRAM), 그리고 자기 및 광학 저장 디바이스(하드 드라이브, 자기 테이프, CD, DVD)와 같은 비휘발성 메모리; 또는 컴퓨터 시스템에 의한 사용을 위해 컴퓨터 판독가능 정보를 저장하는 것이 가능한 현재 알려지거나 이후 개발되는 다른 매체를 포함하나 이에 한정되지 않는다. "컴퓨터 판독가능 저장 매체"는 반송파 또는 전파 신호로 구성되지 않는다.

추가로, 본 문서에서 기술된 방법 및 프로세서는 하드웨어 모듈로 구현될 수 있다. 예를 들어, 하드웨어 모듈은 애플리케이션 특정 집적 회로(Application-Specific Integrated Circuit: ASIC) 칩, 필드 프로그램가능 게이트 어레이(Field Programmable Gate Array: FPGA), 그리고 현재 알려지거나 이후 개발되는 다른 프로그램가능 논리 디바이스를 포함할 수 있으나 이에 한정되지 않는다. 하드웨어 모듈이 활성화되는 경우, 하드웨어 모듈은 하드웨어 모듈 내에 포함된 방법 및 프로세스를 수행한다.

이 명세서에서 "하나의 실시예", "일 실시예", "예시적 실시예" 등에 대한 여하한 언급은 그 실시예와 관련하여 기술된 특정한 특징, 구조 또는 특성이 발명의 적어도 하나의 실시예에 포함됨을 의미한다. 명세서 내의 다양한 자리에서 그러한 구(phrase)들의 출현은 반드시 모두 동일한 실시예를 나타내고 있는 것은 아니다. 추가로, 본 문서에 개시된 여하한 발명 또는 이의 실시예의 어떠한 구성요소 또는 한정이라도 임의의 및/또는 모든 다른 구성요소 또는 한정(개별적으로 또는 임의의 조합으로) 또는 본 문서에서 개시된 여하한 다른 발명 또는 이의 실시예와 조합될 수 있고, 모든 그러한 조합이 발명의 범주와 함께 그에 대한 한정 없이 고려된다.

본 문서에서 기술된 예 및 실시예는 예시적 목적을 위한 것일 뿐이라는 점 및 이를 감안한 다양한 수정 또는 변경이 당업자에게 시사될 것이고 이 출원의 사상 및 범위 내에 포함될 것이라는 점이 이해되어야 한다.

Claims (15)

1. 프로세서에 의해 수행되는 방법에 있어서,
   제1 문서를 검색하는 단계 - 상기 제1 문서는 적어도 제1 어드레스를 포함하는 적어도 2개의 상이한 어드레스를 통해 검색된 콘텐트 블록들을 포함함 - 와,
   상기 적어도 2개의 상이한 어드레스를 통해 검색된 상기 콘텐트 블록들을 포함하는 상기 제1 문서의 제1 뷰를 디스플레이하는 단계와,
   상기 제1 문서의 식별된 콘텐트의 선택을 수신하는 단계와,
   상기 제1 문서의 상기 식별된 콘텐트에 대한 어드레스를 생성하기 위한 요청을 수신하는 단계와,
   상기 어드레스를 생성하기 위한 요청을 수신한 것에 응답하여, 상기 제1 문서의 상기 식별된 콘텐트에 대한 제2 어드레스를 생성하도록 어드레스 서비스를 기동시키고(invoking) 상기 제2 어드레스에서 상기 식별된 콘텐트의 카피의 저장을 시작하는 단계와,
   상기 식별된 콘텐트의 콘텐트 중 일부분의 수정을 수신하는 단계와,
   상기 식별된 콘텐트의 상기 카피 및 상기 수정을 상기 제2 어드레스에 저장하는 단계를 포함하는
   방법.
   
2. 제1항에 있어서,
   상기 식별된 콘텐트의 상기 카피는 상기 식별된 콘텐트의 마스터 문서로 간주되고, 상기 방법은 상기 제2 어드레스를 위한 URL(uniform resource locator)을 수신하는 단계를 더 포함하되,
   상기 URL은 상기 식별된 콘텐트의 상기 마스터 문서에 액세스하는
   방법.
   
3. 제1항에 있어서,
   상기 식별된 콘텐트는 위치 식별자(location identifier)를 이용하여 식별되는
   방법.
   
4. 제3항에 있어서,
   상기 위치 식별자는 단락 식별자(paragraph identifier), 라인 식별자(line identifier), 문자 식별자(character identifier), 범위(range) 및 부분 식별자(part identifier) 중 적어도 하나를 포함하는
   방법.
   
5. 제1항에 있어서,
   상기 제1 문서의 상기 식별된 콘텐트에 대한 수정을 마스터 문서와 병합하도록 요청하기 위해 병합 서비스(merge service)를 기동시키는 단계를 더 포함하는
   방법.
   
6. 제5항에 있어서,
   상기 마스터 문서는 상기 제2 어드레스에 위치한 상기 식별된 콘텐트의 상기 카피인
   방법.
   
7. 제1항에 있어서,
   상기 제1 문서의 상기 식별된 콘텐트에 대한 상기 제2 어드레스를 요청하기 위해 상기 어드레스 서비스를 기동시키는 단계는 상기 제2 어드레스 및 상기 식별된 콘텐트에 액세스하고 수정하기 위한 연관된 허가를 요청하는 단계를 포함하는
   방법.
   
8. 제1항에 있어서,
   상기 수정을 수신하는 단계는 상기 어드레스를 생성하기 위한 요청 이전인
   방법.
   
9. 제1항에 있어서,
   상기 수정을 수신하는 단계는 상기 어드레스를 생성하기 위한 요청 이후인
   방법.
   
10. 시스템으로서,
    디스플레이와,
    프로세서와,
    하나 이상의 저장 매체와,
    상기 하나 이상의 저장 매체 상에 저장된 애플리케이션을 포함하되,
    상기 애플리케이션은 상기 프로세서에 의해 실행될 때, 상기 프로세서가,
    제1 문서를 검색하고 - 상기 제1 문서는 적어도 제1 어드레스를 포함하는 적어도 2개의 상이한 어드레스를 통해 검색된 콘텐트 블록들을 포함함 -,
    상기 적어도 2개의 상이한 어드레스를 통해 검색된 상기 콘텐트 블록들을 포함하는 상기 제1 문서의 제1 뷰를 상기 디스플레이에서 디스플레이하고,
    상기 제1 문서의 식별된 콘텐트의 선택을 수신하고,
    상기 제1 문서의 상기 식별된 콘텐트에 대한 어드레스를 생성하기 위한 요청을 수신하고,
    상기 어드레스를 생성하기 위한 요청을 수신한 것에 응답하여, 상기 제1 문서의 상기 식별된 콘텐트에 대한 제2 어드레스를 생성하도록 어드레스 서비스를 기동시키고 상기 제2 어드레스에서 상기 식별된 콘텐트의 카피의 저장을 시작하고,
    상기 식별된 콘텐트의 콘텐트 중 일부분의 수정을 수신하고,
    상기 식별된 콘텐트의 상기 카피 및 상기 수정을 상기 제2 어드레스에 저장하도록 지시하는
    시스템.
    
11. 제10항에 있어서,
    상기 식별된 콘텐트의 상기 카피는 상기 식별된 콘텐트의 마스터 문서로 간주되고, 상기 애플리케이션은 또한 상기 프로세서가 상기 제2 어드레스에 대한 URL을 수신하도록 지시하되,
    상기 URL은 상기 식별된 콘텐트의 상기 마스터 문서에 액세스하는
    시스템.
    
12. 제10항에 있어서,
    상기 식별된 콘텐트는 위치 식별자를 이용하여 식별되는
    시스템.
    
13. 제12항에 있어서,
    상기 위치 식별자는 단락 식별자, 라인 식별자, 문자 식별자, 범위 및 부분 식별자 중 적어도 하나를 포함하는
    시스템.
    
14. 제10항에 있어서,
    상기 애플리케이션은 또한 상기 프로세서가 상기 제1 문서의 상기 식별된 콘텐트에 대한 수정을 마스터 문서와 병합하도록 요청하기 위해 병합 서비스를 기동시키도록 지시하는
    시스템.
    
15. 제14항에 있어서,
    상기 마스터 문서는 상기 제2 어드레스에 위치한 상기 식별된 콘텐트의 상기 카피인
    시스템.

Images