KR100445922B1 - 다큐먼트 콘텐츠를 선택적으로 제공하는 방법과 시스템, 공동 작업 웹 브라우징 설립 방법 및 기록 매체 - Google Patents

Abstract

액세스 특권의 등급에 따라 사용자에게 디스플레이용 웹 콘텐츠 부분에 대한 액세스를 선택적으로 제공하고, 서로 다른 사용자 지정 장치로 서로 다른 디스플레이용 웹 콘텐츠 부분을 보내는 공동 작업 시스템 및 방법이 개시된다. 본 발명의 웹 브라우징 시스템 및 방법은 멀티미디어 출력을 요구 장치에만 한정시키지 않고, 단말 사용자가 어떤 장치가 웹 콘텐츠를 수신할 것인지 선정할 수 있게 하고, 웹 콘텐츠를 디스플레이하기 위해 공동 작업할 몇몇 장치를 선택할 수도 있게 한다. 프록시 엔티티는 웹 서버와 사용자 위치 사이에 도입된다. 다중 사용자에게 전송될 다큐먼트는 다중 특권 그룹을 정의하는 폴리시 파일을 갖는다. 각각의 특권 그룹은 서로 다른 태그 세트를 액세스한다. 각각의 사용자는 소정의 그룹으로 로그인할 것이고, 서비스 디스커버리를 통해 사용자가 소유한 모든 장치를 프록시에게 식별시킨다. 이런 정보 모두가 주어지면, 프록시가 허용된 태그 대 허용된 출력 장치의 맵핑을 구성할 수 있는데, 즉, 사용자가 액세스하는 것이 허가된 각각의 태그는 사용자가 소유하거나 액세스하는 것이 허용된 하나 이상의 출력 장치에 대해 맵핑된다.

Description

다큐먼트 콘텐츠를 선택적으로 제공하는 방법과 시스템, 공동 작업 웹 브라우징 설립 방법 및 기록 매체{SYSTEM AND METHOD FOR COLLABORATIVE MULTI-DEVICE WEB BROWSING}

본 발명은 전반적으로 콘텐츠의 웹 기반 브라우징에 관한 것으로, 보다 구체적으로는 다수의 사용자 위치중 하나에 선택적으로 제공되는 콘텐츠 부분에 대한 사용자 뷰잉(viewing) 및 대화(interaction)에 관한 것이다.

다수의 원거리 위치로부터 단일 다큐먼트에 대해 행해지는 공동 작업의 필요에 부응하기 위해 그룹웨어 애플리케이션이 개발되었다. 예를 들면, 다수의 사원들이 세계 도처의 그들 각각의 사무실에서 프리젠테이션을 볼 수 있고, 또는 다수의 학생들이 그들 각각의 원격 워크스테이션으로 교수의 강의에 출석할 수 있다. 대부분의 이용 가능한 그룹웨어 애플리케이션은 인터넷 기반형으로, 이것으로 중앙의 기업 또는 대학 기반 서버가 다큐먼트를 로드하고 다큐먼트에 대한 액세스를 관리한다. 인터넷 그룹웨어 모델을 월드와이드 웹으로 확대하는 것이 최근의 연구 및 개발의 주제이다. 월드와이드 웹을 최적 활용하여 다수의 관계자가 공동 작업할 수 있게 하여, 다수의 사용자가 동시에 단일 다큐먼트를 볼 수 있게 하는 것이 바람직하다.

노쓰 캐롤라이너 대학의 연구 과제(D. Stotts, J. Prins, L. Nyland, T. Fan의 "Cobweb:Tailorable, Analyzable Rule for Collaborative Web Use" 참조할 것)는 공동 작업 웹 브라우징 시스템의 한 버전을 다룬다. Sttots 등의 연구 과제의 목표는 다수의 개인(리더와 부하들)이 웹을 공동으로 브라우즈하여 세계 각처에서 별개의 워크스테이션상에서 작업할 수 있게 하는 것이다. 부하들은 리더에 의해 페치된 웹 페이지를 볼 수 있고, 참가자들 모두는 공유 화이트보드(shared whiteboard)를 통해 통신할 수 있다. 리더와 청중 간의 대화는 세션의 초기에 선정된 공동 작업 프로토콜(collabolation protocol)에 의해 결정된다. 프로토콜의 선택에 의해 어떤 애플릿(applet)이 사용자에게 전송될 것인지 결정한다. 프로토콜에는 두 개의 프로토콜(즉, 강의 및 회의)이 있는데, 이들은 참가자에게 제공되는 일련의 기능들이 상이하다. 예를 들면, 웹 강의 프로토콜은 사용자에게 버튼을 디스플레이하여, 사용자가 선도하던지 또는 중단(break)(이것은 사용자가 당분간 강연자의 뷰를 수신하는 것을 원하지 않는다는 것을 의미한다)할 수 있게 한다. 웹 회의 프로토콜은 이것과 동일한 기능을 사용자에게 제공하지 않는다. 예를 들면, 웹 회의 프로토콜은 "발언권 획득(Grab Floor)" 또는 "인원 추가(Add Person)"같은 기능이 있는 버튼을 갖는다. Stotts 등의 시스템이 제공하지 않는 것은 모든 사용자보다 적은 사용자에게 모든 콘텐츠보다 적은 콘텐츠를 제공하는 메커니즘이다.

