문서 공동 편집 장치 및 그 방법{COOPERATIVE APPARTUS FOR EDITING DOCUMNET AND METHOD USING THE SAME}

본 발명은 다수의 편집자가 통신망에 연결된 개인용 컴퓨터(PC)를 이용하여 문서를 공동으로 편집하기 위한 문서 공동 편집 장치 및 그 방법과 상기 방법을 실현시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록매체에 관한 것으로, 특히 공동 편집 참여자들이 클라이언트/서버 형태의 공동 편집 세션을 형성하여 문서를 편집하기 위한 문서 공동 편집 장치 및 그 방법과 상기 방법을 실현시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록매체에 관한 것이다.

공동 편집기는 계층적으로 설계되었는데 데이터 전송과 공동 편집 세션의 생성/관리를 담당하는 T.120 프로토콜 스택 계층, 편집 명령어들을 처리하고 이들 명령어들을 동기화하여 모든 편집자들이 동일한 웹 문서의 사본을 유지할 수 있도록 하는 문서 관리자 계층, 그리고 편집 명령을 생성하고 수정된 웹 문서를 화면에 보여주는 사용자 인터페이스 계층으로 구분된다.

종래의 공동 편집 방법에는 응용 프로그램의 화면만을 공유하고 한 명의 편집자와 편집권을 획득하여 편집할 수 있는 응용 프로그램 공유 형식의 공동 편집 방법과, 편집 권한의 제한없이 공동 영역에 문자나 이미지를 추가/삭제할 수 있는 공유 화이트보드 형식의 공동 편집 방법 등이 있다.

전자는 모든 종류의 매체들을 편집할 수 있으나 응용 프로그램 공유 기능을 이용하여 공동 편집을 실시하므로 여러 편집자가 동시에 편집할 수 없는 등 공동 편집을 위한 충분한 기능을 제공하지 못하고, 후자는 텍스트 문서의 편집이 불가능하다는 단점 때문에 진정한 의미의 공동 편집이라고 보기 어려운 문제점이 있었다.

본 발명은, 상기한 바와 같은 문제점을 해결하기 위하여 안출된 것으로, 편집자들이 네트워크에 연결된 각각의 단말기에 공동 편집기를 실행하여 다수의 편집자가 하나의 문서를 동시에 공동으로 편집할 수 있도록 하는 문서 공동 편집 장치 및 그 방법과 상기 방법을 실현시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수있는 기록매체를 제공하는데 그 목적이 있다.

도 1 은 본 발명이 적용되는 공동 편집 시스템에 대한 구성 예시도.

도 2a 는 공동 편집기를 실행할 때 보여지는 화면구성의 일예시도.

도 2b 는 공동 편집기를 실행할 때 보여지는 화면구성의 다른 예시도.

도 3 은 공동 편집기 실행 화면에서 텍스트 편집 창만을 따로 나타낸 예시도.

도 4 는 공동 편집기와 T.120 프로토콜 스택과의 상관관계를 나타내는 구성도.

도 5 는 본 발명에 따른 웹 문서 공동 편집 장치의 구성도.

도 6 은 본 발명에 따른 웹 문서 공동 편집 방법중 공동 편집을 시작하는 과정에 대한 일실시예 흐름도.

도 7 은 웹 문서를 내부 형식으로 바꾸었을 때, 하나의 라인을 표현하기 위한 자료 구조도.

도 8 은 본 발명에 따른 웹 문서 편집 장치 및 그 방법중 편집 명령어 처리 과정에 대한 설명도.

도 9a 는 본 발명에 따른 웹 문서 편집 방법 중 클라이언트에서의 편집 명령어 처리 과정에 대한 일실시예 흐름도.

도 9b 는 본 발명에 따른 웹 문서 편집 방법 중 클라이언트에서의 편집 메시지 처리 과정에 대한 일실시예 흐름도.

