JP5648773B2 - ドキュメント入力編集システム - Google Patents

Description

本発明は、複数の参加者が構成要素の単位で情報を入力または特定し、相互に直接的または間接的なコミュニケーションを取りながら、この入力または特定された情報の内容および属性、並びに構成要素間の関係等を編集し、体系化または整理された知識または情報を構成し、共有するための技術に関する。従来の電子会議システム、電子掲示板、或いはドキュメント編集システム等に代わる、新しいコミュニケーションやコラボレーションを可能とするネットワーク・アプリケーション、及びこれに関するシステム、プログラム、方法を考案したものである。多様な意見や立場が存在する複雑なテーマに関し、様々な知識、概念、主張、認識等に関する情報を体系的に整理または調整し、最終的にこれらの情報の体系（以下、「情報体系」）を得ることを可能とすることを目標とする。

なお、本発明の名称としては「ドキュメント入力編集システム」を挙げており、また請求項及び明細書の記載においても、同様の文言を用いているが、本システムは、既に記述したとおり、単にドキュメントを編集する目的においてだけでなく、会議を実施する目的においても用いることができる。これは、会議のプロセスを議事録というドキュメントを作成する作業であると解釈することや（多くの会議においてはそのアウトプットとして議事録が作成される）、何らかのドキュメントを編集作成するための会議を実施するものと想定することにより、「ドキュメント入力編集システム」をそのまま会議システムとして適用することができるが、必ずしもこの認識に制限することを意図するものではない。そもそも、複数者の間でドキュメントを入力編集するプロセスと会議を実施するプロセスとは、それらの実施形態にもよるが、情報を共有しつつ、参加者間で協力、対立、調整等を繰り返しながら、認識、意見、考え等を整理するプロセスとして理解すれば、同様の目的を持つプロセスであると捉えることができ、これらのプロセスをコンピュータ・ネットワーク上でヴァーチャル化すれば同じシステムに集約されることは充分に考えられる。むしろ、発明者は、本発明システムを活用することにより、複数者の間でドキュメントを入力編集するプロセスと会議を実施するプロセスとはそれを区分する境界を失い、利用者はこの両方のうちどちらとも解釈できるプロセスをも進めることができるようになると認識するものである。

文章を階層構造において整理し、分かりやすい要約を作成する方法については特許文献１においても提案されている。これは、複数のメッセージをそれぞれ１つ以上の文からなる部分文書に分割し、メッセージ間の応答関係と、部分文書間の引用関係とに基づき、各部分文書をノードとして接続してなる階層構造を構成することにより、複数のメッセージの内容の要約を作成するというものだ。

しかしながら、応答関係と引用関係に基づく階層化では、これらの関係が階層構造を構築するための重要な手掛かりとして機能する反面、階層構造がこれらの関係から強い制約を受け、情報を自由に構造化することができない。例えば、利用者が意識的に構造の調整を行うことが困難である。ましてや意見や立場の異なる複数の利用者が調整を図りながら、複雑で多様な議論の内容を体系立てて整理することは到底できない。この文献で示されるのは、飽くまで既存の一般的な電子掲示板を改造したようなしくみであると考えられ、通常の方法でやり取りされるメッセージを対象としたシステムであり、また要約を作成することのみに用途が絞られているなど、利用範囲が制限される。特許文献１で示されるのは、議論をするための場が別にあることを前提とし、そこでの議論を整理するための補完的なシステムであり、それ自体が議論（例えば、互いに意見を述べ合い、互いの意見を戦わせ、互いの認識の共有を図り、何らかの結論やアウトプットを求めること）の場として機能するものではない。

また、議論の中での発言を構造化することによりその内容を容易に理解できるようにしようとする取り組みは非特許文献１においても紹介されている。ここに記載される「ディスカッションマイニング」と呼ばれるシステムは、対面式（オフライン）の会議における議事録の生成と再利用を目的とする。会議の状況を複数台のカメラやマイクによって記録すると同時に、書記が専用ツールを用いて手動でテキストを入力することにより議事録を作成し、これにメタデータを付与することにより発言間の関係を定義し、議事録の構造の可視化を実現している。

しかしながら、このシステムでは、以下の理由により、多数の参加者の参加する議論の過程で体系だった知識を整理することは必ずしも容易ではない。まず、複数の利用者が既に提示されている情報に対し、自身の意思や意見を反映させるメカニズムは提供されていない。また、立場や意見の異なるユーザの考えを調整するためのメカニズムや意思決定に関するメカニズムは準備されていない。これらのメカニズムは、もしあったとしても、オフラインでの会議に委ねられる。他者の提示した情報を、自身の解釈に基づき別の文脈のなかに再定義しようとする提案を相互に出し合いながら、様々な情報の位置付けが全体として最適化されていくプロセスを可能とする本発明に記載のシステムとは異なる。

会議の成果を効率的に整理し、活用することを可能とする、非常に優れたシステムであると評価されるが、非特許文献１に記載のシステムは、論文の中でも明記されている通り、あくまでも「オフラインの会議に焦点を絞った、議事録の生成と再利用」を目的とするものであり、本発明が課題とする問題における解決を提供するものではない。

また、議論においてなされた発言を構造化することにより、議論の内容や流れの把握を容易にしようとする方法は特許文献２において提案されている。これは、「発言の種類に関する情報と、発言の各種類間の参照関係に関する情報を用い、質疑応答に関する発言をモデル化した質疑応答モデルを参照することにより、各発言者の発言を構造化する」ことによる解決を図ったものである。しかしながら、この方法では、以下の理由により、意見や立場の異なる多数の参加者の参加する議論の過程で体系だった知識を整理することは必ずしも容易ではない。

第一に、一度入力された発言の内容、種類、関係を編集することが想定されていない。複雑なテーマを扱う議論の場において、最初から完璧な情報を入力し、最適な属性と関係を付与することを要求することは困難であり、また特定の参加者が独断で処理することが適切な議論のプロセスといえるのは特殊なケースである。もちろん、一度入力されたデータを編集し保存する機能は通常の情報システムであれば備えていて当然であるが、このように意見や立場の異なる多数の参加者を前提とした場合には、情報をコントロールする権限を誰がどのように保持し、どのようなプロセスを経て編集が処理されるのかは、適切な解決が必要となる重要な課題である。こうしたことから、編集プロセスが想定されていない、或いは明示されていないことは、この技術に残された大きな問題である。

第二に、情報の種類として「質問」と「回答」及び「同意」と「非同意」を想定し、「質疑応答モデル」に基づく構造化を前提としている。質疑応答（及び賛否の確認）のプロセスによって議論を展開することは、オーソドックスなスタイルの一つであるといえるが、このプロセスで扱うことのできない議論は非常に多い。提案、報告、意見や、或いは他の発言に対する指摘、補足、コメント等のように、質疑、賛否のいずれにも該当し得ない発言や、質疑、賛否から独立して取り扱われるべき発言はいくらでも想定される。「質疑応答モデル」に基づく構造化を前提とした議論の枠組みではこうした発言を取り扱うことができず、参加者が自由に議論することを制限し、議論の展開や構造化において決定的な制約が課せられる。

第三に、「同意」や「非同意」を表明するプロセスは提供されているが、これによって付与された個人の意思や意見を全体的なコンセンサス、意思決定、調整、駆け引き等に反映するためのメカニズムは想定されていない。これは、議論のプロセスを経て、何らかの結論を出すことは想定されておらず、従ってそのための合意形成のメカニズムは必要とされていないためである。目的を持った議論を実施するためには、中途半端な解決しか提供されていないシステムであると言わざるを得ない。

第四に、これは第一、第二、第三の理由から導かれることでもあるが、大量の情報を共有しながら、体系立てて知識を整理することに適した方法とはいえないことである。多様なアクターの参加する議論において体系化された知識を整理するためには、試行錯誤やコミュニケーションを行うしくみ、複雑なアーキテクチャの中で各発言の位置付けを明確化するしくみ、コンセンサスや調整のしくみ等が不可欠であるが、この方法にはそれが欠如している。

結局、特許文献２では、同じ議論のなかで多数の参加者が発言することや、多数の発言を体系立てて整理することは想定されておらず（仮にそうした状況において用いようとすると適切に機能することは期待されない）、該文献の「発明を実施するための最良の形態」に示される通り、比較的小規模な参加者による小規模な議論を対象としたものであるという域を超えるものではないと考えられる。

議論においてなされた発言を構造化した上で、各発言の信頼性を数値的に評価することにより議論の結論を得ようとした方法は特許文献３において提案されている。これは、「主張の入力の際には、前記主張を論証する少なくとも一つ以上の根拠および、前記根拠を統合して前記主張を導く論理である理由を、前記主張の下位に展開して入力し、展開された前記根拠及び前記理由のそれぞれを論証する第一の根拠および第一の理由を前記根拠および前記理由のそれぞれの下位に展開する手順を再帰的に繰り返し、入力された主張群、根拠群および理由群を論証構造に展開する」ことにより解決を図ったものである。しかしながら、この方法では、以下の理由により、意見や立場の異なる多数の参加者が自由に議論し、体系だった知識を整理することは容易ではない。

第一に、発言は必ずしも論証の対象となりうるもの、またはなるべきものとは限らない。多くの発言には、それに対する賛成意見もあれば、反対意見もあり、いずれの指摘も尤もであるというケースは少なくない。全ての発言において論理的な結論を得るまで論争することを促すシステムは、参加者に求められる負荷が大きく、また非常なストレスとなる。特定の主張に対する賛成でも反対でもない意見や情報が、議論の中で重要となる状況は少なくないが、この技術の枠組みで議論するとそうした意見や情報を取り扱うことができない。

第二に、論理が巡回するケース（例えば、Ａの根拠はＢ、Ｂの根拠はＣ、Ｃの根拠はＤ、そしてＤの根拠はＡ、といったケース）では、「もはやこれ以下の下位の根拠と理由に展開できない議論の底となるＢＴＭの根拠およびＢＴＭの理由」を到達せず、主張がどこまでいっても掘り下げられていって、結論を得ることが出来ないという状況が少なくないと懸念される（グラフ理論の用語でいう「閉路」に該当するケース）。

第三に、同じ主張に対する根拠や理由、或いは信頼性において、そもそも認識が一致せず、合意を得ることが困難なのである。意見や立場、背景知識などが異なれば、同じ主張に対する信頼性の認識が一致することは期待できない。提案者は、その場合はさらに下位に根拠や理由を展開することにより根拠や理由の信頼性を評価することにより、解決を得ることを期待していると考えられるが、どこまで掘り下げても、「ＢＴＭの根拠およびＢＴＭの理由」まで到達しても、認識が一致しないということが想定される。このシステムがうまく機能するためには、議論の目的や背景知識、基本的な考えかたをある程度共有していることが前提であるか、或いは認識が一致しない場合に信頼性を審判する役割があることが前提でなければならないと考えられる。しかしながら、とりわけ提案者が例として取り上げるような政治的な議題を設定した場合、そもそもどのようなレベルにおいても認識が一致することは期待できず、結局この技術が目標とする、対立関係を解決する論理的な結論を得ることが困難であるといえる。また審判者を想定した場合においても、審判者が相互に対立するいずれの主張からも独立した視点や判断基準を持ちうるかについては、現実問題として難しいといえる。

そもそも、特許文献３で提案されている技術は、議論における対立を論理的に処理し、それぞれの対立に対する結論を得ることを目的としており、対立するそれぞれの立場を共存させたまま処理することは想定されていない。論証に基づく対立の処理より結論を得ることにおいて有効性は認められるが、体系だった知識を整理するのには適していない。

複数の人間がアイデアを持ち寄って議論し、討議の内容を構造化しながら、ドキュメントを作成するためのしくみについては、非特許文献２においても提案されている。これは、「メーリングリスト上に発生した会話を内容の点から構造化し、ユーザに分かりやすい形で表示する機能を提供する」というもので、「メーリングリスト中に発生した会話情報を解析」し、「会話情報を構造化してデータ管理する機能を実現」するものである。さらに、「会話情報から共有文書の修正に関するＴｏＤｏリストを生成し、対象文書の修正状態に基づき、ＴｏＤｏリスト中の修正状態を更新する機能を提供」するものである。しかしながら、この方法では、以下の理由により、多数の参加者の参加する議論の過程で体系だった知識を整理することは必ずしも容易ではない。

第一に、ドキュメントに含まれる内容の一部に関する修正の必要を感じた人によるドキュメントに対する操作が間接的であり、直接的ではないということである。修正内容をドキュメント内において直接提示するわけではなく、ドキュメントとは別に存在するメーリングリストの中で議論し、必要な修正をＴｏＤｏリストとして抽出し、その後担当者が修正を行うというプロセスを経る。日常的に行われている自然なコミュニケーションのなかで議論を行うことができるという利点はあるが、修正の対象となる要素において直接修正案を提示するわけではないため、修正案を提示する者の意図が確実に伝達されない恐れがあり、コミュニケーションの効率が悪化し、また二度手間、三度手間となってしまう場合も少なくない。このようなシステムは、修正を指示する者と指示される者とが分かれている場合や、それぞれの担当が明確である場合等において比較的効率よく機能するかもしれないが、指示命令系統が明確でなく、参加者の役割分担が明確でない場合には効率的に機能しないと考えられる。

第二に、通常やり取りされる電子メールに含まれる文書の一部を言語解析に基づき抽出するというプロセスを経ているため、システムの使い心地は解析の精度に大きく依存する。自然言語によるコミュニケーションにおいては、文化、流行、個人的な癖等の多様なゆらぎが発生するため、例え書き言葉であったとしても、解析の精度については常に問題が発生している。従って、システムの挙動を左右する重要な判断において、言語解析による抽出を用いる方法では、システムは利用者が期待する通りの動作をするとは限らない。特殊な文章で記述したために重要な発言内容が放置されてしまう場面も発生しうると考えられる。そうした状況において、利用者がシステムに正しく解析されるよう記述しようと意識することになれば、結局自然なコミュニケーションができなくなってしまう。

さらに追記するとすれば、議論の内容を構造化したものであるが、アウトプットとして得るべきドキュメントの内容を構造化したものではない。あくまでもメーリングリスト内での議論が中心であり、議論のプロセスと編集のプロセスが別のものとして存在する。議論の内容そのものをドキュメントとして扱う本発明とは、その発想が根本的に異なる。本発明に記載のシステムにおける中心的なプロセスにおいては、議論と編集が同時に処理される。本発明に記載のシステムでは、議論とドキュメントを一体化させることにより、コミュニケーションの一元化を行っている。そこでは、ドキュメントに含まれる要素の内容と構造そのものが議論の主たる対象であり、状況毎に発生する一時的なメッセージ（例えば「要素Ａは要素Ｂと関係Ｒであるべきだ」「要素Ａの内容はＸであるべきだ」といった内容のもの）は、操作の対象とされる要素に付随する情報として扱われる。

なお、以上に示した文献の参照先は下記の通りである。
特開２００３−１４１０２７ 特開２００６−１８６９１ 特開２００４−２００７４１. 「議事録アノーテーションによる議論の支援と再利用に関する研究」清水敏之、２００３年２月 「電子メールをベースにした討議型共同文書作成システムの研究開発」インテック・ウェブ・アンドゲノム・インフォマティクス株式会社、平成１３年１月

複数の参加者を前提としたドキュメント編集または議論のための従来型の一般的なシステムにおける大きな課題のひとつは、ユーザが多様な情報が複雑に絡み合った情報量が膨大なドキュメントまたは議論の内容を、短時間で的確に把握することが困難であるということであった（課題Ａ）。これは本発明が解決しようとする主要な課題のひとつである。

様々なアプローチでこの問題に対する解決に取り組んだモデルも存在する。ただし、多様な情報が複雑に絡み合った情報量が膨大な情報を、短時間で的確に把握することが困難であることは、人間の認知と思考の限界による根本的な制約でもあり、それに対する何らかの解決が提示できたとしても、問題の改善はむしろ程度の問題であり、その解決が充分になされたかどうかを明確に断定することは容易ではない。上記背景技術として挙げた文献に記載された技術は、この問題に対する解決に取り組んだ技術の代表例として挙げたものだ。しかしながら、これらの技術は、複数の参加者を前提としたドキュメント編集または議論のためのシステムにおける課題を全て解決するものではない。

また、上記背景技術に代表される、複数の参加者を前提とし、構成要素の単位で情報を整理する、従来型のドキュメント編集または議論のためのシステムに共通して残されたもうひとつの本質的な課題は、意見や立場の異なる多数の参加者が参加する議論の過程で体系だった知識を整理するのが困難であるということだ（課題Ｂ）。さらに、その要因を解析すると、次のような点が挙げられる。

第一に、一度入力されたドキュメントの内容（ドキュメントの構成要素の内容や構成要素間の構成など）を、各参加者の自由な思考を活用し、かつ全体の秩序を維持しながら、調整または編集するためのメカニズムが提供されていない点である（課題Ｂ１）。従来型のシステムにおいては、そもそも調整または編集するためのメカニズムが存在しない（存在したとしても、管理者等による特別な問題を処理するための例外的な措置のためであり、一般ユーザ間で議論またはドキュメント編集を進める通常のプロセスのなかに組み込まれていない）か、或いは意見や立場の異なる多数の参加者の活動による調整や編集を前提としていない。

第二に、ドキュメントや議論の全体としての秩序や整合性を維持したまま、参加者個人の意見を議論のなかに取り込むための決定的なメカニズムが提供されていない点である（課題Ｂ２）。一般に、参加者個々人の意見を尊重することと、ドキュメントや議論の全体としての秩序を維持することは、両立させにくい課題であるが、意見や立場の異なる多数の参加者を前提としたドキュメント編集や議論を効果的に機能させるためには極めて重要な課題である。「Ｗｉｋｉｐｅｄｉａ」等は、各ドキュメント（用語説明）において複数の参加者による自由な参加（説明行為）と全体としての秩序の維持をある程度両立した優れたシステムを提供し、この問題に対する解決の方法を示すひとつのモデルを提供しているように思われるが、これは利害関係の対立や悪意のある参加者が関与するインセンティヴが充分に小さい（ないわけではない）ため機能しているものであり、参加者間の利害関係の対立が激しかったり、悪意のある参加者が関与するインセンティヴが大きかったりする場合においても、現在と同じくらい適切に機能することは期待できない。

第三に、個人の議論に対する継続的なコミットメントを促すメカニズムが提供されていない点である（課題Ｂ３）。ドキュメントや議論の内容は必要に応じて常に更新や再構成がなされるべきであるにもかかわらず、発言時点での意見等が言いっぱなしの状態（その内容や位置付けに関する見直しが行われない状態）になってしまい、ドキュメントや議論の内容が最適化されない。また発言者に自らの発言の内容や処分に関する責任を持つことが要求されないため、発言時点で無責任な発言をしてしまうことを回避できず、また発言に何らかの理由（感情的になる、認識不足である、思慮不足である、等）により発言に瑕疵がある場合においても、これに関する指摘を受け、修正するための機会を得ることができない。

第四に、ドキュメントや議論を構造化するためのフレームワークが提供されていないか、プリミティヴなものであるため、多様でかつ複雑に絡み合った情報を整理することが容易でない点である（課題Ｂ４）。

第五に、ドキュメント編集や議論の最終的なアウトプットを得ることが想定されているものの場合、ドキュメント編集や議論のプロセスとアウトプットを得るプロセスとが別々に存在するか、効果的に統合されていないため、ドキュメント編集や議論からアウトプットを得る際に内容面でのロスが発生しやすく、アウトプットの内容が直接ドキュメント編集や議論の内容を示すものではない点である（課題Ｂ５）。つまり、ドキュメント編集や会議のシステムが、編集中のアウトプットを扱う層（オブジェクト層）と意見交換や議論を行う層（コミュニケーション層）とに分離されていて、コミュニケーション層の内容とオブジェクト層の内容が直接かつ完全に同期していないということである。

