Ｓｔａｔｅｍｅｎｔ　１２

環境転送の意図は

＜１＞ユーザが自分で使用環境情報を個別に新マシンに移す煩わしさを省く

というもの。

これには、

＜２＞トータルの転送時間を短縮する。

ことも期待されています。

さて、現在、ＭＳやアップルでは、＜２＞は、どの程度実現できていますか？

これが実現できてこそ、真の御利益を体感することができるの。

基本特許では、＜２＞の具体的実現法としては、専用ケーブル使うハード手法を例示しています。

では＜２＞は、ソフト系で、どの程度可能か？

ここで、“環境転送指向でＯＳ開発”という基本思想が本質的に関与してきます。

そして、これが情報場の概念に深く関わってくるのです。

各種使用環境情報の転送範囲を取り纏めたのが情報場というコンセプト。

このように、キチンと独立させて考察の対象にしておくと、応用の場面でも効果が発揮できるのですよ。

転送に時間が掛かる原因は何か？

[１]散らばっている情報の回収作業

[２]転送容量の大きさ

[３]新マシンでの再配分作業。

ここで、一番の要因は[２]の転送容量。

ならばですよ、転送容量を減らせばいい。

この為には、情報を圧縮すればいい。

ここまでは、素人でも考えます。

だって、現実に、大容量のファイルを移す場合、圧縮していますから。

ところが、環境転送の場合、個々のファイルや設定情報を移す場合とは、格が違います。

想定範囲の使用環境全体を、一気に、同時に移す必要があるのよ。

しかも、移った先の新マシンで、適切に再配分して各使用環境として使い物になるようにできねば。

この目的で、木のインベッドという抽象概念を実現しているわけです。

つまり、新マシンの環境に適するように、旧マシンの環境を対応させて移す。

これを、情報場で実行しているの。

というわけで、環境転送という観点から見た場合、旧マシンの環境は、各使用情報の内容と、そのラベルに分かれます。

ラベルが木のノードの位置関係を指示していて、このラベルを新マシンの環境木のしかるべき位置に対応させる。

このインベッド結果を、新マシンで再配分するという一連の操作を実施するわけです。

各作業を、こういう風に分析しておくと、ラベルの内容は、インベッドには直接関係しないことが判ります。

だったら、内容を圧縮できますね。

この圧縮効果が大きいことは、[２]の課題として、上で指摘しました。

では、この圧縮は、いつ実施するか？

ここで、環境転送の御利益が発揮できます。

そもそも、環境転送を始めてから旧マシンの使用情報をまとめる必要はないでしょう。

環境転送の核心はインベッドです。

しかし、インベッド前の、まとめる時期については何も述べていません。

だったら、散らばっている使用情報のコピーを、前もって、一箇所にまとめておいたら？

これが出来れば、その時点で、内容情報を圧縮格納できますね。

これで、[１]も速くなるはず。

それに対し、環境転送が発動されると、新マシンのＯＳ構造に適合した情報場が作成されます。

インベッドの前後で分解すれば、

「旧使用環境の部分集合としての旧情報場ｖｓ新使用環境の部分集合としての新情報場」。

基本特許では、この新旧情報場のことを情報場と呼んでいます。

これにより、旧使用環境から、新使用環境へ移す範囲を確定させる。

その後、インベッドする。

この作業は、今回追加した圧縮情報ベースでも同様。

圧縮とは、同じ内容の表現法（コード）の違いです。

転送後、新マシンに新情報場が生成されるわけです。

が、旧ＯＳの場合同様、これも解凍せず、まとまったまま、格納しておきます。

それとは別に、内容を解凍したコピーを各ラベルに応じて、新環境木に配分します。

これで、[３]は、実質的に同じ仕事。

ただ、解凍時間の問題がありますが、[２]の時短効果と比較すれば何てことないでしょう。

当然ですが、各ラベルの各使用情報は、圧縮版と解凍版が改変時に同期します。

つまり、ファイルや設定を変更したら、まとめて格納されている圧縮版の対応コードも変更されます。