도 10 은 본 발명에 따른 웹 문서 편집 방법 중 서버에서의 편집 메시지 처리 과정에 대한 일실시예 흐름도.

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

50 : 웹 문서 공동 편집기 51 : 사용자 인터페이스 모듈

52 : 문서 관리자 모듈 53 : 사용자 관리자 모듈

54 : 비표준 APE

상기 목적을 달성하기 위한 본 발명은, 공동 편집 시스템에서의 문서 공동 편집 장치에 있어서, 문서를 공동 편집할 수 있도록 편집 명령을 생성하고, 편집된 문서를 파싱하여 여러 형태로 편집 환경을 제공하기 위한 편집 환경 제공수단; 상기 편집 명령을 처리 및 동기화하여 동일한 문서의 사본을 관리하기 위한 문서 관리수단; 및 상기 공동 편집에 참여할 사용자들의 정보를 이용하여 적법한 사용자인지를 확인하기 위한 사용자 관리수단을 포함하여 이루어진 것을 특징으로 한다.

또한, 본 발명은, 공동 편집 시스템에 적용되는 문서 공동 편집 방법에 있어서, 공동 편집 작업을 시작하기 위해 공동 편집할 문서를 선택하여 각종 정보가 저장된 편집 정보 제공자 회의에 접속하는 제 1 단계; 상기 편집 정보 제공자 회의에 접속된 사용자가 편집에 대한 명령을 메시지로 변환하여 서버로 전송하는 제 2 단계; 상기 서버로 전송된 메시지를 검사하여 편집 권한 여부를 확인한 후 클라이언트들에게 전송하는 제 3 단계; 및 상기 클라이언트들이 상기 서버로부터 전송된 편집 명령을 반영하여, 각자가 저장하고 있는 편집 문서 복사본의 내용을 수정하는 제 4 단계를 포함하여 이루어진 것을 특징으로 한다.

또한, 본 발명은, 프로세서를 구비한 공동 편집 시스템에, 공동 편집 작업을 시작하기 위해 공동 편집할 문서를 선택하여 각종 정보가 저장된 편집 정보 제공자 회의에 접속하는 제 1 기능; 상기 편집 정보 제공자 회의에 접속된 사용자가 편집에 대한 명령을 메시지로 변환하여 서버로 전송하는 제 2 기능; 상기 서버로 전송된 메시지를 검사하여 편집 권한 여부를 확인한 후 클라이언트들에게 전송하는 제 3 기능; 및 상기 클라이언트들이 상기 서버로부터 전송된 편집 명령을 반영하여, 각자가 저장하고 있는 편집 문서 복사본의 내용을 수정하는 제 4 기능을 실현시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록매체를 제공한다.

본 발명은 모든 편집자들이 문서의 복사본을 자신의 개인용 컴퓨터(PC)에 보관하면서 편집시에 편집 명령어를 메시지로 바꾸어 서버로 전송하고, 전송된 메시지를 공동 편집에 참여중인 모든 편집자에게 재전송하며 메시지를 받은 편집자들이 이 메시지를 분석하여 자신의 문서 복사본에 적용함으로써, 타 편집자들과 항상 동일한 내용을 유지할 수 있도록 하는 것을 특징으로 한다. 만약 같은 위치에서 다수의 편집자가 서로 다른 편집 명령을 실행하더라도 서버가 판단하여 우선순위에 따라 편집 메시지를 생성하여 전송하면 모든 편집자들은 동일한 순서로 메시지를 수신하여 처리하므로 모든 편집자들의 문서 사본을 항상 동일하게 보장할 수 있다.

상술한 목적, 특징들 및 장점은 첨부된 도면과 관련한 다음의 상세한 설명을 통하여 보다 분명해 질 것이다. 이하, 첨부된 도면을 참조하여 본 발명에 따른 바람직한 일실시예를 상세히 설명한다.

도 1 은 본 발명이 적용되는 공동 편집 시스템에 대한 구성 예시도이다.

