ポートフォリオ機能
| ポートフォリオを新規に作成して保存 |
|
|
| 既存のポートフォリオに追加保存 |
|
PDFをダウンロード
|
| 審決分類 |
審判 査定不服 2項進歩性 特許、登録しない。 H04L |
|---|---|
| 管理番号 | 1263658 |
| 審判番号 | 不服2010-16664 |
| 総通号数 | 155 |
| 発行国 | 日本国特許庁(JP) |
| 公報種別 | 特許審決公報 |
| 発行日 | 2012-11-30 |
| 種別 | 拒絶査定不服の審決 |
| 審判請求日 | 2010-07-23 |
| 確定日 | 2012-09-19 |
| 事件の表示 | 特願2007-503036「高データレートインタフェース装置及び方法」拒絶査定不服審判事件〔平成17年 9月22日国際公開、WO2005/088939、平成19年10月11日国内公表、特表2007-528681〕について、次のとおり審決する。 |
| 結論 | 本件審判の請求は、成り立たない。 |
| 理由 |
第1.手続の経緯・本願発明 本願は、平成17年3月10日(パリ条約による優先権主張、外国庁受理2004年3月10日、2004年3月17日、米国)を国際出願日とする出願であって、平成22年3月15日付けで拒絶査定がなされ、これに対して、同年7月23日に審判請求がなされると共に、同日付けで手続補正がなされたものである。 上記手続補正は、補正前の請求項2-45を削除し、補正前の請求項1を残したものである。 したがって、上記補正は、平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第4項第1号に規定する、請求項の削除を目的とするものであって、適法になされた補正である。 その請求項1に係る発明(以下、本願発明という。)は、上記補正により補正された明細書、特許請求の範囲及び図面の記載からみて、特許請求の範囲、請求項1に記載された以下のとおりのものであると認める。 「クライアントがホストと同期していることを確認し、第1インタフェースタイプから第2インタフェースタイプへの動的な変更を実行する方法であって、 前記ホストによって逆方向カプセル化パケットを前記クライアントに送ることと、 前記クライアントから前記ホストに応答パケットを送ることと、 前記応答パケットが前記ホストで受け取られたことを前記ホストによって確認することと、 前記クライアントに、前記第1インタフェースタイプを使用することから前記第2インタフェースタイプを使用することへハンドオフするように命令することと、 のステップを備える方法。」 第2.引用例 原査定の拒絶の理由に引用された国際公開第02/49314号(平成14年6月20日公開、以下、「引用例」という。)には、「GENERATING AND IMPLEMENTING A COMMUNICATION PROTOCOL AND INTERFACE FOR HIGH DATA RATE SIGNAL TRANSFER」(邦訳:「通信プロトコルの発生と実施および高いデータレート信号転送のためのインターフェース」)として、図面とともに、以下の事項が記載されている。 イ.「 8. Reverse Link Encapsulation Packets [0162] Data is transferred in the reverse direction using a Reverse Link Encapsulation Packet. A forward link packet is sent and the MDDI link operation (transfer direction) is changed or turned around in the middle of this packet so that packets can be sent in the reverse direction. The format of the Reverse Link Encapsulation packet is illustrated in FIG. 17. As shown in FIG. 17, this type of packet is structured to have Packet Length, Packet Type, Reverse Link Flags, Turn- Around Length, Parameter CRC, Turn-Around 1, Reverse Data packets, and Turn-Around 2. This type of packet is generally identified as a Type 65 packet. [0163] The MDDI link controller behaves in a special manner while sending a Reverse Link Encapsulation Packet. The MDD interface has a strobe signal that is always driven by the host. The host behaves as if it were transmitting a zero for each bit of the Turn- Around and Reverse Data Packets portions of the Reverse Link Encapsulation packet. The host toggles MDDI_Strobe signal at each bit boundary during the two turn-around times and during the time allocated for reverse data packets. (This is the same behavior as if it were transmitting all-zero data.) The host disables its MDDI data signal line drivers during the time period specified by Turn- Around 1, and the client re-enables its line drivers during the Driver Re-enable field following the time period specified by Turn-Around 2 field. The display reads the Turn-Around Length parameter and drives the data signals toward the host immediately after the last bit in the Turn-Around 1 field. The display uses the Packet Length and Turn-Around Length parameters to know the length of time it has available to send packets to the host. The client may send filler packets or drive the data lines to a zero state when it has no data to send to the host. If the data lines are driven to zero, the host interprets this as a packet with a zero length (not a valid length) and the host does not accept any more packets from the client for the duration of the current Reverse Link Encapsulation Packet. 」(35頁1-26行) 邦訳 「8.逆方向リンクカプセル化パケット [0162]データは、逆方向リンクカプセル化パケットを用いて逆方向に転送される。順方向リンクパケットが送信され、MDDIリンク動作(転送方向)がパケットの中央で変化または方向転換されるので、パケットは、逆方向に送信することができる。逆方向リンクカプセル化パケットのフォーマットは図17に図解される。図17に示すように、このタイプのパケットは、パケット長、パケットタイプ、逆方向リンクフラッグ、方向転換レングス、パラメータCRC、方向転換1、逆方向データパケット、および方向転換2を持つように構成される。このタイプのパケットは、一般にタイプ65パケットとして識別される。 [0163]MDDIリンクコントローラは、逆方向リンクカプセル化パケットを送信しながら、特別な方法で振舞う。MDDインターフェースは、常にホストにより駆動されるストローブ信号を有する。ホストは、逆方向リンクカプセル化パケットの方向転換パケットおよび逆方向データパケットの各ビットに対してあたかもゼロを送信するかのように振舞う。ホストは、2回の方向転換の期間および逆方向データパケットに対して割当てられた時間期間に各ビット境界において、MDDI_Sｔｒｏbe信号をトグルする。(これは、ホストがあたかも全てゼロのデータを送信しているのと同じ振る舞いである。)ホストは、方向転換1により指定される時間期間にMDDIデータ信号ラインドライバをディスエーブルにし、クライアントは、方向転換2フィールドにより指定される時間期間に続くドライバ再イネーブル期間にそのラインドライバを再イネーブルにする。ディスプレイは方向転換レングスパラメータをリードし、方向転換1フィールド内の最後のビットの直後にホストに向けてデータ信号を駆動する。ディスプレイは、パケットレングスパラメータと方向転換レングスパラメータを用いて、ホストにパケットを送信するために利用可能な時間の長さを知る。クライアントは、ホストに送信すべきデータが無いとき、フィラーパケットを送信することができ、またはデータラインをゼロ状態に駆動することができる。データラインがゼロに駆動されると、ホストはこれをゼロの長さ(正しい長さではない)を有するパケットとして解釈し、ホストは、現在の逆方向リンクカプセル化パケットの期間、クライアントからこれ以上のパケットを受付けない。」 ロ.「18. Interface Type Handoff Request Packets [0180] The Interface Type Handoff Request Packet enables the host to request that the client or display shift from an existing or current mode to the Type-I (serial), Type-II (2- bit parallel), Type-III (4-bit parallel), or Type-IV (8-bit parallel) modes. Before the host requests a particular mode it should confirm that the display is capable of operating in the desired mode by examining bits 6 and 7 of the Display Feature Capability Indicators field of the Display Capability Packet. The format of a Interface Type Handoff Request Packet is shown in FIG. 27. As shown in FIG. 27, this type of packet is structured to have Packet Length, Packet Type, Interface Type, and CRC fields. This type of packet is generally identified as a Type 75 packet, and uses a pre-selected fixed length of 4 bytes. 19. Interface Type Acknowledge Packets [0181] The Interface Type Acknowledge Packet is sent by the display to confirm receipt of the Interface Type Handoff Packet. The requested mode, Type-I (serial), Type-II (2- bit parallel), Type-III (4-bit parallel), or Type-IV (8-bit parallel) mode, is echoed back to the host as a parameter in this packet. The format of a Interface Type Acknowledge Packet is shown in FIG. 28. As shown in FIG. 28, this type of packet is structured to have Packet Length, Packet Type, Interface Type, and CRC fields. This type of packet is generally identified as a Type 76 packet, and uses a pre-selected fixed length of 4 bytes. 20. Perform Type Handoff Packets [0182] The Perform Type Handoff Packet is a means for the host to command the display to handoff to the mode specified in this packet. This is to be the same mode that was previously requested and acknowledged by the Interface Type Handoff Request Packet and Interface Type Acknowledge Packet. The host and display should switch to the agreed upon mode after this packet is sent. The display may lose and re-gain link synchronization during the mode change. The format of a Perform Type Handoff Packet is shown in FIG. 29. As shown in FIG. 29, this type of packet is structured to have Packet Length, Packet Type, Packet Type, and CRC fields. This type of packet is generally identified as a Type 77 packet in the 1-byte type field, and uses a pre-selected fixed length of 4 bytes.」(40頁17行-41頁19行) 邦訳 「18.インタフェースタイプハンドオフリクエストパケット [0180]インターフェースタイプハンドオフリクエストパケットは、クライアントまたはディスプレイが、既存のモードまたは現在のモードからタイプ1(シリアル)モード、タイプ2(2ビットパラレル)モード、タイプ3(4ビットパラレル)モードまたはタイプ4(8ビットパラレル)モードに推移することをホストが要求することを可能にする。ホストが特定のモードを要求する前に、ホストは、ディスプレイ能力パケットのディスプレイ特徴能力インジケータフィールドのビット6およびビット7を調べることにより、ディスプレイが所望のモードで動作可能であることを確認する必要がある。インタフェースタイプハンドオフリクエストパケットのフォーマットは図27に示される。図27に示すように、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、インターフェースタイプフィールドおよびCRCフィールドを持つように構成される。このタイプのパケットは一般的にタイプ75パケットとして識別され、4バイトのあらかじめ選択された固定長を使用する。 19.インターフェースタイプアクノレジパケット [0181]インターフェースタイプアクノレジパケットは、インターフェースハンドオフパケットの受信を確認するためにディスプレイにより送信される。要求されたモード、すなわち、タイプ1(シリアル)、タイプ2(2ビットパラレル)、タイプ3(4ビットパラレル)またはタイプ4(8ビットパラレル)モードはこのパケット内のパラメータとしてエコーバックされる。インターフェースタイプアクノレジパケットは図28に示される。図28に示すように、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、インターフェースタイプフィールド、およびCRCフィールドを持つように構成される。このタイプのパケットは一般的にタイプ76パケットとして識別され、4バイトのあらかじめ選択された固定長を使用する。 20.実行タイプハンドオフパケット [0182]実行タイプハンドオフパケットは、ホストがディスプレイに対してこのパケット内で指定されたモードにハンドオフするように命令するための手段である。これは、インターフェースタイプハンドオフリクエストパケットおよびインターフェースタイプアクノレジパケットにより以前に要求されアクノレジされたモードと同じモードである。ホストとディスプレイはこのパケットが送信された後、一致したモードに切り替わらなければならない。ディスプレイは、モード変更の期間にリンクの同期を失い、取り戻すようにしてもよい。実行タイプハンドオフパケットのフォーマットは図29に示される。図29に示すように、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、およびインターフェースタイプフィールドおよびCRCフィールドを持つように構成される。このタイプのパケットは一般的に1バイトタイプフィールド内でタイプ77パケットとして識別され、4バイトのあらかじめ選択された固定長を使用する。」 ハ.「[0229] In order for image data to be viewed on a display (micro-display), or to reliably receive all packets sent by the host, the display signal processing must be synchronized with the forward link channel timing. That is, signals arriving at the display and the display circuits must be time synchronized for proper signal processing to occur. A high level diagram of states achieved by signal processing steps or a method by which such a synchronization can be implemented is presented in the illustration of FIG. 49. In FIG. 49, the possible forward link synchronization "states" for a state machine 4900 are shown being categorized as one Async Frames State 4904, two Acquiring Sync States 4902 and 4906, and three In-Sync States 4908, 4910, and 4912.」(57頁26行-58頁3行) 邦訳 「[0229]画像データがディスプレイ(マイクロディスプレイ)上で見えるために、またはホストにより送信されたすべてのパケットを確実に受信するために、表示信号処理は、順方向リンクチャネルタイミングと同期を取らなければならない。すなわち、ディスプレイに到着する信号および表示回路は、適切な信号処理を発生するために、時間同期されなければならない。信号処理レベルにより得られる高レベルの状態図またはそのような同期が実施できる方法は図49の説明図に提示される。図49において、ステートマシン4900のための可能な順方向リンク同期「状態」が、1つの非同期フレーム状態4904、2つの獲得同期状態4902および4906、および3つの同期状態4908、4910、および4912として、分類されて示される。」 ニ.「[0236] As stated earlier, at the time of "start-up", the host configures the forward link to operate at or below a minimum required, or desired, data rate of 1 Mbps, and configures the sub-frame length and media-frame rate appropriately for a given application. That is, both the forward and reverse links begin operation using the Type-I interface. These parameters are generally only going to be used temporarily while the host determines the capability or desired configuration for the client display (or other device). The host sends or transfers a sub-frame Header Packet over the forward link followed by a Reverse Link Encapsulation Packet which has bit '0' of the Request Flags set to a value of one (1), in order to request that the display responds with a Display Capability Packet. Once the display acquires synchronization on (or with) the forward link, it sends a Display Capability Packet and a Display Request and Status Packet over the reverse link or channel.」(60頁1-13行) 邦訳 「C.初期化 [0236]上述したように、「開始」の時刻において、ホストは順方向リンクを最低限必要なデータレートまたはそれを下回るデータレート、または所望の1Mbｐｓで動作するように構成し、所定のアプリケーションに対して適切にサブフレーム長およびメディアフレームレートを構成する。すなわち、順方向リンクおよび逆方向リンクはタイプIインターフェースを用いて動作を開始する。これらのパラメータは一般には、ホストがクライアントディスプレイ(または他の装置)に対して能力または所望の構成を決定する間、一時的に使用されるだけである。ホストは、ディスプレイがディスプレイ能力パケットに応答することを要求するために、要求フラッグのビット「0」が(1)の値に設定された逆方向リンクカプセル化パケットに続いて順方向リンクを介してサブフレームヘッダパケットを送信または転送する。ディスプレイが順方向リンク上で(または順方向リンクを用いて)同期を獲得すると、ディスプレイは、逆方向リンクまたはチャネルを介してディスプレイ能力パケットおよびディスプレイリクエストおよびステータスパケットを送信する。」 ホ.「[0264] Once a client is connected to the host, or visa versa, , or detected as present, either the client or the host sends appropriate packets requesting service in steps 5404 and 5406. The client could send either Display Service Request or Status packets in step 5404. It is noted that the link, as discussed above, could have been previously shut down or be in hibernation mode so this may not be a complete initialization of the communication link that follows. Once the communication link is synchronized and the host is trying to communicate with the client, the client also needs to provide Display Capabilities packet to the host, as in step 5408. The host can now begin to determine the type of support, including transfer rates, the client can accommodate. [0265] Generally, the host and client also negotiate the type (rate/speed) of service mode to be used, for example Type I, Type U, Type II, and so forth, in a step 5410. Once the service type is established the host can begin to transfer information. In addition, the host may use Round Trip Delay Measurement Packets to optimize the timing of the communication links in parallel with other signal processing, as shown in step 5411. [0266] As stated earlier, all transfers begin with a Sub-Frame Header Packet, shown being transferred in step 5412, followed by the type of data, here video and audio stream packets, and filler packets, shown being transferred in step 5414. The audio and video data will have been previously prepared or mapped into packets, and the filler packets are inserted as needed to fill out the required number of bits for the media frames. The host can send packets such as the Forward Audio Channel Enable Packets to activate sound device, or In addition, the host can transfer commands and information using other packet types discussed above, here shown as the transfer of Color Map, Bit Block Transfer or other packets in step 5416. In addition, the host and client can exchange data relating to a keyboard or pointing devices using the appropriate packets. [0267] During operation one of several different events can occur which lead to the host or client desiring a different data rate or type of interface mode. For example, a computer or other device communicating data could encounter loading conditions in processing data that causes a slow down in the preparation or presentation of packets. A display receiving the data could change from a dedicated AC power source to a more limited battery power source, and either not be able to transfer in data as quickly, process commands as readily, or not be able to use the same degree of resolution or color depth under the more limited power settings. Alternatively, a restrictive condition could be abated or disappear allowing either device to transfer data at higher rates. This being more desirable, a request can be made to change to a higher transfer rate mode. [0268] If these or other types of known conditions occur or change, either the host or client may detect them and try to renegotiate the interface mode. This is shown in step 5420, where the host sends Interface Type Handoff Request Packets to the client requesting a handoff to another mode, the client sends Interface Type Acknowledge Packets confirming a change is sought, and the host sends_Perform Type Handoff Packets to make the change to the specified mode.」(69頁25行-71頁2行) 邦訳 「[0264]クライアントがホストに接続されると、または逆の場合も同じであるが、または存在するとして検出されると、クライアントまたはホストは、ステップ5404および5406において、サービスを要求する適当なパケットを送信する。クライアントはステップ5404において、ディスプレイサービスリクエストまたはステータスパケットに送信することができる。上述したように、リンクは以前に停止することができたあるいはハイバネーションモードにいることができたので、これは次に続く通信リンクの完全な初期化でないかもしれない。通信リンクが同期化され、ホストがクライアントと通信しようとすると、クライアントは、ステップ5408において、ディスプレイ能力パケットをホストに供給する必要もある。ホストは今、クライアントが適合することができる転送レートを含むサポートのタイプを判定することを開始することができる。 [0265]一般的に、ホストとクライアントはステップ5410において、使用されるサービスモードのタイプ(レート/速度)、例えばタイプ1、タイプU、タイプ2等をネゴシエートする。サービスタイプが確立されると、ホストは情報の転送を開始することができる。さらに、ステップ5411に示すように、他の信号処理と並列に通信リンクのタイミングを最適化するために、ホストは往復遅延測定パケットを使用してもよい。 [0266]上述したように、すべての転送は、サブフレームヘッダパケットがステップ5412において転送されるように示されることで始まり、ステップ5414において、データのタイプ、ここでは、ビデオおよびオーディオストリームパケット、およびフィラーパケットが転送されるように示される。オーディオデータおよびビデオデータは、以前にパケットに作られまたはマップされていたであろう、そして、フィラーパケットは、媒体フレームに対して必要な数のビットを書き込むために必要に応じて挿入される。ホストは音響装置をアクティブにするために、順方向オーディオチャネルイネーブルパケットのようなパケットを送信することができる。さらに、ステップ5416において、上述した他のパケットタイプを用いてコマンドおよび情報を転送することができる。ここでは、カラーマップの転送、ビットブロック転送、または他のパケットの転送として示される。さらに、ホストとクライアントは適当なパケットを用いてキーボードまたはポインティングデバイスに関連するデータを交換することができる。 [0267]動作中に、所望の異なるデータレートまたはタイプのインターフェースモードを所望するホストまたはクライアントに導くいくつかの異なるイベントの1つを生じることができる。例えば、データを通信するコンピュータまたは他の装置は、パケットの製作または提示において減速を生じさせるデータを処理中にローディング条件に遭遇することもありえる。そのデータを受信するディスプレイは、専用のAC電源からより制限されたバッテリー電源に切り替わるということもあり得る。そして、データを迅速に転送することができず、容易にコマンドを処理することができないか、またはより制限された電源設定の下で同じ程度の分解能または色の深さを使用することができない。あるいは、制限条件が低減されあるいは消失され、どちらか一方の装置がより高いレートでデータを転送することを可能にする。これはより高い転送レートモードに変更するための要求を行うことができるので、より望ましい。 [0268]これらのまたは他のタイプの周知の条件が生じるまたは変化するなら、ホストまたはクライアントはそれらを検出し、インターフェースモードを再交渉しようと試みる。これは、ステップ5420に示される。ここでは、ホストは、他のモードへのハンドオフを要求しているクライアイントにインターフェースタイプハンドオフリクエストパケットを送信し、クライアントは変更が求められたことを確認するインターフェースアクノレジパケットを送信し、そしてホストは、指定されたモードに変更するために実行タイプハンドオフパケットを送信する。」 ここで、上記イ.?ホ.の記載、関連図面ならびにこの分野における技術常識を考慮すると、 上記ホ.の、「[0268]これらのまたは他のタイプの周知の条件が生じるまたは変化するなら、ホストまたはクライアントはそれらを検出し、インターフェースモードを再交渉しようと試みる。これは、ステップ5420に示される。ここでは、ホストは、他のモードへのハンドオフを要求しているクライアントにインターフェースタイプハンドオフリクエストパケットを送信し、クライアントは変更が求められたことを確認するインターフェースアクノレジパケットを送信し、そしてホストは、指定されたモードに変更するために実行タイプハンドオフパケットを送信する。」には、「インターフェースタイプハンドオフリクエストパケット」、「インターフェースアクノレジパケット」、および、「実行タイプハンドオフパケット」の一連の送信動作によるインターフェースタイプを変更する方法について示されている。 また、「条件が生じ」たことに対応する、または、「条件が」「変化する」ことに対応したホストまたはクライアントによるインターフェースモードの再交渉は、「動的」ということができ、「インターフェースタイプの動的な変更を実行する方法」について示されているといえる。 上記ロ.には、「インタフェースタイプハンドオフリクエストパケット」、「インターフェースタイプアクノレジパケット」、および、「実行タイプハンドオフパケット」について記載され、「インターフェースタイプアクノレジパケット」はディスプレイにより送信されるものであること、また、「実行タイプハンドオフパケット」は、「インターフェースタイプハンドオフリクエストパケット」および「インターフェースタイプアクノレジパケット」により以前に要求されアクノレジされたモードと同じモードとなるよう、ディスプレイに対して、インターフェイスタイプをハンドオフするように命令するものであることが示されている。 ここで、「ディスプレイ」は「クライアントまたはディスプレイ」とあるように、「クライアント」と同等のものである。 また、「インタフェースタイプハンドオフリクエストパケット」、「インターフェースタイプアクノレジパケット」、および、「実行タイプハンドオフパケット」の送出によって、以前に要求されアクノレジされたモードと同じモードとなるように命令を送出する一連の動作は、「ステップを備える方法」ということができる。 したがって、「ホストからクライアントにインターフェースタイプハンドオフリクエストパケットを送ることと、クライアントからホストにインターフェースタイプアクノレジパケットを送ることと、アクノレジされたモードに、ハンドオフすることを命令するため、クライアントにインターフェースタイプをハンドオフするように命令することと、のステップを備える方法」について記載されている。 これらより、上記引用例には以下の発明(以下、「引用発明」という。)が記載されている。 「インターフェースタイプの動的な変更を実行する方法であって、 ホストからクライアントにインターフェースタイプハンドオフリクエストパケットを送ることと、 クライアントからホストにインターフェースタイプアクノレジパケットを送ることと、 アクノレジされたモードに、ハンドオフすることを命令するため、前記クライアントにインターフェースタイプをハンドオフするように命令することと、 のステップを備える方法」 第3.対比・判断 (1)対比 本願発明と引用発明とを対比する。 引用発明の「インターフェース」は、明らかに、本願発明の「インタフェース」に相当する。 そして、引用発明の「インターフェースタイプ」は、ホストとクライアントとのインタフェースのモードを示すタイプであり、本願発明の「インタフェースタイプ」に相当する。 引用発明の「インターフェースタイプ」の「変更」は、一のインターフェースタイプを、他のインターフェースタイプに変更することである。ここで「一の」を「第1」、「他の」を「第2」と呼ぶことは任意であるから、本願発明の「第1インタフェースタイプから第2インタフェースタイプへの」「変更」に相当する。 引用発明の「アクノレジパケット」は、要求に対する応答のためのパケットであり、本願発明の「応答パケット」に相当する。 本願発明の「応答パケットがホストで受け取られたことをホストによって確認することと、」は、「前記クライアントから前記ホストに応答パケットを送ることと、」と「前記クライアントに、前記第1インタフェースタイプを使用することから前記第2インタフェースタイプを使用することへハンドオフするように命令することと、」の間に行われるステップとして特定された事項である。 ここで、本願明細書における、「【0505】もしこれらの或いは他のタイプの知られている条件が発生する或いは変化する場合、ホスト又はクライアントのどちらかはそれらを検出し、そしてインタフェースモードを再交渉しようとしてよい。これはステップ5420において示され、ここでは、ホストは、別のモードへのハンドオフを要求するクライアントに、インタフェースタイプハンドオフ要求パケットを送信し、クライアントは、変更が求められることを確認するインタフェースタイプ肯定応答パケットを送信し、そしてホストは、指定されたモードに変更するために実行型ハンドオフパケットを送信する。」とのハンドオフのステップに関する記載を参照しても、「クライアントは、変更が求められることを確認するインタフェースタイプ肯定応答パケットを送信し」と、「そしてホストは、指定されたモードに変更するために実行型ハンドオフパケットを送信する。」との間に特別のステップは示されていない。 したがって、該「応答パケットがホストで受け取られたことをホストによって確認することと、」のステップは、モードの変更を確認するための応答パケットがホストによって受け取られ、また、その受け取りが正常に行われたことをホスト自身が確認するという、応答パケットの送受信に関し通常行われる、当然の動作ステップ以上の技術的事項を示すものではないといえる。 一方、引用発明の「アクノレジ」とは、一般に、正しくデータが受信されたことを示す信号が送信側に返ってくることを意味するものである。引用発明の「アクノレジされたモード」は、送信側に帰ってきた信号を受け取り、その受け取りによって、モード(インタフェースタイプ)を確認したことを意味するものであり、本願発明の「応答パケットがホストで受け取られたことをホストによって確認すること」に相当するものである。 引用発明の「ハンドオフすることを命令するため、前記クライアントに、実行タイプハンドオフパケットを送信する」は、インターフェイスタイプを一のものから、他のものに変更(ハンドオフ)することを命令するものであって、「一の」を「第1」、「他の」を「第2」と呼ぶことは任意であるから、本願発明の「前記クライアントに、前記第1インタフェースタイプを使用することから前記第2インタフェースタイプを使用することへハンドオフするように命令すること」に相当する。 よって、本願発明と引用発明は、以下の点で一致ないし相違している。 (一致点) 「第1インタフェースタイプから第2インタフェースタイプへの動的な変更を実行する方法であって、 前記クライアントから前記ホストに応答パケットを送ることと、 前記応答パケットが前記ホストで受け取られたことを前記ホストによって確認することと、 前記クライアントに、前記第1インタフェースタイプを使用することから前記第2インタフェースタイプを使用することへハンドオフするように命令することと のステップを備える方法」 (相違点1) 第1インタフェースタイプから第2インタフェースタイプへの動的な変更を実行するに際し、本願発明は、「クライアントがホストと同期していることを確認」しているに対し、引用発明では、そのようなことは行っていない点。 (相違点2) 「前記クライアントから前記ホストに応答パケットを送る」ステップの前に、本願発明では、「前記ホストによって逆方向カプセル化パケットを前記クライアントに送る」ステップを行っているのに対し、引用発明では、「前記ホストによって逆方向カプセル化パケットを前記クライアントに送る」ステップを行うことについて明示されていない点。 (2)当審の判断 まず、相違点1について検討する。 引用例の上記ハ.に、「ホストにより送信されたすべてのパケットを確実に受信するために、表示信号処理は、順方向リンクチャネルタイミングと同期を取らなければならない。」と記載されるように、ホストとクライアントとが同期を取ることは、送信及び受信が確実に行われるための前提となる事項であるといえる。 そして、引用例の上記ニ.には、「初期化」として、まず、所望の構成を決定する間、一時的に使用されるインターフェースタイプで所定のパケットを受信し、同期を確認することが記載されている。 初期化の動作に限らず、インタフェースタイプの変更の際に、所定のパケットの送信及び受信が行われることにより同期を確認することは、適宜なし得るものであり、「クライアントがホストと同期していることを確認し、第1インタフェースタイプから第2インタフェースタイプへの動的な変更を実行する方法」とすることは、当業者が容易に想到し得たものである。 次に、相違点2について検討する。 引用例には、逆方向のデータ伝送に関し、上記イ.に、「[0162]データは、逆方向リンクカプセル化パケットを用いて逆方向に転送される。順方向リンクパケットが送信され、MDDIリンク動作(転送方向)がパケットの中央で変化または方向転換されるので、パケットは、逆方向に送信することができる。」と記載されているように、「ホストによって逆方向リンクカプセル化パケットをクライアントに送る」ことにより、逆方向のデータ伝送が行われることが示されている。 したがって、引用発明において、クライアントからホストに応答パケットを送る際、つまり、逆方法にデータを送る際には、「ホストによって逆方向リンクカプセル化パケットをクライアントに送ること」が直前のステップとして実行されることは、明示されていなくとも明らかなものである。 ここで、本願発明の「逆方向カプセル化パケット」に関し、本願明細書の【0134】には、「データは逆方向リンクカプセル化パケットを使用して逆方向で転送される。順方向リンクパケットは送信され、MDDIリンク動作(転送方向)は、パケットが逆方向で送信できるようにこのパケットの真中のあたりで変更又は方向転換される。」とあるように、引用例の「逆方向リンクカプセル化パケット」と同様のものとして示されており、引用発明の「逆方向リンクカプセル化パケット」を、「逆方向カプセル化パケット」とすることに何らの差違はない。 そして、本願発明に関する作用・効果も引用発明から当業者が予測できる範囲のものである。 第4.結語 以上のとおり、本願発明は、引用発明に基づいて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。 よって、結論のとおり審決する。 |
| 審理終結日 | 2012-04-17 |
| 結審通知日 | 2012-04-24 |
| 審決日 | 2012-05-09 |
| 出願番号 | 特願2007-503036(P2007-503036) |
| 審決分類 |
P
1
8・
121-
Z
(H04L)
|
| 最終処分 | 不成立 |
| 前審関与審査官 | 吉田 隆之 |
| 特許庁審判長 |
藤井 浩 |
| 特許庁審判官 |
矢島 伸一 遠山 敬彦 |
| 発明の名称 | 高データレートインタフェース装置及び方法 |
| 代理人 | 堀内 美保子 |
| 代理人 | 竹内 将訓 |
| 代理人 | 村松 貞男 |
| 代理人 | 野河 信久 |
| 代理人 | 砂川 克 |
| 代理人 | 山下 元 |
| 代理人 | 峰 隆司 |
| 代理人 | 福原 淑弘 |
| 代理人 | 河野 哲 |
| 代理人 | 市原 卓三 |
| 代理人 | 岡田 貴志 |
| 代理人 | 勝村 紘 |
| 代理人 | 蔵田 昌俊 |
| 代理人 | 佐藤 立志 |
| 代理人 | 河野 直樹 |
| 代理人 | 中村 誠 |
| 代理人 | 幸長 保次郎 |
| 代理人 | 白根 俊郎 |