そもそも何が問題なのか？

問題の特許とは？

ＬＺＷ法とは？

目的

特許を回避するためには？

辞書テーブルを使用しないＬＺＷ復号化

実際にＧＩＦの展開を行う

本当に大丈夫なのか？

ＧＩＦエンコード

最後に

お願い

免責事項

　一体何があったのだろうか？
　実はこれにはライセンス供与元の米ユニシス・コーポレーション社（以下ユニシス）の対応が深く関わっている。そもそもユニシスはＧＩＦフォーマットに採用されているＬＺＷという圧縮法に関わる特許を取得している。この特許は本国ではもちろんのこと、我が日本においても１９８４年に出願され、１９９７年に登録されている。そして特許成立を期に、この圧縮法を利用しているソフトウェアに対してライセンス料を徴収するという手段に出た。これが世に言う第一期ＧＩＦ騒動である。

　ちなみに、このときの騒動をご存じ無い方もかなりの割合でいらっしゃるのでは無いかと思う。それもそのはず、当時のユニシス側の対応としては、商用のソフトウェアにのみライセンス料を要求し、フリーソフトにはそれを課さないと言う方針だったからである。従って企業側には頭の痛い問題に違いはなかっただろうが、個人でフリーソフトを出している人間にとっては、あくまで対岸の火事でしか無かったわけである。故に、広く一般に騒がれることもなく、ライセンス問題はいったん収束するかにも見えた。
　しかし時が経つこと３年余、火の手は遂に対岸へと燃え広がった。第二期ＧＩＦ騒動の始まりである。インターネットの普及と共に拡大の一途を遂げるＧＩＦフォーマットの利用に対し、これ幸いとばかりにユニシスはライセンス料の徴収を徹底して行う方針転換を断行する。それまでは徴収を免れていたＧＩＦフォーマットを扱うフリーソフトに対しても、$5000という法外なライセンス料の支払いを要求してきた。それだけでは無い。直接はＧＩＦを扱うことのないＩＥコンポーネント等を利用したフリーソフトに対してもライセンス料徴収の対象としたのである。もちろん、マイクロソフト社の方でもユニシスにライセンス料を払っており、完全なる二重払いと言うことになる訳だが、このような二次利用に対しての明確な基準が無いために混乱の度合いはさらに深まるばかりである。
　こうした状況に対し、著名な各フリーソフト作者達はこぞってＧＩＦフォーマットのサポートを凍結し、辛うじて難を逃れている。善意により無償で提供しているフリーソフトを公開するために$5000も払わなくてはならない事を鑑みれば、至極当然の選択と言えよう。

　しかし、今後のフリーソフト界の発展及び活性化を願う身としては、現在の状況が決して良いものだとは思えない。特許の利用に対してライセンス料を支払う事は当然の義務ではあるのだが、そのやり方や対象の選択に対してユニシスに強い不信感を抱いているのは、何も私だけではあるまい。ただし、だからと言ってＧＩＦフォーマットを利用しないことによって、この問題を解決しようという態度がベストだとも思えない。はっきり言わせてもらうが、それは非常に後ろ向きなやり方である。クリエイターたる者、常に新たな可能性を模索し続けなければなるまい。無いなら作る、壊れたら直す、使えないのなら何とかする・・・のが我々開発系の人間の責務では無かろうか？従って、今回もユニシスの要求に対し素直に従う事も無ければ、ＧＩＦの利用を止めるような事もしない。あくまで法に則った上で、ＧＩＦを利用する道を模索する。道は一本では無いのだ。

　お世辞にも将来性の期待される画像フォーマットとは言い難いＧＩＦではあるが、まだまだ現役であり今後も様々な場面で利用されることは多いはずである。それがフリーソフトにおいて使用できないと言うのでは、ＰＣ業界全体で見ても大きなマイナスになるとしか考えられない。そもそもＧＩＦというフォーマットは米CompuServeにおいて、ライセンスフリーを謳い文句に策定されたフォーマットである。ライセンスフリー故に大きく広まり、発展を遂げてきた。それを後から湧いて出てきた特許によって根こそぎ強奪するようなやり方がまかり通ってしまうのは、サブマリン特許が認められてしまうアメリカならではの事情ってヤツなんだろうとつくづく感じる。権利期間も先進国の中では唯一、出願日からではなく、公開日からとなっている問題点もあり、今後しばらくは悩まされることになるだろう。少なくともＧＩＦが衰退する方が先なのは間違いなさそうだ。

