知財クラスタの皆さん、バージョン管理システムどうですか?

超々久しぶりのブログになってしまいました。皆さんお元気ですか?僕は元気です。

さて、先日ツイッターでこのようなアンケートをしてみました。

その結果、多くの人が「使ってない」と答えました。これは、今まで私が現場で見聞きした状況と変わりません。

バージョン管理システムは、比較的大きなプロジェクトでプログラムのソースコードのバージョンを管理する目的で作られたものですよね。一方、知財クラスタの仕事は、大規模プロジェクトというよりは、個人プレーに近いですし、扱うものがソースコードではなく、日本語などの自然言語による文書であるという違いもあります。このような違いがあるので、皆さんは他に適したツールを使っているかもしれませんが、私はプログラマなので、使い慣れたバージョン管理システムを使っています。

バージョン管理システムはいろいろな意味で便利だと思いますが、普段の仕事で解決してくれている課題は次のようなものです。

課題

まず、明細書や契約書をWordで書いてる人は、以下のような問題に遭遇したことはないでしょうか。

①バージョン取り違え問題

下の図のような経験はないでしょうか。

f:id:kolibri:20210202164247p:plain

 

一見して、「今必要なのはどれだよ!」と思ってしまいますよね。Finalって言ってるのが正しいの?ファイルのタイムスタンプ?本当にそれが一番最新だという確信はどうすれば持てるの?

間違って古いバージョンで出願してしまったら目も当てられません。

ファイルを一つにして常に上書き保存するようにしてもいいですけど、修正履歴やそれぞれのバージョンを保存しておきたいと思うのも普通のことですよね。どういう意図で変更したのかを後から検証できることも重要です。このような異なるバージョンを複数のファイルで管理するのは煩雑すぎますよね。

もっとも、SharePointクラウドドライブのバージョン履歴機能、Wordのバージョン履歴機能を使ってもいいですけど、その場合次のような問題が発生しませんか?

②修正問題

 例えば甲さんが以下の文章をWordで作成したとします。

f:id:kolibri:20210202171034p:plain

 

次にそれを乙さんが修正履歴をつけて修正したとします。

f:id:kolibri:20210202171331p:plain

乙さんの修正を見た甲さんは、

「Wordの修正履歴を見ると、第1稿が第2稿になってるのが分かるね。あとHogeHogeに続いてFugaFugaが追加されてるね。」と思いました。

しかし、よく見てください。「テキスト」という文字が「テキト」に変わってませんか?修正履歴もないのに。。。これは、いわゆる「サイレント修正」・・・

 

こういう場合、Wordの「文章の比較」ツールやWinMerge等を使うのが通常かと思います。このようにテキヌトのサイレント修正もよくわかりますね。

f:id:kolibri:20210202172515p:plain

しかし、毎度毎度修正前のファイルと修正後のファイルを選択して「文章の比較」ツール等を使って比較するというのも面倒です。何ならバージョン違いの複数のファイルを扱っている場合、ファイルの取り違えも起こりそうです。


意図的かどうかは別にして、こうした無言の修正が行われることもあるようです。これを見過ごすのは危険ですよね。

解決手段

冒頭で述べたように、自然言語の文書ファイルに適したツールを導入されている方もいらっしゃると思いますが、私は現在、Gitというバージョン管理システムを使っています。『GitHubで情報漏洩』などのニュースが報じられることもあるので、GitとGitHubについては、ほとんどの方が聞いたことがあるのではないでしょうか。

Gitでは、上記のようなバージョン違いのファイルをそれぞれ保存することができます。また、TortoiseGitのようなGUIアシスタントを使えば、以前のバージョンとの差分を簡単に確認することができます。

他にも、内向きの情報を含んだファイルを外部に送信する際に、内向きの情報をストリップしておきたいケースもあるでしょう。そのような場合にも便利にバージョン管理できると思います。

最後に