다른 그룹웨어 모델은 VIEW Media^*(본 명세서 전반에 걸쳐 "*"표시된 용어는 각 소유권자의 트래이드마크를 나타내는 것임) 공동 작업 하이퍼미디어 시스템으로, 이것은 회의 시스템이 공유 다큐먼트에 대한 각 사용자의 액세스 권한에 근거하여 사용자마다 볼 수 있는 공유 다큐먼트의 뷰(views)를 제한할 수 있게 하는 것이다(Y. Tokota. T. Nakamura, H. Tarumi, Y. Kambayashi의 "Multiple Dynamic View Suport for Cooperative Work" Proc. of IEEE Int'l Conf. on Database System for Advanced Applications, 1999, pp. 331-338 참조할 것). VIEW Media는 강연자가 학생들이 강연자의 사적인 주석(annotations)을 보는 것을 금하는 방법을 제공한다. VIEW Media 방법은 하이퍼미디어 다큐먼트를 다수의 성분으로 이루어진 것으로 보며, 이 것에 의해 이들 성분의 상이한 서브세트들이 그룹웨어 세션의 상이한 수령인에게 선택적으로 전송될 수 있다. 따라서, 종래의 그룹웨어에서 발견되는 WYSIWIS(What-you-see-is-What-I-see;모든 사람이 동일한 것을 보는 것) 원리 대신에 다수의 부분 뷰(partial views)가 지원된다. 또한, 4등급의 사용자 액세스 권한이 지원되는데, 즉, 사용자가 하이퍼미디어 객체의 모든 내용을 수신할 수 있는 등급, 객체의 일부분을 수신할 수 있는 등급, 사용자가 객체의 존재 여부는 수신할 수 있지만 그 객체 자체를 수신할 수는 없는 등급, 사용자가 객체는 물론 객체의 존재 여부조차도 수신할 수 없는 등급이 존재한다. 웹 서버상에 위치되는 자원 관리 서버(Resource Manage Server)로 불리우는 중간 프록시(intermediate proxy)는 하이퍼텍스트 다큐먼트(즉 웹 페이지)로부터 다수의 뷰를 생성하여, 그것의 분배를 관리한다.

다른 그룹웨어 시스템인 CAT^*(collaborative active textbooks) 시스템은 다수의 사용자가 동일한 웹 애니메이션 쇼의 서로 다른 부분 뷰를 볼 수 있게 한다(M. Brown, M. Najork, "Collaborative Active Textbooks: a Web-Based Algorithm Animation System for an Electronic Classroom", IEEE Symposium on Visual Languages, 1996, pp.266-275 참조할 것). 강사의 스크린은 동일한 알고리즘의 다수의 애니메이션 뷰를 포함하며, 더불어 애니메이션을 조정하는(예를 들면, 속도 조정) 제어 스크린도 포함하고 있다. 각 학생들도 동일한 웹 페이지를 지시하고 다수의 애니메이션 뷰를 수신하지만, 제어 스크린을 볼 수는 없다. 애니메이션은 시퀀스 내의 관심있는 부분을 식별하는 특수한 언어로 작성된다. 다운로드된 클라이언트측 애플릿은 관심있는 부분을 수신하여 반응한다. 이런 식으로, 강사는 애니메이션의 속도를 제어하지만, 학생은 자신이 보는 뷰를 제어한다. 각 학생은 강사나 다른 학생과 무관하게 자신이 갖고 있는 뷰와 대화할 수 있다. 그러나, 만약 강사가 웹 페이지를 변경하면, 새로운 애니메이션을 수신하기 위해 모든 학생이 새로운 웹 페이지로 수동 변경해야 한다. 그러나 일단 강사가 페이지를 변경하면, 청중인 사용자가 자동으로 새로운 웹 페이지를 수신하도록 하는 것이 바람직하다. Brown 등의 작업의 다른 단점은 다수의 뷰가 사전에 작성자에 의해 구성된다는 것이다. 다수의 뷰의 생성은 기반 웹 페이지를 서브 다큐먼트로 자르는 것에 기초하여 쉴새없이 제공하는 것이 바람직하다.

비디오 회의 애플리케이션의 공유 원격 제어는 T. Hodes, M. Newman, S. McCanne, R. Katz, J. Landay에 의해 "Shared Remote Control of a Video Conferencing Application : Motivation, Design, and Implementation", SPIE Multimedia Computing and Networking(MMCN), Proc. SPIE, vol.3654, 1998(conf. held Jan 199), pp. 17-28에 제안되었다. 비디오 회의 애플리케이션 "rvic(remote video conferencing)"을 조작하기 위한 원격 제어로서 PDA가 이용된다. 이들 저자는 또한 서비스 디스커버리 메커니즘도 설명한다. Hodes 등의 애플리케이션 원격 제어는 회의 애플리케이션을 편성하는 것을 다루지만 웹을 다루는 것은 아니다.

http://grapics.stanford.edu/projects/iwork/에서 찾을 수 있는 논문에서 Armando Fox 교수가 설명하는 스탠포드의 대화형 워크스테이션 연구 과제는 "다중 브라우징(multi-browsing)"의 개념을 도입한다. 이 과제의 목표는 다중 장치, 다중 사용자 환경으로 실험하는 것으로, 특히 어떤 컴퓨터 장치에서 다른 데로 모든 종류의 작업을 이동시키는 것과, 그룹 대화를 지원 및 용이하게 하는 것이었다. 이러한 시스템하에서 사용자는 직렬화된 양식으로 다중 장치와 대화할 것이다. 예를 들면, 사용자가 방을 이동하면, 그의 애플리케이션을 보기 위해 혹은 태스크를 완료하기 위해 그와 대화중이던 장치도 변경되어야 할 것이다. 또한, 각기 동일한 다큐먼트를 디스플레이하고 있는 몇몇 장치를 병렬로 이용하는 개념도 있다. 주로, 이 과제는 각각의 디스플레이상에 상이한 화면이 보여질 수 있는 월 디스플레이(wall displays)에 촛점이 맞춰져 있다. 예를 들어 슬라이드 프리젠테이션의 경우, 프리젠테이션의 서로 다른 페이지들은 상이한 스크린상에 나타날 것이며, 사용자가 이동하면, 프리젠테이션도 사용자를 따라갈 것이다. 이 과제는 더 많이 방의 인프라스트럭처와 대화하는 방법을 조사하며, 위치 정보를 수집하는 센서와 관계가 있다.

하나 이상의 PDA와 디지털 화이트보드 간의 대화는 J. Rekimoto에 의해 "A Multiple Device Approach for Supporting Whiteboard-based Interactions", Human Factors in Computing System(CHI) 1998, pp. 344-351에 상세히 설명된 것처럼 구현된다. 그의 첫 번째 예로서, 저자는 사용자가 하나의 컴퓨터 스크린상에서 객체를 "픽(pick)"하여 다른 컴퓨터 스크린상에 "드롭(drop)"할 수 있는 시스템을 설명한다. 두 번째 예로서, 저자는 사용자가 PDA 상에서 그림을 그려서 이 새로 그려진 객체를 동일한 펜을 이용해 PDA로부터 디지털 화이트보드로 "픽-앤-드롭(pick-and-drop)"할 수 있게 하는 시스템을 설명한다. 또한 PDA는 브러시 유형과 펜의 컬러를 설정하는데 이용되며, 스크린상에서 객체의 외관 속성을 변경시킬 수 있다. 이런 식으로, PDA는 화이트보드 애플리케이션을 조작하기 위한 원격 제어로서 이용된다.

MIT 미디어 랩의 "Let's Browse"^*시스템은 다른 형태의 공동 작업 웹 브라우징을 구현하는데, 이것은 H. Lieberman, N. Van Dyke, A. Vivacqua에 의해 "Let's Browse : a collaborative browsing agent", Knowl. Based Syst. (UK), Vol.12, No.8, Dec. 1999, pp.427-431에 상세히 설명되어 있다. "Let's Browse" 시스템에서, 각각의 사용자는 선호하는 웹 페이지의 프로파일을 갖는다. 사용자가 웹 브라우징 컴퓨터의 근처에 있을 때, 컴퓨터상의 에이전트는 사용자의 프로파일과 일치하는 웹 페이지를 프리페치(prefetch)할 것이다. 브라우징 세션을 다수의 사용자가 함께 열람할 때, 에이전트는 사용자가 공동으로 관심을 갖는 페이지를 발견할 것이다. 또한 저자는 하나 이상의 사용자로부터의 활성 입력과 그로 인한 각 사용자 프로파일의 갱신을 예기한다.

또다른 공동 작업 시스템이 RealNetworks^*에 의해 제공된다. 리얼 프리젠터(real Presenter)라고 불리우는 이 제품은 다수의 수령인이 웹 프리젠테이션(realnetworks.com의 products/presenterplus/info.html의 기사를 참조할 것)을 열람하는 것을 허용하며, 프리젠터가 프리젠테이션으로부터 각각의 슬라이더를 나래이션과 함께 작성하는 것을 허용한다. 다음, 프리젠터는 프리젠테이션을 RealMedia^*다큐먼트로 변환하여, 이것을 웹 서버에 업로드할 수 있으며, 웹 서버에서는 모든 사람이 자신의 로컬 컴퓨터로 이 다큐먼트를 액세스할 수 있다.

또한, 웹 사이트web.calstatela.edu의 ats/real/develop/broadcast.htm에서 열람할 수 있는 RealPresenter^*의 생방송 버전도 있다. 생방송 버전의 경우, 사용자가 프리젠테이션 링크상에서 클릭하면, 사용자는 프리젠터가 RealPresenter 소프트웨어를 이용해 그의 책상에서 제공하는 생방송 프리젠테이션을 수신할 수 있다. 오디오 및 슬라이드 데이터는 RealServer^*에게 전송되고, 이후에 RealServer^*는 이 데이터를 그 링크상에서 클릭하는 모든 사람에게 보낸다. 이 제품에 추가적으로 바라는 것은 출력을 각 소유권자의 다중 장치 사이에서 분할하고 약간의 특권 그룹(privilege groups)의 개념으로 액세스를 조정할 수 있었으면 하는 것이다

마이크로소프트사의 NetMeeting^*(이것은 웹 사이트microsoft.com의 catalog/display.asp?site=113subid=22pg=1 페이지에서 열람할 수 있음)은 참가자가 실시간으로 윈도우즈 다큐먼트를 공동 작업 및 공유할 수 있게 해준다. 모든 사용자는 표준 데이터 회의 프로토콜 T120을 이용해 그들의 스크린상에서 동일한 정보를 본다.

Netscape Conference^*(이것은 웹 사이트aibn.com의 /help/Software/Netscape/Communicatior/Conference/browsing.html 페이지에서 열람할 수 있음)는 두 명의 사람이 인터넷을 통해 동일한 웹 페이지를 동시에 보도록 하는 공동 작업 브라우징 특징을 제공하는데, 그들 각각은 언제든지 브라우저를 제어할 수 있다. 이것은 표준 비디오 회의 프로토콜(H.323)을 이용한다. 또한, Netscape Conference^*는 정보 교환에 이용되는 화이트보드를 제공한다.

WebEx.com^*에서 발견되는 또다른 서비스는 다수의 이용자가 공통 프리젠테이션 온라인을 따라갈 수 있도록 한다(웹 사이트webex.com을 참조할 것). 브라우징 사용자의 스크린은 캡처(capture)되어, 웨백스 닷 컴(WebEx.com)사의 서버로 전송된 뒤, 이후 회의 세션에 다른 사용자에게 중계된다. 이 시스템은 발언권을 가지는 사람을 제어하는 메커니즘을 지원하며, 웹 페이지용으로 이용될 수 있을뿐만 아니라 어떠한 애플리케이션으로부터의 다큐먼트용으로도 이용될 수 있다.

또다른 시스템 즉, Yahoo!^*Games은 다수의 이용자가 동일한 게임을 열람하는 것을 허용하며, 웹 기반의 접속 메커니즘(Web-based join mechanism)을 갖는다. 대화형 온라인 게임은 종종 부분 뷰를 허용한다. 예를 들면, x-trek^*같은 게임은 다른 플레이어가 볼 수 없는 즉석 메시지(instant messages)를 친구와 교환할 수 있다. 그러나, 이러한 선택적인 콘텐츠 디스플레이는 웹 기반형이 아니어서, HTTP가 아닌 사설 프로토콜에 기반하고 있다. 또한, 이렇게 온라인으로 하는 것은 출력을 다수의 출력 장치에 대해 분할하지 않는다.

콘텐츠의 상이한 부분들이 상이한 사용자에 대해 이용 가능하게 되는 웹 기반 공동 작업 시스템 및 방법이 추가적으로 요구된다. 전술한 인용 문헌의 메커니즘은 그런 능력을 갖지 않는다. 더 나아가, 출력을 다수의 소 클라이언트 장치에 대해 분리하는 것도 요구될 수 있을 것이다. 예를 들면, 사용자의 요구하는 장치가 셀 폰이면, 소형 셀 폰 디스플레이와 그에 한정된 오디오 성능을 이용해서, 요구된 콘텐츠에 액세스하는 것이 실용적이지 않을 수도 있다. 오히려, 사용자는 비주얼 콘텐츠(visual content)가 관련 TV 스크린이나 컴퓨터 모니터상에 디스플레이되고 오디오는 최대 범위 스테레오 시스템으로 전달되기를 바랄 수도 있다.

비디오 회의용 공통 규격은 T.120 뿐만 아니라 패킷-전환형/IP 네트워크를 통한 오디오/비디오 회의용 H.323를 포함한다. 트랜스코딩을 허용하기 위해 웹 콘텐츠에 주석을 달기 위한 W3C에 대한 제안, "Annotation of Web Conent for Transcoding"[W3C]도 존재한다. 이 해결법에서, 콘텐츠에는 메타데이터(metadata)로 주석이 달려지는데, 이 메타데이터는 다운스트림 엔티티나 서버에게 각 성분의 중요도와 단말 장치에 디스플레이하기 위해 성분을 트랜스코드하는 방법을 설명한다. 그러므로, 이것은 웹 콘텐츠를 수신 장치의 성능에 적응시키려고 시도한다. W3C 제안은, 웹 콘텐츠가 XML로 작성되며 트랜스코딩 규칙을 정의하기 위해 RDF(resource description framework) 파일을 이용한다는 것을 전제로 하고 있다. 이 파일에서, 단말 장치의 성능이 주어지면, 무엇을 전송할 것인가 하는 규칙은 요구하는 콘텐츠(영상 또는 비디오 파일)마다 정의된다. 이러한 적응의 결과로 단 하나의 웹 페이지가 존재하게 되며, 이것은 단말 장치로 보내진다.

개인용 장치에서 나타나는 경향은, 사용자가 운반 가능하고 때와 장소를 가리지 않고 이용할 수 있는, 보다 소형의 그리고 보다 더 휴대에 적합한 장치쪽으로 흘러가고 있다. PDA 같은 이동 장치는 종종 오로지 적은 일련의 기능들만을 지원하는 기술에 의해 제한을 받는데, 예를 들면, PDA는 오디오없이 소형 스크린을 갖기 때문에 텍스트를 전용으로 지원하는 제한을 갖는다. 또한, 하드웨어적인 제한에 덧붙여서, 이러한 이동 장치는 독립된 비접속 모드에서 동작할 때 제한된 성능을 갖는다. PDA가 예컨대 캘린더링 및 어드레스 북(calendering and address book)처럼 매우 유용한 애플리케이션을 지원하더라도, PDA가 제공할 수 있는 기능은 비접속시 장치의 성능에 의해 원래부터 제한을 받는다. 네트워크된 상호 통신 성능을 휴대용 장치에 통합함으로써, 이동 장치의 사용자는 네트워크에 의해 제공될 수 있는 보다 풍부한 일련의 애플리케이션에 액세스할 수 있게 되는데, 예를 들면, 사용자는 그들 자신의 데스크탑 애플리케이션, e-메일 및 웹에 액세스할 수도 있고, 네트워크된 PDA나 향상된 셀 폰을 통해 다른 사용자와 접속할 수도 있다.

전술한 관점에서, 본 발명의 목적은 이동형과 고정형을 포함하는 다수의 네트워크된 장치가 서로 공동 작업할 수 있도록 하여 이동 네트워크 장치의 성능을 향상시키는 시스템 및 방법을 제공하는 것이다.

본 발명의 다른 목적은, 단일 애플리케이션의 출력이 공동 작업 환경에서 장치 각각에 대해 선택적으로 분배될 수 있는, 다수의 고정형 및 이동형 장치의 집단(aggregation)으로 정의된 가상 머신(virtual machine)을 제공하는 것이다.

상기 및 다른 목적은, 액세스 특권의 등급에 따라 사용자에게 디스플레이하도록 웹 콘텐츠의 부분들에 대한 액세스를 선택적으로 제공하고, 그리고 상이한 사용자 지정 장치에 디스플레이하도록 웹 콘텐츠의 상이한 부분들을 감독하는 공동 작업 시스템 및 방법을 제공하는 본 발명에 의해 실현된다. 웹 브라우징과 관련한 본 발명의 시스템 및 방법은 요구 장치에 대해 멀티미디어 출력을 제한하지 않으므로, 단말 사용자는 어떤 장치가 웹 콘텐츠를 수신해야하는지 선정할 수 있고, 웹 콘텐츠를 디스플레이하기 위해 공동 작업할 장치를 몇 개라도 선택할 수 있다. 예를 들면, 콘텐츠의 사운드 부분은 고 품질 스피커로 전송될 수 있는 반면, 비디오 부분은 텔레비전 스크린으로 전송될 수 있어서, 사용자가 웹 페이지의 각 성분을 실행 혹은 디스플레이하기 위해 입수할 수 있는 가장 좋은 장치(품질면이나 편리성면에서 가장 좋은 장치)를 선택할 수 있게 된다. 따라서, 공동 작업의 다중 장치 웹 브라우징은, 콘텐츠 혹은 콘텐츠 부분을 제공하기에 더 적합한 더 크거나 상이한 출력 기능을 갖는 근처의 다른 출력 장치를 취함으로써, 단말 사용자로 하여금 요구 장치의 제한된 성능(예를 들면, 셀 폰의 소형 디스플레이)을 극복할 수 있게 한다. 그러므로, 각각의 장치의 기능은, 몇몇 장치의 공동 작업으로부터 초래되는 가상 머신을 생성함으로써 확대된다.

웹 페이지 상의 콘텐츠는 또한 전체나 혹은 그 일부분이 하나 이상의 단말 사용자에게 전송된다. 본 발명의 공동 작업 다중 장치 웹 브라우징으로, 웹 페이지상의 콘텐츠는 전체 그룹의 사람들에게(이들중 하나만이 그것을 요구함) 자동적으로 전달될 수 있다. 그룹의 멤버들은 자신의 특권의 등급에 따라 전체 페이지 혹은 페이지의 일부분을 수신할 수 있다. 예를 들면, 수업을 하는 선생님의 경우,선생님은 네비게이션 바(navigation bar)로 그의 슬라이드를 통해 네비게이트할 수 있어야 하지만, 학생들은 강의동안에 네비게이션을 변경할 수 없어야 한다. 이 경우, 학생들은 선생님과 동일한 특권 등급 그룹에 속하지 않으므로, 시스템은 학생들에게 네비게이션 바를 감출 것이다. 그러므로, 몇몇 사용자는 다큐먼트의 부분 뷰만을 수신하므로, 시스템과 방법은 웹 세션의 참가자 간에 제어형 대화를 도입한다.

공동 작업 다중 장치 웹 브라우징에 있어서, 어떤 장치 혹은 어떤 사용자가 웹 콘텐츠의 어떤 부분을 수신할 것인지에 대한 판정은, 각각의 XML 다큐먼트에 대해 그 다큐먼트의 생성시 웹 작성자에 의해 작성된 폴리시 파일(policy file)을 이용하여, 세션의 초기에 동적으로 행해진다. 폴리시 파일은 XML 웹 페이지상에 메타데이터를 포함하여, 다수의 특권 그룹을 정의하는 규칙을 포함하고 있다. 각각의 특권 그룹은 서로 다른 태그 세트(set of tags)에 액세스한다. 각각의 사용자는 소정의 그룹으로 로그인(login)할 것이고, 또한 서비스 디스커버리(service discovery)를 통해 프록시에 대해 사용자가 소유한 모든 장치를 식별할 것이다. 이러한 정보가 모두 주어지면, 프록시는 허용된 출력 장치 대 허용된 태그들의 전체적인 맵핑(mapping)을 구성할 수 있는데, 즉, 사용자가 액세스하는 것이 허용된 각각의 태그는 사용자가 소유하거나 혹은 액세스하는 것이 허용된 하나 이상의 출력 장치에 대해 맵핑된다.

상이한 장치 및 단말 사용자에게 전송되는 서브 다큐먼트(sub-documents)를 생성하기 위해, 웹 콘텐츠는 바람직하게는 XML을 이용해 트랜스코드된다. 적절한태그를 선택하고 전형적으로 HTML, XML. WML 등인 적절한 출력 포맷으로 다큐먼트를 발생하기 위해(혹은, 스피커로 전송될 엔코드된 오디오의 스트림같은 비 텍스트 포맷도 됨), 변형(transformations)이 적용된다. 서비스 디스커버리는 각각의 장치에 의해 요구되는 코덱 포맷(codec format)에 대해 알기 위해 수행된다.

다중 장치 웹 브라우징의 전체 프로세스는 사용자로부터 투명하게 이루어지지만, 볼 수 있도록 허용된 각각의 태그가 어디에 디스플레이될 것인지에 관해서는 단말 사용자에게 약간의 제어가 제공된다. 다중 장치 웹 브라우징 프록시는 장치들 각각과 관련하여 사용자가 행한 장치의 선정 및 태그의 리스트와 함께 사용자에게 애플릿을 전송할 것이다. 그러면, 단말 사용자는 사용자 위치에서 최적의 디스플레이를 위해 태그와 장치의 더욱 편리한 결합(association)을 선택함으로써 그룹 세션을 개인화(personalize)할 수 있다.

도 1은 전형적인 웹 브라우징 시스템의 개략적인 예시도,

도 2는 본 발명에 따른 웹 브라우징 시스템의 개략적인 예시도,

도 3은 근처의 고성능 출력 장치를 활용함으로써 단일 사용자의 웹 브라우징 세션이 향상되는, 공동 작업 다중 장치 웹 브라우징의 제 1 시나리오를 예시한 도면,

도 4는 다른 장치뿐만 아니라 다른 사용자도 브라우징 세션의 출력중에서 선택된 부분을 수신하는 공동 작업 다중 장치 웹 브라우징의 제 2 시나리오를 예시한 도면,

도 5는 본 발명에 따른 데이터 변환의 효율을 예시하는 도면,

도 6은 새로운 공동 작업 세션의 설립시 관계되는 엔티티를 예시하는 도면,

도 7은 본 발명과 관련한 대화의 전체 시퀀스를 도시하는 도면,

도 8a 및 도 8b는 새로운 공동 작업 세션의 설립을 위한 프로세스 흐름을 상세히 설명한 도면,

도 9는 프록시가, 웹 페이지와 관련한 URL 요구가 새로운 브라우징 세션의 설립을 초래해야 할 때를 결정하는 대표적인 알고리즘,

도 10은 프록시로부터 세션 개시자의 브라우저로 전송되는 대표적인 로그인/등록 스크린을 예시하는 도면,

도 11은 신규 사용자 및/또는 장치가 설립된 세션에 접속(joining)하는 대표적인 프로세스 흐름도.

도면의 주요 부분에 대한 부호의 설명

10 : 사용자 위치 12 : 웹 서버

14 : 인터넷 16 : 사용자 위치 브라우저

17 : 시각적 디스플레이 성분 18 : 오디오 디스플레이 성분

20, 610 : 프록시 30 : 사용자 요구 장치

400 : 웹 프리젠테이션 410 : 강사 위치

415 : 주석 416 : 네비게이션 바

417 : 디스플레이 부분 612 : 서비스 디스커버리

이제부터 본 발명은 특별히 첨부 도면을 참조하여 더욱 상세하게 설명될 것이다.

이후의 설명을 위해, 본 발명의 시스템과 방법은, 웹 클라이언트가 사용자 머신상에서 국소적으로 작동하고 웹 서버는 인터넷으로 원거리에서 작동하는 전형적인 웹 브라우징 애플리케이션에 적용되는 것으로 가정한다. 사용자가 웹 브라우저를 통해 웹 페이지를 요구할 때, 이 요구는 다큐먼트를 웹 브라우저로 곧장 리턴(returns)시키는 적절한 웹 서버로 전송된다. 웹 브라우저는 리턴된 콘텐츠에포함된 HTML을 분해(parse)하여 제공(render)할 정도의 지능을 갖는다. "웹 페이지"와 "웹 다큐먼트"라는 용어가 호환성있게 이용될 수도 있는데, 웹 페이지 혹은 웹 다큐먼트의 콘텐츠는 "부분(portions)" 혹은"서브 다큐먼트(sub-document)"로 선택적으로 분할되고, 이러한 부분이나 서브 다큐먼트에 대한 액세스도 선택적으로 제어될 것이다. 본 발명의 바람직한 실시예는 웹 다큐먼트가 XML을 이용해 생성되는 것을 필요로 하며, 이후의 설명은 언어(langusge)처럼 XML의 이용을 가정한다. HTML로 제공되는 다큐먼트에도 본 발명이 적용될 수 있으나, 본 발명의 목적들 중 몇몇은 HTML과 동작할 때 실현되지 않을 수 있음을 유의해야 한다.

도 1은 전형적인 웹 브라우징 구현의 개략적인 예시도이다. 도 1을 참조하면, 사용자 위치(10)에 있는 사용자(도시 안됨)는 인터넷(14)을 통해 웹 서버(12)로부터 콘텐츠를 입수할 것이다. 일단 콘텐츠가 사용자 위치 브라우저(16)에 수신되면, 이 콘텐츠는 디스플레이 성분(17)에서 시각적 디스플레이의 형태로 사용자에게 전송되고/되거나 오디오는 오디오 디스플레이 성분(18)에 제공된다. 공동 작업 환경에서, 이 모델은 하나의 사용자 위치에서 다수의 디스플레이 성분을 포함하는 것뿐만 아니라 다수의 사용자 위치도 포함하도록 확대된다.

본 발명의 공동 작업 다중 장치 웹 브라우징의 이면에 있는 개념은, 먼저 웹 다큐먼트를 독립적인 부분들로 분할한 뒤, 다음에 이들 부분들을 디스플레이를 위해 선택적으로 전송하는 것이다. 공동 작업의 테마는 몇몇 등급으로 적용된다. 첫째, 하나의 사용자만이 웹을 브라우징할 때, 공동 작업의 개념은 다수의 클라이언트 장치에 적용되고, 이 다수의 클라이언트 장치는 공동 작업을 하여 가상 머신을 형성하고 있다. 각 웹 다큐먼트의 부분들은, 웹 브라우징 세션을 개시한 요구 장치의 근처에 모두 위치되어 있는 이 가상 머신의 다수의 클라이언트 성분들 간에 분리된다. 이러한 유형의 공동 작업 다중 장치 웹 브라우징은 단일 사용자의 웹 브라우징 경험을 보강해준다. 두 번째로, 다수의 인적 사용자가 존재할 때, 공동 작업의 개념은 사용자 위치 전역에 적용된다. 따라서, 웹 다큐먼트의 부분들이 다수의 국소 장치(local devices)에 제공될 수 있을뿐만 아니라, 동시에 이 웹 다큐먼트의 부분들은 각 사용자의 기호와 허가(permissions)에 따라 지리적으로 서로 멀리 떨어져 여기저기 분산되어 있는 다수의 사용자에게도 제공될 수 있다.

공동 작업 다중 웹 브라우징에 선행하는 하나의 관문은 사용자와 장치 모두가 그들 서비스에 등록함과 함께 타인에 의해 등록된 서비스를 발견하는 어떤 수단을 가져야 한다는 것이다. 사용자와 장치의 등록 및 디스커버리 메커니즘은 예컨대 SLP(Service Location Protocol), Sun Microsystems^*의 Jini^*, Bluetooth's^*SDP(Service Discovery Protocol), Microsoft^*'s UPP^*(Universal Plug and Play) 등의 서비스 디스커버리 프로토콜 및 미들웨어 레지스트리(middleware registry)를 필요로 한다. 다중 사용자는 웹 브라우징 세션에 등록한 뒤, 세션 프리젠터에 의해 제어되는 세션을 따를 것이다.

성능과 관련하여 장치 입력을 수신하고 웹 콘텐츠를 수신 및 분해하기 위해, 도 2에 도면 부호(20)로 도시된 프록시 엔티티가 제공되는데, 이것은 웹 서버(12)와 사용자 위치(10) 사이에 위치된다. 프록시는 웹 서버로부터 웹 다큐먼트의 형태로 입력을 수신하고, 사용자 위치로부터는 사용자 위치 장치 성능 정보의 형태로 입력을 수신하도록 되어 있다. 이후에 상세히 설명하는 것처럼, 프록시는 이 입력 정보를 활용하여 사용자 액세스 특권 정보와 장치 성능 정보에 따라서 웹 다큐먼트의 부분들에 대한 액세스를 선택적으로 제어한다.

도 3은 근처의 고성능 출력 장치를 활용함으로써 단일 사용자 웹 브라우징 세션을 보강한, 공동 작업 다중 장치 웹 브라우징의 제 1 시나리오를 예시한다. 이 개념은, 원래의 장치가 효과적으로 지원하지 못하는 웹 콘텐츠의 부분들을 실행 또는 디스플레이하기 위해 근처의 다른 출력 장치를 수단으로 도입함으로써, 웹 브라우징을 하는데 이용되는 원래의 장치의 성능을 확대하는 것이다. 예를 들면, 가정 환경에서, 사용자는 예컨대 소형 스크린과 저 해상도를 가지며 사운드 지원은 되지 않는 PDA 같은 사용자 요구 장치(30)로 웹을 브라우징하기 시작할 수 있다. 만약 근처에 예컨대 단거리 무선 접속을 제공하는 Bluetooth^*칩이 장치된 고품질 스피커, 라디오(32), TV(34)가 있다면, 사용자는 웹 콘텐츠의 사운드 부분을 스피커로 보내고 그래픽 콘텐츠는 TV 스크린으로 보내는 것을 결정할 수 있다. 사용자는 웹을 네비게이트하는데 원래의 PDA를 원격 제어로서 계속 이용할 수 있다. 주변에 I/O 주변 장치가 있는 제한적인 이동 장치의 성능을 확대시키는 능력은 사용자의 브라우징 경험을 보강시킨다. 사용자는 또한 어떤 출력 장치에서 어떤 출력 데이터/스트림이 실행/디스플레이될 것인지를 제어할 수 있으므로, 비디오 영상이 TV(34)에 전송되는 동안, 영상이 PC(36)의 모니터상에서 디스플레이되거나 또는 프린터(38)에서 하드 카피로 출력되도록 계속해서 전송될 수 있다.

도 4는 다른 장치뿐만 아니라 다른 사용자도 브라우징 세션의 출력을 수신할 수 있게 함으로써 웹 브라우징 경험을 보강해주는, 공동 작업 다중 장치 웹 브라우징의 제 2 시나리오를 예시한다. 도 4의 제 2 시나리오에서, 강사는 웹 서버에 기억되는 웹 프리젠테이션(400)을 작성하고, 아마도 전화 회의, 회의실 또는 강의실 등에서 이 프리젠테이션을 다른 사용자에게 보여주고자 한다. 강사는 강사 위치(410)에 도착할 것이고, 이곳은 이미 스피커(413)와, 랩탑 컴퓨터(411) 및 WinCE^*장치(412)가 설치되어 있다. WinCE^*장치는 강사가 프리젠테이션 동안 실내를 이리저리 이동할 수 있게 해준다. 이 경우에서, 개략적으로 도시된 프리젠테이션(400)은 시각적 디스플레이 부분(417), 오디오 디스플레이 부분(414), 네비게이션 바(416), 강사의 주석(415)을 포함한다. 진행/역행 버튼이 있는 네비게이션 바(416)는 WinCE^*장치와 강사의 랩탑 컴퓨터에만 전송되어야 한다. 동시에, 강사는 그래픽 슬라이드(417)가 강사의 랩탑 컴퓨터에 전송되어 강의실의 큰 스크린(도시 안됨)상에 투영되는 것을 원할 수도 있다. 또한, 강사는 프리젠테이션의 오디오 부분(414)이 방안에서 이용할 수 있는 사운드 시스템(413)으로 전송되는 것을 원할 수도 있다. 따라서 이후에 설명되는 것은 제 1 시나리오의 가상 머신 개념과 동일하여, 각 액세스된 웹 페이지의 콘텐츠가 단일 사용자의 컴퓨터, PDA, 스테레오 시스템에 분할된다. 프리젠테이션(400)의 개략도에서, 주석(415)(웹 페이지의 좌측 부분), 네비게이션 바(416)(최상부 그림), 슬라이드(중앙 부분)(417)는 모두 강사의 랩탑으로 전송된다. 또한, 강사가 프리젠테이션을 제공하는 동안에 이리 저리 걸어다니면서 원격 제어를 하고자 하는 경우에는, 네비게이션 바가 강사의 PDA(도시 안됨)로도 전송될 수 있다. 오디오는 강사의 방에서 이용할 수 있는 스테레오 스피커로 보내진다.

예시된 것처럼, 가상 머신 시나리오의 확대로서, 방안의(혹은 원거리에 있는) 다른 사람도 장치를 구비하여 자신의 장치로 프리젠테이션의 일부를 수신하고자 함을 가정하였다. 예를 들면, 방안의 몇몇 학생은 PDA(418)를 구비하고 다른 사람들은 랩탑(419)을 구비할 수 있을 것이다. 슬라이드 부분(417)이 청중에게 전송될 수 있다(저 해상도로 트랜스코드된 버전이 PDA에 전송됨). 원거리에 위치하는 학생은 예시되지 않았지만, 프리젠테이션의 오디오 및 슬라이드 부분이 해당 학생 사용자에 의한 액세스를 위해 제공될 것임을 가정한다. 사용자들은 서로 다른 액세스 특권을 가져서, 사용자중 어떤 그룹은 웹 페이지에서 어떤 멀티미디어 객체를 수신할 수 있도록 허용할 것인지를 제어한다. 예를 들면, 강사는 방안의 다른 사람들보다 더 높은 등급의 특권을 갖는다. 강사는 주석과 네비게이션 바를 수신하도록 허용된다. 반대로, 청중 구성원이 네비게이션 바를 작동하여 프리젠테이션을 중단시켜서는 안되므로, 청중 구성원은 웹 다큐먼트의 네비게이션 바 부분을 수신할 수 없게 된다. 그러므로, 이러한 시나리오 하에서, 소정의 객체(예를 들면, 네비게이션 바)는 다중 목적지를 가질 수 있으며, 다중 객체는 동일한 목적지(예를 들면, 강사의 컴퓨터)를 가질 수 있으며, 그리고 사용자는 다중 출력 장치(예를 들면, 컴퓨터, PDA, 스테레오 스피커)를 소유/제어할 수 있다. 전술한 강사/학생 시나리오는 어떠한 회의 시나리오에도 똑같이 잘 적용된다. 예를 들면, 전형적인 전화 회의는, 화자는 말하면서 다른 슬라이드로 바꾸고 다른 청중들은 비록 자신이 수신할 수 있도록 특권을 부여받은 부분에 대한 것이기는 하지만 온라인 그래픽 프리젠테이션을 쫓아가도록 되어 있는 동시 웹 세션에 참가자들이 접속함으로써 향상될 수 있을 것이다.

전술한 것을 가능하게 하기 위해서, 세션 프리젠터는 먼저 슬라이드 프리젠테이션를 구성하고("웹 제작(web authoring)"이라고 불리우는 단계), 슬라이드의 시퀀스를 XML 웹 페이지로서 웹 서버에 기억시켜야 한다. 제작의 일부로서, 구성자(composer)는 XML "폴리시" 파일을 선택적으로 생성할 수도 있다. 폴리시 파일은 어떤 XML 태그가 어떤 특권 그룹으로 전송되도록 허용되었는지를 구술하는 맵핑 규칙(mapping rules)을 포함한다. 나중에, 세션 프리젠터가 공동 작업 프리젠테이션의 일부로서 웹 슬라이더에 액세스하기를 원할 때, 프리젠터는 프리젠테이션의 첫 번째 페이지를 다운로드할 것이다. 프리젠테이션의 첫 번째 페이지는 프록시에 의해 해석된다. 만약 첫 번째 페이지가 폴리시 파일을 참조하고 있으면. 프록시는 폴리시 파일을 요구하여, 잘 형성된 태그 맵핑 규칙을 구성한다. 폴리시 파일이 없는 경우에는, 프록시가 강제로 디폴트로 서브 최적 맵핑 규칙 세트를 발생한다. 이 때, 프록시는 다른 사용자가 세션 프리젠터의 브라우징 세션을 따라갈 수 있도록 공동 작업 다중 장치 웹 브라우징 세션에 대한 상태(state)를 생성한다. 프록시는 이 새로운 세션을 서비스 디스커버리 메커니즘에 등록하여 새로운 가입자가 세션을 발견할 수 있게 한다.

새로운 잠재적 가입자가 설립된 세션에 접속하기를 원할 때, 이 가입자는 먼제 서비스 디스커버리 메커니즘에 질의하고, 이 메커니즘은 이용 가능한 서비스의 리스트를 리턴한다. 가입자가 원하는 공동 작업 다중 장치 브라우징 세션을 선택하면, 선택된 프록시로부터 사용자명과 패스워드를 묻는 로그인 양식이 가입자에게 리턴된다. 제공된 패스워드가 폴리시 파일에 정의된 패스워드와 일치하면, 프록시는 각각의 새로운 가입자를 특권 그룹과 연관시킨다. 또한, 프록시는 입력된 사용자명과 연관된 모든 장치를 서비스 디스커버리에게 요구한다. 이 때, 프록시는 각 가입자의 장치로 전송되어야 하는 XML 태그만을 선택하는 맵핑 규칙을 구성할 수 있다. 프록시는 여러 부분 또는 서브 다큐먼트를 생성하는 적절한 XSL 다큐먼트를 구성하고, 이 부분 또는 서브 다큐먼트는 이후에 가입자 및 가입자의 다중 장치로 푸시(pushed)된다. 각 가입자 및 각 장치는 웹 프리젠테이션의 부분 뷰를 수신한다. 데이터 푸시 메커니즘(data push mechanism)은 가입자의 브라우저에서 데이터 전달이 어떻게 지원되느냐에 따라 변할 것이다. 만약 종점(endpoint)이 브라우저가 아니라 장치라면, 데이터 푸시는 물리적인 장치를 액세스하는데 필요한 방법에 따라 변할 것이다. 마지막으로, 가입자가 프록시의 출력 장치에 대한 멀티미디어 태그/객체의 처음 맵핑을 변경하고자 원할 수도 있으므로, 프록시는 사용자가 언제든지 맵핑을 커스텀화(customize)하도록 신청할 수 있는 개인화 구성 애플릿(personalized configuration applet)을 만들 수 있게 된다. 프록시는 이러한 커스텀화된 맵핑을 이용하여 태그/멀티미디어 분배의 최종 폴리시를 설립한다.

프록시

프록시의 기본 성분은, 사용자 요구를 수신하고 이 요구를 웹 서버로 전송하며 서비스 디스커버리 동안에 사용자 위치와 통신하는(이것은 이후에 상세히 설명되듯이 국소적이거나 분산된 기능일 수도 있다) 적어도 하나의 통신 성분과, 웹 서버로부터 페치된 다큐먼트를 분해하는 적어도 하나의 처리기 성분과, 폴리시 파일을 해석하는 적어도 하나의 처리기 성분과, 다큐먼트 부분을 사용자 위치에 대해 동적으로 맵핑하는 처리기 성분 및, 프리페치된 파일을 캐싱(caching)하는 적어도 하나의 캐시 위치(cache location)를 포함한다. 만약 다큐먼트가 XML로 제공되면, XML 파일을 이용해 이러한 분해(parse)를 수행하는 것이 최적이므로, XMK 분해기(parser)와 XSL 엔진(engine)이 필요하다. 변환을 수행할 수 있는 많은 XSL 처리기가 존재하는데, 상세한 것은 공지되어 있으므로 본 명세서에서 반복하지 않을 것이다. 프록시는 사용자 위치에서 그 능력에 대해 전송된 콘텐츠를 "커스텀화(customize)"하기 위해 웹 다큐먼트 전부 혹은 부분들을 트랜스코딩하는 성분을 추가로 포함한다.

프록시는 시스템의 어느 곳이든(웹 서버내 혹은 사용자 위치까지도 포함함) 위치될 수 있지만. 종단 사용자와 웹 서버 사이에 위치되는 프록시에 지능을 부여하는 것이 최적이다. 프록시는 예컨대 Apache^*프록시처럼 다중 장치 다중 사용자 선택성 처리를 수행하도록 커스텀화된 입수 가능한 프록시일 수 있다. 선택적으로, 프록시는 서블릿(servlet)을 갖는 웹 서버로 구현될 수 있다. 실제로, 다중장치 프록시는 전송될 다큐먼트를 생성하여 목적지로 분배하기 때문에 종단 클라이언트에게 웹 서버처럼 보여진다. 그러므로, 서블릿은 인터넷 웹 서버에 대한 요구를 전송하고 그 응답을 수신하며 분해를 수행하는 것을 다룰 수 있다. 웹 서버 부분은 서블릿에 의해 캐시된 다큐먼트를 검색하여 종단 장치로 분배한다.

프록시의 분해 및 액세스 제어 기능에 더하여, 중간 프록시를 이용하면 몇몇 다른 이점도 존재한다. 프록시는 인터넷에 대해 종단 장치를 은닉하므로, IP 어드레스를 반드시 가질 필요는 없는 스피커처럼 국소적으로 장치를 액세스할 수 있다. 또한, 프록시는 인터넷과 종단 장치 사이에서 버퍼의 역할을 한다. 예를 들면, 오디오 성분이 스트림으로 전송되고 있는 경우, 네트워크 디스플레이의 맥동은 스트림을 중단시켜서 다시 시작하게 만든다. 프록시는 종단 장치에 대해 보다 더 부드럽고 정규적이도록 데이터 및 스트림을 버퍼할 수 있다. 프록시 이용과 관련한 또다른 이점은 프록시가 클라이언트 종단에서 어떤 것도 실행하지 않도록 해주는 것으로, 이것은 종단 장치가 소형이고 제한적인 성능을 가질 수 있으므로 바람직하다. 프록시 제공 트랜스코딩 기능은 웹 콘텐츠에 적용되어 특정 장치에 대한 전송을 적합하게 만들 수 있다. 예를 들면, Palm Pilot^*s는 오로지 2비트 그레이스케일 화상만을 지원하므로, 종단 장치로 전송하기 전에 프록시에서 영상의 트랜스코딩이 적용될 수 있다.

또한, 프록시는, 필요한 추가 파일(예를 들면, 영상, 오디오 파일 등)을 종단 사용자에게 요구하기 위해 대기하지 않고 페치한다는 점에서 브라우저처럼 작용한다. 웹 페이지를 수신하는 모든 종단 장치는 추가 파일을 질의할 것이 예측되므로, 프록시가 이 추가 파일을 질의하여, 일단 이들을 웹 서버로부터 캐시하고, 요구하는 종단 장치로 제공하면 되는 이점을 갖는다. 도 5는 본 발명에 따른 데이터 전송의 전술한 효율을 예시한다.

도 5에 도시된 바와 같이, 장치(Dev 1)는 웹 다큐먼트의 질의를 개시한다. 프록시는 이 요구를 전송하지만, 웹 서버로부터 응답이 되돌아 올때, 프록시는 브라우저가 그러는 것처럼 이 파일을 분해하여 영상, 사운드 파일 등을 질의한다. 이러한 영상 사운드 파일 등에 대한 질의가 종단 장치로부터 오면, 프록시는 캐시되어 있던 이 다큐먼트를 즉시 리턴시킬 수 있다. 프록시 페치 및 캐시 해결책은 또한 비 브라우저 종단 장치의 문제점도 해결한다. 예를 들어, 사용자는 영상을 TV 스크린에 보내는 것을 선택할 수 있지만, TV 스크린은 2진 데이터를 개대하므로, 프록시는 TV 스크린 대신에 XML 파일에 포함된 영상을 페치해야 한다.

서비스 디스커버리

공동 작업 다중 웹 브라우징은 두 가지 이유에서 서비스 디스커버리 메커니즘을 요구하는데, 첫째, 프록시가 다중 종단 장치에 대해 멀티미디어 세션을 분할할 수 있기 위해서는 프록시가 등록된 사용자와 함께 그들의 등록된 장치도 발견하는 어떤 수단을 가져야 하고, 둘째, 사용자가 브라우징 세션을 설립 또는 접속할 수 있도록 사용자와 그들 장치는 등록된 프록시를 발견하는 어떤 수단을 가져야 하기 때문이다. 사용자, 장치, 프록시의 등록 및 디스커버리에 관련한 메커니즘은 서비스 디스커버리 프로토콜을 요구한다. Sun Microsystems^*의 Jini^*, SLP^*, Microsoft^*의 UPP^*를 포함해 본 발명의 시스템에서 이용할 수 있는 많은 서비스 디스커버리 프로토콜이 존재한다. 이들은 공지된 프로토콜이므로, 서비스 디스커버리 프로토콜의 세부 사항은 본 명세서에서 상세히 다룰 필요가 없다.

도 6에 도시된 바와 같이, 서비스 디스커버리 및 등록은 공동 작업 다중 장치 웹 브라우징에 의해 세션 설립 단계와 세션 접속 단계에서 채용된다. 세션 설립 단계에서, 프록시와 서비스 디스커버리 간에 일련의 대화가 존재한다. 서비스 디스커버리는 프록시의 국소 성분일 수도 있고, 다수의 사이트 간에 분산될 수도 있고, 또는 중앙 집중화된 위치에서 발견될 수도 있다. 제 1 단계에서 프록시(610)는 클라이언트(즉, 세션 생성자(session creator)(614))가 나중에 프록시를 찾을 수 있도록 스스로 서비스 디스커버리(612)에 등록한다. 마찬가지로, 사용자/세션 생성자도 사용자에 의해 소유된 각 장치를 서비스 디스커버리에 등록한다. 사용자 등록은 세션의 설립시에 행해 질 수도 있고, 혹은 초기에 이루어졌다가 세션 설립시에 필요에 따라 사용자 장치 이용 가능성에 근거하여 갱신될 수도 있다.

다음, 세션 생성자(614)는 원하는 프록시의 하이퍼링크를 클릭하거나 그렇지 않으면 웹 대화를 개시한다. 세션 생성자의 시스템은 이 세션 생성자가 웹에 접속하려고 시도함으로써 간단히 프록시를 액세스하도록 구성될 수도 있고, 그러면 프록시의 주문이 사용자에게 투명해진다. 웹 대화를 개시한 경우, 웹 대화를 개시하는 즉시 세션 생성자의 시스템은 서비스 디스커버리에게 등록된 프록시를 찾을 것을 질의하고, 프록시가 선택 및 접속된다. 일단 접속되면, 프록시(610)는 세션명과 첫 번째 XML 웹 페이지의 URL을 요구하는 세션 로그인 메뉴를 리턴시킨다. 그 이후, 프록시는 등록된 XML 페이지와 그 연관된 폴리시 파일(617)을 웹 서버(615)로부터 가져온다. 프록시는 이 XML 페이지와 폴리시 파일을 분해하여, 특권 그룹을 생성하고, 사용자명과 패스워드를 요구하는 로그인 메뉴를 세션 생성자로 보낸다. 사용자와 특권 그룹이 일치하면, 프록시는 서비스 디스커버리에게 새로운 세션을 알리고, 세션 생성자에 의해 등록된 모든 장치를 요구한다. 마지막으로, 세션 생성자가 수신하는 것이 허락된 요구된 XML 페이지의 일부가 세션 생성자로 리턴된다.

세션 접속 단계에서는, 현재의 세션이 이미 설립되어 있고, 프록시/사용자 및 서비스 디스커버리 간에 3개의 대화가 존재하는데, 첫째는, 새로운 사용자 또는 가입자가 자신의 장치를 서비스 디스커버리에 등록하는 것이고, 둘째는, 가입자가 서비스 디스커버리에게 현재 진행중인 브라우징 세션의 리스트를 요구하는 것이고, 셋째는, 프록시가 새로운 가입자와 연관된 모든 등록된 장치를 서비스 디스커버리에게 요구하는 것이다. 도면 부호(616)에 있는 표는 프록시와 세션을 등록하기 위해 서비스 디스커버리 성분에 보유되어 있을 수 있는 간단한 기록을 제공한다.

본 발명의 시스템 및 방법과 현재의 서비스 디스커버리 사이의 전술한 대화는 두 개의 동작 즉, register() 및 query()로 줄일 수 있다. 현재의 서비스 디스커버리 프로토콜은 프록시와 브라우징 세션 뿐만 아니라 사용자와 그들의 장치까지도 register()할 수 있다. 또한, 서비스 디스커버리는 query()에 응답하여, 등록된 프록시 및/또는 세션의 리스트나, 등록된 사용자와 각 사용자와 연관된 장치의 리스트를 리턴할 수 있다. 서비스 디스커버리의 레지스트리가 중앙 집중화되어있는지 혹은 분산되어 있는지, 또는 등록된 프록시/세션이 국소 영역을 위한 것인지 혹은 넓은 영역에서 이용 가능한 것인지는 선택된 서비스 디스커버리 프로토콜에 의해 결정되는 요인으로, 본 발명의 시스템과 방법을 변경시키지는 않을 것이다. 물론, 넓은 영역을 지원하는 것이 원거리 광역 공동 작업(예를 들면, 원거리 학생과의 원격 학습)을 제공하도록 프록시의 성능을 확대시킬 것이다.

서비스 디스커버리에 대한 인터페이스는 서비스 디스커버리와 대화하고 있는 것이 클라이언트인지 혹은 프록시인지에 따라 다르다. 프록시는 서비스 디스커버리에게 어떠한 시각적 인터페이스도 요구하지 않을 것이므로, 간단한 절차적 API가 인터페이스할 것이다. 반대로, 클라이언트상의 종단 사용자는 서비스 디스커버리에 대해 그래픽 UI 또는 브라우저형 인터페이스를 가질 수 있다. 클라이언트와 서비스 디스커버리 간의 대화의 상세한 내용은 본 발명의 범주를 벗어난 것이다. 이런 대화가 존재하고, 이 대화로 클라이언트 장치를 등록시킬 수 있을 뿐만 아니라, 리스트된 프록시 및/또는 세션을 클라이언트에게 리턴시킬 수 있다는 사실만이 필요하다.

갱신 데이터 전송

약간의 갱신 데이터가 존재할 때마다, 이 데이터는 스피커나 TV 스크린 같은 모든 브라우저와 장치로 푸시되어서, 모든 사람이 그들이 보는 것에 동기화되어야 한다. 그러나, 클라이언트측에서 변형은 필요하지 않으며, 어떠한 프로그램도 다중 장치 웹 브라우징을 기능시키기 위해 실행될 필요가 없다. 그 이유의 일부분은 Palm Pilot^*같은 어떤 장치들은 멀티쓰레드(multi-threaded)되어 있지 않아서 이들 장치상에서 데몬(daemon)이 실행될 수 없기 때문이다. 그러므로, 데이터를 푸시하는데, 웹 브라우저의 현재 특징만을 이용하려고 노력하는 것이 바람직하다. 서버 푸시(server push) 혹은 클라이언트 풀(client pull), 이 두 개의 해결책 중 하나가 종단 브라우저로 데이터를 전송하는데 이용될 수 있다. 서버 푸시의 경우, 서버는 데이터(chunk of data)를 송신하고, 브라우저는 이 데이터를 디스플레이하지만 접속은 개방해두며, 서버가 원할 때마다 서버는 더 많은 데이터를 전송하고 브라우저는 그것을 디스플레이하면서 접속은 개방해둔다. 반대로, 클라이언트 풀에서는, 서버가 "이 데이터를 5초동안 리로드(reload)하라"든지 혹은 "이 다른 URL을 10초동안 로드하라"는 지시(HTTP 응답으로 혹은 다큐먼트 헤더로)와 함께 데이터를 송신한다. 지정된 시간이 경과하면, 클라이언트는 지시된 것을 실행한다(즉, 현재 데이터를 리로드하거나 새로운 데이터를 입수함).

클라이언트 풀에 대한 서버 푸시의 주요 이점은, 데이터가 언제 그리고 얼마나 자주 전송될 것인지에 대해 서버가 완전히 제어한다는 것이다. 또한, 이 방법은 새로운 HTTP 접속이 모든 시간 내내 개방되어질 수 없기 때문에 더 효과적일 수 있다. 단점(downside)은 개방되어 있는 동안 개방 접속이 서버측상의 자원을 소비하는 것이다. 불행하게도, 브라우저의 모든 플레이버(flavors)는 동이한 특성을 갖지 않는데, 예를 들면, Netscape^*와 IE^*는 서버 푸시와 클라이언트 풀을 구현하는데 동일한 기술을 이용하지 않는다. 예를 들어, 서버 푸시(이것은 서버가 데이터를 브라우저로 푸시하는 것을 허용한다)를 하기 위해, 넷스케이프는 "멀티파트/혼합형(multipart/mixed)"으로 지칭되는 특정한 마임형(a specific mime-type)에 의존하는데, 이것은 단일 메시지(혹은 HTTP 응답)가 많은 데이터 항목을 포함하도록 하는 것이다. 푸시된 데이터의 다른 부분들은 정의된 구분 문자 스트링(delimiter string)으로 분리된다. 그러나 IE 브라우저는 마임 형태를 이용하지 않으므로, 본 발명은 브라우저로 데이터를 푸시하는데 이 방법을 사용할 수 없다. WinCE^*장치에서 이용되는 IE 포켓과 관련해서는, 이들이 완전한 http 사양을 구현하지 않으며, 우리가 클라이언트 풀 기법을 이용할 수 있게 해주는 자바스크립트를 지원하지 않는다.

그러므로, 지원되는 특징의 차이가 주어지면, 각각의 브라우저 유형에 맞게(적어도 가장 흔한 브라우저 유형에 맞게) 데이터를 푸시하는 다른 방법이 필요하다. 다음의 해결책이 제공된다. Netscape^*의 경우, 클라이언트가 넷스케이프를 실행중임을 프록시가 발견하면, 서버 푸시 모델을 이용할 것인지 혹은 클라이언트 풀 모델을 이용할 것인지 결정할 수 있다. 서버 푸시 모델일 경우에는, 프록시와 클라이언트 장치의 웹 브라우저 사이에 영구 링크(permanent link)가 개방된다. 이 링크는 종단 브라우저가 http 헤더에 mime-type=multipart/mixed를 수신할 때 개방된다. 다음, 데이터는 이 파이프를 통해 웹 서버로 푸시된다. 다음 코드는 일 예를 제공한다.

이 예에서, 영구 링크는 클라이언트 브라우저가 콘텐츠 유형 멀티파트/혼합형으로 메시지를 수신할 때 생성된다. 속성 경계(attribute boundary)는 서버에 의해 푸시된 데이터를 구분하는데 이용될 스트링을 지정한다. 그러므로, 서버가 클라이언트에게 데이터를 전송하고자 할 때, 이것은 데이터를 경계 스트링으로 구분하고, 헤더 콘텐츠 유형으로 데이터 유형을 정의한다.

클라이언트 풀 방법은 자바스크립트를 이용하거나, 혹은 웹 페이지를 주기적으로 리로드하는 것을 허용하는 리프레시(Refresh)로 불리우는 특수한 http 헤더를 이용하여 행해질 것이다. 그러므로, 만약 다큐먼트가 프록시에서 변경되면, 새로운 콘텐츠는 정기적인 시간 간격으로 디스플레이될 것이다. 이 특수 http 헤더는 Refresh:3 같은 것이 될 수 있다. 동일한 웹 페이지는 매 3초마다 리프레시된다.

만약 종단 클라이언트가 IE를 실행중이면, 현재 IE 버전으로는 서버 푸시가 지원되지 않으므로, 오로지 클라이언트 풀 방법이 이용될 수 있다. 그러므로, 클라이언트 브라우저는 (자바스크립트 혹은 http 리프레시 헤더를 이용하여) 갱신을 할 것인지 프록시에게 정기적으로 질의해야 할 것이다.

넷스케이프 및 IE와 관련한 또다른 선택적인 해결책은, 프록시로부터의 통지(notification)에 귀를 기울여서 프록시로부터 전송된 url로 다큐먼트를 보여줄 것을 브라우저에게 말하는 애플릿을 이용하는 것이다. 이 방법은 은닉형 클라이언트 풀(hidden client pull)인데, 이것은 새로운 데이터의 이용 가능한 때가 통지되는 애플릿의 제공에 의해 더 융통성있어 진다. 이런 식으로, 페이지는 새로운 데이터가 이용 가능할 때를 제외하면 정기적인 순간에 리프레시되어지지 않는다. 이런 것은 넷스케이프에 대해서는 넷스케이프 플러그-인으로, 혹은 IE에 대해서는 Microsoft Active X^*성분으로 행해질 수 있다.

만약 클라이언트가 포켓 IE(WinCE 장치)를 실행중이면, 데이터를 푸시할 자명한 방법이 존재하지 않는데, 그 이유는 클라이언트가 HTTP의 완전 버전을 실행하지 않고, 리프레시 HTTP 헤더를 이해하지 못하며, 자바스크립트 혹은 자바도 이해하지 못하며, 서버 푸시를 지원하지 않기 때문이다. 해결책은, HTML 다큐먼트를 디스플레이하기 위해 API를 제공하는 HTML 뷰어 제어라고 불리우는 것을 사용하는 것이 될 수 있다. 이러한 시스템에는, 프록시로부터 (소켓을 이용하여) 데이터를 수신할 수 있는 프로그램이 작성될 수 있고, 사람들은 HTML 다큐먼트를 디스플레이하기 위해 HTML 뷰어 API를 이용할 수 있다.

공동 작업 프로세스

장치와 사용자가 본 발명의 프록시 기반 해결책을 이용하여 공동 작업하는데 필요한 특정한 단계들의 시퀀스가 이제부터 설명될 것이다. 일반적으로, 도 7에 도시된 프로세스는 프록시가 웹 페이지의 XML 태그를 각 사용자와 관련한 상이한 출력 장치들에 대해 맵핑하는 일련의 규칙을 어떻게 만드는지 개략적으로 설명한다. 개념상의 선명성을 위해, 공동 작업 다중 장치 웹 브라우징 세션의 정규 동작은 4 단계로 나뉘어질 수 있다. 제 1 단계로, 단계(701)에 도시된 바와 같이 웹 페이지는 XML로 예비 제작(pre-authored)되어야 한다. 웹 제작 단계는 다중 사용자들간의 공동 작업을 돕기 위한 XML 폴리시 파일의 생성도 추가적으로 포함할 수 있다(폴리시 파일은 태그를 특권 그룹에 맵하는 디폴트 규칙을 포함한다). 웹 제작 다음에, 단계(720)에 도시된 바와 같이 사용자가 전술한 XML 웹 페이지와, 만약 존재한다면 폴리시 파일도 요구함으로써, 브라우징 세션이 프록시에서 설립되어야 한다. 다음, 단계(740)에 도시된 바와 같이, 새로운 잠재적 가입자가 세션에 로그인하고 그들이 속한 특권 그룹을 식별함으로써, 이미 설립된 브라우징 세션에 접속할 수 있다. 마지막으로, 설립된 세션에 접속한 이후에, 단계(760)에서 가입자는, 가입자가 소유하거나 또는 액세스가 허가된 종단 장치에 XML 태그를 맵하는 그 규칙을 커스텀화(cuatomize)할 수도 있다. 전술한 단계의 각각은 이제 더욱 상세하게 설명될 것이다.

웹 제작(Web Authoring)

공동 작업 다중 장치 웹 브라우징은 도 7의 웹 제작 단계(701)에서 웹 사이트의 작성자가 다중 XML 관련 다큐먼트를 생성하는 것을 요구하는데, 이 다중 XML 관련 다큐먼트는 XML 웹 페이지, 그 첨부 XSL 다큐먼트, 비록 매우 유리하기는 하지만 선택적인 폴리시 파일을 포함한다. 웹 페이지를 작성하는데 이용되는 전통적인 언어는 HTML이다. HTML은 웹 페이지의 성분의 포맷팅을 기술하는 표준화된 마크업 언어(standardized markup language)이다. 웹 페이지의 콘텐츠와 무관하게 범용 태그(generic tags)가 사용되는데, 이것은 사람이 HTML 소스를 판독 및 이해하는 것을 어렵게 한다. HTML 태그는 포맷팅 의미는 갖지만 웹 다큐먼트의 일부처럼 콘텐츠 의미는 갖지 않는다. 그 결과로, HTML은 본 발명에 적절하지 않다. 자바스크립트 혹은 마이크로소프트 제이스크립트(Microsoft Jscript)같은 스크립트를 이용해 HTML을 더 융통성있고 의미있게 만들려고 노력은 했지만, 현재의 HTML은 웹 작성자에게 폴리시 파일을 생성하는 능력을 제공하지 못한다. 본 발명이 HTML을 이용해 생성된 다큐먼트에 적용될 수 없다고 말할 수는 없다. 사실, HTML 다큐먼트는 본 발명을 이용하는 서로 다른 사용자 장치에서 콘텐츠 부분의 전송을 위해 다큐먼트 부분들로 분할될 수 있다. 그러나, 다큐먼트를 분할하고, 폴리시 파일에 근거하여 상이한 특권 그룹에 속한 사용자에게 콘텐츠를 선택적으로 전송하는 양상은 HTML 다큐먼트로 쉽게 구현되지 않는다.

선택적으로, XML은 작성자가 자신의 다큐먼트를 개발할 때 자신이 필요한 태그를 구성하는 언어이다. XML은 포맷팅이 아니라 의미 규칙을 기술하는데, 포맷팅은 XSL 혹은 CSS로 작성될 수 있는 스타일 시트(style sheet)로 다큐먼트에 부가된다. 본 발명을 구현하기 위한 웹 콘텐츠의 제작 언어로서 XML에 의존하는 것이 바람직하다. 웹 커뮤니티는 풍성한 웹 콘텐츠를 개발함에 있어서 HTML의 한계를 인식하는데, 그 이유는 마크업 언어처럼 XML로의 변환을 시작하려고 하는 노력때문이다. XHTML 같은 W3 제안은 HTML과 XML 간의 호환성을 정의하는 방법을 제공한다. 또한, 수많은 웹 서버가 이미 웹 콘텐츠를 XML 다큐먼트로 기억하고 있지만, 이 콘텐츠를 종단 사용자에게 전송하기 전에 HTML로 변환한다.

XML은 그 융통성으로 인해 본 발명을 구현하기에 매우 적합하다. 모든 작성자가 자신이 소유한 태그와 성분을 정의하기 때문에, 최종 다큐먼트를 선택된 장치로 전송될 수 있는 독립적인 성분으로 분할하는 것이 더 쉽다. 페이지 상에서 각기 고유하게 명명된 태그는 태그가 전송될 출력 장치를 기술하고 있는 자신의 디멀티플렉싱 폴리시를 갖는 것이 최선이다. XML은 각 태그의 이름을 고유하게 정의하는 능력을 제공하고, XSL은 각 태그의 용도를 정의할 수 있다. 더 나아가, XSL 다큐먼트는 커스텀화된 XML을 브라우저가 제공할 수 있는 언어로 변환하기 위해 XML-활동가능 브라우저에 의해 요구된다. 이러한 XSL 다큐먼트는 XML에서 HTML로(또는 필요하다면 다른 마크업 언어로)의 변환을 정의할 것임을 가정하였고, 이것은 프록시가 서버와 브라우저 사이에 이용되지 않는 경우라 해도 비 XML-활동가능 브라우저가 웹 다큐먼트를 처리할 수 있음을 보장할 것이다.

도 4에 도시된 슬라이드 프리젠테이션을 위한 XML 웹 페이지의 다음 예를 고려하자. 웹 페이지에 4개의 성분 즉, 네비게이션 버튼, 그래픽 슬라이드, 사적인 주석, 오디오가 존재했었음을 상기하자. 각 페이지의 비 오디오 성분을 기술하는데 이용되는 XML 파일은 다음과 같다.

다큐먼트는 타이틀(tag<title>)과 네비게이션 바(tag<nav_bar)를 갖는 헤더 부분과, 슬라이드(tag<picture>)와 사적인 주석(tag<notes>)을 포함하는 두 개의 모체 부분을 갖는다.

이러한 두 개의 파일(XML 및 XSL)에 더하여, 작성자는 맵핑 규칙을 정의하는 폴리시 파일을 선택적으로 작성할 수도 있는데, 이 맵핑 규칙은 어떤 XML 태그가 어떤 특권 그룹과 어떤 장치에 분배되어야 하는지를 다룬다. 폴리시 파일에 의해 제공되는 가장 큰 이점은 웹 프리젠테이션에서 누가 무엇을 볼 것인지 제어하는 능력이다. 폴리시 파일은 특권 그룹을 정의하고, 다음에 각각의 특권 그룹이 XML 태그의 어떤 서브세트를 수신하도록 허가되었는지 정의한다. 작성자는 폴리시 파일을 이용하여, 다른 가입자들에게는 완전한 액세스 특권을 부여하면서 특정 그룹은 웹 프리젠테이션의 부분 뷰만을 수신하도록 제한할 수 있다.

폴리시 파일의 주요 책임은 특권 그룹의 정의이다. 특권 그룹 이면에 있는 개념은 공동 작업 브라우징 세션에서 참가자의 액세스 특권을 구별하는 메커니즘을 제공하는 것이다. 세션은 서로 다른 특권 그룹에게 서로 다른 웹 브라우징 세션의 부분 뷰를 제공할 수 있다. 브라우징 세션에서 다중 사용자에게 전송될 웹 페이지의 작성자는 어떤 사용자 그룹에게는 다른 그룹들보다 특정 XML 태그를 액세스하는 더 높은 혹은 더 낮은 특권을 주고자 할 수도 있다. 위의 예에서, 폴리시 파일은 공동 작업 프록시를 통해 대학 수업을 온-라인으로 학생에게 제공하는 강사가 학생들이 각 제공된 웹 페이지상에서 태그의 서브셋만을 보도록 제한할 수 있게 하는데, 다시 말해서, 강사는 학생들이 사적인 메모 주석을 볼 수 없게 하고(<notes> 태그는 학생들이 이용 불가함), 학생들이 강의에 대한 네비게이션 제어를 액세스하지 못하게 한다(<nav_bar> 태그는 학생들이 이용 불가함).

폴리시 파일이 XML 다큐먼트의 부분일 수도 있지만, 폴리시 파일은 폴리시 파일을 참조하는 XML 웹 페이지와 분리된 제 2의 파일인 것이 바람직하다. 분리된 파일의 이용은 다중 웹 페이지가 동일한 폴리시 파일을 참조하는 것을 허용한다. 예를 들면, 이러한 것은 모든 웹 페이지에 대해 동일한 특권 그룹의 세트를 정의하면서도 각 페이지에 대해서는 새로운 폴리시 파일을 재작성하는 것을 원하지 않는, 웹 슬라이드 프리젠테이션을 구성하는 작성자에게 유용할 수도 있다. 실제, 작성자는 프리젠테이션시 각 페이지에 의해 참조되는 단일 폴리시 파일을 작성한다. 동일한 폴리시 파일을 참조하는 모든 페이지는 동일한 특권 그룹을 공유한다. 작성자는 프리젠테이션에서 다중 페이지를 이동하면서 단일 폴리시 파일로 고려될 모든 XML 태그를 모은다. 분리된 폴리시 파일을 대신할 수 있는 것은 각각의 XML 페이지에 폴리시 파일의 정보를 내장하는 것이다. 그러나, 폴리시 파일 메타데이터 정보를 고유 파일로 분리하는 것이 작성자가 더 쉽게 특권 그룹을 갱신할 수 있게 하는데, 즉, 작성자는, 동일 특권 그룹과 관련해 동일한 내장된 정의를 포함하는 각각의 웹 페이지를 편집할 필요없이, 각 웹 페이지에 의해 참조되는 하나의 폴리시 파일만을 간단히 변경하면 된다.

전술한 XML 페이지의 예와 관련해 작성된 폴리시 파일의 예가 이하에 도시된다. 폴리시 파일은 XML 다큐먼트로 구성될 것이다. 이 다큐먼트에서, 명칭부(namespace)는 이러한 폴리시 파일에 이용되는 태그와 값들을 표준화하도록 정의된다. 다음에서, 명칭부 접두어(prefix) cmdb(collaborative multi-device browsing)이 도입된다. 이전 예에 대응하는 XML 폴리시 파일은 다음과 같다.

작성자가 폴리시 파일 내에서 사용해야 하는 태그 및 속성들을 표준화하는 스키마(schema)가 정의될 필요가 있다. 어떤 속성에 대해 이용되는 값도 표준화되어야 한다. 예를 들어, 모든 공동 작업 다중 장치 프록시가 특권 그룹이 정의되고 있음을 이해하기 위해 모든 작성자는 표준 태그명 "group"을 이용하는 것이 중요하다. 동일한 XML 폴리시 파일은 다음에 제안된 표준 태그명 group, device, taglist, undefinetag_list, media_types, images, text을 포함한다(비디오 및 오디오는 도시 안됨). 또한, 각각의 태그는 자신의 고유 속성을 갖는데, 예를 들면, 그룹 태그는 "name", "password", "input_permitted"를 갖는다. 마지막으로, 속성 "name"과 "password"의 값은 표준화될 필요가 없지만, 어떤 속성의 값들은 표준화되어서, 작성자가 의도한 그것의 의미를 프록시가 보편적으로 이해할 수 있어야 한다. 예를 들면, input_permitted는 "예(yes)" 혹은 "아니오(no)"로 설정되는 표준화된 값을 가져야 한다(그렇지 않으면, 다른 작성자들은 참/거짓, 온/오프, 1/0 등을 이용할 것이다). 공지된 명칭에 대해서는 어느 정도 자유로울 수 있는데, 즉, 프록시는 <device name="InternetExplorer">가 장치 속성 IE를 말하는 것임을 이해할 수 있다. 그러나, 다른 종단 장치에 대해서는 이것이 좀 어렵다. 결과적으로, 장치를 칭하기 위해 공통의 용어로 일치시키는 것이 바람직하다. 이러한 단어(vocabulary)는 언제든지 지정될 수 있으며, 당연히 확장도 가능할 것이다.

또한 장치 태그의 속성 성능은 작성자가 콘텐츠 출력 장치의 성능과 관련해 특정 요구를 지정하도록 도입될 수도 있다. 예를 들어, 태그의 다음 세트가 사운드 카드를 갖는 어떤 장치로 전송될 수 있음을 의미하는 <cmdb:device capability="sound_card">가 이용될 수 있다. 여기에서는 성능 속성의 값을 표준화하여 프록시가 성능 속성의 값을 서비스 디스커버리에서 검색한 값과 일치시킬 수 있도록 하는 것이 더 중요하다. 프록시는 각 장치에 대해 서비스 디스커버리 데이터베이스에 등록된 다양한 속성으로부터 장치의 성능을 익힐 것이다. 성능을 기술하는 표준화 방식이 없는 경우에는 프록시가 이 정보의 이점을 취할 수 없다. 그러므로, 장치는 작성자가 그들 성능을 서비스 디스커버리에 기재한 것과 동일한 단어를 이용해야 한다. W3C 드래프트 "Composite Capability/Preference Profiles(CC/PP)"는 장치 특성의 세계 표준화를 추구하는데, 이것은 본 발명의 이런 양상을 장래에 보다 더 쉽게 구현하게 할 수도 있다.

세션에 의해 프록시로 다운로드된(혹은 XML 페이지의 일부인) 첫 번째 XML 페이지와 연관된 초기 폴리시 파일이 특권 그룹 즉, 세션내내 관찰되는 맵핑 규칙을 정의하는 것으로 가정하였다. 다른 폴리시 파일을 갖는 다른 페이지도 고려될 수 있지만, 초기 폴리시 파일에 의해 정의된 특권 그룹 및 태그 맵핑 규칙이 모든 이후의 폴리시 파일을 무효로 만든다. 비정의된 태그에 대한 다음의 논의와 관련하여, 브라우징 세션이 이미 설립되었고, 세션의 첫 번째 XML 페이지와 함께 다운로드된 초기 폴리시 파일이 존재하는 것으로 가정한다.

폴리시 파일의 Undefined_Tags 변수는, 강사 혹은 세션 프리젠터가 공동 작업 브라우징 세션을 설립한 첫 번째 웹 페이지에 의해 참조되는 폴리시 파일내에 정의되지 않은 태그를 갖는 웹 페이지에 액세스하는 경우, 미지의 XML 태그를 어디로 전송할 것인지를 프록시에게 말한다, 세션 프리젠터가 오로지 초기 폴리시 파일의 정의를 따르는 웹 페이지에만 액세스하도록 제한하는 것은 너무나 제한적인 것이다. 실제, 세션 프리젠터가 초기 웹 페이지의 폴리시 파일의 범주를 벗어나는웹 사이트를 자유롭게 브라우즈하도록 하는 것이 바람직하다. 예를 들어, 슬라이드 쇼를 웹 청중에게 제공하는 강사는, 데몬스트레이션을 위해, 강의용으로 준비한 슬라이드만을 보여주는 것이 아니라, 준비된 강의용 외의 웹 페이지에서도 슬라이드를 보여주고 싶을 것이다. 이러한 시나리오에서, 세션 프리젠터는 미리 정의된 폴리시 파일을 갖지 않는 웹 페이지를 방문하는데, 예를 들면, CNN같은 상업용 웹 사이트는 분명히 공동 작업 웹 브라우징이며, 초기 폴리시 파일 PF와 다른 폴리시 파일 PF' 및 PF''를 갖는 두 개의 다른 웹 페이지를 방문한다.

또한 사용자는 폴리시 파일을 갖는 어떠한 웹 페이지도 액세스하지 않고 공동 작업 브라우징 세션을 설립할 수 있다. 이러한 경우는, 사람들 그룹이 함께 브라우즈하기를 원하지만 정식으로 정의한 특권 그룹의 다른 사용자 서브셋에는 관심이 없는 일반적인 시나리오를 지원하는 것이 그 의도이다. 그러나, 세션 프리젠터가 다른 그룹이 보는 것을 보다 더 정식으로 제어하기 위한 방법을 요구하면, 폴리시 파일은 동일한 웹 페이지의 부분 뷰를 제공하는 수단을 제공한다.

초기 폴리시 파일의 범주를 벗어나는 웹 페이지에 대한 액세스를 허용한 결과, 프록시는 초기 폴리시 파일에 정의되지 않은 친숙하지 않은 XML 태그도 고려할 것이다. 미정의된 태그를 다루기 위해, Undefined_Tags 변수의 개념이 도입된다. Undefined_Tags 변수는 정의되지 않은 태그를 전송할 곳을 프록시에게 지시한다. 프록시가 정의되지 않은 태그를 고려할 때, 프록시는 이것을 자신의 미디어 혹은 MIME 유형에 기초하여 태그로 전환하는데, 그 이유는 미지의 태그 명칭에 기초하여 전환하는 것은 불가능하기 때문이다. 이런 목적을 위해 섹션 미디어 유형이 폴리시 파일에 포함된다. 작성자는 어떤 태그가 어떤 미디어 유형에 속하는지를 기재하는데, 이것이 어떤 태그가 어떤 미디어 유형으로부터 유래된 것인지를 프록시가 아는 방법이다. 전술한 예에서, 폴리시 파일은 프록시에게, 액세스를 위한 PC 기반 브라우저를 이용해서는 유형 텍스트, 영상, 오디오, 비디오의 미정의된 태그를 강사와 학생들에게 전송하라고 지시하고, 액세스를 위한 PDA 기반 브라우저를 이용해서는 단지 유형 텍스트의 미정의된 태그만을 전송하라고 지시한다. 태그명이 폴리시 파일에 정의되지 않은 페이지를 액세스하는 것은 최적이 아닌 페이지 프리젠테이션을 초래한다.

동일한 폴리시 파일이 다중 웹 페이지에 의해 참조될 수도 있다. 세션 프리젠터는 프리젠테이션을 위한 웹 슬라이드 시퀀스를 제작할 수도 있는데, 슬라이드 시퀀스의 시작 페이지는 프리젠테이션에서 액세스되는 모든 이후의 페이지에 적용할 수 있는 폴리시 파일에 대한 참조를 포함할 것이다. 프리젠테이션에서 액세스될 각각의 다음 페이지는 동일한 폴리시 파일을 참조할 것이다. 다중 웹 페이지에 의해 참조되는 폴리시 파일은 브라우징 세션 동안 고려될 모든 태그의 리스트를 가능한 완전하게 포함해야 한다. 폴리시 파일에 실수로 누락된 모든 미정의된 태그는 이전에 논의된 Undefined_Tags 메커니즘에 의해 포착될 것이며, 그 결과 최적은 아니지만 차선의 프리젠테이션을 유도할 수 있다.

폴리시 파일은 태그명의 수퍼셋(superset)을 포함하므로, 폴리시 파일에 의해 커버되는 각각의 웹 페이지는 기재된 태그명의 상이한 서브셋을 이용할 수도 있으므로, 상이한 외관을 가질 수 있다. 지금 진행하는 일 예의 콘텐츠에서, 프리젠테이션의 다음 슬라이드는 이전에 정의된 페이지의 태그명과 동일한 것을 재사용할 수도 있고, 또는 태그명의 다른 서브셋을 이용하여 다른 모양과 느낌을 유도할 수도 있다.

다중 웹 페이지에 적용하도록 폴리시 파일의 범주를 확대하는 한 가지 이유는 커스텀화(customization)를 단순화시키기 위한 것이다. 만약 각각의 웹 페이지가 상이한 태그 서브셋을 이용하지만 동일한 특권 그룹 세트를 이용할 경우, 종단 사용자는 각 페이지가 다운로드될 때 새로운 맵핑을 요구 또는 생성해야 할 것이다. 세션 내의 모든 태그들을 단일 폴리시 파일로 모음으로써, 종단 사용자는 프리젠테이션에서 초기에 강의 레이아웃을 커스텀화할 수 있을 것이다. 상이한 페이지는 계속해서 상이한 태그를 이용할 것이므로, 집단 폴리시 파일내에 페이지 단위로 태그를 그룹화하는 메커니즘의 필요성이 존재하며, 그렇게 함으로써 종단 사용자는 어떤 태그가 프리젠테이션의 어느 페이지에 속하는지를 알아차릴 수 있다.

비록 사용자가 특정 XML 태그를 액세스할 특권을 가졌을지라도, 그 사용자는 해당 XML 태그를 처리할 수 있는 출력 장치를 구비하지 않을 수도 있다. 예를 들면, 사용자가 라우드스피커가 없는 PDA로 공동 작업 브라우징 세션에 액세스했는데, <audio_music>이라고 불리우는 태그를 액세스하는 것을 허가받았다면, 이 사용자는 하드웨어적 제한 때문에 사실상 <audio_music>의 이점을 누릴 수 없을 것이다.

공동 작업 세션을 설립

도 7의 단계(720)을 참조하면, 비록 폴리시 파일없이도 세션을 설립하는 것이 가능하지만, 새로운 공동 작업 브라우징 세션은 전형적으로 폴리시 파일이 프록시로 다운로드될 때 설립된다. 폴리시 파일의 추가된 이점은 특권 그룹이라고 불리는 가입자의 상이한 그룹의 정의를 공동 작업 브라우징 세션내에 가능하게 하는 것으로, 이렇게 하면 프록시는 XML 태그의 상이한 서브셋을 상이한 특권 그룹으로 선택적으로 전송할 수 있다. 다음, 각각의 새로운 가입자는 로그인 패스워드를 제공함으로써, 설립된 공동 작업 브라우징 세션에 접속한다. 이 패스워드는 그 가입자를 폴리시 파일에 정의된 특권 그룹과 연관시킨다. 패스워드는 e-메일같은 어떤 결합외 메커니즘(out-of-band mechanism)에 의해 미리 사용자에게 제공된다. 공동 작업 브라우징 세션에서 요구되는 특권의 등급에 따라, 폴리시 파일의 몇몇 혹은 모두가 암호화될 수도 있다. 전술한 예의 경우, 폴리시 파일은 두 개의 특권 그룹 "강사"와 "학생"을 정의하고, 각 그룹과 연관된 패스워드를 정의하며, 각 그룹이 수신하도록 허용된 태그를 정의한다. 폴리시 파일이 없는 경우, 이것은 부재 폴리시 파일(null policy file)이라고 불리우는데, 프록시는 디폴트 맵핑 규칙을 강제로 구성하며, 이 디폴트 맵핑 규칙은 작성자의 바램과 일치하지 않을 수도 있다.

정확한 로그인 다음에, 프록시는 각 특권 그룹 즉, 그룹내에서 각기 정확하게 로그인된 가입자가 어느 XML 태그를 수신하도록 허가되었는지를 알기 위해 폴리시 파일을 찾아본다. 각각의 특권 그룹내에서, XML 태그가 전송될 곳을 지배하는 맵핑 규칙은 사용자 출력 장치/브라우저에 근거하여 더욱 상세해질 수 있다. 또한 폴리시 파일은 각 XML 태그의 미디어 유형을 식별하는데, 이것은 종단 사용자가 각기 고유하게 명명되어진 XML 태그(영상, 오디오 등)의 목적을 이해할 수 있도록 만든다. 이후에 논의되는 바와 같이, 태그 마다의 미디어 식별(per-tag media identification)은 태그와 출력 장치 사이의 맵핑 규칙을 커스텀화하려고 노력하는 종단 사용자를 도와준다. 전술한 것은 작성자가 다양한 일반적인 시나리오에 참여하도록 더 융통성있게 디폴트 태그 맵핑 규칙을 구성하는 것을 가능하게 한다. 이전의 예에서, 웹 페이지의 작성자는 교실에서 강사의 랩탑을 통해 큰 투영 스크린에 슬라이드를 제공하는 강사가 걸어다니면서 강사의 무선 PDA를 통해 프리젠테이션을 원격 제어하는 것을 선호할 것이라고 생각할 수도 있다. 이 경우, 전술한 폴리시 파일은 사적인 주석이 랩탑으로 전송되지 않고 PDA로 전송되는 디폴트 규칙을 지정하여, 강사가 방안의 어디에서든지 강의를 하면서 주석을 찾을 수 있게 한다. 두 번째 예로서, 강사의 교실에 위치하지는 않지만 강사의 세션을 원거리에서 따라가고 있는 두 명의 학생이 있다고 가정하자. 한 명의 학생은 접속된 랩탑상의 브라우저로 세션을 따라가는 반면, 다른 학생은 접속된 PDA(아마도 클램톱(clamtop) WinCE^*장치나 무선 PDA)를 통해 강의를 따라가고 있다. 이 예에서, 폴리시 파일은 타이틀과 그래픽 슬라이드만이 랩탑 브라우저를 갖는 학생에게 전송되도록 하는 반면에 타이틀과 트랜스코드된 그래픽 슬라이드가 PDA를 갖는 학생에게 전송되도록 하는 디폴트 규칙을 지정한다. 또한 특정 디폴트 트랜스코딩 파라미터도 작성자에 의해 제공된다.

XML 웹 페이지가 첨부 폴리시 파일을 갖는지 혹은 갖지 않는지를 결정하기 위해, 프록시는 검색한 XML 페이지를 분해해야 한다. 만약 프록시가 폴리시 파일에 대한 참조를 찾아내면, 이 프록시는 폴리시 파일을 페치해야 한다. 폴리시 파일은 text/policy_file처럼 자신의 MIME 유형으로 자신의 URL을 가질 수 있는데, 이것은 그것이 영상일 때처럼 프록시로 하여금 여분의 파일을 페치하도록 만든다.

폴리시 파일에 대한 참조를 내장하는 한 가지 방법은 스타일시트 다큐먼트가 XML로부터 참조되는 방식과 동일한 방식을 따르는 것이다. XML 다큐먼트는 어떤 스타일시트가 다음 유형의 처리 정보를 이용하는지를 나타낸다.

동일한 방법으로, 처리 명령이 다음과 같이 이용될 수 있다

다음, 다중 장치 웹브라우징 프록시는 이 명령을 알아차리고, href 속성에 지정된 어드레스에 위치되어 있는 파일을 검색할 것이다.

도 7의 세 번째 단계(740)는 XML 웹 페이지와 관련한 요구에 의해 이루어진 프록시 내에 브라우징 세션을 설립하는 것이다. 도 8에 도시된 것처럼, 프록시내에 공동 작업 다중 장치 웹 브라우징 세션을 설립하기 위한 프로세스 흐름도에는 10개의 단계가 존재한다. 단계(801)에서, 프록시는 스스로를 서비스 디스커버리 데이터베이스에 등록한다. 일단 프록시가 작동하여 실행중이면, 프록시는 자신의 명칭과 자신의 IP 네트워크 어드레스를 개념적으로 서비스 디스커버리 데이터베이스(SDDB)라고 불리우는 서비스 디스커버리 프로토콜을 통해 등록한다. 서비스 디스커버리 프로토콜은 (1) 프록시들을 등록하고 각각의 프록시내에 각각의 브라우징 세션을 등록할 수 있어야 하고, (2) 각 장치의 소유자와 함께 장치를 등록할 수 있어야 하며, (3) 프록시, 세션, 사용자 장치들이 이미 SDDB에 자신을 등록했는지와 관련한 질의에 응답할 수 있어야 한다. 개념적으로, 서비스 디스커버리 프로토콜은 기록과 질의를 모두하는 데이터베이스처럼 작용한다. 그러나, 어떤 서비스 디스커버리가 이용되는지, 그리고 그 서비스 디스커버리 프로토콜이 자신의 SDDB를 어떻게 구현하는지에 대한 상세한 내용은 본 발명의 구현에 중요한 것이 아니다. 예를 들어, 전술한 것처럼, SDDB는 중앙 집중화된 데이터베이스 레지스트리로서 구현되거나 혹은 분산형 데이터베이스 등록 방식으로서 구현될 수도 있다.

도 8의 다음 단계(802)는 세션 생성자가 자신의 브라우저를 서비스 디스커버리 데이터베이스에 등록하는 것을 포함한다. 세션 생성자는 개시자의 브라우저 가능 컴퓨터가 SDDB에 등록될 것을 요구하는 SDDB에게 등록 메시지를 전송한다. 장치의 등록(이 경우에는 개시자의 컴퓨터)은 장치의 IP 어드레스, 장치명, 장치 소유자의 이름, 장치의 미디어 디코딩 능력(MPEG 비디오, .wav^*, RealVideo^*, WindowsMedia^*, JPEG^*< GIF^*, HTML 4.0, XML 등), 장치의 액세스 모드(장치 드라이버와 유사한 것으로, 이것으로 장치와 통신하는 프로토콜임)의 제공을 수반한다. 또한 등록 메시지는 모든 등록된 프록시와 그들의 등록된 세션의 리스트에 대한 요구도 포함한다.

등록 이후, 세션 생성자는 단계(803)에서 브라우징 세션을 생성하기 위한 프록시를 선택하고, 단계(804)에서 "세션 생성" 메시지를 프록시에게 전송한다. 구체적으로, 브라우저 가능 컴퓨터를 등록한 후, SDDB는 이용 가능한 프록시와 그들의 진행중인 세션으로 이루어진 리스트를 포함하는 응답을 세션 생성자로 리턴한다. 이 리스트는 간단한 하이퍼텍스트 인터페이스가 세션 생성자로 제공될 수 있도록 작성되어야 하는데, 그러면 누군가가 세션 생성자가 접속하고자 하는 곳으로 프록시상에서 수작업으로 클릭할 수 있다. 링크는 프록시가 자신을 SDDB에 등록할 때 프록시에 의해 제공된 사전 정의된 웹 페이지를 지목할 것이다. 이것은 새로운 세션 설립 형식이며, 사용자가 프록시명을 클릭하면, 이 사전 정의된 형식에 대한 요구가 프록시에게 전송되고, 프록시는 세션 생성자에게 다큐먼트를 리턴한다. 이러한 형식 덕분에, 사용자는 새로운 웹 브라우징 세션을 생성하는 것이 가능해질 것이다. 브라우저가 프록시 필드의 자동 갱신을 지원할 경우, 프록시 상에서의 클릭으로 브라우저가 원하는 프록시를 지목하도록 브라우저를 고쳐 쓸 수 있다면, 그것도 유용할 것이다(모든 브라우저 Http GET 요구는 프록시를 통해 라우트된다). 그러나, 브라우저가 자동 고쳐 쓰기(automatic redirection)를 지원하지 않는다면, 세션 생성자는 프록시 파라미터를 브라우저로 수동으로 전송해야 하는데, 다시 말해서 사용자가 "Edit Preferences"(넷스케이프인 경우) 혹은 "Tool->Internet Option" 메뉴(인터넷 익스플로러인 경우)를 편집해야 하며, 프록시 필드를 적절한 어드레스와 포트로 설정해야 한다. 이 때, 브라우저는 다음 단계동안 적절히 셋업될 것인데, 즉, 선택된 프록시를 통해 XML 웹 페이지를 요구한다.

프록시의 선정시, 사용자의 수작업을 필요로 하는 것은 프록시의 자동 선정 및 브라우저의 자동 고쳐 쓰기에 비해 바람직하지 않게 보일 수도 있다. 수작업이 관련되는 것은 구현이 덜 복잡해지는 이점이 있는 반면, 자동 선정 및 고쳐 쓰기는서비스 디스커버리 프로토콜에 추가적인 요구를 부과할 수도 있다. 예를 들면, SDDB에 대한 등록 메시지는, 등록된 프록시 리스트 및 진행중인 세션 리스트에 관한 개략적 질의처럼 가장 간단한 형식으로 해석되는 서비스 디스커버리 요구를 포함한다. 이러한 개략적인 서비스 디스커버리 요구가 주어지면, SDDB는 요구 사용자가 프록시 리스트에만 관계된 세션 생성자인지, 혹은 단지 진행중인 브라우징 세션들중 하나에 가입되어 있는 일반 사용자인지 말할 수 없다. 가입자인 경우, 가입자에 의한 수동 조정이 있어야 하며, 누구든지 진행중인 세션과 관련해 디스플레이되는 리스트를 조사하여 그중에서 하나를 선정하도록 할 수 있어야 한다. 그러므로, 요구 장치의 사용자가 가입자라고 믿으면, 두 리스트는 SDDB에 의해 리턴되어 요구 장치에서 서비스 디스커버리 프로토콜에 의해 디스플레이되어야 한다. 가입자가 아니라 세션 생성자인 사용자는, 비록 프록시를 선택하는 자동화된 알고리즘을 적용하는 것이 가능할 지라도, 프록시를 수작업으로 선택하도록 강제될 것이다. 프록시의 자동 선정을 완전히 지원하기 위해, 두 유형의 등록 요구 즉, (단지 프록시 리스트만을 요구하는) 세션 개시자로부터의 등록 요구와 (단지 브라우징 세션의 리스트만을 요구하는) 가입자로부터의 등록 요구를 서로 구별할 수 있도록 서비스 디스커버리 프로토콜에 대해 추가적인 요구가 부과될 것이다. 이런 식으로, SDDB는 선택적으로, 가입자인 사용자를 등록하기 위해 세션 리스트만을 리턴하거나 세션 개시자인 사용자를 등록하기 위해 프록시 리스트만을 리턴하거나 할 수 있다. 그 결과, 자동 방법(프록시 선택 및 브라우저 고쳐 쓰기)은 수동 방법(세션 선택)으로부터 분리될 수 있다. 자동 메커니즘은 이용 가능한 프록시와 관련해 수신된리스트의 수동 디스플레이를 무시하여 무효로 한다.

일반적으로, 세션 생성자는 아마도 PDA 뿐만 아니라 랩탑과 스테레오 시스템인 다수의 장치를 소유 및 등록할 수 있다. 이때 오로지 요구되는 것은, 프록시를 통해 XML 웹 페이지를 요구함으로써 공동 작업 브라우징 세션을 개시할 수 있는 적어도 하나의 브라우저 가능 HTTP 장치를 세션 생성자가 구비하는 것이다. 간단한 예로서, 도 6에 단 하나의 장치 즉, 브라우저를 지원할 수 있는 랩탑을 갖는 세션 생성자를 도시했다.

단계(805)에서, 프록시는 세션 생성 메시지를 세션 생성자로 보내어, 세션명과 세션의 첫 번째 XML 웹 페이지의 URL을 요구한다. 세션 생성자가 프록시를 선택하여 그것을 클릭하면, 요구가 프록시로 전송되고, 프록시는 새로운 세션 설립 형식을 리턴한다. 사용자는 단계(806)에서 세션명, 페치될 첫 번째 웹 페이지의 URL, 공개되지 않는 패스워드를 지정한다. 패스워드는 세션명이 미리 저장(pre-reserved)된 경우에 이용된다. 세션명을 미리 저장하는 것은 세션 생성자가 사전에(예를 들면 몇일 전에) 자신이 사용할 세션명과 그것과 연관된 패스워드를 지정했음을 의미한다. 이러한 연관 세션명-패스워드는 세션을 보호할 목적으로 시스템 관리자에 의해 공동 작업 다중 장치 웹 브라우징 프록시에 기억될 수 있다. 이런 식으로, 사전에 기억된 패스워드를 아는 사람만이 그 이름을 갖는 세션을 설립할 수 있다. 이것은 프리젠터가 원하는 사람이 아니면, 다른 웹 페이지를 지목하게 될 이 이름으로 그 누구도 세션을 생성할 수 없도록 보장한다. 세션을 사전 저장하는 이러한 개념은 슬라이드 프리젠테이션의 경우에는 유용하지만, 홈 시나리오의경우에는 그렇지 않다.

프록시가 완성된 형식을 수신하면, 단계(807)에서 이 세션명을 위한 어떤 패스워드를 가지고 있는지 판정하기 위해 검사한다. 만약 "예"이면, 프록시는 기억된 패스워드와 사용자가 지정한 패스워드를 비교한다. 만약 사용자가 입력한 패스워드가 일치하지 않으면, 이 요구는 중지(dropped)된다. 그러나 만약 패스워드가 정확하거나 혹은 이 세션에 대해 사전에 기억된 정보가 없으면, 단계(808)에서 프록시는 적당한 웹 서버로부터 웹 페이지를 페치할 수 있다. 프록시는 요구가 유래된 곳으로부터 소켓과 IP 어드레스를 기억하고, 이것을 웹 서버로부터 리턴된 파일과 연관시킨다.

세션 생성 형식으로 지정된 URL에 대응하는 페이지(XML 혹은 HTML)가 프록시에 도달하면, 단계(809)에서 프록시는 이것을 처리하여 세션을 설립할 필요가 있다. 만약 이것이 HTML 다큐먼트이면, 세션은 전술한 폴리시 파일을 갖지 않을 것이므로, 행해질 수 있는 다큐먼트 부분의 분할은 미디어-유형으로 제한되며, 상이한 특권 그룹의 즉각적인 구현도 존재하지 않는다. 바람직한 XML 다큐먼트의 구현이면, XML 다큐먼트는 어떤 다른 다큐먼트가 페치되어야 하는지를 결정하기 위해 분해될 필요가 있다. XSL 다큐먼트도 전형적으로 페치되는 것을 필요로 한다. 또한, 이 페이지는 폴리시 파일이 페치될 필요가 있음을 나타내는 "폴리시" 파일에 대한 참조를 포함할 수도 있다.

만약 분해된 XML 페이지내에 폴리시 파일에 대한 참조가 존재한다면, 단계(810)에서 프록시는 폴리시 파일을 웹 서버로부터 다운로드한다. 프록시는 폴리시 파일을 이용하여 특권 그룹에 근거하는 규칙들을 설립할 것인데, 이 규칙들은 웹 페이지의 여러 성분을 서로 다른 사용자들과 출력 장치에게 디스패치(dispatch)한다. 프록시는 다음 세 가지 시나리오중 하나를 고려할 것이다. 즉, 1) 폴리시 파일이 웹 페이지에 의해 참조되며, 모든 특권 그룹에 대해 패스워드를 정의한다. 2) 폴리시 파일이 참조는 되지만 어떤 특권 그룹에 대해서는 패스워드를 정의하지 않는다. 3) 웹 페이지가 폴리시 파일에 대한 참조를 포함하지 않는다.

