Statement 25

 

前回のWindows7に関する検証結果は、訂正しました。

これで、世間が一層騒がしくなった風情。

実は、7での転送は、文字サイズに関する限り、成功しています。

(依然として、他の設定情報で、7に転送系バグが発生する可能性は残っていますが。)

では、転送結果、何故、このような画面が出現したのか?

 

Windows7

 

これはね、転送直後の画面です。

再起動すると、無事、正常な100%変更成功画面になるという筋書き。

一方、WindowsXPの方は、再起動後も、文字サイズの異常状態が治らないの。

こういう違いです。

皆さんも、手持ちの7やXPで実験してみてください。

再現性があります。

(XPが手元にないユーザも多いカモ。

しかし、まだ残っているユーザも多数いるはず。

だから、誤魔化せないぜ、MSよ。)

 

7で、文字サイズのバグは解消されても、それは転送範囲を簡略化した効果。

特許としては、無効化できないの。

XPでバグ発生ですよ。

こちらとしては、バグを一つ見つければいいのよ。

それで、転送が難しい証拠になります。

逆に、7で、文字サイズの転送をバグなく実施したという事実が特許侵害の証拠になります。

もう少し、詳しく論じておきましょうか。

素人の判事や陪審員にポイントを判らせる必要がありますから。 

 

何故、MSは、私の特許を無効化できると思い込んでいたのか?

まずは、この錯覚、というか、妄想の根拠の推察から。

ある一つのアプリに着目して、それをimportします。

次に、二つ目のアプリもimportできるようにする。

更には、三つ目のアプリもimportできるようにする。

そこで、三つマトメて、importしてみます。 

これに、無事、成功したとしますね。 

これで、高を括るわけです。 

 

「個々のアプリのimportが成功してるんだから、マトメたimportも、自然にできるはず。」

という一般化による錯覚が発生します。 

だから、

「多数のアプリを同時に転送しても大丈夫。」

こういう新猿の帰納法が採用できると思い込むわけだ。

しかし、残念ながら、そう単純ではないの、設定情報を移す場合は。

その具体例が、文字のサイズ。

 

100%の文字サイズマシン情報を200%の文字サイズマシンに転送します。

すると、転送先のマシンでは、文字サイズの意味で、矛盾が発生。

どちらかの%に統一するのがマトモな処理です。

この場合、転送先マシンが100%になるか、200%になるかですが。

結果が100%になれば、文字サイズの転送が出来たことになり。

200%のままだと、文字サイズの転送は、できてないことになる。

いずれにせよ、何らかの、統一した結果が期待されます。

これに成功しているか?

前回の実験結果は、XPでバグの発生を証明しています。

 

では、何故、これで、特許侵害になるのか?

転送失敗したということは、逆に、特許侵害してないことを意味しないのか?

意味してません。

失敗は、

「設定情報の転送は、物凄く難しい」

ことを意味します。

上の伏線で言えば、新猿の帰納法が適用できないくらい難しいの。

 

これを、特許的に言えば、

「設定情報の同時複数転送は、importと比較し、新規性・進歩性がある。」

となります。

MSが失敗するくらい難しいの。

ゆえに、特許無効化は無理です。

importレベルの技術なら、こういう種類のバグは発生するはずがない。

結果の現象論ではなく、理論的に考察しておくと。

 

文字サイズは、内部で、蜘蛛の巣のように、相互に絡み合っているわけです。

これを、キチンと解き解すには、木構造に展開し、階層化する操作が必須です。

これを実施して、初めて、マトメ転送が、矛盾なく実行できるわけだ。

だからこそ、特許では、階層化や木構造を強調したわけです。

ということは、

「木構造を採用してない転送は、特許侵害にならないのでは?」

再度、こういうグルグル廻りを始める職人が多いカモ。

だから、駄目なのよ、脳タリンは。

 

私が特許侵害だと指摘しているのは、

「(複数)設定情報を転送する場合、暗黙の裡に、木構造を採用する。」

という事実関係です。

意識しようがしまいが、問答無用で、採用しているの。

そうしないと、整合的に、転送できないからです。

方式や、システムレベルで、必ず、木構造を扱う宿命なの。

それが、設定情報の転送。 

そして、本特許は、プログラムレベルで、木構造を扱う場合だけに限定してません。

 

