【事件の表示】
　特願２００２−５６３３８１「効率的なデータロード及びアンロードのために統合されるパケット基準のプロトコル論理を用いるハードウェア支援設計検証システム」拒絶査定不服審判事件〔平成１４年　８月１５日国際公開、ＷＯ０２／６３５０７、平成１６年　６月２４日国内公表、特表２００４−５１９０４１〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本願は、２００１年（平成１３年）１０月１９日の国際出願（パリ条約による優先権主張２０００年（平成１２年）１０月２０日、アメリカ）であって、平成１９年３月３０日付けの拒絶理由通知に対して同年１０月２日付けで手続補正がなされたが、同年１１月２０日付けで拒絶査定がなされ、これに対し、平成２０年２月２０日に拒絶査定不服審判が請求されるとともに、同年３月２１日付けで手続補正（以下、「本件補正」という。）がなされたものである。
　
第２　平成２０年３月２１日付けの手続補正についての補正却下の決定
〔補正却下の決定の結論〕
　平成２０年３月１７日付けの手続補正を却下する。
　
〔理由〕
１．本件補正前及び本件補正後の本願発明
　本件補正は、明細書の特許請求の範囲についてするもので、補正前（平成１９年１０月２日付け手続補正）に、
「【請求項１】
　ハードウェアアクセラレータと通信するホストワークステーションを有し、目標設計を検証するためのハードウェア支援設計検証システムであり、前記目標設計は、レジスタ及びメモリを有し、前記ホストワークステーションは、前記目標設計内のレジスタ及びメモリにデータをロードしあるいはデータをアンロードするものであって、
　前記目標設計内に統合されるプロトコル論理を有し、該プロトコル論理は、
　　前記ホストワークステーションと通信し、前記ホストワークステーションから送信さ
　れたデータ及びコマンドを含むパケットを蓄積する入力パケットレジスタと、
　　前記ホストワークステーションと通信し、前記ホストワークステーションに送信され
　るデータを含むパケットを蓄積する出力パケットレジスタと、
　　前記目標設計内の所定の動作、レジスタあるいはメモリ位置を識別するために、前記
　入力パケットレジスタ内の前記コマンドをデコードするコマンドデコード論理であり、
　前記所定の動作は、書込コマンドあるいは読取コマンドによって指示され、
　　前記コマンドデコード論理でデコードされた書込コマンドに対して、前記入力パケッ
　トレジスタ内に蓄積されているデータを、前記目標設計内の前記レジスタあるいはメモ
　リ位置に書き込む書込コマンド実行論理と、
　　前記コマンドデコード論理でデコードされた読出コマンドに対して、前記目標設計内
　の前記レジスタあるいはメモリ位置からデータを読み出し、当該データを前記出力パケ
　ットレジスタ内に蓄積する読出コマンド実行論理を有している。
　　【請求項２】
　請求項１に記載のハードウェア支援設計検証システムであって、前記プロトコル論理は
、前記入力パケットレジスタからのデータが新しいか否かを決定し、コマンドのデコード
及び実行の作動を制御する論理を含んでいる。」
とあったものを、補正後（平成２０年３月２１日付け手続補正）に、
「【請求項１】
　ハードウェアアクセラレータと通信するホストワークステーションを有し、ユーザー設
計を検証するためのハードウェア支援設計検証システムであり、前記ユーザー設計は、レ
ジスタ及びメモリを有し、前記ホストワークステーションは、前記ユーザー設計内のレジ
スタ及びメモリにデータをロードしあるいはデータをアンロードするものであって、
　前記ユーザー設計内に統合されるプロトコル論理を有し、該プロトコル論理は、
　　前記ホストワークステーションと通信し、前記ホストワークステーションから送信さ
　れたデータ及びコマンドを含むパケットを蓄積する入力パケットレジスタと、
　　前記ホストワークステーションと通信し、前記ホストワークステーションに送信され
　るデータを含むパケットを蓄積する出力パケットレジスタと、
　　前記ユーザー設計内の所定の動作、レジスタあるいはメモリ位置を識別するために、
　前記入力パケットレジスタ内の前記コマンドをデコードするコマンドデコード論理であ
　り、前記所定の動作は、書込コマンドあるいは読取コマンドによって指示され、
　　前記コマンドデコード論理でデコードされた書込コマンドに対して、前記入力パケッ
　トレジスタ内に蓄積されているデータを、前記ユーザー設計内の前記レジスタあるいは
　メモリ位置に書き込む書込コマンド実行論理と、
　　前記コマンドデコード論理でデコードされた読出コマンドに対して、前記ユーザー設
　計内の前記レジスタあるいはメモリ位置からデータを読み出し、当該データを前記出力
　パケットレジスタ内に蓄積する読出コマンド実行論理を有している。
　　【請求項２】
　請求項１に記載のハードウェア支援設計検証システムであって、前記プロトコル論理は
、前記入力パケットレジスタからのデータが新しいか否かを決定し、コマンドのデコード
及び実行の作動を制御する論理を含んでいる。」
と補正しようとするものである。
　
　すると、本件補正は、本件補正前の請求項１に記載した発明を特定するために必要な事項である「目標設計」を「ユーザー設計」と限定し、かつ、本件補正後の請求項１に記載された発明は、本件補正前の請求項１に記載された発明と、産業上の利用分野及び解決しようとする課題が同一であるものであるから、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法（以下、「平成１８年改正前特許法」という。）第１７条の２第４項第２号の特許請求の範囲の減縮を目的とするものに該当する。
　
　そこで、本件補正後における特許請求の範囲に記載されている事項により特定される発明が特許出願の際独立して特許を受けることができるものであるか（平成１８年改正前特許法第１７条の２第５項において準用する同法第１２６条第５項に規定する要件を満たすか）否かを、請求項１に係る発明（以下、「本願補正発明」という。）について以下に検討する。 
　
２．刊行物の記載事項
＜刊行物１＞
　原査定の拒絶の理由に引用された、本願出願前に頒布された刊行物である米国特許第５５４６５６２号明細書（以下、「刊行物１」という。）には、図面とともに以下の技術事項が記載されている。（なお、括弧内の日本語は、審判合議体による英日仮訳である。）
　
（ア）「Summary
  This invention provides an emulation model for a VLSI device or a system, with the ability to observe and modify internal registers and status of a VLSI circuit, while being used in a simulated design. This emulation model combines in-circuit emulation techniques along with hardware modeling techniques to provide a simulation model capable of providing controllability and observability within the VLSI device or circuit being emulated within a simulated system. Normal device operations are continually submitted to the device in order to keep it in an acquiesced state such that the internal state of the device is kept operational and architecturally unmodified. A simulated functional access is gathered from the simulator and submitted to the device to change the internal state of the device to reflect the simulated access. Independently, any user request to view or alter the device's status is submitted to the device to reflect the user request. Any breakpoint operation requested by the user is monitored whenever a simulated functional access is submitted to the device. Breakpoint conditions then are reported back to the user and to the simulator to allow the user to effectively debug the simulated design.」（第７欄第２６行ないし第４７行）
　