このように、ＯＳを創るのですよ。

新ＯＳで、転送結果以外の使用情報が木に追加される場合も、同様です。

確認しておきますが、インベッドに要する時間だけは、どうしようもありません。

但し、インベッド自体を簡略化して実行できる可能性は残ります。

マ、これは理論上の話題ですが。

これを実現するには、新ＯＳの構造に制約を付ければいいのですが・・・。

さて、将来、ここまで発展するかな。

以上が環境転送指向でＯＳ開発する触発効果。

Windows７までは基本特許を侵害しています。

この事実を、すでに論証しました。

今回指摘したのは、環境転送３の内容。

今更、得意がって、高転び自滅するわけがない。

つまり、環境転送１にあたる本特許は、この方面の基本特許だということ。

派生特許に関するポートフォリオを、こういう風に先行予約公開するのもビジネス戦略。

実質的に、複数の特許群で権利を守っていくのと同値なの。

こちらの方が高級戦略。

こういうビジネス展開してるのですよ。

転送速度系の応用発展機能は、環境転送特許のクレーム範囲ではありません。

この御利益を強調すると、

「マトメコピー機能や圧縮・解凍機能を使わない転送は特許侵害してない」

と言い出すことが目に見えていたからです。

だからこそ、その前の（新）情報場でクレームしておいたわけ。

しかし、速く転送することを本気で考えると、ここまで踏み込むべきでしょう。

いずれにせよ、課題は、旧情報場を新情報場に変換処理するインベッド作業。

これが実現できなければ、どうしようもありません。

その証拠が他社のＯＳマシン。

一方、現在、Windows系では、環境転送機能が利用できます。

実際に、旧マシンから情報場を作成し、新マシンで環境利用しているわけですから。

これを、理論的に細かく言えば、

「旧マシンの旧情報場を新マシンの新情報場にインベッドしてる」

ということ。

新旧マシンで木構造が違うという事実を強調したのですよ。

では、旧情報場を新情報場に直すインベッド作業は、何処でやるのか？

転送前か後か。

これに関しては、ユトリがあります。

いずれにせよ、環境転送機能が発動した後の仕事という事実は同じです。

つまり、環境転送ソフトが新旧マシンで動かなければ話が始まらない。

ここがポイント。

ソフト自体は新マシンの新ＯＳに付属しています。

しかし、それで、旧マシンの旧ＯＳの旧使用環境を扱うわけだ。

しかも、新マシンの新ＯＳの新使用環境へのインベッドの成功保証付き。

これを保証するのが、情報場という概念。

インベッドが保証できる範囲のＯＳ相手に、保証できる範囲の情報場を（旧使用環境から）切り出す。

今回、圧縮・解凍を絡めたので、情報場コンセプトの意義が際立ったのでは？

特許侵害の観点から、一番大事な事実を再強調しておきます。

基本特許で言う“使用環境”という概念は曖昧です。

例えば、ＯＳ付属のソフトなんてものは、時代と共に変化していく宿命。

曖昧なものはインベッドできません。

これを、新ＯＳ向けにキチンと範囲確定したのが情報場。

しかも、インベッドの成功保証付き。

一方、今回の“旧使用環境のマトメコピー”は範囲確定させないと設定できません。

よって、ここでは、実用的に、

「旧ＯＳ内の使用環境を“できるだけ広い範囲で切り出したもの”」

と言っておきましょうか。

情報場の範囲をカバーするという想定。

しかし、それでも、新ＯＳが出来上がってみないと、情報場は決まりません。

想定範囲にズレが生じることもあるということ。

更に言えば、旧情報場が新情報場にインベッドできる保証もありません。

これを保証するのが環境転送。

この意味で、環境転送３は環境転送の応用特許だということ。

今更、

「ｅｘｐｏｒｔ-ｉｍｐｏｒｔで特許侵害を回避できる」

なんぞという甘い妄想抱かないように。

長いものには巻かれる、神とは組んでビジネスする。