いやいや、こういう問題だったらこっちのツールのほうがもっとスマートに解決できるよ、っていうのがあれば是非いろいろ教えてほしいです。いろいろ試してみたいと思っています。

逆に、この記事を見て万一「ほうほう、Gitってのが便利なのか、じゃあこのGitHubってところに作成中の明細書を上げてバージョン管理しようかな」と思われた方いらっしゃいましたら、事故(ダンス)っちまう前に私でもほかのエンジニアでもいいので一言相談してください。

私からは以上です。

参考リンク

git-scm.com

qiita.com

弁理士試験、「いくつあるか問題」問題

「いくつあるか問題」・・・・・・悪魔的発想・・・・・・!!!!

 

 昨日は日本弁理士会の賀詞交歓会(@ホテルオークラ東京)に出席してきました。リアル知り合いの方々に確認したところ皆さん参加しないとのことで、ボッチで参加してご飯を食べて帰ってきました。来年参加するときはもう少しまともなムーブができればと思っています。ご飯は美味しかったです。

 

 今日のブログのネタは、弁理士試験の『いくつあるか問題』です。「『いくつあるか問題』って何?」という方のために説明すると、問題ひとつにつき4~5個の〇×の小問(以下、枝といいます)があり、その〇(又は×)の個数を選択肢の中から答える問題です。例えば次のような問題です。

 特許法に規定する手続に関し、次の(イ)~(ホ)のうち、正しいものは、いくつあるか。


(イ) 特許庁長官は、遠隔又は交通不便の地にある者のため、請求により又は職権で、特許出願について出願審査の請求をすることができる期間を延長することができる。

(ロ) 日本国内に住所又は居所を有する者であって手続をするものの委任による代理人は、特別の授権を得なければ、特許法第 41 条第1項に規定する優先権の主張を伴う特許出願をすることはできない。

(ハ) 特許庁長官又は審判長は、手続をする者の代理人がその手続をするのに適当でないと認めるときは、その改任を命ずることができる。また、改任の命令をした後に当該適当でないと認める代理人特許庁に対してした手続は、特許庁長官又は審判長によって却下される場合がある。

(ニ) 特許庁長官又は審判官は、中断した審査、特許異議の申立てについての審理及び決定、審判又は再審の手続を受け継ぐべき者が受継を怠ったときは、申立てにより又は職権で、相当の期間を指定して、受継を命じなければならず、指定した期間内に受継がないときは、受継を命じた日に受継があったものとみなすことができる。

(ホ) 拒絶理由の通知に対する意見書を特許出願人が郵便により提出し、日本郵便株式会社の営業所に差し出した日時を郵便物の受領証により証明できない場合、その郵便物の通信日付印により表示された日時のうち日のみが明瞭であって時刻が明瞭でないときは、当該意見書は、表示された日の午後 12 時に特許庁に到達したものとみなされる。


1 1つ
2 2つ
3 3つ
4 4つ
5 5つ

