2020-001847

第１　手続の経緯

本願は，平成２７年１０月２８日の出願であって，その後の手続の概要は，以下のとおりである。

第２　原査定の概要

原査定（令和元年１１月５日付け拒絶査定）の概要は次のとおりである。

本願請求項１～７に係る発明は，以下の引用文献１～５に基づいて，その発明の属する技術の分野における通常の知識を有する者（以下，「当業者」という。）が容易に発明できたものであるから，特許法第２９条第２項の規定により特許を受けることができない。

引用文献等一覧

１．柿元 宏晃 他，「Ｗｅｂ行動リプレイシステムに基づくＷｅｂアプリケーション動作検証システムとその応用」，２００９年度人工知能学会全国大会（第２３回）論文集，社団法人人工知能学会，２００９年６月１９日，第1頁－第4頁

２．牟田 拓，「ゼロからはじめる Microsoft Visual Basic クリッカブルマップエディタ～その４～」，Ｈｅｌｌｏ！ＰＣ５・８／５・２４，ソフトバンクパブリッシング株式会社，１９９９年５月２４日，第6巻 第8号，第196頁-第201頁

３．特開平１１－３６９１９号公報

４．特開２０００－１８１８３５号公報

５．特開平７－２１０６７号公報

第３　本願発明

本願請求項１～７に係る発明（以下，それぞれ「本願発明１」～「本願発明７」という。）は，令和元年６月３日付けの手続補正で補正された特許請求の範囲の請求項１－７に記載された事項により特定される発明であり，本願発明１は以下のとおりの発明である。

「　【請求項１】

表示されたオブジェクトに対する操作記録情報を記録し，記録した前記操作記録情報に従った操作を発生させる処理をコンピュータに実行させる操作記録再生プログラムであって，

前記操作記録情報に記録する前記操作の種類が操作の対象オブジェクトに対する移動操作の場合，前記操作の種類を示す操作種類情報と，前記操作の対象オブジェクト内の操作位置を示す相対位置情報と，移動元の表示領域情報と，移動先の位置情報と，移動先の表示領域情報と，を対応付けて前記操作記録情報に記録し，

前記操作記録情報に含まれる前記操作種類情報が移動操作を示す場合，前記操作記録情報に記録した前記移動元の表示領域情報と，前記移動先の表示領域情報と，前記相対位置情報と，前記移動先の位置情報と，に基づき，前記移動先の表示領域情報に対して前記対象オブジェクトの移動先の位置を補正し，補正した前記位置に前記対象オブジェクトを移動する操作を発生させる，操作記録再生プログラム。」

なお，本願発明２－７の概要は以下のとおりである。

本願発明２は，本願発明１を操作再生プログラムの発明としたものである。

本願発明３及び４は，それぞれ本願発明１に対応するシステム及び方法の発明であり，本願発明１とカテゴリ表現が異なるだけの発明である。

本願発明５～７は，本願発明１，３，４をさらに減縮した発明である。

第４　引用文献，引用発明等１．引用文献１について

原査定の拒絶の理由に引用された上記引用文献１には，図面とともに次の事項が記載されている。

（当審注：下線は，参考のために当審で付与したものである。）

「２． Ｗｅｂ行動リプレイシステム

Ｗｅｂブラウジング時のユーザの行動を記録し，ユーザの行動を再現するシステムをＷｅｂ行動リプレイシステムと呼ぶ．本システムは，ユーザのマウスの動きも再生可能である．」（第１頁右欄１～４行）

「３．１　関連システム

本手法のように，Ｗｅｂ行動リプレイシステムに基づいて，行動の記録・再現を行うシステムの一つに，デスクトップアプリケーションのロギングツールがある．イベントの発生した位置をＯＳから取得し，記録・再現を行うというアプローチである．Ｗｅｂ上ではレイアウト上部オブジェクトがレイアウト下部のオブジェクトを押し出すという表示規則があるため，サイズが表示ごとに不定のオブジェクト（広告など）や，インターフェースの部分的な変更によって下位のオブジェクトの位置も不定になることがある．取得したイベント発生位置を絶対位置として取得している場合では，イベントの再現時にオブジェクトの位置とイベント発生位置のずれが生じ，正確に再現することができない点が課題である．

また，Ｗｅｂ上のシステムによってイベントの記録を行っている既存のシステムも存在する．これらのシステムではリンクやボタンなど，粒度の粗い行動のみに絞ってイベントの監視を行い，それらに発生したイベント列を命令セットとして記録している．Ｗｅｂ技術が発展した現在のＷｅｂアプリケーションでは，マウスカーソルの軌跡，ｍｏｕｓｅｄｏｗｎ， ｍｏｕｓｅｕｐに連動するアクション（オブジェクトのドラッグ＆ドロップや軌跡による描画など）やｍｏｕｓｅｏｖｅｒに連動するアクション（プルダウンメニューなど）が使われているものがある．既存のシステムのように，リンクやボタンによって発生するイベントを監視するだけでは，これら複雑なアクションを記録することはできないという課題がある．」（第２頁左欄下から７行～同頁右欄１９行）