（「要約
　本発明は、シミュレートされた設計図に使用されており、ＶＬＳＩ回路の内部レジスタ及び状態を観測し修正するための能力を持つ、ＶＬＳＩデバイス又はシステムのためのエミュレーションモデルを供給する。このエミュレーションモデルは、シミュレートされたシステム内でエミュレートされているＶＬＳＩデバイス又は回路内で可制御性と可観測性を提供できるシミュレーションモデルを提供するために、ハードウェアモデリング技術に加えてインサーキットエミュレーション技術を兼ね備える。通常のデバイス操作は、デバイスの内部状態が、操作上及びアーキテクチャー上、修正されていない状態を保たれるような黙従した状態にそれを保つために、デバイスを絶えず従わせる。シミュレートされた機能的アクセスは、シミュレートされたアクセスを反映し、デバイスの内部状態を変えるためにシミュレーターから集められて、デバイスに提出される。独自に、デバイスの状態を見るか又は変更するためのユーザーのどんな要求も、ユーザー要求を反映するためにデバイスに提出される。ユーザーによって要求されたブレイクポイント操作はどれでも、シミュレートされた機能的アクセスがデバイスに提出されるときはいつでも、モニターされる。そして、ブレイクポイントの状態は、シミュレートされた設計図を効果的にデバッグすることをユーザーに許容するために、ユーザーに及びシミュレーターに折り返し報告される。」）
　
（イ）「FIG. 1 shows a block diagram of a simulation system with an emulation modeling apparatus in accordance with the invention. An engineering workstation 15 executes a host simulation environment 26. Environment 26 provides logic simulation, employing an emulation modeling apparatus 54 (also referred to as emulation modeler), to functionally emulate a device under simulation 48 (also referred to as a DUS). The internal operations of DUS 48 are made visible and allowed to be controlled via a model debug and user interface 20, which is also executed on workstation 15. Examples of devices or systems which are candidates for emulation models are microprocessors, complex peripheral controllers such as hard disk controllers, graphics accelerators, FDDI controllers, DSP devices etc., as well as systems consisting of a combination of these devices.
  Environment 26 represents any commercial logic simulator environment (e.g., sold by Cadence Design Systems Inc. of San Jose, Calif.) which runs on commercial workstation 15 and provides a means to interface user-defined models into a simulated design. A model interface 28 (FIG. 4) is created for a device and its instances to be emulated within simulator 26. For each instance of the emulated device, there is a corresponding model debug and user interface 20. Interface 20 displays all relevant debug information to the user, and also accepts any request from the user to change or to set internal operational variables of the emulated device. Interface 20 is a graphical user interface (GUI) which works alongside simulator 26 on workstation 15.
  All simulator specific information is passed to and from simulator 26 and emulation modeler 54 via a remote access port 24 with the use of a simulation communication channel 30, and a command and data channel 32. Likewise all emulation specific debug information is passed to and from interface 20 and emulation modeler 54 via remote access port 24 with the use of a GUI communication channel 22, and a command and data channel 32.
  Emulation modeler 54 takes any information coming over channel 32 and parses the requests within a command and data interpreter and router 34. All simulation specific data is passed to a simulation specific functional state generator 40 via a simulation command and data channel 36, while all emulation specific requests and data are passed to a user request and default functional state generator 42 via an emulation command and data channel 38. Finally, all maintenance and system related requests are passed to a device control 50 via a maintenance command and data channel 52. Control 50 prepares DUS 48 upon power-on reset to remain in an acquiesced state. All emulation specific information and default state information for the device is passed to control 50 from state generator 42 via an emulation and default state machine channel 46. All simulation specific information is passed to control 50 from state generator 40 via a simulation state machine channel 44. Based upon the response from DUS 48, control 50 routes back the data to generators 40, 42, and router 34 via respective communication channels 44, 46, and 52. These responses are further funneled into interface 34 via channels 36, 38. Finally, emulation modeler 54 responds back to simulator 26 and interface 20 via channel 32, remote access port 24, and through communication channels 30 and 22, respectively.」（第７欄第５０行ないし第８欄第４３行）
　