特許文献１で提案されたシステムにおいては、議論と要約が別に存在することが前提とされる（発明内容は議論から要約を作成するシステム）。非特許文献１で提案されたシステムにおいては、対面式の会議とシステム上で扱うデータとが分離されている（提案内容はオフラインの会議における議事録の生成と再利用を行うシステム）。特許文献２で提案されたシステムは、ドキュメント編集や議論のプロセスとアウトプットを得るプロセスとが別々に存在するものではないが、そもそも最終的なアウトプットを明示的に導くことが前提とされたものではない（発明内容は各発言を構造化することにより、議論の内容や流れ、発言が議論に与えた影響の把握を容易とする電子会議システム）。特許文献３で提案されたシステムにおいては、ドキュメント編集や議論のプロセスとアウトプットを得るプロセスとが統合したものといえるが、上記で述べたように、論証の対象とならない発言を取り扱うことや論理が巡回するケースを取り扱うことができないなど、その実現方法に問題がある。非特許文献２で提案されたシステムにおいては、メーリング上での議論とこれを構造化したデータとが別に存在することが前提とされる（提案内容はメーリングリスト中に発生した会話情報を解析し、構造化して管理する機能を提供する解析システム）。

第六に、議論や編集されるドキュメントを収束させるメカニズムが提供されていない点である（課題Ｂ６）。複数の参加者を前提としたドキュメント編集または議論のためのシステムにおいて、ドキュメントや議論の内容を発散させることは極めて容易である（例えば、「２ｃｈ」等の掲示板システムのように、参加者がどんな発言でも自由に書き込むようにしておけばよい）。しかしながら、多様でかつ多数の発言がなされた後、ドキュメント編集や議論の内容を収束させ、結論に近づけていくことは、非常な高度な課題である。上記の背景技術のなかでは、特許文献３に記載されたシステムは、ドキュメント編集や議論の内容を収束させるプロセスを提供しようとしたものであるといえるが、既述した理由により適切に機能するかどうか疑問が持たれ、ドキュメント編集や議論の内容を収束させる決定的な方法であるとはいえない。

第七に、ドキュメント編集や議論のアウトプットが整理された場合においても、そのアウトプットがどのように活用されるかが明確でなかったり、アウトプットが活用されるプロセスから、ドキュメント編集や議論に参加した参加者に何らかの情報がフィードバックされるメカニズムが存在しなかったりするため、参加者の議論に参加するインセンティヴが働きにくい点である（課題Ｂ７）。

本発明は、上記課題に対し、以下の手段を以って解決しようとする。

課題Ａに対し本発明では、議論の構造化、構造化された議論の視覚的表示、この視覚的表示を通じた操作を中心としたいくつかのメカニズムにより、その解決を図る。具体的には、請求項１、請求項２、段落０１４１に記載された各手段により、この課題を解決する。

課題Ｂに関しては、課題Ｂの問題が発生する要因を分析した各課題を解決する下記の手段を総合的に適用することにより、その解決を図る。

課題Ｂ１に対し本発明では、各参加者が新しい発言（要素）を自由に追加することができるようにした上で、要素に対するコントロールを行う権限の管理を行い、既存の要素に関しては、関連する要素に対するコントロールを行う権限を保持する参加者間でのミクロな合意ベースでの編集（構造化等）を可能とすること等により、この課題を解決する。具体的には、請求項１、段落００７５、段落００９８に記載された各手段により、この課題を解決する。

課題Ｂ２に対し本発明では、参加者に対し自由に発言できる環境を提供すると供に自分の発言に対する責任を負うことを要求し、発言間の構成に関しては、関係する発言に対する責任を負う者の間でのコンセンサスにより決定されるようにすることにより、この課題を解決する。これにより、ドキュメントや議論の全体としての秩序や整合性を維持しながら、参加者が個人として言うべきことはきっちり言える環境を提供し、参加者が、自律、分散、協調しながら、ドキュメントや議論全体を発展させていくメカニズムを提供する。具体的には、段落００７５、段落００９０、段落００９８、請求項２、段落０１２８に記載された各手段により、この課題を解決する。

課題Ｂ３に対し本発明では、自分の発言に対するコントロールを行う自由と責任を継続的に付与し、自分の発言が修正されるべきであるとの指摘や提案を受ければ、その指摘や提案を検討した上で発言の内容に反映し、またドキュメントや議論の内容が再構成されれば、それに応じて自分の発言の位置付けを再検討した上で発言の内容に反映することができるようにしておくことにより、この課題を解決する。具体的には、段落００９０、段落００９８、請求項２乃至３に記載された各手段により、この課題を解決する。

課題Ｂ４に対し本発明では、ドキュメントを構成する各要素に意味的位置付け、意味的性質、論理的性質等を示す属性を付与し、各要素を要素間の関係を定義する情報により構造化するアーキテクチャと、これを制限する制約条件とにより、ドキュメントや議論の性質に適した、これを構造化するためのフレームワークを提供することにより、この課題を解決する。具体的には、請求項１、段落０１０７、段落０１１３、段落０１１０、段落０１３７、段落０１３９に記載された各手段により、この課題を解決する。

課題Ｂ５対し本発明においては、オブジェクト層とコミュニケーション層が分離されておらず、議論の場が編集中のアウトプットそのものであり、ドキュメント編集や議論からアウトプットを得る際に期待されない内容面でのロスが発生することはない。具体的には、段落０１１０、段落０１１３に記載された各手段により、この課題を解決する。

課題Ｂ６に対し本発明においては、要素間の関係により定義される構造を支持構造として捉え、各要素（発言）に対する発言者が重視する度合いを支持構造のなかに集約し、競合する複数の要素から特定の要素が選定される際には、高く支持される支持構造を獲得した要素が選定されるメカニズムを採ることができるようにすることにより、この課題を解決する。具体的には、段落０１０７、請求項２などに記載された各手段により、この課題を解決する。

課題Ｂ７に対し本発明においては、ドキュメント編集や議論のアウトプットが活用されるプロセスを明確に設計しておくことを想定し、アウトプットが何らかの方法で活用される過程における情報を、アウトプットに関連するステイタス情報としてモニタリングし、議論の参加者や議論の閲覧者にフィードバックするメカニズムを用いることができるようにして、参加者の議論に参加するインセンティヴを直接または間接的に喚起することを可能とすることにより、この課題を解決する。ここで、議論に参加するインセンティヴを「間接的に喚起する」というのは、議論を閲覧するインセンティヴを高めることにより議論の閲覧者を増やし、多くの人に閲覧される環境を実現することにより議論に参加することのインセンティヴを喚起することをいう。具体的には、段落０１１５、段落０１１７、段落０１３１、請求項３、段落０１３７、段落０１３９に記載された各手段により、この課題を解決する。

以下において、各請求項の記載に基づく解決手段について、その詳細を整理する。

本発明において、請求項１及び以下の請求項に記載のドキュメント入力編集システムとは、少なくとも、ユーザがドキュメントに含まれる要素を入力または特定する機能と、要素の内容及び属性並びに要素間の関係性を編集する機能を具備するシステムをいう。また、ここでいう要素は、ドキュメントに含まれ、ドキュメントを構成する情報であり、文章、発言等ひとまとまりのテキストデータ（タグ等を用いて、フォント、字飾り等の情報が埋め込まれたものを含む）として記録される情報、及び表、グラフ、画像、映像、音声、アニメーション等ひとまとまりのデータ（ファイル、オブジェクト等の形態によるものを含む）として記録される情報を含むことができる。各要素は、各ドキュメントにおいて、その内容の範囲を特定し、他の要素と明確に区別される情報が保持されることにより定義される（具体的にはデータベース、タグ等を用いて実装される）。

請求項１に記載の発明は、ネットワーク上で機能し、複数ユーザの参加が可能なドキュメント入力編集システムであって、該ドキュメント入力編集システムで取り扱われるドキュメントに関する情報を管理するドキュメント情報管理手段と、該ドキュメントに含まれる要素に関する情報を管理する要素情報管理手段と、該ドキュメントに含まれる任意の要素と他の要素との関係を定義する情報（以下、「関係定義情報」）を管理する関係定義情報管理手段と、ユーザ・アカウント情報を管理するユーザ管理手段と、以下に示す少なくともいずれかの手段を用いた操作を行うユーザを識別または認証するユーザ識別認証手段と、ユーザによる操作を通じてドキュメントに含まれる要素を入力または特定する要素入力特定手段と、少なくともいずれかのユーザによる操作を通じて該要素の内容を編集する要素内容編集手段と、少なくともいずれかのユーザによる操作を通じて該要素または該要素の他の要素に対する関係の属性を入力または特定する要素属性入力特定手段と、該関係定義情報管理手段において管理される関係定義情報に基づき該ドキュメントに含まれる各要素をツリー状に構造化された状態で表示する構造表示手段と、要素及び要素間の構造を視覚的（グラフィカル）に表示するユーザ・インタフェース（以下、「GUI」）と、少なくともいずれかのユーザによる該構造表示手段によって表示される要素に対する操作を通じて該要素の他の要素との関係を入力または編集する要素関係入力編集手段と、該ドキュメントに含まれる各要素に関し、当該要素に対する処分を決定する権限（以下、「要素支配権」）を保持するユーザを特定する要素支配ユーザ特定情報を管理する要素支配ユーザ特定情報管理手段と、要素内容編集手段、要素属性編集手段、要素関係入力編集手段の少なくともいずれかを用いた編集操作において、編集対象となる要素または該編集操作に関連する要素が、該編集操作の操作者が要素支配権を保持しない要素である場合、該要素の要素支配権を保持するユーザに、該編集操作の内容について承認を求める承認要求手段と、該承認要求手段が機能するのに応じて、概要その要素支配権を保持するユーザに、該編集操作の内容に応じて承認又は拒絶の意思を特定させる承認拒絶手段と、該ドキュメント入力編集システムにおいて編集操作可能な状態にあるドキュメント（以下、「編集ドキュメント」）を、要素の属性及び関係定義情報並びに該関係定義情報に基づく要素の構造化のパターン等の情報を対象とする明確な規則、または該情報に応じて与えられる明確な規則に沿って、計算機上の処理、特別な権限（以下、「ドキュメント取りまとめ権限」）が与えられたユーザの操作、またはこの両方によって実行されるプロセスによって、整理することにより定義されるドキュメント（以下、「完成ドキュメント」）を作成する完成ドキュメント作成手段と、を具備し、該要素関係入力編集手段は、該GUIにおいて、関係元の要素と関係先の要素の両方もしくは少なくとも一方または要素間の関係を示す表示部を、ポインティング・デバイスによって操作されるポインタの位置及び該ポインティング・デバイスを通じて与えられるイベントによって特定することによって、該編集に必要な情報が与えられるものであり、該完成ドキュメント作成手段において、編集ドキュメントに含まれる各要素（以下、「編集要素」）のうち、完成ドキュメントに含まれる要素（以下、「完成要素」）として取り上げる、または完成要素を作成するための素材とされる編集要素を選定する基準（以下、「要素選定基準」）として、選定の候補となる各編集要素に付随する任意の情報、該編集要素と直接または間接的に関係付けられた要素に関する情報、該関係定義情報に基づく要素の構造化のパターンに関する情報とのうち少なくともいずれかの情報またはこれに基づき計算される情報を評価の対象とする基準が用いられ、該プロセスが該要素選定基準に沿ったものとなるよう制約を受けていることを特徴とするドキュメント入力編集システムである（図１）。

ドキュメント情報管理手段と、要素情報管理手段と、関係定義情報管理手段とは、少なくとも各管理手段が管理の対象とする情報を保持するための記録手段を備えていることが必要であり、通常はデータベースを用いて実現されることが想定されるが、これに限定することなく、ＸＭＬ等のタグ言語を用いて記述されたファイル、或いはその他のスタイルにおいて記録された特別なデータファイルとして実現されることも可能である。なお、ドキュメント情報管理手段と、要素情報管理手段と、関係定義情報管理手段とは、同一のデータベースを用いて実現しても構わない（小規模なシステムとして実装する場合にはむしろ同一のデータベースにおいて、異なるテーブルとして実装するのが通常の設計である）（図２）。いっぽう、ドキュメント情報管理手段と、要素情報管理手段と、関係定義情報管理手段とを、異なるデータベースにおいて実現する場合には、保持するデータの整合性を維持するため、少なくとも、ドキュメント情報管理手段と要素情報管理手段との間、及び要素情報管理手段と関係定義情報管理手段との間において、相互に連携を取ることが期待される。

請求項１の記載による「複数ユーザの参加が可能」であることは、この入力及び編集のうち少なくともいずれかの操作を行うことのできるユーザが、複数（２人、３人、４人、または５人以上）存在することをいう。

また「ドキュメントに含まれる要素を入力または特定する」という文言における「入力する」及び「特定する」の意味は以下の通りである。「入力する」とは、該ドキュメント入力編集システムにおいて編集されるドキュメントに含まれるべき要素を、該ドキュメント入力編集システムを構成し、ユーザが利用するインタフェース（クライアント・コンピュータ等。ただし、コンピュータに限らず、携帯電話、ＰＤＡ、カメラ、ボイス・レコーダ等、ユーザ・インタフェースと通信手段を備えた他の種類に分類される装置であっても構わない）における何らかの入力手段（キーボード、ポインティング・デバイス、マイク、カメラ、タッチパネル等）を通じて新たに入力することとする。「特定する」とは、該ドキュメント入力編集システム内に存在する情報（該ドキュメント入力編集システムにおいて扱われる既存のドキュメントや該ドキュメントの構成要素等）、もしくは該ドキュメント入力編集システムの外部に存在し、対象として特定することが可能な任意の既存の情報（記事、論文、書籍、レポート、写真、映像、音声等の各種情報の一部もしくは全て）を特定する情報を付与することとする。

また、請求項１に記載の「いずれかのユーザ」とは、該ドキュメント入力編集システムを利用するユーザの部分集合に該当するユーザであり、各操作の対象となる要素を入力または編集したユーザ、該要素と一定の関係（対象要素の親要素または子要素、対象要素と親要素や子要素を共有する要素などとの関係（一次的関係）、対象要素と一次的関係にある要素との間で一次的関係にあり、対象要素及び対象要素との間で一次的関係に該当する要素を除く要素との関係（二次的関係）、対象要素と二次的関係にある要素との間で一次的関係にあり、対象要素及び対象要素との間で一次的関係または二次的関係に該当する要素を除く要素との関係（三次的関係）、同様に四次的関係、以下同様、及び、規則的に定められるこれらの部分集合、など）（以下、「一定関係」）にある要素を入力または編集したユーザ、特定の権限が付与されたユーザ等が該当し得る。

ここで、要素または該要素の他の要素に対する関係の「属性」とは、各要素または各要素の他の要素に対する関係に付随し、当該要素の種類、位置付け、特徴等を示す情報を指すものとする。各要素に必ずひとつずつ与えられるものとは限らず、複数付与されることや、何も付与されないことも想定される。属性は、入力（例えば、名前を自由につけて属性を定義すること）や特定（例えば、予め準備されたリストから選択すること）により与えられるようにしておくことが想定される。またはこの組み合わせとして、通常はリストから選択して特定するが、適当な属性がリストに存在しない場合には新たに定義を付与する、といった方法で与えることができるようにしておくこともできる。また、「編集」とは、いずれかのユーザが、対象となるドキュメントにおいて、既に保持されている情報を元にして、これに対する修正（要素の内容や属性の修正、要素間の関係の修正を含む）、新たな要素の追加（要素の入力や特定を含む）、及びこれらを複合的に組み合わせた操作をいう。また、該属性を、要素毎にではなく、関係毎に付与するようにしておくことも想定される。属性は、要素に付随する情報として持たせることも可能であるが（図５−Ａ）、関係定義情報に付随する情報として持たせることも可能である（図５−B）。

また請求項１に記載の「ドキュメントに含まれる任意の要素と他の要素との関係を定義する情報」（関係定義情報）を、データベース（以下、「DB」）において実装する設計方法としてはいくつかの方法が考えられる。例えば、該ドキュメントに含まれる要素の内容等（当該要素の属性を含むこともできる）を定義するテーブルとは別に、任意の要素間の関係性を定義するリレーション・テーブルを用いて実装する方法が考えられる（図６−Ａ、図６−Ｂ）。また、相互に関係を持つ少なくとも２つの要素において、少なくとも１つの要素を関係元要素、他の要素を関係先要素として取り扱うことを想定し、関係元要素の内容等を定義する行において、該関係元要素と関係を有する該関係先要素との関係を定義する情報を保持するという方法も考えられる（図６−Ｃ）。或いは、関係元要素と関係先要素の双方において、該関係元要素と該関係先要素との間の関係に関する情報を保持するという方法も考えられる。これらは、DBの設計方法の例であり、他にも様々な設計方法が可能である。また、各要素は他の要素との関係を保持することができるが、全ての要素が他の要素に関連付けられていることは必要ではなく、ドキュメントに含まれる要素の一部は一時的または継続的に独立して存在しても構わない。他の要素に関連付けられるための条件が満たされない場合、継続的に独立して存在し続けることになる。

請求項１に記載のドキュメント入力編集システムは、少なくともいずれかのユーザによる操作を通じて該要素の属性を編集する要素属性編集手段を具備することができる（図３、図４）。

請求項１に記載のドキュメント入力編集システムは、属性が、他の要素との関係における意味的位置付けを示す情報であることができる。

ここで「他の要素との関係における意味的位置付け」とは、閲覧者が要素を解釈する際に、解釈の対象となる要素によって指示される内容が他の要素との関係においてどのような類のものであるかを定義する、解釈上の助けとなる情報であり、見出し、小見出し、本文といった、単なる構造的位置付け（内容に関わらず与えられる、文章構造上の位置付けを定義する情報）とは区別したものである。意味的位置付けの例としては、支持、反論、コメント、対案等が挙げられる。

請求項１に記載のドキュメント入力編集システムは、属性が、該属性が与えられた要素の意味的性質を示す情報であることができる。

ここで「意味的性質」とは、閲覧者が要素を解釈する際に、解釈の対象となる要素によって指示される内容がそれ自体においてどのような類のものであるかを定義する、解釈上の助けとなる情報である。文章中の位置付けにかかわらず付与することができる属性情報であるという点において上記「意味的位置付け」とは異なる。意味的性質の例としては、事実、法律、要望、問題、認識、提案等が挙げられる。

請求項１に記載のドキュメント入力編集システムは、属性が、他の要素との関係における論理的性質を示す情報であることができる。

ここで「他の要素との関係における論理的性質」とは、対象要素が他の要素との関係において持つべき論理構造上の位置付けを解釈するために与えられる情報である。論理的性質の例としては、仮説、真、偽、原因、結果、必要条件、充分条件、前提、根拠等が挙げられる。前提や知識を共有しない複数の参加者により展開されるドキュメント入力編集システムにおいては、同じ要素に対して相反する複数の属性が、各参加者の解釈を特定する情報として、多重にまたは同時に設定され、またそれによって複数の解釈体系が構成されることが想定される。このように属性の多重性を適用した場合には、どの解釈体系において、どの構造がロジックとして破綻しているのかということを明確化して示すといった機能を有するアプリケーションを構築することができる。

なお一部の属性に関しては、意味的位置付け、意味的性質、論理的性質のうち複数のいずれとしても扱うことが可能なものも存在する。また、意味的位置付けを示す属性情報、意味的性質を示す属性情報、論理的性質を示す属性情報は同じ要素に対して重複して付与することも可能である。また、他の要素との関係の変化に応じて、ある種類の属性情報（例えば、意味的性質を示す属性情報）を付与していた要素に別の種類の属性情報（例えば、意味的位置付けを示す属性情報）を付与しなおす操作を行うことも想定される。