「３．２　ユーザの環境に影響を受けにくいイベント発生座標の取得

本手法では，Ｗｅｂ上で動作するシステムによってイベントの記録し，ＤＯＭ構造に基づく行動情報の取得を行うため，オブジェクト位置の変動や，ユーザの環境による影響に柔軟に対応することが可能である．

Ｗｅｂページ上でマウスカーソルによるイベントが発生した場合，Ｗｅｂページの左上を基準とした座標としてイベントの発生位置を取得する．本研究ではこの座標をイベント絶対座標と呼ぶ．得られた座標情報をそのまま再現時に利用した場合，前述のようにサイズの可変なオブジェクトに対応することができなくなる．

そこで，イベント絶対座標を，イベントが発生した座標直下のオブジェクトを基準として表現する（図２）．イベントの絶対座標直下のオブジェクトをイベント直下オブジェクト，イベント直下オブジェクトの左上座標とイベントの絶対座標との差をイベント相対座標と呼ぶ．イベント絶対座標は，イベント直下オブジェクトの左上座標とイベント相対座標の和で表すことができる．本手法ではイベント直下オブジェクトの位置を座標の代わりにＸＰａｔｈで表現する．この表現により，再現時に可変長のオブジェクトによってイベント直下オブジェクトの位置が変動した場合でも，ＸＰａｔｈに変更がなければ，取得時と同様に再現することが可能になる．」（第２頁右欄２０行～第３頁左欄２行）

「図２

」（第３頁）

「３．４　テストケースの生成

本手法では，相対的な位置関係でイベントを発生させるための命令セットを，「イベント発生時間」「イベントタイプ」「イベント直下オブジェクトのパス」「イベント相対座標」から生成する．イベントを発生させる位置は命令セットの実行時にリアルタイムに決定する．前述のように，命令セットを実行する環境ごとにウィンドウサイズ，オブジェクトの表示位置に誤差が生じるため，実行時にリアルタイムに計算を行うことで，正確なイベント発生位置を決定することができる．そのため，生成する命令セットは，時系列に並んだ命令群だけでなく，命令セットの実行時にイベント直下オブジェクトのパスから座標を計算する関数を含んだものとなる．図３は，命令群を時系列に並べた命令セットの一部であり，オブジェクトのドラッグ＆ドロップを行った場合のものである．ＭＡｒｅｐ．ｍｏｕｓｅｍｏｖｅ，ＭＡｒｅｐ．ｍｏｕｓｅｏｖｅｒ，ＭＡｒｅｐ．ｍｏｕｓｅｄｏｗｎ，ＭＡｒｅｐ．ｍｏｕｓｅｕｐはそれぞれ，ｍｏｕｓｅｍｏｖｅ，ｍｏｕｓｅｏｖｅｒ，ｍｏｕｓｅｄｏｗｎ，ｍｏｕｓｅｕｐイベントを発生させる関数である．ＭＡｔｒａｃｅ．ｏｂｊはイベントの発生した位置直下のオブジェクトのパスを，イベント発生順に格納している．ＭＡｔｒａｃｅ．ｐｏｓはイベントの発生位置を，その直下のオブジェクトからの相対位置として格納している．ＭＡｒｅｐ．ｔｉｍｅはイベント間の遅延を発生させる関数である．ＭＡｔｒａｃｅ．ｔｉｍｅはイベント間の時間を格納した変数であり，ＭＡｒｅｐ．ｔｉｍｅへの入力として与えられる．

再現時のイベント絶対位置は，イベント直下オブジェクトのパス（ＭＡｔｒａｃｅ．ｏｂｉ）から計算した座標とイベント相対座標（ＭＡｔｒａｃｅ．ｐｏｓ）の和によって計算できる．この計算を時系列に沿ってイベントごとに行うことで，オブジェクトサイズの変更にも柔軟に対応し，Ｃａｐｕｔｕｒｅ時と同様の行動を再現できる．」（第３頁左欄下から６行～同頁右欄２２行）

引用文献１のＷｅｂ行動リプレイシステムの処理は，コンピュータにプログラムを実行させることによって実現されていることは明らかであるから，引用文献１には，「Ｗｅｂ行動リプレイシステムの処理をコンピュータに実行させるプログラム」が記載されていると認められる。

したがって，上記引用文献１には次の発明（以下，「引用発明」という。）が記載されていると認められる。

（引用発明）

Ｗｅｂブラウジング時のユーザの行動を記録し，ユーザの行動を再現するＷｅｂ行動リプレイシステムの処理をコンピュータに実行させるプログラムであって，

ユーザのマウスの動きも再生可能であり，

Ｗｅｂページ上でマウスカーソルによるイベントが発生した場合，Ｗｅｂページの左上を基準としたイベントの発生位置の座標をイベント絶対座標と呼び，

イベント絶対座標を，イベントが発生した座標直下のオブジェクトを基準として表現し，

イベントの絶対座標直下のオブジェクトをイベント直下オブジェクト，イベント直下オブジェクトの左上座標とイベントの絶対座標との差をイベント相対座標と呼び，