（「図１は、本発明に従うエミュレーションモデリング装置と共にシミュレーションシステムのブロック図を示す。エンジニアリングワークステーション１５は、ホストシミュレーション動作環境２６を実行する。動作環境２６は、エミュレーションモデリング装置５４（また、エミュレーションモデラーと呼ばれる）を使用するために、シミュレーション下のデバイス４８（また、“ＤＵＳ”と呼ばれる）を機能的にエミュレートするために、論理シミュレーションを提供する。ＤＵＳ４８の内部の働きは、モデルデバッグ及びユーザーインターフェース２０を介して可視化され、制御され得る。それはまた、ワークステーション１５上で実行される。エミュレーションモデルの候補であるデバイス又はシステムの例は、マイクロプロセッサー、ハードディスクコントローラーのような複雑な周辺機器コントローラー、グラフィックスアクセラレータ、ＦＤＤＩコントローラー、ＤＳＰデバイスなど、及びこれらのデバイスの組合せから成るシステムである。
　動作環境２６は、市販のワークステーション１５上で作動する市販の論理シミュレーター動作環境（例えば、カリフォルニア州サンノゼのケイデンス・デザイン・システムズによって販売される）のどれでも典型となり、ユーザーによって定義されたモデルをシミュレートされた設計図に連結するための手段を提供する。モデルインターフェース２８（図４）は、デバイスとそのインスタンスがシミュレーター２６内にエミュレートされるために作成される。エミュレートされたデバイスのそれぞれのインスタンスのために、対応するモデルデバッグ及びユーザーインターフェース２０がある。インターフェース２０は、すべての関連デバッグ情報をユーザーに表示し、また、エミュレートされたデバイスの内部の操作変数を変更するか又は設定するために、ユーザーからどんな要求も受け入れる。インターフェース２０は、ワークステーション１５上のシミュレーター２６と並んで働くグラフィカルユーザーインターフェース（ＧＵＩ）である。
　すべてのシミュレーターの特定の情報が、シミュレーションコミュニケーションチャンネル３０、コマンド及びデータチャンネル３２を使用してリモートアクセスポート２４を介してシミュレーター２６から及びシミュレーター２６に対して、エミュレーションモデラー５４に対して及びエミュレーションモデラー５４から送られる。同様にすべてのエミュレーションの特定のデバッグ情報が、ＧＵＩコミュニケーションチャンネル２２、コマンド及びデータチャンネル３２を使用してリモートアクセスポート２４を介してインターフェース２０から及びインターフェース２０に対して、エミュレーションモデラー５４に対して及びエミュレーションモデラー５４から送られる。
　エミュレーションモデラー５４は、チャンネル３２から来るどんな情報も取得し、コマンド及びデータインタープリター／ルーター３４内で要求を解析する。すべてのシミュレーションの特定のデータが、シミュレーションコマンド及びデータチャンネル３６を介してシミュレーション特定機能状態生成機４０に送られ、同時にエミュレーションの特定の要求とデータは、エミュレーションコマンド及びデータチャンネル３８を介してユーザー要求及びデフォルト機能状態生成機４２に送られる。最後に、すべてのメンテナンス及びシステムに関連した要求は、メンテナンスコマンド及びデータチャンネル５２を介してデバイスコントロール５０に送られる。コントロール５０は、黙従した状態にとどまるためにパワー・オン・リセット上のＤＵＳ４８を準備する。デバイスのためのすべてのエミュレーションの特定の情報及びデフォルト状態の情報は、エミュレーション及びデフォルト状態マシンチャンネル４６を介して状態生成機４２からコントロール５０へ送られる。すべてのシミュレーションの特定の情報は、シミュレーション状態マシンチャンネル４４を介して状態生成機４０からコントロール５０へ送られる。ＤＵＳ４８からの応答に基づいて、コントロール５０は、それぞれの通信チャンネル４４、４６及び５２を介して生成機４０、４２及びルーター３４にデータを返送する。これらの応答は、さらにチャンネル３６、３８を介してインターフェース３４に流される。最後に、エミュレーションモデラー５４は、シミュレーター２６及びインターフェース２０に、チャンネル３２、リモートアクセスポート２４を介し、それぞれコミュニケーションチャンネル３０及び２２を通して、返答を返す。」）
　
（ウ）「FIG. 5 shows the details of a command and data interpreter and router 34 (FIG. 1). All the requests to and from emulation modeler 54 are routed through a command and data channel 32. A command and data network interface 78 interprets the command and the data packets and farms out relevant packets to a simulation `run-time` information router 80, an emulation modeler related information router 82, and a debug and emulation `run-time` information router 84. Routers 80, 82 and 84 act as bidirectional software buffers. Router 80 provides the buffering for simulation related information and communicates with a simulation specific functional state generator 40 (FIG. 1) via a simulation command and data channel 36. Router 82 provides the buffering for maintenance related information and communicates with device control 50 (FIG. 1) via a maintenance command and data channel 52. Router 84 provides the buffering for debug run-time information and communicates with state generator 42 (FIG. 1) via an emulation command and data channel 38. All the responses received by channels 36, 52, and 38 are passed to routers 80, 82, and 84 which then transfer them to block 78, which in turn passes all responses to channel 32.」（第９欄第２９行ないし第５０行）
　
（「図５は、コマンド及びデータインタープリター／ルーター３４（図１）の詳細を示す。エミュレーションモデラー５４に対する要求及びエミュレーションモデラー５４からの要求のすべては、コマンド及びデータチャンネル３２を通して伝送される。コマンド及びデータネットワークインターフェース７８は、コマンド及びデータパケットを解釈し、シミュレーション‘ラン−タイム’情報ルーター８０、エミュレーションモデラー関連情報ルーター８２及びデバッグ及びエミュレーション‘ラン−タイム’情報ルーター８４に、適切なパケットを委託する。ルーター８０、８２及び８４は、双方向ソフトウェアバッファとして機能する。ルーター８０は、関連情報をシミュレーションのためのバッファリングに提供し、シミュレーションコマンド及びデータチャンネル３６を介してシミュレーション特定機能状態生成機４０（図１）と通信し合う。ルーター８２は、関連情報をメンテナンスのためのバッファリングに提供し、メンテナンスコマンド及びデータチャンネル５２を介してデバイスコントロール５０（図１）と通信し合う。ルーター８４は、デバッグランータイム情報にバッファリングを提供し、エミュレーションコマンド及びデータチャンネル３８を介して状態生成機４２（図１）と通信し合う。チャンネル３６、５２及び３８によって受け取られたすべての応答は、ルーター８０、８２及び８４を通され、それからブロック７８にそれらを転送し、次にチャンネル３２にすべての応答を送る。」）
　
（エ）「FIG. 7 shows the details of an emulation specific and default functional state generator 42 (FIG. 1). A emulation buffering setup 93 sets up all required software queues to buffers emulation specific data and command coming over from user interface 20. All emulation specific information is received via channel 38 by an emulation model (instance) selection and response router 94. Router 94 determines which specific type and instance of emulation model the `user and debug request` is for. Accordingly, the information is passed to one of several possible emulation model default/debug access generators 96, 98, etc. Generator 96 identifies what debug or functional state change access was requested and accordingly either prepares an emulation command or pulls up a list of access patterns to be applied to the device under simulation. This access list or command is passed on to a status `update/view` request and response router 100. A similar function to that performed in generator 96 is performed by other generator 98, etc. for other emulation model types and instances. Router 100 passes the debug command or access list to device control 50 (FIG. 1) via an emulation and default state machine channel 46. The state change update from control 50 is received back by router 100 which passes the related functional state change to one of generators 96, 98, etc. This response is further passed back to router 94 which in turn passes it on to channel 38.」（第１０欄第１３行ないし第３７行）
　
（「図７は、特定の及びデフォルトの機能的な状態生成機のエミュレーションの詳細を示す。エミュレーションバッファリングセットアップ９３は、ユーザーインターフェース２０から来るバッファエミュレーションの特定のデータとコマンドにすべての要求されたソフトウェア待ち行列をセットアップする。すべてのエミュレーションの特定の情報は、エミュレーションモデル（インスタンス）選択及び応答ルーター９４によってチャンネル３８を介して受け取られる。ルーター９４は、‘ユーザー及びデバッグ要求’がどの特定のタイプ及びインスタンスのためにあるかを決定する。したがって、情報は数個の可能なエミュレーションモデルデフォルト／デバッグアクセス生成機９６、９８などの１つに送られる。生成機９６は、どんなデバッグか、又は機能的な状態変更アクセスが要求されたかを確認し、したがって、シミュレーション下のデバイスに適用されるために、エミュレーションコマンドを準備するか、又はアクセスパターンのリストを引き上げる。このアクセスリスト又はコマンドが、状態‘最新化／検査’要求及び応答ルーター１００に伝えられる。生成機９６で実行されたものへの同様の機能は、他のエミュレーションモデルタイプ及びインスタンスのための他の生成機９８などによって実行される。ルーター１００は、エミュレーション及びデフォルト状態マシンチャンネル４６を介してデバイスコントロール５０（図１）にデバッグリスト又はアクセスリストを渡す。コントロール５０からの状態変更の最新情報は、生成機９６、９８などの１つへ関連した機能的な状態変更を送るルーター１００によって受けられる。この応答は、さらに、次にチャンネル３８にそれを渡すルーター９４に戻される。」）
　
（オ）「FIG. 8 shows the details of device control 50 (FIG. 1). The three types of accesses to DUS 48 are received by three separate channels 44, 52, and 46. Simulation specific requests and responses are handled by a simulation access vector process and response router 102. Maintenance and diagnostic specific requests and responses are handled by a maintenance, setup, and control router 104. And emulation specific requests and responses are handled by a debug (default) access vector process and response router 106. Routers 102, 104, and 106 act as bidirectional software buffers for passing requests and responses for all VLSI devices models and related instances. DUS 48 (FIG. 1) is represented in FIG. 8 as several personality modules 108, 110, etc. An emulation model needs to utilize information specific to the device being simulated (from relevant data provided in the manufacture's data sheets) to control one VLSI device supported by the emulation modeling apparatus. The control method is common to all devices whereas the information governing the operational aspect is unique or personal to a device thus the module is referred to as the personality module. Individual VLSI device (type A, and related representations) are controlled by personality module 108. Similarly other VLSI devices are controlled by similar personality modules 110 etc. Simulation related access and response to and from router 102 to all VLSI devices are passed via a simulation access request channel 112. Emulation modeler system request and response to and from router 104 to all VLSI devices are passed via an emulation modeler system request channel 114. And finally user debug request and response to and from router 106 to all VLSI devices are passed via an emulation debug and default access channel 116. These same channels 112, 114, and 116 are used respectively to send back responses from the personality modules 108, 110, etc. to the routers 102, 104, and 106 which pass back the responses over the channels 44, 52, and 46.」（第１０欄第３９行ないし第１１欄第７行）
　
（「図８は、デバイスコントロール５０（図１）の詳細を示す。ＤＵＳ４８への３つのタイプのアクセスは、３つの別々のチャンネル４４、５２及び４６によって受け取られる。シミュレーションの特定の要求と応答は、シミュレーションアクセスベクトル処理／応答ルーター１０２によって扱われる。メンテナンス、診断特有の要求及び応答は、メンテナンス、セットアップ、及び制御ルーター１０４によって扱われる。そして、エミュレーションの特定の要求と応答は、デバッグ（デフォルト）アクセスベクトル処理／応答ルーター１０６によって扱われる。ルーター１０２、１０４及び１０６は、すべてのＶＬＳＩデバイスと関連するインスタンスに対して要求と応答を通すために双方向ソフトウェアバッファとして機能する。ＤＵＳ４８（図１）は、いくつかのパーソナリティモジュール１０８、１１０などとして図８に表される。エミュレーションモデルは、エミュレーションモデル装置によってサポートされる１つのＶＬＳＩデバイスを制御するために（製造のデータシートに提供された関連データから）シミュレーションされるデバイスに特定の情報を利用する必要がある。制御方法は、すべてのデバイスに共通だが一方、作動状況を決定する情報は、デバイスに特有か、またはパーソナルであり、したがって、モジュールは、パーソナリティモジュールと呼ばれる。個々のＶＬＳＩデバイス（タイプＡ、そして関連する表現）は、パーソナリティモジュール１０８によって制御される。同様に、他のＶＬＳＩデバイスは、同様のパーソナリティモジュール１１０などによって制御される。すべてのＶＬＳＩデバイスについてルーター１０２に対して及びルーター１０２からのシミュレーションに関連したアクセス及び応答は、シミュレーションアクセス要求チャンネル１１２を介して送られる。すべてのＶＬＳＩデバイスについてルーター１０４に対して及びルーター１０４からのエミュレーションモデラーシステムの要求及び応答は、エミュレーションモデラーシステム要求チャンネル１１４を介して送られる。そして最後に、すべてのＶＬＳＩデバイスについてルーター１０６に対して及びルーター１０６からのユーザーデバッグ要求及び応答は、エミュレーションデバッグ及びデフォルトアクセスチャンネル１１６を介して送られる。これらの同じチャンネル１１２、１１４及び１１６は、パーソナリティモジュール１０８、１１０などからチャンネル４４、５２及び４６上に応答を戻すルーター１０２、１０４及び１０６に応答を返送するためにそれぞれ使用される。」）
　
（カ）「FIG. 9A shows the details of one of a typical device under simulation 48 (FIG. 1). The details of interface to this modules were described above as personality modules 108, 110, etc. (This is the only module which uses firmware. Any designer skilled in firmware development will be able to use the descriptions and the flowchart on FIG. 9B to build emulation model personality module 108, 110, etc. for a device under simulation.) This module interfaces with a reference element 122. This module is central in keeping reference element 122 in a known valid state for reference element 122 to function as a simulation model while independently allowing the user to view and change the internal registers of reference element 122. Three access type informations are received by an arbitration and synchronization control circuit 118 via three channels 112, 114, and 116 described above in connection with FIG. 8.
 FIG. 9B is a flowchart detailing how this arbitration and synchronization is performed by circuit 118. Reference element 122 is controlled continually by circuit 118 via hardware buffers and latches 120 and 124. Upon power-on-reset and whenever there is no functional access, reference element 122 is kept in a quiescent state by applying a default set of stimuli to reference element 122. When a valid access is requested, reference element 122 is brought out from the quiescent state and new access applied, the response is monitored and then farmed back to one of appropriate channels 112, 114, or 116. Reference element 122 is again made to go back to quiescent state until later time when simulator 72 or the user interface 20 needs to access it.」（第１１欄第１０行ないし第３９行）
　
（「図９Ａは、典型的なシミュレーション下のデバイス４８（図１）の１つの詳細を示す。このモジュールに対するインターフェースの詳細は、パーソナリティモジュール１０８、１１０などとして上記された。（これは、ファームウェアを使用するただ１つのモジュールである。ファームウェア開発に熟練したどんなデザイナーも、シミュレーション下のデバイスのためのパーソナリティモジュール１０８、１１０などのエミュレーションモデルを構築するために図９Ｂの記述とフローチャートを使用することができるだろう。）このモジュールは、参照構成要素１２２に連結する。このモジュールは、参照構成要素１２２の内部レジスタを観測して変更することをユーザーに独立して許容している間、参照構成要素１２２がシミュレーションモデルとして機能するように知られている有効な状態に参照構成要素１２２を保つことにおいて中心をなしている。３つのアクセスタイプ情報が、図８に関連して上記された３つのチャンネル１１２、１１４及び１１６を介して調停及び同期制御回路１１８によって受け取られる。
　図９Ｂは、この調停及び同期が、回路１１８によってどのように実行されるかを詳しく述べているフローチャートである。参照構成要素１２２は、ハードウェアバッファ及びラッチ１２０及び１２４を介して回路１１８によって絶えず制御される。パワー・オン・リセットの状態で、そしてどんな機能的なアクセスもない時はいつでも、参照構成要素１２２は、参照構成要素１２２に対する試験信号のデフォルトセットを適用することによって静止した状態を保たれる。有効なアクセスが要求されるとき、参照構成要素１２２は、静止した状態から取り出され、そして新しいアクセスが適用され、応答は、監視され、そしてそれから適切なチャンネル１１２、１１４又は１１６の一つに請け負わせて戻される。参照構成要素１２２は、シミュレーター７２かユーザーインターフェース２０がそれにアクセスする必要がある後の時間まで静止した状態に再び戻らされる。」）
　
（キ）「2. Reference element 122 can easily be adapted to provide an interface to a `Packet Transfer Bus`, such as PCI, SBUS (MBUS or XBUS from SUN Microsystems, Mountain View, Calif.), FUTURE BUS (IEEE standard) etc. This is possible because the emulation model can accumulate a packet transfer request from the simulator (in simulation time ticks) and later submit a `real time` request to the BUS. The response from real devices on the BUS are in turn picked up in real time and then farmed back to the simulation hardware in simulation time ticks.
3. Reference element 122 can easily be adapted to provide an interface to a programmable emulation subsystem as marketed by companies such as Aptix Corporation, San Jose, Calif. or Quickturn Design Systems Corp., Mountain View, Calif., thereby enhancing the usefulness of these verification tools as a simulated subsystem instead of just an emulation subsystem.」（第２５欄第１５行ないし第３２行）
　
（「２．参照構成要素１２２は、ＰＣＩ、ＳＢＵＳ（サン・マイクロシステムズ、マウンテンビュー、カリフォルニアからのＭＢＵＳ又はＸＢＵＳ）、フューチャーバス（ＩＥＥＥ規格）などのような‘パケット転送バス’にインターフェースを提供するために容易に適合させられる。これは、エミュレーションモデルが、シミュレーター（シミュレーションタイムチックにおける）からパケット転送要求を蓄積し、後で‘リアルタイム’の要求をバスに提出することができるので可能である。バス上の実際のデバイスからの応答は、順番にリアルタイムに取り上げられ、それからシミュレーションタイムチックにおけるシミュレーションハードウェアに請け負わせて戻される。
３．参照構成要素１２２は、Ａｐｔｉｘ社、サンノゼ、カリフォルニア又はクイックターン・デザイン・システムズ社、マウンテンビュー、カリフォルニアのような企業によって市場に出されているようなプログラマブルエミュレーションサブシステムに、それによってまさしくエミュレーションサブシステムの代わりにシミュレートされたサブシステムとしてこれらの検証ツールの有用性を高めながら、インターフェースを提供するために容易に適合させられる。」
　
（ク）「Although most of the sections of the emulation modeler are shown to be implemented in software, a significant portion of the emulation modeler can be developed as firmware or even hardware which will provide a very fast and efficient simulation and emulation modeling environment.
 The emulation modeler can also be integrated with a hardware simulator (hardware accelerators sold by IKOS Systems, Cupertino, Calif. or Zycad Corp., Fremont, Calif.). This will provide a very fast albeit little more expensive emulation modeling apparatus.」（第２６欄第８行ないし第１６行）
　
（「エミュレーションモデラーのセクションの大部分は、ソフトウェアで実行されることが示されるけれども、エミュレーションモデラーの重要な部分は、高速で効率的なシミュレーション及びエミュレーションモデリング環境を提供するファームウェアか又はハードウェアとしてでも開発可能である。
　また、エミュレーションモデラーは、ハードウェアシミュレーター（ＩＫＯＳシステムズ、クパチーノ、カリフォルニア、又は、ザイキャド社、フリーモント、カリフォルニアによって販売されたハードウェアアクセラレータ）と統合可能である。これは、わずかに高価であるが高速なエミュレーションモデリング装置を提供するであろう。」）
　
（ケ）FIGURE-9A、上記（オ）及び上記（キ）の記載から見て「REFERENCE ELEMENT（参照構成要素）１２２は、VLSI Device, System Bus, FPGA netlist（ＶＬＳＩデバイス、システムバス、ＦＰＧＡネットリスト）のいずれかからなる。」（FIGURE-9A、上記（オ）及び上記（キ）から認定） 
　
　上記（ア）ないし（ケ）の記載事項を総合勘案すると、刊行物１には、次の発明（以下、「刊行物１発明」という。）が開示されていると認められる。
　
「エミュレーションモデルの候補であるデバイス又はシステムの例である、マイクロプロセッサー、ハードディスクコントローラーのような複雑な周辺機器コントローラー、グラフィックスアクセラレータ、ＦＤＤＩコントローラー、ＤＳＰデバイスなど、及びこれらのデバイスの組合せから成るシステムをエミュレートし、その重要な部分は、高速で効率的なエミュレーションモデリング環境を提供するハードウェアであって、ハードウェアシミュレーターと統合可能であるエミュレーションモデリング装置５４と通信するエンジニアリングワークステーション１５を有し、ＶＬＳＩデバイス、システムバス、ＦＰＧＡネットリストのいずれかからなる参照構成要素１２２の内部レジスタを観測して変更するためのシミュレーションシステムであり、前記参照構成要素１２２は、レジスタを有し、前記エンジニアリングワークステーション１５は、前記参照構成要素１２２に要求を送りあるいは応答を得るものであって、
　前記エミュレーションモデリング装置５４内にあって、
　前記エンジニアリングワークステーション１５とコマンド及びデータチャンネル３２を介して通信するコマンド及びデータインタープリター／ルーター３４内にあって、前記エンジニアリングワークステーション１５から送信されたコマンド及びデータパケットを解釈し、同じコマンド及びデータインタープリター／ルーター３４内にある双方向ソフトウェアバッファとして機能するエミュレーション‘ラン−タイム’情報ルーター８４に、適切なパケットを委託するコマンド及びデータネットワークインターフェース７８と、
　前記デバッグ及びエミュレーション‘ラン−タイム’情報ルーター８４と通信するユーザー要求及びデフォルト機能状態生成機４２内にあって、すべてのエミュレーションの特定の情報を受け取り、‘ユーザー及びデバッグ要求’がどの特定のタイプ及びインスタンスのためにあるかを決定し、情報を数個の可能なエミュレーションモデルデフォルト／デバッグアクセス生成機９６、９８などの１つに送り、前記エミュレーションモデルデフォルト／デバッグアクセス生成機９６、９８などの１つから応答を受け取るエミュレーションモデル（インスタンス）選択及び応答ルーター９４と、どんなデバッグか、又は機能的な状態変更アクセスが要求されたかを確認し、シミュレーション下のデバイスに適用されるために、エミュレーションコマンドを準備するか、又はアクセスパターンのリストを引き上げ、このアクセスリスト又はコマンドを、状態‘最新化／検査’要求及び応答ルーター１００に伝える前記エミュレーションモデルデフォルト／デバッグアクセス生成機９６、９８と、デバッグリスト又はアクセスリストをデバイスコントロール５０に渡し、前記デバイスコントロール５０からの状態変更の最新情報のうち関連した機能的な状態変更を前記生成機９６、９８などの１つへ送る前記状態‘最新化／検査’要求及び応答ルーター１００と、
　前記状態‘最新化／検査’要求及び応答ルーター１００と通信する前記デバイスコントロール５０内にあって、エミュレーションの特定の要求と応答を扱い、ＶＬＳＩデバイスと関連するインスタンスに対して要求と応答を通すために双方向ソフトウェアバッファとして機能し、シミュレーション下のデバイス（ＤＵＳ）４８であるパーソナリティモジュール１０８、１１０などに対してユーザーデバッグ要求を送り、前記パーソナリティモジュール１０８、１１０などからの応答を受け取るデバッグ（デフォルト）アクセスベクトル処理／応答ルーター１０６と、
　前記ＤＵＳ４８内にあって、前記デバッグ（デフォルト）アクセスベクトル処理／応答ルーター１０６と通信し、アクセスタイプ情報を受け取り、前記参照構成要素１２２を絶えず制御し、前記参照構成要素１２２に有効なアクセスを適用し、前記参照構成要素１２２からの応答を監視し、前記応答を前記デバッグ（デフォルト）アクセスベクトル処理／応答ルーター１０６へ戻す調停及び同期制御回路１１８と、
を備えるシミュレーションシステム。」
　
３．対比
　本願補正発明を、刊行物１発明と比較する。
　
（ア）刊行物１発明における「エンジニアリングワークステーション１５」及び「ＶＬＳＩデバイス、システムバス、ＦＰＧＡネットリストのいずれかからなる参照構成要素１２２」は、それぞれ本願補正発明における「ホストワークステーション」及び「ユーザー設計」に相当する。
　
（イ）刊行物１発明における「エミュレーションモデリング装置５４」は、「エミュレーションモデルの候補であるデバイス又はシステムの例である、マイクロプロセッサー、ハードディスクコントローラーのような複雑な周辺機器コントローラー、グラフィックスアクセラレータ、ＦＤＤＩコントローラー、ＤＳＰデバイスなど、及びこれらのデバイスの組合せから成るシステムをエミュレート」する装置であり、内部に本願補正発明における「ユーザー設計」に相当する「ＶＬＳＩデバイス、システムバス、ＦＰＧＡネットリストのいずれかからなる参照構成要素１２２」を有しており、本願補正発明における「ハードウェアアクセラレータ」とは、“ユーザー設計を検証するために使用する装置”という点で一致するといえる。
　
（ウ）刊行物１発明における「シミュレーションシステム」は、本願補正発明における「ユーザー設計」に相当する「ＶＬＳＩデバイス、システムバス、ＦＰＧＡネットリストのいずれかからなる参照構成要素１２２」にユーザー要求やデバッグ要求を送り、応答を得るシステムであるから、本願補正発明における「ユーザー設計を検証するためのハードウェア支援設計検証システム」とは、“ユーザー設計を検証するシステム”という点で一致するといえる。
　
（エ）刊行物１発明では、「エンジニアリングワークステーション１５」が「参照構成要素１２２」に「要求を送りあるいは応答を得る」ものであり、当該「要求」を送るために「デバッグリスト」や「アクセスリスト」を送っているのであるから、当該「デバッグリスト」や「アクセスリスト」は、本願補正発明における「データ」に相当する。
　また、刊行物１発明は「エミュレーションモデリング装置」を有する「シミュレーションシステム」であるから、刊行物１発明における「シミュレーションシステム」が「参照構成要素１２２の内部レジスタを観測して変更する」ことは、「参照構成要素１２２の内部レジスタ」に蓄積されているデータを読み出すことによって観測し、「参照構成要素１２２の内部レジスタ」にデータを書き込んで蓄積することにより変更することであり、上記「データ」に相当する「デバッグリスト」や「アクセスリスト」は、上記「レジスタ」にロードされ、上記「応答」は、何らかの「データ」として上記「レジスタ」からアンロードされることは明らかである。
　してみると、刊行物１発明における「前記エンジニアリングワークステーション１５は、前記参照構成要素１２２に要求を送りあるいは応答を得るもの」は、本願補正発明における「前記ホストワークステーションは、前記ユーザー設計内のレジスタ」に「データをロードしあるいはデータをアンロードするもの」に相当するといえる。
　
（オ）刊行物１発明における「エミュレーションモデリング装置５４」内にある「参照構成要素１２２」以外の構成は、「参照構成要素１２２」内の内部レジスタを観測して変更する手順（プロトコル）を示す論理（ロジック）であるから、本願補正発明における「プロトコル論理」に相当するといえる。
　
（カ）刊行物１発明における「デバッグ及びエミュレーション‘ラン−タイム’情報ルーター８４」は、「双方向ソフトウェアバッファとして機能」するものであり、「バッファ」は「蓄積媒体」であるから、これは、「双方向」すなわち「入力」と「出力」の「情報蓄積媒体」であるといえる。
　また、刊行物１発明における「コマンド及びデータパケット」は、「コマンド及びデータを含む情報」であり、「コマンド及びデータネットワークインターフェース７８」が「エンジニアリングワークステーション１５から送信されたコマンド及びデータパケットを解釈」して上記「デバッグ及びエミュレーション‘ラン−タイム’情報ルーター８４」に「適切なパケットを委託」するから、刊行物１発明には「前記ホストワークステーションと通信し、前記ホストワークステーションから送信されたコマンド及びデータを含む情報を蓄積する入力情報蓄積媒体」が存在するといえる。
　さらに、上記のように「デバッグ及びエミュレーション‘ラン−タイム’情報ルーター８４」が、「出力」の「情報蓄積媒体」であるとき、上記「デバッグ及びエミュレーション‘ラン−タイム’情報ルーター８４」から上記「エンジニアリングワークステーション１５」に対して、「応答」となる何らかのデータが「出力」されることは明らかであるから、刊行物１発明には、「前記ホストワークステーションと通信し、前記ホストワークステーションに送信されるデータを含む情報を蓄積する出力情報蓄積媒体」が存在するといえる。
　加えて、上記「コマンド」は、「解釈」されて、「ユーザー要求及びデフォルト機能状態生成機４２」及び「デバイスコントロール５０」を介して、最終的には、「エミュレーションコマンド」という「参照構成要素１２２」に対して指示を伝えて制御する情報として使用されるものであるから、刊行物１発明には、「前記ユーザー設計を制御するために、前記入力情報蓄積媒体内の前記コマンドをデコードするコマンドデコード論理」が存在するといえる。
　してみると、刊行物１発明と本願補正発明とは、“前記ホストワークステーションと通信し、前記ホストワークステーションから送信されたコマンド及びデータを含む情報を蓄積する入力情報蓄積媒体と、前記ホストワークステーションと通信し、前記ホストワークステーションに送信されるデータを含む情報を蓄積する出力情報蓄積媒体と、前記ユーザー設計を制御するために、前記入力情報蓄積媒体内の前記コマンドをデコードするコマンドデコード論理”が存在する点で一致するといえる。
　
（キ）上記（エ）に記載したように、刊行物１発明は、「参照構成要素１２２の内部レジスタ」に蓄積されているデータを読み出すことによって観測し、「参照構成要素１２２の内部レジスタ」にデータを書き込んで蓄積することにより変更するものであるから、上記「レジスタ」に対して、何らかの読み出し用の情報及び書き込み用の情報を使用して、データを読み出し及び書き込みする論理が存在することは明らかである。
　してみると、刊行物１発明と本願補正発明とは、“書き込み用の情報を使用して、前記入力情報蓄積媒体内に蓄積されているデータを、前記ユーザー設計内の前記レジスタ位置に書き込む論理と、読み出し用の情報を使用して、前記ユーザー設計内の前記レジスタ位置からデータを読み出し、当該データを前記出力情報蓄積媒体内に蓄積する論理”が存在する点で一致している。
　
　すると、本願補正発明と、刊行物１発明とは、次の点で一致する。
＜一致点＞
　ユーザー設計を検証するために使用する装置と通信するホストワークステーションを有するユーザー設計を検証するシステムであり、前記ユーザー設計は、レジスタを有し、前記ホストワークステーションは、前記ユーザー設計内のレジスタにデータをロードしあるいはデータをアンロードするものであって、
　プロトコル論理を有し、該プロトコル論理は、
　前記ホストワークステーションと通信し、前記ホストワークステーションから送信されたコマンド及びデータを含む情報を蓄積する入力情報蓄積媒体と、
　前記ホストワークステーションと通信し、前記ホストワークステーションに送信されるデータを含む情報を蓄積する出力情報蓄積媒体と、
　前記ユーザー設計を制御するために、前記入力情報蓄積媒体内の前記コマンドをデコードするコマンドデコード論理であり、
　書き込み用の情報を使用して、前記入力情報蓄積媒体内に蓄積されているデータを、前記ユーザー設計内の前記レジスタ位置に書き込む論理と、
　読み出し用の情報を使用して、前記ユーザー設計内の前記レジスタ位置からデータを読み出し、当該データを前記出力情報蓄積媒体内に蓄積する論理を有している。」
　
　一方で、両者は、次の点で相違する。
＜相違点１＞
　「ユーザー設計を検証するために使用する装置」及び「ユーザー設計を検証するシステム」が、本願補正発明では、それぞれ「ハードウェアアクセラレータ」及び「ユーザー設計を検証するためのハードウェア支援設計検証システム」であるのに対し、刊行物１発明では、それぞれ「エミュレーションモデルの候補であるデバイス又はシステムの例である、マイクロプロセッサー、ハードディスクコントローラーのような複雑な周辺機器コントローラー、グラフィックスアクセラレータ、ＦＤＤＩコントローラー、ＤＳＰデバイスなど、及びこれらのデバイスの組合せから成るシステムをエミュレートし、その重要な部分は、高速で効率的なエミュレーションモデリング環境を提供するハードウェアであって、ハードウェアシミュレーターと統合可能であるエミュレーションモデリング装置５４」及び「ＶＬＳＩデバイス、システムバス、ＦＰＧＡネットリストのいずれかからなる参照構成要素１２２の内部レジスタを観測して変更するためのシミュレーションシステム」である点。
　
＜相違点２＞
　本願補正発明では、「ユーザー設計内」に、「レジスタ及びメモリ」が存在するのに対し、刊行物１発明では、「レジスタ」は存在するが、「メモリ」が存在するか否か明確でない点。
　
＜相違点３＞
　本願補正発明では、「プロトコル論理」が「ユーザー設計内に統合される」のに対し、刊行物１発明では、プロトコル論理に相当する構成は存在するが、当該プロトコル論理がユーザー設計内に統合されるか否か明確でない点。
　
＜相違点４＞
　「ホストワークステーションから送信されたコマンド及びデータを含む情報を蓄積する入力情報蓄積媒体」及び「ホストワークステーションに送信されるデータを含む情報を蓄積する出力情報蓄積媒体」が、本願補正発明では、それぞれ「ホストワークステーションから送信されたデータ及びコマンドを含むパケットを蓄積する入力パケットレジスタ」及び「ホストワークステーションに送信されるデータを含むパケットを蓄積する出力パケットレジスタ」であるのに対し、刊行物１発明では、エンジニアリングワークステーション１５から送信されたコマンド及びデータパケットを解釈し、適切なパケットを委託するコマンド及びデータネットワークインターフェース７８から、当該適切なパケットを委託される双方向ソフトウェアバッファとして機能するエミュレーション‘ラン−タイム’情報ルーター８４である点。
　
＜相違点５＞
　「前記ユーザー設計を制御するため」の「コマンド」が、本願補正発明では、「前記ユーザー設計内の所定の動作、レジスタあるいはメモリ位置を識別するため」の「コマンド」であり、「所定の動作」は、「書込コマンドあるいは読取コマンドによって指示される」のに対し、刊行物１発明では、ユーザー設計を制御するためのコマンドであるが、ユーザー設計内の具体的に何を制御するためのコマンドであるのか明確でなく、所定の動作を指示する書込コマンドあるいは読取コマンドが存在するのか否か明確でない点。
　
＜相違点６＞
　「書き込み用の情報」及び「読み出し用の情報」が、本願補正発明では、それぞれ「書込コマンド」及び「読出コマンド」であり、それぞれに対する「論理」が、「書込コマンド実行論理」及び「読出コマンド実行論理」であるのに対し、刊行物１発明では、何らかの「書き込み用の情報」及び「読み出し用の情報」は存在するが、それが「書込コマンド」及び「読出コマンド」であるか否か明確でなく、そのため「論理」が「書込コマンド実行論理」及び「読出コマンド実行論理」であるか否か明確でない点。
　
４．判断
　上記相違点について検討する。
　
（ア）相違点１について
　「ハードウェアアクセラレータ」は、とても広い技術的な概念を有する用語であり、処理の高速化を行う付加的なハードウェアであれば、すべて含まれるものである。
　そして、刊行物１発明における「エミュレーションモデリング装置５４」は、その重要な部分は、高速で効率的なエミュレーションモデリング環境を提供するハードウェアであり、市販のハードウェアシミュレーターと統合可能であるから、全体的に見て処理の高速化を行う付加的なハードウェアが含まれているといえるものである。
　してみると、刊行物１発明における「エミュレーションモデリング装置５４」には、「ハードウェアアクセラレータ」が含まれていると考えることが自然であり、本願補正発明における「ハードウェアアクセラレータ」と実質的な相違はなく、そのため、本願補正発明における「ユーザー設計を検証するためのハードウェア支援設計検証システム」と刊行物１発明における「参照構成要素１２２の内部レジスタを観測して変更するためのシミュレーションシステム」との間にも実質的な相違はない。
　なお、本願補正発明における「ハードウェア支援設計検証システム」が、「ハードウェアアクセラレータ」と「ホストワークステーション」のみから構成されて「ユーザー設計を検証する」システムであったとしても、そのようなシステムは、例えば、特表平４−５０２９８５号公報（図１、４１、４９、５４ないし５８、６０及び各図の説明におけるホストコンピュータとリアライザハードウェアシステム）、特開平１０−２３２８９０号公報（図６及びその説明におけるコンピュータシステムＡ１８と組込論理アナライザー２６０を組み込んだＰＬＤ１６を有する電子システム２５２）等に記載されているように周知技術であり、刊行物１発明においても上記周知技術のように「ハードウェア支援設計検証システム」が、「ハードウェアアクセラレータ」と「ホストワークステーション」のみから構成されて「ユーザー設計を検証する」システムとすることに困難性はない。
　
（イ）相違点２について
　「ユーザー設計内」に、「レジスタ」だけでなく「メモリ」も設けることは、通常行われていることであり、刊行物１発明においても、「ユーザー設計内」に、「レジスタ」だけでなく「メモリ」も設けることは、当業者が適宜なし得ることである。
　
（ウ）相違点３について
　「ユーザー設計内に統合されるプロトコル論理」は、上記（ア）に記載した特表平４−５０２９８５号公報（図５８及びその説明におけるリアライザハードウェアシステム内のＬチップ及び相互接続中で実現されるアナライザロジック）、特開平１０−２３２８９０号公報（図６及びその説明における組込論理アナライザー２６０）等に記載されているように周知技術であるから、刊行物１発明におけるプロトコル論理を、「ユーザー設計内に統合される」ようにすることは、当業者が適宜なし得ることである。
　なお、「ユーザー設計内に統合されるプロトコル論理」として、どのような機能を有するプロトコル論理を統合するかは、当業者が適宜選択し得る設計的事項であり、刊行物１発明における書き込み、読み出しを含めたプロトコル論理を統合することに困難性はない。
　
（エ）相違点４について
　刊行物１発明におけるコマンドとデータパケットとは、ともにコマンド及びデータチャンネル３２を介してエンジニアリングワークステーション１５から送られてくるから、コマンドもパケットとして送られてくると考えることが自然であり、当該コマンドを独立したパケット内に格納するか、データと同じパケット内に格納するかは、当業者が適宜選択し得る設計的事項に過ぎない。
　してみると、刊行物１発明において、エンジニアリングワークステーション１５から送信されたコマンド及びデータパケットをデータ及びコマンドを含むパケットとすることは、当業者が適宜なし得ることである。
　また、パケットを使用して通信を行う場合に、当該パケットを蓄積する蓄積媒体としてパケットレジスタを使用することは、常とう手段（例えば、特開平４−３５２２９３号公報（入力データパケットレジスタ２２、出力データパケットレジスタ１０）等）であり、刊行物１発明における双方向ソフトウェアバッファとして機能するエミュレーション‘ラン−タイム’情報ルーター８４に代えて、入力及び出力のパケットレジスタを使用したルーターを適用することは、当業者が適宜なし得ることである。
　
（オ）相違点５及び６について
　刊行物１発明において、「前記ユーザー設計を制御するため」の「コマンド」は、ユーザー設計を制御するためのコマンドであり、また、刊行物１発明には、「ユーザー設計内」の「レジスタ」にデータを書き込んだり、「ユーザー設計内」の「レジスタ」からデータを読み出したりするために使用する何らかの「書き込み用の情報」及び「読み出し用の情報」が存在することから、この何らかの「書き込み用の情報」及び「読み出し用の情報」を「前記ユーザー設計を制御するため」の「コマンド」とすることは、当業者が適宜なし得ることである。
　なお、上記のように、何らかの「書き込み用の情報」及び「読み出し用の情報」を「前記ユーザー設計を制御するため」の「コマンド」とした場合、上記「論理」が「書込コマンド実行論理」及び「読出コマンド実行論理」となることは明らかである。
　また、「ユーザー設計内」の「レジスタ」にデータを書き込んだり、「ユーザー設計内」の「レジスタ」からデータを読み出したりするためには、上記「レジスタ」の位置を識別するための情報を必要とすることは明らかであり、その情報としても上記「コマンド」を使用することも、当業者が適宜なし得ることである。
　
　そして、上記各相違点を総合的に検討しても、ユーザー設計を検証するシステムという同一の技術分野に属する上記刊行物１発明及び上記周知技術を組み合わせることにより、本願補正発明を構成することは、当業者が容易に想到し得ることであり、その作用効果も当業者が予測し得るものにすぎない。
　したがって、本願補正発明は、刊行物１発明及び周知技術に基づいて当業者が容易に発明をすることができたものであり、特許出願の際独立して特許を受けることができないものである。
　
５．請求人の主張について
　請求人が、平成２１年６月２５日付け回答書において行った、平成２１年３月２３日付け審尋に対する回答（１）ないし（７）について検討する。
　
（ア）回答（１）について
　請求人は、
「出願人は、「引用例５に記載されているエミュレーションモデラーは、要求を受け取るためにユーザー設計（ＤＳＵ４８）を停止状態に保つ必要があるのに対して、第１発明の（請求項１に係る）ハードウェア支援設計検証システムは、ユーザー設計内に統合されるプロトコル論理（入力パケットレジスタ、出力パケットレジスタ、コマンドデコード論理、書込コマンド実行論理、読出コマンド実行論理）を有しているため、要求を受け取るためにユーザー設計を停止状態に保持する必要がない。」ことを主張しています。なお、本願明細書には、「ユーザー設計内に統合されるプロトコル論理に含まれている、コマンドデコードブロック５１からのコマンド情報信号５１が入力される態制御ブロック４２」が記載されており、この状態制御ブロック４２を用いることによって、ユーザー設計は、ユーザー要求およびデバッグ要求を受け取ることができ、したがって、停止状態に保持される必要がありません。そして、第１発明では、要求を受け取るためにユーザー設計を停止状態に保持する必要がないため、ハードウェア検証の動作性を高めることができます。ここで、第１発明において、ユーザー設計を停止させた状態で要求を受け取ることもできますが、このような形態は、第１発明の目的に対応しないものであり、また、ユーザー設計内に第１発明のプロトコル論理を統合する必要性もありません。
 　なお、引用例５に記載されている発明における「ユーザー設計（ＤＵＳ４８）を停止状態に保持する必要性」は、第１発明の「ユーザー設計内へのプロトコル論理の統合」を教示していません。なぜなら、第１発明の「ユーザー設計内に統合されるプロトコルロ論理」は、「入力パケットレジスタ」および「出力パケットレジスタ」を用いてユーザー要求およびデバッグ要求を受信することができ、したがって、ユーザー設計を停止状態に保持する必要がないからです。さらに、引用例５に記載されているエミュレーションモデラーは、図８に示されていますように、通信チャンネル４４、４６および５２を介してユーザー設計（ＤＵＳ）と通信します。もし、引用例５に記載されている発明において、第１発明のプロトコル論理がユーザー設計（例えば、ＶＬＳＩ装置１０８、１１０）内に統合されていれば、制御コマンドおよびデータをホストワークステーションに通信するためおよびＤＵＳを停止状態に保持するために使用される通信チャンネル４４、４６および５２は必要ありません。このことによっても、引用例５には、第１発明の「ユーザー設計内へのプロトコル論理の統合」を教示していません。
　したがって、前置審査官の指摘は承服することができません。」
と記載し、本願補正発明において、「ユーザー設計」を検証する際に、「ユーザー設計」を「停止状態」としないことを限定する構成が「入力パケットレジスタ」及び「出力パケットレジスタ」を使用することである旨主張しているが、本願明細書中に、「入力パケットレジスタ」及び「出力パケットレジスタ」を使用する理由が、上記「ユーザー設計」を検証する際に、「ユーザー設計」を「停止状態」としないためである旨の記載はなく、また、上記４．（エ）に記載したように、パケットを使用して通信を行う場合に、当該パケットを蓄積する蓄積媒体としてパケットレジスタを使用することは、常とう手段であり、入力情報蓄積媒体及び出力情報蓄積媒体をともにパケットレジスタで構成することは、当業者が適宜なし得ることであるから、上記請求人の主張を採用することはできない。さらに、入力情報蓄積媒体及び出力情報蓄積媒体をともにパケットレジスタで構成すると、「ユーザー設計」を検証する際に、「ユーザー設計」を「停止状態」としなくても検証可能となることは明らかであるし、そもそも「ユーザー設計」を検証する際に、「ユーザー設計」を「停止状態」とするかしないかは、「ユーザー設計」の「検証システム」の使用態様であり、ユーザーが当該「検証システム」をどのように使用するかに応じて、適宜選択し得る事項に過ぎず、本願補正発明の進歩性を判断するための基準とはなり得ない。
　
（イ）回答（２）について
　請求人は、
「前置審査官は、「引用例５の背景技術の欄（米国特許第4,590,581号明細書）に記載されているハードウェアモデラー」と「引用例５に記載されているエミュレーションモデラー」を混同しています。引用例５の背景技術の欄に開示されていますハードウェアモデラーは、低いシミュレーション動作能力および内部動作の監察能力、また、特に、以前にシミュレートされた全入力信号を繰り返すためのハードウェアエミュレータの必要性を克服するエミュレーションシステムのようなエミュレーションモデラーと区別されるべきものです。すなわち、“ハードウェアモデラー”と“エミュレーションモデラー”は別のものであり、実際に、引用例５の第１２欄第５９行〜第６２行に、“This　method　to　keep　the　device　logically　and　functionally　correct，by　keeping　it　in　a　quiescent　state，is　totally　different　from　the　hardware　modeler．”「装置を停止状態に保持することによって装置を論理的および機能的に正しいく保持するこの方法は、ハードウェアモデラーと全く異なるものである。」と記載されています。また、引用例５には、引用例５に記載されているエミュレーションモデラーがハードウェアモデラーと同じものであることを示唆する記載もありません。
　したがって、前置審査官の「引用例５に記載されているエミュレーションモデラーは、ハードウェアアクセラレータによるモデラーと考えられる。」という指摘は承服することができません。」
と主張しているが、上記４．（ア）に記載したように、刊行物１発明における「エミュレーションモデリング装置５４」は、本願補正発明における「ハードウェアアクセラレータ」と実質的な相違はなく、また、もし相違があったとしても、上記４．（ア）に記載したように、「ハードウェア支援設計検証システム」が、「ハードウェアアクセラレータ」と「ホストワークステーション」のみから構成されて「ユーザー設計を検証する」システムは、周知技術であり、刊行物１発明を「ハードウェア支援設計検証システム」が、「ハードウェアアクセラレータ」と「ホストワークステーション」のみから構成されて「ユーザー設計を検証する」システムとすることに困難性はないから、上記請求人の主張を採用することはできない。
　
（ウ）回答（３）について
　請求人は、
「ここで、出願人が審判請求書において主張しているのは、「引用例５に記載されている、フォーマットの混合でモデル化されるエミュレーションモデラーは、ユーザー設計内への統合を教示しているか否か。」であり、前置審査官が指摘されていますように、「引用例５に記載されている回路の必要性が失われるか否か。」ではありません。
　当業者であれば、引用例５に記載されているミュレーションモデラーを統合し、同時に、フォーマットの混合で展開することを思いつくことはありません、なぜなら、この場合、「ユーザー設計内に統合されるプロトコル論理」による利点が失われるからです。さらに、引用例５に記載されているプロトコル論理が、フォーマットの混合で展開されるように、ユーザー設計内に統合されると、装置は、ソフトウェアまたはファームウェアで展開される論理を編集、処理および作動させるために追加されたオーバーヘッドによって、低いシミュレーション動作性を示すことになります。
　なお、第１発明は、「ユーザー設計内に統合されるプロトコル論理」を有しているとともに、このプロトコル論理は、「ホストワークステーションから送信されるデータおよびコマンドを含むパケットを蓄積する入力パケットレジスタ」と、ホストワークステーションに送信されるデータを含むパケットを蓄積する出力パケットレジスタ」と、「入力パケットレジスタ内のコマンドをデコードするコマンドデコード論理」と、「コマンドデコード論理でデコードされた書込コマンドに対して、入力パケットレジスタ内に蓄積されているデータを、ユーザー設計内のレジスタあるいはメモリ位置に書き込む書込コマンド実行論理」と、「コマンドデコード論理でデコードされた読出コマンドに対して、ユーザー設計内のレジスタあるいはメモリ位置からデータを読み出し、当該データを出力パケットレジスタ内に蓄積する読出コマンド実行論理」を有しているため、ユーザー設計を停止状態に保持する必要がありません。
　したがって、前置審査官の指摘は承服することができません。」
と主張しているが、前項に記載したように、刊行物１発明における「エミュレーションモデリング装置５４」は、本願補正発明における「ハードウェアアクセラレータ」と実質的な相違はなく、また、もし相違があったとしても、「ハードウェア支援設計検証システム」が、「ハードウェアアクセラレータ」と「ホストワークステーション」のみから構成されて「ユーザー設計を検証する」システムは、周知技術であり、刊行物１発明を「ハードウェア支援設計検証システム」が、「ハードウェアアクセラレータ」と「ホストワークステーション」のみから構成されて「ユーザー設計を検証する」システムとすることに困難性はないため、追加されたオーバーヘッドによって、低いシミュレーション動作性を示すことはないと考えられ、上記５．（ア）に記載したように、パケットを使用して通信を行う場合に、当該パケットを蓄積する蓄積媒体としてパケットレジスタを使用することは、常とう手段であり、入力情報蓄積媒体及び出力情報蓄積媒体をともにパケットレジスタで構成することは、当業者が適宜なし得ることであり、また、入力情報蓄積媒体及び出力情報蓄積媒体をともにパケットレジスタで構成すると、「ユーザー設計」を検証する際に、「ユーザー設計」を「停止状態」としなくても検証可能となることは明らかであるし、そもそも「ユーザー設計」を検証する際に、「ユーザー設計」を「停止状態」とするかしないかは、「ユーザー設計」の「検証システム」の使用態様であり、ユーザーが当該「検証システム」をどのように使用するかに応じて、適宜選択し得る事項に過ぎないから、ユーザー設計を停止状態に保持する必要があるかないかは、本願補正発明の進歩性を判断するための基準とはなり得ないため、上記請求人の主張を採用することはできない。
　
（エ）回答（４）について
　請求人は、
「前述しましたように、引用例５に記載されているシミュレーションモデラーは、第１発明のように、ハードウェアアクセラレータを使用することによって実効性を向上させるものではありません。また、引用例に記載されているシミュレーションモデラー（３つのルーター８０、８２および８４）は、第１発明の、ユーザー設計を停止状態に保持させる必要がない「ユーザー設計内に統合されるプロトコル論理（入力パケットレジスタ、出力パケットレジスタ、コマンドデコード論理、書込コマンド実行論理、読出コマンド実行論理）」を有していません。このため、ハードウェアアクセラレータを使用して、ユーザー設計が、引用例５に記載されている３つのルーター８０、８２および８４によって実行される場合には、ハードウェアアクセラレータを使用することによって期待される実効性の重大な低下をもたらすことになります。
　したがって、前置審査官の指摘は承服することができません。」
と主張しているが、上記２．において記載したように、刊行物１から刊行物１発明を認定する際、ルーター８４のみが関係し、ルーター８０及び８２は関係せず、また、上記４．（ウ）に記載したように、「ユーザー設計内に統合されるプロトコル論理」は、周知技術であり、刊行物１発明におけるプロトコル論理に相当する構成について、「ユーザー設計内に統合される」ようにすることは、当業者が適宜なし得ることであるから、上記請求人の主張を採用することはできない。
　
（オ）回答（５）について
　請求人は、
「本願の図３に示されていますように、入力パケットレジスタ８０は、ユーザー設計（ＤＵＶ３０）の「内部レジスタおよびメモリ」にデータを転送するためのデータチャンネル５０を有しています。そして、第１発明では、ＮＥＷＩＮ信号８３で示される新しいパケットが到達すると直ちに入力データが転送される、ユーザー設計の「内部レジスタおよびメモリ」を用いることによって、バッファのオーバーフローの恐れを克服しています。ユーザー設計の「内部レジスタおよびメモリ」を用いることによる利点は、引用例５に記載されているバッファがソフトウェア（ＦＩＦＯ）バッファであるため、引用例５では達成されません。加えて、引用例５に記載されているソフトウェアバッファは、ユーザー設計（ＤＵＳ４８）の外部のルーター８０、８２および８４で展開されます。
　したがって、前置審査官の指摘は承服することができません。」
と主張しているが、本願の請求項に、上記「ユーザー設計（ＤＵＶ３０）の「内部レジスタおよびメモリ」にデータを転送するためのデータチャンネル５０を有して」いること、上記「ＮＥＷＩＮ信号８３で示される新しいパケットが到達すると直ちに入力データが転送される、ユーザー設計の「内部レジスタおよびメモリ」を用いることによって、バッファのオーバーフローの恐れを克服」することは記載されていないため、本願補正発明の構成として、上記「ユーザー設計（ＤＵＶ３０）の「内部レジスタおよびメモリ」にデータを転送するためのデータチャンネル５０を有して」いること、上記「ＮＥＷＩＮ信号８３で示される新しいパケットが到達すると直ちに入力データが転送される、ユーザー設計の「内部レジスタおよびメモリ」を用いることによって、バッファのオーバーフローの恐れを克服」することは存在せず、上記請求人の主張は、本願補正発明に基づく主張ではないため、採用することはできない。なお、通信の際に、オーバーフローが生じないような構成を採用することは、当然行われることであり、ソフトウェア（ＦＩＦＯ）バッファであっても、オーバーフローを生じないような構成（例えば、容量を大きくする）とすることは、当業者が当然に行うことである。また、上記３．（オ）に記載したように、「エミュレーションモデリング装置５４」内にある「参照構成要素１２２」以外の構成は、本願補正発明における「プロトコル論理」に相当し、上記４．（ウ）に記載したように刊行物１発明におけるプロトコル論理を、「ユーザー設計内に統合される」ようにすることは、当業者が適宜なし得ることであるから、刊行物１において、ソフトウェアバッファが、ユーザー設計（ＤＵＳ４８）の外部のルーター８０、８２および８４で展開されることが記載されていたとしても、本願補正発明の進歩性の判断にを左右する根拠とはなり得ない。
　
（カ）回答（６）について
　請求人は、
「引用例５に記載されている“emulation　model　default/debug　access　generators　96　and　98”は、図７に示されていますように、エミュレーションＤＵＳアクセス１００を介してユーザー設計（ＤＵＳ４８）と通信します。このため、引用例５に記載されている“emulation　model　default/debug　access　generators　96　and　98”は、第１発明の「ユーザー設計内に統合される書込コマンド実行論理」および「ユーザー設計内に統合される読出コマンド実行論理」に対応しません。なぜなら、第１発明は、「ユーザー設計内に統合されるプロトコル論理は、書込実行コマンド論理、読出実行コマンド論理を有している」、すなわち、「書込実行コマンド論理および読出実行コマンド論理は、ユーザー設計内に統合されている」のに対し、引用例５に記載されている“emulation　model　default/debug　access　generators　96　and　98”は、ユーザー設計（ＤＵＳ４８）の外部に設けられているからです。
　したがって、引用例５には、第１発明の「ユーザー設計内に統合される書込コマンド実行論理」および「ユーザー設計内に統合される読出コマンド実行論理」は記載されていません。また、引用例２にも、第１発明の「ユーザー設計内に統合される書込コマンド実行論理」は記載されていません。
　このため、前置審査官の指摘は承服することができません、」
と主張しているが、上記３．（オ）に記載したように、「エミュレーションモデリング装置５４」内にある「参照構成要素１２２」以外の構成は、本願補正発明における「プロトコル論理」に相当し、上記３．（キ）に記載したように、刊行物１発明には、上記「レジスタ」に対して、何らかの読み出し用の情報及び書き込み用の情報を使用して、データを読み出し及び書き込みする論理が存在し、上記４．（ウ）に記載したように刊行物１発明におけるプロトコル論理を、「ユーザー設計内に統合される」ようにすることは、当業者が適宜なし得ることであるから、刊行物１において、“emulation　model　default/debug　access　generators　96　and　98”が、ユーザー設計（ＤＵＳ４８）の外部に設けられることが記載され、「ユーザー設計内に統合される書込コマンド実行論理」および「ユーザー設計内に統合される読出コマンド実行論理」が直接記載されていないとしても、本願補正発明の進歩性の判断を左右する根拠とはなり得ない。
　
（キ）回答（７）について
　請求人は、
「第１および第２発明は、平成１９年３月３０日付けの拒絶理由通知書で引用された引用例５および引用例２、平成１９年１１月２０日付けの拒絶査定で引用された引用例９はもとより、前記拒絶理由通知書で引用された引用文献１、３、４、６にも、第１および第２発明の構成要件である、ユーザー設計を停止状態に保持させる必要なく、ハードウェアアクセラレータを用いるハードウェア支援設計検証システムにおけるハードウェア検証の動作性を高めるための、『「ホストワークステーションから送信されるデータおよびコマンドを含むパケットを蓄積する入力パケットレジスタ」と、ホストワークステーションに送信されるデータを含むパケットを蓄積する出力パケットレジスタ」と、「入力パケットレジスタ内のコマンドをデコードするコマンドデコード論理」と、「コマンドデコード論理でデコードされた書込コマンドに対して、入力パケットレジスタ内に蓄積されているデータを、ユーザー設計内のレジスタあるいはメモリ位置に書き込む書込コマンド実行論理」と、「コマンドデコード論理でデコードされた読出コマンドに対して、ユーザー設計内のレジスタあるいはメモリ位置からデータを読み出し、当該データを出力パケットレジスタ内に蓄積する読出コマンド実行論理」を有している「ユーザー設計内に統合されるプロトコル論理」』についてなんら記載されて示唆する記載もありません。また、引用文献１〜６に記載されている技術をどのように組み合わせても、第１及び第２発明の「ユーザー設計内に統合されるプロトコル論理」を容易に想到することはできません。」
と主張しているが、上記４．に記載したように、上記各相違点を総合的に検討しても、ユーザー設計を検証するシステムという同一の技術分野に属する上記刊行物１発明及び上記周知技術を組み合わせることにより、本願補正発明を構成することは、当業者が容易に想到し得ることであり、その作用効果も当業者が予測し得るものにすぎないから、上記請求人の主張を採用することはできない。
　
６．本件補正についてのむすび
　以上のとおり、本件補正は平成１８年改正前特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので、特許法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
第３　本願発明について
１．本願発明
　平成２０年３月２１日付けの手続補正は上記のとおり却下されたので、本願の請求項に係る発明は、平成１９年１０月２日付け手続補正書により補正された明細書の特許請求の範囲の請求項１及び２に記載されたとおりのものであるところ、請求項１に係る発明（以下、「本願発明」という。）は、上記「第２〔理由〕１．」の本件補正前の請求項１として記載したとおりのものである。
　
２．引用例
　原査定の拒絶の理由で引用された引用例１及びその記載事項は、上記「第２〔理由〕２．」における刊行物１に関して記載したとおりである。
　
３．対比・判断
　本願発明は、上記「第２〔理由〕」で検討した本願補正発明から、本件補正前の請求項１に記載されていた「目標設計」を「ユーザー設計」とした限定を解除したものである。
　
　そうすると、本願発明の構成要件を全て含み、更に構成要件の一部に限定を行ったものである本願補正発明が、前記「第２〔理由〕４．」に記載したとおり、刊行物１に記載された発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、本願発明は、刊行物１に記載された発明に基づいて当業者が容易に発明をすることができたものである。
　
第４　むすび
　以上のとおり、本願の請求項１に係る発明は、特許法第２９条第２項の規定により特許を受けることができないものである。
　したがって、その余の請求項について論及するまでもなく、本願は、拒絶すべきものである。
　よって、結論のとおり審決する。