請求項１に記載のドキュメント入力編集システムは、複数の要素の関係がツリー構造として定義される特徴を有する。

なお「ツリー構造」とは、グラフ理論において定義される木の構造を適用したデータ構造であり、各要素（ノードと呼ばれる）が枝分かれした階層構造のなかに位置付けられることにより構成される。要素と要素の関係を枝（エッジ）ともいう。直接接続されたノード間の関係を親子関係と呼び、「ルート」（親要素を持たず、ツリー構造の頂点に位置付けられるノード）に近い側のノードを「親」、ルートから遠い側のノードを「子」と呼ぶ。一般的なツリー構造においては、ルート以外の全てのノードはただひとつの親との関係を持つ。各ノードはひとつまたは複数の子を持つことができ、子を持たないノードは、ツリー構造の末端に位置付けられ、「リーフ」と呼ばれる。ルートを除く全てのノードから親ノードの方向に関係を辿るとルートに到達する。ノードＡから親ノードの方向に関係を辿ってルートに到達するまでの間にノードＢが位置する場合、ノードＡをノードＢの「先祖」と呼び、ノードＢをノードＡの「子孫」と呼ぶ。また、親を共有する任意のノードを「兄弟」と呼ぶ。（当業者であれば、一般的なツリー構造、及びこれを変形したものに関するバリエーションに関する知識を有するものとして、ここではこれ以上の詳細の記述を省略する。）

要素間の関係が循環する（親ノードの方向にずっと関係を辿っていくと元のノードに到達する）ことはないなど、ツリー構造においては、ツリー構造の定義に該当するための条件が存在し、段落００６２に記載のドキュメント入力編集システムにおける複数の要素の関係はこれを満たしているものと期待される。ただし、様々な類の関係が多重に与えられるケースも想定されるが、その場合には必ずしもツリー構造の定義に該当するための条件を満たすとは限らない。しかしながら、特定の条件を満たす関係のみを考慮した場合に、ツリー構造を保持しているという場合には、各要素をツリー構造として表示する処理が可能であるため、段落００６２に記載のドキュメント入力編集システムに該当するものとする。

請求項１に記載のドキュメント入力編集システムは、要素が他の複数の要素に関係付けられることができることができる。

「要素が他の複数の要素に関係付けられること」を可能とするためには、リレーショナル・データベースを用いて、要素間の関係に関するデータを保持するテーブルを要素自体に関するデータを保持するテーブルとは別に定義するなど、システム設計上の工夫をすることが必要となる（図８）。このとき、要素間の関係に対しては、方向性の有無、循環性の有無、重み付けの有無、要素間の入出力を伝播させる機能の有無、構造パターンによる制約の有無等、様々な制約条件を設定することが想定される。これにより、グラフ理論（ノードとエッジの集合で構成されるグラフに関する研究領域）において研究される様々なタイプのグラフ構造（或いはネットワーク構造）を取り扱うことが可能となる。様々なバリエーションが考えられるものの、この制約条件は、それぞれのドキュメント入力編集システムにおいて取り扱われるドキュメントや議論の性質を考慮した、どうシステム上でのルールとして適切なものを付与することができるようにしておくことが期待される。

なお、段落００６２の記載を継承し、段落００６５に記載に該当するドキュメント入力編集システムの場合、ある要素が複数の親要素を保持することができることをいうものとする。通常のツリー構造は、ルート要素以外の全ての要素は親要素との関係を必ずただ一つ保持するものとしてデータ構造を定義することができる。一部の要素が複数の親要素との関係を保持することにより、同じ要素群においてツリー構造が多重に存在することができる。なお、この場合、子要素との関係は考慮に含めずにデータ構造を解釈した記述であることを確認する。子要素との関係を考慮に入れる場合、ルート要素とリーフ要素以外の全ての要素は、ただ1つの親要素との関係と１つ以上の子要素との関係を保持するため、複数の要素に関係付けられていることになるが、段落００６２の記載を継承し、段落００６５に記載に該当するドキュメント入力編集システムの場合、各要素の親要素に対する関係のみが複数保持されることを意図したものであり、子要素との関係はカウントせずに解釈するものとする。

請求項１に記載のドキュメント入力編集システムは、要素及び要素間の構造を視覚的（グラフィカル）に表示するユーザ・インタフェース（以下、「GUI」）を具備し、要素の他の要素との関係を入力または編集する要素関係入力編集手段は、該GUIにおいて、関係元の要素と関係先の要素の両方もしくは少なくとも一方または要素間の関係を示す表示部（ライン、エリア等）を、ポインティング・デバイスによって操作されるポインタの位置及び該ポインティング・デバイスを通じて与えられるイベントによって特定することによって、該編集に必要な情報が与えられるものである特徴を有する。

ここで「ポインティング・デバイス」とは、コンピュータのディスプレイで表示される情報に対し、座標や対象を特定する機能を有する装置であり、マウスやトラックパッド、トラックボール、スティック型ポインティング・デバイス、タッチパネル等が例として挙げられる。「ポインティング・デバイスを通じて与えられるイベント」の例としては、ドラッグ、ドロップ、クリック等、及びこれらの組み合わせによる操作（ドラッグ・アンド・ドロップ操作等）が挙げられる。

なお、請求項１に記載のＧＵＩ上における、要素の他の要素との関係を入力または編集するための操作の例としては、関係元となる要素をドラッグ操作で関係先となる要素の上に動かしドロップ操作を行う等の操作が挙げられる。例えば、既に他の要素に関係付けられている要素或いはどの要素とも関係付けられていない要素（以下、「要素Ａ」）を、既に存在する別の要素（以下、「要素Ｂ」）の子として位置付ける（即ち、要素Ａの要素Ｂに対する関係を付与する）際に、ユーザが要素Ａをドラッグして要素Ｂの上に持っていってポインタをリリースすると、システム上では、要素Ａが要素Ｂの子となるように、要素Ａの他の要素に対する関係を定義する関係定義情報を編集するといったプロセスが処理されるようにしておくことができる（図１０）。或いは、既に他の要素との関係が定義されている要素Ｃの関係先要素との関係を切断する際に、ユーザが要素Ｃを右クリックすると「親要素との関係を切断する」といったメニューを表示し（或いは、ユーザが要素Ｃの親要素に対する関係を示すラインを右クリックすると「この関係を切断する」といったメニューを表示し）、ユーザがこのメニューを選択すると、システム上では、要素Ｃの親要素に対する関係が切断されるよう、要素Ｃの他の要素に対する関係を定義する関係定義情報を編集するといったプロセスが処理されるようにしておくことができる（図１１）。

請求項１に記載のドキュメント入力編集システムは、複数のドキュメントを同時に開いた上で、異なるドキュメントに含まれる要素間の関係を入力または編集することを可能とする異文書要素間関係入力編集手段と、いずれかのドキュメントに含まれる要素（または要素セット）の帰属を他のドキュメントに変更することを可能とする要素帰属先文書変更手段と、いずれかのドキュメントに含まれる要素（または要素セット）のコピーを他のドキュメントに含まれる要素として作成することを可能とする要素異文書複製手段と、いずれかの要素（または要素セット）を複数のドキュメントに同時に帰属させることを可能とする要素複数文書同時帰属手段とのうち、少なくともいずれかを具備することができる（図１２）。

このとき、特定の対象となる要素は必ずしも１つだけでなくてもよい。特別な操作（例えば、ＧＵＩ上で指定されたエリアに含まれる要素を選択状態とする方法、Ｃｔｒｌキー等を押しながらＧＵＩ上でポインタを合わせてクリックすると選択状態である要素の一覧に加えられるようにする方法等）で複数の要素を同時に特定した上で、これらの複数の要素を一度に同様の編集操作の対象とすることも想定される。

なお、段落００７１の記載においては、要素を操作の対象として挙げているが、該要素だけでなく、該要素を特定することまたは該要素を含む範囲を特定することによって指定されうる、関係付けられた複数の要素（以下、「要素セット」）を一括して操作の対象とすることも想定される（なお、該要素セットに含まれる要素の範囲は、該要素と一定関係にある要素として指定されうる。例えば、要素間の構造がツリー構造として定義される場合のシンプルな例を挙げれば、特定された要素の下位（子孫）に位置づけられる全ての要素を含め、要素セットとして扱うことができる）。その際には、該要素セットが該要素セットの内容や構造を維持したまま、関係付け、帰属変更、コピー作成、同時帰属等されることが想定される。

これにより、各ドキュメントの構成を維持したまま、このドキュメントに含まれる情報を、他のドキュメントから参照し、または他のドキュメントに取り込むことを可能とし、ドキュメントに含まれるリソースの有効活用や最適配置を促進する。

請求項１に記載のドキュメント入力編集システムは、該ドキュメントに含まれる要素によって構成される情報の全体的構造を表示する全体的構造表示手段と、該全体的構造の一部である局部的構造を表示する局部的構造表示手段とを具備し、該局部的構造表示手段において表示される局部的構造の該全体的構造におけるポジションを特定する情報を該全体的構造表示手段において表示する機能と、該全体的構造表示手段において特定されたポジションまたは範囲に位置する要素を含む局部的構造を該局部的構造表示手段において表示する機能とのうち、少なくともいずれかを具備することができる。

即ち、全体的構造と局部的構造を別のフィールドで表示し、該全体的構造のなかでの該局部的構造のポジションまたは範囲を示す情報を、該全体的構造を表示する手段において表示する機能と、全体的構造のなかで特定されたポジションに位置する要素を含む局部的構造を、該局部的構造を表示する手段において表示する機能とのうち、少なくともいずれかを具備するものである。言うまでもないが、局部的構造表示手段において表示される局部的構造およびこれを構成する各要素の情報は、全体的構造表示手段上で表示されるよりも詳細なものであることが期待される。

「該全体的構造のなかでの該局部的構造のポジションまたは範囲を示す情報を、該全体的構造を表示する手段において表示する機能」を実装する場合、局部的構造表示手段に表示される局部的構造が移動すると、これに応じて全体的構造表示手段において表示される範囲の位置も移動することが期待される（図１３−Ａ）。このとき、全体的構造表示手段上で新たに任意の範囲（例えば、ポインタをドラッグした両端を対角線とする長方形に含まれる範囲）を指定した場合に、この範囲に含まれる局部的構造を局部的構造表示手段に表示するようにしておくこと（図１３−Ｂ）や、形状と大きさが固定された範囲を特定するエリアをポインタによるドラッグ＆ドロップ操作で移動することにより特定された局部的構造を局部的構造表示手段に表示するようにしておくこと、等により、局部的構造表示手段と全体的構造表示手段の連携による操作のユーザビリティを向上させることが期待される。

また「全体的構造のなかで特定されたポジションに位置する要素を含む局部的構造を、該局部的構造を表示する手段において表示する機能」を実装する場合、例えば、全体的構造表示手段上で表示される全体的構造に含まれる要素をクリックすると、クリックされた要素をルートに見立て、この要素に直接的または間接的に関連付けられた要素をこの要素にぶら下げて構成されるツリー構造を、局部的構造表示手段において表示するようにしておく等の方法が考えられる（図１３−Ｃ）。

なお「全体的構造」とは、必ずしも該ドキュメントに含まれる要素によって構成される情報の全体をカバーするものではなく、局部よりも全体に近いマクロな範囲の情報をカバーするものも含むものとする。また、全体的構造表示手段は、全体的構造を必ずしも一画面で表示できる必要はなく、画面をスクロールする等の操作を通じて容易な操作で全体的構造が確認できるものであれば構わない。

請求項１に記載のドキュメント入力編集システムは、少なくとも該ドキュメントに含まれる要素を特定することが可能な入力情報を与えることにより、該要素と特定の関係にある他の要素の表示／非表示を切り替える特定関連要素表示切替手段を具備することができる。

なお、特定される要素は必ずしもひとつでなくても構わない。即ち、「少なくとも該ドキュメントに含まれる要素を特定することが可能な入力情報」には、ただひとつの要素を特定する情報だけでなく、要素を検索する情報、要素の種類や範囲を指定する情報など、要素の集合を定義する情報が含まれる。例えば、ある属性を持つ全ての要素を特定し、それらの要素の子として位置付けられる要素（属性により範囲を制限することも可）の表示を消す（非表示にする）といった操作等を可能とすることが想定される（図１５）。

「該要素と特定の関係にある他の要素」とは、該要素を特定することを通じて特定される範囲に含まれる要素の集合を指すものである。例えば、複数の要素の関係がツリー構造として定義される場合には、特定された要素の下位（子孫）に位置付けられる全ての要素を表示／非表示の切り換えの対象として扱うことが想定される（図１４）。複数の要素の関係がネットワーク構造として定義される場合には、特定された要素と直接接続された要素と間接的に接続された要素（範囲を制限する情報を与えることが期待される。例えば、「特定された要素と直接接続された要素およびこれに直接接続された要素」、など）を表示／非表示の切り換えの対象として扱うことが想定される。その他、任意の参照関係に基づく範囲指定、要素の内容や属性の同一性や類似性、相違性、関連性等に基づく範囲指定、要素に関する履歴情報に基づく範囲指定、これらを複合的に用いた範囲指定等により、表示／非表示の切り換えの対象となる要素を確定することが想定される。例えば、「質問」という属性を保持する全ての要素を対象として特定し、その全ての要素の子としてぶら下がっている各要素のうち、「回答」という属性を持ち、過去７日以内に入力または編集された要素を、最近入力または更新されたものから順に３つまでを表示する、といった操作を可能とすることが想定される。

また、表示／非表示の切り換えの対象とされる要素の表示／非表示に関するステイタスを明確にするための情報を表示する仕様を持たせておくことも想定される。例えば、切り換えの対象とされる要素が、表示されている状態では「−」（マイナス）記号を含むアイコンを表示し、表示されていない場合には「＋」（プラス）記号を含むアイコンを表示し、存在しない場合にはこれらのアイコンを表示せず、表示／非表示に関するステイタスの変化に応じてこのアイコンを切り替えるという仕様を採用することが可能である（図１６）。このとき、「少なくとも該ドキュメントに含まれる要素を特定することが可能な入力情報」は、これらのアイコンをクリックする操作により与えられることが想定される。

請求項１に記載のドキュメント入力編集システムは、要素に付随する任意の情報のうち少なくともいずれかの照合を行うことにより、要素を検索する要素検索手段を具備し、該要素検索手段を通じて抽出された要素（以下、「抽出要素」）のみ、もしくは、該抽出要素及び該抽出要素と特定の関係にある要素のみ、を構造化された状態で表示する抽出関連要素構造表示手段、または、該要素検索手段を通じて抽出された抽出要素を強調して表示する抽出要素強調構造表示手段、のうち少なくともいずれかを具備することができる。

例えば、抽出関連要素構造表示手段が用いられる際の処理プロセスの例としては、ユーザが検索語を入力して検索ボタンを押した際に、全ての要素の内容を検索し、検索語にマッチする用語を含む要素（類義語、反義語等、検索語と関係する用語にマッチする用語を含む要素を含めることも想定される）を抽出し、抽出された要素のみを構造表示手段に表示するといったプロセスが挙げられる（図１７−Ａ）。或いは、ユーザが特定の属性（例えば「問題」）を指定し、これに該当する属性を持つ全ての要素（要素が属性を複数保持することができる場合は、第一属性、第二属性等、マッチングの対象とする属性を制限することも想定される。また異なる属性が細分化や関係付等で整理されている場合は、例えば「問題」という属性を指定した際に、「問題」に関係する他の属性、「深刻問題」、「通常問題」、「軽度問題」等が付与された要素を併せてマッチングの対象とすることも想定される。さらに、同じ要素にプライオリティの異なる複数の属性が与えられる場合や、何らかの形で各属性に重要性等の程度が付与されている場合には、このプライオリティや程度を、抽出要素を表示する際の順序決定に用いる等の応用も想定される）を抽出し、この抽出された要素の親に該当する要素及びこの抽出された要素に関連付けられた特定の属性（例えば「解決案」）が付与された要素と併せて、構造表示手段に表示するといったプロセスが挙げられる（図１７−Ｂ）。また、抽出要素強調構造表示手段が用いられる際の処理プロセスの例としては、このように抽出された要素を強調した上で、抽出されていない要素と併せて表示するといったプロセスが挙げられる（図１７−Ｃ、図１７−Ｄ）。

「要素に付随する任意の情報」の例としては、要素の内容、属性、関係定義情報、入力日時、更新日時、データベースにおいて整理される際のＩＤ等が挙げられる。また「抽出要素を強調して表示する」とは、抽出要素を示す情報を、通常もしくは他の要素と比較して異なる表示形式（例えば、別色、太字、異なるフォント、下線、点滅等）で表示することである。

請求項１に記載のドキュメント入力編集システムは、要素の表示順序または表示位置の決定または調整に影響を及ぼすソーティング条件情報を入力または特定するソーティング条件情報入力特定手段を具備することができる。

例えば、複数の要素の関係により構築される構造がツリー構造の場合、同じ親を共有する兄弟要素を表示するときの表示順序を設定するための手段として用いられることが想定される。「ソーティング条件情報」の例としては、入力や編集がなされた日時による時系列の順、他の要素との間に保持する関係の数の順、参照される頻度の順、重要性や支持の大きさを示す値（要素毎に与えられる値）の大きい順、（複雑または曖昧な検索情報が入力される場合には）その検索条件との一致度が高い順、等を指定するソーティング条件情報が考えられる。

段落００８４に記載の「要素検索手段」で用いられる検索条件情報を入力または特定する手段や、段落００８７に記載の「ソーティング条件情報入力特定手段」は、これらの条件を入力するためのテキスト・フィールドや、予め定められた条件情報を特定するリストやボタン、複合的に定められる複雑な条件情報を入力するために複数の入力手段を組み合わせたパネル等として実装されることが想定される（図１８）。

請求項１に記載のドキュメント入力編集システムは、該ドキュメントに含まれる各要素に関し、当該要素に対する処分を決定する権限（以下、「要素支配権」）を保持するユーザを特定する要素支配ユーザ特定情報を管理する要素支配ユーザ特定情報管理手段を具備し、かつ、要素内容編集手段、要素属性編集手段、要素関係入力編集手段の少なくともいずれかを用いた編集操作において、編集対象となる要素または該編集操作に関連する要素が、該編集操作の操作者が要素支配権を保持しない要素である場合、該要素の要素支配権を保持するユーザに、該編集操作の内容について承認を求める承認要求手段と、該承認要求手段が機能するのに応じて、概要その要素支配権を保持するユーザに、該編集操作の内容に応じて承認又は拒絶の意思を特定させる承認拒絶手段と、を具備する特徴を有する。

要素支配ユーザ特定情報管理手段において管理される要素支配ユーザを特定する情報は、要素の内容を記録するテーブルと同じテーブルにおいて保持されていても、要素の内容を記録するテーブルとは異なるテーブルにおいて保持されていても構わない（図１９−Ａ、図１９−Ｂ）。

編集対象となる要素が、編集操作者が要素支配権を保持しない要素である場合に、該要素の要素支配権を保持するユーザに承認を求めるプロセスと、編集操作に関連する要素が、編集操作者が要素支配権を保持しない要素である場合に、該要素の要素支配権を保持するユーザに承認を求めるプロセスとは、順を追って処理しても、同時に処理しても構わない（図２０では順を追って処理するプロセスを例として記載している）。

ここで「当該要素に対する処分」とは、当該要素または当該要素の付随する任意の情報の更新、複製、削除等の処理をいうものであり、要素内容編集手段、要素属性編集手段、要素関係入力編集手段等を用いて実行される処理を含む。要素支配ユーザ特定情報管理手段においては、要素毎に設定される各ユーザの要素支配権を、処分の内容毎に設定するようにしておくことも想定される（図１９−Ｃ）。また、通常、要素支配権は要素毎にそれぞれ１人のユーザに独占的に付与されるものと想定することができるが、これは必須ではない。また、管理的な役割を担うユーザには、該ユーザが管轄するドキュメントに含まれる全ての要素（他のユーザが要素支配権を保持する大部分の要素を含む）に対する一定水準の要素支配権を、要素毎に保持される要素支配権と併せて付与しておくことも想定される。