イベント絶対座標は，イベント直下オブジェクトの左上座標とイベント相対座標の和で表すことができ，

イベント直下オブジェクトの位置を座標の代わりにＸＰａｔｈで表現し，

この表現により，再現時に可変長のオブジェクトによってイベント直下オブジェクトの位置が変動した場合でも，ＸＰａｔｈに変更がなければ，取得時と同様に再現することが可能になり，

相対的な位置関係でイベントを発生させるための命令セットを，「イベント発生時間」「イベントタイプ」「イベント直下オブジェクトのパス」「イベント相対座標」から生成し，

イベントを発生させる位置は命令セットの実行時にリアルタイムに決定し，

実行時にリアルタイムに計算を行うことで，正確なイベント発生位置を決定することができ，

そのため，生成する命令セットは，時系列に並んだ命令群だけでなく，命令セットの実行時にイベント直下オブジェクトのパスから座標を計算する関数を含んだものとなり，

オブジェクトのドラッグ＆ドロップを行った場合の命令群を時系列に並べた命令セットの一部であるＭＡｒｅｐ．ｍｏｕｓｅｍｏｖｅ，ＭＡｒｅｐ．ｍｏｕｓｅｏｖｅｒ，ＭＡｒｅｐ．ｍｏｕｓｅｄｏｗｎ，ＭＡｒｅｐ．ｍｏｕｓｅｕｐはそれぞれ，ｍｏｕｓｅｍｏｖｅ，ｍｏｕｓｅｏｖｅｒ，ｍｏｕｓｅｄｏｗｎ，ｍｏｕｓｅｕｐイベントを発生させる関数であり，

ＭＡｔｒａｃｅ．ｏｂｊはイベントの発生した位置直下のオブジェクトのパスを，イベント発生順に格納しており，

ＭＡｔｒａｃｅ．ｐｏｓはイベントの発生位置を，その直下のオブジェクトからの相対位置として格納しており，

ＭＡｒｅｐ．ｔｉｍｅはイベント間の遅延を発生させる関数であり，

ＭＡｔｒａｃｅ．ｔｉｍｅはイベント間の時間を格納した変数であり，ＭＡｒｅｐ．ｔｉｍｅへの入力として与えられ，

再現時のイベント絶対位置は，イベント直下オブジェクトのパス（ＭＡｔｒａｃｅ．ｏｂｉ）から計算した座標とイベント相対座標（ＭＡｔｒａｃｅ．ｐｏｓ）の和によって計算でき，この計算を時系列に沿ってイベントごとに行うことで，オブジェクトサイズの変更にも柔軟に対応し，Ｃａｐｕｔｕｒｅ時と同様の行動を再現できる

プログラム。

２．引用文献２について

原査定の拒絶の理由に引用された上記引用文献２には，図面とともに次の事項が記載されている。

「領域を移動する

前回紹介したサイズ変更を応用すれば，領域を移動させるのは難しくありません。左辺，上辺を移動させるときの処理からＷｉｄｔｈ，Ｈｅｉｇｈｔプロパティを変更している部分を取り去り，ちょっとした補正を加えたものを使えばいいだけだからです。実用一点張りの連載ならそうするところなのですが，これはＶｉｓｕａｌＢａｓｉｃの入門なのですから，別の手を使ってみることにします。サイズ変更を応用する方法は難しくありませんので，みなさんへの課題としておきましょう。

今回紹介する別の方法は，ドラッグ＆ドロップを使う方法です。フォームのデザイン時には，フォーム上に配置したコントロールの上でマウスの左ボタンを押しそのままマウスを動かす（ドラッグ）することで，簡単にコントロールを動かすことができます。これと同じ機能をプログラムの実行時にも使えるようにしようというわけです。

フォームに貼り付けたコントロールが実行時に動かせないのは，そのコントロールのＤｒａｇＭｏｄｅプロパティが，

続きを表示（全32行）

となっているからです。手動とは，「ドラック処理をやりたいなら自分でプロタラムを作りなさい」という意味です。これを，

とすれば，配置したコントロールは実行中でも動かすことができるようになります。試しにＦｏｒｍ１の中にボタン（Ｃｏｍｍａｎｄ１）を作り，そのＤｒａｇＭｏｄｅプロパティを［自動］に設定し，プログラムを実行してみてください。ボタンをドラッグすると，図１のようにマウスポインタにボタンの“影”がくっついて移動するようになります。

もっとも，これでは単に動かせるようになっただけで，マウスのボタンを離すと（ドロップすると）影は消えてしまいます。理由は簡単。ドラッグ処理は“自動”で行われるようになりましたが，ドロップ処理は自動では行われないからです。

では，ドロップ処理はどうすればいいのでしょうか。何かがドロップされるとＶｉｓｕａｌ ＢａｓｉｃはＤｒａｇＤｒｏｐというイベントを発生させます。もしＰｉｃｔｕｒｅ１でＤｒａｇＤｒｏｐイベントが発生したときを捉えてドロップ処理をしたいなら，Ｐｉｃｔｕｒｅ１＿ＤｒａｇＤｒｏｐというプロシージャを作って処理を書けばいいわけです。