　前述したようにＧＩＦフォーマット自体はライセンスフリーであり、その規則に従う限り自由に使用することができる。問題なのはその圧縮法であるＬＺＷだ。
　このＬＺＷという圧縮法は何もＧＩＦにのみ採用されているわけではない。有名なところではＰＤＦやPostScriptにも使用されているし、ＴＯＷＮＳユーザーにはおなじみのＴＩＦＦの圧縮形式の一つとしても採用されている。（時期的に考えて富士通がＴ－ＯＳの標準ＴＩＦＦライブラリに対してライセンス料を支払っているとは考えにくい。従ってＴ－ＯＳ上で動作するＴＩＦＦを扱うソフトは全て限りなく黒に近いため注意されたい。）
　つまり、この特許によって影響を受けるソフトウェアはかなりの数に上ると考えて間違いは無いだろう。

　ユニシスはＬＺＷ法に関して２つの特許と幾つかの公開特許を有している。その内容も圧縮に関わる物や復元に関する物など多岐に渡り、正にＬＺＷ包囲網と言わんばかりの様相を呈している。中でも基本となる特許である「データ伸長法および装置ならびにデータ圧縮伸長法および装置」（特許番号：第２６１００８４号）はＬＺＷ法を利用する上での大きな障壁となっている。興味のある方は、実際に読んでみるのも良いだろう。

　さてこの特許だが、ほとんどそのままＬＺＷの圧縮・復元理論を特許にしてしまったような構成になっており、なるほど普通にＧＩＦ展開などをコーディングすれば見事に抵触してしまうように出来ている。敵ながら天晴れと言う他はあるまい。
　そして、それぞれの特許はソフトウェアで実装した場合（いわゆる手法）とハードウェアで構成した場合（いわゆる装置）の２通りづつ記されており、実施例も豊富に紹介されている。

　この様に、特許として認められているのは圧縮と復元に関する部分であるため、生成されたＧＩＦ画像やＴＩＦＦ画像そのものには何ら問題は発生しない。問題はそれをどうやって作成し、どうやって閲覧するか、その点のみにある。

　ここで辞書テーブルを利用した圧縮について少し説明しよう。
　たとえば「０１１０１００１１０１」という２進数１１ビットのデータ列があったとする。これを辞書テーブルを使って圧縮してみよう。
　ぱっと見てお分かりかと思うが、同じ様なデータが２つあることに気が付かれるだろう。そう、「０１１０１」というデータ列が２回現れている。したがってここではテーブルの内容を、

　テーブルNo.0＝「０」
　テーブルNo.1＝「０１１０１」

としてやることにより、圧縮後のデータは「１０１」という３ビットに収まってしまう。これがテーブル型圧縮の基本である。
　特徴としては繰り返し現れるパターンに強いという点があり、特に１６色でタイルパターンを多用して書かれた画像などには効果があるだろう。

図１．辞書テーブルを用いた圧縮

しかしながら、辞書テーブルを利用している圧縮法というのは他にも基本となるＬＺ法や、ＺＩＰ・ＰＮＧ等にも採用されているＬＺ７７法などがあり、テーブルを利用しているというだけでは問題の特許に触れることは無い。

　では、ユニシスの特許（あるいはＬＺＷ法）には一体どんな特許性があるのだろうか？

　それはひとえに辞書テーブルの扱いにある。一つは辞書テーブルが時々刻々と動的に変化する点、もう一つは辞書テーブルに追加するデータ列の選択手法にＬＺＷ法ならではの特徴が見られる。これによって、パターンが途中で変化する場合でも柔軟に対応することができ、高圧縮率と高速性を見事なバランスで両立させている。

　詳しい説明はここでは省略させていただくが、興味があればＧＩＦの仕様書やその手の参考文献などがあるので、そちらを参照されたい。

　対するＧＩＦデコーダの方はと言えば、これまでに蓄積された大量のＧＩＦ画像が存在する上、中には（私の様に）ＧＩＦを使い続ける人もいるだろう。要するに、デコーダの方は使わないと言う訳にはいかないのである。

