【事件の表示】
　特願２００７−５５４４４１「トランザクション情報を処理するためのトランザクションシステム、及びトランザクションを遂行する方法」拒絶査定不服審判事件〔平成１８年　８月１７日国際公開、ＷＯ２００６／０８４５０１、平成２０年　８月　７日国内公表、特表２００８−５３０６６５〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　
　本願は，２００５年１２月２８日（パリ条約による優先権主張外国庁受理２００５年２月９日　欧州特許庁）を国際出願日とする出願であって，
平成１９年８月８日付けで特許法第１８４条の５第１項の規定による書面が提出され，
平成１９年１０月４日付けで特許法第１８４条の４第１項の規定による明細書，請求の範囲，及び，図面（図面の中の説明に限る）の日本語による翻訳文が提出され，
平成２０年１１月１１日付けで審査請求がなされ，
平成２３年８月２３日付けで審査官により拒絶理由通知がなされたが，これに対する応答はなく，
平成２４年２月３日付けで審査官により拒絶査定がなされ，
これに対して平成２４年６月７日付けで審判請求がされるとともに，同日付けで手続補正がなされ
平成２４年８月２９日付けで特許法第１６４条第３項に定める報告（前置報告）がなされ，
平成２４年１１月１５日付けで当該報告に対する意見を求める旨の審尋がなされ，
平成２５年２月１８日付けでこれに対する回答がなされ，
平成２６年１月２１日付けで当審により拒絶理由が通知され，
これに対して平成２６年５月２７日付けで意見書が提出されたものである。
　
　
第２．平成２４年６月７日付け手続補正
　
　上記平成２４年６月７日付けの手続補正は，特許請求の範囲を下記本願特許請求の範囲に補正するものである。
　
「　【請求項１】
　送り状を作るデータを得るための手段を具備し，少なくとも１つのサービスプロバイダのトランザクション情報を処理するためのトランザクションシステムであって，
　前記トランザクションシステムは，電気的にトランザクション処理モジュールによって処理される，トランザクション若しくはビジネスプロセスをマップするための少なくとも１つのトランザクション処理モジュールを備え，
　前記トランザクションは，トランザクションを実行するための前記トランザクション処理モジュールにそれぞれ関連付けられ，プロセスをプロセスの要素である部分的なプロセスに分解することを可能にし，前記各トランザクション処理モジュールのそれぞれがデータを受信及び／又は送信，及び，データを取得，及び／又は，処理するように構成され
　前記トランザクション処理モジュールは，コンテキストマネージャによって管理し，初期設定された送り状を作るデータが記憶されるデータコンテナを備えるとともに，
　少なくとも１つのデータモジュールにインターフェースを介して接続され，前記データモジュールは，アプリケーション特有のデータ構造を生データに変形する生データモジュールであり，
　前記生データの記録は，いくつかの部分から成り，その一方は，構造の点においてスタティックであり，すべての生データの記録に関連している技術的，及び手続き的データが含まれ，１つのタイプのビジネストランザクションから別のものに変わる手続き的データが含まれ，
　前記コンテキストマネージャは，前記トランザクション処理モジュールのための中央制御方法として，または前記トランザクション処理モジュールのための中央サービスプロバイダとして形成され，前記トランザクション処理モジュールを始動，及び／又は，終了できるように構成され，
　前記データコンテナは，トランザクションプロセスで生成されたデータオブジェクトを記憶するためのものであり，システムクラッシュの後に前記データオブジェクトを修復することができるデータの可変値そして規定されたプロパティを含んでいることを特徴とする，トランザクションシステム。
　　【請求項２】
　前記データモジュールは，データコンポーネントを備えることを特徴とする，請求項１に記載のトランザクションシステム。
　　【請求項３】
　前記トランザクションシステムは，データコンテナを，始動，及び／又は，終了できるように構成される制御モジュールを備えることを特徴とする，請求項１又は請求項２に記載のトランザクションシステム。
　　【請求項４】
　前記コンテキストマネージャは，互いに関係なく複数のトランザクション処理モジュールを，始動，及び／又は，終了できるように構成されることを特徴とする，請求項１に記載のトランザクションシステム。
　　【請求項５】
　前記コンテキストマネージャは，制御モジュールとして構成されることを特徴とする，請求項１から請求項４のうちいずれか１項に記載のトランザクションシステム。」
　
　
第３．平成２６年１月２１日付けの当審拒絶理由
　
　当審による平成２６年１月２１日付けの拒絶理由（以下，これを「当審拒絶理由」という）は，概略，次のとおりである。
　
『１．この出願の請求項１〜５に係る発明は，その出願前日本国内において頒布された下記の刊行物１〜６に記載された発明に基づいて，その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
　
２．この出願は，明細書，特許請求の範囲及び図面の記載が下記の点で，特許法第３６条第４項第１号及び第６項第１号，第２号に規定する要件を満たしていない。　
　
　　　　　　　　　　　　　　　　　記　 
　
（理由１）
［引用文献等一覧］
１．特開２００４−２３４２０３号公報
２．特表２００４−５３６４０２号公報
３．SHUPING　RAN　その他：“The　rigorous　evaluation　of　enterprise　java　bean　technology”INFORMATION　NETWORKING,２００１.PROCEEDINGS.15TH　INTERNATIONAL　CONFERENCE　ON　31　JANUARY-2,PISCATAWAY,NJ,米国,IEEE,２００１年,　ｐ９３−１００
４．特表２００３−５２９９５２号公報　
５．特開２００３−１５７２４２号公報　
６．特開平９−３１１８９９号公報　
　
備考：　
　
・・・（中略）・・・
　
　以上のとおりであるから，本願発明は，引用発明１，引用文献４に記載された技術事項，及び，周知の技術事項から，当業者が容易に想到し得たことと認められる。 
　
・・・（中略）・・・
　
（理由２）
（１）特許法第３６条第４項第１号について　
ア　発明の詳細な説明の記載では，図１の記載されている本発明に係るトランザクションシステムを示す概略図の構成及びその動作が不明りょうである。
　すなわち，発明の詳細な説明の図１の構成を説明するための記載と認められる下記のａ〜ｆについては，対応する記号の記載が図１になされていない。
　
ａ．００８２段落に「［承認モジュール　ＢＭ］　承認モジュールは様々な承認（例えば，承認の機能として表われたメニュー構造の制御）を制御する。但し，承認の概念は提供された記述に基づいて他の要素に従って拡大されなければならない。」と記載されているが，図１には，［承認モジュール　ＢＭ］についての記載がなされていない。
　
ｂ．００８３段落に「［ライブラリ］　ライブラリはＣＡＲＢＯＮフレームワークの基礎的な機能を具備する。前記基礎的な機能は，例えば，記録すること，エラーを処理すること，システム情報へのアクセスなどの機能である。」と記載されているが，図１には，「ライブラリはＣＡＲＢＯＮフレームワーク」についての記載がなされていない。
　
ｃ．００８５段落に「［ＣＡＲＢＯＮ］　ＣＡＲＢＯＮは，好適に次の構成要素を具備するプラットフォームに関するものである。
（１）クライアント　
（２）トランザクションタイプ　
（３）コンポーネント　
（４）ライブラリ」と記載されているが，図１には，［ＣＡＲＢＯＮ］についての記載がなされていない。
　
ｄ．００８６段落に「［ＣＡＲＢＯＮクライアント］　ＣＡＲＢＯＮクライアントは，個別の機能／アプリケーションを始動する。いくつかのＣＡＲＢＯＮクライアントはお互いに隣接して存在する。」と記載されているが，図１には，［ＣＡＲＢＯＮクライアント］についての記載がなされていない。
　
ｅ．００８８段落に「［ＣＡＲＢＯＮフレームワーク　ＣＦ］　ＣＡＲＢＯＮフレームワークは，いくつかのモジュールをまとめて有することが好ましい。ＣＡＲＢＯＮフレームワークは，アシスタントを基礎とするトランザクションタイプのためのクライアントを生成する機能を具備するＡＰＩであることが好ましい。」と記載されているが，図１には，［ＣＡＲＢＯＮフレームワーク　ＣＦ］についての記載がなされていない。
　
ｆ．００９１段落に「［ＣＡＲＢＯＮカーネル］　ＣＡＲＢＯＮカーネルの機能が実装された領域は，ＣＡＲＢＯＮカーネルと呼ばれる。」と記載されているが，図１には，［ＣＡＲＢＯＮカーネル］についての記載がなされていない。
　
イ　図３に示されている本発明に係る情報技術システムのブロックダイヤグラムに関して，発明の詳細な説明には，０１４０段落の記載がなされているが，この０１４０段落には，図３の記載されている本発明に係る情報技術システムの構成及びその動作が詳細に説明されておらず，図３に示されている本発明に係る情報技術システムの構成及びその動作が理解できない。
　
ウ　図４に示されている本発明に係るトランザクションの論理的順序を説明するブロックダイヤグラムに関して，発明の詳細な説明には，０１５０落の記載がなされているが，この０１５０段落には，図４の記載されている本発明に係るトランザクションの論理的順序を説明するブロックダイヤグラムに関して詳細に説明されておらず，図４に示されている本発明に係るトランザクションの論理的順序を説明するブロックダイヤグラムの構成及びその動作が理解できない。
　
エ　図５に示されている本発明に係る情報技術システムにおける論理的コンポーネント間の生データの交換を説明するブロックダイヤグラムに関して，発明の詳細な説明には，０１５１落の記載がなされているが，この０１５１段落には，図５に記載されている本発明に係る情報技術システムにおける論理的コンポーネント間の生データの交換を説明するブロックダイヤグラムに関して詳細に説明されておらず，図５に示されている本発明に係る情報技術システムにおける論理的コンポーネント間の生データの交換を説明するブロックダイヤグラムの構成及びその動作が理解できない。　
　
　以上のとおりであるから，本願の発明の詳細な説明の記載は，その発明の属する技術の分野における通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記載されているとは認められない。　
　
（２）特許法第３６条第６項第１号，第２号に規定する要件を満たしていない。
オ　請求項１に「トランザクションシステムは，電気的にトランザクション処理モジュールによって処理される，トランザクション若しくはビジネスプロセスをマップする」と記載されているが，「ビジネスプロセスをマップする」は何を意味するのか不明である。
（「何」かを「何」かにマッピングすることを意味するのであれば，「何」を「何」にマッピングしているのか不明である。）
　
カ　請求項１に「前記トランザクション処理モジュールは，コンテキストマネージャによって管理し，初期設定された送り状を作るデータが記憶されるデータコンテナを備えるとともに，」と記載されているが，この記載における「初期設定された送り状を作るデータ」とは如何なる「データ」であるのか明りょうでない。
　また，この「初期設定された送り状を作るデータ」が発明の詳細な説明及び図面のいずれを指すのか明確でない。
　
キ　請求項１に「少なくとも１つのデータモジュールにインターフェースを介して接続され，前記データモジュールは，アプリケーション特有のデータ構造を生データに変形する生データモジュール」と記載されているが，明細書を参酌しても「生データ」がどのような「データ」であるのか定義が不明であり，「生データモジュール」がどのようなものであるのか不明確である。
　
ク　請求項１に「前記生データの記録は，いくつかの部分から成り，その一方は，構造の点においてスタティックであり，すべての生データの記録に関連している技術的，及び手続き的データが含まれ，１つのタイプのビジネストランザクションから別のものに変わる手続き的データが含まれ」と記載されているが，この記載は何を意味するのか不明である。
　例えば，「記録，はいくつかの部分から成り」は日本語として何を意味するのか不明である。「記録」が「記録する」動作を意味するのか，「記録」されたデータを意味するのか，それとも何を意味するのか不明である。また，記録される場所についても不明である。）
　また，「その一方は」と記載されているが，何に対して「一方」であるのか不明である。
　また，「構造の点においてスタティックであり」についても，「データの記録」が構造の点についてスタティック（静的）であるとは何を意味するのか不明である。
　さらに，「技術的データ」がどのような「データ」であるのか定義が不明である。そして，「生データの記録は，」「すべての生データの記録に関連している技術的，及び手続き的データが含まれ」についても，日本語として何を意味するのか不明である。同様に，「生データの記録は，」「１つのタイプのビジネストランザクションから別のものに変わる手続き的データが含まれ」についても日本語として何を意味するのか不明である。
　また，「１つのタイプのビジネストランザクションから別のものに変わる」について，「別のもの」が何を意味するのか不明である。』
　
　
第４．平成２６年５月２７日付けの意見書
　
　上記第３．の当審拒絶理由に対し，上記平成２６年５月２７日付けの意見書（以下，これを「当審意見書」という）における意見の内容は以下のとおりである。
 