ＤｒａｇＤｒｏｐプロシージャは，

という３つの仮引数をとります。何がドロップされたのかをＳｏｕｒｃｅで示し，どこにドロップされたのかを（Ｘ，Ｙ）という座標で表すわけです。したがって，

とプログラムすれば，ドロップされたものをドロップされた座標に移動することができます。Ｓｏｕｒｃｅは仮引数宣言からもわかるように（各種）コントロールを表すオブジェクト変数ですから，各コントロールに用意されているＭｏｖｅメソッドを使ってコントロールを動かすわけです。これが今回作成するドラッグ＆ドロップの骨子です。

骨子と断ったのは，この方法では狙ったとおりの場所ヘコントロールを動かすことができないからです（実際に上のプログラムを入力して動かしてみるとわかります）。理由は，

にあります。Ｘ，Ｙは，ドロップが行われたコントロール（この場合はＰｉｃｔｕｒｅ１）での，ドロップされた座標を表しています。すなわちこれは，ドロップ時のＰｉｃｔｕｒｅ１におけるマウスポインタの座標なのです。－方Ｍｏｖｅメソッドは，コントロールの左上隅の座標が，指定された座標になるようにコントロールを動かします。つまりこのプログラムでは，コントロール内のどこでマウスの左ボタンを押してドラッグを開始しようが，ドロップしたときには常にマウスポインタの位置がコントロールの左上隅になってしまうわけです。

これを解決するには，ドラッグ開始時に「コントロールのどこでマウスの左ボタンが押されたのか」をチェックし，ドロップ時にその分を補正する必要があります。［自動］でドラッグ開始されたのでは補正分を得ることができませんから，補正するにはＤｒａｇＭｏｄｅプロパティを［０-手動］に戻し，プログラム内でドラッグを開始させる必要があります。

プログラム内でドラッグを開始させるには，ドラッグを開始させたいコントロールのＤｒａｇメソッドを使います。

とすれば，Ｃｏｍｍａｎｄ１がドラッグ中となるわけです。これでコントロール移動に必要な知識は揃いました。早速プログラムしてみることにしましょう。

領域移動のプログラム

リスト１は，上の考え方にしたがって作成した，領域移動のプログラムです。

Ｌａｂｅｌ１＿ＭｏｕｓｅＤｏｗｎプロシージャは，Ｌａｂｅｌ１でマウスのボタンが押されたときに呼び出されるプロシージャで，マウスポインタの形から，マウスのボタンが押されたとき何をすればいいのか判断してそれぞれの処理をしています。領域のサイズ変更部分は前回作りましたから，今回はドラッグ開始処理を付け加えます。ドラッグ開始は，マウスポインタが上下左右矢印のときとします。追加した行は行末に「’＊＊」を，削除する行は行頭に「’＊＊」を付加してあります。仮引数が２行に分けて書いてあるのは掲載の都合ですので，みなさんは一行のままにしておいて構いません。

追加部分ではまず，あとで補正できるように現在のマウスの位置をｄｓＸ，ｄｓＹという大域変数に保存しています（大域変数ｄｓＸ，ｄｓＹは，全プログラムの先頭に入力してください）。ここで保存しているＸ，ＹはＬａｂｅｌ１の内部座標で，Ｌａｂｅｌ１の左上隅から何Ｔｗｉｐｓのところでマウスのボタンが押されたかを表しているのだということを思い出しておいてください。あとで再び登場します。ちなみにｄｓＸ，ｄｓＹは，ドラッグ（Ｄｒａｇ）スタート（Ｓｔａｒｔ）時のＸ座標，Ｙ座標という意味で命名しました。

ｄｓＸ，ｄｓＹにドラッグ開始時のマウス位置を保存できたら，Ｄｒａｇメソッドを使ってＬａｂｅｌ１のドラッグ動作をスタートさせます。サイズ変更のときにはＳｈａｐｅ１のサイズを変更してからＬａｂｅｌ１をそれに合わせましたが，Ｓｈａｐｅコントロールはドラッグ＆ドロップすることができませんので，移動ではＬａｂｅｌ１をドラッグ＆ドロップしてから新しい位置にＳｈａｐｅ１を移動させます。

これでドラッグが開始されましたから，次にドロップ時のプログラムを作ります。Ｐｉｃｔｕｒｅ１＿ＤｒａｇＤｒｏｐです。こちらではｎｅｗｘ，ｎｅｗｙという２つの変数に補正込みの新しい移動先を算出し，そこにＳｏｕｒｃｅをＭｏｖｅします。先ほど実験したように，ドロップされた座標（Ｘ，Ｙ）にコントロールを動かすとそこがコントロールの左上隅になってしまいますから，ドラッグ前にコントロールでマウスのボタンが押されたときの差分ｄｓＸ，ｄｓＹをその座標から引いてやればＯＫです（図２参照）。

このとき気を付けなければならないのが，ｄｓＸ，ｄｓＹはＴｗｉｐｓ単位であるのに対し，Ｌａｂｅｌ１の移動先の座標であるＸ，Ｙは（ズーム処理の関係で）ｖｂＵｓｅｒ単位になっているということです。単純に，

