【事件の表示】
　特願２００２−　４２５８９「メッセージ処理方法」拒絶査定不服審判事件〔平成１４年１１月　８日出願公開、特開２００２−３２４０５５〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
　第１．手続の経緯
　本願は、平成９年６月１０日（以下、「原出願日」という。）に出願した特願平９−１５２４２６号の一部を平成１４年２月２０日に新たな特許出願としたものであって、平成１７年６月１日付けで拒絶理由通知がなされ、同年１１月３０日付けで手続補正がなされるとともに同日付けで意見書が提出され、同年１２月１９日付けで最後の拒絶理由通知がなされ、平成１８年３月１４日付けで手続補正がなされるとともに同日付けで意見書が提出されたが同年４月１０日付けで拒絶査定がなされ、これに対し、同年６月２１日に審判請求がなされるとともに、同日付けで手続補正がなされ、同年９月４日付けで前置報告がなされ、平成２０年９月９日付けで当審より審尋がなされ、同年１２月８日付けで回答書が提出されたが、平成１８年６月２１日付けでなされた手続補正は当審により平成２１年１月２６日付けで却下されるとともに、同日付けで当審より再度の最初の拒絶理由通知がなされ、同年３月１７日付けで手続補正がなされるとともに同日付けで意見書が提出され、同年５月１２日付けで当審より再度の最後の拒絶理由通知がなされ、同年８月１０日付けで手続補正がなされるとともに同日付けで意見書が提出されたものである。
　
　第２．平成２１年８月１０日付けの手続補正についての補正却下の決定
　［補正却下の決定の結論］
　平成２１年８月１０日付けの手続補正を却下する。
　
　［補正却下の決定の理由］
　（１）補正の内容
　平成２１年８月１０日付けの手続補正（以下、「本件補正」という。）は、平成２１年３月１７日付けの手続補正により補正された特許請求の範囲（以下、「補正前の特許請求の範囲」という。）の記載
　
「【請求項１】
　新たな会話が発生するたびに生成され、生成されたそれぞれが前記会話を担当することにより、複数の会話を非同期に同時に進行することができる会話スレッドと、
　前記会話スレッドの生成を制御可能な会話スレッド制御部と、
　前記会話のメッセージが送出されるネットワークに対応したプロトコルに、前記メッセージを変換するプロトコル・マネジャと、
　前記会話に使われているエージェント・コミュニケーション言語を他の言語に翻訳するトランスレータと、
　を含むソフトウェア部品を有し、
　ネットワークを介して他のメッセージ処理装置にメッセージを送出可能なメッセージ処理装置で実行されるメッセージ処理方法であって、
　（ａ）新たな会話が発生するたびに生成された前記会話スレッドを含んでいるソフトウェア部品を停止する段階と、
　（ｂ）前記ソフトウェア部品をシリアライズによりネットワーク上転送可能となるように転換し前記ネットワークを介して他のメッセージ処理装置に送出する段階と、
　（ｃ）シリアライズされた前記ソフトウェア部品を、前記他のメッセージ処理装置において、デ・シリアライジングにより再開する段階と、を含むメッセージ処理方法。
　
　【請求項２】
　新たな会話が発生するたびに生成され、生成されたそれぞれが前記会話を担当することにより、複数の会話を非同期に同時に進行することができる会話スレッドと、
　前記会話スレッドの生成を制御可能な会話スレッド制御部と、
　前記会話のメッセージが送出されるネットワークに対応したプロトコルに、前記メッセージを変換するプロトコル・マネジャと、
　前記会話に使われているエージェント・コミュニケーション言語を他の言語に翻訳するトランスレータと、
　を含むソフトウェア部品を有し、
　ネットワークを介して他のメッセージ処理装置にメッセージを送出可能なメッセージ処理装置で実行されるメッセージ処理システムであって、
　（ａ）新たな会話が発生するたびに生成された前記会話スレッドを含んでいるソフトウェア部品を停止する機能と、
　（ｂ）前記ソフトウェア部品をシリアライズによりネットワーク上転送可能となるように転換し前記ネットワークを介して他のメッセージ処理装置に送出する機能と、
　（ｃ）シリアライズされた前記ソフトウェア部品を、前記他のメッセージ処理装置において、デ・シリアライジングにより再開する機能と、を含むメッセージ処理システム。
　
　【請求項３】
　新たな会話が発生するたびに生成され、生成されたそれぞれが前記会話を担当することにより、複数の会話を非同期に同時に進行することができる会話スレッドと、
　前記会話スレッドの生成を制御可能な会話スレッド制御部と、
　前記会話のメッセージが送出されるネットワークに対応したプロトコルに、前記メッセージを変換するプロトコル・マネジャと、
　前記会話に使われているエージェント・コミュニケーション言語を他の言語に翻訳するトランスレータと、
　を含むソフトウェア部品を有し、
　ネットワークを介して他のメッセージ処理装置にメッセージを送出可能なメッセージ処理装置で実行されるメッセージ処理をコンピュータに実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体であって、
　（ａ）新たな会話が発生するたびに生成された前記会話スレッドを含んでいるソフトウェア部品を停止するステップと、
　（ｂ）前記ソフトウェア部品をシリアライズによりネットワーク上転送可能となるように転換し前記ネットワークを介して他のメッセージ処理装置に送出するステップと、
　（ｃ）シリアライズされた前記ソフトウェア部品を、前記他のメッセージ処理装置において、デ・シリアライジングにより再開するステップと、を含むメッセージ処理をコンピュータに実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。」
　
を、
　
「【請求項１】
　人間が理解可能な言語を用いた新たな会話が発生するたびに生成され、生成されたそれぞれが前記会話を担当することにより、複数の会話を非同期に同時に進行することができる会話スレッドと、
　前記会話スレッドの生成を制御可能な会話スレッド制御部と、
　前記会話のメッセージが送出されるネットワークに対応したプロトコルに、前記メッセージを変換するプロトコル・マネジャと、
　前記会話に使われているエージェント・コミュニケーション言語を他の言語に翻訳するトランスレータと、
　を含むソフトウェア部品を有し、
　ネットワークを介して他のメッセージ処理装置にメッセージを送出可能なメッセージ処理装置で実行されるメッセージ処理方法であって、
　（ａ）新たな会話が発生するたびに生成された前記会話スレッドを含んでいるソフトウェア部品を停止する段階と、
　（ｂ）前記ソフトウェア部品をシリアライズによりネットワーク上転送可能となるように転換し前記ネットワークを介して他のメッセージ処理装置に送出する段階と、
　（ｃ）シリアライズされた前記ソフトウェア部品を、前記他のメッセージ処理装置において、デ・シリアライジングにより再開する段階と、を含むメッセージ処理方法。
　
　【請求項２】
　人間が理解可能な言語を用いた新たな会話が発生するたびに生成され、生成されたそれぞれが前記会話を担当することにより、複数の会話を非同期に同時に進行することができる会話スレッドと、
　前記会話スレッドの生成を制御可能な会話スレッド制御部と、
　前記会話のメッセージが送出されるネットワークに対応したプロトコルに、前記メッセージを変換するプロトコル・マネジャと、
　前記会話に使われているエージェント・コミュニケーション言語を他の言語に翻訳するトランスレータと、
　を含むソフトウェア部品を有し、
　ネットワークを介して他のメッセージ処理装置にメッセージを送出可能なメッセージ処理装置で実行されるメッセージ処理システムであって、
　（ａ）新たな会話が発生するたびに生成された前記会話スレッドを含んでいるソフトウェア部品を停止する機能と、
　（ｂ）前記ソフトウェア部品をシリアライズによりネットワーク上転送可能となるように転換し前記ネットワークを介して他のメッセージ処理装置に送出する機能と、
　（ｃ）シリアライズされた前記ソフトウェア部品を、前記他のメッセージ処理装置において、デ・シリアライジングにより再開する機能と、を含むメッセージ処理システム。
　
　【請求項３】
　人間が理解可能な言語を用いた新たな会話が発生するたびに生成され、生成されたそれぞれが前記会話を担当することにより、複数の会話を非同期に同時に進行することができる会話スレッドと、
　前記会話スレッドの生成を制御可能な会話スレッド制御部と、
　前記会話のメッセージが送出されるネットワークに対応したプロトコルに、前記メッセージを変換するプロトコル・マネジャと、
　前記会話に使われているエージェント・コミュニケーション言語を他の言語に翻訳するトランスレータと、
　を含むソフトウェア部品を有し、
　ネットワークを介して他のメッセージ処理装置にメッセージを送出可能なメッセージ処理装置で実行されるメッセージ処理をコンピュータに実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体であって、
　（ａ）新たな会話が発生するたびに生成された前記会話スレッドを含んでいるソフトウェア部品を停止するステップと、
　（ｂ）前記ソフトウェア部品をシリアライズによりネットワーク上転送可能となるように転換し前記ネットワークを介して他のメッセージ処理装置に送出するステップと、
　（ｃ）シリアライズされた前記ソフトウェア部品を、前記他のメッセージ処理装置において、デ・シリアライジングにより再開するステップと、を含むメッセージ処理をコンピュータに実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。」（以下、「補正後の特許請求の範囲」という。）
　
に補正するとともに、明細書段落【０１０９】及び図１４を補正するものである（なお、補正前の特許請求の範囲に記載されている請求項と、補正後の特許請求の範囲に記載されている請求項を、以下ではそれぞれ「補正前の請求項」、「補正後の請求項」という。）。
　
　（２）新規事項について
　補正後の請求項１には、「前記会話のメッセージが送出されるネットワークに対応したプロトコルに、前記メッセージを変換するプロトコル・マネジャ」と「前記会話に使われているエージェント・コミュニケーション言語を他の言語に翻訳するトランスレータ」とを含む「ソフトウェア部品」が、シリアライズによりネットワーク上転送可能となるように転換されて前記ネットワークを介して他のメッセージ処理装置へ送出され、シリアライズされた「前記ソフトウェア部品」を、前記他のメッセージ処理装置において、デ・シリアライジングにより再開するという趣旨の記載（以下、「記載Ａ」という。）が存在しているが、そのようなことは願書に最初に添付した明細書又は図面に記載された事項の範囲内のものではない（なお、以下では、「願書に最初に添付した明細書」を「当初明細書」と略記し、「願書に最初に添付した図面」を「当初図面」と略記し、「当初明細書又は当初図面」を「当初明細書等」と略記する。）。
　当初図面の図３には、「エージェント２０１」とは別個に「エージェント・コミュニケーション・システム２００」が存在し、この「エージェント・コミュニケーション・システム２００」の内部に、「プロトコル・マネージャ２３０」と「トランスレータ２２１」が存在している。
　また、当初明細書の段落【００１５】には「本発明は、耳と口に相当する
ソフトウェア部品（エージェント・コミュニケーション・システム）をエージェントに提供する
移動エージェント
エージェント・コミュニケーション・システム２００と対話することができる
移動エージェントがネットワーク上を移動する場合
　当初明細書等のその他の箇所の記載を参照しても、補正後の請求項１の前記記載Ａに対応する記載は存在せず、自明でもない。 
　なお、平成２１年８月１０日付けで提出された意見書の「（１）理由Ａについて」において請求人は、
　
「しかし、段落［００１５］には、「本発明は、
耳と口
この耳と口を
付ける
　そして、審判長殿が指摘された段落［００５３］、［０１０１］により、「移動エージェントがネットワーク上を移動する」際には、
当然に
　
と主張している（以下、この主張を「主張１」という。）ので、検討する。
　
　当初明細書の段落【００１５】、【００１９】には、それぞれ、
　
「【００１５】
【課題を解決するための手段】本発明は、
耳と口
耳は
というAPI
により提供され
口は
というAPIにより提供される
これらのAPIは
メソッド
として実装されている
　
「【００１９】また、本発明の一態様においては、
この耳と口を
付けるためには
インスタンシエートするだけで実現できる
　
という記載が存在する。前記段落には「耳と口」をエージェントに「付ける」という記載が存在するが、この記載は技術用語を用いた記載ではなく、比喩的表現を用いた記載であるから、この比喩的表現の意味するところを検討する。当該技術分野における技術常識によれば、前記段落【００１９】に記載されている「オブジェクト」の「インスタンシエート」とは、オブジェクトのインスタンスを計算機の主記憶上に生成して動作可能な状態にすることを意味し、前記段落【００１５】に記載されている「メソッド」とは、オブジェクトのインスタンスが有する関数であって、呼び出しを受けると実行を開始して所定の処理を行うように作成されている関数のことであり、前記段落【００１５】の「API」とは、関数を呼び出すための機構を意味するものであるから、これらの技術常識に鑑みれば、前記段落【００１５】、【００１９】の「耳と口」をエージェントに「付ける」という比喩的表現は、「エージェント・コミュニケーション言語マネジャ・オブジェクト」のインスタンスを生成し、そのインスタンスが有するメソッドをAPIを用いてエージェントが呼び出すことを意味するに過ぎず、請求人の前記主張１のように、「エージェント・コミュニケーション言語マネジャ・オブジェクト」が「当然」にネットワーク上を移動することを意味する記載であるとは認められない。
　また、前記段落【００１５】、【００１９】に記載されている「エージェント・コミュニケーション言語マネジャ・オブジェクト」とは、図３の「エージェント・コミュニケーション言語マネージャ２０３」に対応するものと解されるところ、この図３は、当初明細書の段落【００５２】に、
　
「【００５２】Ｂ．システム構成
　次に、
図３
サーバ側のシステム構成
　
と記載されているように、「サーバ」側のシステム構成を説明する図であり、当該「サーバ」とは、当初明細書の段落【００４３】に、
　
「【００４３】
【実施例】以下、図面を参照して本発明の実施例を説明する。図１を参照すると、本発明の移動オブジェクトを実行する分散ネットワーク環境１５０が示されている。
各サーバ
には
移動エージェント
にサービスを与える
プレース
　
と記載されているように、移動エージェントにサービスを与える「プレース」を、各サーバは備えている。そして、前記段落【００１５】、【００１９】に記載されている「エージェント・コミュニケーション言語マネジャ・オブジェクト」とは、エージェントに「耳と口」を付けるというサービスをエージェントに提供するものであるから、段落【００４３】の「プレース」に前記「エージェント・コミュニケーション言語マネジャ・オブジェクト」は含まれるものと解される。
　すると、例えば請求人が平成２１年８月１０日付けの意見書に添付した
　
　山崎重一郎（外１名）、「Telescript入門」、初版、株式会社アスキー、１９９６年７月１１日、第２１及び１０３頁、ＩＳＢＮ：４−７５６１−１６５６−６
　
という文献の第２１頁第２５行に「「プレース」は、それに
入ってくる
場である
　また、当初明細書及び当初図面のその他の箇所の記載を参照しても、補正後の請求項１の前記記載Ａに対応する記載は存在せず、自明でもない。 
　なお、当初明細書の末尾の【図面の簡単な説明】の中には「【図１４】本発明のエージェント・コミュニケーション・システムをネットワーク上移動させる場合の処理手順の一実施例を示すフローチャートである。」という記載（以下、「記載Ｂ」という。）が存在しているが、当初図面の図１４の中を参照しても「エージェント・コミュニケーション・システム」自体をネットワーク上で移動させる手法は何ら具体的に開示されておらず、また、前記記載Ｂは、当初明細書の段落【０１０１】の「移動エージェントがネットワーク上を移動する場合、図１４に示されるステップを実行することによって移動を可能になる。」という記載（移動エージェントが移動するという趣旨の記載）と矛盾する記載である。したがって、前記記載Ｂは、正しくは「【図１４】本発明の移動エージェントをネットワーク上移動させる場合の処理手順の一実施例を示すフローチャートである。」とすべき誤記であると認められ、前記記載Ｂ（発明の詳細な説明ではない【図面の簡単な説明】の中の一文に過ぎない）に基づいて、前記記載Ａが自明であるとは認められない。
　また、平成２１年８月１０日付けの意見書の「（１）理由Ａについて」において請求人は、
　
「なお、
要約
　
と主張しているが、特許法第３６条第２項に規定されているように、「要約書」は、「明細書」や「図面」とは別のものであり、当初明細書でも当初図面でもないので、請求人の当該主張は失当であり、採用できない。
　以上述べたように、前記記載Ａを含んでいる本件補正は、当初明細書及び当初図面に記載した事項の範囲内において行われていないので、特許法第１７条の２第３項に規定する要件を満たしていない。 
　
　（３）補正の目的要件
　上記「（２）新規事項について」で述べたように、本件補正は特許法第１７条の２第３項に規定されている要件を満たしていないが、
仮に
仮定した場合に
　補正後の請求項１の「人間が理解可能な言語を用いた新たな会話」という記載は、補正前の請求項１の「新たな会話」という発明特定事項を限定するものであって、補正前の請求項１に記載された発明と補正後の請求項１に記載された発明の産業上の利用分野及び解決しようとする課題は同一であるから、本件補正は、特許法第１７条の２第４項第２号の特許請求の範囲の減縮を目的とする補正である。
　
　（４）独立特許要件について
　上記「（２）新規事項について」で述べたように、本件補正は特許法第１７条の２第３項に規定されている要件を満たしていないが、
仮に
仮定した場合
　
　（Ａ）特許法第２９条第２項の要件について
　（A-1）補正後の発明
　補正後の請求項１には、次の発明（以下、「本件補正発明」という。）が記載されている。
　
　（本件補正発明）
　人間が理解可能な言語を用いた新たな会話が発生するたびに生成され、生成されたそれぞれが前記会話を担当することにより、複数の会話を非同期に同時に進行することができる会話スレッドと、
　前記会話スレッドの生成を制御可能な会話スレッド制御部と、
　前記会話のメッセージが送出されるネットワークに対応したプロトコルに、前記メッセージを変換するプロトコル・マネジャと、
　前記会話に使われているエージェント・コミュニケーション言語を他の言語に翻訳するトランスレータと、
　を含むソフトウェア部品を有し、
　ネットワークを介して他のメッセージ処理装置にメッセージを送出可能なメッセージ処理装置で実行されるメッセージ処理方法であって、
　（ａ）新たな会話が発生するたびに生成された前記会話スレッドを含んでいるソフトウェア部品を停止する段階と、
　（ｂ）前記ソフトウェア部品をシリアライズによりネットワーク上転送可能となるように転換し前記ネットワークを介して他のメッセージ処理装置に送出する段階と、
　（ｃ）シリアライズされた前記ソフトウェア部品を、前記他のメッセージ処理装置において、デ・シリアライジングにより再開する段階と、を含むメッセージ処理方法。
　
　（A-2）引用文献
　当審において平成２１年５月１２日付けで通知された最後の拒絶理由において引用文献１として挙げられている
　
　Markus Strasser et al.，Mole - A Java Based Mobile Agent System，Proceedings of the ECOOP'96 workshop on Mobile Object Systems，1996年，p.28〜35（以下、「引用文献１」という。）
　
は、本願の原出願日よりも前に頒布された文献であり、この引用文献１には、以下の（1-A）〜（1-H）の事項が記載されている。
　
　（1-A）「Each location represents an execution environment for agents, where agents can compute, communicate to other agents and use resources and services of the underlying system.（各々のロケーションは、エージェントにとっての実行環境を意味し（represents）、そこでエージェントは計算し、
他のエージェントと通信（communicate）し
　
　（1-B）「After the command to migrate is issued, the execution of the agent at the current location is stopped, the agent is removed from the source location and transported to the destination location. There, the execution of the agent continues.（マイグレートするためのコマンドが発行された後で、現在のロケーションにおける
エージェントの実行はストップされ
宛先（destination）のロケーションへと転送される。そこで、そのエージェントの実行は続行する
　
　（1-C）「Then, the program, the data（object attributes） and the execution state of the agent has to be transformed into a transport representation.（それから、
エージェントのプログラムとデータ（オブジェクトの属性）と実行状態は転送用の表現形式（transport representation）へと変形
　
　（1-D）「After the call of the migrate statement, a stop method is called, enabling the agent to clean up and to prepare to migrate（for example stop all other threads）. Then, the agent is sent to the destination location. Therefore, the data state is sent using the Java object serialization package provided by JavaSoft（Sun）. The destination location examines the received serialized data state and requests the classes, that are not locally available, from the source location.（マイグレートの記述の呼び出しの後で、ストップ・メソッドが呼ばれ、エージェントがクリーン・アップを行ってマイグレートの準備をする（例えば
他のすべてのスレッドを停止させる
データ状態（data state）は
シリアライゼーション
受信したシリアライズされているデータ状態
　
　（1-E）「At the destination location, the agent is created using the received data. Then, a start method is called.（宛先のロケーションでは、
受信されたデータを用いてエージェントが生成され、それからスタート・メソッドが呼ばれる
　
　（1-F）「A complex problem not mentioned up to now is the question of how to migrate an agent if it may have several execution points at a time, for example by creating several threads. Using threads, the complexity of a migration grows - not only on the technical side. The simple question not yet finally answered is , what to do, if there are several threads active in an agent and one of these threads wants to migrate. Migrating all threads? Apart from the fact that this is impossible with the mechanism described above, it is a semantic problem, because the other threads don't register this migration. Migrating only the thread which wishes to migrate? This would 'split' the agent and in our opinion cannot be the correct semantics of a migration. In the current implementation it is supposed, that the stop method of an agent stops all other threads and doesn't return until all other threads of the agent are stopped. This imposes another burden on the agent programmer and some resarch work will be invested in this problem.（ここまでで言及されていない１つの複雑な問題は、例えば
複数のスレッドを生成
１つのエージェントの中に複数のアクティブなスレッドがあって
現時点での実施状況（current implementation）では、１つのエージェントのストップ・メソッドは、他のすべてのスレッドを停止させ、他のすべてのスレッドが停止させられるまでは復帰しないものと考えられ（supposed）ている
　
　（1-G）「One of the basic abitities of an agent is its ability to communicate to other agents.（
エージェントの基本的な能力の１つは、他のエージェントと通信（communicate）することである
　
　（1-H）「High level communication between agents is a research field of its own and some general communication protocols have been proposed [18][30][80]. In Mole, we chose to realize a set of commonly used low-level communication protocols. Higher-level protocols (
such as KQML
can be
　In the first implementation of Mole, the following two means of communication are realized:　
　・Remote procedure call（中略） 
　・message passing between agents 
　There is no difference between local and global communication in the use of this mechanisms, providing some level of access transparency. The communication patners are always addressed via their name and their actual location.
　（エージェント間の高レベルの通信（communication）は、その独特の研究分野であり、いくつかの一般的な通信プロトコルが提案されてきている [18][30][80]。Moleにおいては、我々は、一般的に用いられている低レベルの通信プロトコルのセットを選択して使用した。これらのプロトコルの
最上位において（on top）
ＫＱＭＬのような
　Moleを最初に実装（first implementation）した際には、以下の
２つの通信手段が実現されている
　・リモート・プロシジャ・コール（中略） 
　・
エージェント間のメッセージ・パッシング
　アクセスの透過性（access transparency）のいくつかのレベルを提供するこれらのメカニズム（this mechanisms）を使うと、局所的（local）な通信と
大域的（global）な通信
通信の相手同士は、常にその名前と現実のロケーションとを介してアドレスされる
　
　上記（1-F）には、１つのエージェントが複数のスレッドを生成するという趣旨の記載（原文は、A complex problem not mentioned up to now is the question of how to migrate 
an agent
it
　
　上記（1-H）の記載から、或るロケーションに存在するエージェントは、他のロケーションに存在するエージェントに対して
最上位のプロトコルとしてＫＱＭＬという通信プロトコルを用いて
　ここで、前記（1-H）の前記「ＫＱＭＬ」という通信プロトコルにおいて、どのような表現形式のメッセージを用いることが周知なものとして当業者に知られているかを確認するために、本願の原出願日前に頒布された文献である
　
　Genesereth, M.R., Software agents, Communications of the ACM, Vol.37, No.7, July 1994, p.48-53 and 147, ISSN:0001-0782（以下、「周知事項開示文献」という。）
　
を参照すると、その第５２頁の左欄外の「Knowledge Query and Manipulation Language」というタイトルの囲み記事の中に、
　
「As used in ACL, KQML messages are similar to KIF expressions.（
ＡＣＬにおいて使用されている
ＫＱＭＬのメッセージ
　
「The following dialogue is a little more interesting. In this case, the first message is a request for the receiver to execute the operation of printing a string to its standard I/O stream. The second message tells the sender that the request has been satisfied.
　A to B：(perform (print Hello! t))
　B to A：(reply done)
（以下の対話（dialogue）は、さらに少し興味深い。このケースでは、最初のメッセージは受け手（receiver）に対し、その標準Ｉ／Ｏストリームに１つの文字列を印刷する処理を行うことを要求するものである。２番目のメッセージは、送り手（sender）に要求が満たされたことを返答するものである。
　ＡからＢへ：（実行しろ（印刷しろ（こんにちは）ｔ））
　ＢからＡへ：（返答　済んだ））」（前記囲み記事内の第１５〜２０行）
　
と記載されているように、ＫＱＭＬが使用するメッセージが、人間が理解可能な言語を用いた表現形式のメッセージであることは、当業者にとって周知な事項であるから、引用文献１において最上位のプロトコルとしてＫＱＭＬという通信プロトコルを用いてメッセージを送出するエージェントは、前記メッセージとして、人間が理解可能な言語を用いた表現形式のメッセージを送出するものと解される。
　
　したがって、引用文献１には次の発明（以下、「引用発明」という。）が記載されている。
　
　（引用発明）
　複数の動的に生成されたスレッドを含み、最上位のプロトコルとしてＫＱＭＬという通信プロトコルを用いて人間が理解可能な言語を用いた表現形式のメッセージの交換を行うエージェントを有し、 
　エージェントが実行される他のロケーションにメッセージを送出可能なロケーションで実行されるメッセージ処理方法であって、 
　（ａ）前記複数の動的に生成されたスレッドを含んでいるエージェントを停止する段階と、
　（ｂ）エージェントのプログラムとデータ（オブジェクトの属性）と実行状態を転送用の表現形式（transport representation）へと変形するとともに、エージェントのデータ状態（data state）をJavaSoft（Sun）によって提供されるJavaオブジェクト・シリアライゼーション・パッケージを用いて他のロケーションへ送出する段階と、
　（ｃ）前記エージェントの実行を、前記他のロケーションにおいて、受信したシリアライズされているデータ状態を用いて続行する段階と、を含むメッセージ処理方法。
　
　（A-3）対比
　次に、引用発明と、本件補正発明とを対比する。
　引用発明の「複数の動的に生成されたスレッド」と、本件補正発明の「人間が理解可能な言語を用いた新たな会話が発生するたびに生成され、生成されたそれぞれが前記会話を担当することにより、複数の会話を非同期に同時に進行することができる会話スレッド」とは、ともに、「複数の動的に生成されたスレッド」である点において共通する。
　引用発明の「メッセージの交換」が、本件補正発明の「会話」に相当する。
　引用発明の「複数の動的に生成されたスレッドを含み、最上位のプロトコルとしてＫＱＭＬという通信プロトコルを用いて人間が理解可能な言語を用いた表現形式のメッセージの交換を行うエージェント」と、本件補正発明の「人間が理解可能な言語を用いた新たな会話が発生するたびに生成され、生成されたそれぞれが前記会話を担当することにより、複数の会話を非同期に同時に進行することができる会話スレッドと、前記会話スレッドの生成を制御可能な会話スレッド制御部と、前記会話のメッセージが送出されるネットワークに対応したプロトコルに、前記メッセージを変換するプロトコル・マネジャと、前記会話に使われているエージェント・コミュニケーション言語を他の言語に翻訳するトランスレータと、を含むソフトウェア部品」とは、ともに、「複数の動的に生成されたスレッドを含み、人間が理解可能な言語を用いた会話を行うソフトウェア部品」である点において共通する。
　引用発明では、エージェントはロケーションにおいて実行され、エージェントの実行によってメッセージの交換が行われているから、このことを上位概念化して把握すると、引用発明の「ロケーション」が、本件補正発明の「メッセージ処理装置」に相当する。
　引用発明の「前記複数の動的に生成されたスレッドを含んでいるエージェントを停止する段階」と、本件補正発明の「新たな会話が発生するたびに生成された前記会話スレッドを含んでいるソフトウェア部品を停止する段階」とは、ともに、「前記複数の動的に生成されたスレッドを含んでいるソフトウェア部品を停止する段階」である点において共通する。
　引用発明の「エージェントのプログラムとデータ（オブジェクトの属性）と実行状態を転送用の表現形式（transport representation）へと変形するとともに、エージェントのデータ状態（data state）をJavaSoft（Sun）によって提供されるJavaオブジェクト・シリアライゼーション・パッケージを用いて他のロケーションへ送出する段階」と、本件補正発明の「前記ソフトウェア部品をシリアライズによりネットワーク上転送可能となるように転換し前記ネットワークを介して他のメッセージ処理装置に送出する段階」とは、ともに、「前記ソフトウェア部品の実行再開に必要な、前記ソフトウェア部品の少なくとも一部の構成要素をシリアライズにより転送可能となるように転換し、他のメッセージ処理装置に送出する段階」である点において共通する。
　シリアライズされているデータ状態を使用するためには、該データ状態をデ・シリアライズする必要があることは当然であるから、引用発明の「前記エージェントの実行を、前記他のロケーションにおいて、受信したシリアライズされているデータ状態を用いて続行する段階」と、本件補正発明の「シリアライズされた前記ソフトウェア部品を、前記他のメッセージ処理装置において、デ・シリアライジングにより再開する段階」とは、ともに、「前記ソフトウェア部品を、前記他のメッセージ処理装置において、デ・シリアライジングにより再開する段階」である点において共通する。
　
　したがって、引用発明と本件補正発明は、以下の点で一致し、また、相違している。
　
　（一致点）
　複数の動的に生成されたスレッドを含み、人間が理解可能な言語を用いた会話を行うソフトウェア部品を有し、
　他のメッセージ処理装置にメッセージを送出可能なメッセージ処理装置で実行されるメッセージ処理方法であって、
　（ａ）前記複数の動的に生成されたスレッドを含んでいるソフトウェア部品を停止する段階と、
　（ｂ）前記ソフトウェア部品の実行再開に必要な、前記ソフトウェア部品の少なくとも一部の構成要素をシリアライズにより転送可能となるように転換し、他のメッセージ処理装置に送出する段階と、
　（ｃ）前記ソフトウェア部品を、前記他のメッセージ処理装置において、デ・シリアライジングにより再開する段階と、を含むメッセージ処理方法。
　
　（相違点１）
　前記（一致点）における「複数の動的に生成されたスレッド」が、本件補正発明では「新たな会話が発生するたびに生成され、生成されたそれぞれが前記会話を担当することにより、複数の会話を非同期に同時に進行することができる会話スレッド」であるのに対し、引用発明ではメッセージの交換を行うエージェントの内部のスレッドではあるものの、「新たな会話が発生するたびに生成され、生成されたそれぞれが前記会話を担当することにより、複数の会話を非同期に同時に進行することができる会話スレッド」であるか否かは明らかではない点。
　
　（相違点２）
　前記プログラム部品が、本件補正発明では「前記会話スレッドの生成を制御可能な会話スレッド制御部」も含むのに対し、引用発明のエージェントに含まれているスレッドは、複数の動的に生成されたスレッドではあるものの、「前記会話スレッドの生成を制御可能な会話スレッド制御部」を引用発明のエージェントが含むか否かは明らかではない点。
　
　（相違点３）
　前記プログラム部品が、本件補正発明では「前記会話のメッセージが送出されるネットワークに対応したプロトコルに、前記メッセージを変換するプロトコル・マネジャと、前記会話に使われているエージェント・コミュニケーション言語を他の言語に翻訳するトランスレータ」も含むのに対し、引用発明のエージェントは「前記会話のメッセージが送出されるネットワークに対応したプロトコルに、前記メッセージを変換するプロトコル・マネジャと、前記会話に使われているエージェント・コミュニケーション言語を他の言語に翻訳するトランスレータ」を含むか否かは明らかではない点。
　
　（相違点４）
　他のメッセージ処理装置への「送出」や「転送」が、本件補正発明ではネットワークを介して行われているのに対し、引用発明では他のロケーションへの送出や転送がネットワークを介して行われているのか否かが明らかではない点。
　
　（相違点５）
　本件補正発明では、「ソフトウェア部品」を、シリアライズにより転送可能となるよう転換し他のメッセージ処理装置に送出し、シリアライズされた「ソフトウェア部品」をデ・シリアライジングにより再開するのに対し、引用発明では、シリアライズにより転送可能となるよう転換されて他のメッセージ処理装置に送出されるのは「エージェントのデータ状態（data state）」のみであり、引用発明ではエージェントのプログラムとデータ（オブジェクトの属性）と実行状態は、転送用の表現形式（transport representation）へと変形はされているものの、それらエージェントのプログラムとデータ（オブジェクトの属性）と実行状態はどのような機構によって送出されるのかは引用発明では明らかではなく、そのため、引用発明ではエージェントの実行を再開する際にデ・シリアライジングされるのは前記データ状態（data state）のみであり、引用発明ではエージェントの実行を再開する際に前記転送用の表現形式（transport representation）へと変形されているエージェントのプログラムとデータ（オブジェクトの属性）と実行状態が、どのように受信されて使用されるのかは不明である点。
　
　（A-4）判断
　次に、上記相違点の各々について検討する。
　
　まず、上記相違点１及び相違点２について検討する。
　当審において平成２１年５月１２日付けで通知された最後の拒絶理由において引用文献２として挙げられている
　
　鈴木信雄・他、「OSI CCRを用いたUNIX用分散トランザクション処理方式」、電子情報通信学会技術研究報告、Vol.92, No.290（CPSY92-45〜54）、社団法人電子情報通信学会、１９９２年１０月２３日、p.43〜50（以下、「引用文献２」という。）
　
は、本願の原出願日よりも前に頒布された文献であり、この引用文献２には、図面とともに以下の（2-A）〜（2-G）の事項が記載されている。
　
　（2-A）「サーバプロセス内はマルチスレッド・サーバとして実現する」（第４６頁左コラム第２６〜２７行）
　
　（2-B）「分散トランザクション処理機能を実現するモジュールをマルチスレッド・サーバとして実現する」（第４６頁左コラム第３６〜３８行）
　
　（2-C）「（１）Client：分散トランザクション処理機能を利用するユーザプロセスであり、CCR Managerプロセスに対してトランザクションの開始と終了、及び資源更新等の要求を行う」（第４７頁左コラム第１２〜１５行）
　
　（2-D）「（２）CCR Manager：分散トランザクション処理機能を提供するプロセスで（中略）また、後に述べるようにマルチスレッド・サーバとして実現されており」（第４７頁左コラム第１６〜２２行）
　
　（2-E）「スレッドは、同一プロセス内で複数の論理的な制御の流れを実行させることができる機構である。これは、複数クライアントに対するサービスを行うサーバなどに有効で」（第４７頁右コラム第５〜８行）
　
　（2-F）「図４にCCR Managerプロセス内でのスレッドの構成を示す。
　（１）Communication Coordinator：Clientプロセスからの要求を受けて
トランザクション毎にTransaction Coordinatorスレッドを生成する
Clientプロセスや他ノードからのメッセージを非同期に受信し、そのメッセージに対応したトランザクションを管理しているTransaction Coordinatorスレッドへメッセージ受信を通知する
　（２）Transaction Coordinator：CCRプロトコル機械の上位に位置し、
トランザクション毎に生成される
　
　（2-G）「そのために、一つのスレッドが特定のコネクションを使用しようとする場合、
スレッドとコネクションの対応を取る必要がある
　この問題に対処するために、本システムでは図５のような手法を用いた。構成要素としては次のようなものがある。
　（１）transaction wait queue：
Communication Coordinatorスレッドは、Clientプロセスからのコネクション確立要求に対してacceptを行った後、このqueueへソケット接続し、トランザクション開始要求を待つ
　（２）transaction queue：
Communication Coordinatorスレッドは、Clientプロセスからのトランザクション開始要求を受信すると
メッセージ受信を検出し、対応するTransaction Coordinatorスレッドへ通知する
　
　上記（2-A）〜（2-G）の記載によれば、引用文献２では、１個のサーバプロセスは、Communication Coordinatorを含んでおり、複数のClientプロセスの各々からトランザクション要求を受け取ると、前記Communication Coordinatorは、それぞれのトランザクション要求に対応するTransaction Coordinatorスレッドを前記サーバプロセスの内部に生成し、それぞれのTransaction Coordinatorスレッドに対応するトランザクション処理を行わせるようになっている。
　ここで、トランザクションとは、例えばデータの問い合わせを行うメッセージを受け取ると、その問い合わせに対する応答メッセージを返すというように複数のメッセージを交換することを含むから、トランザクションとは会話の一種であり、このことを踏まえて引用文献２の前記記載を参照して上位概念化して把握すると、会話を行う１つのプログラムの中に、新たな会話が発生するたびに生成され、生成されたそれぞれが前記会話を担当することにより、複数の会話を非同期に同時に進行することができる会話スレッドと、前記会話スレッドの生成を制御可能な会話スレッド制御部とを含むことが公知である。そして、引用発明の「複数の動的に生成されたスレッド」を含んでいる「エージェント」は、メッセージの交換を行うエージェントであり、上述の如く会話とはメッセージの交換を行うことであるから、引用発明のメッセージ交換を行うエージェントが、前記公知な「新たな会話が発生するたびに生成され、生成されたそれぞれが前記会話を担当することにより、複数の会話を非同期に同時に進行することができる会話スレッドと、前記会話スレッドの生成を制御可能な会話スレッド制御部」を含むようにすることは、当業者が容易に想到し得た事項に過ぎない。
　したがって、上記相違点１及び相違点２は、格別のものではない。
　
　次に、上記相違点３について検討する。
　当審において平成２１年５月１２日付けで通知された最後の拒絶理由において引用文献４として挙げられている
　
　北垣高成・他、「並列処理型センサベーストマニピュレーションシステム：匠」、日本ロボット学会誌、Vol.15，No.3、社団法人日本ロボット学会、１９９７年４月１５日、p.51〜60（以下、「引用文献４」という。）
　
は、本願の原出願日よりも前に頒布された文献であり、この引用文献４には、図面とともに以下の事項が記載されている。
　
「5.2　ルータを用いたシステム構成
　本ルータを用いたシステム構築の際、以下の点を設計指針とした。
・
ネットワーク内を流れるデータはＮＥＴプロトコルデータに限定
・INMOS社供給のホストI/Oライブラリが利用可能。
・
iserver（INMOS社供給のサーバ）とそれを利用するエージェントの入出力部のみでiserver用プロトコル（以下、ISERVERプロトコルと呼ぶ）データを使用
・任意のエージェントが接続先として任意のiserverを選択可能。
　（中略）
　これらの指針によりFig.8に示されるような構成のシステムが開発された。
図中、四角で囲まれているのはそこを流れるデータプロトコルを示している
　（中略）
　本ルータで通信を行う
エージェント
３つのタイプ
　Type１はネットワークと直接入出力を行う最も単純な形のエージェントである。
　
Type２は
Bodyではそのエージェント固有のデータ処理を行う
HeadとBodyは並列で稼働させる
　
Type３はType２にさらにisv2netというプロセスが並列で稼働するエージェントである。isv2netではISERVERプロトコルデータをNETプロトコルデータに変換する
　
　この記載から、引用文献４のType３のエージェントの内部では、HeadとBodyとisv2netという３つのプログラムが並列に稼働し、前記isv2netはエージェントからのデータが出力されるネットワークに対応するプロトコルに、前記データを変換するプログラム（本件補正発明の「プロトコル・マネジャ」に対応）であり、このようなものは周知技術に過ぎず、引用発明のエージェントが、このようなプロトコルの変換を行う周知なプログラムをその内部に含んで、引用発明において「最上位のプロトコル」として用いられている「ＫＱＭＬという通信プロトコル」との間でプロトコルの変換を行うようにすることは、当業者が容易に想到し得た事項に過ぎない。
　
　また、当審において平成２１年５月１２日付けで通知された最後の拒絶理由において引用文献５として挙げられている
　
　横田一正・他、「マルチエージェントによる異種問題解決系の構想」、レクチャーノート／ソフトウェア学８　マルチエージェントと協調計算III、株式会社近代科学社、１９９４年１０月２０日、初版、p.67〜74、ISBN:4-7649-0227-3（以下、「引用文献５」という。）
　
は、本願の原出願日よりも前に頒布された文献であり、この引用文献５には、図面とともに以下の（5-A）〜（5-C）の事項が記載されている（なお、以下の（5-A）、（5-C）は、引用文献５の記載を転記したものであり、（5-B）は、第６９頁の「表１」の記載内容を文章で描写したものである。）。
　
　（5-A）「３　基本モデル
　３．１　基本的な機能
　既存の問題解決器のもっている情報は、大域システムから考えれば基本的にはすべて局所的なものである。そこでまず、分散問題解決システムのために、各問題解決器を（ある環境内で）大域的な
エージェント
エージェント
言語
対応する機能
表１
　
　（5-B）第６９頁の表１には「言語と機能の対応」という表題がつけられ、表１の中には「言語」という欄と「機能」という欄が設けられ、前記「言語」という欄の「共通な言語（構文，型システム，語彙，内部データ構造）」という記述に対応づけて、前記「機能」という欄には、「共通言語と各固有言語との変換」という記述が存在している。
　
　（5-C）「３．２　基本概念−環境とエージェント
　関連する問題解決器が共存するための共通空間を環境といい、各問題解決器を覆い環境とのインタフェースを司るものを
皮
エージェント
　３．２．１　
エージェント
エージェント
皮
機能
　・自己モデル定義
　（中略）
　・データ変換（
構文，型
　　
エージェントが外部と通信するすべてのメッセージの変換／逆変換を定義する
　・（同期機能を含む）通信機能
　　非同期メッセージは内の問題解決器の並行実行制御（concurrency　control）の機能に依存して逐次化するかどうかが決定される。同期メッセージはひとつの問合せのサブトランザクションのエージェント間の同期を行なうためのものである。」（第７０頁第６〜２２行）
　
　上記（5-C）の記載は、「問題解決器」を「皮」で覆ったものが「エージェント」であり、前記「皮」は、各エージェントが外部と通信するメッセージの「構文」や「型」を変換する機能を有しているという趣旨の記載であるから、したがって、前記「エージェント」は、前記「構文」や前記「型」を変換する機能を有する「皮」というプログラムをその内部に含んでいる。そして、上記（5-A）、（5-B）の記載から、前記「構文」や前記「型」の変換とは、すべてのエージェントが共有する共通な言語と、各エージェントに固有な言語との間の変換であることが判る。
　このように、エージェントが送受信するメッセージの言語を変換するプログラム（本件補正発明の「トランスレータ」に対応）をエージェントの内部に含むようにすることは周知技術であり、この周知技術を用いて引用発明のエージェントの内部に上記言語の変換を行うプログラムを含ませて、引用発明の「人間が理解可能な言語を用いた表現形式のメッセージ」を表現するために使用されている言語との間で言語間の変換を行う構成とすることは、当業者が容易に想到し得た事項に過ぎない。
　したがって、上記相違点３も格別のものではない。
　
　次に、上記相違点４について検討する。
　引用発明のロケーション間では、メッセージ等の授受を行っているから、それらのロケーションの間に何らかの通信手段を引用発明が有していることは当然であるが、ネットワークを介して通信を行うことは周知技術であるから、引用発明における通信をネットワークを介して行うようにすることは、当業者が容易に想到し得た事項に過ぎず、上記相違点４も格別のものではない。
　
　次に、上記相違点５について検討する。
　引用発明では、「エージェントのプログラムとデータ（オブジェクトの属性）と実行状態」は「転送用の表現形式（transport representation）」へと変形されているが、この「転送用の表現形式（transport representation）」としては種々の形式が必要に応じて利用可能であることは当業者にとって自明であり、また、引用発明の「JavaSoft（Sun）によって提供されるJavaオブジェクト・シリアライゼーション・パッケージ」を用いてシリアライズされた形式というのも「転送用の表現形式（transport representation）」の一種であるから、引用発明において「エージェントのプログラムとデータ（オブジェクトの属性）と実行状態」が変形される「転送用の表現形式（transport representation）」として、「JavaSoft（Sun）によって提供されるJavaオブジェクト・シリアライゼーション・パッケージ」を用いてシリアライズされた形式を採用することは、当業者が容易に想到し得た事項に過ぎない。また、引用発明において、送出先のロケーションにおいてエージェントの実行を再開するためには、「エージェントのデータ状態（data state）」だけでは不十分であり、「エージェントのプログラムとデータ（オブジェクトの属性）と実行状態」も送出先のロケーションでアクセスできるようにしておく必要があることは当然であり、必要なデータやプログラムを一括して転送することは周知技術であるから、引用発明において、「エージェントのデータ状態（data state）」と一緒に「エージェントのプログラムとデータ（オブジェクトの属性）と実行状態」も一緒にシリアライズして送出する（すなわち、１個のエージェント全体を一括してシリアライズして送出する）ようにすることは、当業者が容易に想到し得た事項に過ぎない。そして、このように、一括してシリアライズされたエージェント全体を送出するようにされれば、それに伴って、受信側のロケーションではデ・シリアライズにより一括してエージェントが得られるので、そのエージェントの実行を再開するようになるのは、当然のことである。
　したがって、上記相違点５も格別のものではない。
　
　（A-5）特許法第２９条第２項についてのまとめ
　以上のように、相違点１〜５は、いずれも格別のものではなく、本件補正発明が有する効果も当業者であれば当然に予測可能な効果に過ぎず、格別な効果でもない。
　
したがって、本件補正発明は、引用文献１に記載されている引用発明に基づいて当業者が容易に発明できたものであるから、特許法第２９条第２項の規定により、特許を受けることができない
　なお、請求人は審判請求理由において当時の引用文献３（この審決で挙げている「引用文献１」と同一の文献である。）について、「複雑で解決方法が難しい」という趣旨の記載が当該文献中に存在するという指摘を行っているが、引用文献１（この審決で挙げている引用文献１。以下同じ。）には、上記（1-F）に、「In the current implementation it is supposed, that the stop method of an agent stops all other threads and doesn't return until all other threads of the agent are stopped.（現時点での実施状況（current implementation）では、１つのエージェントのストップ・メソッドは、他のすべてのスレッドを停止させ、他のすべてのスレッドが停止させられるまでは復帰しないものと考えられ（supposed）ている。）」と記載されているように、マイグレートの対象となっている１個のエージェントが複数のスレッドを含む際の解決策が示唆されており、そのような解決策の具体例として、当審において平成２１年５月１２日付けで通知された最後の拒絶理由において引用文献３として挙げられている
　
　鈴木信雄・他、「SunOSにおけるマルチスレッド・プロセス移送方式の提案」、情報処理学会第５０回全国大会講演論文集（４）、社団法人情報処理学会、１９９５年３月１５日、p.4-275〜4-276（以下、「当審の引用文献３」という。）
　
には、
　
　（3-A）「本稿では、マルチスレッド・プロセスを移送する時に必要な手法について述べ」（第4-275頁左コラム第２０〜２１行）
　
　（3-B）「本実現手法の前提となる基本的なプロセス移送の手順は次のとおりである［２］。（図１）
　（中略）
　（２）シグナルを受け取ったプロセスは、
シグナル処理関数
　（５）起動されたプロセスは、（２）で中断された
シグナル処理関数
　
　（3-C）「本稿で述べるマルチスレッド対応の手法は、上記手順中の
シグナル処理関数
　
　（3-D）「移送処理を行う
シグナル処理関数
自分以外のスレッドを一時的に停止する
その後のプロセス再開時に（中略）suspendしていた全スレッドのresumeにより、移送前の状態へ戻る
　
という記載が存在しているから、仮に請求人の前記指摘が、引用発明が未完成発明であると主張する趣旨のものであると仮定しても、
引用文献１においては上記（1-F）の如く解決策を示唆する記載が存在しているから
　ちなみに、複雑で人間にとって判りにくい言語であっても、その言語の文法と単語を学習した人間にとって
理解可能な言語である
上位概念
下位概念
　なお、仮に、上に挙げた「周知事項開示文献」の第５２頁の前述の囲み記事に記載されている前述の対話の例が、「人間の会話に近い言語」や「人間にとって直感的に判りやすいエージェント・コミュニケーション言語」とは言えないと仮定しても、前記囲み記事に記載されている前記対話の例が「人間が理解可能な言語」を用いて行われていること自体に変わりはないので、上記（A-2）〜（A-4）の検討結果や結論には変更は無い。
　
　（Ｂ）特許法第３６条第４項の要件について
　補正後の請求項１には、「前記ソフトウェア部品をシリアライズによりネットワーク上転送可能となるように転換し」という記載と、「シリアライズされた前記ソフトウェア部品を、前記他のメッセージ処理装置において、デ・シリアライジングにより再開する」という記載が存在する。これらの記載に含まれている「前記ソフトウェア部品」とは、同じく補正後の請求項１に記載されている「人間が理解可能な新たな会話が発生するたびに生成され、生成された
それぞれ
それぞれ
　
「段落［０１０１］には、「移動エージェントがネットワーク上を移動する場合、図１４に示されるステップを実行することによって移動を可能になる。」と記載されております。よって、補正後の図１４により、移動エージェントをネットワーク上で移動させる場合、当該移動エージェント全体をシリアライズして送出するということは明らかです。そして、移動エージェント全体とは、段落［００１９］により、移動エージェントに付されたソフトウェア部品をも含むことができます。その場合、エージェント・コミュニケーション・システム中では、その中でスレッドが停止され、移動エージェント全体がシリアライズされ、他のノードにおいてこれがデ・シリアライズされ、そこでエージェント・コミュニケーション・システム内のスレッドが再開されることが、当該記載から
自明です
　
と主張しているが、何故そのようなことが「自明」であるのか、根拠が不明であり、当該主張は採用できない（仮に請求人が主張するようなことが記載されていると仮定しても、単なる願望が記載されているだけであり、
具体的な実現手法
複数の
　なお、上記「（A-5）特許法第２９条第２項についてのまとめ」で挙げた「当審の引用文献３」に記載されている公知技術を用いれば実施できるとしても、上記「（A-5）特許法第２９条第２項についてのまとめ」で述べたように、
引用文献１においては
解決策を示唆する記載が存在しているから
そのような示唆を行う記載が存在していない本願の発明の詳細な説明
　
　（Ｃ）独立特許要件についてのまとめ
　上記「（２）新規事項について」で述べたように、本件補正は特許法第１７条の２第３項に規定されている要件を満たしていないが、
仮に
仮定した場合
　
　（５）補正却下のまとめ
　上記「（２）新規事項について」で述べたように、本件補正は平成１４年法律第２４号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第３項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　また、仮に、本件補正が特許法第１７条の２第３項の規定を満たすものと仮定しても、上記「（４）独立特許要件について」で述べたように、本件補正は平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　よって、上記［補正却下の決定の結論］のとおり決定する。 
　
　第３．本願について
　（3-1）本願明細書及び図面
　平成２１年８月１０日付けの手続補正は上記のとおり却下されたので、本願明細書の特許請求の範囲の記載は、平成２１年３月１７日付け手続補正書により補正された特許請求の範囲（上記［補正却下の決定の理由］の中の上記「（１）補正の内容」に記載された補正前の特許請求の範囲）の記載となり、本願明細書の発明の詳細な説明の記載は、当初明細書に記載された発明の詳細な説明の記載となり、図面は当初図面と同じものとなる。
　
　（3-2）当審の最後の拒絶理由
　当審における平成２１年５月１２日付けの最後の拒絶理由の概要は以下のとおりである（なお、以下の拒絶理由における「補正後の請求項」とは、平成２１年３月１７日付けの手続補正で補正された後の請求項、すなわち、上記［補正却下の決定の理由］の「（１）補正の内容」における「補正前の請求項」と同一の請求項を指すことに注意されたい）。
　
「　　　　　　　　　　　　　理　由
　
　　　　　　　　　　＜＜＜　最　後　＞＞＞
　
【理由Ａ】平成２１年３月１７日付けでした手続補正は、下記の点で願書に最初に添付した明細書又は図面（以下、「当初明細書等」という。）に記載した事項の範囲内においてしたものでないから、特許法第１７条の２第３項に規定する要件を満たしていない。
　
　　　　　　　　　　　　　　　記
　
　補正後の請求項１〜３には「前記会話のメッセージが送出されるネットワークに対応したプロトコルに、前記メッセージを変換するプロトコル・マネジャ」と「前記会話に使われているエージェント・コミュニケーション言語を他の言語に翻訳するトランスレータ」とを含む「ソフトウェア部品」が、シリアライズによりネットワーク上転送可能となるように転換されて前記ネットワークを介して他のメッセージ処理装置へ送出され、シリアライズされた「前記ソフトウェア部品」を、前記他のメッセージ処理装置において、デ・シリアライジングにより再開するという趣旨の記載（以下、「記載Ａ」という。）が存在しているが、そのようなことは当初明細書等には記載されておらず、当初明細書等の記載から自明でもない。 
　（中略）
　このように、平成２１年３月１７日付けでした手続補正は、前記記載Ａを含んでいるから、当初明細書等に記載した事項の範囲内においてしたものでなく、したがって特許法第１７条の２第３項に規定する要件を満たしていない。
　　　　　　　　　　　　　　　　　　　　　　　　　（以上、理由Ａ）
　
【理由Ｂ】この出願は、発明の詳細な説明の記載が下記の点で、特許法第３６条第４項に規定する要件を満たしていない。
　
　　　　　　　　　　　　　　　記
　
　（１）上記【理由Ａ】で指摘したように、補正後の請求項１〜３には前記記載Ａが存在しているが、前記記載Ａの具体的な実現手法が、当業者が実施できる程度に明確かつ十分に発明の詳細な説明において開示されていない。
　
　（２）補正後の請求項１〜３には、「前記ソフトウェア部品をシリアライズによりネットワーク上転送可能となるように転換し」という記載と、「シリアライズされた前記ソフトウェア部品を、前記他のメッセージ処理装置において、デ・シリアライジングにより再開する」という記載が存在する。これらの記載に含まれている「前記ソフトウェア部品」とは、同じく請求項１〜３に記載されている「新たな会話が発生するたびに生成され、生成されたそれぞれが前記会話を担当することにより、複数の会話を非同期に同時に進行することができる会話スレッドと（中略）と、を含むソフトウェア部品」のことである。ここで、前記「生成されたそれぞれが前記会話を担当することにより、複数の会話を非同期に同時に進行することができる会話スレッド」という記載は、「それぞれ」という表記によって端的に表現されているように、前記会話スレッドは複数存在するものと解され、したがって、補正後の請求項１〜３には、「複数の会話スレッドを含むソフトウェア部品をシリアライズによりネットワーク上転送可能となるように転換し、シリアライズされた前記ソフトウェア部品を、前記他のメッセージ処理装置において、デ・シリアライジングにより再開する」という事項（以下、「事項Ｃ」という。）が実質的に記載されていることになるが、そのような「事項Ｃ」の具体的な実現手法が、当業者が実施できる程度に明確かつ十分に発明の詳細な説明において開示されていない。したがって、補正後の請求項１〜３に記載された発明は実施できない。
　（中略）
　
　（３）図１４には「エージェント・コミュニケーション言語マネージャ内のスレッドの停止」、「エージェント・コミュニケーション言語マネージャ内のスレッドの再開」と記載されているが、この記載の意味するところが不明であり、具体的な実現手法も不明である。明細書や図面のその他の箇所の記載を参照しても、「エージェント・コミュニケーション言語マネージャ」の内部にスレッドが存在することは記載されておらず、具体的にどのような処理を行うスレッドを「エージェント・コミュニケーション言語マネージャ」の内部に設け、それら内部のスレッドを具体的にどのように制御するのか不明であり、図１４の前記記載は実施できない（すなわち、前回の拒絶理由通知書において【理由２】の（２）として指摘した記載不備が、依然として解消されていない。）。
　（中略）
　よって、この出願の発明の詳細な説明は、当業者が請求項１〜３に係る発明を実施することができる程度に明確かつ十分に記載されていない。
　　　　　　　　　　　　　　　　　　　　　　　　（以上、理由Ｂ）
　
【理由Ｃ】この出願の下記の請求項に係る発明は、その出願前日本国内又は外国において頒布された下記の刊行物に記載された発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　　　　　　　　　　　　　　　記
　
・請求項１〜３
引用文献：
　１．Markus Strasser et al.，Mole - A Java Based Mobile Agent System，Proceedings of the ECOOP'96 workshop on Mobile Object Systems，1996年，p.28〜35
　
　２．鈴木信雄・他、「OSI CCRを用いたUNIX用分散トランザクション処理方式」、電子情報通信学会技術研究報告、Vol.92, No.290（CPSY92-45〜54）、社団法人電子情報通信学会、１９９２年１０月２３日、p.43〜50
　
　３．鈴木信雄・他、「SunOSにおけるマルチスレッド・プロセス移送方式の提案」、情報処理学会第５０回全国大会講演論文集（４）、社団法人情報処理学会、１９９５年３月１５日、p.4-275〜4-276
　
　４．北垣高成・他、「並列処理型センサベーストマニピュレーションシステム：匠」、日本ロボット学会誌、Vol.15，No.3、社団法人日本ロボット学会、１９９７年４月１５日、p.51〜60
　
　５．横田一正・他、「マルチエージェントによる異種問題解決系の構想」、レクチャーノート／ソフトウェア学８　マルチエージェントと協調計算III、株式会社近代科学社、１９９４年１０月２０日、初版、p.67〜74、ISBN:4-7649-0227-3
　
備考：
　（１）請求項１について
　（中略）
　（２）請求項２、３については、請求項１と同様の理由により、進歩性は否定される。
　　　　　　　　　　　　　　　　　　　　　　　（以上、理由Ｃ）」
　
　（3-3）当審の判断
　そこで、上記拒絶理由について検討する。
　
　（イ）【理由Ａ】について
　上記【理由Ａ】において指摘されている「記載Ａ」は、上記［補正却下の決定の理由］の「（２）新規事項について」において指摘した「記載Ａ」と同趣旨の記載であり、上記「（２）新規事項について」において説明した理由と同様の理由により、当初明細書又は当初図面に記載された事項の範囲内のものではない。
　したがって、上記【理由Ａ】において指摘されている「記載Ａ」を含む平成２１年３月１７日付けでした手続補正は、当初明細書又は当初図面に記載した事項の範囲内においてしたものでないから、特許法第１７条の２第３項に規定する要件を満たしていない。
　
　（ロ）【理由Ｂ】の（１）について
　上記「（イ）【理由Ａ】について」で指摘したように、前記「記載Ａ」は、当初明細書又は当初図面に記載された事項の範囲内のものではない。また、上記「（3-1）本願明細書及び図面」で述べたように、発明の詳細な説明の記載は、当初明細書に記載されている発明の詳細な説明の記載と同じである。したがって、前記「記載Ａ」の具体的な実現手法は、当業者が実施可能な程度に明確かつ十分に発明の詳細な説明において開示されておらず、本願の発明の詳細な説明の記載は、特許法第３６条第４項に規定されている要件を満たしていない。
　
　（ハ）【理由Ｂ】の（２）について
　上記【理由Ｂ】の（２）において指摘されている「事項Ｃ」は、上記［補正却下の決定の理由］の「（４）独立特許要件について」の（Ｂ）において指摘した「事項Ｃ」と同趣旨の事項であり、上記「（４）独立特許要件について」の（Ｂ）において説明した理由と同様の理由により、具体的な実現手法が、当業者が実施できる程度に明確かつ十分に発明の詳細な説明において開示されていない。したがって、本願の発明の詳細な説明の記載は、特許法第３６条第４項に規定されている要件を満たしていない。
　
　（ニ）【理由Ｂ】の（３）について
　上述の如く平成２１年８月１０日付けの手続補正は却下されたから、図１４の記載も、補正前の記載（すなわち、当初図面の図１４の記載）に戻るので、同図に関連して指摘を行った上記【理由Ｂ】の（３）の記載不備は依然として解消されておらず、本願の発明の詳細な説明の記載は、特許法第３６条第４項に規定されている要件を満たしていない。
　
　（ホ）【理由Ｃ】について
　（ホ−１）本願発明
　平成２１年８月１０日付けの手続補正は上記のとおり却下されたので、本願明細書の特許請求の範囲の記載は、平成２１年３月１７日付け手続補正書により補正された特許請求の範囲に記載されたものとなり、その請求項１に記載されている発明（以下、「本願発明」という。）は、次のとおりのものである。
　
　（本願発明）
　新たな会話が発生するたびに生成され、生成されたそれぞれが前記会話を担当することにより、複数の会話を非同期に同時に進行することができる会話スレッドと、
　前記会話スレッドの生成を制御可能な会話スレッド制御部と、
　前記会話のメッセージが送出されるネットワークに対応したプロトコルに、前記メッセージを変換するプロトコル・マネジャと、
　前記会話に使われているエージェント・コミュニケーション言語を他の言語に翻訳するトランスレータと、
　を含むソフトウェア部品を有し、
　ネットワークを介して他のメッセージ処理装置にメッセージを送出可能なメッセージ処理装置で実行されるメッセージ処理方法であって、
　（ａ）新たな会話が発生するたびに生成された前記会話スレッドを含んでいるソフトウェア部品を停止する段階と、
　（ｂ）前記ソフトウェア部品をシリアライズによりネットワーク上転送可能となるように転換し前記ネットワークを介して他のメッセージ処理装置に送出する段階と、
　（ｃ）シリアライズされた前記ソフトウェア部品を、前記他のメッセージ処理装置において、デ・シリアライジングにより再開する段階と、を含むメッセージ処理方法。
　
　（ホ−２）引用発明Ｂ
　一方、上記【理由Ｃ】において引用文献１として引用した文献には、上記［補正却下の決定の理由］の「（A-2）引用文献」において引用文献１に記載されているものとして認定した「引用発明」を更に上位概念化して把握することによって得られる次の発明（以下、「引用発明Ｂ」という。）が記載されている。
　
　（引用発明Ｂ）
　複数の動的に生成されたスレッドを含み、メッセージの交換を行うエージェントを有し、 
　エージェントが実行される他のロケーションにメッセージを送出可能なロケーションで実行されるメッセージ処理方法であって、 
　（ａ）前記複数の動的に生成されたスレッドを含んでいるエージェントを停止する段階と、
　（ｂ）エージェントのプログラムとデータ（オブジェクトの属性）と実行状態を転送用の表現形式（transport representation）へと変形するとともに、エージェントのデータ状態（data state）をJavaSoft（Sun）によって提供されるJavaオブジェクト・シリアライゼーション・パッケージを用いて他のロケーションへ送出する段階と、
　（ｃ）前記エージェントの実行を、前記他のロケーションにおいて、受信したシリアライズされているデータ状態を用いて続行する段階と、を含むメッセージ処理方法。
　
　（ホ−３）対比
　次に、引用発明Ｂと、本願発明とを対比すると、上記［補正却下の決定の理由］の「（A-3）対比」と同様の理由により、引用発明Ｂと本願発明は、以下に記す一致点Ｂにおいて一致し、また、以下に記す相違点Ａ〜Ｅにおいて相違する。
　
　（一致点Ｂ）
　複数の動的に生成されたスレッドを含み、メッセージを送出するソフトウェア部品を有し、
　他のメッセージ処理装置にメッセージを送出可能なメッセージ処理装置で実行されるメッセージ処理方法であって、
　（ａ）前記複数の動的に生成されたスレッドを含んでいるソフトウェア部品を停止する段階と、
　（ｂ）前記ソフトウェア部品の実行再開に必要な、前記ソフトウェア部品の少なくとも一部の構成要素をシリアライズにより転送可能となるように転換し、他のメッセージ処理装置に送出する段階と、
　（ｃ）前記ソフトウェア部品を、前記他のメッセージ処理装置において、デ・シリアライジングにより再開する段階と、を含むメッセージ処理方法。
　
　（相違点Ａ）
　上記「（A-3）対比」で挙げた相違点１と同様。
　
　（相違点Ｂ）
　上記「（A-3）対比」で挙げた相違点２と同様。
　
　（相違点Ｃ）
　上記「（A-3）対比」で挙げた相違点３と同様。
　
　（相違点Ｄ）
　上記「（A-3）対比」で挙げた相違点４と同様。
　
　（相違点Ｅ）
　上記「（A-3）対比」で挙げた相違点５と同様。
　
　（ホ−４）判断
　次に、上記相違点の各々について検討する。
　
　まず、上記相違点Ａ及び相違点Ｂは、上記［補正却下の決定の理由］の「（A-4）判断」において相違点１及び相違点２について検討した理由と同様の理由により、格別のものとは認められない。
　
　次に、上記相違点Ｃについて検討する。
　上記【理由Ｃ】で挙げた引用文献４には、上記［補正却下の決定の理由］の「（A-4）判断」において引用文献４について述べたように、Type３のエージェントの内部では、HeadとBodyとisv2netという３つのプログラムが並列に稼働し、前記isv2netはエージェントからのデータが出力されるネットワークに対応するプロトコルに、前記データを変換するプログラム（本願発明の「プロトコル・マネジャ」に対応）であり、このようなものは周知技術に過ぎず、引用発明Ｂのエージェントが、このようなプロトコルの変換を行う周知なプログラムをその内部に含むようにすることは、当業者が容易に想到し得た事項に過ぎない。
　また、上記［補正却下の決定の理由］の「（A-4）判断」において引用文献５について述べたように、エージェントが送受信するメッセージの言語を変換するプログラム（本願発明の「トランスレータ」に対応）をエージェントの内部に含むようにすることは、上記【理由Ｃ】で挙げた引用文献５に開示されているように周知技術であり、この周知技術を用いて引用発明Ｂのエージェントの内部に上記言語の変換を行うプログラムを含ませる構成とすることは、当業者が容易に想到し得た事項に過ぎない。
　したがって、上記相違点Ｃも格別のものではない。 
　
　上記相違点Ｄは、上記［補正却下の決定の理由］の「（A-4）判断」において相違点４について検討した理由と同様の理由により、格別のものとは認められない。
　
　上記相違点Ｅは、上記［補正却下の決定の理由］の「（A-4）判断」において相違点５について検討した理由と同様の理由により、格別のものとは認められない。
　
　（ホ−５）【理由Ｃ】についてのまとめ
　以上のように、相違点Ａ〜Ｅは、いずれも格別のものではなく、本願発明が有する効果も当業者であれば当然に予測可能な効果に過ぎず、格別な効果でもない。
　したがって、本願発明は、引用文献１に記載されている引用発明Ｂに基づいて当業者が容易に発明できたものであるから、特許法第２９条第２項の規定により、特許を受けることができない。
　なお、請求人は審判請求理由において当時の引用文献３（上記【理由Ｃ】で挙げている引用文献１と同一の文献である。）について、「複雑で解決方法が難しい」という趣旨の記載が当該文献中に存在するという指摘を行っているが、上記【理由Ｃ】で挙げている
引用文献１には
解決策を示唆する記載が存在しているから
　
　（3-4）まとめ
　上記（3-3）の（イ）で述べたように、平成２１年３月１７日付けでした手続補正は、特許法第１７条の２第３項に規定された要件を満たしていないので、特許を受けることができない。
　また、上記（3-3）の（ロ）〜（ニ）で述べたように、本願の発明の詳細な説明の記載は、特許法第３６条第４項に規定されている要件を満たしていないので、特許を受けることができない。
　また、上記（3-3）の（ホ）で述べたように、本願発明は特許法第２９条第２項に規定されている要件を満たしていないので、特許を受けることができない。
　よって、結論のとおり審決する。