また「編集操作の内容について承認を求める承認要求手段」は、少なくとも、編集操作を行うユーザ（編集操作ユーザ）が承認を求める編集内容を入力するためのインタフェースと、編集の対象となる要素の要素支配権を保持するユーザ（要素支配ユーザ）に該編集内容を提示し、要素支配ユーザがこれに対する承認の可否を入力するためのインタフェースと、これらのインタフェースを通じた入出力情報を処理するプログラムとが存在することによって実現される。ただし、「編集操作ユーザが承認を求める編集内容を入力するためのインタフェース」は、通常の編集操作を入力する画面があれば充分であり、編集対象となる要素または編集操作に関連する要素が、編集操作ユーザが要素支配権を保持する要素でない場合に、要素支配ユーザに対し、該編集操作の内容について承認を求める処理を実行するようにしておくことにより実現することができる。なお「編集の対象となる要素の要素支配権を保持するユーザ（要素支配ユーザ）に該編集内容を提示し、要素支配ユーザがこれに対する承認の可否を入力するためのインタフェース」は、該ドキュメント入力編集システムに含まれるものであっても構わないし、該ドキュメント入力編集システムとは別に存在するものであっても構わない。該ドキュメント入力編集システムに含まれるものである場合には、例えば、各ユーザ個人向けのものとして準備される画面において、ユーザ自身が要素支配権を保持する全ての要素に関する編集の提案（承認を求める要求）の一覧を表示する画面と、この一覧を構成する各提案を選択することにより開くことのできるその提案の詳細について表示する画面とを提供し、そのなかで必要な情報や機能を配置しておくことにより実現される（図２１）。また、該ドキュメント入力編集システムとは別に存在するものである場合には、該編集内容を伝える情報（テキストや画像などにより与えられる）と、該編集操作への承認の可否を指定するための情報（これはＵＲＬ等のリンク情報として与えられ、少なくとも該ドキュメント入力編集システム及び該編集操作を特定する情報が必要であり、承認の可否を指定するためのコマンド機能を有する情報を含むことができる）とを含むメッセージを、本人が使用するメール・ソフトやメッセンジャー・ソフトを通じて表示することができれば、この条件を満たす。このメールやメッセンジャーのソフトウェアから承認の可否を直接入力できるようにしておくことが可能である。或いは、メールやメッセンジャーのソフトウェアで受け取ったメッセージの内容を確認したあと、一度該ドキュメント入力編集システムにおける各ユーザ個人向けのものとして準備された画面を開いた上で、詳細を確認したり、商人の可否を指定したりすることができるようにしておくことも可能である。

あるユーザによるある要素に対する編集操作において、この要素の要素支配権を保持する他のユーザ（要素支配ユーザ）に編集内容に関する承認を求める要求に対し、この要素支配ユーザからの承認の反応が得られた場合に、システムは、この編集操作によって予約された更新処理を実行し、拒絶の反応が得られた場合には、この編集操作によって予約された更新処理を破棄することが期待される。また、この要求に対し、一定期間内にこの要素支配ユーザからいずれの反応も得られなかった際には、承認の反応が得られたものと見做し、この更新処理を実行するようにしておくことも考えられる（図２０）。

さらに、該承認要求手段に付随する機能として、編集操作ユーザが承認を求める際の画面において該編集操作の意図などについてのコメントを別途要素支配ユーザに対するメッセージとして入力し、要素支配ユーザがこれに対する承認の可否を入力する際の画面にこのメッセージを表示できるようにしておくこと（図２２）や、要素支配ユーザが承認の可否を入力する際の画面において承認の可否の理由についての説明や編集操作ユーザからのメッセージへの返答を編集操作ユーザに対するメッセージとして入力し、編集操作ユーザが承認の可否を確認する画面にこのメッセージを表示できるようにしておくこと、などが可能である。その際には、各要素について、過去になされた編集内容に関する情報（編集操作者に関する情報を含む）に加え、編集操作ユーザから要素支配ユーザへのメッセージや、要素支配ユーザから編集操作ユーザへのメッセージの履歴情報が閲覧できる機能を提供することが可能である（図２３）。

通常の能力を有する多くの利用者の参加する議論の場において、最初から精度の高い情報が、精度の高いポジションにおいて、精度の高い属性値が付与されたうえで入力されることを期待するのは困難である。現実世界においても、参加者の主体性が認められる会議であれば、多くの議論は提案と調整の繰り返しのプロセスを経て展開されるのが通常である。その際、各発言の内容および位置付けを、相互のコンセンサスを確認しながら、柔軟に調整するしくみがなければ、議事を効率的かつ効果的に進めることは困難となる。この問題に対し、各要素に対する要素支配権を設定したうえで、要素の内容や属性、要素間の構成の調整には関係する要素に対する要素支配権を保持するユーザの承認が必要とされるメカニズムを用いることにより、ドキュメントや議論の全体としての秩序や整合性を維持したまま、参加者個人の意見を議論のなかに取り込み、各要素の内容、属性、関係等を柔軟に更新することを可能とするメカニズムを提供する。

請求項１に記載のドキュメント入力編集システムは、要素入力特定手段、要素属性入力特定手段、要素内容編集手段、要素属性編集手段、要素関係入力編集手段等を用いることにより可能となる各操作の権限がユーザ毎に付与されることができる。

即ち、ユーザ毎に操作権限を設定することができるものである。操作権限をユーザ毎に設定する場合のユーザ情報を記録するデータ構造としては、各操作権限を個別に設定する場合や、権限レベルを設定することにより各操作権限を設定する場合等が想定される（図２４）。これにより、ユーザの能力、資格、貢献度、当事者度、信頼度、誓約事項等に応じて、各ユーザに実行可能な操作を別々に設定することが可能となる。これは、会議、ドキュメント編集等におけるコミュニケーション、コラボレーションを円滑かつ効果的に進行させる上で重要な要件になると考えられる。

さらに、各操作の対象となるドキュメントや要素の範囲を制限した上で各権限を付与するとより効果的に機能する。例えば、ドキュメント毎に異なるルールを設定し、これに対する誓約を行ったユーザが一定の権限を取得するしくみや、自身が要素支配権を保持する要素と特定の関係にある要素という範囲においてのみ特定の権限を行使することができるしくみ等として運用することができる。

請求項１に記載のドキュメント入力編集システムは、該要素関係入力編集手段によって定義される各要素の他の要素との関係により構成される構造が、各要素に付随する任意の情報または既に与えられている要素間の関係に基づく全体的もしくは局部的な構造化状況に関する条件によって制約されていることができる。

ここで「各要素に付随する任意の情報」とは、当該関係の関係元または関係先となる要素に付随する、要素の内容、属性、関係定義情報、入力日時、更新日時、データベースにおいて整理される際のＩＤ等を示す情報をいう。例えば、親子関係という構造に該当する２つの要素においては、親要素の関係定義情報は子要素の関係定義情報よりも新しく更新されたものであってはならないという制約（即ち、各要素は該要素の関係定義情報よりも古い関係定義情報を有する要素の親になるという関係の構造を構成することはできないという制約）等がこれに該当する。また「既に与えられている要素間の関係に基づく全体的もしくは局部的な構造化状況に関する条件」には、要素間の関係性があるパターン（或いはテンプレート）に収まることや、ある要素と関係付けられる要素数等に関する条件等が含まれる。例えば、予め定められた全体的または局部的な構造のパターンがあり、一度あるパターンが満たされた構造は一定水準において固定され、特別な場合を除き、編集の対象とすることができないという制約等がこれに該当する（なお、ここで「特別な場合」とは、ドキュメントの編集を円滑に進めるために必要な一定の状況が満たされた場合などであり、例えば、固定された構造の部分構造と置き換えるべき構造を、固定された構造の外側で編集し、固定された構造の部分構造よりもこれと置き換えるべき構造がある評価基準において一定以上高い評価を得た場合といったものが想定される）。

請求項１に記載のドキュメント入力編集システムは、各要素が、該要素と他の要素との関係において特定条件を満たした際に、予め定義されたルールに従い、該要素の属性、該要素の他の要素との関係、またはこの両方を自動的に変化させる要素関係自動編集手段を具備することができる。

即ち、要素が他の要素との関係において特定条件を満たすことをトリガーとして、要素の属性、他の要素との関係、またはこの両方を、予め定義されたルールに従い、自動的に変化させる手段を具備するものである。ここで「自動的に」とは、特段の操作を行わなくてもその変化が発生することをいう。なお、この「特定条件」及び「ルール」は、当該要素に与えられる属性毎に、または当該要素に与えられる属性と当該要素と特定の関係にある他の要素に与えられる属性とのパターン毎に、異なるものを定義することができる。

ここに記載のルールの例としては、「説明」という属性が与えられる要素Ａの下に、「換言」という属性が与えられる要素Ｂがぶら下がっている状況において、要素Ｂの支持指数（その要素の内容がどの程度のユーザの支持を獲得するものであるかを示すものとして要素毎に設定される尺度。各ユーザが各要素に対し支持／不支持を明示的に示すことにより計算される変数として実装することや、子や子孫の数や内容、属性等に応じて計算される変数として実装することが想定される）が要素Ａの支持指数を上回った際に、要素Ｂと要素Ａのポジションが自動的に入れ替わり、要素Ｂに「説明」という属性が与えられ、要素Ａに「換言」という属性が与えられ、要素Ａ及び要素Ｂにぶら下がっている各要素は元々ぶら下がっている要素に付随して移動する（各要素の属性毎に、要素の移動に付随して移動するか、元々ぶら下がっていたポジションに新たに移動してきた要素にぶら下がるようにするか、全てどちらか一方にぶら下がるようにするか、が決定されるという仕様でも構わない）、というものが考えられる（図１７−Ａ）。

或いは、「説明」という属性が与えられる要素Ａの下に、新たに「要約」という属性が与えられる要素Ｂをぶら下げるオファー（編集操作（ここでは「ぶら下げ」）に関する承認を求める処理）が行われた際、このオファーが承認されると、この承認によって実行される編集操作の後、要素Ａと要素Ｂのポジションが入れ替わり、要素Ｂに「説明」という属性が与えられ、要素Ａに「詳細」という属性が与えられ、要素Ａ及び要素Ｂにぶら下がっている各要素は全て要素Ｂの下にぶら下がる、というものが考えられる。ここに記載したものはごく一部の例であり、他にも様々なルールを設定することが想定される（図１７−Ｂ）。

請求項１に記載のドキュメント入力編集システムは、ドキュメントに含まれる複数の要素のなかで、存続するまたは有効である要素を選定する際に、特定の要素を選定する基準（以下、「要素選定基準」）として、選定の候補となる各要素に付随する任意の情報、該要素と直接または間接的に関係付けられた要素に関する情報、関係定義情報に基づく要素の構造化のパターンに関する情報とのうち少なくともいずれかの情報またはこれに基づき計算される情報を評価の対象とする基準が用いられることを特徴とすることができる。

例えば、複数の要素が競合する場合（記載内容が重複するため同時に存続させる（或いは有効とする）と議論の焦点が定まらず支障をきたす場合等）には、競合する各要素の支持指数（その要素の内容がどの程度のユーザの支持を獲得するものであるかを示すものとして要素毎に設定される尺度。各ユーザが各要素に対し支持／不支持を明示的に示すことにより計算される変数として実装することや、各要素の子や子孫に位置する要素の数や内容、属性等に応じて計算される変数として実装することが想定される）や支持構造（その要素がどのような要素間の構造において支持されているのか）を計算し、その数値が最も高いもの（または支持構造が最も高い評価を得る要素）を存続させるまたは有効とすることにより、ドキュメント（或いは議論）の内容を効果的或いは効率的に整理することを可能とする。

なお「要素に付随する任意の情報」の例としては、要素の内容、属性、関係定義情報、入力日時、更新日時、データベースにおいて整理される際のＩＤ、請求項２に定義される要素ウェイト情報等が挙げられる。また「該要素と直接または間接的に関係付けられた要素に関する情報」とは、その要素に直接または間接的に関連付けられた要素の数や、関係付けられた各要素についての上記「要素に付随する任意の情報」に準拠する情報等である。また「関係定義情報に基づく要素の構造化のパターンに関する情報」とは、構造化状況のパターン毎に設定される数値（固定値またはパターン自体以外の基準で調整される基準値）等が想定される。また「これに基づき計算される情報」とは、例えば、その要素と一定の関係にある各要素（直接または間接的に関係付けられた要素のうち特定の条件に該当する要素）について、属性毎に設定される定数と要素ウェイト情報の積を計算し、それらの和として得られる数値等である。例えば、複数の要素が競合する場合にはこの数値が大きいものを選定する等の形で基準が設定される。

請求項１に記載のドキュメント入力編集システムは、該ドキュメント入力編集システムにおいて編集操作可能な状態にあるドキュメント（以下、「編集ドキュメント」）を、要素の属性及び関係定義情報並びに該関係定義情報に基づく要素の構造化のパターン等の情報を対象とする明確な規則、または該情報に応じて与えられる明確な規則に沿って、計算機上の処理、特別な権限（以下、「ドキュメント取りまとめ権限」）が与えられたユーザの操作、またはこの両方によって実行されるプロセスによって、整理することにより定義されるドキュメント（以下、「完成ドキュメント」）を作成する完成ドキュメント作成手段を具備し、該完成ドキュメント作成手段において、編集ドキュメントに含まれる各要素（以下、「編集要素」）のうち、完成ドキュメントに含まれる要素（以下、「完成要素」）として取り上げる、または完成要素を作成するための素材とされる編集要素を選定する基準（以下、「要素選定基準」）として、選定の候補となる各編集要素に付随する任意の情報、該編集要素と直接または間接的に関係付けられた要素に関する情報、該関係定義情報に基づく要素の構造化のパターンに関する情報とのうち少なくともいずれかの情報またはこれに基づき計算される情報を評価の対象とする基準が用いられ、該プロセスが該要素選定基準に沿ったものとなるよう制約を受けている特徴を有する（図２６）。

請求項１に記載の「明確な規則」は、例えば、「編集ドキュメントにおける属性ＰＥ１の要素は、そこで定義されるロジックが成立するために必要な条件が、該要素に関連付けられた要素において、排他的かつ網羅的に設定された時点で完成ドキュメントに組み込まれる」、「属性ＰＥ２の要素は完成ドキュメントに必ず組み入れられる」といった規則や「属性ＰＥ４の要素は条件Ｃ１を満たさなければ完成ドキュメントに組み入れることはできない」、「属性ＰＥ５の要素は完成ドキュメントに組み入れることはできない」といった規則などのように定義される。「要素の属性及び関係定義情報並びに該関係定義情報に基づく要素の構造化のパターン等の情報を対象とする明確な規則」とは、該情報に適用される規則であり、また「該情報（要素の属性及び関係定義情報並びに該関係定義情報に基づく要素の構造化のパターン等の情報）に応じて与えられる明確な規則」とは、該情報の内容に応じて設定される明確な規則（適用の対象は問わない）である。

請求項１に記載の該編集ドキュメントを「整理する」プロセスとしては、該編集ドキュメントに含まれる要素または情報を予め定められたフォーマット（以下、「完成ドキュメント・フォーマット」）に収納し、該完成ドキュメント・フォーマットに収納した内容を確定することにより実行すること等が想定される。なお、該編集ドキュメントに含まれる編集要素または情報を完成ドキュメント・フォーマットに収納する際には、完成ドキュメントに含まれる要素として取り上げるもしくは完成ドキュメントに含まれる要素を作成するための素材とされる編集要素に関する内容の全てを収納するようにしておいても、或いはその内容の一部を収納するようにしておいても構わず、また、元の内容をそのまま収納しても、或いは何らかの修正を加えた上で収納しても構わない。いずれにせよ、完成ドキュメントに含まれる要素として取り上げる編集要素または完成ドキュメントに含まれる要素を作成するための素材とされる編集要素と、この編集要素を元に作成された完成ドキュメントに含まれる要素との対応関係が明確化されることが期待される（図２７）。

請求項１に記載のドキュメント入力編集システムは、該規則が、該完成ドキュメントを構成する各要素と該編集ドキュメントを構成する各要素との対応関係、または該完成ドキュメントを構成する要素間の構造と該編集ドキュメントを構成する要素間の構造との対応関係に関する規則として与えられることができる。

ここで「該完成ドキュメントを構成する各要素と該編集ドキュメントを構成する各要素との対応関係」に関する規則とは、例えば「編集ドキュメントにおける属性ＰＥ６の要素は完成ドキュメントにおける属性ＰＣ５の要素に変換される」といった規則や「完成ドキュメントにおける属性ＰＣ６の要素として組み込むことができるのは編集ドキュメントにおける属性ＰＥ７またはＰＥ８の要素のみである」といった規則である。また、「該完成ドキュメントを構成する要素間の構造と該編集ドキュメントを構成する要素間の構造との対応関係」に関する規則とは、例えば「編集ドキュメントにおける属性ＰＥ９の要素に属性ＰＥ１０の要素が少なくとも１つ以上関係付けられていて、その属性ＰＥ１０の各要素に属性ＰＥ１１、ＰＥ１２、ＰＥ１３の要素がそれぞれ少なくとも１つ以上関係付けられている場合に、この属性ＰＥ９、ＰＥ１０、ＰＥ１１、ＰＥ１２、ＰＥ１３の各要素はそれぞれの関係（構造）を維持したまま完成ドキュメントに組み込まれ、各要素の属性がＰＣ９、ＰＣ１０、ＰＣ１１、ＰＣ１２、ＰＣ１３に変換される」といった規則（この規則を適用した完成ドキュメントの作成例を図２８に示す）や「その際、特定の条件に該当する場合には、属性ＰＥ９の要素には少なくとも複数の属性ＰＥ１０の要素が関係付けられていなければならない」といった規則である。

請求項１に記載のドキュメント入力編集システムは、完成ドキュメントが、少なくとも1つ以上の質問と該質問に付随するそれぞれ複数の選択肢とに適用することが可能な要素または情報を含むドキュメント（以下、「質問ドキュメント」）であることができる。

「質問ドキュメント」とは、選択肢が複数ある質問が複数並び、そのまままたは必要に応じてコンピュータ上で自動的にもしくは人為的に加工することによりアンケート等の質問に用いることができるドキュメントである（選択肢は、各質問においてひとつだけ選択するタイプのものでも、複数選択するタイプのものでも構わない）。例えば、編集ドキュメントにおいて、属性「論点」の要素が属性「質問」の要素にそれぞれ変換され、前記属性「論点」の各要素に関連付けられていた属性「考え方」の要素が前記属性「質問」の各要素に関連付けられた属性「選択肢」の要素にそれぞれ変換され、前記属性「考え方」の各要素に関連付けられていた属性「賛成根拠」の要素が前記属性「選択肢」の各要素に関連付けられた属性「利点」の要素にそれぞれ変換され、前記属性「立場」の各要素に関連付けられていた属性「反対根拠」の要素が前記属性「選択肢」の各要素に関連付けられた属性「欠点」の要素にそれぞれ変換され、（場合によっては、前記属性「立場」の各要素に関連付けられていた属性「コメント」の要素が前記属性「選択肢」の各要素に関連付けられた属性「補足」の要素にそれぞれ変換され、）編集ドキュメントにおけるその他の属性の要素を取り上げる対象から外す、ことにより定義された完成ドキュメントである（図２６）。或いは、「論点」という属性が与えられた複数の要素と、前記「論点」という属性が与えられた各要素に関連付けられた「考え方」という属性が与えられたそれぞれ複数の要素とにより構成される完成ドキュメント（前の例に習いさらに「賛成根拠」「反対根拠」「コメント」等の要素が含まれていても構わない）であって、これをコンピュータ上で自動的にもしくは人為的に加工してアンケート等の質問に用いることができるというものもこれに含まれる。

