PIGSのモジュールまわりの処理で特許とれそうな(勢いの)アイデアが浮かんだので、
同様の特許がないか特許庁で検索しておりました。
# 先の「松下 vs ジャストシステム in アイコン特許」の件は、当然の判決と思っていますので、
# ここでは触れません。
特許検索ページで、
キーワードを
コンピュータ プログラム キャッシュ 速度で検索するも、同様のアイデアはヒットしませんでした。
特許化を検討したいところですが(審議中のがあるかもしれんが)、フリーソフトウェア作家な道としては、
特許が逆にマイナスになるかもしらんので、しばらく沈黙。
# 弁理士に10万 + 報酬をはらうっていうのもなんだし。
んで、探している途中で、アレッ? な特許を発見。
特許公開2002-189618 差分キャッシュを用いたWWWサーバとWWWブラウザの処理方法、およびそのプログラム
概要は、こんな感じで、
ブラウザからのリクエストにより作成したWebページを、サーバがキャッシュしておく、
再度同じクライアントから要求があった場合に、
サーバ上では再度Webページを作成し、キャッシュされている前回の情報との差分を抽出、
差分があった場合は、独自のHTTPプロトコル(又はHTTPヘッダー)でブラウザに送信。
独自のHTTPプロトコル(又はHTTPヘッダー)に対応したブラウザは、差分情報と前回の情報を元にWebページを合成し表示する。
通信回線の高速化を目的とする。
えーと、いいですか? 10回ほど読み直してみても、
「独自のHTTPプロトコルヘッダーを処理するWWWサーバ(又はApacheモジュール)の開発と、
独自のブラウザ(又は既存ブラウザに対するプラグイン)を自力で開発する必要がある」
「トータルで考えた場合に、レスポンスや使い勝手が悪くなりそうなアルゴリズムで、
RFC化されずに特許化されているから、フリーソフトウェア作家の反感を買い、ニーズとか人気とか将来性とかは無縁に見えるアイデア。」
「しかも特許の重要なファクターを具現化する、実際のプロトコルヘッダーの様式については一切触れず。
通信回線はこれでいいかもしらんが、
WWWサーバに必要な設備と、一回のリクエストで走るサーバ上のプログラムコード量はアホみたいに増える。」
「差分を取るためには、少なくてもWebページを構成するHTML全体 × 2倍以上のメモリを消費するうえに、
ほぼ毎回DBとWWWサーバ間を似たり寄ったりなデータが2~3往復するのはどうなのよ? という問題と、
DBサーバがWWWサーバと同じマシンにある場合のリソース(メモリとCPU)の枯渇が心配。」
「URLが一文字違うだけでキャッシュミス。
動的なQueryString (?hoge=huge) なんかがくっつていてると、毎回キャッシュミス」
「差分抽出(DIFF)アルゴも、行の完全一致検索(strcmp)にしか見えないし、
1. DBから前回のHTML全文を毎回取得
2. オンメモリで差分検索
3. 1文字違うだけで差分発生
4. 差分の作成と、今回分の全HTMLを再キャッシュ
5. ∞
と、高速処理は期待できないアルゴを搭載」
「【クライアント識別子としてCookies等を送信する】とあるので、セッション管理必須」
「独自HTTPプロトコルヘッダー(又はWWWサーバ)と対となる、
独自ブラウザの開発が必要なアイデアは、超ドリーマーというか、Myファンタジー」
「プロキシサーバへの配慮はまったくありませんよね。これ。ピアツーピアのみで。
独自のプロトコルヘッダと、
プロトコルシーケンスに対応する独自のステータスコードなんてものを勝手に決めたら、
厳しく設定されたプロキシは通してくれませんよ?」
「ブラウザのキャッシュ制御は、今でさえ、ブラウザ毎にけっこう癖やらバグがあり、スッキリしない状態ですが。
さらに複雑性をもちこみ、事態を悪化させたい気持ちは理解にくるしみます。」
「DHTML(ダイナミックHTML)でコンテンツを更新することが極端に難しくなるアイデア。
ブラウザは、サーバから送られて来た差分と、DHTMLで追加/更新したコンテンツがコンフリクトを起こした場合に、
どちらを優先させればいいの?
というありがちな問題には、出願者はまったく気が付いていない模様。
もしかして、【ブラウザは必ずHTMLのパースからやり直すハズ】という前提だから(具体的にはかかれていないが)、
DHTMLでの編集結果とのコンフリクトなんて、気にする必要がないってか?」
「結局サーバ側では毎回ページを丸ごと再作成。サーバがやるべき仕事量は当社比3倍。ブラウザの仕事量も倍増。
ネットワークトラフィックだけが軽減されるが、さまざまなトラブルの要因になる複雑性を併せ持つアイデア」
が特許として登録されている気がしますが。
気のせいでしょうか?
みたいな。
ごめんね、この特許よりも Ajaxのほうが「超スゲ~ことができる」気がするんですが。
# この特許が流行っていたら、Ajaxは生まれなかったかもしれんがね。
HTTP/1.1 の If-Modified-Since からインスパイアされ、コスト度外視の特許を書きあげたように見えますが、
やはり、長く広く愛されるのはシンプルな方式なんですよ。と。
つーかね、HTTP/1.1 + α どころか、こんなに穴だらけに見えるアイデアなのに、特許になりえるんですねぇ… しっかりしてくれよ特許審査。
特許出願者もさ、特許出願より先にRFCをかけよ。
ネットワークの世界でRFCよりも重要視されるドキュメントはそうないよ?
実際、お気軽に F5アタックでも掛けてくる輩がいれば、
# 中華圏の皆様はこの手のいたずらがお好きですよね。
この特許を組み込んだWWWサーバは瞬殺されそうです。いやきっと。むしろ絶対に。
稼動暦数年の商用のWWWサーバを実装したことのある身としましては、
ずいぶん乱暴な特許だなぁ~と思いまして。
まぁ、特許というものは、大概そんなもんかもしれんけども。
すいみませんね。ひがんでしまって。
きっと、特許がうらやましいんです。
おばらっち亭では、この特許と特許出願者を応援していますですよ。