とやったのでは，正しい移動先は求まりません。前回使ったＰｉｃｔｕｒｅ１．ＳｃａｌｅＸメソッドを使い，ｄｓＸの単位をＴｗｉｐｓからｖｂＵｓｅｒへ変換してやる必要があります（Ｙ座標に関しても同じです）。

座標が求まったら，そこへＳｏｕｒｃｅ（すなわちＬａｂｅｌ１）を移動させ，続いてＳｈａｐｅ１のほうもここに移動させます。Ｌａｂｅｌ１とＳｈａｐｅ１はいずれも配列ですが，１つの領域は同じインデックスのＬａｂｅｌ１とＳｈａｐｅ１の組み合わせで表現していますので，ドロップされたＳｏｕｒｃｅ（すなわちＬａｂｅｌ１）のｌｎｄｅｘをそのままＳｈａｐｅ１のインデックスとすれば，対応するＳｈａｐｅ１となります。

Ｓｈａｐｅ１の移動が終わったら，Ｌａｂｅｌ１＿ＭｏｕｓｅＤｏｗｎプロシージャの冒頭で無効にしておいたＬａｂｅｌ１を再び生き返らせます。この処理は前回作成したＬａｂｅｌ１＿ＭｏｕｓｅＵｐプロシージャで行っているのですが，ドラッグ＆ドロップ時にはＬａｂｅｌ１でＭｏｕｓｅＵｐイベントが発生しません。こちらで生き返らせる必要があります。最後に，ドロップ後の領域の座標を自作のｍａｋｅＣｏｏｒｄｓ関数で得て，それをリストビューコントロール（ＬｉｓｔＶｉｅｗ１）の該当行にセットしてドロップ作業は終了です。

といきたいところなのですが，１つ見落としがあります。ここまでのプログラムを入力したら，試しに実行し，領域を移動させてみてください。大きく移動させた際にはちゃんと移動しますが，少ししか移動させない場合には動きません。ドロップ時にマウスポインタの位置をよくチェックしているとわかるのですが，ドロップ先がＰｉｃｔｕｒｅ１ではなく自分自身（Ｌａｂｅｌ１）になっているからです。これに対応するには，Ｌａｂｅｌ１にドロップされたときの処理を付け加える必要があります。それがリスト２になります。

Ｌａｂｅｌ１＿ＤｒａｇＤｒｏｐプロシージャのプログラムは，先のＰｉｃｔｕｒｅ１＿ＤｒａｇＤｒｏｐとほとんど変わりません。ｎｅｗｘ，ｎｅｗｙの算出方法が違うだけです。Ｌａｂｅｌ１＿ＤｒａｇＤｒｏｐの仮引数Ｘ，Ｙは，Ｌａｂｅｌ１の中のどこにドロップされたのかを表していることに注意しましょう。Ｘ，ＹはＬａｂｅｌ１の内部座標（単位はＴｗｉｐｓ）です（図３）。

これを押さえておけば，ドラッグ開始位置からドロップ位置までの移動距離（Ｘ軸方向）は，

で求まることは簡単にわかるでしょう（単位はＴｗｉｐｓ）。あとは，ＳｏｕｒｃｅのＬｅｆｔプロパティとＴｏｐプロパティに動いた距離を加えれば，新しい座標が求まります。ただし，ＳｏｕｒｃｅはＰｉｃｔｕｒｅ１に配置してありますので，そのＬｅｆｔ，ＴｏｐプロパティはｖｂＵｓｅｒ単位になっている点，新しい座標もｖｂＵｓｅｒ単位しなければならない点に注意が必要です。移動距離をＴｗｉｐｓからｖｂＵｓｅｒに変換してから，ＬｅｆｔプロパティやＴｏｐプロパティに加えればＯＫです。

先にＬａｂｅｌ１＿ＭｏｕｓｅＤｏｗｎプロシージャで，移動やサイズ変更に関係のないＬａｂｅｌ１はすべて無効にしておいたのは，このドロップ処理のことを考えたからです。他のＬａｂｅｌ１が生きていると，自分自身へのドラッグ＆ドロップ以外のケースも考えなければならなくなります。移動距離の計算も，簡単に，

では済まなくなり，ちょっと面倒そうです。そこまで考えたところで頭がごちゃごちゃになりそうだったので，関係のないものには消えてもらうことにしたというのが本音です。」（第１９６頁左欄１０行～第１９９頁左欄９行）

「図２

」（第１９８頁）

したがって，上記引用文献２には，「コントロール内のどこでマウスを使用してドラッグを開始しようが，ドロップしたときには常にマウスポインタの位置がコントロールの左上隅になってしまうことを課題とし，ドロップされた座標（Ｘ，Ｙ）にコントロールを動かすとそこがコントロールの左上隅になってしまうことを回避するために，ドラッグ前にコントロールでマウスのボタンが押されたときの差分ｄｓＸ，ｄｓＹを，ドロップされた座標（Ｘ，Ｙ）から引き，位置を補正する手法」が記載されていると認められる。

３．引用文献３について