폴리시 파일을 액세스하면, 프록시는 그룹과 이 그룹들이 각기 수신하도록 허용된 것에 대한 범용 정보(generic information)만을 갖는다. 특정 사용자 혹은 장치에 대해서는 아직까지 어떠한 폴리시도 세우지 않았다. 허가된 출력 장치와 허가된 XML 태그의 각 사용자에 대한 완전한 맵핑을 세우기 위해서, 프록시는 여전히 각 사용자가 패스워드를 통해 로그인하여 그들 자신을 주어진 특권 그룹의 멤버로 식별하는 것을 필요로 하고, 그리고 각각의 사용자가 자신의 출력 장치를 등록하여 웹 멀티미디어를 수신하는데 어떤 장치를 이용할 수 있는지 프록시가 알도록하는 것을 필요로 한다(이러한 등록은 이미 발생했을 것이므로 도시 안함).

단계(811)에서 결정된 것처럼 만약 폴리시 파일이 존재하고, 단계(812)에서 결정된 것처럼 모든 특권 그룹에 대해 패스워드를 정의한다면, 프록시는 이 폴리시 파일을 해석하여, 있을 수 있는 특권 그룹 값과 그들의 연관 패스워드 및 허가를 식별한다. 폴리시 파일은 누가 무엇을 볼 것인지, 그리고 어떤 장치가 다큐먼트의 어떤 부분을 수신할 것인지를 제어할 수 있게 한다. 그렇게 하기 위해, 폴리시 파일은 특권 그룹을 정의하고, 각각의 특권 그룹이 어떤 XML 태그의 서브셋을 수신하도록 허가되는지를 정의한다. 폴리시 파일은 더욱 상세한 사항을 제공하여, 태그들이 액세스 장치의 유형에 따라 각각의 특권 그룹내에서 더욱 세밀한 정도(finer granularity)로 디멀티플렉스될 수 있도록 할 수도 있다. 따라서 세션을 설립하기 위해, 프록시는 작성자에 의해 정의된 특권 그룹 값(만약 있다면 그 관련 패스워드도)과 이 그룹에 허가된 태그의 리스트를 분리할 필요가 있다. 이 정보를 이용하여 프록시는 다큐먼트의 어떤 부분이 각각의 가입 사용자에세 전송될 수 있는지에 관한 규칙과 맵을 설정할 것이다. 일단 단계(813)에서 어떠한 패스워드가 검증되면, 프록시는 단계(814)에서 다큐먼트를 다큐먼트 부분들로 분할하여 단계(815)에서 이 부분들을 전송을 위해 맵핑하기 위해 폴리시 파일 정보를 적용할 수 있다. 만약 사용자가 출력 장치를 지정했다면, 프록시는 전송하기 위한 다큐먼트 부분을 클라이언트 위치에 맵핑함에 있어서 이 정보를 충분히 참고할 것이다.