『３．本願発明が特許されるべき理由
　（ａ）理由１について
　本願発明と引用文献１に記載の引用発明１との相違点について，「分散トランザクションシステム」に送り状を作るデータを得る手段を設けて本願発明のように構成することと，「トランザクション集中管理部１３０」をコンテキストマネージャーに代えて本願発明のように構成することと，外部から入力されるデータを処理できる形式のデータに変換する手段を設けて本願発明のように構成することと，処理対象のデータを固定部分と可変部分とに分けて処理するようにして本願発明のように構成することとは，それぞれ当業者が容易に想到し得たものである。しかし，引用発明１を「分散トランザクションシステム」において送り状を作るデータを得る手段を設け，「トランザクション集中管理部１３０」をコンテキストマネージャーに代え，外部から入力されるデータを処理できる形式のデータに変換する手段を設け，処理対象のデータを固定部分と可変部分とに分けて処理するようにして，相違点の全てを一括して本願発明のように構成することは当業者が容易に想到し得ないと考える。
　同様にして，本願発明と引用文献２に記載の引用発明２との相違点および本願発明と引用文献３に記載の引用発明３との相違点の全てを一括して本願発明のように構成することは当業者が容易に想到し得ないと考える。
　（ｂ）理由２について
　図１に記載されている本願発明に係るトランザクションシステムを示す概略図の構成及びその動作は，本願の発明の詳細な説明の記載から明りょうである。すなわち，本願の発明の詳細な説明の記載は，その発明の属する技術の分野における通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記載されていると考える。
４．むすび
　したがって，本願発明は引用発明１，引用発明２および引用発明３から，その発明の属する技術分野における通常の知識を有する者が容易に発明をすることができたものではない。また，不明りょうな記載はない。よって，原査定を取り消す，この出願の発明はこれを特許すべきものとする，との審決を求める。』
　
　
第５．当審の判断
　
　以下では，まず，当審拒絶理由のうち，上記第３，（理由２）が解消されたものであるか否かについて判断し，その後，上記第３，（理由１）が解消されたものであるか否かについて判断する。
　
１．（理由２）の（１）（特許法第３６条第４項第１号）について
　
（１）本願の請求項１に係る発明である「トランザクションシステム」に関し，特に図１に係る本願明細書の発明の詳細な説明は，依然として，当業者が本願の請求項１に係る発明を実施することができる程度に明確かつ十分に記載されていない。
　すなわち，本願の請求項１に係る発明である「トランザクションシステム」に関し，本願明細書の発明の詳細な説明の段落【００６８】〜【００９２】には以下の記載がある。（下線は説明の便宜上，当審で附与したものである。）
　
「【００６８】
　本発明の特に好ましい実施形態では，トランザクション処理モジュールが統合されているトータルシステムは，トランザクションが最も小さい機能ユニットに分解された高度にモジュール化された方式である。従って，トランザクション処理モジュールは特に他の，複数のトランザクション処理モジュールの要素であるプロセスをマップすることができる。例えば，トランザクション処理モジュールはバー・コードのスキャン，個人的なアイデンティティデータの獲得または値の計算をマップすることができる。これらの個々のプロセスは，ただ一度実行されなければならないように，他のトランザクション処理モジュールによってモジュールとして呼ぶことができる。
【００６９】
　コンピュータシステムは少なくとも２つのデータソースかデータ受信端末から成り立つ。データソースはデータが供給される起源の場所である。データ受信端末はデータ及びこうして受け取るサイトの行先である。データの受け取りは普通，標準化されたインターフェースによって起こる。データソース及びデータ受信端末は，例えば，ローカルデータベース，サーバに支援されたデータベース，アプリケーションサーバまたはサードパーティシステムいずれの場合もある。以下，簡単に，そのようなデータソース及びデータ受信端末を一般にデータシステムと呼ぶ。データシステムは出力側と同様，入力側に置くことができる。
図１
・・・（中略）・・
【００７７】
　本発明の特に好ましい実施形態を以下に示す。
【００７８】
・・・（中略）・・
【００８２】
　
［承認モジュール　ＢＭ］
　
承認モジュールは様々な承認（例えば，承認の機能として表われたメニュー構造の制御）を制御する。但し，承認の概念は提供された記述に基づいて他の要素に従って拡大されなければならない。
【００８３】
　
［ライブラリ］
　
ライブラリはＣＡＲＢＯＮフレームワークの基礎的な機能を具備する。前記基礎的な機能は，例えば，記録すること，エラーを処理すること，システム情報へのアクセスなどの機能である。
【００８４】
　ライブラリの機能は，クライアント側の通信基盤を必要としない。特に，それぞれ適切に構築されたプログラムは，ライブラリの機能にアクセスすることができる。ライブラリはユーザーへの直接のダイアログではなく，確実にユーザ・インタフェースと関連付けられるコンポーネントを具備することが好ましい。前記コンポーネントはＣＡＲＢＯＮフレームワーク，クライアント，又はトランザクション処理モジュールによって使用される補助機能（メッセージ表示）である。
【００８５】
　
［ＣＡＲＢＯＮ］
　
ＣＡＲＢＯＮは，好適に次の構成要素を具備するプラットフォームに関するものである。
　
（１）クライアント
　
（２）トランザクションタイプ
　
（３）コンポーネント
　
（４）ライブラリ
【００８６】
　
［ＣＡＲＢＯＮクライアント］
　
ＣＡＲＢＯＮクライアントは，個別の機能／アプリケーションを始動する。いくつかのＣＡＲＢＯＮクライアントはお互いに隣接して存在する。
【００８７】
　基本的に，全てのプログラムは，ＣＡＲＢＯＮネットワーク全体，又はＣＡＲＢＯＮネットワークの一部のどちらかを使用するクライアントとして参照することができる。大部分において，前記プログラムはいくつかのトランザクションを実行することを目的とするプログラムである。しかし，ＣＡＲＢＯＮホストのような，他のＣＡＲＢＯＮクライアントにサービスを提供する他のプログラムもまたクライアントとして参照することができる。
【００８８】
　
［ＣＡＲＢＯＮフレームワーク　ＣＦ］
　
ＣＡＲＢＯＮフレームワークは，いくつかのモジュールをまとめて有することが好ましい。ＣＡＲＢＯＮフレームワークは，アシスタントを基礎とするトランザクションタイプのためのクライアントを生成する機能を具備するＡＰＩであることが好ましい。
【００８９】
　ＣＡＲＢＯＮフレームワークの範囲において提供される前記機能は四つの作業エリアにグループ化されることが好ましい。
　（１）コア機能−前記クライアントの始動／終了，トランザクションの始動／終了，又は管理
　（２）トランザクション補助（マスク，データ管理，シーケンス制御等）
　（３）コンポーネント（データへのアクセス，印刷等）
　（４）基礎的機能の供給（記録すること，エラー処理等）
【００９０】
　［ＣＲＡＢＯＮホストＣＨ］
　ＣＡＲＢＯＮホストは，他のモジュール若しくはサービスを起動，終了，若しくは停止することができるホストモジュールである。
【００９１】
　
［ＣＡＲＢＯＮカーネル］
　
ＣＡＲＢＯＮカーネルの機能が実装された領域は，ＣＡＲＢＯＮカーネルと呼ばれる。
【００９２】
　ＣＡＲＢＯＮカーネルは複数のコンポーネントで構成することが好ましい。前記コンポーネントの一例を以下に示す：
　すなわち，Ｅｐｏｓ．アプリケーション，ＣＡＲＢＯＮ．コンテキスト，ＣＡＲＢＯＮ．リカバリー，及びＣＡＲＢＯＮ．セッションである。
　特に，前記コンポーネントは次の機能を実行するために構成されることが好ましい。
　（１）Ｅｐｏｓ．アプリケーション−アプリケーションの始動，アプリケーションフレームワークの初期化及び管理，
　（２）ＣＡＲＢＯＮ．コンテキスト−トランザクションタイプの始動，停止，管理，ホスティングサービス，バックアップ，修復の制御，
　（３）ＣＡＲＢＯＮ．リカバリー−バックアップ，修復のためのデータ記録，管理，
　（４）ＣＡＲＢＯＮ．セッション−セッションの管理。」
　
　上記引用の記載は，本願発明の概略図である図１の各構成について説明するための記載とされるところ，上記引用の記載のうち，段落【００８２】における「承認モジュール　ＢＭ」，段落【００８３】における「ライブラリ」，段落【００８５】における「ＣＡＲＢＯＮ」，段落【００８６】における「ＣＡＲＢＯＮクライアント」，段落【００８８】における「ＣＡＲＢＯＮフレームワーク　ＣＦ」，及び，段落【００９１】における「ＣＡＲＢＯＮカーネル」については，いずれも，対応する構成が図１に示されておらず，図１において本願発明が具体的にどのように構成され，かつ各構成がどのように動作するのかについて不明りょうである。よって，本願明細書の発明の詳細な説明は，依然として，当業者が本願の請求項１に係る発明を実施することができる程度に明確かつ十分に記載されておらず，特許法第３６条第４項第１号で定めるところによる記載がされていないものでもある。
　したがって，当審拒絶理由の（理由２），（１），ア，ａ．〜ｆ．でも指摘した点は解消されておらず，特許法第３６条第４項第１号で定めるところによる記載がされていないものでもある。
　
（２）本願の請求項１に係る発明である「トランザクションシステム」に関し，特に図５に係る本願明細書の発明の詳細な説明は，依然として，当業者が本願の請求項１に係る発明を実施することができる程度に明確かつ十分に記載されていない。
　すなわち，本願の請求項１に係る発明である「トランザクションシステム」に関し，本願明細書の発明の詳細な説明の段落【０１５１】には以下の記載がある。
　
「【０１５１】
　図式的なブロックダイヤグラムにより，図５に総合システムにおける，個々の層間の生データ交換についての論理的順序を示す。図５では，４つのデータブロック３１ａ，３１ｂ，３１ｃ及び３１ｄは例を用いて示される。データブロック３１ａから３１ｄのそれぞれは生データのための基礎としてアプリケーション特有のデータ構造を備える。但しこれらのデータ構造が生データでないことが，示されるべきである。生データは，生データモジュール３２が，一度アプリケーション特有のデータ構造をデータブロック３１ｃから生データに変形させたときのみ得られる。よって，生データモジュール３２はデータ変形プロセスを遂行する。２つの矢印３３ａ及び３３ｂによって示されるトランザクションのステップでは，生データサービスコンポーネント３５と同様，アーカイブの記憶３４で記憶されるところで，生データの記録は入力側１１から部門出力側１２に送信される。与えられたトランザクションに必要であれば，生データサービスコンポーネント３５はサードパーティシステム１４に生データを送信する。適切なアカウントの原則に従うために，トランザクションのアプリケーション特有のデータはまた記憶される。データブロック３１ａ及び３１ｂは，生データに変えられない相互作用データ及びプロセスデータを表すが，むしろこのために特に提供されるサービスコンポーネント３６及び３７で変わらずに送信される。サービスコンポーネント３６及び３７は，部門出力側１３とサードパーティシステム１４間の相互作用データ及びプロセスデータの交換もまた保障する。」
　
　しかしながら，上記引用の記載には，図５に示された，本願発明に係るシステムにおける生データの交換が，本願発明のどの構成により，どのように行われているのか，具体的に何ら示されておらず，また，その他の箇所にも，図５について説明する箇所を見出せない。よって，図５において本願発明が具体的にどのように構成され，かつ各構成がどのように動作するのかについて不明りょうであることから，本願明細書の発明の詳細な説明は，依然として，当業者が本願の請求項１に係る発明を実施することができる程度に明確かつ十分に記載されているとはいえず，特許法第３６条第４項第１号で定めるところによる記載がされていないものでもある。
　したがって，当審拒絶理由の（理由２），（１），エでも指摘した点は解消されておらず，特許法第３６条第４項第１号で定めるところによる記載がされていないものでもある。
　
（３）以上の点について，審判請求人は，当審意見書において，
『　（ｂ）理由２について
　図１に記載されている本願発明に係るトランザクションシステムを示す概略図の構成及びその動作は，本願の発明の詳細な説明の記載から明りょうである。すなわち，本願の発明の詳細な説明の記載は，その発明の属する技術の分野における通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記載されていると考える。』
　と主張しているが，上記主張は，上記（理由２）の（１）の当審拒絶理由に対し，何ら具体的な釈明を行うものではないから，上記引用の主張は採用できない。
　
　したがって，当審拒絶理由の（理由２），（１），ア，及び，エでも指摘した点は解消されておらず，また，意見書の内容を加味しても，本願明細書の発明の詳細な説明は，依然として，当業者が上記指摘の記載を含む請求項１に係る発明を実施することができる程度に明確かつ十分に記載されているとはいえず，特許法第３６条第４項第１号で定めるところによる記載がされていないものでもある。
　
　
２．（理由２）の（２）（特許法第３６条第６項第１号，第２号）について
　
（１）本願の請求項１に記載の「トランザクションシステムは，電気的にトランザクション処理モジュールによって処理される，トランザクション若しくはビジネスプロセスをマップする」における「ビジネスプロセスをマップする」について，その技術的な意味が依然として不明である。
　すなわち，上記「マップする」とは，具体的にどのような処理を指すのか不明であり，また，仮に，“何”かを“何”かに“マッピングする”ことを意味するものと解しても，具体的に，“何”を“何”に“マッピングする”すること指すのか，本願明細書の発明の詳細な説明，及び，図面に記載された内容を参酌しても，依然として不明である。
　したがって，当審拒絶理由の（理由２），（２），オでも指摘したように，請求項１に係る発明は依然として明確でなく，本願は，特許法第３６条第６項第２号に規程する要件を満たしていない。
　
（２）本願の請求項１に記載の「前記トランザクション処理モジュールは，コンテキストマネージャによって管理し，初期設定された送り状を作るデータが記憶されるデータコンテナを備えるとともに，」における「初期設定された送り状を作るデータ」について，その技術的な意味が依然として不明であるとともに，本願明細書の発明の詳細な説明及び図面に示されたいずれの構成を指すのか依然として明確でない。
　すなわち，上記「初期設定された送り状を作るデータ」との記載について，「初期設定された送り状を作るデータ」が具体的にどのようなデータを指すのか，本願明細書の発明の詳細な説明，及び，図面に記載された内容を参酌しても，依然として不明である。また，「初期設定された送り状を作るデータ」について，対応する構成が本願明細書の発明の詳細な説明及び図面に認められず，よって，本願明細書の発明の詳細な説明及び図面に示されたいずれの構成を指すのか依然として明確でない。
　したがって，当審拒絶理由の（理由２），（２），カでも指摘したように，本願は，特許法第３６条第６項第１号及び第２号に規程する要件を満たしていない。
　
（３）本願の請求項１に記載の「少なくとも１つのデータモジュールにインターフェースを介して接続され，前記データモジュールは，アプリケーション特有のデータ構造を生データに変形する生データモジュール」における「生データ」及び「生データモジュール」について，その技術的な意味が依然として不明である。
　すなわち，上記「生データ」との記載について，具体的にどのような「データ」を指すのか，本願明細書の発明の詳細な説明，及び，図面に記載された内容を参酌しても，依然として不明である。また，上記「生データ」が不明である以上，「アプリケーション特有のデータ構造」から該「生データ」を生成する「生データモジュール」についても，どのように「生データ」を処理するのか依然として不明である。
　したがって，当審拒絶理由の（理由２），（２），キでも指摘したように，請求項１に係る発明は依然として明確でなく，本願は，特許法第３６条第６項第２号に規程する要件を満たしていない。
　
（４）本願の請求項１に記載の「前記生データの記録は，いくつかの部分から成り，その一方は，構造の点においてスタティックであり，すべての生データの記録に関連している技術的，及び手続き的データが含まれ，１つのタイプのビジネストランザクションから別のものに変わる手続き的データが含まれ」における「記録，はいくつかの部分から成り」，「その一方は」，「構造の点においてスタティックであり」，「技術的データ」，「生データの記録は，」「すべての生データの記録に関連している技術的，及び手続き的データが含まれ」，「生データの記録は，」「１つのタイプのビジネストランザクションから別のものに変わる手続き的データが含まれ」，及び，「１つのタイプのビジネストランザクションから別のものに変わる」について，その技術的な意味が依然として不明である。
　すなわち，上記「記録，はいくつかの部分から成り」における「記録」との記載は，「記録」するという動作を意味するのか，「記録」されたデータを意味するのか，或いは，それ以外の何を意味するのか，本願明細書の発明の詳細な説明，及び，図面に記載された内容を参酌しても，依然として不明である。
　また，上記「その一方は」との記載は，「その」が指すものが“何”であるのか不明であることから，“何”に対して「一方」であるのか，本願明細書の発明の詳細な説明，及び，図面に記載された内容を参酌しても，依然として不明である。
　また，上記「構造の点においてスタティックであり」との記載は，「データの記録」が構造の点についてスタティック（静的）であるとは，どのようなことを意味しているのか全く不明であり，本願明細書の発明の詳細な説明，及び，図面に記載された内容を参酌しても，依然として不明である。
　また，上記「技術的データ」との記載は，どのような点をもって「技術的データ」というのか何ら定義がなされておらず，本願明細書の発明の詳細な説明，及び，図面に記載された内容を参酌しても，依然として不明である。
　また，上記「生データの記録は，」「すべての生データの記録に関連している技術的，及び手続き的データが含まれ」との記載は，上記のようにそもそも「記録」との記載が，「記録」するという動作を意味するのか，「記録」されたデータを意味するのか，或いは，それ以外の何を意味するのか不明であるし，「すべての生データの記録に関連している技術的，及び手続き的データ」とは何を意味しているのか全く不明であり，本願明細書の発明の詳細な説明，及び，図面に記載された内容を参酌しても，依然として不明である。
　また，上記「生データの記録は，」「１つのタイプのビジネストランザクションから別のものに変わる手続き的データが含まれ」との記載は，上記のようにそもそも「記録」との記載が，「記録」するという動作を意味するのか，「記録」されたデータを意味するのか，或いは，それ以外の何を意味するのか，不明であるし，「１つのタイプのビジネストランザクションから別のものに変わる手続き的データ」とは何を意味しているのか全く不明であり，本願明細書の発明の詳細な説明，及び，図面に記載された内容を参酌しても，依然として不明である。
　また，「１つのタイプのビジネストランザクションから別のものに変わる」における「別のもの」について，その技術的な意味が依然として不明であり，本願明細書の発明の詳細な説明，及び，図面に記載された内容を参酌しても，依然として不明である。
　したがって，当審拒絶理由の（理由２），（２），クでも指摘したように，請求項１に係る発明は依然として明確でなく，本願は，特許法第３６条第６項第２号に規程する要件を満たしていない。
　
（５）以上の点について，審判請求人は，当審意見書において，
『　（ｂ）理由２について
　図１に記載されている本願発明に係るトランザクションシステムを示す概略図の構成及びその動作は，本願の発明の詳細な説明の記載から明りょうである。すなわち，本願の発明の詳細な説明の記載は，その発明の属する技術の分野における通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記載されていると考える。』
　と主張しているが，上記主張はそもそも特許法第３６条第４項第１号に関する釈明であり，上記（理由２）の（２）の当審拒絶理由に対し，何ら具体的な釈明を行うものではないから，上記引用の主張は採用できない。
　
　したがって，当審拒絶理由の（理由１），（２），オ〜クでも指摘した点は解消されておらず，本願は，特許法第３６条第６項第１号及び第２号に規程する要件を満たしていない。
　
　
３．（理由１）（特許法第２９条第２項）について
　
（１）本願発明
　上記１．及び２．において検討したとおり，本願の請求項１に係る発明は，特許請求の範囲の記載が明確ではなく，発明の詳細な説明の記載は，当業者がその実施をすることができる程度に明確かつ十分に記載したものではないが，一応，請求項１に係る発明（以下，これを「本願発明」という）は，前記「第２．平成２４年６月７日付け手続補正」における請求項１に記載された字句どおりの，下記の記載のとおりのものとして，以下の特許法第２９条第２項についての検討を行う。
　
「送り状を作るデータを得るための手段を具備し，少なくとも１つのサービスプロバイダのトランザクション情報を処理するためのトランザクションシステムであって，
　前記トランザクションシステムは，電気的にトランザクション処理モジュールによって処理される，トランザクション若しくはビジネスプロセスをマップするための少なくとも１つのトランザクション処理モジュールを備え，
　前記トランザクションは，トランザクションを実行するための前記トランザクション処理モジュールにそれぞれ関連付けられ，プロセスをプロセスの要素である部分的なプロセスに分解することを可能にし，前記各トランザクション処理モジュールのそれぞれがデータを受信及び／又は送信，及び，データを取得，及び／又は，処理するように構成され
　前記トランザクション処理モジュールは，コンテキストマネージャによって管理し，初期設定された送り状を作るデータが記憶されるデータコンテナを備えるとともに，
　少なくとも１つのデータモジュールにインターフェースを介して接続され，前記データモジュールは，アプリケーション特有のデータ構造を生データに変形する生データモジュールであり，
　前記生データの記録は，いくつかの部分から成り，その一方は，構造の点においてスタティックであり，すべての生データの記録に関連している技術的，及び手続き的データが含まれ，１つのタイプのビジネストランザクションから別のものに変わる手続き的データが含まれ，
　前記コンテキストマネージャは，前記トランザクション処理モジュールのための中央制御方法として，または前記トランザクション処理モジュールのための中央サービスプロバイダとして形成され，前記トランザクション処理モジュールを始動，及び／又は，終了できるように構成され，
　前記データコンテナは，トランザクションプロセスで生成されたデータオブジェクトを記憶するためのものであり，システムクラッシュの後に前記データオブジェクトを修復することができるデータの可変値そして規定されたプロパティを含んでいることを特徴とする，トランザクションシステム。」
　
（２）引用文献の記載事項及び引用発明
（２−１）引用文献１
　本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となり，平成２６年１月２１日付けの当審拒絶理由において引用された，特開２００４−２３４２０３号公報（以下，「引用文献１」という。）には，関連する図面と共に，以下の記載がなされている。
　（当審注：下線は参考のため，当審で附与したものである。）
　
Ａ．「【０００１】
【発明の属する技術分野】
本発明はコンピュータシステムの分散トランザクションシステムに係り，特に，ＥＪＢ（登録商標）コンテナ異常終了時に仕掛かり中トランザクションを短時間で決着するシステム
　
Ｂ．「【０００７】
本発明の目的は，Ｊａｖａ（登録商標）（プログラミング言語の一種）の技術を使用した
分散トランザクションシステムにおいて，アプリケーションプログラムが動作中（トランザクション処理中）に
【０００８】
【課題を解決するための手段】
前記課題を解決するために，本発明は主として次のような構成を採用する。
アプリケーションプログラム，トランザクションマネージャ，リソースマネージャ，他のＥＪＢ（登録商標）コンテナ情報保持部，を有する複数のＥＪＢ（登録商標）コンテナと，各ＥＪＢ（登録商標）コンテナの前記トランザクションマネージャに接続されたトランザクション集中管理部と，各ＥＪＢ（登録商標）コンテナのリソースマネージャに接続されたリソースと，を備えた分散トランザクションシステムであって，
一のＥＪＢ（登録商標）コンテナ上で動作するアプリケーションプログラムがアクセス対象としているリソースの情報を前記一のＥＪＢ（登録商標）コンテナから前記トランザクション集中管理部に通知し，
前記トランザクション集中管理部が前記一のＥＪＢ（登録商標）コンテナによるトランザクション実行中の異常終了を検知した場合に，前記トランザクション集中管理部を経由して通知された前記リソースの情報を使用して他のＥＪＢ（登録商標）コンテナが仕掛かり中のアクセスの決着処理を前記リソースに対して要求する
【０００９】
本発明は，この構成を採用することにより，ＥＪＢ（登録商標）コンテナがトランザクション実行中に異常終了した場合に，他の起動済ＥＪＢ（登録商標）コンテナが，仕掛かり中のアクセスの決着処理をリソースに対して要求するので，ＥＪＢ（登録商標）コンテナ起動処理に要する時間分だけ回復時間を短縮することができる。」
　
Ｃ．「【００１０】
【発明の実施の形態】
本発明の実施形態に係る分散トランザクションシステムについて，図面を参照しながら以下説明する。図１は，本発明の実施形態に係るコンピュータシステムの分散トランザクションシステムにおける全体構成を示す図である。
【００１１】
図１において，分散トランザクションシステムは，ＥＪＢ（登録商標）コンテナ（Ｅｎｔｅｒｐｒｉｓｅ　Ｊａｖａ（登録商標）Ｂｅａｎｓ（ＴＭ）ｃｏｎｔａｉｎｅｒ）１０１，１１１と，ＤＢＭＳ（Ｄａｔａ　Ｂａｓｅ　Ｍａｎａｇｅｍｅｎｔ　Ｓｙｓｔｅｍ）１２０と，トランザクション集中管理１３０と，から構成されており，ＥＪＢ（登録商標）コンテナ１０１上には，アプリケーションプログラム１０２，トランザクションマネージャ１０３，リソースマネージャ１０４，他ＥＪＢ（登録商標）コンテナ情報１０５が存在する。ここで，他ＥＪＢ（登録商標）コンテナ情報１０５は，トランザクションマネージャ１０３が他のＥＪＢ（登録商標）コンテナ１１１がアクセス対象としているリソースを記憶するためのものである。同様の構成のＥＪＢ（登録商標）コンテナは，他にも複数個存在し，その一つがＥＪＢ（登録商標）コンテナ１１１である。
【００１２】
トランザクション集中管理１３０は，各ＥＪＢ（登録商標）コンテナ上に存在するトランザクションマネージャ１０３，１１３を制御するためのものであり
【００１３】
図１に示す構成例は，二つのＥＪＢ（登録商標）コンテナが，お互いの情報を持ち合う形になっているが，一つ又は複数個のＥＪＢ（登録商標）コンテナが，複数個のＥＪＢ（登録商標）コンテナの情報を全て記憶する形でもよい。また，他ＥＪＢ（登録商標）コンテナの情報を記憶するＥＪＢ（登録商標）コンテナ情報１０５，１１５は，アプリケーションプログラムを実行させずに決着処理専用として用意しても良い。」
　
Ｄ．「【００１４】
図２は，本発明の実施形態に係る分散トランザクションシステムにおいて，ＥＪＢ（登録商標）コンテナ１０１，１１１上でアプリケーションプログラム１０２，１１２を動作させる際に，トランザクションマネージャ１０３，１１３が行う処理を示すフローである。
【００１５】
ステップ２０１にて，アプリケーションプログラムをデプロイ（配備）し，ステップ２０２で，当該アプリケーションプログラムがアクセス対象としているリソースの情報をトランザクション集中管理１３０に連絡する。ステップ２０３でイベントの発生を待ち，ステップ２０４で発生したイベントの内容を判定して，
イベントがアプリケーションプログラムの起動要求であった場合，ステップ２０５でアプリケーションプログラムを起動し，アプリケーションプログラムを実行するとともに，ステップ２０３に戻って，新たなイベントの発生を待つ。
　
　以下，引用文献１の記載事項について検討する。
　
　ア．上記Ａ．の「本発明はコンピュータシステムの分散トランザクションシステムに係り，特に，ＥＪＢ（登録商標）コンテナ異常終了時に仕掛かり中トランザクションを短時間で決着するシステム・・・」との記載，及び，上記Ｂ．における段落【０００８】の記載から，
　引用文献１は，
“ＥＪＢコンテナ異常終了時に仕掛かり中トランザクションを短時間で決着する分散トランザクションシステムであり，
　アプリケーションプログラム，トランザクションマネージャ，リソースマネージャ，他のＥＪＢコンテナ情報保持部，を有する複数のＥＪＢコンテナと，各ＥＪＢコンテナの前記トランザクションマネージャに接続されたトランザクション集中管理部と，各ＥＪＢコンテナの前記リソースマネージャに接続されたリソースと，を備えた分散トランザクションシステムであって，
　一のＥＪＢコンテナ上で動作するアプリケーションプログラムがアクセス対象としているリソースの情報を前記一のＥＪＢコンテナから前記トランザクション集中管理部に通知し，
　前記トランザクション集中管理部が前記一のＥＪＢコンテナによるトランザクション実行中の異常終了を検知した場合に，前記トランザクション集中管理部を経由して通知された前記リソースの情報を使用して他のＥＪＢコンテナが仕掛かり中のアクセスの決着処理を前記リソースに対して要求する，システム”について説明するものであることが理解できる。
　
　イ．上記Ｂ．の「分散トランザクションシステムにおいて，アプリケーションプログラムが動作中（トランザクション処理中）に」との記載，上記Ｄ．の「図２は，本発明の実施形態に係る分散トランザクションシステムにおいて，ＥＪＢ（登録商標）コンテナ１０１，１１１上でアプリケーションプログラム１０２，１１２を動作させる際に，トランザクションマネージャ１０３，１１３が行う処理を示すフローである。」，及び，「ステップ２０１にて，アプリケーションプログラムをデプロイ（配備）し，ステップ２０２で，当該アプリケーションプログラムがアクセス対象としているリソースの情報をトランザクション集中管理１３０に連絡する。ステップ２０３でイベントの発生を待ち，ステップ２０４で発生したイベントの内容を判定して，・・・（中略）・・・イベントがアプリケーションプログラムの起動要求であった場合，ステップ２０５でアプリケーションプログラムを起動し，アプリケーションプログラムを実行するとともに，ステップ２０３に戻って，新たなイベントの発生を待つ。」との記載から，
　引用文献１に記載の「システム」において，
　前記“ＥＪＢコンテナにおけるトランザクションマネージャは，トランザクション処理に係るアプリケーションプログラムを動作させる際に，アプリケーションプログラムをデプロイし，アクセス対象としているリソースの情報をトランザクション集中管理部に通知し，発生したイベントの内容を判定してアプリケーションプログラムの起動要求であった場合，アプリケーションプログラムを起動して実行する”ことが記載されているといえる。
　
　ウ．上記Ｃ．の「トランザクション集中管理１３０は，各ＥＪＢ（登録商標）コンテナ上に存在するトランザクションマネージャ１０３，１１３を制御するためのものであり」との記載から，
　引用文献１に記載の「システム」において，
　前記“トランザクション集中管理部は，各ＥＪＢコンテナ上に存在する前記トランザクションマネージャを制御するものであ”ることが記載されているといえる。
　
　エ．上記ア．の検討結果における“一のＥＪＢコンテナ上で動作するアプリケーションプログラムがアクセス対象としているリソースの情報を前記一のＥＪＢコンテナから前記トランザクション集中管理部に通知し”に関し，
　上記イ．の検討結果によれば，「アプリケーションプログラム」が「アクセス対象としているリソースの情報をトランザクション集中管理部に通知」するのは，「ＥＪＢコンテナにおけるトランザクションマネージャ」であることから，
　上記“一のＥＪＢコンテナ上で動作するアプリケーションプログラムがアクセス対象としているリソースの情報を前記一のＥＪＢコンテナから前記トランザクション集中管理部に通知”することは，前記“ＥＪＢコンテナにおける前記トランザクションマネージャによって”行われることが読み取れる。
　
　以上，ア．ないしエ．で指摘した事項を踏まえると，引用文献１には，次の発明（以下，「引用発明」という。）が記載されているものと認められる。
　
「ＥＪＢコンテナ異常終了時に仕掛かり中トランザクションを短時間で決着する分散トランザクションシステムであり，
　アプリケーションプログラム，トランザクションマネージャ，リソースマネージャ，他のＥＪＢコンテナ情報保持部，を有する複数のＥＪＢコンテナと，各ＥＪＢコンテナの前記トランザクションマネージャに接続されたトランザクション集中管理部と，各ＥＪＢコンテナの前記リソースマネージャに接続されたリソースと，を備えた分散トランザクションシステムであって，
　前記ＥＪＢコンテナにおける前記トランザクションマネージャは，トランザクション処理に係るアプリケーションプログラムを動作させる際に，アプリケーションプログラムをデプロイし，アクセス対象としているリソースの情報を前記トランザクション集中管理部に通知し，発生したイベントの内容を判定してアプリケーションプログラムの起動要求であった場合に，アプリケーションプログラムを起動して実行するものであり，
　前記トランザクション集中管理部は，各ＥＪＢコンテナ上に存在する前記トランザクションマネージャを制御するものであり，
　前記ＥＪＢコンテナにおける前記トランザクションマネージャによって，一のＥＪＢコンテナ上で動作するアプリケーションプログラムがアクセス対象としているリソースの情報を前記一のＥＪＢコンテナから前記トランザクション集中管理部に通知し，
　前記トランザクション集中管理部が前記一のＥＪＢコンテナによるトランザクション実行中の異常終了を検知した場合に，前記トランザクション集中管理部を経由して通知された前記リソースの情報を使用して他のＥＪＢコンテナが仕掛かり中のアクセスの決着処理を前記リソースに対して要求する，システム。」 
　
（２−２）引用文献４
　本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となり，平成２６年１月２１日付けの当審拒絶理由において引用された，特表２００３−５２９９５２号公報（以下，「引用文献４」という。）には，関連する図面と共に，以下の記載がなされている。
　（当審注：下線は参考のため，当審で附与したものである。）
　
Ｅ．「【０００５】
　（発明の開示）
　本発明によれば，ベアラにインタフェースするためのベアラアダプテーション層，及び起点サーバにインタフェースするためのクライアントを含むスタックを含む通信用ゲートウェイであって，
　前記スタック上のユーザとして機能し，かつ外部エンティティに対するインタフェース手段をサポートして補助的サービスを提供する
コンテキストマネージャ
　【０００６】
　コンテキストマネージャが，スタック上のユーザであり，かつインタフェース手段をサポートするための手段を有するため，その構造のプラットフォームとして機能するので，これは非常に柔軟で汎用性のある構成である。」
　
Ｆ．「【００５１】
　図１を参照すると，ＷＡＰゲートウェイ１が移動体オペレータのドメイン２において接続されている。このゲートウェイは，ハンドセット（クライアント）４のための移動体オペレータのネットワーク３とのベアラリンク（bearer link）を有する。ゲートウェイ１は，ＨＴＴＰリンクによって無線電話アプリケーション（ＷＴＡ）サーバ５にも接続されている。ドメイン２は，無線インタフェースによって接続された他のアプリケーションプラットフォーム６も備えている。ゲートウェイ１は，ＨＴＴＰリンクによって起点サーバ１０にも接続されている。これは典型的な配置であるが，ネットワーク３へのリンク及び起点サーバへのリンクのみが必要不可欠なものである。
　【００５２】
　ゲートウェイ１によって，ＷＡＰ機能を有するハンドセット（即ちブラウザ及びＷＡＰスタックを備えたもの）が，移動体オペレータのドメイン２及び他の場所（例えば
サービスプロバイダ
　
Ｇ．「【００５６】
　図２を参照すると，ゲートウェイ１が，最下層から順番に，
　無線データグラムプロトコル（ＷＤＰ）層２１，
　無線トランスポート層セキュリティ（ＷＴＬＳ）層２２，
　
無線トランザクションプロトコル（ＷＴＰ）
　無線セッションプロトコル（ＷＳＰ）層２４
を有する。
　【００５７】
　
コンテキストマネージャ
・軽量ディレクトリアクセスプロトコル（lightweight directory access protocol）（ＬＤＡＰ）クライアント２６，
・プッシュＡＰＩ（push API）２７，
・コンパイラ／エンコーダ（Ｃ／Ｅ）２８，
・ＨＴＴＰクライアント２９，及び
・ＲＡＤＩＵＳアカウンティングサーバ３０
である。
　【００５８】
　
コンテキストマネージャ
　【００５９】
　ゲートウェイ１は，ゲートウェイにおける主要な構成要素の大部分によりアクセスされる内部データベース３２も含む。
　【００６０】
　加えて，ゲートウェイ１は，イベントログ３６及び課金ログ（billing log）３７を維持し，かつスタック２０の全ての層及びコンテキストマネージャ２５と相互作用するイベントマネージャ（event manager）３５も含む。このイベントマネージャ３５は，セッションマネージャ（session manager）４５及びマネジメントコア（management core）４６を含むマネジメントエンティティ４０に接続される。そのマネジメントエンティティに対して，マネジメントＧＵＩ４７が設けられている。」
　
（２−３）引用文献５
　本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となり，平成２６年１月２１日付けの当審拒絶理由において引用された，特開２００３−１５７２４２号公報（以下，「引用文献５」という。）には，関連する図面と共に，以下の記載がなされている。
　（当審注：下線は参考のため，当審で附与したものである。）
　
Ｈ．「【０００１】
【発明の属する技術分野】本発明は，例えばＪａｖａ（登録商標）言語に従うアプリケーションサーバを利用した
分散処理システム
【０００２】
【従来の技術】分散処理システム構築のためのプラットフォーム（基盤）として，アプリケーションサーバと呼ばれるミドルウェアの利用が多くなってきている。現在，アプリケーションサーバの標準仕様としては，Ｊ２ＥＥ（Ｊａｖａ２　Ｐｌａｔｆｏｒｍ，Ｅｎｔｅｒｐｒｉｓｅ　Ｅｄｉｔｉｏｎ）が業界標準の地位を占めている。
【０００３】Ｊ２ＥＥ準拠のアプリケーションサーバ上で動作するアプリケーションシステムは，Ｊａｖａ言語を使用して開発され，ＥＪＢ（Ｅｎｔｅｒｐｒｉｓｅ　Ｊａｖａ　Ｂｅａｎｓ），Ｓｅｒｖｌｅｔ，ＪＳＰ（Ｊａｖａ　Ｓｅｒｖｅｒ　Ｐａｇｅｓ）といったプログラミングモデルに従ったコンポーネント群から構成される形態を取る。
【０００４】しかし，実際のシステムでは，Ｊａｖａ言語以外の言語で開発したコンポーネントの利用が必要であったり，既存のサブシステムを統合して一つのシステムに仕立て上げることが必要であったりするため，システム全体をＪａｖａ言語のみで構築することは困難な場合も多い。
【０００５】このような場合，Ｊａｖａ言語以外の言語で構築するコンポーネントは，分散オブジェクトのための標準規格である
ＣＯＲＢＡ
　
Ｊ．「【００２７】本実施形態の分散処理システムは，図１に示すように，アプリケーションサーバ１０１と，このアプリケーションサーバ１０１に図示しないネットワーク等を介して連携されるＣＯＲＢＡサーバ１０２とを含み，この連携に係る処理，設定，
データの型変換を，連携用アダプタ１０４を介して実行する
【００２８】図１は，アプリケーションサーバ１０１上で動作しているＥＪＢ１０３が，ＣＯＲＢＡサーバ１０２上で動作しているＣＯＲＢＡオブジェクト１０８にアクセスするために，連携用アダプタ１０４を利用している状態を示している。」
　
Ｋ．「【００６５】　本実施形態においてはアプリケーションサーバ１０１とＣＯＲＢＡサーバ１０２との連携に係る処理，設定，
データの型変換を連携用アダプタ１０４を介して実行することで，連携用アダプタ１０４のメソッド内で必要に応じたデータ変換が可能となる
　
（２−４）引用文献６
　本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となり，平成２６年１月２１日付けの当審拒絶理由において引用された，特開平９−３１１８９９号公報（以下，「引用文献６」という。）には，関連する図面と共に，以下の記載がなされている。
　（当審注：下線は参考のため，当審で附与したものである。）
　
Ｌ．「【０００５】
【発明が解決しようとする課題】上記従来の技術は，給与計算に使用する各種のデータの入力作業を分散化させ，平均化させるのに有効な技術である。すなわちマスタファイルを更新する作業が一時期に集中することを防ぎ，更新作業を複数人で分担することも可能となる。しかしながらデータ入力作業そのものは人手で行うことから，入力ミスは発生する。この場合にはデータ修正作業を行わなければならない。特に給与計算の
トランザクション実行
【０００６】本発明の目的は，給与に関係するデータの入力ミスが発生したときのデータ修正に要する担当者の負担を軽減することにある。
【０００７】
【課題を解決するための手段】本発明は，ネットワークを介してクライアントとサーバとが接続され，クライアントから入力したデータに基づいて給与に関するデータを格納するサーバ側のマスタファイルを更新するシステムのデータ入力方法であり，サーバではクライアントから受信した入力データのチェックを行い，データが妥当であればマスタファイルを更新してからクライアントへ正常終了のメッセージを送信し，正常終了のメッセージを受信したときクライアント側で入力データの変更履歴を採取し，マスタ更新済のレコードをデータ修正する場合には，データ変更履歴を基にしてデータ修正の対象とする履歴レコードを選択し，データ修正された入力データについてマスタファイルを再度更新し，再度入力データの変更履歴を採取する給与データの入力方法を特徴とする。」
　
Ｍ．「【００１３】図４は，変更データ履歴ファイル１１のデータ形式の例を示す図である。図中の１行が１レコードであり，マスタファイル中の１レコードに対する１回の更新処理によってレコードが１件ずつ追加される。
４０はすべてのマスタファイルについて共通のデータ形式となる固定部，４１はマスタファイルによってデータ形式が可変となる可変部である。
　
（３）本願発明と引用発明との対比
　本願発明と引用発明とを対比する。
　
（３−１）引用発明における「トランザクション」を「決着」するとは「決着処理」することであり，「トランザクション」を「処理」することに包含されるものであって，本願発明の「トランザクション情報を処理する」ことに相当するといえる。
　してみると，引用発明である「ＥＪＢコンテナ異常終了時に仕掛かり中トランザクションを短時間で決着する分散トランザクションシステム」と，本願発明である「送り状を作るデータを得るための手段を具備し，少なくとも１つのサービスプロバイダのトランザクション情報を処理するためのトランザクションシステム」とは，後記する点で相違するものの，“少なくとも１つのトランザクション情報を処理するためのトランザクションシステム”である点で共通するといえる。
　
（３−２）引用発明の「トランザクションマネージャ」は，本願発明の「トランザクション処理モジュール」に対応するところ，引用発明の「トランザクションマネージャ」は，「アプリケーションプログラムを動作」させて「トランザクション処理」を行うものであり，また，該「トランザクション」を業務システムにおける処理の対象として対応付けることは，当該技術分野における技術常識であり，また，該「トランザクションマネージャ」を「モジュール」として構成し得ることも，同様に技術常識であったといえる。一方，本願発明の「トランザクションシステムは，電気的にトランザクション処理モジュールによって処理される，トランザクション若しくはビジネスプロセスをマップする」における「マップする」の技術的な意味は，上記２．，（１）で述べたように必ずしも明確なものではないものの，上記引用発明に係る「トランザクションマネージャ」が，業務システムにおける処理の対象として「トランザクション」を対応付けることを包含するものと解釈することもできるから，この点において両者は実質的に相違しない。
　してみると，引用発明の「分散トランザクションシステム」が「ＥＪＢコンテナ」の構成として「トランザクションマネージャ」を備えることは，本願発明の「前記トランザクションシステムは，電気的にトランザクション処理モジュールによって処理される，トランザクション若しくはビジネスプロセスをマップするための少なくとも１つのトランザクション処理モジュールを備え」ることに相当するといえる。
　
（３−３）引用発明の「トランザクションマネージャ」が，「アプリケーションプログラムを動作」させて「トランザクション処理」を行い，「リソースの情報を前記一のＥＪＢコンテナから前記トランザクション集中管理部に通知」することと，本願発明の「前記トランザクションは，トランザクションを実行するための前記トランザクション処理モジュールにそれぞれ関連付けられ，プロセスをプロセスの要素である部分的なプロセスに分解することを可能にし，前記各トランザクション処理モジュールのそれぞれがデータを受信及び／又は送信，及び，データを取得，及び／又は，処理するように構成され」ることとは，後記する点で相違するものの，“前記トランザクションは，トランザクションを実行するための前記トランザクション処理モジュールにそれぞれ関連付けられ，前記各トランザクション処理モジュールのそれぞれがデータを受信及び／又は送信，及び，データを取得，及び／又は，処理するように構成され”ることである点で共通するといえる。
　
（３−４）引用発明の「トランザクション集中管理部」は，本願発明の「コンテキストマネージャ」に対応するところ，引用発明の「トランザクションマネージャ」は，「トランザクション集中管理部」によって「制御」されることから「管理」されるものといえ，また，該「トランザクションマネージャ」は，「リソースの情報」を「前記トランザクション集中管理部に通知」し，さらに，「アプリケーションプログラムを動作」させて「トランザクション処理」を行って用いることから，該「リソースの情報」及び「トランザクション処理」結果等のデータを記憶するための，何らかの記憶手段を有することは明らかであり，該何らかの記憶手段が，本願発明における，「トランザクション処理モジュール」の「データコンテナ」に相当する。
　してみると，引用発明の「トランザクションマネージャ」が，「トランザクション集中管理部」により「制御」され，「リソースの情報」を「前記トランザクション集中管理部に通知」し，さらに，「アプリケーションプログラムを動作」させて「トランザクション処理」を行うことと，本願発明の「前記トランザクション処理モジュールは，コンテキストマネージャによって管理し，初期設定された送り状を作るデータが記憶されるデータコンテナを備える」こととは，後記する点で相違するものの，“前記トランザクション処理モジュールは，データが記憶されるデータコンテナを備える”ことである点で共通するといえる。
　
（３−５）上記（３−４）における，引用発明の「トランザクションマネージャ」が有する何らかの記憶手段は，「リソースの情報」及び「トランザクション処理」結果等のデータを記憶するものといえるが，該「トランザクション処理」結果としてのデータが，プロセスで生成されたデータオブジェクトを包含することは，当該技術分野における技術常識であった。
　してみると，引用発明の「トランザクションマネージャ」が，「リソースの情報」を「前記トランザクション集中管理部に通知」し，さらに，「アプリケーションプログラムを動作」させて「トランザクション処理」を行うことと，本願発明の「前記データコンテナは，トランザクションプロセスで生成されたデータオブジェクトを記憶するためのものであり，システムクラッシュの後に前記データオブジェクトを修復することができるデータの可変値そして規定されたプロパティを含んでいる」こととは，後記する点で相違するものの，“前記データコンテナは，トランザクションプロセスで生成されたデータオブジェクトを記憶するためのものであ”る点で共通するといえる。
　
　以上の対比から，本願発明と引用発明とは，以下の点で一致し，また，以下の点で相違する。
　
（一致点）
　少なくとも１つのトランザクション情報を処理するためのトランザクションシステムであって，
　前記前記トランザクションシステムは，電気的にトランザクション処理モジュールによって処理される，トランザクション若しくはビジネスプロセスをマップするための少なくとも１つのトランザクション処理モジュールを備え，
　前記トランザクションは，トランザクションを実行するための前記トランザクション処理モジュールにそれぞれ関連付けられ，前記各トランザクション処理モジュールのそれぞれがデータを受信及び／又は送信，及び，データを取得，及び／又は，処理するように構成され
　前記トランザクション処理モジュールは，データが記憶されるデータコンテナを備えるとともに，
　前記データコンテナは，トランザクションプロセスで生成されたデータオブジェクトを記憶するためのものであることを特徴とする，トランザクションシステム。
　
（相違点１）
　本願発明の「トランザクションシステム」は，「送り状を作るデータを得るための手段」を備えるとともに，「初期設定された送り状を作るデータ」をデータコンテナに記憶するものであるのに対して，引用発明の「分散トランザクションシステム」には，送り状を作るデータを得るための手段を備えておらず，初期設定された送り状を作るデータも記憶されていない点。
　
（相違点２）
　システムが処理するトランザクションに関し，
　本願発明は，「サービスプロバイダ」のトランザクション情報であるのに対して，引用発明は，どのようなトランザクションであるかについて言及されていない点。
　
（相違点３）
　トランザクションに関し，
　本願発明は，「プロセスをプロセスの要素である部分的なプロセスに分解することを可能に」するものであるのに対して，引用発明は，そのような特定がされていない点。
　
（相違点４）
　本願発明は，「コンテキストマネージャ」によってトランザクション処理モジュールを管理し，「前記コンテキストマネージャは，前記トランザクション処理モジュールのための中央制御方法として，または前記トランザクション処理モジュールのための中央サービスプロバイダとして形成され，前記トランザクション処理モジュールを始動，及び／又は，終了できるように構成され」ているのに対して，引用発明は，「トランザクション集中管理部」によってトランザクションマネージャを制御し管理している点。
　
（相違点５）
　本願発明は，「アプリケーション特有のデータ構造を生データに変形する生データモジュール」を備えるとともに，「前記生データの記録は，いくつかの部分から成り，その一方は，構造の点においてスタティックであり，すべての生データの記録に関連している技術的，及び手続き的データが含まれ，１つのタイプのビジネストランザクションから別のものに変わる手続き的データが含まれ」ているのに対して，引用発明は，そのように構成されていない点。
　
（相違点６）
　トランザクションプロセスで生成されたデータオブジェクトを記憶する，データコンテナに関し，
　本願発明は，「システムクラッシュの後に前記データオブジェクトを修復することができるデータの可変値そして規定されたプロパティを含んでいる」のに対して，引用発明は，そのように構成されていない点。
　
（４）相違点についての判断
　
　上記相違点１ないし相違点６について検討する。
　
（４−１）相違点１について
　
　一般に，ビジネストランザクションシステムにおいて，送り状作成のための処理を行うことは，例示するまでもなく本願優先日前には周知の事項であったといえ，また，該送り状の作成を，最初に設定される何らかの設定データをもとに行うことは，当該技術分野における常とう手段である。
　一方，本願発明の「前記トランザクション処理モジュールは，コンテキストマネージャによって管理し，初期設定された送り状を作るデータが記憶されるデータコンテナを備えるとともに，」における「初期設定された送り状を作るデータ」の技術的な意味は，上記２．，（２）で述べたように必ずしも明確なものではないものの，上記周知事項及び常とう手段を採用することで構成される，送り状の作成処理を最初に設定される何らかの設定データをもとに行うことを包含するものと解釈することもできる。
　そして，引用発明と，上記周知事項及び常とう手段とが，同様の技術分野に属することは明らかであるから，引用発明において，上記周知事項及び常とう手段を適用することで，「送り状を作るデータを得るための手段」を備えるとともに，「初期設定された送り状を作るデータ」をデータコンテナに記憶するようにすること，すなわち，相違点１に係る構成とすることは，当業者が容易に想到し得たことである。
　よって，相違点１は，格別のものではない。
　
（４−２）相違点２について
　
　トランザクション処理システムにおいて，サービスプロバイダに係るトランザクションを処理対象とすることは，例えば，上記引用文献４（上記Ｆ．及びＧ．の記載照）に記載されているように，本願優先日前には周知の技術であった。そして，引用発明と上記周知技術とが同様の技術分野に属することは明らかであるから，引用発明における処理対象を，「サービスプロバイダ」のトランザクション情報とすること，すなわち，相違点２に係る構成とすることは，当業者が容易に想到し得たことである。
　よって，相違点２は，格別のものではない。　
　
（４−３）相違点３について
　
　プロセスを，部分的なプロセスにさらに分解可能なものとすることは，情報処理技術の分野における技術常識といえる事項であり，トランザクションに係るプロセスについて該技術常識の如く構成すること，すなわち，相違点３に係る構成とすることは，当業者が適宜なし得る事項である。
　よって，相違点３は，格別のものではない。
　
（４−４）相違点４について
　
　引用文献４には，トランザクションシステムの動作をコンテキストマネージャを用いて制御することが記載されている（上記Ｅ．の記載）。
　また，引用発明の「トランザクション集中管理部」は，「各ＥＪＢコンテナ上に存在する前記トランザクションマネージャを制御する」ものであるところ，該制御の下，「トランザクションマネージャ」が動作を始め，または終了しているから，「トランザクションマネージャ」の開始または終了を制御していることに他ならない。
　そして，引用発明と引用文献４に記載の事項とが同様の技術分野に属することは明らかであるから，引用発明の「トランザクション集中管理部」に対し，上記引用文献４に記載の事項を適用して，「コンテキストマネージャ」によってトランザクション処理モジュールを管理し，「前記コンテキストマネージャは，前記トランザクション処理モジュールのための中央制御方法として，または前記トランザクション処理モジュールのための中央サービスプロバイダとして形成され，前記トランザクション処理モジュールを始動，及び／又は，終了できるように構成され」るようにすること，すなわち，相違点４に係る構成とすることは，当業者が容易に想到し得たことである。
　よって，相違点４は，格別のものではない。
　
（４−５）相違点５について
　
　トランザクション処理システムにおいて，外部から入力されるデータを，処理可能な形式のデータに変換すること（例えば，上記引用文献５の，上記Ｈ．〜Ｋ．の記載）や，処理対象のデータを固定部分と可変部分に分けて処理すること（例えば，上記引用文献６のＬ．及びＭ．の記載）は，いずれも，本願優先日前には周知の技術であった。
　一方，本願発明の「少なくとも１つのデータモジュールにインターフェースを介して接続され，前記データモジュールは，アプリケーション特有のデータ構造を生データに変形する生データモジュール」における「生データ」及び「生データモジュール」の技術的な意味，並びに，本願発明の「前記生データの記録は，いくつかの部分から成り，その一方は，構造の点においてスタティックであり，すべての生データの記録に関連している技術的，及び手続き的データが含まれ，１つのタイプのビジネストランザクションから別のものに変わる手続き的データが含まれ」における「記録，はいくつかの部分から成り」，「その一方は」，「構造の点においてスタティックであり」，「技術的データ」，「生データの記録は，」「すべての生データの記録に関連している技術的，及び手続き的データが含まれ」，「生データの記録は，」「１つのタイプのビジネストランザクションから別のものに変わる手続き的データが含まれ」，及び，「１つのタイプのビジネストランザクションから別のものに変わる」の技術的な意味は，上記２．，（３），及び，（４）で述べたように必ずしも明確なものではないものの，上記周知技術等を採用することで構成される，処理可能な形式のデータを，固定部分と可変部分に分けて構成する態様，及び，該データを生成するための所定の手段を周知のモジュールとして構成する態様を包含するものと解釈することもできる。
　そして，引用発明と，上記周知技術とが，同様の技術分野に属することは明らかであるから，引用発明において，上記周知技術を適用することで，「アプリケーション特有のデータ構造を生データに変形する生データモジュール」を備えるとともに，「前記生データの記録は，いくつかの部分から成り，その一方は，構造の点においてスタティックであり，すべての生データの記録に関連している技術的，及び手続き的データが含まれ，１つのタイプのビジネストランザクションから別のものに変わる手続き的データが含まれ」るようにすること，すなわち，相違点５に係る構成とすることは，当業者が容易に想到し得たことである。
　よって，相違点５は，格別のものではない。
　
（４−６）相違点６について
　
　データオブジェクトが，データ及びプロパティを有することは技術常識であり，また，当該データ及びプロパティを記憶しておくことで，システムクラッシュにより破損したデータオブジェクトを修復可能とすることも，例示するまでもなく周知の技術であった。そして，引用発明と上記周知技術等とが同様の技術分野に属することは明らかであるから，引用発明において記憶するデータに対し，「システムクラッシュの後に前記データオブジェクトを修復することができるデータの可変値そして規定されたプロパティを含んでいる」よう構成すること，すなわち，相違点６に係る構成とすることは，当業者が容易に想到し得たことである。
　よって，相違点６は，格別のものではない。
　
　上記で検討したごとく，相違点１ないし６はいずれも格別のものではなく，そして，本願発明の構成によってもたらされる効果も，当業者であれば容易に予測できる程度のものであって，格別なものとは認められない。
　よって，本願発明は，引用発明，引用文献４に記載の事項，及び，周知の技術に基づいて当業者が容易に発明をすることができたものである。
　
　
第６．むすび
　したがって，本願は，特許法第３６条第４項第１号及び第６項第１号，第２号に規定する要件を満たしていない。
　更に，本願の請求項１に係る発明は，本願の特許出願前に日本国内又は外国において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて，当業者が容易に発明をすることができたものであるので，特許法第２９条第２項の規定により特許を受けることができない。
　
　よって，結論のとおり審決する。