段落０１１５に記載のドキュメント入力編集システムは、該ドキュメント入力編集システムに接続されたネットワーク及び該ネットワーク上の計算機を通じて、該質問ドキュメントに基づき生成された文書または該質問ドキュメント（以下、「アンケート文書」）を用いて、該ネットワーク上の計算機を操作可能な計算機ユーザを対象としたアンケートを実施するアンケート実施手段、または該アンケート実施手段を具備するシステムにアンケート文書を提供するアンケート文書提供手段を具備することを特徴とすることができる（図２９、図３０）。

ここで「該ドキュメント入力編集システムに接続されたネットワーク及び該ネットワーク上の計算機」とは、例えば、該ドキュメント入力編集システムと接続されたサーバ／クライアント・システムとして構成されるコンピュータ・ネットワーク・システム等である。該ドキュメント入力編集システムまたは該ドキュメント入力編集システムにネットワーク接続されたサーバは、該ネットワークを通じて該ネットワーク上のコンピュータに該アンケート文書を送信し、該コンピュータは該サーバの要求に応じて該コンピュータの利用者に該アンケート文書を提示し、該アンケート文書への回答を求め、該利用者の該アンケート文書に対する回答に関する情報（以下、「回答情報」）の入力を受け付け、該回答情報を該サーバに送信し、該サーバは該コンピュータから該回答情報を受信し、該サーバと該コンピュータは必要に応じてこうした通信を繰り返し、該サーバは該コンピュータから送信された該回答情報を記録手段（データベース等）に記録し、必要に応じて集計等の処理を行う。

請求項１に記載のドキュメント入力編集システムは、該完成ドキュメント作成手段において、編集ドキュメントに含まれる各要素（以下、「編集要素」）のうち、完成ドキュメントに含まれる要素（以下、「完成要素」）として取り上げる、または完成要素を作成するための素材とされる編集要素を選定する基準（以下、「要素選定基準」）として、選定の候補となる各編集要素に付随する任意の情報、該編集要素と直接または間接的に関係付けられた要素に関する情報、該関係定義情報に基づく要素の構造化のパターンに関する情報とのうち少なくともいずれかの情報またはこれに基づき計算される情報を評価の対象とする基準が用いられ、該プロセスが該要素選定基準に沿ったものとなるよう制約を受けている特徴を有する。

即ち、編集ドキュメントに含まれる全ての要素（編集要素）が完成ドキュメントに含まれる要素（完成要素）として取り上げられ、或いは完成要素を作成するための素材とされるわけではなく、こうした取り扱いを受ける要素と受けない要素があり（例えば、完成ドキュメントにおけるある属性の要素に直接関係付けられる各編集要素の内容は重複してはならないという制限がある場合など）、こうした取り扱いを受ける編集要素を選定する際には基準（要素選定基準）があり、その要素選定基準として、編集要素に付随する任意の情報、該編集要素と直接または間接的に関係付けられた他の編集要素に関する情報、関係定義情報に基づく編集要素の構造化のパターンに関する情報、或いはこれらの情報に基づき計算されて得られる情報が用いられるということである。例えば、複数の編集要素が競合する（完成要素または完成要素を作成するための素材とされる編集要素として同時に選定することができない）場合には、競合する各編集要素の支持指数（その編集要素の内容がどの程度のユーザの支持を獲得するものであるかを示すものとして編集要素毎に設定される尺度。各ユーザが各編集要素に対し支持／不支持を明示的に示すことにより計算される変数として実装することや、各編集要素の子や子孫に位置する編集要素の数や内容、属性等に応じて計算される変数として実装することが想定される）や支持構造（その要素がどのような編集要素間の構造において支持されているのか）を計算し、その数値が最も高いもの（または支持構造が最も高い評価を得る要素）を完成要素として取り上げる、或いは完成要素を作成するための素材とする編集要素として選定する、といった基準を設けておくこと等が考えられる。

なお「編集要素に付随する任意の情報」の例としては、編集要素の内容、属性、関係定義情報、入力日時、更新日時、データベースにおいて整理される際のＩＤ、請求項２に定義される要素ウェイト情報等が挙げられる。また「該編集要素と直接または間接的に関係付けられた要素に関する情報」とは、その要素に直接または間接的に関連付けられた要素の数や、関係付けられた各要素についての上記「編集要素に付随する任意の情報」に準拠する情報等である。また「関係定義情報に基づく要素の構造化のパターンに関する情報」とは、構造化状況のパターン毎に設定される数値（固定値またはパターン自体以外の基準で調整される基準値）等が想定される。また「これに基づき計算される情報」とは、例えば、その要素と一定の関係にある各要素（直接または間接的に関係付けられた要素のうち特定の条件に該当する要素）について、属性毎に設定される定数と要素ウェイト情報の積を計算し、それらの和として得られる数値等である。例えば、複数の要素が競合する場合にはこの数値が大きいものを選定する等の形で基準が設定される。

請求項２に記載のドキュメント入力編集システムは、ユーザが自身の入力または編集した要素に関する情報を管理または確認するために用いられる表示フィールド（以下、「自己入力編集要素表示手段」）と、編集ドキュメントまたは完成ドキュメントの内容を確認するために用いられる表示フィールド（以下、「ドキュメント内容表示手段」）とのうち、少なくともいずれかの表示フィールドを具備し、該表示フィールドの少なくともいずれかにおいて、ユーザが自身または他のユーザの入力または特定した要素に対し重み付け情報（以下、「要素ウェイト情報」）を設定する要素ウェイト情報設定手段を具備し、該要素選定基準として、該要素ウェイト情報またはこれを用いた計算により求められる数値を評価の対象とする基準を用いることを特徴とする。

ここで「要素ウェイト情報」の例としては、自身の関心の度合い、重視する度合いなどを適用することが想定される。また、要素ウェイト情報に特別な意味を持たせたり（例えば、各要素のユーモア性、深刻性、緊急性、個人性、公共性等の度合いを示すウェイトを設定する等）、同じ要素に複数の要素ウェイト情報を設定したりすることができるようにしておくことも想定される。

編集ドキュメントの内容を確認するために用いられる表示フィールドは、通常具備されている構造表示手段に機能を付加したものでも構わない。例えば、特定の要素を右クリックすると、「要素ウェイト情報」を設定するというメニューが出てきて、これを選ぶと、要素ウェイト情報を数値入力やリストからの選択にて要素ウェイト情報を設定するためのインタフェースが表示される、等の機能が備わっていれば請求項２に記載の要素ウェイト情報設定手段を具備するものといえる。

なお、請求項２においては、要素ウェイト情報を設定する要素ウェイト情報設定手段を具備することのみを要件としているが、要素ウェイト情報を用いて各表示フィールドに表示される要素をソーティング（並び替え）して表示することを可能とする要素ソーティング手段を具備することや、各表示フィールドにおいて要素を表示する際に要素ウェイト情報の内容を表示する要素ウェイト情報表示手段を具備すること、各表示フィールドにおいて要素を表示する際に要素ウェイト情報が特定の条件を満たす要素のみを表示する特定ウェイト条件要素表示手段を具備すること、各表示フィールドにおいて要素を表示する際に要素ウェイト情報が特定の条件を満たす要素を強調して表示する特定ウェイト条件要素強調表示手段を具備すること、なども想定される。

請求項２に記載のドキュメント入力編集システムは、段落０１０７または段落０１１０に記載の要素選定基準として、請求項２に記載の要素ウェイト情報またはこれを用いた計算により求められる数値を評価の対象とする基準を用いることを特徴とする。

例えば、要素選定基準（ドキュメントに含まれる各要素のうち、存続するもしくは有効である要素を選定する際、または完成要素として取り上げるもしくは完成要素を作成するための素材とされる要素を選定する際の選定基準）として、各要素に対し各ユーザが重視する度合いを示す要素ウェイト情報を用いた計算により各要素の指示指数を計算し、これにより得られた数値を評価の対象とする基準を挙げることができる。評価の対象となる数値（支持値）の計算方法の例としては、選定の候補となる要素毎にその要素に対し各ユーザが設定する要素ウェイト情報の和（以下、「直接支持値」）を計算し、子を持たない要素に関してはその要素の直接支持値をその要素の支持値とし、子を持つ要素に関しては、全ての子要素の支持値の合計とその要素の直接支持値の和を以ってその要素の支持値とする、といったものが考えられる（子の支持が親の支持に加算されていく構造）。このとき、要素選定基準は、競合する複数の要素のうちの特定の要素を選ぶ際には支持値の高いものを選定するといったものにしておく。またこの計算方法において、属性の種類によって、親要素の支持値を計算する際に、子要素の支持値を加算しなかったり（例えば「コメント」等、親要素に対し賛成も反対もしない内容を示す要素であることを示す属性の場合）、子要素の支持値の正負を反転させて加算したり（例えば「反論」、「疑問」等、親要素に対し反対する内容を示す要素であることを示す属性の場合）、することも想定される。なお、要素ウェイト情報を「１」等の定数に統一しておけば、よりシンプルな形で実装することも可能である。

請求項２に記載のドキュメント入力編集システムは、ユーザ毎に設定される議決権に関する情報（以下、「ユーザ議決権情報」）を記録するユーザ議決権情報記録手段を具備し、該要素選定基準として、該ユーザ議決権情報記録手段において保持されるユーザ議決権情報またはこれを用いた計算により求められる数値を評価の対象とする基準が用いられることができる。

ここで「ユーザ議決権情報」とは、議決権の有無を示すｂｏｏｌｅａｎ値、所持する票数を表す整数などにより表現されることが想定される（ただし、これに限らず、計算可能な実数であれば、整数でない値や負の値を含め、どんな数字でも構わない）。或いは、「状況１においてはＸ、状況２においてはＹ」といった条件分岐設定等を含む情報でも、ロジカルに定義されるものであれば「ユーザ議決権情報」として用いることができる。請求項２と段落０１２８の記載を同時に満たすドキュメント入力編集システムである場合、該要素選定基準として、該要素ウェイト情報と該ユーザ議決権情報とを用いた計算により求められる数値を用いることができる。

評価の対象となる数値の計算方法の例としては、選定の候補となる要素毎にその要素に対し各ユーザが設定する要素ウェイト情報とそのユーザのユーザ議決権情報を表す値の積の和（以下、「直接支持値」）を計算し、子を持たない要素に関してはその要素の直接支持値をその要素の支持値とし、子を持つ要素に関しては、全ての子要素の支持値の合計とその要素の直接支持値の和を持ってその要素の支持値とする、といったものが考えられる。このとき、要素選定基準は、競合する複数の要素のうちの特定の要素を選ぶ際には支持値の高いものを選定するといったものにしておく。

請求項１に記載のドキュメント入力編集システムは、完成ドキュメントまたは該完成ドキュメントに基づき作成された情報もしくは該完成ドキュメントに関連付けられた情報に対し付与されるステイタス情報を参照するステイタス情報参照手段と、該ステイタス情報参照手段を通じて獲得されたステイタス情報または該ステイタス情報を用いて作成された情報をユーザに提示するステイタス情報提示手段とを具備することができる。

即ち段落０１３１に記載のドキュメント入力編集システムは、完成ドキュメントまたは該完成ドキュメントに基づき作成された情報もしくは該完成ドキュメントに関連付けられた情報に対し付与されるステイタス情報のトレイサビリティを確保したものである。ここで「該完成ドキュメントに基づき作成された情報」とは、該完成ドキュメントから直接作成された情報（以下、「一次的作成情報」）のみならず、一次的作成情報に基づき作成された情報（以下、「二次的作成情報」）、二次的作成情報に基づき作成された情報（以下、「三次的作成情報」）、以下同様に定義される多次的作成情報も含むことができるものとする。

また「ステイタス情報」とは、完成ドキュメントまたは該完成ドキュメントに基づき作成された情報もしくは該完成ドキュメントに関連付けられた情報（以下、「対象情報」）のステイタスを示す情報であり、対象情報がどのような状態であるか、対象情報がどの段階にあるか、対象情報にどのようなイベントが発生したか、対象情報がどのように処分されたか、等といった情報が該当しうる。例えば、該完成ドキュメントが社会問題を整理したものである場合、その社会問題を解決するための政策案、その政策案を具体化した法案、その法案が制定された法律（これらのドキュメントも本発明に記載のドキュメント入力編集システムにおいて入力編集による議論を経たものであることも考えられる）等が対象情報となりうる。このとき、その法案が、議論されている状態、既に取りまとめられた状態、審議中の状態、成立した（または棄却された）状態等を示す情報がステイタス情報である。

また「ステイタス情報を用いて作成された情報」とは、ステイタス情報と他の情報との両方を用いて作成された情報も含まれ、またステイタス情報の内容に応じて他の情報を加工、修正、選定、吟味等したうえで確定される情報も含まれる。

請求項３に記載のドキュメント入力編集システムは、完成ドキュメントまたは該完成ドキュメントに基づき作成された情報もしくは該完成ドキュメントに関連付けられた情報に対し付与されるステイタス情報もしくは該ステイタス情報の変化を検出するステイタス情報変化検出手段と、該完成ドキュメントに含まれる材料を提供した編集ドキュメントに含まれる要素を入力もしくは特定したユーザ（以下、「入力特定ユーザ」）または該入力特定ユーザを指定する別のユーザ（以下、「指定ユーザ」）に対し、該ステイタス情報変化検出手段において検出された変化が予め定められた条件に該当する場合もしくは他の条件において該ユーザ（入力特定ユーザまたは指定ユーザ）の指定する条件が満たされた場合において、または特定のルールによって与えられるタイミングもしくは該ユーザ（入力特定ユーザまたは指定ユーザ）の指定するタイミングにおいて、該ステイタスまたは該変化に関する通知を行うステイタス情報通知手段と、を具備することを特徴とする。

ここで「ステイタス情報変化検出手段」は、段落０１３１に記載の「ステイタス情報参照手段」と関連するが、完成ドキュメントまたは該完成ドキュメントに基づき作成された情報もしくは該完成ドキュメントに関連付けられた情報（以下、「対象情報」）のステイタスを示す情報を、ただ参照することではなく、その変化を検出できることが求められる。例えば、該ステイタス情報参照手段は、対象情報に該当するある法案が、議論されている状態、既に取りまとめられた状態、審議中の状態、成立した（または棄却された）状態等を示す情報がステイタス情報を参照するものであることに対し、ステイタス情報変化検出手段は、その法案が、取りまとめられたとき、審議に入ったとき、成立したとき、棄却されたとき等にその変化を検出するものである。定期的（例えば１０分おき）にステイタス情報を参照し、参照されたステイタス情報が前回参照したときと異なるとき、これを変化として検出する、という形で実装しても構わないし、対象情報を管理するシステムが対象情報のステイタス情報に変化があった場合にこれを該ドキュメント入力編集システムに通知し、この通知を受信することを以って該ステイタス情報の変化を検出する、という形で実装しても構わない。また、「ステイタス情報通知手段」は、段落０１３１に記載の「ステイタス情報提示手段」と関連するが、該ステイタス情報提示手段は、ユーザの求めに応じて提示する場合に活用されることも想定されるが、該ステイタス情報通知手段は、ユーザの求めの有無に関わらず、与えられた条件が整った際にユーザに通知をするものである。

請求項１乃至３に記載のドキュメント入力編集システムは、編集等されるドキュメントが、政策または社会問題に関わる議論、認識、考えかた、立場、主張等を整理するものであることを特徴とすることができる。

政策または社会問題に関わる議論、認識、考えかた、立場、主張等を整理するには、価値観や認識、経験等を共有しない参加者が、互いの意見に耳を傾けながら、利害の対立を解決する困難なプロセスが要求される。各請求項に記載した、ミクロなコンセンサスを通じて各要素の内容と要素間の関係により構成される構造を洗練しつつ、多数の利用者からの支持が得られる要素や少数の利用者からでも強い思いが込められた要素を尊重するメカニズムにより、このプロセスを実現する。

請求項１に記載のドキュメント入力編集システムは、完成ドキュメントとして、特許文献特開２００５−３５３０１８「多様なアクター間の政策コミュニケーションと政治参加を支援するための情報基盤システム」に記載された政策コミュニケーション・システムにおいて取り扱う、政策議題、または、インターネット利用者もしくは政治家（候補者を含む）を対象とする政策アンケート文書（支持、反対、重視等する政策のリストを作成するための項目を提供する文書）を提供することを目的とすることを特徴とすることができる。

特許文献特開２００５−３５３０１８に記載の一部の請求項においては、該政策議題または該政策アンケート文書を、政策議題募集手段等を用いてインターネットを通じて獲得することが想定されているが、本発明の段落０１３９に記載のドキュメント入力編集システムにおいて得られた完成ドキュメントは、該政策議題募集手段等を用いて獲得されるものと併せて、またはこれに代替するものとして用いることが想定される。従って、特許文献特開２００５−３５３０１８に記載の政策コミュニケーション・システム、及び該政策コミュニケーション・システムより、該政策議題または該政策アンケート文書を獲得するためのメカニズム（政策議題募集手段等で構成される）を省略した政策コミュニケーション・システムが、段落０１３９に記載のドキュメント入力編集システムが完成ドキュメントを提供する対象となりうるものとする。

請求項１に記載されたドキュメント入力編集システムにおいて入力、編集等されたドキュメントを、請求項１に記載された該ドキュメント入力編集システムと同様の構造、レイアウト、またはデザインにおいて、表示する入力編集ドキュメント表示手段を具備する、入力編集ドキュメント閲覧システムを構成することができる。

該入力編集ドキュメント表示手段により閲覧されるドキュメントとしては、編集ドキュメント、完成ドキュメント、及びこれを元に作成されたドキュメントが該当しうる。

請求項４に記載の発明は、請求項１乃至３に記載されたドキュメント入力編集システムの各手段として機能するコンピュータ・プログラムである。

本発明の主要な効果は、複数の参加者を前提としたドキュメント編集または議論の場において、多様な情報が複雑に絡み合った情報量が膨大なドキュメントまたは議論の内容をユーザが短時間で的確に把握するのを容易とすること、及び、意見や立場の異なる多数の参加者が参加する議論の過程で体系だった知識を整理するのを可能とすること、である。請求項毎の主要な効果を以下に示す（ただし発明の効果の多くは前の文脈のなかで既に述べており、ここでは各請求項の主要な効果のみ取り上げ、既述事項の一部は割愛する）。

請求項１に記載の発明は、関係定義情報による議論の構造化と、構造表示手段による構造化された議論の視覚的表示、及びこの視覚的表示を通じた操作を可能とすることにより、多様な情報が複雑に絡み合ったドキュメントまたは議論の内容をユーザが短時間で的確に把握し、ドキュメント編集や議論に参加することを容易とする。

段落００５４に記載の構成は、要素属性の編集を可能とすることにより、一度入力された要素の位置付けに違和感が持たれた際にこれを見直すことを促し、ドキュメント内容の最適化を促進する。

段落００５５に記載の構成は、各要素に意味的位置付けを付与することにより、多様でかつ複雑に絡み合った情報を整理することを可能とする。

段落００５７に記載の構成は、各要素の意味的性質を定義することにより、多様でかつ複雑に絡み合った情報を整理することを可能とする。

段落００５９に記載の発明は、各要素の論理的性質を定義することにより、多様でかつ複雑に絡み合った情報を整理することを可能とする。

段落００６２に記載の特徴は、各要素間の関係をツリー構造として定義することにより、多様でかつ複雑に絡み合った情報を整理することを可能とするドキュメントのフレームワークを提供する。