原査定の拒絶の理由に引用された上記引用文献３には，図面とともに次の事項が記載されている。

「【００２４】前記コントローラ１４には，エアフローメータ１の検出した吸入空気量信号，スロットルバルブ開度センサ２の検出したスロットル開度信号，クランク角センサ５の検出したクランク角信号，エンジン冷却水温センサ６の検出した冷却水温信号，触媒温度センサ８からの温度信号，排気センサ９などからの排気酸素濃度信号などが入力し，これらに基づいて，運転状態に応じてリーン燃焼とストイキ燃焼を行うように燃料噴射量，噴射時期を制御し，また機関低温時の部分負荷域など触媒７の早期活性化のために燃料噴射を吸気行程と圧縮行程の２回に分けて行い，かつこのときの全体的な空燃比が空気過剰率λ＝１．１程度となるように燃料供給量を制御する。」

４．引用文献４について

原査定の拒絶の理由に引用された上記引用文献４には，図面とともに次の事項が記載されている。

「【００７７】かかる動作において，画面範囲選択部２１３は，マウスポインタの移動が検出されたことに応答して，現在のマウスポインタの位置で最も手前にあるアプリケーションのビジブルなウインドウサイズと位置をウインドウ・システムに問い合わせ，ウインドウ枠に対応した矩形を表示させる。このウインドウ枠に対応した矩形はデスクトップ上に直接描画することもできるが，透明ウインドウを生成し，その透明ウインドウ上に描画することもできる。その後，マウスの右ボタンが押されたことが検出されたことに応答して，現在のマウスポインタの位置で最も手前にあるアプリケーションのウインドウを前面に表示させ，またウインドウ枠に対応した矩形を強調表示させる。」

５．引用文献５について

原査定の拒絶の理由に引用された上記引用文献５には，図面とともに次の事項が記載されている。

「【００２８】図１３に，削除内容の確認処理（図９の２０９）の詳細を示す。図１に示す削除内容確認キー（２０）が押されながらマウスがクリックされると，処理を開始する（３３１）。まず，前記復元処理の図１１の処理３１２におけるアイコンの特定方法と同様に，マウス位置からアイコンを特定し，削除内容記憶部を特定する（３３２）。次に，ウインドウ画面を開き（３３３），前記特定された削除内容記憶部に格納された削除内容情報に基づき，削除内容をウインドウ内に表示する（３３４）。次に，ウインドウ画面を閉じる（３３５）。この契機は，マウスクリックなどのユーザー操作か，前記削除内容確認キー（２０）が押されてから一定時間後などとすれば良い。そして終了する（３３６）。」

第５　対比・判断

１．本願発明１について

（１）対比

本願発明１と引用発明とを対比すると，次のことがいえる。

ア　引用発明の「Ｗｅｂ行動リプレイシステム」は，「Ｗｅｂブラウジング時のユーザの行動を記録し，ユーザの行動を再現する」ものであって「ユーザのマウスの動きも再生可能であり」，ユーザの行動である，「オブジェクトのドラッグ＆ドロップ」を再現することも可能であるところ，引用発明の「オブジェクトのドラッグ＆ドロップ」の“操作”は本願発明１の「表示されたオブジェクトに対する操作」に相当し，また，引用発明において「記録」される「ユーザの行動」である「オブジェクトのドラッグ＆ドロップ」の“操作”に関する“情報”は，本願発明１の「操作記録情報」に相当するから，引用発明の「Ｗｅｂブラウジング時のユーザの行動」である「オブジェクトのドラッグ＆ドロップ」の“操作”に関する“情報”を「記録し」，「ユーザの行動を再現するＷｅｂ行動リプレイシステム」の処理をコンピュータに実行させる「プログラム」は，本願発明１の「表示されたオブジェクトに対する操作記録情報を記録し，記録した前記操作記録情報に従った操作を発生させる処理をコンピュータに実行させる操作記録再生プログラム」に相当する。

イ　引用発明において，「オブジェクトのドラッグ＆ドロップを行った場合」，「ＭＡｔｒａｃｅ．ｏｂｊ」として，「イベントの発生した位置直下のオブジェクトのパスを，イベント発生順に格納し」，「ＭＡｔｒａｃｅ．ｐｏｓ」として，「イベントの発生位置を，その直下のオブジェクトからの相対位置として格納し」，「ＭＡｔｒａｃｅ．ｔｉｍｅ」として，「イベント間の時間を格納し」ているところ，引用発明の「オブジェクトのドラッグ＆ドロップ」の“操作”は，本願発明１の「操作の対象オブジェクトに対する移動操作」に相当するから，引用発明の「オブジェクトのドラッグ＆ドロップを行った場合」が本願発明１の「前記操作記録情報に記録する前記操作の種類が操作の対象オブジェクトに対する移動操作の場合」に相当する。