(令和元年度弁理士試験短答式筆記試験問題 【特許・実用新案】8 より)

 ちなみにこれの答えは(ロ)(ハ)(ホ)の三つの枝が〇なので答えは「3」です。

 ここで少し考えてほしいのですが、例えば(ロ)(ハ)(ホ)については正しく〇と判断できたとして、(ニ)は本来×なのに間違って〇としてしまった場合、途中までは正しい判断ができていたとしても、全体としては問答無用で不正解になってしまいます。このように、「いくつあるか問題」はすべての枝の問うている内容の「固い知識」を身につけないと正解することは覚束ない、難しい問題です。

 一方で、逆に、(ロ)(ハ)は正しく〇と判断できたが、誤って(ホ)は×だと判断してしまい、更に(ニ)は本来×なところ誤って〇と判断してしまった場合、どうなるでしょうか。このように二重に間違ってしまった場合、〇の数は三つになり、考え方は間違っているのに、問には正解してしまうのです。このように、実力が不足しているのにラッキーで正解できてしまうこともあり、結果だけに着目すると本当の自分の実力が分からなくなってしまう怖さもあります。

 弁理士試験の短答式試験には、「いくつあるか問題」のほかに、いわゆる「五肢択一問題」もあります。「五肢択一問題」は、5つの選択肢の中から最も確からしいものを選択せよ、という問題で、それぞれの枝を相互に比較しながら検討できるため、知識がソコソコでもその場の思考力で知識の穴を補間しながら解けるといった特徴があります。

 

 ところで、「いくつあるか問題」は本当に正解するのが難しい問題なんでしょうか。「五肢択一問題」より難しそうだという感覚はありますが、実際のところどうなんでしょうか。

 枝それぞれの正解率(以下、枝正解率)をpとすると、5枝あるので問題の正答率(以下、問正答率)はp^5になりそうです。ただしこれには二重に間違えて得点してしまう場合や、選択肢にない全部×という解答も含まれています。これらを考慮すると問正答率はp^5より少し確率は高くなりそうです。

 そんな疑問を感じたため、シミュレーションプログラムを簡単に作ってみました。

「いくつあるか問題」シミュレーション

まずは「いくつあるか問題」のシミュレーションです。以下のような流れでシミュレータが問題を作り・解答します。

  1. 5枝の問題を想定し、答えが〇の枝数をランダムで1~5の範囲で決定し、残りは×の枝として問題を作る。
  2. シミュレータが各枝を所定の枝正解率で解く(仮にシミュレータがすべての枝について×を出した場合、〇がゼロ個という選択肢は今回は解答の選択肢の中にないので、〇一つの選択肢を強制的に選択するようにしました。実際人間が解くときもそうするよね?この方法で間違えたことないっす。)
  3. 1で決定された〇の枝数とシミュレータの〇の枝数とを突き合わせて正誤を判定する
  4. 1から3を繰り返す

さて、枝正解率をどうするか、です。ここで、おもむろにBenrishi Power(以下BP)というパラメータを導入してみましょう。BPは弁理士としての知識の固さを表すパラメータとし、0~1の範囲を持たせましょう。仮にBPが0の場合は、何の知識も持ち合わせていないので、枝正解率は50パーセントとします。サイコロを転がしたのと同じです。一方BPが1であれば、どんな問題でも間違えないので、各枝正解率は100パーセントです。BPと枝正解率の関係を次のようにモデル化しました。

枝正解率p=BP/2+0.5

学習の進み具合と枝正解率がリニアな関係として良いのかどうか、という問いかけはこの際無視します。適当です。

この条件でBPを変えつつ夫々のBPごとにシミュレータに10000問ほど解いてもらいました。BPと問正答率との関係は以下のグラフの通りです。参考までに(枝正解率p)^5のグラフも入れています。

 

f:id:kolibri:20200117173433p:plain



まず、BPが0の場合はでたらめに〇×を付けるので、結果的に問題の選択肢を適当に選んだのと同じく、問正答率は0.2になります。全部×という選択肢がないケースの処理の仕方で0.2より少し大きい可能性がありますが、無視できる範囲のようです。

そしてBPが0から0.5、つまり枝正解率が0.5から0.75あたりまでは問正答率は0.4を切っています。それでもp^5の場合よりも問正答率はずいぶん高いです。これは二重に間違えて偶然正解することが多いのが原因と思われます。このあたりのBPと問正答率との関係は勉強をしてもなかなか伸び悩む時期ととらえることができます。

BPが0.6を超えたあたりから急に問正答率が上昇するのが分かります。勉強を続けていると、あるときを境に急に点が伸びだす現象はこの正答率の上昇である程度説明がつくように思います

弁理士試験の短答式試験は、60点満点中39点以上で合格になります。7割取れればOKということです。仮にすべての問題が「いくつあるか問題」だった場合は、問正答率で7割取るにはBPが0.8(枝正解率0.9)ではダメで、BPが0.84程度(枝正解率0.92程度!)必要ということになります。これはかなりキツイのではないでしょうか。