段落００６５に記載の構成は、要素が他の複数の要素に関係付けられることを可能とすることにより、同じリソースが異なる文脈のなかで参照されることを可能とし、ドキュメント編集や議論が一層柔軟に進められることを可能とする。

段落００６８に記載の特徴は、要素及び要素間の構造を視覚的に表示し、この視覚的表示上での要素間の関係を編集することを可能とすることにより、多様な情報が複雑に絡み合ったドキュメントまたは議論の内容に対する修正操作を容易とする。

段落００７１に記載の構成は、ドキュメントに含まれる要素または要素セットを複数のドキュメントの間で柔軟に活用することを可能とすることにより、リソースの有効活用、及び、柔軟なドキュメント編集や議論を可能とする。

段落００７５に記載の構成は、全体的構造と局部的構造とを別に表示し、各表示手段の連携を図ることにより、ドキュメントの内容を柔軟に閲覧することを可能とするナビゲーション機構を提供する。

段落００８０に記載の構成は、一部の要素の表示／非表示を切り替える手段を提供することにより、閲覧者が閲覧したい情報のみを表示することを可能とする。

段落００８４に記載の構成は、ドキュメントに含まれる要素を検索し、抽出された情報のみを表示したり、強調したりして表示することを可能とし、閲覧者が閲覧したい情報を効果的に閲覧することを可能とする。

段落００８７に記載の構成は、ドキュメントに含まれる要素の表示順序または表示位置の決定または調整に影響を及ぼすソーティング条件情報を入力または特定する手段を備えることにより、各要素の表示順序や表示位置をユーザの期待通りに調整することを可能とし、多様な情報が複雑に絡み合った情報を、ユーザが各自の視点から思い通りに閲覧することを可能とする。

段落００９０に記載の特徴は、各要素に対する要素支配権を設定することにより、各ユーザが、自ら要素支配権を保持する要素（主として、自分の入力または編集した要素）に関して、責任を持って継続的にコミットすることを促す。要素の内容や属性、要素間の構成の調整には、関係する要素に対する責任を負う者の間でのコンセンサスが要求されるメカニズムを用いることにより、ドキュメントや議論の全体としての秩序や整合性を維持したまま、参加者個人の意見を議論のなかに取り込むための決定的なメカニズムを提供する。

段落００９８に記載の構成は、ユーザ毎に操作権限を設定することができるようにすることにより、ユーザの能力、資格、貢献度、当事者度、信頼度、誓約事項等に応じて、各ユーザに実行可能な操作を別々に設定することを可能とし、各ユーザの役割に応じた参加を可能とし、会議やドキュメント編集等におけるコミュニケーションやコラボレーションを円滑かつ効果的に進行させる効果が期待される。

段落０１０１に記載の構成は、新たに付与される要素間の関係を、各要素に付随する任意の情報または既に与えられている要素間の関係に基づく構造化状況に関する条件によって制約することにより、情報を効果的に整理することを促進し、また既に完成度が高まった情報が容易に破壊されることを防止し、ドキュメントや議論の構造化を生産的に進めることのできる環境を提供する。

段落０１０３に記載の構成は、特定の条件が満たされた際に、要素の属性または要素間の関係を自動的に編集する手段を備えることにより、ドキュメント編集や議論における情報の効率的な整理を可能とする。

段落０１０７に記載の構成は、ドキュメントに含まれる複数の要素のなかから、要素選定基準に基づき、存続するまたは有効である要素を選定する手段を備えることにより、各要素が要素選定基準で重く評価されるよう修正されるインセンティブを働かせながら、複数の要素の間に存在する内容の重複や矛盾等を整理することを促し、発散しがちな議論やドキュメントを収束させることを可能とする。

請求項１に記載の発明は、ドキュメント編集または会議のアウトプットとして完成ドキュメントを整理することを前提とすることにより、ドキュメント編集または会議に目的意識、参加インセンティヴ、及び緊張感を持たせ、目に見える具体的な成果が得られることを可能とする。また、完成ドキュメントを整理する過程に明確な秩序を持たせることにより、公平な条件のもと、多くの参加者の立場が集約されたアウトプットを得ることを可能とする。また、ドキュメント編集や議論のプロセスがアウトプットを得るプロセスそのものであり、アウトプットの内容が直接ドキュメント編集や議論の内容を示し、ドキュメント編集や議論からアウトプットを得る際に期待されない内容面でのロスが発生することはない。

段落０１１３に記載の構成は、完成ドキュメントを構成する各要素と編集ドキュメントを構成する各要素との対応関係、または完成ドキュメントを構成する要素間の構造と編集ドキュメントを構成する要素間の構造との対応関係に関する規則を、完成ドキュメントを作成する過程で適用される規則として用いることにより、編集ドキュメントの内容を完成ドキュメントに直接組み込みつつ、完成ドキュメントの性質に合致したスタイルのドキュメントを作成することを可能とする。以って、ドキュメント編集や議論の過程で整理されたリソースを、ドキュメント編集や議論の終了後においても、効果的に活用することを可能とする。

段落０１１５に記載の構成は、質問と質問に付随するそれぞれ複数の選択肢とに適用することが可能な要素または情報を含むドキュメントを完成ドキュメントとして得ることにより、議論やドキュメント編集の結果導かれた内容について、議論に参加していない人を含む他者の意思を確認したり、これに関する特定のコミュニティの中での意思決定を支援したりするための素材を提供することを可能とする。

段落０１１７に記載の構成は、質問と質問に付随するそれぞれ複数の選択肢とに適用することが可能な要素または情報を含むドキュメントを完成ドキュメントとして得たうえで、これに基づくアンケート文書を用いたアンケートを実施することを可能とし、議論やドキュメント編集の結果導かれた内容について、議論に参加していない人を含む他者の意思を確認したり、これに関する特定のコミュニティの中での意思決定を支援したりすることを可能とする。

段落０１１９に記載の特徴は、ドキュメントに含まれる複数の要素のなかから、要素選定基準に基づき、完成ドキュメントに組み入れる要素を選定する手段を備えることにより、各要素が要素選定基準で重く評価されるよう修正されるインセンティヴを働かせながら、複数の要素の間に存在する内容の重複や矛盾等を整理することを促し、発散しがちな議論やドキュメントを収束させることを可能とする。

請求項２に記載の発明は、ユーザが自身または他のユーザの入力または特定した要素に対し要素ウェイト情報を設定することを可能とすることにより、各ユーザが要素毎に重視する度合いを設定し、この度合いに応じて各ユーザに表示される情報を調整したり、各ユーザの思い入れの強さをドキュメント全体の構成に反映させたりすることを可能とする。とりわけ、利用者自身のための情報整理を目的として各要素に付与される重み付け情報を、利用者間で共有されるドキュメント全体のなかでの情報整理のために活用することにより、各利用者が自ら重視する以上に大きな重み付けが全体的な意思決定や調整の場面においていたずらに付与されるのをなくし、意思決定や調整の内容のバランスや秩序が維持されることを可能とする（ここで、「利用者」は議論への参加者とは区別して用いられており、議論への参加者を含むが、直接議論に参加しない利用者も含むことができる）。

請求項２に記載の発明は、ユーザが自身または他のユーザの入力または特定した要素に対し設定する要素ウェイト情報またはこれを用いた計算により求められる数値を評価の対象とする基準を、要素選定基準として用いることにより、ユーザ個々人の思い入れの強さをドキュメント全体の構成に反映することを可能とする。

段落０１２８に記載の構成は、要素選定基準として、ユーザ議決権情報を用いることにより、議論やドキュメント編集の内容に関連する当事者や、意思決定に特別な影響を及ぼすべきユーザの判断を重く扱うなど、ユーザの立場や考えかた、投入するコスト等に応じた意思決定への参加を可能とする。株主会議等のように、参加者毎に議決権が異なるコミュニティにおける新たな会議方法として適用することも効果的であると期待される。

段落０１３１に記載の構成は、完成ドキュメントまたは該完成ドキュメントに基づき作成された情報もしくは該完成ドキュメントに関連付けられた情報に対し付与されるステイタス情報を参照し、ステイタス情報またはこれを用いた情報をユーザに提示する手段を備えることにより、ドキュメント編集または議論の内容に関するトレイサビリティを実現し、ドキュメント編集または議論された内容に関する継続的なコミットメントやそれに関する事後的なフォローを可能とする。アウトプットが何らかの方法で活用される過程における情報を、アウトプットに関連するステイタス情報としてモニタリングし、議論の参加者や議論の閲覧者にフィードバックするメカニズムを用いることができるようにして、参加者の議論に参加するインセンティヴを直接または間接的に喚起する。

請求項３に記載の発明は、完成ドキュメントまたは該完成ドキュメントに基づき作成された情報もしくは該完成ドキュメントに関連付けられた情報に対し付与されるステイタス情報もしくは該ステイタス情報の変化を検出し、ユーザに通知する手段を備えることにより、ドキュメント編集または議論の内容に関するトレイサビリティを実現し、ドキュメント編集または議論された内容に関する継続的なコミットメントやそれに関する事後的なフォローを可能とする。アウトプットが何らかの方法で活用される過程における情報を、アウトプットに関連するステイタス情報としてモニタリングし、議論の参加者や議論の閲覧者にフィードバックするメカニズムを用いることができるようにして、参加者の議論に参加するインセンティヴを直接または間接的に喚起する。

段落０１３７に記載の構成は、政策または社会問題に関わる議論、認識、考えかた、立場、主張等を整理するドキュメントを取り扱う対象とし、価値観や認識、経験等を共有しない参加者が、互いの意見に耳を傾けながら、利害の対立を解決する困難なプロセスを可能とする。

段落０１３９に記載の構成は、政策コミュニケーション・システムにおいて取り扱うことが可能な政策議題または政策アンケート文書を完成ドキュメントとして得ることにより、中立、公平、かつ的確な政策議題または政策アンケート文書を準備することが容易でなかったという、従来の政策コミュニケーション・システムにおける問題を解消することを可能とする。

段落０１４１に記載の構成は、ドキュメント入力編集システムにおいて入力、編集等されたドキュメントを、該ドキュメント入力編集システムと同様の構造、レイアウト、またはデザインにおいて、表示する手段を提供することにより、多様な情報が複雑に絡み合った情報量が膨大なドキュメントまたは議論の内容を短時間で的確に把握することを可能とする。また、議論やドキュメント編集の過程自体にコミットしない環境においてもドキュメントの内容を分かりやすく確認することを可能とする。

発明の実施するための最良の形態

本発明に記載されたドキュメント入力編集システムは、主として、複数の電子計算機（コンピュータ、コンピュータを小型化した各種装置、コンピュータが保持する機能の一部のみを備えた装置等）によって構成されるネットワーク上で機能し、データベース（リレーショナル・データベース等）やグラフィカル・ユーザ・インタフェース（インターネット・ブラウザ等）を用いて実装されることが想定される。

本発明に記載のドキュメント入力編集システムの実施例は、ワールド・ワイド・ウェブ上で構成されるサーバ／クライアント型システムとして提供される、以下に記載のシステムである。実施例の細部にいたっては、「課題を解決するための手段」欄で既に述べた様々なバリエーションを適用することが想定されるが、本実施例の記載においては細部のバリエーションの既述は省略し、システムの挙動を左右する主要な機能を示しながら、全体としての構成例を記載するものとする。

なお、本システムは、少なくともウェブ・サーバ（Ａｐａｃｈｅ等）、データベース・サーバ（ＰｏｓｔｇｒｅＳＱＬ、ＭｙＳＱＬ、Ｏｒａｃｌｅ等）、及び複数のウェブ・クライアント（Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ等）がネットワーク接続された上に構成されるウェブ・アプリケーションであり、ウェブ・サーバ上ではデータベース・サーバへのアクセスを制御しながら、ウェブ・クライアントに対してサービスを提供するプログラム（ＰＨＰ、Ｊａｖａ等による）が稼動することにより実装される。

本システムでは、ユーザに対してサービスが提供されるウェブ・クライアント上で提示されるユーザ・インタフェースにおいて、パブリック・エリア（原則として誰でも同じ情報を確認することのできる領域）に配置される、「議論一覧」、「全体マップ」、「カレント・スコープ」、「発言ボード」、「発言ビューア」、「新規発言」、「発言更新」、「ホワイト・ボード」（本発明に記載の請求項には該当しない）、「リンク・リソース」（本発明に記載の請求項には該当しない）とそれぞれ名付けられたブロック（サブ・ウインドウ）、及びプライベート・エリア（ユーザ毎に提示する情報や提供するサービスが異なる領域）に配置される、「私の発言」、「私へのオファー（承認要求）」、「私からのオファー（承認要求）」とそれぞれ名付けられたブロックが備わっている。パブリック・エリアに配置される各ブロックと、プライベート・エリアに配置される各ブロックとは、ウェブ上のコンテンツを区分するタブ（パブリック・エリア・タブ、及びプライベート・エリア・タブ）によって切り分けて表示されることが想定される。本システムは、ユーザが利用するウェブ・クライアントにおいて、パブリック・エリア内、及びプライベート・エリア内に配置される、これらのブロックの組み合わせによって、ユーザに対し各サービスを提供する。各ブロックは、ウェブ・クライアント上の標準のウインドウ内にレイアウトされるか、或いは必要なときにポップアップ・ウインドウとして立ち上がるかのいずれか（時と場合による）によって提供される。

「議論一覧」ブロックは、現在進められている議論の一覧を表示する（図３３）。以下の各ブロックで提供されるサービスは、原則として「議論一覧」ブロックで選択された特定の議論に関する情報を取り扱うものである。「議論一覧」ブロックでは、各議論は、その種類毎にタブ形式で分類された後、議論のタイトルの一覧が表示される。議論の種類は、最終的なアウトプットとして獲得することを目指す完成ドキュメントの種類によって分類され、「社会問題」、「政策議題」と二種類の完成ドキュメントを獲得するための二種類を想定しているが、設計上、議論の種類はさらに増えても対応可能することができる。

「議論一覧」ブロックにおける各タブのなかでは、デフォルトで時系列（議論の開始が新しい順）に表示されるが、アクティブな順（算出方法は別途定める）に表示することもできるようにする。この表示順序はボタンにより切り替えられるようにする。また、その他の表示順序のニーズが出てきたときにも対応可能な設計にしておく。議論の数が画面一杯に納まらない数まで増えた場合には、スクロールバーを表示して、参照箇所を上下に移動できるようにする。スクロールバーで対応できないほど数が増えた場合にはページ切替機能を実装するなどして対応する。

「議論一覧」ブロック上で表示される中から議論のタイトルをクリックすると、クリックされた議論は選択状態となり、選択状態の議論のタイトルは強調表示するなどして、分かりやすく表示する。他の全てのブロックの表示は、この画面で選択された議論に関する情報が提示される。 実際に議論の内容をじっくりと参照する際には、このブロック自体は閉じておくことという使いかたが想定される。その代わり、現在の議論の内容タイトルが確認できる情報を、何らかの方法で提示しておく。

「全体マップ」ブロックは、その議論のなかで展開された全ての発言（要素）が構造化された状態の全体的構造を「全体マップ」として表示する（図３４）。「全体マップ」ブロックにおいては、「Ｔｒｅｅ」、「Ｆｒｅｅ」の２つのフィールドを準備しておく。構造化された発言（他のものと関係付けられた発言）は「Ｔｒｅｅ」フィールドに表示し、構造化されていない発言（他のものと関係付けられていない発言）は「Ｆｒｅｅ」フィールドに表示する。各フィールドは、 デフォルトでは、ちょうど全体が表示されるように縮尺を設定する。また、画面端に「スケール・コントローラ」を配置し、表示領域の拡大縮小を行うためのインタフェースを提供する。拡大されて、表示領域が全体の一部のみを表示する状態となった場合には、表示領域内をドラッグ・アンド・ドロップ操作で表示領域を移動できるようにしておく（ＰＤＦビューアのような操作性が想定される想定）。

「全体マップ」ブロック上には、１〜３個程度の「スコープ」と呼ばれる図形が配置されている。スコープで囲われている部分に配置されている発言の構造（局部的構造）を「カレント・スコープ」ウインドウに表示する。マップ上でスコープをドラッグするとスコープが移動し、「カレント・スコープ」ウインドウに表示される内容もこれに応じて変化する。マップ上を右クリックして、表示されるメニューから「新しいスコープ」を選択すると、新しいスコープを追加できるようにしておく。「スコープ」の大きさは、「カレント・スコープ」ウインドウに表示されるコンテンツの範囲を示す丁度いい大きさのものを用いる。「スケール・コントローラ」で表示領域の拡大や縮小を行った際には、それに応じて「スコープ」の大きさも調整されるようにしておく。

「全体マップ」上に配置した「スコープ」の数だけ「カレント・スコープ」ウインドウが存在し、対応するものが同じ色で表示されるなど、視覚的に分かりやすくする。複数のスコープを同時に用いる場合は、各ブロックを、閉じたり、開いたりできるようにしておく（ただし、ここでいう「閉じる」は最小化またはバーに集約することであり、消去することではない）。

「Ｔｒｅｅ」フィールドに表示される各発言は構造化された状態で表示される。各発言は小さなアイコンで示され、子はその親よりもインデントして表示させ、構造上の関係（主に親子関係）を表すラインを引く。兄弟となる発言の表示順序は、参照数、支持票数、新着順、古株順といった具合に切り替えられるようにしておく。一方、「Ｆｒｅｅ」フィールドの表示は、横軸に時間軸を、縦軸に意味的な軸を取り、各発言はこの二次元空間上で各発言の状態を示す座標に配置されるようにしておく。この意味的な軸は、僅か一次元軸と制約はあるが、ある考えに賛成派か、反対派か、その中間的なポイントを取るのか、発言の際に、例えばスライド・バーのようなインタフェースを通じて発言者に明示してもらうようにしておく。この意味的な軸は、その内容毎に複数の軸を設け、これらを切り替えられるようにしておいても構わない。

「カレント・スコープ」ブロックは、構造化された（他のものと関係付けられた）発言内容の概略（要素属性アイコン＋導入部）を、構造化された状態で表示する（図３５）。「全体マップ」ブロックにおける「Ｔｒｅｅ」フィールドに配置された「スコープ」の範囲に位置する構造化された発言を、構造化されたまま表示し、「全体マップ」ブロックの「スコープ」の移動に伴い、「カレント・スコープ」ブロックの表示領域も移動させる。表示領域の移動は 「全体マップ」ブロック上での操作（ドラッグ・アンド・ドロップ等）に応じて、滑らかな移動ができるようにしておく。例えば、「カレント・スコープ」ブロックの表示で内容を確認しながら、「全体マップ」ブロック上の「スコープ」へのドラッグ操作（「スコープ」内表示領域の移動）を続け、気になったところでドロップする（「スコープ」内表示領域を確定する）といった操作ができるようにする。複雑多様を極める議論の全体像を的確に把握するために、感覚的なインタフェースが非常に重視されるため。ただし、この「滑らかな移動」の実装にコストを要する場合には、「カレント・スコープ」上での表示内容を、スコープの移動前からスコープの移動後の画面へジャンプさせる仕様でも構わない。

「カレント・スコープ」ブロックは複数表示することも想定される。その場合「全体マップ」ブロックに表示されるスコープを複数表示し、対応するものを同じ色調で彩るなど、視覚的に分かりやすく示すようにしておく。また「カレント・スコープ」ブロック上に表示される各発言は、左側に要素属性を示すアイコンが表示され、右側に発言内容の導入部が表示される。各発言は構造化された状態で表示される。構造上の関係（主に親子関係）を表すラインを引くとともに、子はその親よりもインデントして表示させる。構造上兄弟関係に位置する要素の表示順序は、「全体マップ」ブロック上で指定された表示順序に従う。

