任天堂ｖｓコロプラの無効資料のゲームを解析してみた
ご挨拶
あけましておめでとうございます。
kolibriと申します。元家庭用ゲームのプログラマ、現在は弁理士登録していますが現状あまり弁理士っぽいことをできていない人間です(^^;
『一年の計は元旦にあり』ということで、今年はブログをやってみようと思い立ちました。知財・ゲーム・カメラ・音楽等、自分の興味のあることを細々（ほそぼそ）と綴るブログをイメージしていて、あまり高い頻度での更新はできないかと思いますが、何卒よろしくお願いいたします。
今回のネタ
さて、最初のエントリは何にしようかとネタを探していたところ、任天堂とコロプラの特許訴訟を追いかけているパテントマスター・宮寺さんの以下の記事が目に留まりました。
訴訟が提起されてからもう2年近く経過していて私はすっかりこの件を忘れていたのですが、当然というか訴訟自体は続いており、どうも今年昨年の7月になって、任天堂側の特許、通称(?)『シルエット特許』に対する無効資料がコロプラから新たに追加されたようです。シルエット特許について知らない人のために補足すると、ゲーム中にキャラクタが地形オブジェクトに遮蔽されてしまった場合、遮蔽されたキャラクタのシルエットを表示することでキャラクタがどこにいるのかを視覚的にわかりやすくする特許です（ざっくり）。
宮寺さんによると、コロプラはPCゲーム「Impossible Creatures」のゲームプレイ動画等から無効を主張しているようです。↓がその動画。
しかし、記事でも指摘されていますが、内部の実装次第ではシルエット特許の技術的範囲に属さない可能性は大いにあるわけで（そもそもコロプラが白猫の内部実装を変更することで外見の変更を抑えつつシルエット特許を回避しているわけでして）動画という外見のみではどうも話がスッキリしません。
プログラマとしては内部実装にムクムクと興味が湧きあがってきます。
折よくSteamのウィンターセールで「Impossible Creatures」が割引になっており、200円ちょっとだったので購入してみました。
前置きが長くなってしまいましたが、今回のブログネタはこの「Impossible Creatures」の描画を解析し、ゲームでの実装とシルエット特許との関係を探ってみようという内容になります。
もっとも、シルエット特許の出願日は2002年4月で、「Impossible Creatures」の発売日は2003年1月と出願日より後です。更に今回はSteam経由でゲームを購入しているので、アップデートで内部実装が発売当初から変更されている可能性もわずかながらあります。新規性違反で特許を無効にしたい場合は、特許出願よりも前に発明が公知等になっていることを示す必要がありますので、いくらこのゲームを解析しようがその結果は新規性違反の無効理由を示す資料として直接的に価値があるわけではありません。
なお、私自身は任天堂ともコロプラとも利害関係はなく、ごく個人的な好奇心でやっているということを申し添えておきます。
シルエット特許のおさらい
本題に入る前に、任天堂のシルエット特許とはどういうものだったか、おさらいしてみたいと思います。
【請求項１２】
ゲーム空間における少なくとも地形オブジェクトおよびプレイヤキャラクタを前記ゲーム空間に配置された仮想カメラに基づいて俯瞰的に表示するゲーム装置に、
プレイヤの操作に応答して、前記ゲーム空間における前記プレイヤキャラクタおよび前記仮想カメラの位置を決定する位置決定ステップ、
前記仮想カメラから前記地形オブジェクトまでの奥行情報をＺバッファに書込みながら、前記地形オブジェクトを地形オブジェクト画像によってフレームバッファ内に描画する地形オブジェクト描画ステップ、
前記Ｚバッファの奥行情報を書換えず、前記プレイヤキャラクタを第１目印画像によって前記フレームバッファ内に描画する第１目印画像描画ステップ、および
前記Ｚバッファの奥行情報を参照し、かつ前記プレイヤキャラクタが前記地形オブジェクトよりも前記仮想カメラ側にあるときは前記Ｚバッファの奥行情報を書換えながら、前記プレイヤキャラクタをプレイヤキャラクタ画像によって前記フレームバッファ内に描画するプレイヤキャラクタ描画ステップを実行させる、ゲームプログラム。
（各ステップごとに色付けしてみました）
請求項を分解すると、（１）位置決定ステップと（２）地形オブジェクト描画ステップと（３）第１目印画像描画ステップと（４）プレイヤキャラクタ描画ステップの４ステップからなるゲームプログラムであることが分かります。
このうち、（１）の位置決定ステップは（２）以降のステップに登場する登場人物を定義しているだけで目新しいものはないので（俯瞰的にというところは気になりつつも）、（２）、（３）、（４）に着目してみます。
詳しく説明すると記事が無駄に長くなってしまうので実施例をザックリ説明すると、
（２）は地形オブジェクト（上図中の７８）をフレームバッファに描画しつつ、地形オブジェクト７８の奥行情報をZバッファに格納するという、ごくごく一般的な描画方法です。
（３）では、（２）でZバッファに書き込まれた地形オブジェクト７８の奥行情報を書き換えずにプレイヤキャラクタ７４のシルエット（目印画像）８２をフレームバッファに描画するという特殊な描画をします。請求項では特定されていませんが、実施例では奥行情報を参照（≠書換*1）しないことで、地形とキャラクタの前後関係を無視してキャラシルエットを無理やり描画する旨言及されています（【００７３】あたり）。
（４）では、（３）でキャラシルエット８２を無理やり描画したわけですが、これではキャラの絵がシルエットのみですし、何より地形との前後関係が破綻していますので、改めて同じプレイヤキャラクタ７４をもう一度描画します。この２回目の描画は１回目と異なり、地形オブジェクトの奥行情報が書き込まれたZバッファを参照することで、地形オブジェクトとの前後関係を考慮しつつ、プレイヤキャラクタを「通常通り」描画します。これによって、本来シルエットが表示されていてはおかしい場所については２回目の描画で上書きされて、破綻のない絵が出来上がるという寸法です。
ラクガキで各ステップを表現すると次のようになるでしょうか。
請求項で特定されている発明はシルエット表示に限っておらず、実際の権利範囲はこの実施例よりも更に広いということは留意が必要です。
一般に、キャラクタが地形に遮蔽されてプレイヤにとって見づらい、ということは結構起こり得る話で、それを解決する方法としてかなりエレガントだと思います。回避案はいくつか考えられるものの、特にモバイルの軽量なゲームで侵害しまっているのではないかと思われるような製品もあるようなないような。。。皆さん大丈夫ですかね？
「Impossible Creatures」描画解析
対象製品の描画を解析するためには、ゲーム側からグラフィックスAPIがどのように呼ばれているかを知る必要があります。このためのツールはMicrosoftのPix等いろいろとありますが、「Impossible Creatures」はDirectX 8という古いAPIで描画されているため、Pix等の最近のツールは対応していません。どうしたものかと調べていたところ、こんな素敵なツールを見つけました。
CG野郎には有名なんでしょうか、私は知らなかったです。今回はこれでやってみます。
解析対象を上のようなシーンに決定しました。画面がなんかバグっているというか、どういうシーンなのかよくわからない、という声が聞こえてきそうです。おそらくapitrace側のバグと思われます。ソースが公開されているのでデバッグしたいところですがそんな時間は取れないのでこのままいきます。
解析対象シーンの画面中央右上に謎オブジェクトが描画されていますが、これはプレイヤの陣地にある地形オブジェクトになります。キャラクタユニットがその地形オブジェクトの右側に半身隠れるような形で描画されており、地形オブジェクトに遮蔽されているキャラクタ部分が緑色のシルエット状になっているのが分かるかと思います（ホントにわかる？）。
いかにもシルエット特許っぽい見た目ですが、今回の目的は肝心の内部実装がどうなっているのか？を追及することです。
先ほど説明したように、apitraceではAPIがどのように呼ばれているか、すなわち、解析対象のシーンを構築する際に各段階で「DirectXのどのAPIが」「どういうパラメータを引数として」「どういう順番で呼ばれたか」を見ることができます。
ここからはフレームの初期状態からフレームバッファが完成するまでの短い時間の中で描画が如何にして行われているか、時間軸（＝APIコール順）に沿って見ていきます。
フレームの初期状態から順にAPIコールを追っていくと、このゲームではまず地形オブジェクトを先に描画していることが分かりました。
上のスクリーンショットでは地形オブジェクトは描かれているが、キャラクタやシルエットは表示されていないということが分かります。地形オブジェクト描画時にはもちろんZバッファへの書き込みが行われています。これはシルエット特許における（２）地形オブジェクト描画ステップに相当するものです。
更にAPIコールを進めると、キャラクタの緑のシルエットを表示しているAPIコールが見つかりました。
ここで注目すべきは、画面右側のCurrent StateのParametesタブの下側の「D3DRS_ZWRITEENABLE」の項目のパラメータが０になっている点です。これは、当該シルエットの書き込みの際に、Zバッファへの書き込みを禁止することを示しています。（ZFUNCの説明は割愛）このステップはシルエット特許における（３）第１目印画像描画ステップに相当します。
更に進めていくと、キャラクタ描画のAPIコールが出てきました。
ここでは、ZENABLE及びZFUNCの値から、Zバッファを参照していることが分かります。更に、先ほどのD3DRS_ZWRITEENABLEが１、つまり、Zバッファ書き込みアリでキャラクタを描画していることが分かります。これはシルエット特許における（４）プレイヤキャラクタ描画ステップに相当するものです。
検討
解析の項目で見たように、シルエット特許の請求項に記載されているそれぞれのステップに相当するAPIコールがあります。また、そのAPIコールの順序はシルエット特許の請求項記載のステップの順序と一致しています。しかし些末ではありますが、（３）のステップで、プレイヤキャラクタ描画ステップで描画される場所にはシルエットが描画されていない、というシルエット特許の実施例とは少々異なる点があります。ほかにも複数細かな気になる点はあり、各ステップごとの詳細な比較検討もしたいところですが、これ以上続けると初ブログが長文になりすぎてしまうので、この辺でやめておこうと思います（力尽きたとも言う。毎日ブログ書いてる人とか凄過ぎ、、、）。
まとめ
「Impossible Creatures」の シルエット表示は、任天堂のシルエット特許と技術的な特徴が似ていた。
しかし、冒頭説明したように「Impossible Creatures」の発売日はシルエット特許の出願前ではないので、如何に似ていようとも新規性違反の無効理由とはならない。
（今回書いてる最中に思ったのですが、このシルエット特許、例えばタッチパネルを用いた新しいUIの発明などと違って、特に新しい技術を用いているわけではなく、ごくごく普通にグラフィクスAPIを使用しているだけで、課題としても作ってる側としてはよく遭遇するものなので、探せば似たような実装例が見つかるような気もしていますが、はたして。）
*1:実施例ではZバッファに対する参照と書換が同じような操作であるかのような記載がありますが、別の概念です。請求項でも明確に区別されています。すなわち、Zバッファに対しては①参照するし書き換える、②参照しないが書き換える、③参照するが書き換えない、④参照しないし書き換えない、という異なる4種類の操作があり得るということです。実施例では④ですが、ナイーブに考えると③も権利範囲に入るように思います。