도 1에 도시된 바와 같이, 모든 기능들은 클라이언트/서버 환경에서 동작하도록 정의되었으므로, 한 세션에는 반드시 하나의 서버가 존재해야 한다. 서버의 역할은 공동 편집 세션내에서 발생한 모든 편집 메시지를 전송받아 이를 다시 편집자들에게 분배하는 것이다. 통신망에 연결된 다수의 컴퓨터 중 편집하려는 웹 문서를 처음 오픈하고 세션을 생성한 사람의 컴퓨터는 그 세션에 서버 토큰이 있는지를 확인하여 서버 토큰이 가능한 상태이면 서버 토큰을 획득하고 서버가 된다.

일반적으로, 서버는 세션이 끝날 때까지 서버로서의 역할을 수행하지만 부득이하게 세션의 서버를 바꾸어야 할 경우에는 서버 토큰을 클라이언트들 중 하나에게 넘겨주게 된다. 이에 토큰을 전달받은 클라이언트는 자신이 새로운 서버가 되었음을 세션내의 모든 컴퓨터들에게 알린다. 토큰을 이용하여 서버 및 클라이언트를 구분하므로 한 세션에 두개 이상의 서버가 존재하는 경우는 발생하지 않는다.

각 편집자들은 자신에게 할당된 영역만을 편집할 수 있고, 나머지 영역에 대해서는 편집 권한이 없다. 편집자들은 각자의 역할에 따라 편집 권한이 다르게 부여되는데, 일반적으로 웹 사이트 관리자와 웹 디자이너 등은 편집 권한을 많이 갖고, 광고주나 컨텐츠 제공자들은 편집 권한을 적게 갖는다. 한편, 편집 권한은 세션 관리자에 의해서 제어되는데, 세션 관리자는 문서의 모든 영역을 편집할 수 있는 권한이 있고, 다른 편집자들에게 편집 권한을 할당할 수 있다. 그리고, 공동 편집 세션에서 파일의 생성, 삭제 및 저장, 사용자 관리 등의 역할을 수행한다.

도 2a 는 공동 편집기를 실행할 때 보여지는 화면구성의 일예시도이다.

도 2a에 도시된 바와 같이, 공동 편집기 창을 두개의 창으로 나누어 하나는 위지윅 형태의 편집이 가능한 위지윅 편집 창(21)으로 사용하고, 다른 하나는 텍스트 형식으로 편집하는 텍스트 편집 창(22)으로 사용한다. 각각의 창에서 편집이 가능하며 편집된 내용은 다른 창에 반영되어 항상 두개의 창이 같은 내용을 유지한다. 도면에서 "23"은 텍스트 편집을 위하여 사용되는 편집자의 캐럿(Caret)을 나타낸다.

도 2b 는 공동 편집기를 실행할 때 보여지는 화면구성의 다른 예시도이다.

도 2b에 도시된 바와 같이, 각각 독립적인 제어가 가능한 두개의 창을 생성한다. 예를 들면, "25"는 웹 문서 텍스트를 보여주는 창이고, "24"는 웹 문서를 파싱한 결과를 보여주는 창이다. "25"는 도 2a의 "22"의 창과 같고, "24"는 웹 문서를 파싱한 결과를 보여주는 창인데 이를 실행하는 방법은 다음과 같이 두 가지가 있다.

첫번째 방법은 도 2b의 경우와 같이 공동 편집기 프로그램에 내장된 위지윅 편집 창을 실행하여 위지윅 편집과 텍스트 편집을 병행하는 것이다.