만약 단계(811)에서 결정된 것처럼 폴리시 파일이 존재하지 않는다면, 사용자에 대한 태그의 맵핑은 어떤 발견적 해결법(heuristic)을 이용해 프록시에 의해 발생되어야 한다. 모든 태그가 필연적으로 정의되지 않았으므로, 디폴트가 미디어 혹은 MIME 유형에 근거하여 태그를 전환시키려고 할 것이다. 이 경우는 HTML 다큐먼트가 세션 생성자에 의해 요구되는 경우와 동일하다. 실제, XML 다큐먼트가 폴리시 파일 참조를 갖고 있지 않다면, 이 XML 다큐먼트는 XSL 다큐먼트의 도움으로 HTML 다큐먼트로 변환되어야 할 것이다. 그렇지 않으면, 태그가 프록시에 대해 어떠한 것도 의미하지 않으므로, 어떠한 디멀티플렉싱도 행해질 수 없다. HTML 다큐먼트로는, 행해질 수 있는 유일한 분해(parsing)는 미디어 유형에 근거하므로, 영상 또는 오디오가 다큐먼트의 나머지로부터 분리되어, 이 상이한 미디어 유형을 상이한 장치들로 전송하기 위해 사용자에게 제공될 수 있다. 또한, 폴리시 파일의 부재시 및/또는 사용자의 특권 등급을 검증하기 위한 패스워드의 부재시, 오로지 하나의 디폴트 그룹만이 존재할 수 있다. 그러므로, 패스워드가 정의되지 않았으므로, 이 단일 특권 그룹에 대한 액세스는 개방된다. 따라서, 이 세션에 접속하는 어떠한 사용자도 액세스를 획득할 수 있으며, 오로지 자신의 장치에 대해 웹 콘텐츠의 미디어 유형 기반 분할을 선택하는 것만 가능할 것이다. 그러면 단계(816)에서 다큐먼트를 미디어 유형 다큐먼트 부분으로 분할하고, 단계(817)에서 전송을 위해 이 부분들을 사용자 장치 정보에 따라 클라이언트 출력 장치로 맵핑함에 있어서 프록시의 역할이 감소될 것이다.

