Ｓｔａｔｅｍｅｎｔ １９
環境転送とは何ぞや？
当時、大学なんかのシステム管理者がやっていたのは、ネット接続アドレスの割り振り。
自動化された現在じゃ、考えられない状況です。
で、メイン端末はWindowsではなく、Ｓｕｎのワークステーション。
演習室で、新マシンに入れ替える際、ケーブル接続後の各端末のネット設定を、どうしたか？
システム管理者が、一々、設定していったか、それとも、中央でマトメて設定できたか？
まず、ここを確認する必要があります。
会社の端末の入れ替え時、設定は誰がやっていたかな。
少なくとも、教員研究室で、端末にWindowsパソコンを導入すると、ケーブル接続しても、システム管理者はネット経由でネット接続設定できませんでした。
これは、私の研究室だけではないことを確認済みです。
当然ですね、ケーブで繋いだだけではネット接続できてないわけだから。
Ｓｕｎ⇒Ｓｕｎ間でも、Windows⇒Windowsでも、できるはずがない。
この事実が大事。
つまり、設定情報が転送できない具体例があったということ。
当然、ダイヤルアップ設定情報も移せません。
一方、ＸＰのＦＳＴＷで、これを転送可能にしたのが環境転送。
これで、特許成立。
ちなみに、ネット接続後、ファイルの転送レベルなら、ＳｕｎからWindowsでも、やれましたよ、当時から。
これは伏線。
では、ネット接続後、他の設定情報なら転送できたか？
ここまで曖昧に匂わせておいて、そろそろ、核心に。
システム管理者レベルでやるリモート設定と転送設定は違います。
リモート設定は、あくまでも、離れた場所から管理者やユーザが入力するの。
一方、転送設定は、旧マシンの設定情報を新マシンに転送して、ＯＳ的に有効化する必要があります。
ソフトとして作り込む必要があるわけ。
転送を同一マシンレベルで，貧弱に実施していたのが、ＭＳの持ち出したｅｘｐｏｒｔ-ｉｍｐｏｒｔ機能。
以前、ｅｘｐｏｒｔとｉｍｐｏｒｔは対になった概念だと指摘しました。
これも伏線。
環境転送は、どちらに比較的近いか？
ｉｍｐｏｒｔ側ですね。
しかし、単純なｉｍｐｏｒｔ機能とは格が違います。
（哲学ではなく、数学の）カテゴリー論の用語を使えば、
「ｐｕｓｈ ｄｏｗｎ ｖｓ ｐｕｌｌ ｂａｃｋ」
でｐｕｌｌ ｂａｃｋの方だと言った方が、より近い比喩になります。
つまり、環境転送はｉｍｐｏｒｔではなく、新規なｐｕｌｌ ｂａｃｋだと言ってるの。
具体的に比較指摘しておきましょうか。
まず、従来のメールなんかの単純ｉｍｐｏｒｔは、
「同じＯＳ上の同じアプリや、精々が別アプリから」
という類。
ｉｍｐｏｒｔの場合、これが一番多いですね。
では、別マシンへのｉｍｐｏｒｔは無かったか？
この場合、別マシンへの転送手段を、どうするのか？
ネット以外の手段を使ったｉｍｐｏｒｔは、それまであったか？
あったとしたら、どうやったのか？
まず、この段階で、検証作業が必要になります。
少なくとも、専用ケーブル使ったシステムは無かったことは確認済み。
これは転送速度問題に関係します。
これで、環境転送特許の新規性・進歩性の追加。
ミーティングでＭＳ側がプレゼンしたのは、このステージをパスできてなかったということ。
ここで、上のシステム管理レベルの伏線が効くのよ。
ネットで繋げれば、似たようなものだと思うのが素人。
プログラムとしての作りこみ問題ですよ。
私の特許のプログラムレベルクレームが、ここで作用するのよ。
それでも、WindowsからWindowsなら簡単に作れたのでは？
ここから、次の進化局面に入ります。
個々のｉｍｐｏｒｔレベルの転送ならできたカモ。
しかし、複数の設定をまとめて同時に転送することはできるか？
この課題を思いつくプロはいなかったと言ってるの、私は。
これで、更なる、追加の新規性・進歩性確認。
当時の技術レベルでは、個別ｉｍｐｏｒｔで一つ一つ実施していくしかなかったのですよ。
例えば、データベースアプリでのｉｍｐｏｒｔとか。
これに関しても、すでに、伏線を張っておきました。
ｅｘｐｏｒｔとｉｍｐｏｒｔのペアで、初めて、別マシンへの転送が出来る仕組みになっています。
つまり、こういう高級ｉｍｐｏｒｔの場合、相棒のｅｘｐｏｒｔ抜きでは機能しないの。
一方、環境転送はｐｕｌｌ ｂａｃｋだけで動きます。
そもそも、複数設定をまとめて、同時に対象化するという機能自体が無かったの。
情報場で指定するグローバルな範囲の複数設定の課題です。
この複数設定対象同時転送機能こそが環境転送の目玉。
これは、局所的な、ｉｍｐｏｒｔ単独機能のカバーする範囲を超えているのですよ。
すると、技術職人は、
「一つ一つ転送できると（仮定）したら、複数同時も簡単だ。」
と、こう言い出すはず。
それが、理論知らずの職人の弊害だと指摘してあげているのよ。
難しさが全然違います。
これは、単に量の話しではなく、質が違うの。
どう質的に違うのか？
ＸＰのＦＳＴＷがバグだらけになったくらい違うのよ。
世間は、素人向けの一括転送ＦＳＴＷよりも、プロ向けのシステム管理系の方が技術的に高級だと考えるはず。
だから、システム管理系ソフトがあれば、ＦＳＴＷは簡単に作れると錯覚するのよ。
しかして、その実体は？
システム管理系の方が低級なのよ。
ここが判ってなかったの、従来のプロに。
私が、ＡＩ系の話題を持ち出したのは、こういう伏線。
素人向けに仕上げる方が、遥かに、難しいの。
転送の労力を、システム管理者負担からプログラム側に移す分だけ難しい。
自然言語の比喩で言えば、マシンが単語を提示した後、文章の組み立てを、どちらが行うか。
人かマシンか。
単純に、単語を羅列すれば良いというものじゃないのよ。
今まで、ＵＳＭＴも特許侵害の対象として扱ってきたのは、ここで比較するための伏線です。
１９９８年当時、システム管理者向けに、ＵＳＭＴの未熟版に相当するものがあったカモ。
しかし、ＦＳＴＷに相当するものは、絶対に、無かったの。
そして、いいですか、
「ＦＳＴＷ作った後は、その隠れた技術が、ＵＳＭＴにも利用されたはずだ」
と言ってるのよ。
これが、ＦＳＴＷ以降のＵＳＭＴも侵害対象だという意味。
つまり、ＵＳＭＴは、それまでの流れと新しい潮流の合併。
こう主張できるのですよ。
これを、逆に、
「それまでのシステム管理技術を利用して、素人向けのＦＳＴＷを作った。」
と解釈するのは間違い。
何故、こう断言できるのか？
だって、システム管理者が実施しているのはｐｕｓｈ ｄｏｗｎの見本ですもの。
一方、ＦＳＴＷはｐｕｌｌ ｂａｃｋの見本。
これが基本思想の違い。
当然、機能にも技術にも影響します。
というわけで、以後、システム管理系の寝言は通用しません、環境転送特許の無効化には。
これで、ｐｕｌｌ ｂａｃｋの勝利。
返す刀で、ｉｍｐｏｒｔを袈裟懸けに。
技術職人が作るのだから、どのソフトにも、少しはバグが残ります。
しかし、ＦＳＴＷのバグは、そういうレベルじゃなかったの。
ほぼ、使い物にならないレベルのバグ。
環境転送では、新しい、システムレベルバグが発生したのですよ。
判り易い例を。
ＦＳＴＷでバグが発生します。
ここで、従来の君らの武器を使います。
転送失敗箇所を一つ選んで、別ソフト作ってｉｍｐｏｒｔで転送するとします。
この場合も、同じバグは発生しますか？
しないでしょう。
では、何故、ＦＳＴＷでは発生したのか？
転送対象が多かったから手抜きしたなんて言い訳は駄目。
それほど多くないでしょうが、転送対象は。
それでも、あのバグ発生ぶり。
ここは、やはり、何か、本質的なことが関与していると思うべきなの。
そもそも、ＦＳＴＷのバグは、個別転送レベルのバグなのか？
勿論、症状的には、個別のファイルや設定レベルで発生します。
しかし、原因は何処に潜んでいるのか？
その根本原因は何か確認してみましたか？
君らは、単なる個別バグだと言いたいでしょう。
残念ながら、こちらが、システム固有のバグだと言うと、反論できないのよ。
それまでの個別ｉｍｐｏｒｔ系バグと比較して、多ければ駄目。
特許無効の理由に、ｉｍｐｏｒｔを持ち出せないということ。
それが論理。
これがｐｕｌｌ ｂａｃｋの難しさです。
ｐｕｌｌ ｂａｃｋは設定情報のみならず、７のようなファイル転送までもカバーします。
ｐｕｓｈ ｄｏｗｎなシステム管理レベルの機能じゃないということ。
これで７も特許侵害。
勿論、Ｖｉｓｔａになると、職人得意のアドホック訂正を実施したでしょう。
つまり、対症療法。
その結果、目立ったバグは減ったはず。
それで、普通くらいの機能になったか？
（Ｖｉｓｔａで、マトモなバグ処理できていたのかな？
私は、購入してないので未確認ですが。）
７で設定転送を外したのは、単なる特許対策だとは思えないのですが・・・。
今からでも、バグ発生の原因調査はできるでしょう。
現時点で、それをやってないとすると、その事実だけでも、アメリの負け。
未来永劫、設定情報の転送はしないつもりなのか。
それなのに、ＯＳをコロコロ変え、パソコンをファッション並みに売り出す。
その度に、入れ替え手間が発生。
それじゃ、人類の迷惑。
環境転送の御利益が、まるで、判ってない証拠。
今から、慌てて検査に走っても、裁判的には手遅れ。
逆に証拠になります。
つまり、脳足りんで特許侵害。
その結果、
「環境転送はバグが多くて役に立たない」
という印象や風評が世間に広まったカモ。
万死に値します。
こういう状況だったのですよ。
勝負という意味が判っているのかね、アメリよ。
だから困るのよ、職人だけで、見様見真似で勝手に開発されると。
御本尊の私を抜きにして、愚かな。
中国の粗悪模倣品を笑えない技術力。
何を誤魔化しているのよ、“背景一つ”の転送で。
しかも、“グレードアップ可能なWindowsＯＳ間”転送で。
おまけに、７でメールを外して、設定転送を中止しておいて。
７で設定情報の転送を休止したのは、不要だと思ったからか？
違いますね、そんなことは有り得ません。
不要どころか、今後、ますます輝きを増す、最重要課題の一つです。
この点を判らせてきたの、敵に対しても。
実は、環境転送特許では、転送結果の品質保証の観点から、転送モデルをキチンと明細記述しています。
モデルの整合性でバグを（他のソフト並みに）減らそうという姿勢。
あれを、単なる抽象の箔付け飾りと思ったのでしょう、ＭＳやアップルは。
１９９８年当時の人類の知的水準は、そういうレベルだったの。
だからこそ、ＭＳは特許無効化を狙うのです。
ところが、こちらは、その行為自体が、環境転送特許の新規性・進歩性の証拠になると言ってるの。
次回、特許の転送モデルについて議論していきます。
勿論、核心はグローバルな情報場の概念。
これが、転送保証の技術と関連してきます。
何故、私が、伏線として、“木のインベッド”なんて概念を持ち出したのか。
この段階では、こう指摘しても、チンプンカンプンでしょう、多分。
あれは、後付けだろうと思うはず。
フフン、それが青い。
モデルの伏線だったのですよ。
これと、特許の明細が、どう繋がるのか？
こう質問してやっても、解答は判らないでしょう。
だから、ＭＳやアップルが特許無効化可能と妄想を抱くのよ。
業界も、まだまだ、甘いわ。
言っておきますが、モデルは環境転送の品質保証の観点からのサービス情報ですよ。
特許のクレームは、モデルに依存してないという事実が大事。
つまり、
「モデルから外れた粗悪品だから特許侵害してない。」
という言いわけはできないの。
システムとしてｐｕｌｌ ｂａｃｋしてると特許侵害です。
マ、粗悪品でも、そうと意識せずにモデルに準拠してるのですが・・・。
何を言ってるのか判らないはず。
次回までの課題と思って、考えてみなさい、新猿の知性よ。