두번째 방법은 일반 웹 브라우저를 실행하여 편집 결과만 확인하는 것이다. 이때, 위지윅 편집은 불가능하고 텍스트 편집만 가능하다. 그리고, 편집 중인 문서의 내용이 수정될 때마다 웹 브라우저에게 알려줘야 하는데, 이를 위하여 편집중인 문서를 웹 문서의 형태로 저장하고 웹 브라우저에게 메시지를 보내어 이 파일을 읽도록 한다. 이때, 웹 사이트를 직접 편집하는 경우 웹 문서에 포함된 URL(Uniform Resource Locator)을 "http://"로 시작하는 절대 주소 형식으로 바꾸어 그림들을 웹 사이트로부터 직접 읽어오게 한다. 그리고, 로컬 디스크에 저장된 웹 문서를 공동 편집하는 경우에는 그림 파일들을 모두 클라이언트에 복사하여 서버의 로컬 디스크와 같은 환경을 만들어 편집한다. 물론 위의 두 가지 방법을 병행하여 두개의 창으로 웹 문서를 편집하고, 웹 브라우저로 내용을 확인하는 방법을 사용할 수도있다.

도 3 은 공동 편집기 실행 화면에서 텍스트 편집 창만을 따로 나타낸 예시도이다.

도면에서 "31"은 편집자의 캐럿이고, "32"는 편집자가 락(lock)을 요청한 영역이다. 이 영역은 편집자 혹은 세션 관리자가 락(lock)을 해제할 때까지 다른 편집자로부터 보호된다. 편집자는 각 라인별로 편집 권한이 제한되는데, 편집자는 자신이 편집할 수 있는 라인에 대해서만 락(lock) 및 편집을 할 수 있다. 락(lock) 영역은 텍스트의 색을 달리하여 자신이 락(lock)한 영역인지 다른 편집자가 락(lock)한 영역인지 구분한다. 또한, "33"은 라인 번호로서 각 라인을 구분하기 위한 용도로 사용된다.

본 발명에서는 한 라인 당 하나의 인스턴스 번호가 부여되고, 이 번호는 서버에서 관리한다. 하나의 라인이 추가되면 서버에서 새로운 인스턴스 번호를 하나 생성하여 부여하고, 라인이 삭제되면 인스턴스 번호도 함께 삭제되며, 라인이 수정되었을 때에는 인스턴스 번호가 그대로 유지된다.

도 4 는 공동 편집기와 T.120 프로토콜 스택과의 상관관계를 나타내는 구성도이다.

도 4에 도시된 바와 같이, 공동 편집기를 실행하기 전에 반드시 T.120 프로토콜 스택을 실행해야 하는데 이는 공동 편집기가 T.120의 응용 프로그램(45)으로 동작하기 때문이다. 멀티미디어 데이터 회의를 위한 T.120 프로토콜 스택은 데이터 전송 및 리소스 관리를 위한 MCS(MultiPoint Communications Service :T.122/125)(41)와 회의 및 세션을 관리하는 GCC(Generic Conference Control : T.124)(42), 그리고 T.120 프로토콜 스택의 기능들을 이용하여 회의를 생성하고 유지 및 관리하는 NC(Node Controller)(43)가 있다. 이들 중 MCS(41)와 GCC(42)는 각각 T.122/125, T.124등의 표준이 정의되어 있으나 NC에 대한 표준은 없다. 회의 진행중에 사용할 수 있는 응용 프로그램(45)으로는 화이트보드, 파일 전송, 응용 프로그램 공유, 채팅 등이 있으며, 이러한 응용 프로그램들이 동작하기 위한 표준은 각각 T.126, T.127, T.128, T.134등으로 정의되어 있다.

표준 APE(44)는 이들 표준 응용 프로그램들이 MCS/GCC와 데이터를 전송하기 위한 방법을 정의한 것으로 T.121로 정의되어 있다. 웹 문서 공동 편집기(47)가 MCS/GCC와 데이터를 교환할 때는 비표준 APE(46)를 이용하는데, 비표준 APE(46)는 공동 편집에 적합하도록 표준 APE(44)를 수정한 것이다. 또한, 웹 문서 공동 편집기(47)를 실행하는 동안 파일 전송이나 채팅, 화이트보드 같은 T.120 응용 프로그램을 사용할 수도 있으므로, 이러한 응용 프로그램들을 사용하여 편집에 필요한 파일의 전송이나 편집에 관한 의견 교환 등을 할 수 있다.