「カレント・スコープ」ブロック上で、各発言のアイコンをドラッグ・アンド・ドロップ操作で他のアイコンの上に重ねると、各発言の構造関係の再構築（原則としてドラッグ元の発言がドロップ先の発言の子となり、ドラッグ元の子孫はそのまま継承）が仮設定される。またアイコンを右クリックすると表示されるメニューのなかに「属性の更新」オプションを提示し、このオプションを選択すると、更新操作の入力を受け付ける画面が提示され、この画面上で更新操作を実行すると属性の更新が仮設定される。これらの仮設定の際、操作者から発言者にオファーが出され、このオファーが承認されると、仮設定が実行される。複数の仮設定が同時に行われた際には最初に承認された仮設定が採用され、他の仮設定は全てキャンセルされる。仮設定の採用やキャンセルは、操作者に通知される。この操作は、複数の「カレント・スコープ」ブロック間や「発言ボード」ウインドウとの間に渡り可能とする。

「発言ボード」ブロックは、各発言が構造化されている（他の発言の関係付けられている）かどうかに関わらず、発言内容の概略（要素属性アイコン＋導入部）を一覧として表示する（図３６）。「発言ボード」ブロックでは、原則として各発言の概要が時系列に表示されるようにしておく。基本的に、各発言のなかでは、最初の書き出しに、発言を要約する内容、最も言いたいことを書いてもらうようルールを設けておく。まず一言で説明して、続きを補足でかためていくイメージで整理してもらう。「新規発言」ブロックは、そうした書き出しを促すインタフェースを採用する。

また「発言ボード」ブロックにおいて、発言は、自由発言（まだ構造化されていない発言）の一覧、構造発言（既に構造化された発言）の一覧、全ての発言（自由発言と構造発言の両方）の一覧とをタブベースで切り替えられるようにする。他のフィルタを設置したいニーズが出てくれば、同様のタブで追加対応できる設計としておく。各タブのなかで発言の数が画面一杯に納まらない数まで増えた場合には、スクロールバーを表示して、参照箇所を上下に移動できるようにする。スクロールバーで対応できないほど数が増えた場合にはページ切替機能を実装するなどして対応する。各タブのなかで特定の発言をクリックすると、その発言の詳細が「発言ビューア」ブロックに表示され、その発言で参照される図がある場合、「ホワイト・ボード」ブロックに表示される図も切り替わる。

自由発言は必ずしも要素属性が設定されているわけではない。「発言ボード」ブロックにおける自由発言は、要素属性が設定されている場合は要素属性のアイコンを左に表示し、設定されていない場合は「未設定（自由）」であることを示すアイコンを表示する。構造発言は必ず要素属性が設定されているので、そのアイコンを左に表示する。これらのアイコンをドラッグ・アンド・ドロップ操作によって、構造化または構造調整ができる。

「発言ボード」ブロックにおいて、構造発言のアイコンを右クリックして表示されるメニューのなかに「カレント・スコープ」を準備し、これを選択すると、「カレント・スコープ」ブロックがその構造発言を中心とした表示に切り替わる。カレント・スコープが複数ある場合には、右クリックで「カレント・スコープ１」、「カレント・スコープ２」とメニューが出て、それぞれを選択した際には対応するブロックの表示が切り替わる。

「発言ビューア」ブロックは、他のブロックで特定された個々の発言に関する全ての情報を全て表示する（図３７）。「発言ボード」ブロックまたは「カレント・スコープ」ブロックに表示される任意の発言が選択（アイコンをクリック）されたときに、その発言の詳細を表示する。発言の属性と、発言内容の全文が表示される。発言内容の全文が表示エリア内に表示しきれない場合は、スクロールバーを表示して表示領域の調整を可能とすることにより対応する。表示部の側には、その発言の構造上の位置付けを明確化するための情報として、親要素や子要素のリストを添える（自由発言である場合にはその旨を記載）情報を示しておくこともできる。

「発言ビューア」ブロックにおいて表示される発言の中で参照しているリソース（画像、外部リソース、外部リソースが想定される）が存在する場合には、そのリソースを特定する情報を「ホワイト・ボード」ブロック、「リンク・リソース」ブロック等にに提示することを通じてそのリソースにアクセスできるようにする。画像の場合は、「ホワイト・ボード」ウインドウでその内容を閲覧できるようにする。外部リソースの場合、これにアクセスするためのリンク情報を「リンク・リソース」ブロックに表示する。通常は新しいウインドウで表示することになると考えられるが、ユーザの予測に反して重いタスクを開始してしまわないように、意思確認のプロセスを経るようにしておく。内部リソースの場合も、これにアクセスするためのリンク情報を「リンク・リソース」ブロックに表示する。このリンクがクリックされた際には、リンクの対象を他のブロックで表示できる対象であるかを判断し、新しいウインドウを立ち上げる必要がある場合には、外部リソースを参照する場合と同様のプロセスを経る。

「新規発言」ブロックは、新しい発言を入力または特定するためのインタフェースを提供する（図３８）。発言権を有するユーザが、新しく発言を追加するために必要な情報を入力する手段を提供する。このインタフェースにおいては、新しい発言の親（または子）となる発言を特定する情報（特定しない場合は自由発言として扱う）、発言の属性（発言の種類または構造上の位置付けを特定する情報）を特定する情報、及び発言の内容（発言が長くなる場合はスクロールバーで対応）といった情報を入力または確認するための手段を備えておく。これに加え、「発言」ボタン、「キャンセル」ボタンを添えておく。

「新規発言」ブロックは、必要な時にポップアップ・ウインドウとして立ち上がるようにしておく。「全体マップ」ブロックの「Ｆｒｅｅ」フィールドを右クリックして表示されるメニューの中から、「新規自由発言」を選択すると、親（または子）を特定しない自由発言を入力するためのインタフェースとしてこのブロックを開いて、発言内容を記入する欄にカーソルが入った状態にする。このとき、「属性」は「指定なし」の状態にしておき、「指定なし」のまま発言を実行することも可能だが、必要な場合にはリストから指定できるようにしておく。また、「カレント・スコープ」ブロックで、特定の発言のアイコンを右クリックして表示されるメニューのなかに「子として発言」というコマンドをおいておき、これを選択すると、その発言を「親」として特定できる情報（システムが特定できるためのＩＤと、利用者が特定できるためのリード文との両方が確認できるようにしておく）が与えられた状態でこのブロックを開く。その他の動作は、上記に同じ。

さらに、「発言ボード」ブロックで、特定の発言を右クリックして表示されるメニューのなかに「子として発言」（自由発言と構造発言の両方が対象）、「親として発言」（自由発言のみが対象）というコマンドをおいておく。その他の動作は、上記に習うものとする。また、「発言ビューア」ブロックで、特定の発言を参照している際に、右クリックして表示されるメニューのなかに「子として発言」（自由発言と構造発言の両方が対象）、「親として発言」（自由発言のみが対象）というコマンドをおいておく。その他の動作は、上記に習うものとする。

「発言更新」ブロックは、過去に入力または特定された発言の内容を編集するためのインタフェースを提供する（図３９）。既に発言として存在する要素を更新するために必要な手段を提供する。このブロックでの更新操作の対象は、発言内容及び属性を対象とする（構造関係の更新は「カレント・スコープ」ブロック上での操作に委ねるものとする。発言内容、属性を修正するためのフィールドに加えて、関連付けの情報を表示し、「更新」ボタン、「キャンセル」ボタンを添える（なお、発言の更新は、発言の趣旨や内容が大幅に修正するのではなく、小幅な微調整を行うものであることを原則としておく。この原則が尊重されるための具体的なしくみ（システム的なインセンティヴの与えかた）を実装することが期待されるが、当初は更新者の自主規制に委ね、発言の趣旨が大幅に変更されることがないよう促す雰囲気だけを作っておく）。

「発言更新」ブロックにおいて、発言者本人が更新を行う場合には、更新内容を即座に反映させるが、その更新内容は、原則として、親子関係にある発言の発言者には通知されるようにしておく（更新前と更新後の内容が対比できる形で確認できるようにしておくとさらに分かりやすい）。この通知には、拒絶オプションを添えておいて、通知を受け取ったものは通知のなかで更新された発言との関係を維持するか、切るかを一方的に選択することができるようにしておく。ただし、自身の発言の子孫または先祖に該当する発言の更新に関する情報を受信するかどうかは、各発言者本人が、発言毎に設定できるようにしておき、そのポリシーを尊重する形で通知が行われるようにしておく。

「発言更新」ブロックにおいて、発言者本人でない者が更新を行う場合には、すぐに更新するのではなく、まずは更新内容の仮設定がなされ、発言者本人に対してオファー（更新内容に関する承認を要求する通知）が送信される。これに対し、発言者本人が承認した時点で仮設定の内容をドキュメントのデータに反映し、拒絶されたら仮設定はキャンセルされるようにしておく。さらに、これらのオファーを送信する際には、発言者本人へのメッセージを添えることができるようにしておく。

さらに、以下に記載する「ホワイト・ボード」ブロックを実装する場合には、「新規発言」ブロック及び「発言更新」ブロックにおいて、「図を追加」ボタンを配置し、このボタンをクリックすると、図の名前とソースの場所を入力するためのインタフェースを立ち上げ、求められた情報を入力すると、カーソルの位置に図を貼り、サムネイルをどこかに表示するようにしておく。

「ホワイト・ボード」ブロックは、その議論のなかで参照される図画を表示する（図４０）。「発言ボード」ブロック、または「カレント・スコープ」ブロックで発言が選択されたとき、その発言に図への参照が含まれている場合、その図を表示する。 選択された発言のなかに複数の図への参照が含まれている場合には、デフォルトでは代表的な図（指定されていない場合には最初に参照されるもの）を表示し、その他の図は「近隣図」としてサムネイルを表示する。

ブロック内下部の図画表示エリアに図を表示し、上部に「近隣図」のサムネイルが表示される。サムネイルをクリックすると、図画表示エリアに表示される図が切り替わる。図画表示エリアの図をクリックすると、フルサイズの画像が別ウインドウで立ち上がる。また、図を右クリックして表示されるメニューの中から、「この図を参照する自由発言を追加」を選択すると、その図を参照する自由発言を追加できるようにしておく。サムネイルの表示範囲の切替は、サムネイルの左右に配置された矢印ボタンをクリックすることにより行うことができるようにしておく。なお、このサムネイルの切替は、輪状のフィルムが回転するようなイメージで、回転が加速的にスタートして減速して停止するといった、感覚的に分かりやすい切替ができるようにしておくことも可能である。表示範囲にある任意のサムネイルをクリックすると、そのサムネイルが示す図を図画表示エリアに表示する。

「ホワイト・ボード」ブロックでは、ドキュメント内の各要素から参照される図は、「近隣指数」の高いものを「近隣図」として取り扱う。近隣図はサムネイルに表示して直ぐに参照できるようにする。近隣指数の計算式は別途定めるが、選択された同じ発言の中で参照されている別の図は近隣指数が最大に近い値を取り、複数の発言から参照される図に関しては、参照元が重複する図ほど近隣指数がさらに高い値を取り、選択された発言が構造化された発言である場合には、選択された発言の親子或いは親類関係の発言のなかで参照されている図は近隣指数がある程度高くなるように計算式を設定する。サムネイルは、近隣指数の高い順に中央から順に配置され、左または右に進めば進むほど近隣指数は低くなる（ある程度以上はプレーンになる）。サムネイルの配置は、輪状に構成され、1周すると元のサムネイル・リストの表示に戻る（なおこのモデルでは、新しい発言が選択される度にサムネイルの配置を再構成されることとなるが、サムネイルの相対的な配置が選択される発言に関わらず一定であるモデルを適用することも想定される）。

「リンク・リソース」ブロックは、議論を進める上で参照すべきリソースを提示する（図４１）。ここで取り扱うリソースには外部リソースと内部リソースがあって、それぞれブロック内に備えられる別々のタグの中で一覧として整理する。 一覧からリソースを選択すると、選択したリソースの内容を表示する。原則として、ポップアップされる別ウインドウにて表示するが、内部リソースはシステム内に準備された他のブロック内のコンテンツとして表示するようにしておくことも想定される。

表示順序は、その議論のなかで、そのリソースへのリンク数が多い順を基本とするが、新着順でも表示できるようにしておく。ただし、前者の場合、同じ人が複数の発言で同じリソースを参照したとしても、それは重複してカウントしないこととする（これは特定のリソースの表示順序を上げることを主たる目的とした不毛な発言が繰り返されるのを抑止する必要があるためである）。さらに複雑な順序計算のメカニズムを導入することも想定され、これに対応できる設計としておくことが期待される。

外部リソースとしては、主に報告書等のように充分に整理され、ある程度確定されたたドキュメント（ＰＤＦ、ＨＴＭＬ、または何らかの形式のウェブ・ドキュメント）を想定するが、一般のウェブサイト（例えば、組織のサイト）やその一部（例えば、掲示板の中のあるトピックに関するもの）へのリンクも可能とする。一方、内部リソースとしては、他の議論、特定の発言、社会問題、政策議題、ユーザ情報等のデータを参照することが想定される。

基本的には「新規発言」ブロックにおける新規発言登録操作が実行された際、または「発言更新」ブロックにおける発言更新操作が実行された際に、新たに追加されたリンク・リソースがある場合、このリンク・リソースを自動的に検出し、「リンク・リソース」ブロックに表示するリンク・リソースとして追加するようにする。また、「リンク・リソース」ブロックでの操作により、リソース登録だけの操作も可能としておく。また、「リンク・リソース」ブロック上で、リソースを指定して右クリックすると表示されるメニューの中から、「このリンク・リソースを参照する自由発言を追加」を選択すると、そのリンク・リソースを参照する新たな自由発言を追加することができるようにしておく。

以上の各ブロックを通じてドキュメントに含まれる要素に対する更新操作のパターンを、操作内容、操作者、操作対象の観点から列挙すると、様々なパターンが挙げられる。このうちいくつかについて取り上げてみる。例えば、操作番号Ａ００１の操作においては、ユーザＡの操作により、ユーザＡの自由発言（＝他の発言に関連付けられていない発言、以下同様）を、ユーザＢの自由発言の子に位置付ける編集操作（発言内容の修正を行う場合も含む）を行った場合、承認要求がユーザＡからユーザＢに送信されて、この承認要求が承認された場合に、ユーザＡの自由発言をユーザＢの自由発言の子にするという構造化を行い（関係定義情報を与え）、編集が完了するというものである。或いは、操作番号Ａ０１０の操作においては、ユーザＣの操作により、ユーザＡの構造発言（＝他の発言に関連付けられた発言、少なくとも１組の親子関係の親または子に位置付けられている場合を含む、以下同様）を、ユーザＢの自由発言の子に位置付ける編集操作（発言内容の修正を行う場合も含む）を行った場合、承認要求がユーザＣからユーザＡとユーザＢに送信されて、この承認要求が承認された場合に、ユーザＢの自由発言をユーザＡの構造発言の親にするという構造化を行い（関係定義情報を与え）、編集が完了するというものである。或いは、操作番号Ａ０１６の操作においては、ユーザＡの操作により、ユーザＡの第一の構造発言を、ユーザＡの第二の構造発言の子に位置付ける編集操作（発言内容の修正を行う場合も含む）を行った場合、承認要求はどのユーザにも送信されず、操作後即座にユーザＡの第一の構造発言をユーザＡの第二の構造発言の子にするという構造化を行い（関係定義情報を与え）、編集が完了するというものである。或いは、操作番号Ａ０２２の操作においては、ユーザＡの操作により、ユーザＡの第一の自由発言に、ユーザＡの発言を新たに子として追加する編集操作を行った場合、承認要求はどのユーザにも送信されず、操作後即座にユーザＡの第一の構造発言の子としてユーザＡの新たな発言が追加され、編集が完了するというものである。省略した他の編集操作についても同様のプロセスを実現するものとする。

次に述べる「私の発言」、「私へのオファー」、「私からのオファー」の各ブロックで提供される機能は、「プライベート・エリア」内で、さらに表示内容及び操作内容を切り分けるためのタブとして実現しても構わない。これらの機能は、ユーザ毎に異なる情報が提示され、ユーザ毎に異なるサービスを提供するものである。また、本実施例では言及しないが、「私の注目する発言」、「私の指示する発言」等、「私の発言」、「私へのオファー」、「私からのオファー」以外のブロックを提供することも想定される。

「私の発言」ブロックは、これまでそのユーザが行った発言の一覧を示す（図４３）。各発言に関する情報はブロック形式でレイアウトし、この中では、発言ＩＤ（個人毎に設定されるシリアル番号）と発言のリード（書き出し）２行程度を示すといった形態で整理された情報を示す。各発言に関する情報を示すブロックの上部には、各発言に、付与するウェイトを示す。ウェイトがゼロの場合は表示を薄くして目障りでないようにする。クリックすると、ウェイトの数字を変更することができる。設定可能なウェイトに上限を設ける際には、設定済みのウェイトの合計値と残り値をどこかに表示する。また、各発言に関する情報を示すブロックの下部には、各発言の下部には、発言の日時、テーマ、議論のタイトル（書き出しのみ）、発言のステイタス（構造発言の場合には階層レベルと発言の種類、自由発言の場合にはその旨と発言の種類を提示）を添える。各発言に関する情報を示すブロックをクリックするとその発言や他の発言との関係に関する詳細を確認できるようにしておく。

なお、「私の発言」ブロック内の上部には、このブロック内に表示されるコンテンツを何らかの方法で印刷する機能を動作させるためのボタンや、検索、ソーティング等の条件情報を入力するための手段などを供えておくことができる。例えば、検索用のキーワードを入力するテキスト・フィールドにキーワードを入力後、リターン・キーを押すと検索を実行し、検索結果（入力したキーワードを含む発言）のみを抽出して下部にリストアップするようにしておく。また、表示方法欄に準備された項目のいずれかを選択すると、発言の表示順序を選べるようにしておく（テーマ順、活発順、時間順、重要順、議題順等）。

「私へのオファー」ブロックは、ユーザの発言に対するオファー（承認要求）の内容を提示し、これに対する処分を決める情報（承認、または拒否）とその理由（承認要求者へのメッセージ）を入力するためのインタフェースを提供する（図４４）。デフォルトで示されるオファーは、現在返信が求められているものとしておく。ブロック上部の「過去のオファーを見る」というボタンを押すと、過去に自分が受けたオファー（既に承認又は拒絶の返信をして処理が済んでいるもの）の一覧を示す。またブロック上部の「表示方法」を選択することにより、自分へのオファーの順序を並び替えることができるようにしておく。

表示部では、まずオファーが提示されている自分の発言を示す。発言番号とリードをまず示し、発言日、メインテーマ、議題文、ポジションを示す。これらの情報にマウスオーバーすると、全文の内容が確認できるようにしておく。この「自分の発言」を示す下に、この発言へのオファーの一覧がぶら下がるように表示されるようにする。

オファーの内容はオファー毎にブロック形式で表示される。各オファーを表示するブロック内では、まずオファーＩＤ（オファーを受けるユーザごとに設定されるシリアル番号）、次いでオファーの内容が表示される。例えば、オファーの内容が構造調整の場合、「どの発言の何というポジション（又は自由発言）から、どの発言の何というポジション（又は自由発言）に変更」といったスタイルで示される。或いは、オファーの内容が内容変更の場合、「どの発言（上記発言の繰り返しになる）の内容を何に変更」といったスタイルで示される。この下に、オファーの日時、回答期限、回答期限までの残り時間等を示す。残り時間があと僅かになると、色を変えて分かりやすく表示する。さらにその下には、オファーした人からのメッセージを示す。メッセージがない場合は空欄のまま処理する。

