【事件の表示】
　特願２００４−５１４３２３「通信網に加入している端末に関係付けられた口座にクレジットを入金するための方法」拒絶査定不服審判事件〔平成１５年１２月２４日国際公開，ＷＯ０３／１０７６４７，平成１７年１０月６日国内公表，特表２００５−５３０２５４〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
１　手続の経緯
　本願は，平成１４年６月１８日を国際出願日とする出願であって，平成１８年１０月１９日付けの拒絶理由通知に対して，平成１９年４月２日付けで意見書が提出されるとともに同日付けで手続補正がなされたが，同年１２月１９日付けで拒絶の査定がなされ，この拒絶の査定を不服として，平成２０年３月２４日に審判請求がなされたものである。
　
２　本願発明
　本願の請求項１に係る発明（以下「本願発明」という。）は，明細書及び図面の記載からみて，平成１９年４月２日付けの手続補正により補正された特許請求の範囲の請求項１に記載された次の事項により特定されるものである。
　「通信網に加入しているユーザー端末に関係付けられた口座にクレジットを入金するための方法において，
　（１）ユーザー端末と通信網エンティティの間で対話を行い，少なくとも，クレジットを前記ユーザー端末に関係付けられた前記口座へ入金するか否か，入金されるクレジットの額，及び入金元を提示する段階と，
　（２）ＤＩＡＭＥＴＥＲプロトコルに基づいて，前記通信網エンティティから前記入金元に，前記ユーザー端末に関係付けられた口座へ前記クレジットの額を入金することを要求する段階と，から成り，
　前記（２）要求する段階は，当該要求を，口座へ或る額の入金を求める要求として識別するＤＩＡＭＥＴＥＲ要求メッセージを生成する段階を含んでおり，
　前記生成されたＤＩＡＭＥＴＥＲ要求メッセージは，ユーザー端末対入金先関係口座を識別する属性値対を更に含むことを特徴とする方法。」
　
３　引用例
　原査定の拒絶の理由に引用された特開２００２−７４００１号公報（以下「引用例１」という。）には，振込処理方法に関して，以下（１ａ）−（１ｇ）の記載がある。
（１ａ）「【００３７】さらに，本実施形態例は，ＡＴＭなどの端末ではなく，インターネットバンキングシステムを利用しているので，パソコン，携帯情報端末，携帯電話などの端末を利用している。
【００３８】図１は本発明の実施形態にかかる振込処理システムの構成を説明するための概念図である。」
（１ｂ）「【００４２】図２で示すように受取人端末と支払人端末はインターネット等ネットワーク（７）を介して本発明のシステムに接続されている。」
（１ｃ）「【００４３】図３は本発明の処理フロー例である。
【００４４】受取人認証（８）では本発明を利用して他の口座から引き出す受取人を特定するものである。
【００４５】受取人が誰かを特定することは本システムでは非常に重要な問題である。
【００４６】通常インターネットバンキング等で利用されている認証システムは図８のようにユーザーＩＤとパスワードをインターネット端末に入力するものが多く，本システムも既存のシステムを利用したものなのでこれを利用するが，更に優れた認証方式があれば，そちらを利用した方がよい。
【００４７】図５のように受取人口座に関連付けて公開鍵式暗号の暗号鍵を保存し，前記暗号鍵を基に認証局の証明を貰い，認証を行う方法も考えられる。」
（１ｄ）「【００４８】振込要求，支払人口座番号，必要であれば支払人端末コードを入力（９）は，先に認証を受け既に素性が知れている受取人が，振込要求手続きを入力するものである。」
（１ｅ）「【００５１】支払人への告知（１０）は端末指定コードを利用して電子メールで振込要求の存在を支払人に告知し，支払人をインターネットバンキングへと向かわせるものである。例えば図１３のような文面を利用することが考えられる。尚，端末のセキュリティレベルによっては，電子メールそのものに受取人の素性や振込要求を全て出力することも可能であり，さらに電子メールでＨＴＭＬが送信可能であれば，これを利用して振込要求に対する受諾をおこなう入力フォームをも支払人に出力可能である。」
（１ｆ）「【００５３】支払人への振込要求及び受取人情報を出力（１２）は図１０のような感じで支払人に出力されるものであって，振込要求受諾を入力（１３）のための入力装置（図１０では受諾ボタン）も一緒に出力されている。」
（１ｇ）「【００５４】振込要求にしたがって，振込処理が行われる（１４）は，追加システム（２）が金融機関で利用されている一般的な振込処理システム（１）に対して振込処理の引数を与え，帰ってきた結果を図９にある逆振込サービス入金状況として出力するようにした。もちろん，金融機関で利用されている一般的な振込処理システム（１）は口座間の資金の移動を行っている。
【００５５】図４，及び図５のテーブル例は，金融機関で利用されている一般的な振込処理システム（１）で利用されている口座データに，本発明で必要なデータを付け足した例である。」
　
　ここで，図４及び図５のテーブルをみると，「端末コード」と「口座データ」とが関連付けられており，上記の「受取人端末」と「受取人口座」とは関係付けられているといえる。
　また，図１０の支払人への振込要求出力画面をみると，「振込要求金額」，「受取人氏名」，「受取人住所」，「受取人電子メールアドレス」，「受取人口座」も表示されている。
　また，図１１及び図１２の振込要求手続き入力画面をみると，「振込要求金額」も入力される。
　さらに，上記（１ｅ）の「支払人への」「電子メールそのものに受取人の素性や振込要求を全て出力する」のに，振込処理のためのシステムが上記（１ｄ）の「支払人口座番号」，「支払人端末コード」及び上記の「振込要求金額」を受取人に関する情報と関係付けて記憶することは自明のことである。
　また，上記（１ｃ）の「ユーザーＩＤとパスワード」は，認証情報といえる。
　
　したがって，上記（１ａ）−（１ｇ）の記載及び図面の記載から，引用例１には，
　「受取人口座と関係付けられた携帯電話等の受取人端末と支払人端末とがネットワークを介して接続されている振込処理のためのシステムを利用した振込処理方法であって，
　受取人端末が認証情報を振込処理のためのシステムに送ると，振込処理のためのシステムが認証情報を受けて受取人認証を行い，受取人認証後，受取人端末が振込要求金額，支払人口座番号，支払人端末コードを含む振込要求を振込処理のためのシステムに送信するステップと，
　振込処理のためのシステムが振込要求金額，支払人口座番号，支払人端末コードを含む振込要求を受信して受取人に関する情報と関係付けて記憶し，振込要求金額，受取人の住所氏名，受取人電子メールアドレス，受取人口座を含む振込要求を支払人端末に送信するステップと，
　支払人端末が振込要求の受諾を振込処理のためのシステムに送信し，振込処理のためのシステムが振込要求の受諾を受信して支払人口座から受取人口座へ資金移動する振込処理を行うステップと，からなる振込処理方法。」
の発明（以下「引用発明」という。）が記載されていると認められる。
　
　同じく引用された特開２００２−１６４８８７号公報（以下「引用例２」という。）には，以下（２ａ）−（２ｌ）の記載がある。
（２ａ）「【００１４】【発明が解決しようとする課題】従来のＭｏｂｉｌｅ  ＩＰを使う端末に適用する認証課金システムは，パケット通信の認証課金を行うために設計されたシステムであり，例えば，移動端末上で発生した認証課金（例えば，買い物代金のクレジット支払いのための認証課金）に使うことはできなかった。」
（２ｂ）「【００１７】本発明は，上記事情を考慮してなされたもので，種々の目的でＭｏｂｉｌｅＩＰプロトコルに従う移動端末装置が所定のＡＡＡプロトコルに従うＡＡＡサーバ装置による認証課金サービスを利用することができるようにした，移動端末装置，ＡＡＡサーバ装置，移動通信システム，認証課金サービス提供方法，認証課金サービス享受方法を提供することを目的とする。」
（２ｃ）「【００３５】図１に，本実施形態に係る通信システムのネットワーク構成例を示す。（途中省略）
【００３８】移動端末１０１０は，サブネットワーク１００１をホームネットワークとする，Ｍｏｂｉｌｅ  ＩＰにおける移動端末機能（Ｍｏｂｉｌｅ  ＩＰ処理部）と，ＡＡＡ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ，  Ａｕｔｈｏｒｉｚａｔｉｏｎ  ａｎｄ  Ａｃｃｏｕｎｔｉｎｇ）（例えば，ＤＩＡＭＥＴＥＲ，あるいはＲＡＤＩＵＳ）を利用した課金サービス（他の端末のユーザへの代金の支払い手続きと，その支払代金の自身への通信料の請求分への付け替え手続きを行うサービス等）を受けるための機能（ＡＡＡＭ）（ＡＡＡ処理部）を有する端末である。」
（２ｄ）「【００９０】次に，図１６，図１７を参照しながら，認証課金サービスや認証課金要求／応答の他の例（決済処理サービス）について説明する。図１６は，図１から認証課金サービスに関係する部分を抜き出して記述したものである（図１６では，移動端末１０１０からＡＡＡＦサーバ１０２２を経由せずにＡＨサーバ１０１２に要求がなされる場合を示している）。図１７は，認証課金サービスの手順の他の例である。」
（２ｅ）「【００９２】まず，移動端末１０１０は，例えば上記のＳ２０６で得られた課金情報に基づいて，ＡＡＡＨサーバ１０１２からＡＡＡｙサーバ１０３２に電子決済を行うため，ＡＡＡＨサーバ１０１２に対して，支払い要求を（要求パケットによって）送付する（Ｓ２０７）。」
（２ｆ）「【００９４】次に，ＡＡＡＨサーバ１０１２は，移動端末１０１０から支払い要求のパケットを受信した場合，該当するＡＡＡｙサーバ１０３２に対して，電子決済を行う。例えば，料金データベース記憶部１２０２に必要な情報を記録する。
【００９５】そして，ＡＡＡＨサーバ１０１２は，ＡＡＡｙサーバ１０３２に対して，支払に関する情報のパケットを送信する（Ｓ２０８）。」
（２ｇ）「【００９７】次に，ＡＡＡｙサーバ１０３２は，ＡＡＡＨサーバ１０１２から支払に関する情報を受信した場合，端末１０３０に対し，支払いがあったことを通知するパケットを送信する（Ｓ２０９）。」
（２ｈ）「【００９９】これとともに，ＡＡＡｙサーバ１０３２は，ＡＡＡＨサーバ１０１２に支払い確認応答パケットを送る（Ｓ２１０）。」
（２ｉ）「【０１００】そして，ＡＡＡＨサーバ１０１２は，ＡＡＡｙサーバ１０３２から支払い確認応答パケットを受信した場合，これを，移動端末１０１０へ転送する（Ｓ２１１）。」
（２ｊ）「【０１０２】なお，端末１０３０のユーザに料金を支払う方法としては，例えば，（１）ＡＡＡＨサーバ１０１２の料金データベース記憶部１２０２で，移動端末１０１０のユーザに対して（＋Ｘ）円の課金を記録した場合に，ＡＡＡｙサーバ１０３２の料金データベース記憶部（図示せず）で，端末１０３０のユーザに対して（−Ｘ）円の課金を記録する方法（課金額が正の値になった場合には，通信料金として徴収を行うが，課金額が負の値になった場合には，支払を行う）（途中省略）など，種々の方法がある。」
（２ｋ）「【０１１０】また，移動端末１０１０のホーム・ネットワークと端末１０３０の属するネットワークとが等しい場合に，ＡＡＡＨサーバとＡＡＡＹサーバが同一のサーバになる場合がある（異なるサーバである場合もある）。」
（２ｌ）「【０１１７】なお，以上では，本発明を電子決済に関する手続きに適用した場合を例にとって説明したが，もちろん，本発明は，種々の処理あるいは手続きに適用可能である。以下，その他の例を列挙する。（途中省略）
・第３者による，通話料金の代行支払（移動端末が，広告主に第１の要求を送り，移動端末が広告を見終わった時点で，広告主が応答を返し，広告を見た見返りに，移動端末がその次に通話する代金の一部または全部を該広告主が負担するサービスなど）。」
　
　上記（２ａ）−（２ｌ）の記載及び図面の記載から，引用例２には，
　支払人（移動端末１０１０のユーザー）から受取人（端末１０３０のユーザー）への代金支払のためのサービスを提供するのに，サーバ装置ＡＡＡＨが，ＤＩＡＭＥＴＥＲプロトコルに従い支払人の移動端末１０１０と通信して代金支払のための処理を行うこと
が記載されていると認められる。
　
４　対比
　本願発明と引用発明とを対比すると，
　引用発明の「ネットワーク」，「受取人端末」，「受取人口座」，「資金」は，本願発明の「通信網」，「ユーザー端末」，「口座」，「クレジット」に各々相当し，
　引用発明の「受取人口座へ資金移動する」は，本願発明の「口座にクレジットを入金する」に相当し，
　引用発明の「振込処理のためのシステム」は，受取人端末にネットワークを介して振込処理サービスを提供するのであるから，本願発明の「通信網エンティティ」に相当し，
　引用発明の「振込要求金額」は，本願発明の「入金されるクレジットの額」に相当し，
　引用発明の「支払人口座番号，支払人端末コード」は，本願発明の「入金元」に相当し，
　引用発明の「振込処理のためのシステム」に送信される「振込要求」は，受取人口座への振込要求であり，「クレジットをユーザー端末に関係付けられた口座へ入金する」ことを提示するものといえるから，
　引用発明の「受取人端末が認証情報を振込処理のためのシステムに送ると，振込処理のためのシステムが認証情報を受けて受取人認証を行い，受取人認証後，受取人端末が振込要求金額，支払人口座番号，支払人端末コードを含む振込要求を振込処理のためのシステムに送信するステップ」は，本願発明の「ユーザー端末と通信網エンティティの間で対話を行い，少なくとも，クレジットを前記ユーザー端末に関係付けられた前記口座へ入金するか否か，入金されるクレジットの額，及び入金元を提示する段階」と「ユーザー端末と通信網エンティティの間で対話を行い，少なくとも，クレジットをユーザー端末に関係付けられた口座へ入金することに関する情報，入金されるクレジットの額，及び入金元を提示する段階」として共通し，
　引用発明の「振込処理のためのシステムが振込要求金額，支払人口座番号，支払人端末コードを伴った振込要求を受信して受取人に関する情報と関係付けて記憶し，振込要求金額，受取人の住所氏名，受取人口座を伴った振込要求を支払人端末に送信するステップ」は，本願発明の「ＤＩＡＭＥＴＥＲプロトコルに基づいて，前記通信網エンティティから前記入金元に，前記ユーザー端末に関係付けられた口座へ前記クレジットの額を入金することを要求する段階」と「通信網エンティティから入金元に，ユーザー端末に関係付けられた口座へクレジットの額を入金することを要求する段階」として共通している。
　
　したがって，両者は，
　「通信網に加入しているユーザー端末に関係付けられた口座にクレジットを入金するための方法において，
　（１）ユーザー端末と通信網エンティティの間で対話を行い，少なくとも，クレジットを前記ユーザー端末に関係付けられた前記口座へ入金することに関する情報，入金されるクレジットの額，及び入金元を提示する段階と，
　（２）前記通信網エンティティから前記入金元に，前記ユーザー端末に関係付けられた口座へ前記クレジットの額を入金することを要求する段階と，から成ることを特徴とする方法。」
である点で一致し，以下の点で相違している。
　
［相違点１］
　本願発明は，提示する段階で，クレジットをユーザー端末に関係付けられた口座へ入金するか否かを提示するのに対して，引用発明は，クレジットをユーザー端末に関係付けられた口座へ入金することを提示しており，本願発明のようなものではない点。
［相違点２］
　本願発明は，通信網エンティティから入金元に，ユーザー端末に関係付けられた口座へクレジットの額を入金することを要求するのに，ＤＩＡＭＥＴＥＲプロトコルに基づいて要求するものであって，要求する段階が，当該要求を，口座へ或る額の入金を求める要求として識別するＤＩＡＭＥＴＥＲ要求メッセージを生成する段階を含んでおり，前記生成されたＤＩＡＭＥＴＥＲ要求メッセージは，ユーザー端末対入金先関係口座を識別する属性値対を更に含むものであるのに対して，引用発明は，そのようなものではない点。
　
５　判断
　［相違点１］について検討する。
　ユーザーがサービス提供者にサービスを希望する手続きを行うのに際して，サービスを希望するか否かを提示することが例示するまでもなく周知の事項であるから，引用発明において，提示する段階で，クレジットをユーザー端末に関係付けられた口座へ入金するか否かを提示するようにして，本願発明のようにすることは，当業者が容易になし得たことである。
　［相違点２］について検討する。
　引用例２に，支払人から受取人への代金支払いのためのサービスを提供するのに，サーバ装置が，ＤＩＡＭＥＴＥＲプロトコルに従い支払人の移動端末と通信して代金支払いのための処理を行うことが記載されているから，引用発明において，通信網エンティティから入金元に，ユーザー端末に関係付けられた口座へクレジットの額を入金することを要求するのに，ＤＩＡＭＥＴＥＲプロトコルに基づいて要求するものとし，要求する段階が，当該要求を，口座へ或る額の入金を求める要求として識別するＤＩＡＭＥＴＥＲ要求メッセージを生成する段階を含むようにすることは，当業者が容易になし得たことである。
　その際に，ＤＩＡＭＥＴＥＲプロトコルにおけるメッセージが属性値ペア（ＡＶＰ）を含むことが例示するまでもなく周知の事項であり，引用発明の振込要求も受取人電子メールアドレスと受取人口座を含むものであるから，さらに，生成されたＤＩＡＭＥＴＥＲ要求メッセージが，ユーザー端末対入金先関係口座を識別する属性値対を更に含むものとして，本願発明のようにすることは，当業者が容易に想到し得たことである。
　
　そして，本願発明の効果も，引用発明，引用例２に記載された事項及び周知の事項の効果から，当業者が容易に予測し得た程度のものである。
　
　したがって，本願発明は，引用発明，引用例２に記載された事項及び周知の事項に基いて，当業者が容易に発明をすることができたものと認められる。
　
６　むすび
　以上のとおり，本願発明は，引用発明，引用例２に記載された事項及び周知の事項に基いて，当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
　よって，結論のとおり審決する。