프록시가 임의의 URL을 수신하면, 프록시는 새로운 세션이 설립되어야 하는지를 결정해야 한다. 이 개념은, 세션 생성자가 세션을 설립한 이후라도 세션 생성자는 프리젠테이션의 혹은 동일한 웹 사이트의 부분이 아닌 페이지를 자유롭게 브라우즈해야 한다는 것이다. 두 개의 사이트 혹은 두 개의 프리젠테이션의 차이는 그 페이지를 제작하는데 이용된 태그 즉, 그들이 참조하는 폴리시 파일이다. 사용자가 자신의 브라우저에게 임의의 웹 페이지 혹은 URL을 요구하면, 프록시는 원하는 페이지가 현재의 세션내에서 보여져야 하는지, 혹은 새로운 세션의 첫 번째 페이지로서 보여져야 하는지를 결정하는 것이 필요하다. 첫 째, 이 요구는 새로운 세션을 설립하고자 하는 세션 생성자로부터 유래될 수 있다. 두 번째, 이 요구는 단순히 현재의 세션내에 그 웹 페이지를 보여줄 것을 원하는, 이미 설립된 세션의 리더로부터 유리될 수 있다. 세 번째, 이 요구는 자신의 현재 세션을 중단하고 새로운 세션을 개시하고자 하는, 설립된 세션의 리더로부터 유래될 수 있다. 특히, 두 번째와 세 번째 가능성은 모호하여 프록시를 혼란시킬 수 있다. 이런 모호성은 다음에 설명되는 절차에 의해 해결된다.