도 5 는 본 발명에 따른 웹 문서 공동 편집 장치의 구성도이다.

도 5에 도시된 바와 같이, 웹 문서 공동 편집기(50)는 웹 문서를 파싱하여 시각화하고 위지윅 형태의 편집 환경을 제공하기 위한 사용자 인터페이스 모듈(51)과, 편집에 관련된 여러가지 기능을 수행하기 위한 문서 관리자 모듈(52)과, 웹 문서 공동 편집기가 서버로 동작할때, 공동 편집에 참여할 사용자들의 정보를 관리하기 위한 사용자 관리자 모듈(53)을 구비한다.

여기서, 문서 관리자 모듈(52)은 웹 문서를 읽어서 공동 편집에 적합한 내부 형식으로 바꾸는 기능, 편집 메시지가 도착하면 이를 분석하여 적법한 편집 명령인지 검사하고 편집하는 기능, 편집 명령을 타 편집자들에게 전송하기 위하여 메시지로 바꾸는 기능, 내용이 변경되었을 때 사용자 인터페이스 모듈(21)에게 알리는 기능 등을 수행한다.

그리고, 사용자 관리자 모듈(53)은 공동 편집에 참여할 사용자들의 정보를 관리하고, 사용자가 로그인 했을때 사용자의 아이디와 패스워드를 검사하여 적법한 사용자인지를 확인하는 등의 역할을 수행한다.

도 6 은 본 발명에 따른 웹 문서 공동 편집 방법중 공동 편집을 시작하는 과정에 대한 일실시예 흐름도이다.

도 6에 도시된 바와 같이, 웹 문서 공동 편집기를 실행하기 전에 먼저 T.120 프로토콜 스택을 실행하고 회의를 생성해야 한다. 경우에 따라서 한 개의 컴퓨터에 여러 개의 회의가 진행될 수도 있으므로, 현재 진행중인 여러 개의 회의중에 자신이 참석하려는 회의를 선택하여 그 회의에 참여해야 한다(601). 즉, 현재 진행중인 회의들은 각각의 이름에 의해 구분되므로 자신이 참여하길 원하는 회의의 이름을 선택함으로써, 회의가 이루어진다.

이어서, 편집할 웹 문서를 선택한다(602). 즉, 공동 편집 가능한 웹 문서 리스트를 보고 이 중에서 자신이 편집하길 원하는 웹 문서를 선택한다. 그리고 나서, 로그인을 하는데(603) 공동 편집에서의 로그인은 세션 관리자와 일반 편집자를 구분하고, 문서를 편집할 권한이 있는지를 검사하는 용도로 사용된다.

편집하려는 문서에 대한 세션이 이미 생성되어 있는지를 확인한다(604).

확인결과, 편집하려는 문서에 대한 세션이 이미 생성되어 있지 않으면 토큰을 획득(Grab)하여 서버가 되어 세션을 생성한다(605). 토큰은 T.120의 MCS가 제공하는 기능이므로 웹 문서 공동 편집기는 단순히 토큰을 획득(Grab)하도록 요청하기만 하면 된다. 그리고, 웹 문서를 로드한 후(606) 공동 편집을 시작한다(607).

확인결과, 편집하려는 문서에 대한 세션이 이미 생성되어 있으면 클라이언트가 되어 서버로부터 웹 문서를 전송받아(608) 공동 편집을 시작한다(607). 서버로부터 문서를 전송 받을때는 문서의 위치와 편집자들의 편집 권한, 락(lock)에 대한 정보들도 함께 전송받는다. 왜냐하면 문서의 위치를 알아야만 웹 문서 내에 있는 URL에서 그림 등을 갖고 올 수 있기 때문이다. 만약, 하드디스크에 저장되어 있던 문서를 전송받는 경우라면 그 문서에 포함되어 있는 그림 파일 등도 함께 전송받아서 자신의 로컬 디스크에 저장한다.