また，「オブジェクトのドラッグ＆ドロップを行った場合」に，「イベントの発生位置」が「その直下のオブジェクトからの相対位置として」格納される「ＭＡｔｒａｃｅ．ｐｏｓ」は，ドラッグ＆ドロップの操作におけるドラッグ時に発生する「ｍｏｕｓｅｄｏｗｎ」イベント，及びドロップ時に発生する「ｍｏｕｓｅｕｐ」イベントのそれぞれにおいて，「イベントの発生位置」が「その直下のオブジェクトからの相対位置として」格納されるものと認められることから，引用発明の「ＭＡｔｒａｃｅ．ｐｏｓ」のうち，ドラッグ時に発生する「ｍｏｕｓｅｄｏｗｎ」イベントの「発生位置」が本願発明１の「前記操作の対象オブジェクト内の操作位置を示す相対位置情報」に相当し，また，ドロップ時に発生する「ｍｏｕｓｅｕｐ」イベントの「発生位置」が本願発明１の「移動先の位置情報」に相当する。

また，引用発明では，「ユーザの行動を再現する」際の「相対的な位置関係でイベントを発生させるための命令セット」は，『「イベント発生時間」「イベントタイプ」「イベント直下オブジェクトのパス」「イベント相対座標」から生成』されるものであるところ，引用発明の「イベントタイプ」は，本願発明１の「操作の種類を示す操作種類情報」に相当し，また，上記で検討したとおり，引用発明の「イベント相対座標」は，本願発明１の「前記操作の対象オブジェクト内の操作位置を示す相対位置情報」及び「移動先の位置情報」に相当するものであり，これら「イベントタイプ」及び「イベント相対座標」が“対応付けて”記録されていることは明らかである。

以上のことから，引用発明と本願発明１とは，後記する点で相違するものの，“前記操作記録情報に記録する前記操作の種類が操作の対象オブジェクトに対する移動操作の場合，前記操作の種類を示す操作種類情報と，前記操作の対象オブジェクト内の操作位置を示す相対位置情報と，移動先の位置情報と，を対応付けて前記操作記録情報に記録し”ている点で共通する。

ウ　引用発明では，「再現時のイベント絶対位置」は，「イベント直下オブジェクトのパス（ＭＡｔｒａｃｅ．ｏｂｉ）から計算した座標とイベント相対座標（ＭＡｔｒａｃｅ．ｐｏｓ）の和によって計算でき，この計算を時系列に沿ってイベントごとに行うことで，オブジェクトサイズの変更にも柔軟に対応し，Ｃａｐｕｔｕｒｅ時と同様の行動を再現できる」ものであるから，引用発明において，ユーザの「ドラッグ＆ドロップ」操作を再現する際には，ドラッグ時に発生する「ｍｏｕｓｅｄｏｗｎ」イベントの「発生位置」（本願発明１における「前記相対位置情報」に相当する。）及びドロップ時に発生する「ｍｏｕｓｅｕｐ」イベントの「発生位置」（本願発明１における「前記移動先の位置情報」に相当する。）に“基づいて”，“オブジェクトを移動する操作を発生させ”ていることは明らかである。

また，引用発明において，「ユーザの行動」として「オブジェクトのドラッグ＆ドロップ」を「再現する」“場合”が，本願発明における「前記操作記録情報に含まれる前記操作種類情報が移動操作を示す場合」に相当する。

してみれば，引用発明と本願発明１とは，後記する点で相違するものの“前記操作記録情報に含まれる前記操作種類情報が移動操作を示す場合，前記操作記録情報に記録した前記相対位置情報と，前記移動先の位置情報と，に基づき，前記対象オブジェクトを移動する操作を発生させる”点で共通する。

したがって，本願発明１と引用発明との間には，次の一致点，相違点があるといえる。

（一致点）

「表示されたオブジェクトに対する操作記録情報を記録し，記録した前記操作記録情報に従った操作を発生させる処理をコンピュータに実行させる操作記録再生プログラムであって，

前記操作記録情報に記録する前記操作の種類が操作の対象オブジェクトに対する移動操作の場合，前記操作の種類を示す操作種類情報と，前記操作の対象オブジェクト内の操作位置を示す相対位置情報と，移動先の位置情報と，を対応付けて前記操作記録情報に記録し，

前記操作記録情報に含まれる前記操作種類情報が移動操作を示す場合，前記操作記録情報に記録した前記相対位置情報と，前記移動先の位置情報と，に基づき，前記対象オブジェクトを移動する操作を発生させる，操作記録再生プログラム。」

（相違点）

（相違点１）操作記録情報に記録する情報として，本願発明１は，「移動元の表示領域情報」と，「移動先の表示領域情報」を記録しているのに対して，引用発明は，そのような情報を記録することは記載されていない点。

（相違点２）本願発明１では，前記操作記録情報に含まれる前記操作種類情報が移動操作を示す場合，前記操作記録情報に記録した相対位置情報と，移動先の位置情報とに加えて，「前記移動元の表示領域情報」と，「前記移動先の表示領域情報」とに基づき，「前記移動先の表示領域情報に対して前記対象オブジェクトの移動先の位置を補正し」，「補正した前記位置に」前記対象オブジェクトを移動する操作を発生させるのに対して，引用発明は，操作記録情報に記録した相対位置情報と，移動先の位置情報とに基づいて，対象オブジェクトを移動する操作を発生させているものの，「相対位置情報」と，「移動先の位置情報」に加えて，「移動元の表示領域情報」と「移動先の表示領域情報」とに基づいて，「前記移動先の表示領域情報に対して前記対象オブジェクトの移動先の位置を補正し」，「補正した前記位置に」対象オブジェクトを移動する操作を発生させるものではない点。