各オファーの内容を表示するブロックの右端の詳細ボタンを押すと、仮にオファーを承諾した場合、この発言のポジションと内容は実際にどういった形になるのかを確認することができる（なお、確認画面においても、以下の各操作はできるようにしておく）。保留ボタンを押すと、操作した時点から規定時間（例えば、24時間）後まで、回答期限を延長することができる。保留後の期限が当初の期限よりも前である場合には操作は適用されない。一度だけ押すことができ、保留操作後このボタンは消えてしまう。承認ボタンを押すと、意思確認プロセス（ポップアップ・ウインドウをイメージ）を経た後、このオファーを承認する操作が実行される。同じオファーに対する複数のオファーがある場合、1つのオファーを承認すると、他のオファーは自動的に拒絶されてしまう。ただし、競合しない複数のオファーを受けている場合、この拒絶は適用しない（文言調整と構造調整のオファーを受けている場合等）。また、承認、拒絶、いずれの操作も行わないまま回答期限が過ぎた際には、自動的に「見做し承認」として、承認と同様に取り扱われる。回答期限は、オファーが提示されてから規定時間（例えば、48時間）が経過した時点に設定され、保留ボタンが押された際には、延長される。拒否ボタンを押すと、意思確認プロセスを経た後、このオファーを拒否する操作が実行される。

また、各オファーの内容を表示するブロックの下部には、お返事用のエリアが準備されている。オファーに対して自分の考えを書くことができるようにしておく。基本的に、承認、拒否のいずれかのボタンを操作したときにここに記載した内容が相手に伝えられる。別の使い方としては、承認、拒否の操作をするよりも前の段階で、記入したメモが再度開いたときにも残っているようにして、個人的なメモとして使える機能を持たせてもよい。例えば、「このメッセージはちょっと言い過ぎな気がする」といったメモを残しておいて、しばらく考えてみた後、再度このページを開いたときにそのメモが残っているといった形で使えるようにしておく。

このシステムでは、同じ要素に対し複数のオファーが提示される可能性が大きい。同じ要素に対する複数のオファーは基本的に競合する場合が多い。メールを用いてでも、この問題を解決することはできるが、より使いやすい（インタフェース）を取り入れるため、ウェブを用いる（非同期に発生するオファーを最新の状態で比較しやすくかつユーザが冗長な情報を受け取らなくても済む環境を実現するのに適している）。なお、オファーした人の名前をここに表示するかどうかについては、する場合としない場合、それぞれメリットとデメリットがあり、議論のテーマや参加するユーザのコミュニティの性質等により判断されることとする。

「私からのオファー」ブロックは、ユーザ自身が出したオファーで、現在アクティブなもの（オファーを出して承認待ち状態のものと、承認又は拒否されてまだ確認していないもの）の一覧を示す（図４５）。ブロック上部の「過去のオファーを見る」というボタンを押すと、過去に自分が出したオファー（既に承認又は拒否の返信があり確認処理が済んでいるもの）の一覧を示す。またブロック上部の「表示方法」を選択することにより、自分へのオファーの順序を並び替えることができるようにしておく。

オファーの内容はオファー毎にブロック形式で表示される。各オファーを表示するブロック内では、まずオファーＩＤ（オファーをするユーザごとに設定されるシリアル番号、同じオファーであっても状況に応じて異なるシリアル番号が付与される）、次いでオファーの対象となる発言の内容（２行程度のリードに、各種情報を添えるイメージ）を示す。その後に、オファーの内容が表示される。例えば、オファーの内容が構造調整の場合、「どの発言の何というポジション（又は自由発言）から、どの発言の何というポジション（又は自由発言）に変更」といったスタイルで示される。或いは、オファーの内容が内容変更の場合、「どの発言（上記発言の繰り返しになる）の内容を何に変更」といったスタイルで示される。この下に、オファーの日時、回答期限、回答期限までの残り時間等を示す。残り時間があと僅かになると、色を変えて分かりやすく表示する。さらにその下には、オファーした際に記載したメッセージを表示し、送信したメッセージがない場合は空欄のまま処理する。既に承認または拒否の反応が得られている場合には、相手からのお返事（ない場合は空欄）を表示する。

各オファーの内容を表示するブロックの右肩に、各オファーのステイタスを表示する。承認待ちの場合は、「承認待ち」と表示。承認された場合には「承認済み」、拒否された場合は「拒否済み」と表示し、確認ボタンを添える。この確認ボタンを押せば、このリストから外れ、「過去のオファー」として整理される。各オファーの内容を表示するブロックの右端の詳細ボタンを押すと、仮にオファーを承諾された場合、この発言のポジションと内容は実際にどういった形になるのかを確認することができる。

なお、本システムは、ユーザ・インタフェースとしては特に示されないが、支持構造のプロパゲーションを計算するメカニズムを備えているものとする。幾つかの樹系構造のなかから１つを選ばなければならない場合、樹系構造のなかの支持状況を評価して評価の高い樹系構造を選択することとする。評価に当たっては、樹系構造のなかで支持票数をプロパゲートさせて、樹系構造のルートがどれだけ重く評価されているかを計算して、これを比較するものとする。

比較が必要なのは、ドキュメントの取りまとめを行う特別な権限を保持するユーザ（以下、「ファシリテイター」）が並列する複数の樹系構造を１つに集約するよう指示した場合である。例えば、質問ドキュメントをの内容を確定する際に、重複事項を含む複数の選択肢を調整する必要がある場合などがこれに該当する。これは必ずしもルートである必要はなく、ファシリテイターが調整の必要性を認識した任意の樹系構造において実施することができる（ただし、この数字は樹系構造の中で日常的に示されていることが望ましい。正確な数値を計算できなければ参考値を提示する）。

ファシリテイターが「支持構造による採択発言の選定」を実施することを宣言すると、議論の場においてその旨が示され、該当する樹系構造に含まれる全ての発言の発言者にその旨の通知がなされ、ファシリテイターが設定した期間、そこでの調整（右の「支持票獲得合戦」を参照）が進められる。期限がくると、調整プロセスは終了し、その時点での樹系構造がフィックスされ、採択発言が選定される。万が一、累積支持票数が全く同数になった場合は、ファシリテイターは期限の延長を宣言するか、自身の1票を行使して採択発言を選定することができる。

支持票数の計算方式は以下の通りである（図４６）。（１）全ての発言は原則として1票の支持票数を有する。ただし、「プライベート・エリア」の「私の発言」において、ウェイトＡを配分している際には、上記1票に、子のウェイトＡの数値を加算したものがその発言の支持票数となる。（２）子のない発言の累積支持票数は自身の支持票数である。子のある発言の累積支持票数は、自身の支持票数に、全ての子の累積支持票数を加算したものである。ただし、子の発言がネガティブ発言（プロパティにおいて「異議」等が設定されている発言）である場合には、子の累積支持票数は正負を反転させる（−１を乗じた上で加算する）。従って、累積支持票数が負の数値を取ることもありうる（累積支持票数が負の値である際の取り扱いについては、別途ルールを設ける必要があると思われるが、これは後の対応とする）。（３）同じ樹系構造の中に位置する同じアクターによる発言の票数は重複加算しないものとする。計算対象とする発言の票数の選びかたとしては、その樹系構造の支持票数（樹系構造のルートとなる発言に与えられる累積支持票数）が最大値となるものを選択するものとする。（４）支持しない場合には、意図的に支持構造から離反することもありうるが、その際には累積支持票数の更新も行う必要がある。

以上のメカニズムを機能させることにより、本システム上では次のような支持獲得競争が進められることが可能となる。質問ドキュメントの内容を確定する直前に、複数の選択肢候補の間に重複事項が検出された場合には、その両方の選択肢を同じ議題のなかに収納することはできない。その際には、まず選択肢候補の間で文言等を調整することが期待される。それで重複事項を排除することができれば問題は解決する。しかし、選択肢候補の間での調整によって重複を解決することができない場合、どちらか一方の選択肢しかその議題の中に収納することはできない。この場合には、両者の選択肢候補にぶら下がる樹系構造において、支持票数が大きいものが択一されることとなる。その際には、両方の樹系構造に存在する各モジュールは、互いの樹形構造のなかに位置する他の要素に対しオファーを出し合い、樹系構造の支持を拡大しようとする。この競争は、調整期日を設けてファシリテイターのマネジメントによって実施されることが想定されるが、質問ドキュメントの内容を確定する期日が近づくにつれ、自然と発生する場合もあると予測される。この支持獲得競争のプロセスの中で、議論やドキュメントの内容の最適化が進められると期待される。

なお、当業者であれば容易にイメージが持てるものとして以上には記載していないが、ユーザ登録インタフェース、管理用インタフェース等、システムを動作させるのに必要な基本的な機能は別に備えられていることを前提とする。

ドキュメント入力編集システムの基本形１ ドキュメント入力編集システムの基本形２ ドキュメント入力編集システムの基本形３ ドキュメント入力編集システムの基本形４ 属性情報が付与されるパターン（Ａは、要素に付随する情報として付与する場合。Ｂは、関係定義情報に付随する情報として付与する場合） 関係定義情報を保持するデータ構造の例（Ａは、属性を要素に付随する情報として持たせた場合。Ｂは、属性を関係定義情報に付随する情報として持たせた場合。Ｃは、要素の内容と関係定義情報を同じテーブルに持たせた場合） ツリー構造 各要素を他の複数の要素に関係付けられるようにする場合の、要素間の関係及びデータ構造の例 要素間の構造がツリー構造として定義され、一部の要素が他の複数の要素（親要素）に関連付けられる場合の、要素間のデータ構造の例 ＧＵＩ上でのポインタを用いた操作により各要素の他の要素に対する関係を定義する関係定義情報を編集する操作の例（新たな関係を付与する操作の例） ＧＵＩ上でのポインタを用いた操作により各要素の他の要素に対する関係を定義する関係定義情報を編集する操作の例（既存の関係を削除する操作の例） 異文書要素間関係入力編集手段、要素帰属先文書変更手段、要素異文書複製手段、要素複数文書同時帰属手段による複数のドキュメント間のデータ構造編集操作の例 全体的構造表示手段と局部的構造表示手段とを具備するドキュメント入力編集システムにおける、全体的構造表示手段と局部的構造表示手段との間の操作および表示内容に関する連携動作の例 特定関連要素表示切替手段による表示内容切り換えの例１（特定の要素の下位に位置付けられる要素の表示／非表示を切り替えの対象とする場合） 特定関連要素表示切替手段による表示内容切り換えの例２（特定された複数の要素の下位に位置付けられる指定された属性が付与された要素の表示／非表示を切り替えの対象とする場合） 特定関連要素表示切替手段による表示内容切り換えの例３（「−」アイコンと「＋」アイコンとにより、表示／非表示の切り替えの対象とされる各要素の表示状況を明示する仕様を採用した場合） 抽出された要素に関する表示（Ａは、抽出された要素のみの表示。Ｂは、抽出された要素とこれに関係付けられた要素のみの表示。Ｃは、抽出された要素を強調表示。Ｄは、抽出された要素とこれに関係付けられた要素を強調表示） 検索条件情報またはソーティング条件情報を入力または特定する手段の例 要素支配権ユーザ特定情報を保持するデータ構造の例（Ａは、要素データと要素支配ユーザＩＤを別々のテーブルにおいて持たせる場合。Ｂは、要素データと要素支配ユーザＩＤを同じテーブルにおいて持たせる場合。Ｃは、処分の内容毎に要素支配権を設定することを可能とする場合） 編集対象となる要素または編集操作に関連する要素が、編集操作者が要素支配権を保持しない要素である場合に、該要素の要素支配権を保持するユーザに承認を求め、その応答を処理するプロセス 要素支配ユーザに該編集内容を提示し、要素支配ユーザがこれに対する承認の可否を入力するためのインタフェースの例（一覧表示画面と詳細表示画面） 編集内容が他の要素支配権保持者の承認を必要とする際に、編集操作入力後に提示されるインタフェースの例（要素支配権保持者へのメッセージを入力するためのテキスト・エリアが備えられている） 各要素の編集履歴を表示するインタフェースの例（履歴一覧表示画面と履歴詳細表示画面） 操作権限をユーザ毎に設定する場合のユーザ情報を記録するテーブルの例（Ａは、各操作権限を個別に設定する場合。Ｂは、権限レベルを設定することにより各操作権限を設定する場合） 段落０１０３に記載の要素関係自動編集手段による自動編集の際のルールの例 編集ドキュメントから完成ドキュメントを作成する操作または処理の例 編集ドキュメントに含まれる要素（編集要素）と完成ドキュメントに含まれる要素（完成要素）との対応関係 完成ドキュメントを構成する要素間の構造と編集ドキュメントを構成する要素間の構造との対応関係に関する規則が付与された場合における完成ドキュメント作成の例 アンケート実施手段を具備するドキュメント入力編集システム アンケート実施手段を具備する外部システムにアンケート文書を提供するアンケート文書提供手段を具備するドキュメント入力編集システム 段落０１３１に記載のステイタス情報参照手段とステイタス情報提示手段とを具備したドキュメント入力編集システム 請求項３に記載のステイタス情報変化検出手段とステイタス情報通知手段とを具備したドキュメント入力編集システム 実施例１に記載の「議論一覧」ブロックのイメージ図 実施例１に記載の「全体マップ」ブロックのイメージ図 実施例１に記載の「カレント・スコープ」ブロックのイメージ図 実施例１に記載の「発言ボード」ブロックのイメージ図 実施例１に記載の「発言ビューア」ブロックのイメージ図 実施例１に記載の「新規発言」ブロックのイメージ図 実施例１に記載の「発言更新」ブロックのイメージ図 実施例１に記載の「ホワイト・ボード」ブロックのイメージ図 実施例１に記載の「リンク・リソース」ブロックのイメージ図 実施例１に記載のドキュメント入力編集システムにおける編集操作のパターン 実施例１に記載の「私の発言」ブロックのイメージ図 実施例１に記載の「私へのオファー」ブロックのイメージ図 実施例１に記載の「私からのオファー」ブロックのイメージ図 実施例１に記載のドキュメント入力編集システムにおける支持構造のプロパゲーション 実施例１に記載のドキュメント入力編集システムにおいて進められる支持獲得競争

Claims (4)

1. ネットワーク上で機能し、複数ユーザの参加が可能なドキュメント入力編集システムであって、
   該ドキュメント入力編集システムで取り扱われるドキュメントに関する情報を管理するドキュメント情報管理手段と、
   該ドキュメントに含まれる要素に関する情報を管理する要素情報管理手段と、
   該ドキュメントに含まれる任意の要素と他の要素との関係を定義する情報（以下、「関係
   定義情報」）を管理する関係定義情報管理手段と、
   ユーザ・アカウント情報を管理するユーザ管理手段と、
   以下に示す少なくともいずれかの手段を用いた操作を行うユーザを識別または認証するユーザ識別認証手段と、
   ユーザによる操作を通じてドキュメントに含まれる要素を入力または特定する要素入力特定手段と、
   少なくともいずれかのユーザによる操作を通じて該要素の内容を編集する要素内容編集手段と、
   少なくともいずれかのユーザによる操作を通じて該要素または該要素の他の要素に対する関係の属性を入力または特定する要素属性入力特定手段と、
   該関係定義情報管理手段において管理される関係定義情報に基づき該ドキュメントに含まれる各要素をツリー状に構造化された状態で表示する構造表示手段と、
   要素及び要素間の構造を視覚的（グラフィカル）に表示するユーザ・インタフェース（以
   下、「GUI」）と、
   少なくともいずれかのユーザによる該構造表示手段によって表示される要素に対する操作を通じて該要素の他の要素との関係を入力または編集する要素関係入力編集手段と、
   該ドキュメントに含まれる各要素に関し、当該要素に対する処分を決定する権限（以下、「要素支配権」）を保持するユーザを特定する要素支配ユーザ特定情報を管理する要素支
   配ユーザ特定情報管理手段と、
   要素内容編集手段、要素属性編集手段、要素関係入力編集手段の少なくともいずれかを用いた編集操作において、編集対象となる要素または該編集操作に関連する要素が、該編集操作の操作者が要素支配権を保持しない要素である場合、該要素の要素支配権を保持するユーザに、該編集操作の内容について承認を求める承認要求手段と、
   該承認要求手段が機能するのに応じて、概要その要素支配権を保持するユーザに、該編集操作の内容に応じて承認又は拒絶の意思を特定させる承認拒絶手段と、
   該ドキュメント入力編集システムにおいて編集操作可能な状態にあるドキュメント（以下、「編集ドキュメント」）を、要素の属性及び関係定義情報並びに該関係定義情報に基づく要素の構造化のパターン等の情報を対象とする明確な規則、または該情報に応じて与えられる明確な規則に沿って、計算機上の処理、特別な権限（以下、「ドキュメント取りまとめ権限」）が与えられたユーザの操作、またはこの両方によって実行されるプロセスによって、整理することにより定義されるドキュメント（以下、「完成ドキュメント」）を作成する完成ドキュメント作成手段と、
   を具備し、
   該要素関係入力編集手段は、該GUIにおいて、関係元の要素と関係先の要素の両方もしくは少なくとも一方または要素間の関係を示す表示部を、ポインティング・デバイスによって操作されるポインタの位置及び該ポインティング・デバイスを通じて与えられるイベントによって特定することによって、該編集に必要な情報が与えられるものであり、
   該完成ドキュメント作成手段において、編集ドキュメントに含まれる各要素（以下、「編集要素」）のうち、完成ドキュメントに含まれる要素（以下、「完成要素」）として取り上げる、または完成要素を作成するための素材とされる編集要素を選定する基準（以下、「要素選定基準」）として、選定の候補となる各編集要素に付随する任意の情報、該編集要素と直接または間接的に関係付けられた要素に関する情報、該関係定義情報に基づく要素の構造化のパターンに関する情報とのうち少なくともいずれかの情報またはこれに基づき計算される情報を評価の対象とする基準が用いられ、該プロセスが該要素選定基準に沿ったものとなるよう制約を受けていることを特徴とするドキュメント入力編集システム。
2. 請求項１に記載のドキュメント入力編集システムであって、ユーザが自身の入力または編集した要素に関する情報を管理または確認するために用いられる表示フィールド（以下、「自己入力編集要素表示手段」）と、編集ドキュメントまたは完成ドキュメントの内容を確認するために用いられる表示フィールド（以下、「ドキュメント内容表示手段」）とのうち、少なくともいずれかの表示フィールドを具備し、該表示フィールドの少なくともいずれかにおいて、ユーザが自身または他のユーザの入力または特定した要素に対し重み付け情報（以下、「要素ウェイト情報」）を設定する要素ウェイト情報設定手段を具備し、該要素選定基準として、該要素ウェイト情報またはこれを用いた計算により求められる数値を評価の対象とする基準を用いることを特徴とするもの。
3. 請求項１乃至２に記載のドキュメント入力編集システムであって、完成ドキュメントまたは該完成ドキュメントに基づき作成された情報もしくは該完成ドキュメントに関連付けられた情報に対し付与されるステイタス情報もしくは該ステイタス情報の変化を検出するステイタス情報変化検出手段と、該完成ドキュメントに含まれる材料を提供した編集ドキュメントに含まれる要素を入力もしくは特定したユーザ（以下、「入力特定ユーザ」）または該入力特定ユーザを指定する別のユーザ（以下、「指定ユーザ」）に対し、該ステイタス情報変化検出手段において検出された変化が予め定められた条件に該当する場合もしくは他の条件において該ユーザ（入力特定ユーザまたは指定ユーザ）の指定する条件が満たされた場合において、または特定のルールによって与えられるタイミングもしくは該ユーザ（入力特定ユーザまたは指定ユーザ）の指定するタイミングにおいて、該ステイタスまたは該変化に関する通知を行うステイタス情報通知手段と、を具備することを特徴とするもの。
4. 請求項１乃至３に記載されたドキュメント入力編集システムの各手段として機能するコンピュータ・プログラム。