도 7 은 웹 문서를 내부 형식으로 바꾸었을 때, 하나의 라인을 표현하기 위한 자료 구조도이다.

도 7에 도시된 바와 같이, 웹 문서 공동 편집기는 웹 문서를 이중 연결리스트로 바꾸어 관리한다. 리스트의 한 노드는 하나의 라인을 표현하도록 구성되었고, 각 노드에는 편집을 위하여 필요한 정보들을 저장한다.

웹 문서를 내부 형식으로 바꾸는 과정은 다음과 같다. 아래의 과정은 서버에서만 일어나며 클라이언트들은 서버에서 리스트로 바꾸어 놓은 형태의 웹 문서를 전송받는다. 세션에 참여한 모든 편집자들이 동일한 내용을 유지할 수 있도록 하기위함이다.

첫째, 웹 문서를 읽어서 라인 단위로 분리한 후 노드의 내용 필드(74)에 저장한다. 일반적으로 웹 문서의 경우는 한 라인이 하나의 태그에 해당하는 경우가 많고 라인의 길이가 짧다.

둘째, 라인별로 번호를 부여하여 라인 번호 필드(71)에 저장한다. 이 번호는 각 라인들을 구분하는 역할을 하고, 공동 편집에 참여한 모든 클라이언트들을 통해 동일하게 유지된다.

셋째, 사용자 아이디 리스트(UserID list) 필드(75)에 이 노드를 편집할 수 있는 권한을 가진 편집자들의 사용자 아이디(UserID) 필드(76)들을 리스트 형태로 저장한다. 여기에 등록되지 않은 사용자는 이 노드를 편집할 수 없다. 사용자 아이디 리스트(UserID list) 필드(75)에 등록되기 위해서는 세션 관리자에게 등록을 요청하여야 하는데, 편집이 시작되기 전에 요청할 수도 있고 편집이 진행되는 중에 요청할 수도 있다. 만약 이 리스트가 널(NULL)이면 모든 편집자들이 편집할 수 있다.

넷째, "Previous" 와 "Next"에 각각 앞 노드와 뒷 노드를 가리키도록 값을 설정한다.

다섯째, 나머지 필드들의 값을 0으로 초기화한다.

노드 리스트가 완성되면 공동 편집을 진행하는데 공동 편집중에 임의의 편집자가 편집을 하면 해당 노드의 사용자 아이디(UserID) 필드(76)에 이 노드를 편집한 편집자의 사용자 아디이(UserID)를 저장한다. 만약, 이 필드 값이 0이라면 이는최초에 파일에서 읽은 후 한번도 수정되지 않았다는 의미가 된다.

예약된 사용자 아이디(Reserved UserID) 필드(77)는 이 노드를 편집하기 원하는 편집자가 다른 편집자들이 편집할 수 없도록 락(lock)을 요청했을 때, 락(lock)을 요청한 편집자의 사용자 아이디(UserID)를 저장하는 곳이다. 락(lock)요청은 사용자 아디이 리스트(UserID list) 필드(75)에 등록되어 있는 편집자와 세션 관리자만 할 수 있다. 락(lock) 요청을 해제하면 예약된 사용자 아이디(Reserved UserID) 필드(77) 값이 0이 된다.

도 8 은 본 발명에 따른 웹 문서 편집 장치 및 그 방법중 편집 명령어 처리 과정에 대한 설명도이다.

도 8에 도시된 바와 같이, 클라이언트(82)가 문서의 일부를 편집했다고 가정하면, 사용자 인터페이스 모듈(82b)은 편집자의 키보드 입력이나 마우스 입력을 검사하여 이를 편집 명령으로 바꾸어 문서 관리자 모듈(82a)로 전달한다. 이때, 사용자 인터페이스 모듈(82b)은 수정된 내용을 화면상에 표시하지 않는다.