（２）相違点についての判断

事案に鑑み，上記相違点１及び相違点２についてまとめて検討する。

上記第４，１．の「３．１　関連システム」の記載を参照すると，引用発明は，「Ｗｅｂ上ではレイアウト上部オブジェクトがレイアウト下部のオブジェクトを押し出すという表示規則があるため，サイズが表示ごとに不定のオブジェクト（広告など）や，インターフェースの部分的な変更によって下位のオブジェクトの位置も不定になることがあ」り，「取得したイベント発生位置を絶対位置として取得している場合では，イベントの再現時にオブジェクトの位置とイベント発生位置のずれが生じ，正確に再現することができない」という課題や，「Ｗｅｂ技術が発展した現在のＷｅｂアプリケーションでは，マウスカーソルの軌跡，ｍｏｕｓｅｄｏｗｎ，ｍｏｕｓｅｕｐに連動するアクション（オブジェクトのドラッグ＆ドロップや軌跡による描画など）やｍｏｕｓｅｏｖｅｒに連動するアクション（プルダウンメニューなど）が使われているものがある」ところ，「既存のシステムのように，リンクやボタンによって発生するイベントを監視するだけでは，これら複雑なアクションを記録することはできない」という課題を解決するためになされたものであり，具体的には，「イベントの発生した位置直下のオブジェクトのパスを，イベント発生順に格納し」た「ＭＡｔｒａｃｅ．ｏｂｊ」や，「イベントの発生位置を，その直下のオブジェクトからの相対位置として格納し」た「ＭＡｔｒａｃｅ．ｐｏｓ」，「イベント間の遅延を発生させる関数」である「ＭＡｒｅｐ．ｔｉｍｅ」，「イベント間の時間を格納した変数であり，ＭＡｒｅｐ．ｔｉｍｅへの入力として与えられ」る「ＭＡｔｒａｃｅ．ｔｉｍｅ」などの情報を格納しておき，「再現時のイベント絶対位置」を「イベント直下オブジェクトのパス（ＭＡｔｒａｃｅ．ｏｂｉ）から計算した座標とイベント相対座標（ＭＡｔｒａｃｅ．ｐｏｓ）の和によって計算」し，「この計算を時系列に沿ってイベントごとに行うことで，オブジェクトサイズの変更にも柔軟に対応し，Ｃａｐｕｔｕｒｅ時と同様の行動を再現できる」ようにしたものであると認められるところ，当該引用発明において，上記課題を解決するために，行動の記録時に「移動元の表示領域情報」や「移動先の表示領域情報」を記録しておき，行動の再現時に，これらの情報も併せて利用して，「前記移動先の表示領域情報に対して前記対象オブジェクトの移動先の位置を補正」することについては，何らの記載も示唆もなく，また，行動リプレイシステムにおける行動の記録時に「移動元の表示領域情報」や「移動先の表示領域情報」を記録しておき，行動の再現時に，これらの情報も併せて利用して，「前記移動先の表示領域情報に対して前記対象オブジェクトの移動先の位置を補正」することは，上記引用文献２～５にも記載されていないことから，これを，本願出願時の当該技術分野における周知技術であったということもできない。

してみれば，当業者といえども，引用発明及び引用文献２～５に記載された技術的事項から，相違点１及び相違点２に係る本願発明１の構成を容易に想到することはできない。

したがって，本願発明１は，当業者であっても，引用発明及び引用文献２～５に記載された技術的事項に基づいて容易に発明できたものとはいえない。

２．本願発明２について

本願発明２は，本願発明１を操作再生プログラムの発明としたものであり，本願発明１の上記相違点１及び相違点２に係る構成を備えるものであるから，本願発明１と同じ理由により，当業者であっても，引用発明及び引用文献２～５に記載された技術的事項に基づいて容易に発明できたものとはいえない。

３．本願発明３及び４について

本願発明３及び４は，それぞれ本願発明１に対応するシステム及び方法の発明であり，本願発明１とカテゴリ表現が異なるだけの発明であるから，本願発明１と同様の理由により，当業者であっても，引用発明及び引用文献２～５に記載された技術的事項に基づいて容易に発明できたものとはいえない。

４．本願発明５～７について

本願発明５～７は，本願発明１，３，４をさらに減縮した発明であり，本願発明１の上記相違点１及び相違点２に係る構成を備えるものであるから，本願発明１と同じ理由により，当業者であっても，引用発明及び引用文献２～５に記載された技術的事項に基づいて容易に発明できたものとはいえない。

第６　むすび

以上のとおり，本願発明１～７は，当業者が引用発明及び引用文献２～５に記載された技術的事項に基づいて容易に発明をすることができたものではない。したがって，原査定の理由によっては，本願を拒絶することはできない。

また，他に本願を拒絶すべき理由を発見しない。

よって，結論のとおり審決する。