更に言うと、BP0.8位上の合否を分ける枝正解率のところでは、ほんの少しBPが変わっただけで問正答率が大きく変化します。その日の体調や問題との相性で枝正解率は微妙に変化し得るはずですが、その変化が問正答率に増幅して影響するわけです。全く気の抜けない問題です。

もっとも、弁理士試験には「いくつあるか問題」の他に「五肢択一問題」もあります。そちらもシミュレートしてみましょう。

「五肢択一問題」シミュレーション

以下のような流れでシミュレータが問題を作り・解答します。

  1. 5枝の問題を想定する。答えは〇が一つ、残りは全部×という問題を作る。
  2. シミュレータが各枝を所定の枝正解率で解く
  3. シミュレータが出した答えが〇一つの場合、ファイナルアンサーということで4に進む
    3a. シミュレータが出した答えが〇ゼロ個の場合、2に戻って全部の枝解きなおす
    3b. シミュレータが出した答えが〇二個以上の場合、その〇の枝だけ所定の枝正解率で再検討し、3に戻る
  4. 1で決定された〇の枝とシミュレータの〇の枝とを突き合わせて正誤を判定する
  5. 1から4を繰り返す

実際の五肢択一では、確信の持てる枝は◎、自信のない枝は△など、もっと全然複雑な操作をしている人も多いと思いますが、複雑なので割愛します。

このアルゴリズムで同様にシミュレートした結果が次の図です。

 

f:id:kolibri:20200117173944p:plain


「いくつあるか問題」とは異なる傾向が見えます。BPが0から0.5の間も問正答率が順調に伸びていて、0.5以降は伸びが緩やかになります。「いくつあるか問題」と逆の傾向といえるでしょう。問正答率7割を超えるにはおおむねBPが0.45程度、つまり枝正解率0.725程度でOKと読めます。「いくつあるか問題」の問正答率7割に必要なBPとはずいぶん違います

これまでは、「いくつあるか問題」も、「五肢択一問題」も、いずれの問題の枝も同じBPであれば同じ枝正解率としていました。実際には「いくつあるか問題」の枝のほうが「五肢択一問題」の枝よりも簡単に作られている肌感覚があります。現実の問題はどのような難易度調整がされているでしょうか。

現実の問題の正答率とシミュレーションとの比較

ある年度の問正答率データを引っ張ってきました。

特実20問のうち10問が「いくつあるか問題」で問正答率は平均0.496、残りの10問が「五肢択一問題」で問正答率は平均0.656でした。

シミュレーションで見ると、「五肢択一問題」で0.656程度の問正答率を得たい場合、BPは0.4程度でOKです。一方、「いくつあるか問題」で0.496程度の問正答率を得たい場合、BPは0.6を超えて0.7程度必要になります。つまり、同じBPでも、「いくつあるか問題」の方の枝正解率を「五肢択一問題」の枝正解率よりも上げないと、データとシミュレーションの整合性が取れないことになります。すなわち、現実の問題では、「いくつあるか問題」の枝のほうが、「五肢択一問題」の枝よりも簡単に作られている、という予測が立ちます。一年分のみ、更に特実のみの結果ですが、おそらくこの傾向は共通していると思われます。

(ちょっと長くなってしまったので、続きます。たぶん。。。。。。)

 

2020/1/18 細かい修正

任天堂vsコロプラの無効資料のゲームを解析してみた

ご挨拶

あけましておめでとうございます。