単純な場合は、木構造を意識しないでも、転送成功します。 

しかし、複雑になると、交通整理が必須になるの。

このルールが木構造。 

複雑の見本が文字サイズ設定の転送。

100%と200%が交わるわけです。

「デモ、失敗してるじゃないか。

だから、importレベルの技術しか使用しておらず、侵害してない。」

と、三度、グルグル回る職人の惨めさ。

ここで、伏線が効きます。

 

7では文字サイズの転送が成功しました。

ゆえに、7は特許侵害。

何故ならば、文字サイズの転送は、importでは無理だからです。

一方、XPでは、文字サイズの転送に失敗しています。

これは、転送しなかったわけじゃないの。

転送したからこそ起きたバグ。

つまり、XPでも、文字サイズの転送をしたの。

だから、特許侵害。

文字サイズを転送する限り、特許を回避できないの。

 

注意:

転送のビジネス的な意図は、

「新規購入マシンに、既存のマシンの環境情報を転送する」

というものでした。

そこで、200%サイズ旧マシン文字情報を、真っ新な、デフォルト100%サイズ文字マシンに移します。

これで、新マシンに文字サイズの矛盾発生。

これを、何とかしたら、この部分では、バグが発生しません。

で、実際は、どうなっているか?

検証してみなさいよ。

 

職人は、バグが発生しないと、import程度だと思うの。

だから、こういうケースではバグが発生しますよと、証拠を提示しました。

ちなみに、暫く使用したマシン間の転送も、特許の対象ですよ。

新規マシンへの転送限定とは、どこにも書いてない。

200%マシンから、使用済み100%マシンへの転送を試してみましたか?

文字サイズは、どうなるか? 

自分で、やってみなさい。   

 

原理・原則に従ってマトメておくと。

本特許は、転送に関する基本特許です。 

特徴は、設定情報を、キチンと木構造として把握すること。

「情報場」

という専門用語まで採用して、強調しておきました。

木構造の分析が甘いと、転送結果にバグが発生します。

MS職人の技量が未熟だったということ。

逆に言えば、木構造をキチンと把握すると、バグの解析もできます。

何処で、どう、間違ったか、判るの。

 

importと環境転送が本質的に違うことまでは判ったとして。

「木構造を意識してなかったから、特許侵害にはならない。」

と言い出すカモ。

しかし、問答無用で特許侵害してるのですよ。

文字サイズ転送したら、全て、特許侵害。

この意味・理由が判らなければ話にならない。

設定関係の木構造(情報場)は、転送の場面で、不可避に発生するの。

バグの発生は、その情報場が、不完全か、まともかの違い。

もしくは、転送での木の対応が不完全か、完全かの違い。

情報場の生成は必須です。

 

ただ、木のノードが、特許の明細で例示したようになってないカモ。

しかしね、どの形のノード採用しても、木構造として、同値なんですよ。

あれは、参考提示です。 

「ならば、この特許は汎用的過ぎないか?」

汎用的過ぎません。

その証拠が、Windows8です。 

8は、元々、タブレット用に新規開発されたOSでした。

しかし、ビジネス的に、使い勝手が悪過ぎた。

よって、MSは、急遽、8.1に改訂したわけです。

 

このOSにも、一応、まだ、転送機能は残っています。

しかしね、殆ど、役に立たない代物。

まず、肝心の設定情報の転送はできなくなりました。

つまり、私の特許の範囲外です。

この意味で、環境転送はOS付属機能として、汎用的過ぎないの。

複数ファイルのimport程度なら、特許侵害じゃない。

文字サイズを転送したら、特許侵害。

だって、各アプリのimportレベルでは、原理上、文字サイズは転送できませんから。

これで、私の勝ち。

 

天命なんですよ、私がMSに特許侵害で勝つことは。

何故か、MSは、転送制限の、Windows8.1を出してきた。

これにより、

「OSの設定情報の転送をしない転送」

という具体例が登場したわけです。

これならimportレベル複数転送で特許侵害じゃありません。

しかし、文字サイズを転送したら、必ず、特許侵害します。

OS設定情報は、複雑に絡まりあっています。

その具体例が文字サイズ。

これを転送するということは、新旧木構造を対応させるということ。