프록시가 임의의 웹 페이지에 대한 요구를 수신할 때, 새로운 세션을 설립할 것인지를 결정하기 위해, 프록시는 폴리시 파일을 비교하는 것에 근거하는 절차를 이용한다. 만약 요구된 웹 페이지의 폴리시 파일이 세션을 설립하는데 이용된 첫 번째 웹 페이지의 초기 폴리시 파일과 일치한다면, 프록시는 웹 페이지를 동일한 브라우징 세션내에서 보여준다. 세션이 먼저 설립되면, 프록시는 첫 번째 페이지에 의해 참조되는 폴리시 파일의 명칭을 기억하고, 이 폴리시 파일(혹은 참조되는 폴리시 파일이 없다면, 빈 플레이스홀더(null placeholder))을 캐시한다. 동일한 초기 폴리시 파일을 참조하는 어떠한 이후의 웹 페이지는 캐시된 폴리시 파일의 특권 그룹과 태그명을 재사용할 것이고, 동일한 브라우징 세션내에 보여질 것이다. 만약 상이한 폴리시 파일이 액세스되거나 또는 요구된 웹 페이지에 대해 폴리시 파일이 존재하지 않아서, 두 개의 폴릿 파일사이에 불일치가 존재하게 되면, 프록시는 강제로 사용자에게 새로운 세션이 개방되어야 하는지를 묻는다. 모호성 문제는 요구 사용자가 미지의 요구된 웹 페이지가 현재의 세션내에 보여져야 하는지 혹은 새로운 세션을 설립하는데 이용되어야 하는지를 나타냄으로써 해결된다.

전술한 절차의 정의는 반복적인 것처럼 보일 수 있는데, 그 이유는 이것이 새로운 세션을 설립할 것인지 결정하기 위해 현재의 폴리시 파일을 현재 세션의 초기 폴리시 파일과 비교하기 때문이다. 만약 세션이 동일한 절차를 따라 설립되어 진다면, 초기 폴리시 파일에 의해 정의된 현재 세션이 어떻게 되는지에 대한 의문이 발생한다. 그 해결책은 어떤 세션들이 상이한 경로로 생성된다는 것이다. 전술한 바와 같이, 세션 개시에 관해 세 개의 선택안이 존재하는데, 이들중 뒤의 2개만이 모호성 문제를 일으킨다. 첫 번째 선택안의 경우(즉, 세션 생성자가 프록시에게 알려지지 않았고, 요구된 URL도 미지이다), 이것은 분명히 초기 폴리시 파일로 새로운 세션을 설립해야 하는 것이다. 세션 개시에 대한 첫 번째 선택안은 반복을 중단시키고, 새로운 세션의 설립을 이행(bootstrap)한다.

페이지 요구(page request;이 문단의 나머지 부분에서 "페이지 요구"라는 것은 초기 폴리시 파일과 일치하지 않는 폴리시 파일을 갖는 웹 페이지를 요구하는 것과 동일한 것임)가 행해진 후에 새로운 세션 설립에 대해 사용자에게 질의하는 다음의 방법이 싫다면, 페이지 요구가 행해지기 전에 사용자가 명확하게 프록시에게 알리는 이전의 방법을 이용할 수 밖에 없다. 종단 사용자는 요구한 다음의 URL이 새로운 세션을 설립하는데 이용되어야 함을 프록시에게 말한다. 그러나, 사전에 프록시에게 명확하게 알리는 것은 메시지를 발생하기 위한 클라이언트측 코드를 필요로 한다. 이것은 예를 들면 프록시와의 통신에 이용되는 제어에 포함된 애플릿 또는 웹 페이지의 프레임으로 제공될 수 있다. 제어 프레임을 삽입하도록 각각의 웹 페이지를 교정하는 것은 웹 페이지의 레이아웃을 변경시킬 위험을 수반한다. 프레임과 애플릿 지원은 특히 소형 스크린의 PDA인 경우 신뢰할 수 없다. 반대로, 페이지 요구를 행한 뒤에 새로운 세션을 설립할 것인지 사용자에게 물어보는 방법은 클라이언트측 코드는 필요로 하지 않지만, 브라우저에 의한 형식 지원은 필요로 하는데, 이것은 PDA에서 흔한 일이다. 웹 페이지는 수정되지 않고, 웹 브라우저와 사용자의 대화도 수정되지 않는데, 즉, 사용자는 계속해서 자신의 정규적인 대화, 포인팅 및 클릭킹, 혹은 새로운 URL의 입력을 행한다. 사용자에 대해 요구되는 모든 행위는 스크린 프롬프트로서 사용자에게 전송된다. 공동 작업 브라우징 프록시와의 대화는 사용자가 알고자 하는 모든 것이 스크린 프롬프트에 포함되도록 자동 안내된다. 반대로, 사전에 프록시에게 명확하게 알리는 방법에 따르면 공동 작업 웹 브라우징 프록시를 이용하기 위해서 사용자가 그들이 브라우저와 대화하는 방식을 변경할 필요가 있는데, 즉 사용자는 새로운 URL을 포인팅 및 클릭하기 전에 자신이 새로운 세션을 명쾌하게 요구해야 함을 알 필요가 있다. 이 방법은 사용자가 초기 폴리시 파일과 일치하지 않는 웹 페이지를 요구할 때마다 너무나 자주 팝업 메뉴(popup menus)를 귀찮게 하는 단점을 갖는다. 이러한 팝업 효과는 다중 웹 페이지에 적용하기 위해 폴리시 파일의 범주를 확대함으로써 완화될 수 있다. 또한, 팝업 질의는 이후에 논의하는 선택성 메카니즘을 이용하여 완전하게 억제될 수 있다. 이러한 선택성 메커니즘은 이전의 명확하게 알리는 방법과 같은 단점을 갖는데, 다시 말해서 어떻게 할 것인지 프록시와 대화하기 전에 사용자가 알고 있어야 하는 것을 필요로 한다.

페이지 요구 이후에 새로운 세션을 설립하는 것에 대해 사용자에게 질의하는 이후의 방법은 세션 리더가 세션 설립 질의를 억제할 수 있게 하는 선택성 메커니즘과 함께 고려될 수 있다. 이것은 초기 폴리시 파일의 범주 밖의 많은 웹 페이지를 액세스하는 세션 리더에게 전송되는 세션 설립 질의의 빈도를 최소화시키는데 유용할 것이다. 한 가지 해결책은 세션 설립 질의를 명확하게 억제하거나 가능하게 하는 온/오프 버튼 혹은 체크 박스(check box)를 제공하는 것이다. 체크 박스가 세션 설립 문의를 억제하도록 설정되어 있는 브라우징 세션 동안에, 세션 리더는 프리젠테이션 동안 반복되는 질의로 괴롭힘을 당하지 않는다. 물론, 이러한 질의들이 억제되는 동안에는 세션 리더가 새로운 세션을 설립할 수 없을 것이다. 초기 폴리시파일의 범주 밖의 웹 페이지에 대한 각각의 요구는 현재의 브라우징 세션내에 웹 페이지를 보여주는 요구로 가정될 것이다. Undefined_tags 메커니즘은 미지의 혹은 누락된 폴리시 파일을 무효화할 것이다. 일단 질의가 다시 활동 가능 상태로 되면, 세션 리더는 초기 폴리시 파일의 범주 밖의 웹 페이지를 요구할 수 있으며, 새로운 세션을 설립하는 것에 대해 질의될 것이다. 이러한 온/오프 기능은, 브라우저가 보안 웹 페이지와 마주칠 때 종종 나타나는 팝업 메뉴를 억제하는 것과 유사하며, 브라우저로 다운로드되는 사용자 커스텀화 애플릿으로 포함될 수 있다. 만약 세션 리더의 브라우저가 다운로드 가능한 애플릿 또는 클라이언트측 커스텀화 코드를 지원하지 않는다면, 디폴트 설정이 질의를 활동가능하게 하기 위해 설정되어야 한다. 질의의 명확한 억제는 이후의 세션 설립 메커니즘에 대해 상보적이므로, 공동 작업 웹 브라우징의 올바른 기능에 절대적으로 필요한 것은 아니다.

도 9는 URL이 수신될 때 세션 설립을 결정하기 위해 프록시에 의해 이용되는 최종 알고리즘을 요약하는 의사 코드(psuedo-code)를 제공한다. 이 알고리즘은 고려해야 할 여러가지 특별한 경우 때문에 이전에 대충 설명한 것보다 더 복잡하다. 도 9에서, "Current policy file"은 현재 등록된 웹 페이지/URL와 연관된 폴리시 파일을 말한다. "Show page within existing session"은 요구된 페이지상에 기초하여 새로운 세션을 설립하라는 것이 아니라, 요구된 웹 페이지를 현재 브라우징 세션의 모든 가입자에게 전송할 것을 의미한다.

이 단계에서, 프록시는 요구된 웹 페이지에 대해 새로운 세션을 구성해야 하는지 혹은 하지 말아야 하는지 안다. 그러므로, 프록시는 새로운 세션을 개시하기 위해 다음의 사용자 로그인 단계로 진행하던지, 혹은 이 단계를 건너 뛰고 그냥 요구된 웹 페이지를 공동 작업 브라우징 세션의 가입자에게 단순히 전송할 것이다.

도 10은 전술한 단계(807)의 "사용자 정리"를 수행하기 위해 프록시가 구성하는 커스텀화된 로그인 페이지를 도시한다. 프록시는 이 로그인 페이지에 모든 가능한 특권 그룹의 리스트를 포함하여, 사용자가 이들중에 자신이 속한 곳을 선택하도록 할 필요가 있다. 프록시가 이 페이지를 동적으로 구성한 이후, 이것은 이제 세션 생성자라고 불리우는 사용자에게 전송된다. 세션 생성자에게 전송된 하이퍼텍스트 HTML/XML 로그인 인터페이스는 도 10에 되시되어 있다. 이 인터페이스는 합성식으로, 인터페이스내의 모든 필드가 각 세션 생성자에게 보여지는 것은 아니다 프록시는 로그인 프로세스에 의해 제공되는 패스워드를 이용하여 세션 생성자를 특권 그룹으로 분류할 것이며, 사용자명을 이용하여 이 세션 개시자의 등록된 출력 장치를 SDDB에게 질의할 것이다.