kolibriと申します。元家庭用ゲームのプログラマ、現在は弁理士登録していますが現状あまり弁理士っぽいことをできていない人間です(^^;

『一年の計は元旦にあり』ということで、今年はブログをやってみようと思い立ちました。知財・ゲーム・カメラ・音楽等、自分の興味のあることを細々(ほそぼそ)と綴るブログをイメージしていて、あまり高い頻度での更新はできないかと思いますが、何卒よろしくお願いいたします。

今回のネタ

さて、最初のエントリは何にしようかとネタを探していたところ、任天堂コロプラの特許訴訟を追いかけているパテントマスター・宮寺さんの以下の記事が目に留まりました。

tmiyadera.com

訴訟が提起されてからもう2年近く経過していて私はすっかりこの件を忘れていたのですが、当然というか訴訟自体は続いており、どうも今年昨年の7月になって、任天堂側の特許、通称(?)『シルエット特許』に対する無効資料コロプラから新たに追加されたようです。シルエット特許について知らない人のために補足すると、ゲーム中にキャラクタが地形オブジェクトに遮蔽されてしまった場合、遮蔽されたキャラクタのシルエットを表示することでキャラクタがどこにいるのかを視覚的にわかりやすくする特許です(ざっくり)。

宮寺さんによると、コロプラはPCゲーム「Impossible Creatures」のゲームプレイ動画等から無効を主張しているようです。↓がその動画。

www.ign.com

しかし、記事でも指摘されていますが、内部の実装次第ではシルエット特許の技術的範囲に属さない可能性は大いにあるわけで(そもそもコロプラが白猫の内部実装を変更することで外見の変更を抑えつつシルエット特許を回避しているわけでして)動画という外見のみではどうも話がスッキリしません。

プログラマとしては内部実装にムクムクと興味が湧きあがってきます。

折よくSteamのウィンターセールで「Impossible Creatures」が割引になっており、200円ちょっとだったので購入してみました。

store.steampowered.com

前置きが長くなってしまいましたが、今回のブログネタはこの「Impossible Creatures」の描画を解析し、ゲームでの実装とシルエット特許との関係を探ってみようという内容になります。

もっとも、シルエット特許の出願日は2002年4月で、「Impossible Creatures」の発売日は2003年1月と出願日より後です。更に今回はSteam経由でゲームを購入しているので、アップデートで内部実装が発売当初から変更されている可能性もわずかながらあります。新規性違反で特許を無効にしたい場合は、特許出願よりも前に発明が公知等になっていることを示す必要がありますので、いくらこのゲームを解析しようがその結果は新規性違反の無効理由を示す資料として直接的に価値があるわけではありません。

なお、私自身は任天堂ともコロプラとも利害関係はなく、ごく個人的な好奇心でやっているということを申し添えておきます。

シルエット特許のおさらい

本題に入る前に、任天堂のシルエット特許とはどういうものだったか、おさらいしてみたいと思います。

特許3637031

【請求項12】
  ゲーム空間における少なくとも地形オブジェクトおよびプレイヤキャラクタを前記ゲーム空間に配置された仮想カメラに基づいて俯瞰的に表示するゲーム装置に
  プレイヤの操作に応答して、前記ゲーム空間における前記プレイヤキャラクタおよび前記仮想カメラの位置を決定する位置決定ステップ、
  前記仮想カメラから前記地形オブジェクトまでの奥行情報をZバッファに書込みながら、前記地形オブジェクトを地形オブジェクト画像によってフレームバッファ内に描画する地形オブジェクト描画ステップ、
  前記Zバッファの奥行情報を書換えず、前記プレイヤキャラクタを第1目印画像によって前記フレームバッファ内に描画する第1目印画像描画ステップ、および
  前記Zバッファの奥行情報を参照し、かつ前記プレイヤキャラクタが前記地形オブジェクトよりも前記仮想カメラ側にあるときは前記Zバッファの奥行情報を書換えながら、前記プレイヤキャラクタをプレイヤキャラクタ画像によって前記フレームバッファ内に描画するプレイヤキャラクタ描画ステップを実行させる、ゲームプログラム。

(各ステップごとに色付けしてみました)

f:id:kolibri:20200101001410p:plain

プレイヤキャラクタの半身が地形に遮蔽されているときのゲーム画面の図(公報より引用)

請求項を分解すると、(1)位置決定ステップ(2)地形オブジェクト描画ステップ(3)第1目印画像描画ステップ(4)プレイヤキャラクタ描画ステップの4ステップからなるゲームプログラムであることが分かります。

このうち、(1)の位置決定ステップは(2)以降のステップに登場する登場人物を定義しているだけで目新しいものはないので(俯瞰的にというところは気になりつつも)(2)(3)(4)に着目してみます。

詳しく説明すると記事が無駄に長くなってしまうので実施例をザックリ説明すると、

(2)は地形オブジェクト(上図中の78)をフレームバッファに描画しつつ、地形オブジェクト78の奥行情報をZバッファに格納するという、ごくごく一般的な描画方法です。

(3)では、(2)でZバッファに書き込まれた地形オブジェクト78の奥行情報を書き換えずにプレイヤキャラクタ74のシルエット(目印画像)82をフレームバッファに描画するという特殊な描画をします。請求項では特定されていませんが、実施例では奥行情報を参照(≠書換*1)しないことで、地形とキャラクタの前後関係を無視してキャラシルエットを無理やり描画する旨言及されています(【0073】あたり)。

(4)では、(3)でキャラシルエット82を無理やり描画したわけですが、これではキャラの絵がシルエットのみですし、何より地形との前後関係が破綻していますので、改めて同じプレイヤキャラクタ74をもう一度描画します。この2回目の描画は1回目と異なり、地形オブジェクトの奥行情報が書き込まれたZバッファを参照することで、地形オブジェクトとの前後関係を考慮しつつ、プレイヤキャラクタを「通常通り」描画します。これによって、本来シルエットが表示されていてはおかしい場所については2回目の描画で上書きされて、破綻のない絵が出来上がるという寸法です。

ラクガキで各ステップを表現すると次のようになるでしょうか。

 

f:id:kolibri:20200101123620j:plain

f:id:kolibri:20200101123624j:plain

f:id:kolibri:20200101123627j:plain

f:id:kolibri:20200101123632j:plain

 

請求項で特定されている発明はシルエット表示に限っておらず、実際の権利範囲はこの実施例よりも更に広いということは留意が必要です。

一般に、キャラクタが地形に遮蔽されてプレイヤにとって見づらい、ということは結構起こり得る話で、それを解決する方法としてかなりエレガントだと思います。回避案はいくつか考えられるものの、特にモバイルの軽量なゲームで侵害しまっているのではないかと思われるような製品もあるようなないような。。。皆さん大丈夫ですかね?

「Impossible Creatures」描画解析

対象製品の描画を解析するためには、ゲーム側からグラフィックスAPIがどのように呼ばれているかを知る必要があります。このためのツールはMicrosoftのPix等いろいろとありますが、「Impossible Creatures」はDirectX 8という古いAPIで描画されているため、Pix等の最近のツールは対応していません。どうしたものかと調べていたところ、こんな素敵なツールを見つけました。

apitrace

CG野郎には有名なんでしょうか、私は知らなかったです。今回はこれでやってみます。

f:id:kolibri:20191231230142p:plain

解析対象のシーン

解析対象を上のようなシーンに決定しました。画面がなんかバグっているというか、どういうシーンなのかよくわからない、という声が聞こえてきそうです。おそらくapitrace側のバグと思われます。ソースが公開されているのでデバッグしたいところですがそんな時間は取れないのでこのままいきます

解析対象シーンの画面中央右上に謎オブジェクトが描画されていますが、これはプレイヤの陣地にある地形オブジェクトになります。キャラクタユニットがその地形オブジェクトの右側に半身隠れるような形で描画されており、地形オブジェクトに遮蔽されているキャラクタ部分が緑色のシルエット状になっているのが分かるかと思います(ホントにわかる?)

f:id:kolibri:20200101000323p:plain

キャラクタの部分を拡大

いかにもシルエット特許っぽい見た目ですが、今回の目的は肝心の内部実装がどうなっているのか?を追及することです。

先ほど説明したように、apitraceではAPIがどのように呼ばれているか、すなわち、解析対象のシーンを構築する際に各段階で「DirectXのどのAPIが」「どういうパラメータを引数として」「どういう順番で呼ばれたか」を見ることができます。

ここからはフレームの初期状態からフレームバッファが完成するまでの短い時間の中で描画が如何にして行われているか、時間軸(=APIコール順)に沿って見ていきます。

フレームの初期状態から順にAPIコールを追っていくと、このゲームではまず地形オブジェクトを先に描画していることが分かりました。

f:id:kolibri:20200101011048p:plain

先に地形オブジェクトが描画される

上のスクリーンショットでは地形オブジェクトは描かれているが、キャラクタやシルエットは表示されていないということが分かります。地形オブジェクト描画時にはもちろんZバッファへの書き込みが行われています。これはシルエット特許における(2)地形オブジェクト描画ステップに相当するものです。

更にAPIコールを進めると、キャラクタの緑のシルエットを表示しているAPIコールが見つかりました。

f:id:kolibri:20200101010846p:plain

シルエット表示のステップ

ここで注目すべきは、画面右側のCurrent StateのParametesタブの下側の「D3DRS_ZWRITEENABLE」の項目のパラメータが0になっている点です。これは、当該シルエットの書き込みの際に、Zバッファへの書き込みを禁止することを示しています(ZFUNCの説明は割愛)このステップはシルエット特許における(3)第1目印画像描画ステップに相当します。

更に進めていくと、キャラクタ描画のAPIコールが出てきました。

f:id:kolibri:20200101012329p:plain

キャラクタ描画ステップ

ここでは、ZENABLE及びZFUNCの値から、Zバッファを参照していることが分かります。更に、先ほどのD3DRS_ZWRITEENABLEが1、つまり、Zバッファ書き込みアリでキャラクタを描画していることが分かります。これはシルエット特許における(4)プレイヤキャラクタ描画ステップに相当するものです。

検討

解析の項目で見たように、シルエット特許の請求項に記載されているそれぞれのステップに相当するAPIコールがあります。また、そのAPIコールの順序はシルエット特許の請求項記載のステップの順序と一致しています。しかし些末ではありますが、(3)のステップで、プレイヤキャラクタ描画ステップで描画される場所にはシルエットが描画されていない、というシルエット特許の実施例とは少々異なる点があります。ほかにも複数細かな気になる点はあり、各ステップごとの詳細な比較検討もしたいところですが、これ以上続けると初ブログが長文になりすぎてしまうので、この辺でやめておこうと思います(力尽きたとも言う。毎日ブログ書いてる人とか凄過ぎ、、、)。

まとめ

「Impossible Creatures」の シルエット表示は、任天堂のシルエット特許と技術的な特徴が似ていた。

しかし、冒頭説明したように「Impossible Creatures」の発売日はシルエット特許の出願前ではないので、如何に似ていようとも新規性違反の無効理由とはならない。

(今回書いてる最中に思ったのですが、このシルエット特許、例えばタッチパネルを用いた新しいUIの発明などと違って、特に新しい技術を用いているわけではなく、ごくごく普通にグラフィクスAPIを使用しているだけで、課題としても作ってる側としてはよく遭遇するものなので、探せば似たような実装例が見つかるような気もしていますが、はたして。)

 

*1:実施例ではZバッファに対する参照と書換が同じような操作であるかのような記載がありますが、別の概念です。請求項でも明確に区別されています。すなわち、Zバッファに対しては①参照するし書き換える、②参照しないが書き換える、③参照するが書き換えない、④参照しないし書き換えない、という異なる4種類の操作があり得るということです。実施例では④ですが、ナイーブに考えると③も権利範囲に入るように思います。