(57)【要約】【課題】図式的項目間関連二次元表現から文書骨格を作成するだけでなく、本文を含む文書を作成し、かつ文書における編集結果を図式的項目間関連二次元表現に反映して、図式と文書の相互連携を高めることを課題とする。【解決手段】図式的項目間関連二次元表現手段１側に各項目の図式側本文生成・編集手段２および図式側蓄積手段３を設け、図式−ワード・プロセサ手段４で付加タグを付加して、本文を含む文書情報をワード・プロセサ手段７に引き渡す。ワード・プロセサ手段７側では付加タグを変更することなく、項目と本文を変更・編集できる。そしてワード・プロセサ−図式手段５において、付加タグを検知して、ワード・プロセサ手段７側で変更された項目と本文の情報を抜き出し、図式的項目間関連二次元表現手段１に引き渡す。これによって図式的項目間関連二次元表現と文書の相互連携を行う。【選択図】図３
2008282227.tif 000002
【特許請求の範囲】
【請求項１】
図式側本文生成・編集手段と図式側蓄積手段を備えた図式的項目間関連二次元表現手段と、ワード・プロセサ手段と、各項目と各本文に付加タグを付してワード・プロセサ手段に引き渡す図式−ワード・プロセサ手段を備えることを特徴とする情報処理装置。
【請求項２】
図式側本文生成・編集手段と図式側蓄積手段を備えた図式的項目間関連二次元表現手段と、ワード・プロセサ手段と、ワード・プロセサ手段における各項目と各本文の付加タグを分析することによって各項目と各本文を分離して図式的項目間関連二次元表現手段に引き渡すワード・プロセサ−図式手段を備えることを特徴とする情報処理装置。
【請求項３】
図式側本文生成・編集手段と図式側蓄積手段を備えた図式的項目間関連二次元表現手段と、ワード・プロセサ手段と、各項目と各本文に付加タグを付してワード・プロセサ手段に引き渡す図式−ワード・プロセサ手段と、ワード・プロセサ手段における各項目と各本文の付加タグを分析することによって各項目と各本文を分離して図式的項目間関連二次元表現手段に引き渡すワード・プロセサ−図式手段を備えることを特徴とする情報処理装置。
【請求項４】
請求項１から３のいずれかの情報処理装置であって、付加タグをワード・プロセサ手段でユーザ書き換え禁止とすることを特徴とする情報処理装置。
【請求項５】
請求項１から４のいずれかの情報処理装置であって、項目順序変更手段を備えることを特徴とする情報処理装置。
【請求項６】
請求項１から５のいずれかの情報処理装置であって、隠しワード・プロセサ手段を備え、ワード・プロセサ手段における文書の付加タグの一部を削除して隠しワード・プロセサ手段に移す用途に供するワード・プロセサ−隠しワード・プロセサ手段を備えることを特徴とする情報処理装置。
【請求項７】
請求項１から請求項６の各該請求項に含まれる全手段の機能を実現するステップを備える情報処理方法。
【請求項８】
請求項１から請求項６のいずれかとして情報処理装置を機能させる情報処理プログラム。
【請求項９】
前記請求項の情報処理プログラムを記録した情報処理装置読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＫＪ法やマインドマップ等の図式的項目間関連二次元表現等を用いて、着想支援や、情報整理や、情報記憶の促進や、文書作成の支援等を、情報処理装置で行う際の発明に関するものである。
【背景技術】
【０００２】
独創的な着想を生み出す補助とするために、さまざまな着想支援法が提案されてきた。二次元図式的な着想支援法として、わが国で広く用いられて代表的な方法の一つは、川喜田二郎氏の非特許文献１にある紙カード式の「ＫＪ法」であり、以後でＫＪ法と呼ぶ際は川喜田二郎氏の方法を指す。また海外では英国のTony Buzan氏による非特許文献２にある「マインドマップ（Mind
Map）」も普及している。その他にもさまざまな二次元図式的着想支援法が開発されている。これらは新規な着想の支援を行ったり、収集した情報を整理するためや、情報を記憶しやすくするためや、文書作成を支援するため等に用いられ、説明の補助として客先で用いる等の用途に供されることも多い。これらの表現法の表現は多様であるが、その本質は似通っているため、ここではこれらの表現法をまとめて「図式的項目間関連二次元表現法」という言葉で代表して呼び、また作成された図式を「図式的項目間関連二次元表現」と呼ぶことにする。
【非特許文献１】川喜田二郎、『川喜田二郎著作集  第５巻』、中央公論社、１９９６年
【非特許文献２】トニー・ブザン、バリー・ブザン著、神田昌典訳,『ザ・マインドマップ』、ダイヤモンド社、２００５年（原著：The Mind Map Book、複数出版社より）
【０００３】
図式的項目間関連二次元表現の代表的な例として、図１に掲げるのは、紙カード式のＫＪ法等の京都大学式のいわゆる紙切れ法等と呼ばれる図式的項目間関連二次元表現を、本発明の情報処理装置で表現した例である。この図では図式的項目間関連二次元表現の代表的ないくつかをカード中に例示している。過去の京都大学式の表現法を代表してきたＫＪ法では、事柄や概念などを紙のカードに記載していく。１枚のカードに記載される情報を、ここでは「項目」という言葉で呼ぶ。項目においては少ない文字数で要約した表現がとられるのが通常である。項目を記載した多数のカードを机上に並べ、関連のあるものをグループ化する。複数のグループやカードを集めて、さらにグループ化を行うという多段のグループ化を行ってよい。そのようにしてできた関連を表現するため、紙の上に多数のカードを並べて、図のようにグループを閉曲線で囲い、またグループ間の関連に補助の線などを用いて表現する。なお、グループにつける名称や、全体として図式につけるタイトルも、項目という言葉で総称することにする。このＫＪ法と類似する方法では、項目間の階層を図式としてはループ等の閉図形で囲んで表現する等が適当であるので、それらを一括して「ループ型」の図式的項目間関連二次元表現と呼ぶことにする。
【０００４】
一方、マインドマップの場合には、グループ化ではなく、枝分かれという表現法を用いている。前記の図１と同じ項目を表現したのが図２である。図１でタイトルに相当する項目を中央に配置し、グループ化に相当する表現を上位項目からの項目の枝分かれによって表示している。マインドマップと類似する方法では、項目間の階層を枝分かれで表現するので、それらを一括して「ツリー型」の図式的項目間関連二次元表現と呼ぶことにする。マインドマップでは中央からの枝分かれとするが、グラフ理論で述べるツリー形状の表現法、魚の骨格に似た表示法となるフィッシュボーン図など表示形態はさまざまに変形される。
【０００５】
これら以外にも、図式的項目間関連二次元表現法はさまざまある。フローチャートと類似して、矢印を用いて、枝分かれや合流を表現する手法も存在する。これらを一括して「流れ図型」の図式的項目間関連二次元表現と呼ぶことにする。また、二次元の表または座標面として、そこに項目を並べるなどの手法も存在する。それらを一括して「マトリックス型」の図式的項目間関連二次元表現と呼ぶことにする。三次元以上の座標を意図した表現もあるが、図式としては紙面や画像ディスプレイ等に表現するため、図式的項目間関連二次元表現である。いずれにしても、ループ型からマトリックス型に至るまで、あるいはその他の図式的表現法を含め、そのすべては複数の「項目」を図式上に二次元に並べた表現であるというのが共通の特徴である。
【０００６】
一方、文書の章・節・項などを目次と同様の方法で並べる手法は一次元的であって、一次元に並んでいるだけでは、文書中で遠い項目間の関係を把握しにくいという欠点が伴う。それに対して、図式的項目間関連二次元表現として項目を二次元表現で並べれば、思いがけない項目間関連等を把握しやすくなる。そのため、このような図式的項目間関連二次元表現法では、項目の二次元上での配置の移動を行ったり、項目とその間の関係を目立たせる補助的な線や図形を描く等の追加的な二次元表現法を提供していることが多い。
【０００７】
従来はこのような図式的項目間関連二次元表現を紙の上に記述して用いていたが、情報処理装置が普及するに伴い、情報処理装置上で実現することが多くなっている。従来のまま紙の上で行うと、書き直しが面倒であり、また紙カードを並べたり貼り付ける際には、カードが散逸するなどの問題が発生するが、情報処理装置上で実現するならば、操作がより容易になると期待されるからである。特にこのような図式的項目間関連二次元表現を用いて着想や項目を整理した後、それをレポート等として文書にまとめる作業を行うことが多いため、ワード・プロセサ機能をもつ情報処理装置上で全作業を行うことができるなら、能率が向上することが多くなる。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかしながら、情報処理装置を用いた図式的項目間関連二次元表現から文書を作成する際、従来からソフトウェアで提供されているのは、「項目」のみを章・節・項等に単に並べるだけの機能にすぎない。それでは、章・節・項等のタイトルのみが並んだ文書にすぎない。本来、各項目には「本文」が付属するはずであるが、本文を含めた文書を、図式的項目間関連二次元表現からワード・プロセサで作成できていないのである。特にワード・プロセサ側で文書の付加・修正作業を行った際、図式的項目間関連二次元表現にそれを反映する機能も実現されていない。
【０００９】
項目だけで構成された章・節・項等の表現を「文書骨格表現」と呼ぼう。一方、文書本文をも含めた表現を「文書全文表現」と呼ぼう。従来のソフトウェアでは文書骨格表現を実現できて、ワード・プロセサ用ファイル、Ｗｅｂページ用のＨＴＭＬファイル、あるいはそれらをＰＤＦ文書ファイル等に表現できるものが存在したが、文書全文表現を図式的項目間関連二次元表現と連携して生成・編集操作等を行える機能は実現されていなかった。
【００１０】
では、なぜそのような文書全文表現の実現が困難を伴ったのであろうか。一つには、図式的項目間関連二次元表現はコンパクトに紙面に表現する必要があるために、本文の情報まで表記しきれず、紙面に表現していた習慣を引き継いで、本文を蓄積する手段を提供しなかったからであろう。しかしながら、それだけが理由ではない。
【００１１】
ループ型やツリー型の図式的項目間関連二次元表現は、文書の章・節・項等の階層構造と厳密に対応させられる表現法がほとんどであるが、図式的項目間関連二次元表現の中には、文書の一次元的構成と対応させにくい表現法も存在する。たとえば流れ図で枝分かれしたり、逆戻りしたりなどは、文書の書き方としてどういう順序で書くべきかに工夫が必要になってくるのは致し方ない。
【００１２】
さらにもう一つの理由は、「連携編集の困難性」にあったというべきである。図式的項目間関連二次元表現では、項目が図式として明示されていて、かつ項目ごとに分けて情報処理装置内に蓄積するという「項目分割蓄積」方式をとることができる。すなわち項目という単位とその間の関連が表現された形式である。ところが、文書全文表現側では、ワード・プロセサの場合、従来から標準化されているＲＴＦ（Rich Text Format）表現等を用いている。ＲＴＦ等のワード・プロセサのための内部データ形式を、ここでは「文書ファイル形式」と呼ぶ。
【００１３】
文書ファイル形式の側で問題となるのは、ＲＴＦ形式を代表とするファイル形式で扱うのは、基本的には見た目の文書を仕上げるための表現形式だということである。高度なワード・プロセサ用ソフトでないＲＴＦ表現等の文書ファイル形式では、文字の大きさや字体は指定できるが、どこが章タイトルであって、どこが節タイトルであり、またどこが本文であるか等の文書の構成情報が含まれないことが多いのである。
【００１４】
したがって、いったん文書ファイル形式で表現したとたん、元の図式的項目間関連二次元表現における項目や本文の集合であるという構造が消えてしまうＲＴＦ表現等が存在することになる。しかも、旧来のＲＴＦ形式等の標準的な形式を用いて開発を行わないことには、独自のワード・プロセサソフトを一から開発して、独自の高機能を盛り込んでいかなければならないことになるので、開発の困難性が著しく増してしまう。
【００１５】
では、図式的項目間関連二次元表現における項目や本文であるという情報が消えてしまった文書ファイル形式において、ワード・プロセサ操作を行って、内容を改変したらどうなるだろうか。ワード・プロセサ文書としてはそれでも使用することに支障はない。しかし、ワード・プロセサ側で行った変更個所を図式的項目間関連二次元表現に反映させようとしても、それは非常に困難だということになる。
【００１６】
もちろん情報処理装置でプログラミングする際には、複雑なプログラミングを行えば、ほとんどのことは可能になる。図式的項目間関連二次元表現が保持するデータと文字列マッチングを行って、人工知能的に判定するのは一法であるが、しばしば正確さに欠ける。また別法として、ワード・プロセサ側で編集操作を行うたびに、どこを変更したかを逐一記録しておき、それを図式的項目間関連二次元表現に反映するなどである。
【００１７】
しかしながら、独自の高度なワード・プロセサ用ソフトを開発しないかぎり、文章のどこにどのような編集操作を行ったかを記録することは困難である。Windows(R)パソコンでプログラミングする場合、多くのソフトウェア開発会社は、通常はriched32.dll（dllはdynamic link libraryの略であって、要するにサブルーチン群からなるソフトウェア部品である）を用いるが、これは旧来からの基本的なＲＴＦ形式の文書を作成するソフトウェア部品であって、章・節・項・本文等を、書かれた文章中で見分けることを主目的とする手段を提供しないのである。
【００１８】
本発明で述べるのは、このように章・節・項等を見分ける手段のないワード・プロセサ機能を提供するriched32.dll等のソフトウェア部品を用いた情報処理装置において、図式的項目間関連二次元表現に編集操作の結果を反映させるための発明である。このような技術は従来の図式的項目間関連二次元表現において実現されていなかったものである。
【課題を解決するための手段】
【００１９】
riched32.dll等に代表されるソフトウェア部品を用いた情報処理装置の有する機能は、文書の作成・編集・表示・保存機能をもつワード・プロセサ手段である。入力した文章が画面上に表示され、紙面に印刷したのと似た状態で視認できるようにしてある。通常のワード・プロセサの基本機能と同じことであって、選択した文字列を反転表示させ、その切り貼りや削除などを行うことが可能であるし、文字列のセンタリングなど配置の変更も行える。また字体の変更や字色の変更なども可能である。作成された文書はＲＴＦ形式など書式情報を含めた文書ファイル形式で内部に保持していて、ファイルに保存する場合も、ＲＴＦ形式等の既定の書式情報が付属した文書ファイル形式のファイルとして保存する。特にＲＴＦ形式のファイルの場合は、他の商用ワード・プロセサソフトでも読み書き操作を行えるので互換性が高い。
【００２０】
ただし、文書のあくまで見かけに関する書式情報しか保持していないのである。文章を保持しているのはもちろんであるが、付属する書式情報としては、字体は何か、字色は何か、センタリングや字下げなど文字の配置はどうするか等の情報である。けっして章・節・項・本文等の目印を付けているわけではない。たとえば自由な形式で書かれた本文中に、章と同じ体裁の文字列が存在すれば、このような単純な書式情報しか保持しないＲＴＦ形式では自動判別が困難となる。
【００２１】
それに対処するには、このようなＲＴＦ等で表現された文書中に独自の目印となる情報を付加すればよい。そのような目印となる付加情報を、ここでは総称して「付加タグ」と呼ぶことにする。タグのような目印は、Ｗｅｂページ用のＨＴＭＬなどの言語でも広く用いられている技術である。
【００２２】
ただし、大きな問題がある。riched32.dllでは、たとえば１６ポイントのゴシック体の文字列に対して、その先頭と末尾とをタグで囲って、１６ポイントのゴシック体であるとの情報を埋め込むタグはあらかじめ提供されている。しかしながら、章の題目の前後を囲む付加タグを新たに定義する等の定義機能があらかじめ提供されていなかったとしたらどうすべきだろうか。
【００２３】
もしも新たな付加タグを無理に文書に付加したとしよう。しかしながら、そのような付加タグは、タぐの定義機能がない場合はタグだと認識されないため、編集対象の文書にそのまま混在して画面に表示されてしまう。表示されるだけではない。それらの付加タグは、ワード・プロセサによってタグと認識されないため、編集可能対象とみなされ、ユーザが付加タグを自由に書き換えて破壊し、図式的項目間関連二次元表現との連携が崩れてしまう恐れがある。
【００２４】
このような困難に対処するためには、最も単純な方法としては、ユーザ自身が十分に注意を払って、付加タグを書き換えないように気をつけるという原始的な方法がある。一方、付加タグをユーザが書き換えることができないように、システム側で情報技術的に工夫を加えるという方法を案出するのがより優れている。そのようにして付加タグ情報をユーザが勝手に書き換えたり、矛盾が生じることがなく、かつ章・節・項・本文等のどこをユーザがワード・プロセサでどのように変更したかを正確に把握できるなら、ワード・プロセサでの変更を、図式的項目間関連二次元表現に正確に反映させることができ、文書と図式との矛盾がなくなる。
【００２５】
図３に示すのは、そのための装置として備える手段をすべて図示した構成である。用途によって、このうち用いない手段を備えない構成でもよい。また、情報処理装置として当然のこととして、情報処理装置用の通常のキーボードやマウスや音声や画像等の入力手段、通常のディスプレイやプリンタや音声等の出力手段、内部で用いる記憶手段やネットワーク等を介した外部記憶手段等を必要に応じて使えるものとする。また、携帯情報機器やデジタル家電製品等の形態をとる場合は、代替する入力・出力・記憶手段等を必要に応じて備えているものとする。
【００２６】
なお、理解を容易にするため、図４に、各手段の用途をわかりやすく図解してある。図式的項目間関連二次元表現は、ＫＪ法を代表例として述べても、情報処理装置内部のデータ構造は、マインドマップ等の他の表現法も似通っていて、装置として実施するのは容易であるため、ここではこのＫＪ法を例にして述べる。
【００２７】
図式的項目間関連二次元表現手段１が、内部で図式的項目間関連二次元表現のために保持する情報は、カードに表示される「項目」の文字列と、文書化した際にその項目に付随する「本文」、章・節・項など階層としての「レベル」、文書に表示される「順序」、図式表現のための各種の「図式情報」等である。図式情報とはカードの位置や、ループの形等の形状と、その位置座標や、カードの色等の情報であるが、文書作成に反映されない場合には、ここで詳しく述べる必要はない。
【００２８】
「項目」、「本文」、「レベル」、「順序」があれば、文書のための基本データがそろい、文書を生成できる。文書を生成するのがワード・プロセサ手段７であり、ワード・プロセサ手段７はriched32.dllを用いてもよいし、その他のワード・プロセサ機能をもつプログラム等で情報処理装置上に実現される。
【００２９】
図式的項目間関連二次元表現手段１からワード・プロセサ手段７に文書データが渡される際に、図式−ワード・プロセサ手段４が文書データに必要な付加タグを生成する。しかもそれだけではない。図式−ワード・プロセサ手段４は、付加タグに「Read Only」という読み取り専用で、書き込みを禁止する情報を付加して、文書内で表示すべき順序に従って各項目と各本文をワード・プロセサ手段７に引き渡すことができる。ワード・プロセサ手段７はriched32.dllの場合も通常は、Read Onlyであることを判断して、文章の一部を変更禁止にする機能を有しているため、それを利用するのである。もちろんRead Onlyにせずに、単にユーザの注意力に任せるという略式の実現法も存在する。
【００３０】
このように図式−ワード・プロセサ手段４を用意して、かつ付加タグをRead Only状態に指定してワード・プロセサ手段７に引き渡すことにより、ワード・プロセサ手段７で文書を表示して、かつ付加タグもワード・プロセサ手段７で明示的に表示していながら、ユーザが付加タグを書き換えることがなくなる。その結果、後述するように、ワード・プロセサ側での文書内容の変更を、図式的項目間関連二次元表現手段１に反映させることができ、図式と文書の連携を実現する可能性が生まれるのである。
【００３１】
図４で、ワード・プロセサ手段７において、下線を引いて表示した部分がRead Onlyの付加タグの例である。文書編集時に、この部分をユーザが崩すことはない。それ以外の部分は「項目」と「本文」であり、書き込み禁止になっていないので、ユーザが自由に書き換えることができる。ワード・プロセサ手段７が通常有するカーソル移動機能やマウス機能でカーソル位置や選択された文字列を指定して、通常のワード・プロセサのように書き換える。しかしながらRead Onlyの付加タグ部は一切書き換えられることがない。
【００３２】
なお、付加タグをユーザ書き換え禁止にする方法として、付加タグをワード・プロセサ手段７で明示的に表示しながらRead Onlyとするという方法とともに、付加タグをワード・プロセサで不可視にするという方法も存在することを付記しておく。Riched32.dllではなく、高度なワード・プロセサソフトウェアの場合、そのような機能がしばしば実装されている。ユーザから付加タグが見えないため、ユーザが付加タグを書き換えることができない。すなわちこれも一種の書き換え禁止法である。ここでは不可視の場合も含めて、書き換え禁止と表現することにする。
【００３３】
さて、本発明の技術をさらに詳しく述べていこう。技術的には下記の５つの部分に大きく分かれる。
（ア）図式的項目間関連二次元表現手段１にかかわるもの
（イ）図式的項目間関連二次元表現手段１からワード・プロセサ手段７へのデータ引き渡しにかかわるもの
（ウ）ワード・プロセサ手段７にかかわるもの
（エ）ワード・プロセサ手段７から図式的項目間関連二次元表現手段１へのデータ引き渡しにかかわるもの
（オ）その他
この順にそれらの技術を述べていこう。
【００３４】
まず図式的項目間関連二次元表現手段１にかかわる技術であるが、図式を生成・編集・蓄積する手段のみでなく、図式に表現されない本文情報を生成・編集する図式側本文生成・編集手段２と、本文を図式情報とともに蓄積する図式側蓄積手段３が必要となる。従来は図式側で入力した本文を文書側で表現できず、また文書側で編集された本文情報を図式側に送ることができなかったため、このような図式側本文生成・編集手段２と、本文をも対象とした図式側蓄積手段３が付加されることはなかった。
【００３５】
図式側本文生成・編集手段２は、図式側蓄積手段３内の本文に対して、ワード・プロセサ的な生成・編集を行う手段である。また、図式側蓄積手段３は、ソフトウェアの場合は配列や配列リスト（ArrayListなどの名称で、上限の制限のない配列である）や、機能上は配列リストにさらに表示機能を備えたリストビュー等として情報処理装置内の記憶装置に構築される。
【００３６】
注意すべきは、この図式側本文生成・編集手段２は、基本的にワード・プロセサ手段７と同じデータ形式で書式情報を生成・編集できるものでなければならないことである。たとえばワード・プロセサ手段７にＲＴＦ形式を用いた場合には、図式側本文生成・編集手段２は、図式側蓄積手段３へ蓄積するデータ形式としてＲＴＦ形式を用いる。そうでなければ、ワード・プロセサ手段７で付加した書式情報を、図式側本文生成・編集手段２側で失ってしまうからである。なお、生成・編集機能としては、ワード・プロセサ手段７よりも制限されていてもかまわず、たとえば文字色の変更機能を提供しない等の簡略化も可能である。
【００３７】
図式的項目間関連二次元表現手段１において、いずれかの項目（カードなどの表現形態となっている）を選択したとする。たとえばカードをクリックして、ツールバーにおける「本文編集」ボタンを押す等の操作である。あるいはカードを右クリックして、コンテキストメニュー等と呼ばれるメニューをカードのそばに表示し、「本文編集」というメニューを選べばよい。常識的な実現形態を取れる。
【００３８】
このとき、図式側本文生成・編集手段２を表示する。もしワード・プロセサ手段７側でＲＴＦ形式を用いているなら、この図式側本文生成・編集手段２もワード・プロセサ手段７と同じＲＴＦ形式を扱えなければならない。要するに、この図式側本文生成・編集手段２は、ミニワード・プロセサ手段であって、単一項目の本文だけを表示し、それをワード・プロセサ手段７の蓄積形式と同一形式で生成・編集できる手段として実現すればよいのである。ソフトウェアで実現する場合には、riched32.dll等を呼び出すのが典型的な実現形態である。このようにすることによって、各項目についての個別の本文がばらばらに蓄積された状態で、図式側蓄積手段３の本文蓄積部で保持されることになる。しかも項目個別の本文の生成・編集が図式側で可能である。
【００３９】
さて、そのようなばらばらのデータをワード・プロセサ手段７に引き渡し、ワード・プロセサ手段７側で文書の形式で表現することを可能とする橋渡しの手段が必要である。付加タグを生成して付加する手段である。それが図式−ワード・プロセサ手段４である。
【００４０】
図式−ワード・プロセサ手段４で行うことは、カードの順序に従って、かつカードの階層レベルを判別しつつ、図式側蓄積手段３にある各項目と各本文を、順にワード・プロセサ手段７に書き込んでいくことである。このときに注意すべきことは、章・節・項などは、章を「第１章」から順に、節を「第１．１節」から順になど、一般に番号付けを行わなければならないことである。また、付加タグをユーザ書き換え禁止状態にして引き渡すことができる。図式−ワード・プロセサ手段４の動作のステップを図５にフローチャートで示す。
【００４１】
まず項目を数えるためにｉ＝０とするとともに、章・節・項等の番号を初期化する(S41)。ｉを１増やし（S42）、図式側蓄積手段３のｉ番目の項目を１つ取る（S43）。i番目の項目のレベルを調べて、それに従って、章・節・項等の判定を行って、その番号を計算して生成する（S44）。そのような章・節・項等のタイトルに、その項目の本文を組み合わせる（S45）。必要な付加タグを生成して、それらのデータに付加するが、付加タグを書き換え禁止の状態に設定することができる（S46）。それをワード・プロセサ手段７に送る（S47）。全項目を処理したかを判定し、まだならばｉを１増やす部分に戻り、一方、全項目の処理が終了していれば終わる（S48）。
【００４２】
次にこれらの項目と本文を受け取ったワード・プロセサ手段７は、通常のワード・プロセサ機能を備えていればよい。riched32.dllを呼び出す等で実現できるので、ワード・プロセサ手段７を実現できる当業者にとって技術的困難はない。付加タグは書き換え禁止状態にしておけば、ワード・プロセサ手段７でユーザによって書き換えられることはないので、その場合にワード・プロセサ手段７での編集中も常に付加タグは崩れない。
【００４３】
さて、このようなワード・プロセサ手段７でいくつかの項目や本文を書き換えたとしよう。その結果を、図式的項目間関連二次元表現手段１に反映するという機能を付与しなければならない場合がある。そのための手段がワード・プロセサ−図式手段５である。
【００４４】
たとえばワード・プロセサ手段７においてＲＴＦ形式を用いていた場合、ＲＴＦ形式のデータ中から付加タグをすべて検出する。付加タグの検出は、タグ以外には用いない禁止文字や禁止文字列をあらかじめ定めておき、それらを項目や本文中で用いることを禁止すれば容易である。項目や本文に禁止文字や禁止文字列が含まれていないので、そのような文字や文字列を発見しさえすれば、付加タグであることが検出される。たとえば、図４のワード・プロセサ手段中に頻出する三角形状の文字を通常の文章中で使うことはほとんどありえないだろうから、このような使用頻度のきわめて低い文字を付加タグの検出に利用することが可能である。
【００４５】
また、別法としては、項目や本文では書き換え禁止の指定をさせないようにすればよい。書き換え禁止は、通常は本文などに設定することはないので、この方法を使用することが可能である。書き換え禁止状態なら付加タグ、そうでなければ項目や本文であると判断する。これをワード・プロセサ手段７中の文書に対して先頭から順に行っていけば、項目と本文を交互に順に拾い出すことが可能になる。なお、本文が存在しない項目の場合には、本文を空文と判定するため、スペース１個あるいは改行１個のみを入れるなどすればよい。ワード・プロセサ−図式手段５のフローチャートを図６に示す。
【００４６】
まず項目を数えるためにｉ＝０とするとともに、文書のポインタを文書の先頭に設定する（S51）。iを１増やす（S52）。ポインタを進めて、最初の付加タグを見つける（S53）。そこにｉ番目の項目とその本文があるはずなので、それを抽出する（S54）。図式側蓄積手段３の所定位置に項目と本文を入れる（S55）。全項目を処理したかを判定し、まだならばｉを１増やす部分に戻り、一方、全項目の処理が終了していれば終わる（S56）。
【００４７】
これら４手段を用いることにより、図式的項目間関連二次元表現とその文書表現に関して、文書本文を含めて連携を取ることができる。もしこのようなことを可能にせず、項目のみをワード・プロセサ手段７に引き渡したり、逆方向であるワード・プロセサ手段７から図式的項目間関連二次元表現手段１へのデータ引き渡しができないならば、図式を変形するたびに、文書の作り直しは非常に面倒になることが容易に想像できるところである。
【００４８】
ここで、その他の工夫についても述べるならば、その一つは、付加タグがすべて可視の場合に起こる問題への対処である。文書を印刷する際や、他のワード・プロセサで読み取り可能なファイルを作って保存するときに、付加タグのうち不要な部分を削除しなければならないのである。そうでなければ、付加タグが可視のまま印刷やファイル作成が行われてしまう。
【００４９】
この問題に対処するためには、もう一つ別のワード・プロセサ手段を装置内に用意して、それをユーザに見せないことによって実現するのが一法である。それが隠しワード・プロセサ手段９であり、ワード・プロセサ手段７から隠しワード・プロセサ手段９に文書データを引き渡すワード・プロセサ−隠しワード・プロセサ手段８を備えればよい。そして、この隠しワード・プロセサ手段９に構成された文書を、印刷やファイル生成に用いるのである。図式とワード・プロセサの間の変換が可能なように、ワード・プロセサから隠しワード・プロセサへの文書の変換を行う。その際に付加タグの不要部のみを削除する。ワード・プロセサ−隠しワード・プロセサ手段８での処理は、１次元的に順に付加タグの不要部を削除することであり、容易である。隠しワード・プロセサ手段９側に生成された文書を、印刷やファイル保存に用いるならば、不要な可視の付加タグ情報を一切含まない文書を扱えるわけである。
【００５０】
またその他の工夫として、図式的項目間関連二次元表現において、項目の順序を変更可能とする工夫がある。ワード・プロセサ手段７における項目順序の変更は、通常のコピー・アンド・ペーストで行える。そのときに章・節・項等の番号の調整も実現可能である。しかしながら、図式的項目間関連二次元表現においては、通常は文書のように章・節・項等の番号は項目に付されていず、そもそも順序という概念があいまいであるという問題点がある。たとえば項目が生成された順にしかワード・プロセサ手段７で文書にできないのでは困るので、文書として生成するための項目順序が必要なわけである。それが項目順序変更手段６である。
【００５１】
そのような順序変更には、図式側蓄積手段３はいわゆるリストビュー等のソフトウェア部品を利用して情報処理装置の記憶装置上に実現するのが一法である。リストビューは表示項目の基本的な順序変更機能を標準的に有しているため、この種のソフトウェア部品を用いれば、項目順序変更手段６を実現しやすくなる。もちろんリストビューを用いずにすべて自力開発してもよいわけである。
【００５２】
このようなリストビュー等は、図式側蓄積手段３における項目を、ワード・プロセサ手段７における文書の順序どおりに表示する。その中で特定の１個あるいは複数個の項目を選択すると、通常の情報処理装置では、選択項目は反転表示される。それを上方移動ボタンあるいは下方移動ボタンのクリックや、あるいはドラッグ・アンド・ドロップ機能等で、図式側蓄積手段３における希望の位置にユーザが移動する。図式−ワード・プロセサ手段４を起動した際に、その順序どおりにワード・プロセサ手段７に文書を生成して引き渡せばよい。
【００５３】
さて、各手段における処理の手順のうち、まだフローチャートで示していなかったもののフローチャートを示しておこう。いくつかの手段は既製のものを使えるので、特に記載することはない。本発明で必要となる手順のみをフローチャートで示すものとする。実装していない手段がある場合に、該手段に関する手順を素通りする等の対応は、容易にフローチャートを変形できる。また、現在のプログラミングはオブジェクト指向プログラミングが一般化していて、マルチスレッド環境下でイベント駆動的に作動するので、イベントを捕捉することによって機能することを基本としている。
【００５４】
図式的項目間関連二次元表現手段１においては、通常有する機能に、各項目の本文付加のために図式側本文生成・編集手段２を呼び出すステップを付け加えるのみである。図７に示すように、ユーザが項目を選び、たとえば「本文付加」のボタンをクリックする等で本文付加に入ったかを判定して（S11）、選択された項目番号を図式側本文生成・編集手段２を起動して引き渡し（S12）、本文の付加・編集が終わるのを待つだけでよい（S13）。このようなステップがマルチスレッド環境下のイベント駆動で作動していると考えればよい。
【００５５】
図式側本文生成・編集手段２は、図式的項目間関連二次元表現手段１側から起動され、項目番号が引き渡される。図式側蓄積手段３の該当番号における本文記憶場所に本文を生成したり編集する。ワード・プロセサと同等の機能をもつだけである。処理はワード・プロセサ手段と同等であるためフローチャートに表現するほどでない。
【００５６】
図式側蓄積手段３はいわゆるリストビュー等で実現してよい。記憶装置である。いわゆるリストビュー等には通常、項目順序の入れ替えやソートの基本機能があるのでそれを利用できる。ワード・プロセサ手段７における表示順序に項目を並べる機能は、文書骨格表現が可能な従来の図式的項目間関連二次元表現手段１が有しているものであり、それを利用できる。ただし、項目順序の入れ替えステップには、章・節・項等の項目の階層レベルを無視してはならないため、図８のようなフローチャートに従わなければならない。ここでは項目は１つのみ選択して移動すると仮定したフローチャートであり、かつその項目の下位階層にある項目群（たとえば章レベルの項目を選択したとき、その下位にある節・項等の項目すべて）を一括してその順序のまま、移動する方式である。移動先は、たとえば章のレベルの移動の場合には、次に存在する章のレベルの位置に移動するのであって、節や項等の位置を飛ばさなければならない。まず選択項目の下位にある項目をすべて見つけて選択し（S31）、適切な移動先が存在するかを調べ（S32）、選択項目をすべて移動先に移動して矛盾のないレベルを付ける（S33）。これ以外の規準に従う選択と移動方式もあるだろうが、図８と同様に当業者が技術的に実現しうるものであり、図８を処理ステップの代表例として示した。
【００５７】
ワード・プロセサ手段７と隠しワード・プロセサ手段９は、riched32.dll等の標準のものを使用することを本発明では仮定しているため、その機能を一切変更しない。したがってここでフローチャートに表現する必要はない。
【００５８】
ワード・プロセサ−隠しワード・プロセサ手段８においては、付加タグの不要部を削除するとともに、付加タグの書き換え禁止状態を解除する。自動生成された章・節・項等の番号等は削除しない。それを項目ごとに行っていく。図９のようなフローチャートに従わなければならない。まず項目を数えるためにｉ＝０とするとともに、文書のポインタを文書の先頭に設定する（S81）。iを１増やす（S82）。ポインタを進めて、最初の付加タグを見つける（S83）。そこにｉ番目の項目とその本文があるはずなので、付加タグの不要部を削除し、残りの部分の書き換え禁止状態を解除したデータを作成する（S84）。隠しワード・プロセサ手段９の所定位置にその項目と本文を入れる（S85）。全項目を処理したかを判定し、まだならばｉを１増やす部分に戻り、一方、全項目の処理が終了していれば終わる（S86）。
【発明の効果】
【００５９】
本発明は以上に説明したようなものであるから、以下に記載するような効果を発揮する。ＫＪ法やマインドマップ等の着想支援等の用途に用いられる図式的項目間関連二次元表現手段１と、ワード・プロセサ手段７を備えて、両者の連携を情報処理装置が行うことによって、図式作成や文書作成を効率化でき、あるいは両者の相互変換を行うことができる。
【００６０】
ＫＪ法やマインドマップ等の各種着想支援法を情報処理装置で実施する際に、最終的にレポート等の文書を作成することが多い。その際、文書には本文が必要であるが、各種着想支援法では、文書の章・節・項等のタイトルに相当する項目だけを扱って、本文を扱えないのが通常であった。しかしながら、各項目ごとに、図式側本文生成・編集手段２によって本文を入力・編集し、かつ図式側蓄積手段３に本文をも蓄積し、かつ図式−ワード・プロセサ手段４あるいは逆にワード・プロセサ−図式手段５を介することによって、図式的項目間関連二次元表現から文書を自動的に作成し、逆に文書での編集結果を図式的項目間関連二次元表現に自動的に反映することが可能になるため、発明としての効果が大きい。
【００６１】
従来のワード・プロセサには、いわゆるアイデア・プロセサあるいはアウトライン・プロセサと呼ぶ機能として、目次あるいはそれに類似した表現である文書の骨格構造のみを項目の並びで表示するという機能を提供することがあった。そのような表現は、ワード・プロセサ手段７における文書表現の並びを常にそのまま同じ順序で、一次元的に表示しているにすぎない。それに対して、図式的項目間関連二次元表現は、カードとループ、ツリー、マトリックスなどの表現法を通じて、二次元の広がりをもった図式を提供する。カードやループなどをいわゆるドラッグ機能で移動できる図式的項目間関連二次元表現ならば、一次元的な表現のみではつかみきれない関連性を図式の上で発見したり、全体の見通しをよくすること等が可能となり、着想支援や文書作成効率向上や文書品質向上等に寄与すると考えられる。
【００６２】
しかも、図式表現の場合には、さまざまな色を用いたり、項目の文字の大きさを変えたり、さまざまな記号や絵などを項目に貼り付けた二次元的に多彩な表現を可能とできる。実際、マインドマップはそのような表現を奨励しているし、ＫＪ法でも階層表現だけでない関連性を線や矢印などによって付加することができる。このような表現法は、一次元の文章に対して、二次元の俯瞰図というべき見通しのよい文章の把握法や体系化法を提供することになり、利点は非常に大きい。これらが着想支援法と呼ばれることが多いように、新たな着想や発明を生み出す補助として用いることができる。それとともに、収集した情報を整理するためや、情報を記憶するためや、文書の要旨を把握するために用いることができる。あるいは客先での説明の補助として用いれば、説明がわかりやすくなる。そのときに、図式的項目間関連二次元表現と通常の文書表現との間で完全に矛盾をなくし、しかも同時的に両者を生成できるので、情報処理装置としての利点が大きい。
【００６３】
このような情報処理装置は、通常のユーザにとっての利点を有するだけでなく、文章を書く訓練ができていない子供などの場合にも利点が大きいと考えられる。すなわち図式側で文章の骨格をビジュアルに描いてから、ワード・プロセサ手段７において文章を作成するという過程をたどれば、文章作成力を容易に身につけやすくなる。ワード・プロセサとして従来にない高い効果を発揮するわけであり、教育機関や実務機関等で用いるならば、文章作成力に関する高い教育効果や、文書作成効率の向上等を図ることが可能である。
【発明を実施するための最良の形態】
【００６４】
本発明は、コンピュータ上に情報処理装置として実現するのが最良である。あるいは携帯電話機等の携帯情報機器や、デジタル家電製品等の形態をとることもある。図３の手段のすべてを用いるか、あるいは利用しない一部をそれから除いた構成とする。情報処理プログラム、あるいはそれを配布するための記録媒体としても実現される。
【実施例１】
【００６５】
ＫＪ法あるいはそれと類する図式のための図式的項目間関連二次元表現手段１を採用した情報処理装置は、本発明の典型的な実施例であり、図４に相当するものである。その構成は上記にすでに述べたものである。このような図式的項目間関連二次元表現情報処理装置において、図式を作成するとともに、カードなどで表現された各項目に、本文を入力する図式側本文生成・編集手段２から、各項目の本文を付加する。ワード・プロセサ手段７を呼び出す際に、付加タグを付けたデータで引き渡し、文書の表示・編集が可能となる。しかも、付加タグを手がかりとして、編集した文書の内容を、図式側にも反映する情報処理装置として構成することもできる。
【００６６】
このような情報処理装置は、図式と文書の作成が緊密に連携し、図式と文書作成におけるユーザの二度手間を極力排除できることになる。その結果、非常に高い便宜をユーザに提供することが可能である。
【実施例２】
【００６７】
実施例１において、図式をマインドマップにした図式的項目間関連二次元表現情報処理装置は、類似の一実施例となる。実施例１と同様に、実用的で高い便宜を提供できる装置となる。その他の図式的項目間関連二次元表現法に対しても同様にして適用することは、実施例１および２を知れば容易に行える。
【産業上の利用可能性】
【００６８】
既述からわかるように、本発明はコンピュータ技術、携帯情報機器技術、デジタル家電技術等との相性が非常によく、当業者が実施しやすい。応用分野として、実施例１および２におけるＫＪ法やマインドマップ等さまざまな図式的着想支援表現の情報処理装置化において、文書作成と一体化して効率化させる技術として利用可能であり、かつ実施しやすいものである。ワード・プロセサとして見たときにも、二次元俯瞰図的に文書構造と文書内容を理解することが容易になり、従来にない利点を有する情報処理装置として、文書作成、文書内容把握等の目的のために利用するのに適している。よって産業上の利用可能性が大きい発明である。
【図面の簡単な説明】
【００６９】
【図１】着想支援法の分類に関する紙カード式のＫＪ法等の京都大学式の図式的項目間関連二次元表現を本発明の情報処理装置で表現した例である。
【図２】図１と同項目のマインドマップの例である。
【図３】本発明の情報処理装置の構成である。
【図４】本発明の情報処理装置において各手段の用途を図解した図である。
【図５】本発明の図式−ワード・プロセサ手段４における処理のフローチャートである。
【図６】本発明のワード・プロセサ−図式手段５における処理のフローチャートである。
【図７】本発明の図式的項目間関連二次元表現手段１に付け加える処理のフローチャートである。
【図８】本発明の図式側蓄積手段３における処理のフローチャートである。
【図９】本発明のワード・プロセサ−隠しワード・プロセサ手段８における処理のフローチャートである。
【符号の説明】
【００７０】
１  図式的項目間関連二次元表現手段
２  図式側本文生成・編集手段
３  図式側蓄積手段
４  図式−ワード・プロセサ手段
５  ワード・プロセサ−図式手段
６  項目順序変更手段
７  ワード・プロセサ手段
８  ワード・プロセサ−隠しワード・プロセサ手段
９  隠しワード・プロセサ手段
【図３】
2008282227.tif 000003
【図４】
2008282227.tif 000004
【図５】
2008282227.tif 000005
【図６】
2008282227.tif 000006
【図７】
2008282227.tif 000007
【図８】
2008282227.tif 000008
【図９】
2008282227.tif 000009
【図１】
2008282227.tif 000010
【図２】
2008282227.tif 000011