문서 관리자 모듈(82a)은 이 편집 명령이 적법한지를 검사하고, 적법할 경우 편집 명령어를 메시지로 바꾸어 서버(81)로 전송한다. 서버(81)의 문서 관리자 모듈(81b)은 이 메시지를 받아서 편집 권한이 있는지, 그리고 다른 편집자에 의해서 락(lock)이 되어 있는 것은 아닌지 검사한다. 편집 권한이 있는 것으로 확인되면 서버(81)의 문서 관리자 모듈(81b)은 웹 문서의 내용을 수정하고 사용자 인터페이스 모듈(81a)에게 내용이 수정되었음을 알린다. 그러면, 서버(81)의 사용자 인터페이스 모듈(81a)은 수정된 내용에 맞게 화면을 바꾼다.

이어서, 서버(81)의 문서 관리자 모듈(81b)은 사용자 인터페이스 모듈(81a)에게 내용 수정을 알림과 동시에 클라이언트(82,83)에게 수정된 내용을 메시지로 변환하여 전송한다. 편집 메시지를 받은 클라이언트(82,83)의 문서 관리자 모듈(82a,83a)은 각자가 관리하는 웹 문서의 복사본에 수정된 내용을 반영하고 사용자 인터페이스 모듈(82b,83b)에게 내용이 수정되었음을 알린다. 이에, 편집 명령을 수행했던 클라이언트(82)도 변환된 메시지를 전송받은 후에 화면을 수정한다.

이때, 클라이언트가 편집을 한 후 실제로 편집 내용을 확인하기까지 약간의 시간 지연이 발생할 수 있으며, 이러한 시간 지연은 네트워크의 상태에 따라, 서버와 클라이언트 시스템의 하드웨어 성능에 따라 약간씩 차이가 날 수 있다.

이렇게 함으로써, 모든 사용자가 동일한 내용을 유지할 수 있도록 한다.

도 9a 는 본 발명에 따른 웹 문서 편집 방법 중 클라이언트에서의 편집 명령어 처리 과정에 대한 일실시예 흐름도이다.

도 9a에 도시된 바와 같이, 본 발명에서는 웹 문서를 편집하기 위한 명령어로 라인의 수정, 삽입과 삭제, 분할과 합병 등을 정의하였다. 도면은 클라이언트가 이들 명령어 중 하나인 라인 수정 명령을 처리하는 과정을 나타낸 순서도이다.

즉, 사용자가 웹 문서의 특정 영역을 편집하기 위하여 수정(Modify) 명령을 내리면(901), 문서 관리자 모듈에게 이 명령이 전달되는데, 이때 파라미터로 라인번호, 수정된 내용 그리고 사용자 아이디(ID)가 전달된다. 문서 관리자 모듈은 이 명령을 전달받은 후 수정이 가능한지를 검사한다(902). 만약, 다른 사람이 락(lock)해 놓은 경우이거나 사용자가 편집 권한이 없는 경우에는 이 명령은 처리되지 않는다.

검사결과, 수정이 가능하면 전달된 명령을 메시지로 변환한 후(903) 서버로 전송하여(904) 대기 상태로 들어가고(905), 수정 명령이 가능하지 않으면 바로 대기 상태로 들어간다(905).

도 9b 는 본 발명에 따른 웹 문서 편집 방법 중 클라이언트에서의 편집 메시지 처리 과정에 대한 일실시예 흐름도이다.

도 9b에 도시된 바와 같이, 서버로부터 수정된 메시지(라인번호, 수정된 내용 그리고 사용자 아이디(ID))를 전달받으면 메시지에 포함된 사용자 아이디(ID)를 검사하여 자신의 사용자 아이디(My User ID)와 비교한다(912).