로그인 페이지는 세션 설립과 관련한 다음의 조건중 하나에서 세션 생성자에게 전송되는데, 즉, (조건 ⅰ) 사용자가 프록시에 알려지지 않은 경우, 또는 (조건 ⅱ) 사용자가 프록시에게 알려지고(가입자가 진행중인 세션에 알려짐), 이 사용자가 자신이 가입되어 있는 현재 진행중인 세션의 초기 폴리시 파일과 일치하지 않는 폴리시 파일과 함께 URL을 요구하여, 새로운 세션을 설립할 것인지 묻는 프록시로부터의 질문에 대해 "예"라고 응답한 경우, 이런 경우들에 대해서는 새로운 세션을 설립한다. 비록 도 8의 알고리즘이 세션 설립동안에 초기 폴리시 파일이 존재하느냐 혹은 존재하지 않느냐를 구별하더라도, (조건 ⅱ)는 보편성을 잃지 않고 그 차이점을 무시할 수 있으며, 이 두가지 사항을 하나로 묶을 수 있다. 로그인 페이지는 세션을 설립하는데 어떤 조건 세트가 이용되느냐에 따라 변할 것이다.

세션 생성자는 로그인 페이지의 모양과 느낌에 영향을 미치는 세 가지 추가 가능성과 만날 것이다. 즉, (조건 a) 현재의 폴리시 파일이 요구된 웹 페이지에 의해 참조되고, 모든 특권 그룹에 대해 패스워드를 정의하는 경우, (조건 b) 현재의 폴리시 파일이 참조는 되지만 어떤 특권 그룹에 대해 패스워드를 정의하지 않는 경우, (조건 c) 웹 페이지가 현재 폴리시 파일에 대한 참조를 포함하지 않는 경우,

로그인 페이지의 첫 번째 필드는 세션 생성자에게 질문하여 그들 사용자명을 식별하는 것이다. 이 필드는 세션 생성자가 프록시에 대해 신규일 때(조건 ⅰ), 절대적으로 필요하고, 세션 생성자가 현재 진행중인 브라우징 세션의 일원일 때, 다시 말해서 이 세션 생성자의 신원을 이미 알고 있을 때(조건 ⅱ)에는, 기술적으로 요구되지 않는다. 조건 ⅰ이면, 프록시가 세션 개시자의 사용자명을 알 필요가 있는데, 이것은 세션 생성자와 그 사용자명으로 SDDB에 등록된 출력 장치를 일치시키기 위해서이다. 제공된 사용자명은 세션 생성자의 장치와 함께 등록되어 있던 그 사용자명과 동일해야 한다. 만약 사용자명이 다르면, 프록시는 장치를 그들의 소유자와 연관시킬 수 없을 것이다. 조건 ⅱ이면, 프록시는 사용자명 필드 전송에 대해 선택권을 갖는다. 본 발명자의 현재 의도는, 비록 프록시가 이미 세션 개시자의 과거 사용자명을 알고 있을지라도, 이 필드를 보여주는 것이다. 세션 생성자가 과거의 세션은 그냥 놔두고 새로운 세션을 설립하기 위해 신원을 변경시키고자 하는 경우도 있을 수 있을 것이다. 물론, 이 세션 생성자는 새로운 사용자명 하에서 자신이 소유한 장치를 재등록해야 할 것이다.

두 번째 필드는 사용자에게 패스워드를 대신할 수 있는 어떤 것을 제공하라고 요청하는 것으로, 이렇게 함으로써 프록시는 세션 생성자가 속할 특권 그룹을 식별할 수 있다. 패스워드르 대신할 수 있는 것은 조건 a, b, c에 따라 변할 것이다. 만약 현재의 폴리시 파일에 정의된 모든 특권 그룹에 액세스하는 것이 패스워드에 의해 보호된다면(조건 a), 로그인 페이지는 패스워드 필드를 보여야만 할 것이다. 그러나, 만약 어떤 특권 그룹이 패스워드에 의해 액세스 보호되지 않는다면(조건 b), 로그인 페이지는 패스워드 필드와 비 패스워드 보호형 공공 특권 그룹 리스트(list of non-password-protected public privilege groups)의 혼성 문(hybrid)을 제공할 것이다. 이러한 혼성문 시나리오의 일 예가 도 10에 도시되어 있는데, 여기에서 슬라이드 프리젠테이션을 위한 공공 특권 그룹 "강사"와 "학생"은 패스워드로 보호되지 않으며, 적어도 하나의 다른 사적 특권 그룹은 패스워드 엔트리를 요구한다. 만약 세션 생성자가 비 패스워드 보호형 그룹의 멤버로 접속하기 원한다면, 세션 생성자는 원하는 공공 그룹의 박스를 단순히 체크하기만하면 된다. 그렇지 않으면, 세션 생성자가 적절한 패스워드를 입력한다. 마지막으로, 요구된 웹 페이지와 연관된 현재의 폴리시 파일이 없다면(조건 c), 프록시는 단지 하나의 공공 특권 그룹만을 생성한다. 결과적으로, 단 하나의 특권그룹이 체크박스로 리스트되고, 패스워드 필드는 보여지지 않는다.

패스워드가 예컨대 슬라이드 프리젠테이션의 첫 번째 웹 페이지의 작성자로부터의 e-메일 같은 어떠한 결합외 방법으로 사전에 세션 생성자에게 알려졌다고 가정하자. 그러나, 모든 청중 멤버가 항상 사전에 알 수는 없으므로, 사전 패스워드 분배가 항상 가정되는 것은 아니다. 예를 들어, 현재 진행중인 브라우징 세션에 가입하고자 하는 어떤 학생이 자신의 패스워드를 잊어버릴 수도 있고, 패스워드를 수신하지 못했을 수도 있으며, 또는 새로 가입하는 신규 멤버일 수도 있다. 이러한 예에서, 공공 비 패스워드 보호형 특권 그룹에 대한 지원은 모든 가입자에게 패스워드를 알릴 필요없이 이런 학생들도 쉽게 현재 진행중인 브라우징 세션에 접속하게 해준다.

세 번째 필드는 세션 생성자가 세션을 사적인 것으로 혹은 자신을 단일 사용자로 유지하고 싶은지를 체크할 수 있는 박스이다. 이 박스가 체크되면, 세션은 SDDB에 공시되지 않는다. 이 경우, 세션 생성자는 우리 프록시의 다중 장치 능력의 이점은 취하고자 원하지만, 공동 작업 특징은 취하고 싶어하지 않는다. 요구된 웹 페이지에 의한 폴리시 파일에 대한 참조(조건 a 및 b)가 공공 공동 작업 세션이 설정되어야 함을 의미하는 것처럼 보일지라도, 이 폴리시 파일의 존재가 반드시 새로운 세션을 공공 혹은 공동 작업용으로 만들도록 제한하지 않는 것이 바람직하다. 요구된 웹 페이지가 폴리시 파일을 참조하느냐의 여부와 무관하게 세션 생성자가 세션의 성질을 공공/사적으로 결정할 수 있는 완전한 융통성이 제공된다.

네 번째 필드는, 세션 생성자가 다음의 웹 브라우징 세션동안 새로운 세션을 형성할 것인지 묻는 모든 질의들을 즉시 억제하기를 원할 경우에 이 세션 생성자가 체크할 수 있는 박스이다. 이러한 질의는 조건 ⅱ가 참(true)의 값을 가질 때, 다시 말해서, 세션 리더가 세션 설립에 이용되는 초기 폴리시 파일과 다른 폴리시 파일을 갖는 다양한 웹 사이트를 방문할 때 발생된다. 초기 폴리시 파일의 범주 밖으로 자주 벗어나는 사용자가 반복되는 질의를 억제하도록 하기 위해 로그인 페이지에 선택권이 부여된다. 사용자는 로그인 형식을 채우고 그것을 프록시에게 제출한다.

데이터 푸시 프로세스는 이 단계에서 개시된다. 넷스케이프와 IE의 경우, 데이터 푸시는 클라이언트 머신에 다운로드된 애플릿을 이용할 것이다. 이 애플릿은 로그인 페이지가 사용자에게 전송될 때 다운로드되는데, 즉, 이것은 이 때부터 프록시가 브라우저로 데이터를 푸시할 수 있음을 의미한다.

이제 프록시는 세션이 설립됨을 알고 있으므로(세션 생성자가 이 세션을 설립하도록 허용되었음), 프록시는 서비스 디스커버리에 등록하여 그 사실을 알리고, 사람들은 접속할 수 있게 된다. 프록시는 이 세션을 서비스 디스커버리에 등록하기 위해 폴리시 파일에 포함된 정보를 이용한다. 프록시는 등록하여 URL을 액세스 모드로 제공한다. 이것은 이 세션에 대한 특권 그룹의 리스트를 지정하는 폴리시 파일로부터 구성되어 사용자의 패스워드와 이름을 묻는 동적인 로그인 페이지의 URL이다(도 10 참조). 서비스 디스커버리 데이터베이스에 등록하는데 이용되는 API 기능 호출은 다음과 같을 것이다(지정되는 호출은 선택되는 프로토콜에 따라 좌우될 것이다).

여기에서, name은 세션을 식별하고(예를 들면, 프록시를 트랜스코딩하기), access_url은 등록을 위해 프록시에 의해 생성되는 형식의 url이고, proxy_@는 세션을 호스팅하는 프록시의 어드레스이다.

이 단계에서, 서비스 디스커버리는 세션을 방안에서 이용할 수 있는 서비스로, 그리고 종단 사용자가 접속할 수 있는 것으로 개재할 것이다. 이 등록된 세션은 도 6에서 SDDB의 우측에 표의 우측 컬럼에 나타난다.

서비스 디스커버리는 등록된 세션을 "비공개(unannounce)"하는 능력을 허용해야 한다. 예를 들어, 사용자가 "사적인 세션을 원함(want private session)"을 클릭하면, 세션은 SDDB에서 세션 리스트를 제거해야 한다.

또한 프록시는 사용자에 의해 등록된 장치상에서 정보를 검색한다. 특히, 사용자가 세션을 설립하기 위해 이용하는 장치의 액세스 모드를 알 필요가 있다. 이 경우 액세스 모드는 세션 생성자가 이용중인 브라우저의 유형일 것이다(IE, Netscape, Pdcket IE). 프록시는 이 정보를 이용해서 자신이 사용자에게 전송해야 하는 데이터의 포맷을 안다. 예를 들어, IE 5 브라우저인 경우에는, IE 5가 XML 가능형이므로 프록시가 XML 다큐먼트를 곧장 전송할 수 있는 반면, 만약 Netscape이면, Netscape의 현재 이용 가능한 버전이 XML을 이해하지 못하므로,프록시는 HTML 다큐먼트를 생성해야 할 것이다.

프록시는 방안에서 이용가능한 공공 인프라스트럭처와 더불어 사용자가 소유한 장치에 대해 알 필요가 있다. 프록시는 이 정보를 이용하여, 사용자가 더 상세한 데이터 분할을 선택할 수 있도록 커스텀화 형식을 설계하고, 그렇게 함으로써 사용자는 자신이 볼 수 있게 허용된 것의 각 부분을 어떤 출력 장치로 전송할 것인지 선정할 것이다. 이러한 장치의 각각과 관련하여, 프록시는 그 장치로 어떻게 데이터를 전송할 것인지 알 필요가 있다. 예를 들어, 프록시가 이 종단 장치에게 mpeg 피일을 전송할 수 없을 것이라고 규칙 파일이 말할 것같으면, 사용자는 Palm Pilot^*을 이용하여 프록시와 통신할 수 있다. 그러나 프록시가 SDDB에게 질의하면, SDDB는 이 방안에 누구든지 이용할 수 있는 공공 디스플레이가 있다고 리턴한다. 그러면 프록시는 어디의 mpeg 태그가 공공 디스플레이와 연관될 수 있는 커스텀화 형식을 구성할 수 있다. 또한 SDDB는 예컨대 데이터 스트림을 기대하고 있는지 혹은 mpeg 파일을 기대하고 있는지 등등의 디스플레이에 액세스하는 방법도 전송해야 한다.

일단 프록시가 이 "세션"에 대해 알게 되면, 이 세션과 연관된 태그, 이 세션과 연관된 그룹, 그룹에 대한 태그의 디폴트 맵핑(더 엄밀하게 말하면, 각 그룹내의 소프트웨어/하드웨어 장치에 대한 태그의 디폴트 맵핑)이 알려진다. 또한 프록시는 세션을 SDDB에게 알리고, 로그온된 하나의 사용자 즉 세션 생성자가 있음을 알린다. 다음, 프록시는 개별 사용자와, 각 사용자가 속한 그룹과, 각 사용자와 연관된 장치를 찾아낼 것이다.

프록시는 원래 다큐먼트의 어떤 서브셋(어떤 태그)이 세션 생성자에 의해 수신될 수 있는지를 안다(세션 생성자의 특권 그룹과 그 사람이 이용중인 장치가 알려지면). 그러므로 프록시는 이 사용자에 대해 커스텀화된 XSL 변환 파일을 구성할 수 있다. 이 파일은 원래의 XML 파일로부터 사용자가 수신 허용되고 사용자가 수신할 수 있는 태그만을 선택할 것이다. 다음, 어떤 종단 사용자가 다큐먼트의 목적지인지에 따라서, HTML로 변환되거나 혹은 종단 사용자에게 곧장 전송된다. 전술한 바와 같이, 이용될 포맷은 사용자의 장치의 디스커버리동안에 알려진다. 이 시점에서, 프록시는 사용자가 볼 수 있게 허용된 부분 뷰를 전송할 수 있다.

설립된 세션에 접속하기

도 7에 도시된 프로세스 흐름도의 단계(740)는 설립된 세션에 접속하는 신규 사용자 및/또는 장치에 관한 것이다. 이 접속 프로세스는 다음의 다섯 단계를 포함한다. 단계(1100)에서, 각각의 신규 클라이언트 위치/사용자가 서비스 디스커버리 데이터베이스에 등록하고, 현재의 브라우징 세션의 리스트를 검색한다. 사용자가 세션이 진행중인 방으로 들어오거나 원격 강의에 접속하고자 하면, 사용자는 먼저 자신이 소유한 모든 장치를 서비스 디스커버리에 등록해야 한다. 다음, 사용자는 이용 가능한 서비스의 리스트를 서비스 디스커버리 데이터베이스에서 검색한다. 프록시의 예시적인 리스트와 그들이 지원하는 세션이 도 6에 도시되어 있다. 프록시마다 다중 세션이 존재할 수도 있다.

다음, 단계(1102)에서, 신규 가입자는 현재 진행중인 공동 작업 브라우징 세션중 하나에 접속 혹은 가입을 요구할 수 있다. 사용자는, 사용자가 원하는 세션을 수작업으로 선택할 수 있도록 하기 위해 디스플레이되는 진행 세션의 리스트를 수신한다. 제공되는 각각의 세션 레코드는 3개의 세션 정보 부분으로 이루어지는데, 다시 말해서 프록시 IP, 프록시 포트 번호, 세션의 URL로 이루어진다. 상기 세션 레코드의 정보는 수동이나 혹은 자동 방법으로 서비스 디스커버리 인터페이스에서 사용자 브라우저로 전송되어야 한다. 사용자는 (위에서 처럼 프록시 대신에) 리스트에서 세션을 선택한다. 만약 브라우저가 프록시 파라미터의 자동 설정과 세션 URL의 자동 페칭을 지원한다면, 사용자의 세션명 클릭에 대한 응답으로 브라우저 프로세스를 개시하여, 프록시 파라미터 필드를 초기화하고 브라우저에게 세션의 URL을 페치할 것을 요구한다. 만약 브라우저가 자동 전송을 지원하지 않는다면, 사용자는 수작업으로 브라우저를 시작하여, 브라우저의 프록시 파라미터 필드를 설정한 뒤, 세션을 URL을 타이프하여 입력한다.

프록시에서 모든 URL 요구는 가로채기(intercepted)되며, 요구된 URL과 함께 이 URL 요구가 도달되는 포트 번호에 근거하여, 프록시는 요구자에게 현재 세션에 접속할 것인지, 어떤 세션을 원하는지를 확인할 수 있다. 만약 그 요구가 접속 요구인 것으로 판명되면, 그세션을 위한 적절한 로그인 페이지가 사용자에게 전송된다.

단계(1103)에서, 프록시는 로그인 메뉴를 사용자명과 패스워드를 요구하는각각의 잠재 가입자에게 전송한다. 로그인 메뉴는 종단 사용자에게 전송된다. 이 로그인 메뉴는 도 10의 것과 비슷한데, 이제부터 가입자라고 불리우는 사용자가 세션을 사적인 것으로 유지할 수 있는 체크박스 선택권을 갖지 않는다는 것만이 다르다. 사용자는 그 밖의 다른 필드는 이용 가능하며, 사용자명을 입력하고, 패스워드를 입력하든지 혹은 특권 그룹을 클릭해야 한다. 세션에 접속하는 것이 세션을 설립하는 것보다 더 적은 수의 단계를 거치는데, 그 이유는 세션에 접속하는 것은 세션 설립 메뉴 및, 첫 번째 XML 페이지와 폴리시 파일의 다운로딩을 건너뛰기 때문이다. 세션 설립 프로세스 흐름에 따라 데이터 푸시 애플릿이 다운로드되어 클라이언트내에서 초기화된다.

단계(1104)에서, 사용자가 공동 작업 세션에 접속하도록 허가되었는지를 프록시가 판정하면, 프록시는 단계(1105)에서 서비스 디스커버리 데이터베이스에 요구를 전송한다. 서비스 디스커버리 데이터베이스에 대한 요구는 신규로 로그인된 사용자에 대해 등록된 모든 장치의 리스트를 요청한다. 프록시가 신규 로그인된 사용자에게 그 정보를 질의할 수도 있지만, 전술한 바와 같이, 이미 서비스 디스커버리 데이터베이스에 기억되어 있는 이용가능한 사용자 장치 정보를 활용하는 것이 바람직하다. 이전에 상세히 설명된 세션 설립 프로세스에서 처럼, 이 단계는 신규 가입자에 대해 등록된 모든 장치의 리스트를 검색하는 태스크를 포함하지만, 세션 접속 프로세스 흐름의 경우에 있어서는, 세션을 서비스 디스커버리에 알릴 필요가 없다.

마지막으로, 단계(1106)에서, 프록시는 웹 페이지의 적절한 부분 뷰(즉, 다큐먼트 부분(들))를 하나 이상의 사용자 장치에서의 디스플레이를 위해 신규 로그인된 사용자에게 리턴시킨다. 웹 페이지의 부분 뷰는 신규 가입자뿐만 아니라 세션 생성자에게고 풀(pulled)되는데, 그 이유는 이들 모두가 자신의 로그인 입력때문에 프록시로부터 응답을 되돌려 받기를 기다리고 있기 때문이다. 또한, 신규 가입자와 세션 생성자는 둘다 입력 허가된 세션의 다른 멤버에 의해 개시된 이벤트(events)를 푸시(push)하도록 응답할 수 있는 애플릿을 다운로드받는다. 다른 멤버가 새로운 페이지를 요구하면, 프록시는 이 갱신을 세션 멤버의 디스플레이에 푸시하거나, 혹은 가입된 종단 장치(스피커 등)에게 새로운 데이터를 전송한다.