　そこで、今回はユニシスの特許に触れないＬＺＷ復号化手法を考案すること、及びライセンスフリーのＧＩＦデコーダを開発する（のをお手伝いする(^^;）事を目的としたいと思う。

　つまりは、この第１，第８，第１５および第１８項を満たさない方法でＧＩＦの展開を行えば、全く問題ないという事が言える。そして、それぞれの請求項を見てみると第１５項および第１８項の方は「データ圧縮伸長」に関する発明であり、今回の検討に直接影響を及ぼす事はない。また、第８項に関しては「データ伸長装置」についての発明であり、これもまた該当しない。従って、今回問題になるなのは「データ伸長方法」を記した第１項のみという事になる。

　さて、問題の第１クレームにはどんな事が書いてあるのだろうか。残念ながらここに全てを記すわけにはいかないが、概要だけ簡単に説明する事にしよう。

　要するに

という段階を含む復元方法である、と書かれている。これから一つでも外れていれば特許には引っかからないわけだが、だからと言って「扱うのはデータ文字列ではなく画像データだからノープロブレム！」という訳にも行かないだろう。当然、パテントに一休さん的”とんち”は通用しないし、実際問題として実施例の中でそういった応用例も明記されている。
　とは言え、さすがに出力データそのものを変えてしまってはＧＩＦの展開が不可能になってしまうので、それもできない。となると方法を大幅に変えつつ出力データはそのままの状態を維持しなければならない。

　そこでふと気になったのは辞書テーブルである。このクレームの中では何度も「前記メモリ」という単語が出てくる。たとえば『対応する符号信号を用いて、前記メモリから検索可能な形態で、前記メモリにストアすること～』というくだりがあるが、ここで言っている前記メモリとは、正確には「前記符号信号に対応するデータ文字ストリングをストアするメモリ」の事を指している。何のことは無い。要するに、上で説明した辞書テーブルそのものである。ＬＺＷ法も辞書テーブルを利用する圧縮法の一つであるため、クレーム中に辞書テーブルの用法が出てくるのも当然と言えば当然なのであるが、ここで一つの疑問は浮かんでこないだろうか？

そう、本当に辞書テーブルは必要なのだろうか？

ＬＺＷ法はもともと辞書テーブルを利用することを前提に作られた圧縮法であり、また特許もそれに準じて書かれている。ならば辞書テーブルを利用しないでＬＺＷ法と同じ事を実現してしまえば、それはもうＬＺＷ法ではなく、特許にも触れることはない。

　実際、これから述べる方法を用いれば、上の段階の内３，５，６については該当しなくなる。依然として１，２，４には該当しているわけだが、残ったこれらの段階に一体何の特許性があるというのだろうか？

　まず、普通にテーブルを利用した場合では圧縮後の符号化データがそのままテーブルの番号を指し示しており、指定されたテーブルの内容をそのまま出力結果とする事ができる。これに対してテーブルを利用しない場合では、符号化データを受け取った後に、それが一体どんなデータ列を指し示しているのかを逐次求めなければならない。
　また、ＬＺＷでは結果（一つのデータ列）を出力するたびに、テーブルに新しいデータ列を追加する事を行っているが、テーブルを使用しない場合は当然この作業も行わない。

　ここまで聞いて不思議に思う人も多いだろう。テーブルが無いのに、本来テーブルに格納されているべきデータ列を取得出来るとは思えないかも知れない。
　しかし、可能である。そしてそれを理解するには、まずＬＺＷのテーブルの動きを理解しなくてはならない。
　まず最初に、ＬＺＷ法では０～（色数－１）のテーブルを初期化する。初期化の内容はテーブルの番号と同じデータを入れる事、つまり０番のテーブルには０が、５０番のテーブルには５０が入る。そして、テーブルの内容は常に増える一方であり、一度決定されたテーブルの内容は（初期化されない限り）変わることはない。
　従って、圧縮後の符号化データが０～（色数－１）である限り、出力データもそれに対応した０～（色数－１）の値を取る。つまり、符号化データがこの範囲にある場合はテーブルなど利用する必要はない。（逆に言えば、全く圧縮されていない状態である）

図２．辞書テーブルの初期化

　問題なのは符号化コードが（色数－１）より大きくなった場合。この場合は必ず２個以上のデータが格納されている。ＬＺＷ法では展開時に符号化コードに対応するデータ列を出力すると、必ず何らかのデータ列をテーブルに書き加える事になっている。このとき書き込まれるデータは「前回の出力結果」に「今回の出力結果」の先頭１個を付け足した物である。

図３．辞書テーブルへの追加登録

　したがって、前回の出力結果が無い一番最初（０番目）の出力時以外は、必ずデータ出力後にテーブルへ上記のデータ列が加えられる。つまり、５番目のデータを出力した後には、テーブルには５個のデータが新しく加わっている事になる。

　では、これをテーブルを使わないで求めようとするとどうなるか？まず、色数が８色の場合で考えてみる。突然１４という符号化データが現れた。テーブルへの書き込みはいっさい行っていない（と言うよりテーブルそのものが存在しない）ので、１４が一体何を指すのか分からない。しかし、ここで一つの手がかりはある。それは、求めるべきデータ列は本来「７番目のデータを出力する際にテーブルに登録されるはずだった物」である、という事である。何故かというと、テーブルは初期化時に（色数－１）である７まで埋められており、それ以後は最初の一回を除いて毎回一個づつ増えていくからである。

図４．辞書テーブル追加登録のタイミング

　ここまで分かってしまえば、しめたもの。上の説明で行くと、ここでテーブルに書き込まれるはずであったデータは

”（６番目の出力データ列）＋（７番目の出力データ列の先頭１個のデータ）”

である事も自ずと分かってしまう。

　さあ、後一息。今度はその（６番目の出力データ列）と（７番目の出力データ列の先頭１個のデータ）を求めてみよう。もう既に６番目と７番目の出力を行っている訳で、そのデータを保存しておけば良いのだが、テーブルを使わないと決めた以上それは出来ない相談である。従って二度手間になるのを承知で、再び６番目と７番目の出力データを求める。
　ここで６番目の符号化データは４だった。つまり６番目の出力データ列は「４」であることが分かった。しかし７番目の符号化データは１０であった。１０が一体何なのかは、またしても分からない。が、それが「（２番目の出力データ列）＋（３番目の出力データ列の先頭１個のデータ）」であることは明らかである。そして２番目の符号化データを見ると、またしても８だった・・・・。と言うように、どんどんと遡っていくと、いずれは符号化データが７以下に収まる時がやってくる。ちなみに、この８に対する出力データが「２・５」で収束したとすると、最初の符号化コード「１４」に対する出力データは「４・２」という事になる。（どうしてそうなるのかは、各自考えてもらいたい）

　この様に、符号化コードが（色数－１）より大きい場合は、

”｛（符号化コード－色数）の出力データ列｝＋｛（符号化コード－色数＋１）の出力データ列の先頭１個｝”

が求めるべき出力結果になる。ここで（符号化コード－色数）番目や（符号化コード－色数＋１）番目の符号化コードも（色数－１）より大きかった場合は、さらにそれを求めるために同じ事を繰り返す必要がある。そして、いずれ符号化コードが（色数－１）以下になるとデータが確定し、一番上層の符号化コードまで確定した段階で完全な出力データが得られる。

　少しでもプログラムを囓ったことのある方なら説明するまでもないだろうが、上のような処理は再帰関数を用いれば非常に簡潔に記述する事ができる。ただし、ネストする数によっては非常に重い処理になってしまう事も想像に難くない。しかし、テーブルを使わずしてＬＺＷ復号化を実現する以上、ある程度のリスクは覚悟しなければならないのは当然である。もし、これが本家のＬＺＷより高速であるのならば、私が特許を書いている所だ。ただ利点が全く無いというわけでもなく、テーブルへの書き込みが発生しないことから、メモリアクセス（主にライト動作）の低減やテーブルに使用されるべき僅かなメモリを節約できるというメリットも存在する。特に圧縮率の非常に悪い画像などを展開させた場合は、本家を上回る速度が出るのではないかと考えられる。

　さて、これで完璧・・・と言いたいところではあるのだが、やらなければならない仕事はもう一つ残っている。今までの例では符号化コードに対するテーブルの内容は既に決定されている事を暗黙の了解として話を進めてきた。実際、殆どの場合はその通りなのだが、極希に未だ未登録のテーブル番号を指定してくる符号化コードの存在があることも事実である。この様な場合はどうするのかと言うと、一つ前の符号化コードから得られた出力データとその出力データの先頭１個を連結した物を今回の出力データとし、それをそのままテーブルにも登録する。何故そのような処理を行うのかについては、話が長くなるので割愛させて戴くが、この様な場合についてもテーブルを使用しない場合の処理を考えなくてはならない。
　ここで「一つ前の出力データ」を利用することから、前回の出力結果を保存しておいてそれをそのまま使えば良いのでは？と考えた方も多いかと思う。確かに、それは可能であるし、普通であればそうするだろう。しかし、今回考案しているのは「普通でない」ＬＺＷ復元法なだけに、できるだけ本道から逸れた仕様にしておくのが理想である。
　したがって、ここでも先ほど同様に「一つ前の出力データ」を改めて求めることにする。求めるべきデータ列は

”｛（一つ前の符号化コード）の出力データ列｝＋｛（一つ前の符号化コード）の出力データ列の先頭１個｝”

である。これも再帰を伴う処理になるのだが、内容的には先ほどと変わらないため説明は省略させていただく。

　以上の処理を各符号化コードに対して順番に実行していくと、完全な復元データを得ることが出来る。参考までに、処理の流れをＣ言語風に記してみた。このサンプルでは、画像の色数が８色、圧縮後の符号化コードサイズを１バイト固定、とした場合の例である。配列lzw[]に圧縮データを格納しておくと、配列out[]に展開されたデータが返ってくるという寸法だ。分かり易さを重視したために（出力が８ビットアラインされている等）おかしな所も多々あるが、大体こんな感じで書いていけばＬＺＷの展開が行えるだろう。
　ちなみに、ＧＩＦのデコードを行うためには、あと幾つかの処理を追加しなくてはならなくなる上に、扱うデータも可変ビット長であるため実装は若干面倒な物になるが、ここまでの内容を理解できる方であれば大した問題でも無いだろう。後は各自でコーディングしてもらいたい。

char lzw[256] = {2,4,8,7,5,10,13,12,0,9};　//元の圧縮データ
char out[512];　　　　　　　　　　　　　　　　//復元されたデータ
int pos = 0;　　//現在のデータ書き込み位置
int color = 8;　//色数
int size = 10;　//圧縮データのサイズ

/* ＬＺＷ復元化関数 */
void lzw_decode()
{
　　int i;
　　for (i=0;i<size;i++) {
　　　　lzw_string(i);
　　}
}

/* 復元データ取得関数 */
void lzw_string(int x)
{
　　char code = lzw[x];
　　if (code < color) {
　　　　out[pos++] = code;
　　} else if (code > color+x-2) {
　　　　lzw_string(x-1);
　　　　lzw_char(x-1);
　　} else {
　　　　lzw_string(code-color);
　　　　lzw_char(code-color+1);
　　}
}

/* 復元データ取得関数（先頭１バイトのみ） */

void lzw_char(int x)
{
　　char code = lzw[x];
　　if (code < color) {
　　　　out[pos++] = code;
　　} else if (code > color+x-2) {
　　　　lzw_char(x-1);
　　} else {
　　　　lzw_char(code-color);
　　}
}

　なお余談ではあるが、なぜここでお得意のF-BASIC386による記述を行っていないのかと言うと、アルゴリズムの関係上、再帰をスマートに表現するにはＣ言語の方が適当であったという理由に他ならない。プラットフォームに依存しないと言う意味でも好都合であろう。ちなみにF-BASIC386でも書けなくは無いのだが、到底実用的な速度にはならないだろう。

　まず、ＧＩＦがＬＺＷに対して拡張を行っている点としては、クリアコードと終了コードの存在が挙げられる。それぞれ辞書テーブルの特定の番号に割り当てられており、その番号を指し示す符号化コードが現れた場合は、定められた処理を行う必要がある。
　具体的には「色数」のエントリにクリアコードが、「色数＋１」の位置に終了コードが設定されている。このクリアコードが現れた場合の処理であるが、テーブルの内容を初期化するとある。つまり本展開理論においてはクリアコードが現れた場合、その地点を０番目の符号化コードとして再設定する必要がある。また、これらの追加エントリがあるためにテーブルの番号が途中から２つほどずれてしまう点も考慮しなければならないだろう。

　さらに、ＧＩＦでは入力されてくる符号化コードのビット長が可変であるという特徴がある。少しでもビットを切りつめて、出来るだけたくさんのデータを詰め込もうという事なのだろうが、本理論においては過去の符号化コードを利用しなくてはならない場面が頻繁に出現するため、これにも注意を要する。なお、このビット長は最大でも１２である。

　また、テーブルのエントリ数は最大４０９５までと決められている。これを超えた場合はテーブルへのデータ登録を行わないようにしなければいけないのだが、本理論では元々テーブルへの書き込みなど行っていないので、無視してかまわない。

図５．ＧＩＦにおけるＬＺＷ辞書テーブル

　以上の様な点に気を付けてコーディングすれば、完全なＧＩＦデコーダが作成出来ると思うのだが、いかんせん発案者本人である私も未だ作成していない為、本当に出来るのかどうか定かではない。＜理論的に出来ないはずは無いのだが・・・。
　手始めにF-BASIC386用のＧＩＦデコードREXプロシジャでも作成してみようとは思っているのだが、余裕があればWindows用のDLLやOCXを作ってみるのも悪くは無いと考えている。あくまで予定は未定だが。

　また、仮にユニシスの特許問題を回避できたとしても他の特許に触れる可能性がゼロであるとは言えない。少なくとも現時点では、日本国内においてユニシスが取得している他の特許に引っかかることは無いと思うが、他社がそれを所持しているかも知れない。

　更に言えば、この程度の理論はプログラムを囓ったことのある人間ならば誰にでも思いつく方法であるという点も、考慮しなければなるまい。プログラマとしても未熟であり、ましてや法律関係では全くの素人である私の理論である。事情通の人が聞いたなら一笑に付されて終わり・・・なんて事も無いとは言えない。いや、ひょっとしたら同じ方法、あるいはもっと良い方法が既に存在しているかも知れないのだ。
　もし、この方法を利用しようなどと考えているのであれば、その辺の事情を良く理解した上で実行して欲しい。

　今回のアルゴリズムでは辞書テーブル内の特定のエントリを返す関数を利用しているが、エンコードの場合は「特定」ではなく、全てのテーブルの中から同じ物があるかどうかのチェックを行わなくてはならない。従って、実際の処理としては今までに作成されているであろうエントリを全て一つづつ抜き出し、圧縮しようとしているデータ列と同じであるかを調べることになる。さらには、「辞書テーブル内の特定のエントリ」を求める方法も展開時に比べて面倒な処理になることが予想される。まぁ壁は高い方が良いという考えの持ち主であれば、挑戦してみるのも悪くはないだろう。

　ところで、実はＧＩＦエンコードに関してはとっておきの裏技がある。その方法は非常に単純明快であり、しかも１００％ユニシスの特許に抵触しない。

　その方法を説明する前に、まずＬＺＷのテーブル構造を思い出して欲しい。０～（色数－１）番目のテーブルはあらかじめ初期化されている、とご説明したのを覚えているだろうか？しかも、ここに格納されている値はテーブル番号のそれと全く同一の物である。また、テーブルへの書き込みは常に「追加」であり。既に存在しているテーブルの内容が書き換えられることはない。仮に初期化コードが現れてテーブルがクリアされたとしても、「初期化」であるから０～（色数－１）のテーブルの値はまたしてもテーブル番号と同一の値に設定される。

　つまるところ、何時いかなる時であっても０～（色数－１）のテーブルの値はテーブル番号と同じなのである。ここまで説明すれば分かっていただけるだろうか。そう、ＧＩＦエンコード時には元データと同じ値をそのまま圧縮コードとして書き込んでいけばいいのである。それを受け取ったデコーダ側でもそれをそのまま出力する事になるので、どんなデコーダであっても表示可能だ。無論、テーブルなど要らない。

　ただ、元データと出力結果が同じと言うことはつまり、全く圧縮になっていないのである。しかも、ＧＩＦ特有のクリアコードと終了コードの存在により、必ず圧縮前よりも大きなサイズになってしまう。したがって、どうしてもＧＩＦでなければならない理由が無い限りは、この方式によるエンコーダーは利用しない方が良いだろう。
　ちなみに、この方式によって作成されたＧＩＦ画像を展開する場合、通常のアルゴリズムによる展開よりも今回ご紹介した展開ルーチンの方が速く展開を行うことができる。全くもって、どうでも良い話ではあるのだが・・・。

　もっとも、しつこいようではあるがこれで本当に大丈夫なのかどうか実際の所私にも良く分かっていない。もし、もっといい方法がある、或いはこの方法では駄目だとか、何か情報をお持ちの方は是非ご連絡して欲しい。
　引き続き、こちらでも調査を行っていく予定であるが、もし何か分かった場合は追って連絡したいと思う。