비교결과, 사용자 아이디(ID)와 자신의 사용자 아이디(My User ID)의 값이 같지 않으면 클라이언트가 유지하고 있는 내용 리스트에서 라인 번호가 같은 노드가 있는지를 검색한다(913).

이어서, 노드의 내용을 수정한 후(914), 사용자 인터페이스 모듈로 내용이 수정되었음을 알린다(915). 즉, 사용자 인터페이스는 자신이 편집한 내용에 대해서도 반드시 서버로부터 편집 메시지가 전송되어야만 그 내용을 수정할 수 있다. 사용자가 관리하는 리스트는 두개가 있는데 하나는 자신이 편집한 내용을 순서대로 저장하는 편집 리스트이고, 다른 하나는 내용 리스트이다. 편집 리스트는 자신이 편집한 내용을 순서대로 저장하는 곳으로, 실행취소(Undo) 기능을 구현하기 위하여 사용한다. 내용 리스트는 상기 도 7에서 설명한 노드들의 이중 연결 리스트로 모든 편집자의 시스템에 동일한 내용이 관리된다.

기타 다른 명령어들도 수정과 비슷한 방법으로 처리된다. 삽입의 경우는 리스트에서 라인번호가 같은 노드를 검색해서 찾은 노드의 뒤에 노드를 삽입하고, 삭제의 경우는 리스트에서 라인번호가 같은 노드를 검색해서 찾은 노드를 삭제하면 된다.

한편, 사용자 아이디(ID)와 자신의 사용자 아이디(My User ID)의 값이 동일하면 이는 자신이 보낸 편집 메시지이므로, 편집 리스트에 이 내용을 추가한 후(916) 리스트에서 라인 번호가 같은 노드를 검색하는 과정으로 넘어간다(913).

도 10 은 본 발명에 따른 웹 문서 편집 방법 중 서버에서의 편집 메시지 처리 과정에 대한 일실시예 흐름도이다.

도 10에 도시된 바와 같이, 서버의 경우는 클라이언트로부터 전송된 메시지를 처리한다. 클라이언트로부터 전송된 수정 메시지(라인번호, 수정된 내용 그리고 사용자 아이디(ID))를 전달받으면(101) 내용 리스트에서 라인번호에 해당하는 노드를 검색한다(102).

이어서, 이 노드가 락(lock) 상태인지를 확인한다(103).

확인결과, 락 상태가 아니면 편집 권한이 있는지를 확인하여(104) 편집 권한이 없으면 수정된 메시지를 처리하지 않고, 편집 권한이 있으면 내용을 수정한 후(105) 클라이언트로 전송하여(106) 사용자 인터페이스 모듈로 이 내용을 알려 화면을 수정하도록 한다(107).

한편, 락 상태이면 수정을 요청한 사용자가 락을 신청하였는지를 확인한다(108).

확인결과, 수정을 요청한 사용자가 락을 신청하였으면 편집 권한이 있는지를 확인하는 과정(104)으로 넘어가고, 수정을 요청한 사용자가 락을 신청하지 않았으면 수정된 메시지를 처리하지 않는다.

이상에서 설명한 본 발명은 전술한 실시예 및 첨부된 도면에 의해 한정되는 것이 아니고, 본 발명의 기술적 사상을 벗어나지 않는 범위 내에서 여러 가지 치환, 변형 및 변경이 가능하다는 것이 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 있어 명백할 것이다.

상기한 바와 같은 본 발명은, 인터넷의 사용이 일반화되면서 점점 사용빈도가 높아져가는 문서를 다수의 편집자가 공동으로 편집할 수 있게 함으로써, 문서 편집시 소요되는 시간을 줄일 수 있고, 분야별 전문가들이 공동 편집에 참여함으로써 문서의 전문성을 높일 수 있으며, 편집한 내용을 실시간으로 확인하면서 작업을 할 수 있으므로 작업의 능률을 높일 수 있는 효과가 있다.