종단 장치가 브라우저인 경우, 데이터를 푸시하는데 어떤 방법이 이용되는지 결정하기 위해 브라우저의 유형을 아는 것이 반드시 필요하다. 등록시, HTTP 헤더의 User-Agent 필드를 완성함으로써 프록시는 어떤 종단 사용자가 어떤 브라우저 유형을 이용중인지 안다. 다음, 프록시는 브라우저 유형에 따라 데이터 푸시를 어떻게 개시할지 안다. 무 브라우저 장치(non-browser devices)인 경우, 서비스 디스커버리에 의해 리턴된 정보는 이들 장치에 액세스하는 방법을 프록시에게 직접 말해주거나, 혹은 종단 장치와 어떻게 통신할 수 있는지를 알 수 있는 방법을 제공해야 한다.

서브 다큐먼트 대 장치 맵핑(sub-document to Device Mapping)

가입자가 설립된 세션에 접속한 후, 혹은 세션 생성자가 세션 설립을 완료한 후, 세션의 각 참가자는 사용자 개인 취향에 따라 태그 대 장치 맵핑을 구상할 수 있다. 프록시는 초기에 폴리시 파일에 의해 제공된 정보를 이용해, 허용된 태그 대 허용된 출력 장치의 디폴트 맵핑을 구성한다. 그러나, 이 디폴트 맵핑이 종단 사용자를 만족시키지 못할 수도 있고, 도 7의 상세한 프로세스 흐름도의 단계(760)을 참조하여 전술한 것처럼, 세션 생성자가 도쿠먼트 부분 대 출력 장치의 맵핑을 동적으로 변경하고자 할 수도 있다. 세션 생성자는 자신의 장치상에서 자신을 위해 생성된 디폴트 설정을 볼 수 있고, 어떤 태그가 어떤 장치에게 가야하는지를 결정함으로써 더 세밀하게 커스텀화하기를 원하는지 결정할 수 있다. 프록시에 의해 행해진 디폴트 구성은, 예를 들면, 세션 개시 장치가 보여줄 수 있는 태그만을 전송할 수도 있는데, 이것은 소형 장치의 경우에는 무리한 일이 될 수 있다. 그 결과, 세션 생성자는 자신에게 더 편리하게 데이터를 분할하는 개인화 형식(personalization form)을 이용할 것이다.

개인화 버튼은 로그아웃 버튼과 함께 제어 패널상에 위치될 수 있다. 사용자는 브라우저 윈도우상에서 세션을 개시할 것이지만, 프록시가 부분 뷰를 사용자에게 전송할 준비가 되면, 자식 윈도우(child window)에서 이것을 행할 것이다. 사용자는 부모 윈도우(parent window)에게 제어 패널을 전송할 것인데, 사용자는 두 개의 윈도우를 갖고 있는데, 하나는 다음의 브라우징 세션을 위한 것이고, 또 하나는 제어 윈도우를 위한 것이다. 제어 패널은 사용자가 세션으로부터 로그아웃하도록 하는 버튼을 포함하고 있을 것이다. 제어 로그아웃 버튼의 사용자 신청은, 프록시가 그 사용자를 리스트에서 제거하고 그에게 제공되는 모든 변환 파일을 삭제하라는 것을 말한다. 또한 제어 패널은 개인화용 버튼도 포함하는데, 이로써 사용자가 현재의 설정에 만족하지 못하면 개인화 형식을 요구할 수 있으며 태그와 장치 간의 결합(associations)을 변경할 수 있다.

사용자가 "커스텀화" 버튼을 클릭하면, 프록시가 접촉하여 세 번째 정보 스크린을 리턴시킨다. 프록시는 허용된 멀티미디어 태그 대 허용된 출력 장치의 맵핑을 생성하는데 필요한 모든 정보를 갖고 있다. 태그는 XML 파일로부터 취해진다. 사용자 신원과 그 사용자가 연관된 그룹은 사용자 로그인/등록으로부터 취해진다. 이용가능한 장치와 그 소유자의 리스트는 서비스 디스커버리로부터 취해진다. 이것은 프록시가 허용된 태그 대 허용된 장치의 맵핑을 구성할 수 있도록 해준다. 이러한 맵핑은 "커스텀화" 버튼이 클릭될 때 종단 사용자에게 노출되며, 사용자는 리스트에 있는 적절한 장치에 대해 단순히 태그를 "풀(pull)"하기만 하면 맵핑을 변경할 수 있을 것이다.

일반적으로, 사용자는 세션에 로깅하기 전에 다중 장치를 등록한다. 그러나, 사용자가 로그인한 후에 장치를 추가하고 싶을 수도 있다. 이 경우, SDDB에 등록한 후, 새로운 장치는 자동적으로 미디어 공급을 수신하기 시작할 것이고, 애플릿은 자동적으로 갱신될 것이다. 선택 사항으로서 callback() 기능을 이용하는 것이 있다. 콜백(callback)이란, 주어진 사용자명과 일치하는 사용자가 어떤 새로운 장치를 등록하고자 하는지를 서비스 디스커버리가 프록시에게 알리거나 통지하는 것을 말한다(UNIX에서 select()와 유사함). 프록시와 클라이언트 간의 푸시/풀 문제와 비슷하게, 콜백은 서비스 디스커버리가 프록시에 대한 새로운 갱신을 푸시하는 것을 허용한다. 콜백은 효율적인 메커니즘으로, 각 사용자에 대한 프록시 상태의 자동 갱신을 가능하게 한다. 그러나, 콜백은 서비스 디스커버리에 대해 기능적으로 부담을 주며, 대부분의 혹은 어떤 경우에는 일부의 서비스 디스커버리 프로토콜 전체에서 지원되지 않을 수도 있다.

또다른 선택 사항으로서, 종단 사용자에 의해 수신된 커스텀화 스크린상의 "리프레시(refresh)" 버튼을 통해 수동 갱신을 하는 것이 있다. 그러나, 만약 종단 사용자가 커스텀화 스크린을 잠시 개방했는데 그 스크린이 갱신되지 않았다면, 커스텀화 스크린상에 "리프레시" 버튼을 또 포함하는 것이 필요하다. 커스텀화 스크린상의 리프레시 버튼은 첫 번째 스크린상의 커스텀화 버튼과 연계하여 콜백 기능의 필요성을 없애준다. 대신에, 새로운 장치가 추가될 때 종단 사용자는 프록시 상태(그리고 커스텀화 스크린)의 갱신을 수작업으로 개시한다. 종단 사용자는 반드시 서비스 디스커버리로부터 그 사용자에 대해 새로 등록된 장치에 대응하는 데이터를 프록시를 통해 커스텀화 스크린상으로 풀(pulls)해야 한다.

본 발명이 몇 가지 바람직한 실시예를 참조하여 설명되었을지라도, 당업자라면, 첨부된 특허청구범위에 설정된 본 발명의 사상과 범주를 벗어나지 않으면서 세부적인 시스템 및 방법을 수정할 수 있음을 이해할 것이다.

따라서, 본 발명에 따르면, 단말 사용자가 어떤 장치가 웹 콘텐츠를 수신할 것인지 선정할 수 있게 되고, 웹 콘텐츠를 디스플레이하기 위해 공동 작업할 몇몇 장치도 선택할 수 있게 되어, 단말 사용자가 요구 장치의 제한된 성능을 극복할 수있게 된다.

Claims (32)

1. 서버로부터 다수의 클라이언트 위치(location)로 다큐먼트 콘텐츠를 선택적으로 제공하는 방법에 있어서,

   서버로부터 프록시(proxy)로 적어도 하나의 다큐먼트(document)를 제공하는 단계와,

   상기 적어도 하나의 다큐먼트를 하나 이상의 다큐먼트 부분(document portions)으로 선택적으로 분할하는 단계와,

   상기 하나 이상의 다큐먼트 부분 중 적어도 하나를 상기 다수의 클라이언트 위치의 각각에 선택적으로 제공하는 단계를 포함하는

   다큐먼트 콘텐츠를 선택적으로 제공하는 방법.
2. 제 1 항에 있어서,

   상기 적어도 하나의 다큐먼트는 적어도 하나의 다른 파일로의 링크(link)를 포함하고,

   상기 프록시가 상기 적어도 하나의 다른 파일을 프리페칭(prefetching)하고, 상기 적어도 하나의 다른 파일을 캐싱(caching)하는 단계를 더 포함하는

   다큐먼트 콘텐츠를 선택적으로 제공하는 방법.
3. 제 1 항에 있어서,

   상기 프록시가 상기 적어도 하나의 다큐먼트가 연관 폴리시 파일(an associated policy file)을 갖는지 판정하는 단계와,

   상기 폴리시 파일을 액세스하는 단계를 더 포함하는

   다큐먼트 콘텐츠를 선택적으로 제공하는 방법.
4. 제 3 항에 있어서,

   상기 선택적 분할 단계는,

   상기 다큐먼트를 상기 폴리시 파일에 따라 다큐먼트 부분으로 분할하는 단계를 포함하는

   다큐먼트 콘텐츠를 선택적으로 제공하는 방법.
5. 제 4 항에 있어서,

   상기 폴리시 파일은 클라이언트 액세스 정보를 나타내며,

   상기 선택적 제공 단계는,

   상기 클라이언트 액세스 정보에 따라 다큐먼트 부분을 클라이언트 위치로 보내는 단계를 포함하는

   다큐먼트 콘텐츠를 선택적으로 제공하는 방법.
6. 제 5 항에 있어서,

   상기 다큐먼트 부분을 선택적으로 제공하는 단계는,

   상기 다큐먼트 부분의 전부보다 적은 다큐먼트 부분(less than all of said document portions)을 상기 다수의 클라이언트 위치중 적어도 하나로 보내는 단계를 포함하는

   다큐먼트 콘텐츠를 선택적으로 제공하는 방법.
7. 제 1 항에 있어서,

   상기 다수의 클라이언트 위치는 하나의 클라이언트 위치에서 콘텐츠를 출력하기 위한 다수의 장치를 포함하는

   다큐먼트 콘텐츠를 선택적으로 제공하는 방법.
8. 제 7 항에 있어서,

   상기 프록시가 상기 다수의 장치의 각각의 콘텐츠 출력 능력을 판정하는 단계를 더 포함하는

   다큐먼트 콘텐츠를 선택적으로 제공하는 방법.
9. 제 7 항에 있어서,

   상기 클라이언트 위치에 관한 서비스 디스커버리(service discovery)를 작성하는 단계와,

   상기 클라이언트 위치에 대한 서비스 파일을 생성하는 단계를 더 포함하는

   다큐먼트 콘텐츠를 선택적으로 제공하는 방법.
10. 제 9 항에 있어서,

    상시 작성 및 생성 단계는 상기 프록시에서 실행되는

    다큐먼트 콘텐츠를 선택적으로 제공하는 방법.
11. 제 9 항에 있어서,

    상기 프록시가 상기 서비스 파일을 액세스하는 단계를 더 포함하는

    다큐먼트 콘텐츠를 선택적으로 제공하는 방법.
12. 제 8 항에 있어서,

    상기 선택적 분할 단계는,

    상기 콘텐츠 출력 능력에 따라 상기 다큐먼트를 다큐먼트 부분으로 분할하는 단계를 포함하는

    다큐먼트 콘텐츠를 선택적으로 제공하는 방법.
13. 제 11 항에 있어서,

    상기 선택적 분할 단계는

    상기 서비스 파일에 따라 상기 다큐먼트를 다큐먼트 부분으로 분할하는 단계를 포함하는

    다큐먼트 콘텐츠를 선택적으로 제공하는 방법.
14. 제 7 항에 있어서,

    상기 프록시가 상기 다큐먼트 부분을 상기 다수의 장치로 맵핑(mapping)하는 단계를 더 포함하는

    다큐먼트 콘텐츠를 선택적으로 제공하는 방법.
15. 제 14 항에 있어서,

    상기 클라이언트 위치의 사용자가 상기 맵핑을 동적으로 변경하는 단계를 더 포함하는

    다큐먼트 콘텐츠를 선택적으로 제공하는 방법.
16. 제 1 항에 있어서,

    상기 프록시가 상기 하나 이상의 다큐먼트 부분 중 적어도 하나를 트랜스코딩(transcoding)하는 단계를 더 포함하는

    다큐먼트 콘텐츠를 선택적으로 제공하는 방법.
17. 제 12 항에 있어서,

    상기 프록시가 상기 콘텐츠 출력 능력에 따라 상기 하나 이상의 다큐먼트 부분 중 적어도 하나를 트랜스코딩하는 단계를 더 포함하는

    다큐먼트 콘텐츠를 선택적으로 제공하는 방법.
18. 제 1 항에 있어서,

    적어도 하나의 다큐먼트를 생성하는 단계와,

    상기 적어도 하나의 다큐먼트를 상기 서버에 기억하는 단계를 더 포함하는

    다큐먼트 콘텐츠를 선택적으로 제공하는 방법.
19. 제 18 항에 있어서,

    상기 적어도 하나의 다큐먼트에 대해 적어도 하나의 폴리시 파일을 정의하는 단계와,

    상기 적어도 하나의 폴리시 파일을 상기 다큐먼트의 적어도 하나와 연관시키는 단계를 포함하는

    다큐먼트 콘텐츠를 선택적으로 제공하는 방법.
20. 제 19 항에 있어서,

    상기 연관 단계는,

    상기 폴리시 파일을 상기 적어도 하나의 다큐먼트에 병합(incorporating)하는 단계를 포함하는

    다큐먼트 콘텐츠를 선택적으로 제공하는 방법.
21. 제 19 항에 있어서,

    상기 적어도 하나의 폴리시 파일 정의 단계는

    상기 적어도 하나의 다큐먼트에 대해 다수의 다큐먼트 부분을 지정하는 단계를 포함하는

    다큐먼트 콘텐츠를 선택적으로 제공하는 방법.
22. 제 21 항에 있어서,

    상기 다수의 다큐먼트 부분의 각각에 대해 액세스 규칙을 설립하는 단계를 더 포함하는

    다큐먼트 콘텐츠를 선택적으로 제공하는 방법.
23. 제 21 항에 있어서,

    상기 다수의 다큐먼트 부분의 각각에 대한 액세스를 위해 특권 그룹(privilege groups)을 설립하는 단계를 더 포함하는

    다큐먼트 콘텐츠를 선택적으로 제공하는 방법.
24. 제 23 항에 있어서,

    상기 특권 그룹은 상기 다수의 다큐먼트 부분의 각각을 액세스할 수 있는 클라이언트를 식별하는

    다큐먼트 콘텐츠를 선택적으로 제공하는 방법.
25. 다수의 클라이언트 위치와, 웹 서버와, 적어도 하나의 서비스 디스커버리 데이터베이스와, 상기 웹 서버와 상기 다수의 클라이언트 위치 사이에 위치된 다수의 프록시 성분을 포함하는 시스템에서, 클라이언트 세션 요구자(client session requester)로부터의 요구에 응답하여 공동 작업 웹 브라우징 세션(collaborative Web browsing session)을 설립하는 방법에 있어서,

    상기 프록시가 상기 서비스 디스커버리 데이터베이스에 등록하는 단계와,

    상기 세션 요구자가 상기 서비스 디스커버리 데이터베이스에 등록하는 단계와,

    상기 세션 요구자가 프록시를 선택하는 단계와,

    상기 세션 요구자가 상기 프록시에게 세션 생성 요구를 전송하는 단계와,

    상기 프록시가, 적어도 하나의 세션 다큐먼트에 대한 세션명 및 기억 위치를 적어도 포함하는 세션 정보를 요구하는 단계와,

    상기 세션 요구자가 상기 세션 정보를 입력하는 단계와,

    상기 프록시가 상기 적어도 하나의 세션 다큐먼트를 페칭(fetching)하는 단계와,

    상기 프록시가 상기 적어도 하나의 세션 다큐먼트에 대해 폴리시 파일이 존재하는지를 판정하는 단계와,

    상기 프록시가 상기 판정에 근거하여 상기 적어도 하나의 세션 다큐먼트를 하나 이상의 다큐먼트 부분으로 선택적으로 분할하는 단계와,

    상기 프록시가 상기 하나 이상의 다큐먼트 부분을 상기 다수의 클라이언트 위치 중 적어도 하나에 선택적으로 제공하는 단계를 포함하는

    공동 작업 웹 브라우징 세션 설립 방법.
26. 제 25 항에 있어서,

    적어도 하나의 신규 사용자가 상기 세션에 접속(joining)하는 단계를 더 포함하되,

    상기 접속 단계는,

    상기 적어도 하나의 신규 사용자가 현재 세션의 리스트를 획득하는 단계와,

    상기 적어도 하나의 신규 사용자가 상기 현재 세션중 하나의 선택된 세션을 선택하여, 상기 선택된 세션에 대해 접속 요구를 발생하는 단계와,

    상기 프록시가 상기 적어도 하나의 신규 사용자에게 로그인 메뉴(login menu)를 제공하는 단계와,

    상기 프록시가 상기 적어도 하나의 신규 사용자를 위한 사용자 액세스를 검증하는 단계와,

    상기 프록시가 사용자 출력 장치 정보에 대해 상기 세션 디스커버리 데이터베이스에 질의(querying)하는 단계와,

    상기 프록시가 상기 사용자 출력 장치 정보에 따라 상기 적어도 하나의 신규 사용자의 적어도 하나의 장치에 상기 하나 이상의 다큐먼트 부분 중 적어도 하나를 선택적으로 전송하는 단계를 포함하는

    공동 작업 웹 브라우징 세션 설립 방법.
27. 다수의 클라이언트 위치에 다큐먼트 콘텐츠(document content)를 선택적으로 제공하는 시스템에 있어서,

    다수의 클라이언트 위치와,

    상기 다큐먼트 콘텐츠를 기억하고, 클라이언트 요구에 응답하여 적어도 하나의 다큐먼트를 전송하는 적어도 하나의 서버와,

    상기 서버로부터 상기 적어도 하나의 다큐먼트를 수신하고, 상기 적어도 하나의 다큐먼트를 하나 이상의 다큐먼트 부분으로 선택적으로 분할하며, 상기 다수의 클라이언트 위치의 각각에 대해 상기 하나 이상의 다큐먼트 부분 중 적어도 하나를 선택적으로 제공하는 적어도 하나의 프록시를 포함하는

    다큐먼트 콘텐츠를 선택적으로 제공하는 시스템.
28. 제 27 항에 있어서,

    상기 적어도 하나의 프록시는, 상기 적어도 하나의 다큐먼트에 대한 폴리시 파일을 액세스하여, 상기 적어도 하나의 다큐먼트를 선택적으로 분할하기 위해 상기 적어도 하나의 폴리시 파일을 활용하는 적어도 하나의 처리 성분을 포함하는

    다큐먼트 콘텐츠를 선택적으로 제공하는 시스템.
29. 제 27 항에 있어서,

    상기 적어도 하나의 클라이언트 위치는 하나의 클라이언트 위치 당 다수의 장치를 포함하는

    다큐먼트 콘텐츠를 선택적으로 제공하는 시스템.
30. 제 27 항에 있어서,

    상기 적어도 하나의 클라이언트 위치는 상기 적어도 하나의 다큐먼트에 대해 공동 작업하기 위해 다수의 상이한 클라이언트 위치를 포함하는

    다큐먼트 콘텐츠를 선택적으로 제공하는 시스템.
31. 제 27 항에 있어서,

    상기 적어도 하나의 프록시는, 상기 하나 이상의 다큐먼트 부분을 상기 클라이언트 위치 중 적어도 하나에 위치되어 있는 장치에 대해 맵핑하는 적어도 하나의 처리 성분을 포함하는

    다큐먼트 콘텐츠를 선택적으로 제공하는 시스템.
32. 제 1 항의 방법을 컴퓨터에서 구현하는 프로그램을 기록한 컴퓨터 판독가능한 기록 매체.