• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 特36条4項詳細な説明の記載不備 特許、登録しない(前置又は当審拒絶理由) G06F
審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 特許、登録しない(前置又は当審拒絶理由) G06F
審判 査定不服 2項進歩性 特許、登録しない(前置又は当審拒絶理由) G06F
管理番号 1295292
審判番号 不服2012-10627  
総通号数 182 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2015-02-27 
種別 拒絶査定不服の審決 
審判請求日 2012-06-07 
確定日 2014-12-17 
事件の表示 特願2007-554441「トランザクション情報を処理するためのトランザクションシステム、及びトランザクションを遂行する方法」拒絶査定不服審判事件〔平成18年 8月17日国際公開、WO2006/084501、平成20年 8月 7日国内公表、特表2008-530665〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 第1.手続の経緯

本願は,2005年12月28日(パリ条約による優先権主張外国庁受理2005年2月9日 欧州特許庁)を国際出願日とする出願であって,
平成19年8月8日付けで特許法第184条の5第1項の規定による書面が提出され,
平成19年10月4日付けで特許法第184条の4第1項の規定による明細書,請求の範囲,及び,図面(図面の中の説明に限る)の日本語による翻訳文が提出され,
平成20年11月11日付けで審査請求がなされ,
平成23年8月23日付けで審査官により拒絶理由通知がなされたが,これに対する応答はなく,
平成24年2月3日付けで審査官により拒絶査定がなされ,
これに対して平成24年6月7日付けで審判請求がされるとともに,同日付けで手続補正がなされ
平成24年8月29日付けで特許法第164条第3項に定める報告(前置報告)がなされ,
平成24年11月15日付けで当該報告に対する意見を求める旨の審尋がなされ,
平成25年2月18日付けでこれに対する回答がなされ,
平成26年1月21日付けで当審により拒絶理由が通知され,
これに対して平成26年5月27日付けで意見書が提出されたものである。


第2.平成24年6月7日付け手続補正

上記平成24年6月7日付けの手続補正は,特許請求の範囲を下記本願特許請求の範囲に補正するものである。

「 【請求項1】
送り状を作るデータを得るための手段を具備し,少なくとも1つのサービスプロバイダのトランザクション情報を処理するためのトランザクションシステムであって,
前記トランザクションシステムは,電気的にトランザクション処理モジュールによって処理される,トランザクション若しくはビジネスプロセスをマップするための少なくとも1つのトランザクション処理モジュールを備え,
前記トランザクションは,トランザクションを実行するための前記トランザクション処理モジュールにそれぞれ関連付けられ,プロセスをプロセスの要素である部分的なプロセスに分解することを可能にし,前記各トランザクション処理モジュールのそれぞれがデータを受信及び/又は送信,及び,データを取得,及び/又は,処理するように構成され
前記トランザクション処理モジュールは,コンテキストマネージャによって管理し,初期設定された送り状を作るデータが記憶されるデータコンテナを備えるとともに,
少なくとも1つのデータモジュールにインターフェースを介して接続され,前記データモジュールは,アプリケーション特有のデータ構造を生データに変形する生データモジュールであり,
前記生データの記録は,いくつかの部分から成り,その一方は,構造の点においてスタティックであり,すべての生データの記録に関連している技術的,及び手続き的データが含まれ,1つのタイプのビジネストランザクションから別のものに変わる手続き的データが含まれ,
前記コンテキストマネージャは,前記トランザクション処理モジュールのための中央制御方法として,または前記トランザクション処理モジュールのための中央サービスプロバイダとして形成され,前記トランザクション処理モジュールを始動,及び/又は,終了できるように構成され,
前記データコンテナは,トランザクションプロセスで生成されたデータオブジェクトを記憶するためのものであり,システムクラッシュの後に前記データオブジェクトを修復することができるデータの可変値そして規定されたプロパティを含んでいることを特徴とする,トランザクションシステム。
【請求項2】
前記データモジュールは,データコンポーネントを備えることを特徴とする,請求項1に記載のトランザクションシステム。
【請求項3】
前記トランザクションシステムは,データコンテナを,始動,及び/又は,終了できるように構成される制御モジュールを備えることを特徴とする,請求項1又は請求項2に記載のトランザクションシステム。
【請求項4】
前記コンテキストマネージャは,互いに関係なく複数のトランザクション処理モジュールを,始動,及び/又は,終了できるように構成されることを特徴とする,請求項1に記載のトランザクションシステム。
【請求項5】
前記コンテキストマネージャは,制御モジュールとして構成されることを特徴とする,請求項1から請求項4のうちいずれか1項に記載のトランザクションシステム。」


第3.平成26年1月21日付けの当審拒絶理由

当審による平成26年1月21日付けの拒絶理由(以下,これを「当審拒絶理由」という)は,概略,次のとおりである。

『1.この出願の請求項1?5に係る発明は,その出願前日本国内において頒布された下記の刊行物1?6に記載された発明に基づいて,その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により特許を受けることができない。

2.この出願は,明細書,特許請求の範囲及び図面の記載が下記の点で,特許法第36条第4項第1号及び第6項第1号,第2号に規定する要件を満たしていない。

記

(理由1)
[引用文献等一覧]
1.特開2004-234203号公報
2.特表2004-536402号公報
3.SHUPING RAN その他:“The rigorous evaluation of enterprise java bean technology”INFORMATION NETWORKING,2001.PROCEEDINGS.15TH INTERNATIONAL CONFERENCE ON 31 JANUARY-2,PISCATAWAY,NJ,米国,IEEE,2001年, ｐ93-100
4.特表2003-529952号公報
5.特開2003-157242号公報
6.特開平9-311899号公報

備考:

・・・(中略)・・・

以上のとおりであるから,本願発明は,引用発明1,引用文献4に記載された技術事項,及び,周知の技術事項から,当業者が容易に想到し得たことと認められる。

・・・(中略)・・・

(理由2)
(1)特許法第36条第4項第1号について
ア 発明の詳細な説明の記載では,図1の記載されている本発明に係るトランザクションシステムを示す概略図の構成及びその動作が不明りょうである。
すなわち,発明の詳細な説明の図1の構成を説明するための記載と認められる下記のa?fについては,対応する記号の記載が図1になされていない。

a.0082段落に「[承認モジュール BM] 承認モジュールは様々な承認(例えば,承認の機能として表われたメニュー構造の制御)を制御する。但し,承認の概念は提供された記述に基づいて他の要素に従って拡大されなければならない。」と記載されているが,図1には,[承認モジュール BM]についての記載がなされていない。

b.0083段落に「[ライブラリ] ライブラリはCARBONフレームワークの基礎的な機能を具備する。前記基礎的な機能は,例えば,記録すること,エラーを処理すること,システム情報へのアクセスなどの機能である。」と記載されているが,図1には,「ライブラリはCARBONフレームワーク」についての記載がなされていない。

c.0085段落に「[CARBON] CARBONは,好適に次の構成要素を具備するプラットフォームに関するものである。
(1)クライアント
(2)トランザクションタイプ
(3)コンポーネント
(4)ライブラリ」と記載されているが,図1には,[CARBON]についての記載がなされていない。

d.0086段落に「[CARBONクライアント] CARBONクライアントは,個別の機能/アプリケーションを始動する。いくつかのCARBONクライアントはお互いに隣接して存在する。」と記載されているが,図1には,[CARBONクライアント]についての記載がなされていない。

e.0088段落に「[CARBONフレームワーク CF] CARBONフレームワークは,いくつかのモジュールをまとめて有することが好ましい。CARBONフレームワークは,アシスタントを基礎とするトランザクションタイプのためのクライアントを生成する機能を具備するAPIであることが好ましい。」と記載されているが,図1には,[CARBONフレームワーク CF]についての記載がなされていない。

f.0091段落に「[CARBONカーネル] CARBONカーネルの機能が実装された領域は,CARBONカーネルと呼ばれる。」と記載されているが,図1には,[CARBONカーネル]についての記載がなされていない。

イ 図3に示されている本発明に係る情報技術システムのブロックダイヤグラムに関して,発明の詳細な説明には,0140段落の記載がなされているが,この0140段落には,図3の記載されている本発明に係る情報技術システムの構成及びその動作が詳細に説明されておらず,図3に示されている本発明に係る情報技術システムの構成及びその動作が理解できない。

ウ 図4に示されている本発明に係るトランザクションの論理的順序を説明するブロックダイヤグラムに関して,発明の詳細な説明には,0150落の記載がなされているが,この0150段落には,図4の記載されている本発明に係るトランザクションの論理的順序を説明するブロックダイヤグラムに関して詳細に説明されておらず,図4に示されている本発明に係るトランザクションの論理的順序を説明するブロックダイヤグラムの構成及びその動作が理解できない。

エ 図5に示されている本発明に係る情報技術システムにおける論理的コンポーネント間の生データの交換を説明するブロックダイヤグラムに関して,発明の詳細な説明には,0151落の記載がなされているが,この0151段落には,図5に記載されている本発明に係る情報技術システムにおける論理的コンポーネント間の生データの交換を説明するブロックダイヤグラムに関して詳細に説明されておらず,図5に示されている本発明に係る情報技術システムにおける論理的コンポーネント間の生データの交換を説明するブロックダイヤグラムの構成及びその動作が理解できない。

以上のとおりであるから,本願の発明の詳細な説明の記載は,その発明の属する技術の分野における通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記載されているとは認められない。

(2)特許法第36条第6項第1号,第2号に規定する要件を満たしていない。
オ 請求項1に「トランザクションシステムは,電気的にトランザクション処理モジュールによって処理される,トランザクション若しくはビジネスプロセスをマップする」と記載されているが,「ビジネスプロセスをマップする」は何を意味するのか不明である。
(「何」かを「何」かにマッピングすることを意味するのであれば,「何」を「何」にマッピングしているのか不明である。)

カ 請求項1に「前記トランザクション処理モジュールは,コンテキストマネージャによって管理し,初期設定された送り状を作るデータが記憶されるデータコンテナを備えるとともに,」と記載されているが,この記載における「初期設定された送り状を作るデータ」とは如何なる「データ」であるのか明りょうでない。
また,この「初期設定された送り状を作るデータ」が発明の詳細な説明及び図面のいずれを指すのか明確でない。

キ 請求項1に「少なくとも1つのデータモジュールにインターフェースを介して接続され,前記データモジュールは,アプリケーション特有のデータ構造を生データに変形する生データモジュール」と記載されているが,明細書を参酌しても「生データ」がどのような「データ」であるのか定義が不明であり,「生データモジュール」がどのようなものであるのか不明確である。

ク 請求項1に「前記生データの記録は,いくつかの部分から成り,その一方は,構造の点においてスタティックであり,すべての生データの記録に関連している技術的,及び手続き的データが含まれ,1つのタイプのビジネストランザクションから別のものに変わる手続き的データが含まれ」と記載されているが,この記載は何を意味するのか不明である。
例えば,「記録,はいくつかの部分から成り」は日本語として何を意味するのか不明である。「記録」が「記録する」動作を意味するのか,「記録」されたデータを意味するのか,それとも何を意味するのか不明である。また,記録される場所についても不明である。)
また,「その一方は」と記載されているが,何に対して「一方」であるのか不明である。
また,「構造の点においてスタティックであり」についても,「データの記録」が構造の点についてスタティック(静的)であるとは何を意味するのか不明である。
さらに,「技術的データ」がどのような「データ」であるのか定義が不明である。そして,「生データの記録は,」「すべての生データの記録に関連している技術的,及び手続き的データが含まれ」についても,日本語として何を意味するのか不明である。同様に,「生データの記録は,」「1つのタイプのビジネストランザクションから別のものに変わる手続き的データが含まれ」についても日本語として何を意味するのか不明である。
また,「1つのタイプのビジネストランザクションから別のものに変わる」について,「別のもの」が何を意味するのか不明である。』


第4.平成26年5月27日付けの意見書

上記第3.の当審拒絶理由に対し,上記平成26年5月27日付けの意見書(以下,これを「当審意見書」という)における意見の内容は以下のとおりである。

『3.本願発明が特許されるべき理由
(a)理由1について
本願発明と引用文献1に記載の引用発明1との相違点について,「分散トランザクションシステム」に送り状を作るデータを得る手段を設けて本願発明のように構成することと,「トランザクション集中管理部130」をコンテキストマネージャーに代えて本願発明のように構成することと,外部から入力されるデータを処理できる形式のデータに変換する手段を設けて本願発明のように構成することと,処理対象のデータを固定部分と可変部分とに分けて処理するようにして本願発明のように構成することとは,それぞれ当業者が容易に想到し得たものである。しかし,引用発明1を「分散トランザクションシステム」において送り状を作るデータを得る手段を設け,「トランザクション集中管理部130」をコンテキストマネージャーに代え,外部から入力されるデータを処理できる形式のデータに変換する手段を設け,処理対象のデータを固定部分と可変部分とに分けて処理するようにして,相違点の全てを一括して本願発明のように構成することは当業者が容易に想到し得ないと考える。
同様にして,本願発明と引用文献2に記載の引用発明2との相違点および本願発明と引用文献3に記載の引用発明3との相違点の全てを一括して本願発明のように構成することは当業者が容易に想到し得ないと考える。
(b)理由2について
図1に記載されている本願発明に係るトランザクションシステムを示す概略図の構成及びその動作は,本願の発明の詳細な説明の記載から明りょうである。すなわち,本願の発明の詳細な説明の記載は,その発明の属する技術の分野における通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記載されていると考える。
4.むすび
したがって,本願発明は引用発明1,引用発明2および引用発明3から,その発明の属する技術分野における通常の知識を有する者が容易に発明をすることができたものではない。また,不明りょうな記載はない。よって,原査定を取り消す,この出願の発明はこれを特許すべきものとする,との審決を求める。』


第5.当審の判断

以下では,まず,当審拒絶理由のうち,上記第3,(理由2)が解消されたものであるか否かについて判断し,その後,上記第3,(理由1)が解消されたものであるか否かについて判断する。

1.(理由2)の(1)(特許法第36条第4項第1号)について

(1)本願の請求項1に係る発明である「トランザクションシステム」に関し,特に図1に係る本願明細書の発明の詳細な説明は,依然として,当業者が本願の請求項1に係る発明を実施することができる程度に明確かつ十分に記載されていない。
すなわち,本願の請求項1に係る発明である「トランザクションシステム」に関し,本願明細書の発明の詳細な説明の段落【0068】?【0092】には以下の記載がある。(下線は説明の便宜上,当審で附与したものである。)

「【0068】
本発明の特に好ましい実施形態では,トランザクション処理モジュールが統合されているトータルシステムは,トランザクションが最も小さい機能ユニットに分解された高度にモジュール化された方式である。従って,トランザクション処理モジュールは特に他の,複数のトランザクション処理モジュールの要素であるプロセスをマップすることができる。例えば,トランザクション処理モジュールはバー・コードのスキャン,個人的なアイデンティティデータの獲得または値の計算をマップすることができる。これらの個々のプロセスは,ただ一度実行されなければならないように,他のトランザクション処理モジュールによってモジュールとして呼ぶことができる。
【0069】
コンピュータシステムは少なくとも2つのデータソースかデータ受信端末から成り立つ。データソースはデータが供給される起源の場所である。データ受信端末はデータ及びこうして受け取るサイトの行先である。データの受け取りは普通,標準化されたインターフェースによって起こる。データソース及びデータ受信端末は,例えば,ローカルデータベース,サーバに支援されたデータベース,アプリケーションサーバまたはサードパーティシステムいずれの場合もある。以下,簡単に,そのようなデータソース及びデータ受信端末を一般にデータシステムと呼ぶ。データシステムは出力側と同様,入力側に置くことができる。図1で示されている具体例では,最初のデータシステムは2つの付加的なデータシステムが入力側FEと関連付けられるべきである一方,出力側BEと関連付けられるべきである。
・・・(中略)・・
【0077】
本発明の特に好ましい実施形態を以下に示す。
【0078】
・・・(中略)・・
【0082】
[承認モジュール BM]
承認モジュールは様々な承認(例えば,承認の機能として表われたメニュー構造の制御)を制御する。但し,承認の概念は提供された記述に基づいて他の要素に従って拡大されなければならない。
【0083】
[ライブラリ]
ライブラリはCARBONフレームワークの基礎的な機能を具備する。前記基礎的な機能は,例えば,記録すること,エラーを処理すること,システム情報へのアクセスなどの機能である。
【0084】
ライブラリの機能は,クライアント側の通信基盤を必要としない。特に,それぞれ適切に構築されたプログラムは,ライブラリの機能にアクセスすることができる。ライブラリはユーザーへの直接のダイアログではなく,確実にユーザ・インタフェースと関連付けられるコンポーネントを具備することが好ましい。前記コンポーネントはCARBONフレームワーク,クライアント,又はトランザクション処理モジュールによって使用される補助機能(メッセージ表示)である。
【0085】
[CARBON]
CARBONは,好適に次の構成要素を具備するプラットフォームに関するものである。
(1)クライアント
(2)トランザクションタイプ
(3)コンポーネント
(4)ライブラリ
【0086】
[CARBONクライアント]
CARBONクライアントは,個別の機能/アプリケーションを始動する。いくつかのCARBONクライアントはお互いに隣接して存在する。
【0087】
基本的に,全てのプログラムは,CARBONネットワーク全体,又はCARBONネットワークの一部のどちらかを使用するクライアントとして参照することができる。大部分において,前記プログラムはいくつかのトランザクションを実行することを目的とするプログラムである。しかし,CARBONホストのような,他のCARBONクライアントにサービスを提供する他のプログラムもまたクライアントとして参照することができる。
【0088】
[CARBONフレームワーク CF]
CARBONフレームワークは,いくつかのモジュールをまとめて有することが好ましい。CARBONフレームワークは,アシスタントを基礎とするトランザクションタイプのためのクライアントを生成する機能を具備するAPIであることが好ましい。
【0089】
CARBONフレームワークの範囲において提供される前記機能は四つの作業エリアにグループ化されることが好ましい。
(1)コア機能-前記クライアントの始動/終了,トランザクションの始動/終了,又は管理
(2)トランザクション補助(マスク,データ管理,シーケンス制御等)
(3)コンポーネント(データへのアクセス,印刷等)
(4)基礎的機能の供給(記録すること,エラー処理等)
【0090】
[CRABONホストCH]
CARBONホストは,他のモジュール若しくはサービスを起動,終了,若しくは停止することができるホストモジュールである。
【0091】
[CARBONカーネル]
CARBONカーネルの機能が実装された領域は,CARBONカーネルと呼ばれる。
【0092】
CARBONカーネルは複数のコンポーネントで構成することが好ましい。前記コンポーネントの一例を以下に示す:
すなわち,Eｐｏｓ.アプリケーション,CARBON.コンテキスト,CARBON.リカバリー,及びCARBON.セッションである。
特に,前記コンポーネントは次の機能を実行するために構成されることが好ましい。
(1)Eｐｏｓ.アプリケーション-アプリケーションの始動,アプリケーションフレームワークの初期化及び管理,
(2)CARBON.コンテキスト-トランザクションタイプの始動,停止,管理,ホスティングサービス,バックアップ,修復の制御,
(3)CARBON.リカバリー-バックアップ,修復のためのデータ記録,管理,
(4)CARBON.セッション-セッションの管理。」

上記引用の記載は,本願発明の概略図である図1の各構成について説明するための記載とされるところ,上記引用の記載のうち,段落【0082】における「承認モジュール BM」,段落【0083】における「ライブラリ」,段落【0085】における「CARBON」,段落【0086】における「CARBONクライアント」,段落【0088】における「CARBONフレームワーク CF」,及び,段落【0091】における「CARBONカーネル」については,いずれも,対応する構成が図1に示されておらず,図1において本願発明が具体的にどのように構成され,かつ各構成がどのように動作するのかについて不明りょうである。よって,本願明細書の発明の詳細な説明は,依然として,当業者が本願の請求項1に係る発明を実施することができる程度に明確かつ十分に記載されておらず,特許法第36条第4項第1号で定めるところによる記載がされていないものでもある。
したがって,当審拒絶理由の(理由2),(1),ア,a.?f.でも指摘した点は解消されておらず,特許法第36条第4項第1号で定めるところによる記載がされていないものでもある。

(2)本願の請求項1に係る発明である「トランザクションシステム」に関し,特に図5に係る本願明細書の発明の詳細な説明は,依然として,当業者が本願の請求項1に係る発明を実施することができる程度に明確かつ十分に記載されていない。
すなわち,本願の請求項1に係る発明である「トランザクションシステム」に関し,本願明細書の発明の詳細な説明の段落【0151】には以下の記載がある。

「【0151】
図式的なブロックダイヤグラムにより,図5に総合システムにおける,個々の層間の生データ交換についての論理的順序を示す。図5では,4つのデータブロック31a,31b,31c及び31dは例を用いて示される。データブロック31aから31dのそれぞれは生データのための基礎としてアプリケーション特有のデータ構造を備える。但しこれらのデータ構造が生データでないことが,示されるべきである。生データは,生データモジュール32が,一度アプリケーション特有のデータ構造をデータブロック31cから生データに変形させたときのみ得られる。よって,生データモジュール32はデータ変形プロセスを遂行する。2つの矢印33a及び33bによって示されるトランザクションのステップでは,生データサービスコンポーネント35と同様,アーカイブの記憶34で記憶されるところで,生データの記録は入力側11から部門出力側12に送信される。与えられたトランザクションに必要であれば,生データサービスコンポーネント35はサードパーティシステム14に生データを送信する。適切なアカウントの原則に従うために,トランザクションのアプリケーション特有のデータはまた記憶される。データブロック31a及び31bは,生データに変えられない相互作用データ及びプロセスデータを表すが,むしろこのために特に提供されるサービスコンポーネント36及び37で変わらずに送信される。サービスコンポーネント36及び37は,部門出力側13とサードパーティシステム14間の相互作用データ及びプロセスデータの交換もまた保障する。」

しかしながら,上記引用の記載には,図5に示された,本願発明に係るシステムにおける生データの交換が,本願発明のどの構成により,どのように行われているのか,具体的に何ら示されておらず,また,その他の箇所にも,図5について説明する箇所を見出せない。よって,図5において本願発明が具体的にどのように構成され,かつ各構成がどのように動作するのかについて不明りょうであることから,本願明細書の発明の詳細な説明は,依然として,当業者が本願の請求項1に係る発明を実施することができる程度に明確かつ十分に記載されているとはいえず,特許法第36条第4項第1号で定めるところによる記載がされていないものでもある。
したがって,当審拒絶理由の(理由2),(1),エでも指摘した点は解消されておらず,特許法第36条第4項第1号で定めるところによる記載がされていないものでもある。

(3)以上の点について,審判請求人は,当審意見書において,
『 (b)理由2について
図1に記載されている本願発明に係るトランザクションシステムを示す概略図の構成及びその動作は,本願の発明の詳細な説明の記載から明りょうである。すなわち,本願の発明の詳細な説明の記載は,その発明の属する技術の分野における通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記載されていると考える。』
と主張しているが,上記主張は,上記(理由2)の(1)の当審拒絶理由に対し,何ら具体的な釈明を行うものではないから,上記引用の主張は採用できない。

したがって,当審拒絶理由の(理由2),(1),ア,及び,エでも指摘した点は解消されておらず,また,意見書の内容を加味しても,本願明細書の発明の詳細な説明は,依然として,当業者が上記指摘の記載を含む請求項1に係る発明を実施することができる程度に明確かつ十分に記載されているとはいえず,特許法第36条第4項第1号で定めるところによる記載がされていないものでもある。


2.(理由2)の(2)(特許法第36条第6項第1号,第2号)について

(1)本願の請求項1に記載の「トランザクションシステムは,電気的にトランザクション処理モジュールによって処理される,トランザクション若しくはビジネスプロセスをマップする」における「ビジネスプロセスをマップする」について,その技術的な意味が依然として不明である。
すなわち,上記「マップする」とは,具体的にどのような処理を指すのか不明であり,また,仮に,“何”かを“何”かに“マッピングする”ことを意味するものと解しても,具体的に,“何”を“何”に“マッピングする”すること指すのか,本願明細書の発明の詳細な説明,及び,図面に記載された内容を参酌しても,依然として不明である。
したがって,当審拒絶理由の(理由2),(2),オでも指摘したように,請求項1に係る発明は依然として明確でなく,本願は,特許法第36条第6項第2号に規程する要件を満たしていない。

(2)本願の請求項1に記載の「前記トランザクション処理モジュールは,コンテキストマネージャによって管理し,初期設定された送り状を作るデータが記憶されるデータコンテナを備えるとともに,」における「初期設定された送り状を作るデータ」について,その技術的な意味が依然として不明であるとともに,本願明細書の発明の詳細な説明及び図面に示されたいずれの構成を指すのか依然として明確でない。
すなわち,上記「初期設定された送り状を作るデータ」との記載について,「初期設定された送り状を作るデータ」が具体的にどのようなデータを指すのか,本願明細書の発明の詳細な説明,及び,図面に記載された内容を参酌しても,依然として不明である。また,「初期設定された送り状を作るデータ」について,対応する構成が本願明細書の発明の詳細な説明及び図面に認められず,よって,本願明細書の発明の詳細な説明及び図面に示されたいずれの構成を指すのか依然として明確でない。
したがって,当審拒絶理由の(理由2),(2),カでも指摘したように,本願は,特許法第36条第6項第1号及び第2号に規程する要件を満たしていない。

(3)本願の請求項1に記載の「少なくとも1つのデータモジュールにインターフェースを介して接続され,前記データモジュールは,アプリケーション特有のデータ構造を生データに変形する生データモジュール」における「生データ」及び「生データモジュール」について,その技術的な意味が依然として不明である。
すなわち,上記「生データ」との記載について,具体的にどのような「データ」を指すのか,本願明細書の発明の詳細な説明,及び,図面に記載された内容を参酌しても,依然として不明である。また,上記「生データ」が不明である以上,「アプリケーション特有のデータ構造」から該「生データ」を生成する「生データモジュール」についても,どのように「生データ」を処理するのか依然として不明である。
したがって,当審拒絶理由の(理由2),(2),キでも指摘したように,請求項1に係る発明は依然として明確でなく,本願は,特許法第36条第6項第2号に規程する要件を満たしていない。

(4)本願の請求項1に記載の「前記生データの記録は,いくつかの部分から成り,その一方は,構造の点においてスタティックであり,すべての生データの記録に関連している技術的,及び手続き的データが含まれ,1つのタイプのビジネストランザクションから別のものに変わる手続き的データが含まれ」における「記録,はいくつかの部分から成り」,「その一方は」,「構造の点においてスタティックであり」,「技術的データ」,「生データの記録は,」「すべての生データの記録に関連している技術的,及び手続き的データが含まれ」,「生データの記録は,」「1つのタイプのビジネストランザクションから別のものに変わる手続き的データが含まれ」,及び,「1つのタイプのビジネストランザクションから別のものに変わる」について,その技術的な意味が依然として不明である。
すなわち,上記「記録,はいくつかの部分から成り」における「記録」との記載は,「記録」するという動作を意味するのか,「記録」されたデータを意味するのか,或いは,それ以外の何を意味するのか,本願明細書の発明の詳細な説明,及び,図面に記載された内容を参酌しても,依然として不明である。
また,上記「その一方は」との記載は,「その」が指すものが“何”であるのか不明であることから,“何”に対して「一方」であるのか,本願明細書の発明の詳細な説明,及び,図面に記載された内容を参酌しても,依然として不明である。
また,上記「構造の点においてスタティックであり」との記載は,「データの記録」が構造の点についてスタティック(静的)であるとは,どのようなことを意味しているのか全く不明であり,本願明細書の発明の詳細な説明,及び,図面に記載された内容を参酌しても,依然として不明である。
また,上記「技術的データ」との記載は,どのような点をもって「技術的データ」というのか何ら定義がなされておらず,本願明細書の発明の詳細な説明,及び,図面に記載された内容を参酌しても,依然として不明である。
また,上記「生データの記録は,」「すべての生データの記録に関連している技術的,及び手続き的データが含まれ」との記載は,上記のようにそもそも「記録」との記載が,「記録」するという動作を意味するのか,「記録」されたデータを意味するのか,或いは,それ以外の何を意味するのか不明であるし,「すべての生データの記録に関連している技術的,及び手続き的データ」とは何を意味しているのか全く不明であり,本願明細書の発明の詳細な説明,及び,図面に記載された内容を参酌しても,依然として不明である。
また,上記「生データの記録は,」「1つのタイプのビジネストランザクションから別のものに変わる手続き的データが含まれ」との記載は,上記のようにそもそも「記録」との記載が,「記録」するという動作を意味するのか,「記録」されたデータを意味するのか,或いは,それ以外の何を意味するのか,不明であるし,「1つのタイプのビジネストランザクションから別のものに変わる手続き的データ」とは何を意味しているのか全く不明であり,本願明細書の発明の詳細な説明,及び,図面に記載された内容を参酌しても,依然として不明である。
また,「1つのタイプのビジネストランザクションから別のものに変わる」における「別のもの」について,その技術的な意味が依然として不明であり,本願明細書の発明の詳細な説明,及び,図面に記載された内容を参酌しても,依然として不明である。
したがって,当審拒絶理由の(理由2),(2),クでも指摘したように,請求項1に係る発明は依然として明確でなく,本願は,特許法第36条第6項第2号に規程する要件を満たしていない。

(5)以上の点について,審判請求人は,当審意見書において,
『 (b)理由2について
図1に記載されている本願発明に係るトランザクションシステムを示す概略図の構成及びその動作は,本願の発明の詳細な説明の記載から明りょうである。すなわち,本願の発明の詳細な説明の記載は,その発明の属する技術の分野における通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記載されていると考える。』
と主張しているが,上記主張はそもそも特許法第36条第4項第1号に関する釈明であり,上記(理由2)の(2)の当審拒絶理由に対し,何ら具体的な釈明を行うものではないから,上記引用の主張は採用できない。

したがって,当審拒絶理由の(理由1),(2),オ?クでも指摘した点は解消されておらず,本願は,特許法第36条第6項第1号及び第2号に規程する要件を満たしていない。


3.(理由1)(特許法第29条第2項)について

(1)本願発明
上記1.及び2.において検討したとおり,本願の請求項1に係る発明は,特許請求の範囲の記載が明確ではなく,発明の詳細な説明の記載は,当業者がその実施をすることができる程度に明確かつ十分に記載したものではないが,一応,請求項1に係る発明(以下,これを「本願発明」という)は,前記「第2.平成24年6月7日付け手続補正」における請求項1に記載された字句どおりの,下記の記載のとおりのものとして,以下の特許法第29条第2項についての検討を行う。

「送り状を作るデータを得るための手段を具備し,少なくとも1つのサービスプロバイダのトランザクション情報を処理するためのトランザクションシステムであって,
前記トランザクションシステムは,電気的にトランザクション処理モジュールによって処理される,トランザクション若しくはビジネスプロセスをマップするための少なくとも1つのトランザクション処理モジュールを備え,
前記トランザクションは,トランザクションを実行するための前記トランザクション処理モジュールにそれぞれ関連付けられ,プロセスをプロセスの要素である部分的なプロセスに分解することを可能にし,前記各トランザクション処理モジュールのそれぞれがデータを受信及び/又は送信,及び,データを取得,及び/又は,処理するように構成され
前記トランザクション処理モジュールは,コンテキストマネージャによって管理し,初期設定された送り状を作るデータが記憶されるデータコンテナを備えるとともに,
少なくとも1つのデータモジュールにインターフェースを介して接続され,前記データモジュールは,アプリケーション特有のデータ構造を生データに変形する生データモジュールであり,
前記生データの記録は,いくつかの部分から成り,その一方は,構造の点においてスタティックであり,すべての生データの記録に関連している技術的,及び手続き的データが含まれ,1つのタイプのビジネストランザクションから別のものに変わる手続き的データが含まれ,
前記コンテキストマネージャは,前記トランザクション処理モジュールのための中央制御方法として,または前記トランザクション処理モジュールのための中央サービスプロバイダとして形成され,前記トランザクション処理モジュールを始動,及び/又は,終了できるように構成され,
前記データコンテナは,トランザクションプロセスで生成されたデータオブジェクトを記憶するためのものであり,システムクラッシュの後に前記データオブジェクトを修復することができるデータの可変値そして規定されたプロパティを含んでいることを特徴とする,トランザクションシステム。」

(2)引用文献の記載事項及び引用発明
(2-1)引用文献1
本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となり,平成26年1月21日付けの当審拒絶理由において引用された,特開2004-234203号公報(以下,「引用文献1」という。)には,関連する図面と共に,以下の記載がなされている。
(当審注:下線は参考のため,当審で附与したものである。)

A.「【0001】
【発明の属する技術分野】
本発明はコンピュータシステムの分散トランザクションシステムに係り,特に,EJB(登録商標)コンテナ異常終了時に仕掛かり中トランザクションを短時間で決着するシステムに関する。」

B.「【0007】
本発明の目的は,Jaｖa(登録商標)(プログラミング言語の一種)の技術を使用した分散トランザクションシステムにおいて,アプリケーションプログラムが動作中(トランザクション処理中)にEJB(登録商標)コンテナが異常終了した場合に,仕掛かり中トランザクションの決着処理を短時間に行う技術を提供することにある。
【0008】
【課題を解決するための手段】
前記課題を解決するために,本発明は主として次のような構成を採用する。
アプリケーションプログラム,トランザクションマネージャ,リソースマネージャ,他のEJB(登録商標)コンテナ情報保持部,を有する複数のEJB(登録商標)コンテナと,各EJB(登録商標)コンテナの前記トランザクションマネージャに接続されたトランザクション集中管理部と,各EJB(登録商標)コンテナのリソースマネージャに接続されたリソースと,を備えた分散トランザクションシステムであって,
一のEJB(登録商標)コンテナ上で動作するアプリケーションプログラムがアクセス対象としているリソースの情報を前記一のEJB(登録商標)コンテナから前記トランザクション集中管理部に通知し,
前記トランザクション集中管理部が前記一のEJB(登録商標)コンテナによるトランザクション実行中の異常終了を検知した場合に,前記トランザクション集中管理部を経由して通知された前記リソースの情報を使用して他のEJB(登録商標)コンテナが仕掛かり中のアクセスの決着処理を前記リソースに対して要求する構成とする。
【0009】
本発明は,この構成を採用することにより,EJB(登録商標)コンテナがトランザクション実行中に異常終了した場合に,他の起動済EJB(登録商標)コンテナが,仕掛かり中のアクセスの決着処理をリソースに対して要求するので,EJB(登録商標)コンテナ起動処理に要する時間分だけ回復時間を短縮することができる。」

C.「【0010】
【発明の実施の形態】
本発明の実施形態に係る分散トランザクションシステムについて,図面を参照しながら以下説明する。図1は,本発明の実施形態に係るコンピュータシステムの分散トランザクションシステムにおける全体構成を示す図である。
【0011】
図1において,分散トランザクションシステムは,EJB(登録商標)コンテナ(Enｔeｒｐｒiｓe Jaｖa(登録商標)Beanｓ(TM)cｏnｔaineｒ)101,111と,DBMS(Daｔa Baｓe Managemenｔ Sｙｓｔem)120と,トランザクション集中管理130と,から構成されており,EJB(登録商標)コンテナ101上には,アプリケーションプログラム102,トランザクションマネージャ103,リソースマネージャ104,他EJB(登録商標)コンテナ情報105が存在する。ここで,他EJB(登録商標)コンテナ情報105は,トランザクションマネージャ103が他のEJB(登録商標)コンテナ111がアクセス対象としているリソースを記憶するためのものである。同様の構成のEJB(登録商標)コンテナは,他にも複数個存在し,その一つがEJB(登録商標)コンテナ111である。
【0012】
トランザクション集中管理130は,各EJB(登録商標)コンテナ上に存在するトランザクションマネージャ103,113を制御するためのものであり,EJB(登録商標)コンテナとは別のプロセスで動作している。また,DBMS120は,アプリケーションプログラム102,112から,リソースマネージャ104,114経由で参照・更新要求を受ける。なお,本発明の実施形態では,リソースの一例としてDBMSを使って説明を行う。
【0013】
図1に示す構成例は,二つのEJB(登録商標)コンテナが,お互いの情報を持ち合う形になっているが,一つ又は複数個のEJB(登録商標)コンテナが,複数個のEJB(登録商標)コンテナの情報を全て記憶する形でもよい。また,他EJB(登録商標)コンテナの情報を記憶するEJB(登録商標)コンテナ情報105,115は,アプリケーションプログラムを実行させずに決着処理専用として用意しても良い。」

D.「【0014】
図2は,本発明の実施形態に係る分散トランザクションシステムにおいて,EJB(登録商標)コンテナ101,111上でアプリケーションプログラム102,112を動作させる際に,トランザクションマネージャ103,113が行う処理を示すフローである。この処理は,当該EJB(登録商標)コンテナ上でアプリケーションプログラムを起動する際に動作する。
【0015】
ステップ201にて,アプリケーションプログラムをデプロイ(配備)し,ステップ202で,当該アプリケーションプログラムがアクセス対象としているリソースの情報をトランザクション集中管理130に連絡する。ステップ203でイベントの発生を待ち,ステップ204で発生したイベントの内容を判定して,アプリケーションプログラムのアンデプロイ要求(アンロード要求)であった場合はステップ207へ遷移する。また,イベントがアプリケーションプログラムの起動要求であった場合,ステップ205でアプリケーションプログラムを起動し,アプリケーションプログラムを実行するとともに,ステップ203に戻って,新たなイベントの発生を待つ。即ち,図2のフローでは,アプリケーションプログラムを起動205すると,終了待ちをせずにすぐに次のイベント発生待ち203に戻ることにより,複数のアプリケーションプログラムを同時並行に実行できる。」

以下,引用文献1の記載事項について検討する。

ア.上記A.の「本発明はコンピュータシステムの分散トランザクションシステムに係り,特に,EJB(登録商標)コンテナ異常終了時に仕掛かり中トランザクションを短時間で決着するシステム・・・」との記載,及び,上記B.における段落【0008】の記載から,
引用文献1は,
“EJBコンテナ異常終了時に仕掛かり中トランザクションを短時間で決着する分散トランザクションシステムであり,
アプリケーションプログラム,トランザクションマネージャ,リソースマネージャ,他のEJBコンテナ情報保持部,を有する複数のEJBコンテナと,各EJBコンテナの前記トランザクションマネージャに接続されたトランザクション集中管理部と,各EJBコンテナの前記リソースマネージャに接続されたリソースと,を備えた分散トランザクションシステムであって,
一のEJBコンテナ上で動作するアプリケーションプログラムがアクセス対象としているリソースの情報を前記一のEJBコンテナから前記トランザクション集中管理部に通知し,
前記トランザクション集中管理部が前記一のEJBコンテナによるトランザクション実行中の異常終了を検知した場合に,前記トランザクション集中管理部を経由して通知された前記リソースの情報を使用して他のEJBコンテナが仕掛かり中のアクセスの決着処理を前記リソースに対して要求する,システム”について説明するものであることが理解できる。

イ.上記B.の「分散トランザクションシステムにおいて,アプリケーションプログラムが動作中(トランザクション処理中)に」との記載,上記D.の「図2は,本発明の実施形態に係る分散トランザクションシステムにおいて,EJB(登録商標)コンテナ101,111上でアプリケーションプログラム102,112を動作させる際に,トランザクションマネージャ103,113が行う処理を示すフローである。」,及び,「ステップ201にて,アプリケーションプログラムをデプロイ(配備)し,ステップ202で,当該アプリケーションプログラムがアクセス対象としているリソースの情報をトランザクション集中管理130に連絡する。ステップ203でイベントの発生を待ち,ステップ204で発生したイベントの内容を判定して,・・・(中略)・・・イベントがアプリケーションプログラムの起動要求であった場合,ステップ205でアプリケーションプログラムを起動し,アプリケーションプログラムを実行するとともに,ステップ203に戻って,新たなイベントの発生を待つ。」との記載から,
引用文献1に記載の「システム」において,
前記“EJBコンテナにおけるトランザクションマネージャは,トランザクション処理に係るアプリケーションプログラムを動作させる際に,アプリケーションプログラムをデプロイし,アクセス対象としているリソースの情報をトランザクション集中管理部に通知し,発生したイベントの内容を判定してアプリケーションプログラムの起動要求であった場合,アプリケーションプログラムを起動して実行する”ことが記載されているといえる。

ウ.上記C.の「トランザクション集中管理130は,各EJB(登録商標)コンテナ上に存在するトランザクションマネージャ103,113を制御するためのものであり」との記載から,
引用文献1に記載の「システム」において,
前記“トランザクション集中管理部は,各EJBコンテナ上に存在する前記トランザクションマネージャを制御するものであ”ることが記載されているといえる。

エ.上記ア.の検討結果における“一のEJBコンテナ上で動作するアプリケーションプログラムがアクセス対象としているリソースの情報を前記一のEJBコンテナから前記トランザクション集中管理部に通知し”に関し,
上記イ.の検討結果によれば,「アプリケーションプログラム」が「アクセス対象としているリソースの情報をトランザクション集中管理部に通知」するのは,「EJBコンテナにおけるトランザクションマネージャ」であることから,
上記“一のEJBコンテナ上で動作するアプリケーションプログラムがアクセス対象としているリソースの情報を前記一のEJBコンテナから前記トランザクション集中管理部に通知”することは,前記“EJBコンテナにおける前記トランザクションマネージャによって”行われることが読み取れる。

以上,ア.ないしエ.で指摘した事項を踏まえると,引用文献1には,次の発明(以下,「引用発明」という。)が記載されているものと認められる。

「EJBコンテナ異常終了時に仕掛かり中トランザクションを短時間で決着する分散トランザクションシステムであり,
アプリケーションプログラム,トランザクションマネージャ,リソースマネージャ,他のEJBコンテナ情報保持部,を有する複数のEJBコンテナと,各EJBコンテナの前記トランザクションマネージャに接続されたトランザクション集中管理部と,各EJBコンテナの前記リソースマネージャに接続されたリソースと,を備えた分散トランザクションシステムであって,
前記EJBコンテナにおける前記トランザクションマネージャは,トランザクション処理に係るアプリケーションプログラムを動作させる際に,アプリケーションプログラムをデプロイし,アクセス対象としているリソースの情報を前記トランザクション集中管理部に通知し,発生したイベントの内容を判定してアプリケーションプログラムの起動要求であった場合に,アプリケーションプログラムを起動して実行するものであり,
前記トランザクション集中管理部は,各EJBコンテナ上に存在する前記トランザクションマネージャを制御するものであり,
前記EJBコンテナにおける前記トランザクションマネージャによって,一のEJBコンテナ上で動作するアプリケーションプログラムがアクセス対象としているリソースの情報を前記一のEJBコンテナから前記トランザクション集中管理部に通知し,
前記トランザクション集中管理部が前記一のEJBコンテナによるトランザクション実行中の異常終了を検知した場合に,前記トランザクション集中管理部を経由して通知された前記リソースの情報を使用して他のEJBコンテナが仕掛かり中のアクセスの決着処理を前記リソースに対して要求する,システム。」

(2-2)引用文献4
本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となり,平成26年1月21日付けの当審拒絶理由において引用された,特表2003-529952号公報(以下,「引用文献4」という。)には,関連する図面と共に,以下の記載がなされている。
(当審注:下線は参考のため,当審で附与したものである。)

E.「【0005】
(発明の開示)
本発明によれば,ベアラにインタフェースするためのベアラアダプテーション層,及び起点サーバにインタフェースするためのクライアントを含むスタックを含む通信用ゲートウェイであって,
前記スタック上のユーザとして機能し,かつ外部エンティティに対するインタフェース手段をサポートして補助的サービスを提供するコンテキストマネージャを更に備えることを特徴とする通信用ゲートウェイが提供される。
【0006】
コンテキストマネージャが,スタック上のユーザであり,かつインタフェース手段をサポートするための手段を有するため,その構造のプラットフォームとして機能するので,これは非常に柔軟で汎用性のある構成である。」

F.「【0051】
図1を参照すると,WAPゲートウェイ1が移動体オペレータのドメイン2において接続されている。このゲートウェイは,ハンドセット(クライアント)4のための移動体オペレータのネットワーク3とのベアラリンク(bearer link)を有する。ゲートウェイ1は,HTTPリンクによって無線電話アプリケーション(WTA)サーバ5にも接続されている。ドメイン2は,無線インタフェースによって接続された他のアプリケーションプラットフォーム6も備えている。ゲートウェイ1は,HTTPリンクによって起点サーバ10にも接続されている。これは典型的な配置であるが,ネットワーク3へのリンク及び起点サーバへのリンクのみが必要不可欠なものである。
【0052】
ゲートウェイ1によって,WAP機能を有するハンドセット(即ちブラウザ及びWAPスタックを備えたもの)が,移動体オペレータのドメイン2及び他の場所(例えばサービスプロバイダ等)に拠点を置く標準的なHTTPサーバに置かれたアプリケーションにアクセスできるようになる。」

G.「【0056】
図2を参照すると,ゲートウェイ1が,最下層から順番に,
無線データグラムプロトコル(WDP)層21,
無線トランスポート層セキュリティ(WTLS)層22,
無線トランザクションプロトコル(WTP)層23,及び
無線セッションプロトコル(WSP)層24
を有する。
【0057】
コンテキストマネージャ(context manager)25は,スタック22上のユーザであり,外部エンティティに対するインタフェースをサポートしている。この実施態様におけるインタフェース群は,以下のもの即ち,
・軽量ディレクトリアクセスプロトコル(lightweight directory access protocol)(LDAP)クライアント26,
・プッシュAPI(push API)27,
・コンパイラ/エンコーダ(C/E)28,
・HTTPクライアント29,及び
・RADIUSアカウンティングサーバ30
である。
【0058】
コンテキストマネージャ25は,スタック20の上,より詳細にはWSP層24の上のユーザである実行可能コア31も含む。コア31は,インタフェース26-30をサポートする。
【0059】
ゲートウェイ1は,ゲートウェイにおける主要な構成要素の大部分によりアクセスされる内部データベース32も含む。
【0060】
加えて,ゲートウェイ1は,イベントログ36及び課金ログ(billing log)37を維持し,かつスタック20の全ての層及びコンテキストマネージャ25と相互作用するイベントマネージャ(event manager)35も含む。このイベントマネージャ35は,セッションマネージャ(session manager)45及びマネジメントコア(management core)46を含むマネジメントエンティティ40に接続される。そのマネジメントエンティティに対して,マネジメントGUI47が設けられている。」

(2-3)引用文献5
本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となり,平成26年1月21日付けの当審拒絶理由において引用された,特開2003-157242号公報(以下,「引用文献5」という。)には,関連する図面と共に,以下の記載がなされている。
(当審注:下線は参考のため,当審で附与したものである。)

H.「【0001】
【発明の属する技術分野】本発明は,例えばJaｖa(登録商標)言語に従うアプリケーションサーバを利用した分散処理システム及び連携用アダプタ並びに分散処理システムにおける連携方法及びプログラムに関する。
【0002】
【従来の技術】分散処理システム構築のためのプラットフォーム(基盤)として,アプリケーションサーバと呼ばれるミドルウェアの利用が多くなってきている。現在,アプリケーションサーバの標準仕様としては,J2EE(Jaｖa2 Plaｔfｏｒm,Enｔeｒｐｒiｓe Ediｔiｏn)が業界標準の地位を占めている。
【0003】J2EE準拠のアプリケーションサーバ上で動作するアプリケーションシステムは,Jaｖa言語を使用して開発され,EJB(Enｔeｒｐｒiｓe Jaｖa Beanｓ),Seｒｖleｔ,JSP(Jaｖa Seｒｖeｒ Pageｓ)といったプログラミングモデルに従ったコンポーネント群から構成される形態を取る。
【0004】しかし,実際のシステムでは,Jaｖa言語以外の言語で開発したコンポーネントの利用が必要であったり,既存のサブシステムを統合して一つのシステムに仕立て上げることが必要であったりするため,システム全体をJaｖa言語のみで構築することは困難な場合も多い。
【0005】このような場合,Jaｖa言語以外の言語で構築するコンポーネントは,分散オブジェクトのための標準規格であるCORBA(Cｏmmｏn ObjecｔReｑｕeｓｔ Bｒｏkeｒ Aｒchiｔecｔｕｒe)を利用して構築することが多くなってきている。ただし,このような場合,アプリケーションサーバ上のコンポーネントと,CORBAを利用して構築されているコンポーネントの間でのやり取りを行なうことが必要になる。」

J.「【0027】本実施形態の分散処理システムは,図1に示すように,アプリケーションサーバ101と,このアプリケーションサーバ101に図示しないネットワーク等を介して連携されるCORBAサーバ102とを含み,この連携に係る処理,設定,データの型変換を,連携用アダプタ104を介して実行するものである。
【0028】図1は,アプリケーションサーバ101上で動作しているEJB103が,CORBAサーバ102上で動作しているCORBAオブジェクト108にアクセスするために,連携用アダプタ104を利用している状態を示している。」

K.「【0065】 本実施形態においてはアプリケーションサーバ101とCORBAサーバ102との連携に係る処理,設定,データの型変換を連携用アダプタ104を介して実行することで,連携用アダプタ104のメソッド内で必要に応じたデータ変換が可能となるため,EJB103とCORBAオブジェクト108の間のデータの受け渡しにおいて,柔軟な対応が行なえる。」

(2-4)引用文献6
本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となり,平成26年1月21日付けの当審拒絶理由において引用された,特開平9-311899号公報(以下,「引用文献6」という。)には,関連する図面と共に,以下の記載がなされている。
(当審注:下線は参考のため,当審で附与したものである。)

L.「【0005】
【発明が解決しようとする課題】上記従来の技術は,給与計算に使用する各種のデータの入力作業を分散化させ,平均化させるのに有効な技術である。すなわちマスタファイルを更新する作業が一時期に集中することを防ぎ,更新作業を複数人で分担することも可能となる。しかしながらデータ入力作業そのものは人手で行うことから,入力ミスは発生する。この場合にはデータ修正作業を行わなければならない。特に給与計算のトランザクション実行後に計算結果の誤りが発覚した場合には,既に更新されたマスタファイル中の誤ったデータを特定して修正し,再度計算しなおす必要がある。誤ったデータの特定は時間がかかるとともに,担当者の負担が大きく,困難な作業である。なおデータを入力する担当者と誤りを特定する担当者とは必ずしも同一人とは限らない。
【0006】本発明の目的は,給与に関係するデータの入力ミスが発生したときのデータ修正に要する担当者の負担を軽減することにある。
【0007】
【課題を解決するための手段】本発明は,ネットワークを介してクライアントとサーバとが接続され,クライアントから入力したデータに基づいて給与に関するデータを格納するサーバ側のマスタファイルを更新するシステムのデータ入力方法であり,サーバではクライアントから受信した入力データのチェックを行い,データが妥当であればマスタファイルを更新してからクライアントへ正常終了のメッセージを送信し,正常終了のメッセージを受信したときクライアント側で入力データの変更履歴を採取し,マスタ更新済のレコードをデータ修正する場合には,データ変更履歴を基にしてデータ修正の対象とする履歴レコードを選択し,データ修正された入力データについてマスタファイルを再度更新し,再度入力データの変更履歴を採取する給与データの入力方法を特徴とする。」

M.「【0013】図4は,変更データ履歴ファイル11のデータ形式の例を示す図である。図中の1行が1レコードであり,マスタファイル中の1レコードに対する1回の更新処理によってレコードが1件ずつ追加される。40はすべてのマスタファイルについて共通のデータ形式となる固定部,41はマスタファイルによってデータ形式が可変となる可変部である。固定部40も可変部41も,各データ項目を「,」で区切って格納する。固定部40の最初の項目はマスタファイル名称であり,2番目の項目は更新日時,3番目は更新時刻である。更新日時及び更新時刻は,レコードを変更データ履歴ファイル11に格納する際にシステム日付から取得される。4番目の項目は職員番号である。例えば図中のレコード42は,「人事マスタ」に対して,「95年7月1日,10時30分」に職員番号「10」の人のレコードを更新したことを示す。可変部41は,対象となるマスタファイルの各項目に対して操作者が入力したデータを格納する。例えばレコード42は「人事マスタ」に対する更新処理の履歴であるから,可変部41の最初の項目は「職名」が「課員」であることを示し,2番目は「部名」が「総務」,3番目は「課名」が「人事」であることを示している。最後の「追加」はマスタファイルへの操作の種別を示すフラグである。操作者が選択した操作によって,「追加」「更新」「削除」のうちから1つが格納される。」

(3)本願発明と引用発明との対比
本願発明と引用発明とを対比する。

(3-1)引用発明における「トランザクション」を「決着」するとは「決着処理」することであり,「トランザクション」を「処理」することに包含されるものであって,本願発明の「トランザクション情報を処理する」ことに相当するといえる。
してみると,引用発明である「EJBコンテナ異常終了時に仕掛かり中トランザクションを短時間で決着する分散トランザクションシステム」と,本願発明である「送り状を作るデータを得るための手段を具備し,少なくとも1つのサービスプロバイダのトランザクション情報を処理するためのトランザクションシステム」とは,後記する点で相違するものの,“少なくとも1つのトランザクション情報を処理するためのトランザクションシステム”である点で共通するといえる。

(3-2)引用発明の「トランザクションマネージャ」は,本願発明の「トランザクション処理モジュール」に対応するところ,引用発明の「トランザクションマネージャ」は,「アプリケーションプログラムを動作」させて「トランザクション処理」を行うものであり,また,該「トランザクション」を業務システムにおける処理の対象として対応付けることは,当該技術分野における技術常識であり,また,該「トランザクションマネージャ」を「モジュール」として構成し得ることも,同様に技術常識であったといえる。一方,本願発明の「トランザクションシステムは,電気的にトランザクション処理モジュールによって処理される,トランザクション若しくはビジネスプロセスをマップする」における「マップする」の技術的な意味は,上記2.,(1)で述べたように必ずしも明確なものではないものの,上記引用発明に係る「トランザクションマネージャ」が,業務システムにおける処理の対象として「トランザクション」を対応付けることを包含するものと解釈することもできるから,この点において両者は実質的に相違しない。
してみると,引用発明の「分散トランザクションシステム」が「EJBコンテナ」の構成として「トランザクションマネージャ」を備えることは,本願発明の「前記トランザクションシステムは,電気的にトランザクション処理モジュールによって処理される,トランザクション若しくはビジネスプロセスをマップするための少なくとも1つのトランザクション処理モジュールを備え」ることに相当するといえる。

(3-3)引用発明の「トランザクションマネージャ」が,「アプリケーションプログラムを動作」させて「トランザクション処理」を行い,「リソースの情報を前記一のEJBコンテナから前記トランザクション集中管理部に通知」することと,本願発明の「前記トランザクションは,トランザクションを実行するための前記トランザクション処理モジュールにそれぞれ関連付けられ,プロセスをプロセスの要素である部分的なプロセスに分解することを可能にし,前記各トランザクション処理モジュールのそれぞれがデータを受信及び/又は送信,及び,データを取得,及び/又は,処理するように構成され」ることとは,後記する点で相違するものの,“前記トランザクションは,トランザクションを実行するための前記トランザクション処理モジュールにそれぞれ関連付けられ,前記各トランザクション処理モジュールのそれぞれがデータを受信及び/又は送信,及び,データを取得,及び/又は,処理するように構成され”ることである点で共通するといえる。

(3-4)引用発明の「トランザクション集中管理部」は,本願発明の「コンテキストマネージャ」に対応するところ,引用発明の「トランザクションマネージャ」は,「トランザクション集中管理部」によって「制御」されることから「管理」されるものといえ,また,該「トランザクションマネージャ」は,「リソースの情報」を「前記トランザクション集中管理部に通知」し,さらに,「アプリケーションプログラムを動作」させて「トランザクション処理」を行って用いることから,該「リソースの情報」及び「トランザクション処理」結果等のデータを記憶するための,何らかの記憶手段を有することは明らかであり,該何らかの記憶手段が,本願発明における,「トランザクション処理モジュール」の「データコンテナ」に相当する。
してみると,引用発明の「トランザクションマネージャ」が,「トランザクション集中管理部」により「制御」され,「リソースの情報」を「前記トランザクション集中管理部に通知」し,さらに,「アプリケーションプログラムを動作」させて「トランザクション処理」を行うことと,本願発明の「前記トランザクション処理モジュールは,コンテキストマネージャによって管理し,初期設定された送り状を作るデータが記憶されるデータコンテナを備える」こととは,後記する点で相違するものの,“前記トランザクション処理モジュールは,データが記憶されるデータコンテナを備える”ことである点で共通するといえる。

(3-5)上記(3-4)における,引用発明の「トランザクションマネージャ」が有する何らかの記憶手段は,「リソースの情報」及び「トランザクション処理」結果等のデータを記憶するものといえるが,該「トランザクション処理」結果としてのデータが,プロセスで生成されたデータオブジェクトを包含することは,当該技術分野における技術常識であった。
してみると,引用発明の「トランザクションマネージャ」が,「リソースの情報」を「前記トランザクション集中管理部に通知」し,さらに,「アプリケーションプログラムを動作」させて「トランザクション処理」を行うことと,本願発明の「前記データコンテナは,トランザクションプロセスで生成されたデータオブジェクトを記憶するためのものであり,システムクラッシュの後に前記データオブジェクトを修復することができるデータの可変値そして規定されたプロパティを含んでいる」こととは,後記する点で相違するものの,“前記データコンテナは,トランザクションプロセスで生成されたデータオブジェクトを記憶するためのものであ”る点で共通するといえる。

以上の対比から,本願発明と引用発明とは,以下の点で一致し,また,以下の点で相違する。

(一致点)
少なくとも1つのトランザクション情報を処理するためのトランザクションシステムであって,
前記前記トランザクションシステムは,電気的にトランザクション処理モジュールによって処理される,トランザクション若しくはビジネスプロセスをマップするための少なくとも1つのトランザクション処理モジュールを備え,
前記トランザクションは,トランザクションを実行するための前記トランザクション処理モジュールにそれぞれ関連付けられ,前記各トランザクション処理モジュールのそれぞれがデータを受信及び/又は送信,及び,データを取得,及び/又は,処理するように構成され
前記トランザクション処理モジュールは,データが記憶されるデータコンテナを備えるとともに,
前記データコンテナは,トランザクションプロセスで生成されたデータオブジェクトを記憶するためのものであることを特徴とする,トランザクションシステム。

(相違点1)
本願発明の「トランザクションシステム」は,「送り状を作るデータを得るための手段」を備えるとともに,「初期設定された送り状を作るデータ」をデータコンテナに記憶するものであるのに対して,引用発明の「分散トランザクションシステム」には,送り状を作るデータを得るための手段を備えておらず,初期設定された送り状を作るデータも記憶されていない点。

(相違点2)
システムが処理するトランザクションに関し,
本願発明は,「サービスプロバイダ」のトランザクション情報であるのに対して,引用発明は,どのようなトランザクションであるかについて言及されていない点。

(相違点3)
トランザクションに関し,
本願発明は,「プロセスをプロセスの要素である部分的なプロセスに分解することを可能に」するものであるのに対して,引用発明は,そのような特定がされていない点。

(相違点4)
本願発明は,「コンテキストマネージャ」によってトランザクション処理モジュールを管理し,「前記コンテキストマネージャは,前記トランザクション処理モジュールのための中央制御方法として,または前記トランザクション処理モジュールのための中央サービスプロバイダとして形成され,前記トランザクション処理モジュールを始動,及び/又は,終了できるように構成され」ているのに対して,引用発明は,「トランザクション集中管理部」によってトランザクションマネージャを制御し管理している点。

(相違点5)
本願発明は,「アプリケーション特有のデータ構造を生データに変形する生データモジュール」を備えるとともに,「前記生データの記録は,いくつかの部分から成り,その一方は,構造の点においてスタティックであり,すべての生データの記録に関連している技術的,及び手続き的データが含まれ,1つのタイプのビジネストランザクションから別のものに変わる手続き的データが含まれ」ているのに対して,引用発明は,そのように構成されていない点。

(相違点6)
トランザクションプロセスで生成されたデータオブジェクトを記憶する,データコンテナに関し,
本願発明は,「システムクラッシュの後に前記データオブジェクトを修復することができるデータの可変値そして規定されたプロパティを含んでいる」のに対して,引用発明は,そのように構成されていない点。

(4)相違点についての判断

上記相違点1ないし相違点6について検討する。

(4-1)相違点1について

一般に,ビジネストランザクションシステムにおいて,送り状作成のための処理を行うことは,例示するまでもなく本願優先日前には周知の事項であったといえ,また,該送り状の作成を,最初に設定される何らかの設定データをもとに行うことは,当該技術分野における常とう手段である。
一方,本願発明の「前記トランザクション処理モジュールは,コンテキストマネージャによって管理し,初期設定された送り状を作るデータが記憶されるデータコンテナを備えるとともに,」における「初期設定された送り状を作るデータ」の技術的な意味は,上記2.,(2)で述べたように必ずしも明確なものではないものの,上記周知事項及び常とう手段を採用することで構成される,送り状の作成処理を最初に設定される何らかの設定データをもとに行うことを包含するものと解釈することもできる。
そして,引用発明と,上記周知事項及び常とう手段とが,同様の技術分野に属することは明らかであるから,引用発明において,上記周知事項及び常とう手段を適用することで,「送り状を作るデータを得るための手段」を備えるとともに,「初期設定された送り状を作るデータ」をデータコンテナに記憶するようにすること,すなわち,相違点1に係る構成とすることは,当業者が容易に想到し得たことである。
よって,相違点1は,格別のものではない。

(4-2)相違点2について

トランザクション処理システムにおいて,サービスプロバイダに係るトランザクションを処理対象とすることは,例えば,上記引用文献4(上記F.及びG.の記載照)に記載されているように,本願優先日前には周知の技術であった。そして,引用発明と上記周知技術とが同様の技術分野に属することは明らかであるから,引用発明における処理対象を,「サービスプロバイダ」のトランザクション情報とすること,すなわち,相違点2に係る構成とすることは,当業者が容易に想到し得たことである。
よって,相違点2は,格別のものではない。

(4-3)相違点3について

プロセスを,部分的なプロセスにさらに分解可能なものとすることは,情報処理技術の分野における技術常識といえる事項であり,トランザクションに係るプロセスについて該技術常識の如く構成すること,すなわち,相違点3に係る構成とすることは,当業者が適宜なし得る事項である。
よって,相違点3は,格別のものではない。

(4-4)相違点4について

引用文献4には,トランザクションシステムの動作をコンテキストマネージャを用いて制御することが記載されている(上記E.の記載)。
また,引用発明の「トランザクション集中管理部」は,「各EJBコンテナ上に存在する前記トランザクションマネージャを制御する」ものであるところ,該制御の下,「トランザクションマネージャ」が動作を始め,または終了しているから,「トランザクションマネージャ」の開始または終了を制御していることに他ならない。
そして,引用発明と引用文献4に記載の事項とが同様の技術分野に属することは明らかであるから,引用発明の「トランザクション集中管理部」に対し,上記引用文献4に記載の事項を適用して,「コンテキストマネージャ」によってトランザクション処理モジュールを管理し,「前記コンテキストマネージャは,前記トランザクション処理モジュールのための中央制御方法として,または前記トランザクション処理モジュールのための中央サービスプロバイダとして形成され,前記トランザクション処理モジュールを始動,及び/又は,終了できるように構成され」るようにすること,すなわち,相違点4に係る構成とすることは,当業者が容易に想到し得たことである。
よって,相違点4は,格別のものではない。

(4-5)相違点5について

トランザクション処理システムにおいて,外部から入力されるデータを,処理可能な形式のデータに変換すること(例えば,上記引用文献5の,上記H.?K.の記載)や,処理対象のデータを固定部分と可変部分に分けて処理すること(例えば,上記引用文献6のL.及びM.の記載)は,いずれも,本願優先日前には周知の技術であった。
一方,本願発明の「少なくとも1つのデータモジュールにインターフェースを介して接続され,前記データモジュールは,アプリケーション特有のデータ構造を生データに変形する生データモジュール」における「生データ」及び「生データモジュール」の技術的な意味,並びに,本願発明の「前記生データの記録は,いくつかの部分から成り,その一方は,構造の点においてスタティックであり,すべての生データの記録に関連している技術的,及び手続き的データが含まれ,1つのタイプのビジネストランザクションから別のものに変わる手続き的データが含まれ」における「記録,はいくつかの部分から成り」,「その一方は」,「構造の点においてスタティックであり」,「技術的データ」,「生データの記録は,」「すべての生データの記録に関連している技術的,及び手続き的データが含まれ」,「生データの記録は,」「1つのタイプのビジネストランザクションから別のものに変わる手続き的データが含まれ」,及び,「1つのタイプのビジネストランザクションから別のものに変わる」の技術的な意味は,上記2.,(3),及び,(4)で述べたように必ずしも明確なものではないものの,上記周知技術等を採用することで構成される,処理可能な形式のデータを,固定部分と可変部分に分けて構成する態様,及び,該データを生成するための所定の手段を周知のモジュールとして構成する態様を包含するものと解釈することもできる。
そして,引用発明と,上記周知技術とが,同様の技術分野に属することは明らかであるから,引用発明において,上記周知技術を適用することで,「アプリケーション特有のデータ構造を生データに変形する生データモジュール」を備えるとともに,「前記生データの記録は,いくつかの部分から成り,その一方は,構造の点においてスタティックであり,すべての生データの記録に関連している技術的,及び手続き的データが含まれ,1つのタイプのビジネストランザクションから別のものに変わる手続き的データが含まれ」るようにすること,すなわち,相違点5に係る構成とすることは,当業者が容易に想到し得たことである。
よって,相違点5は,格別のものではない。

(4-6)相違点6について

データオブジェクトが,データ及びプロパティを有することは技術常識であり,また,当該データ及びプロパティを記憶しておくことで,システムクラッシュにより破損したデータオブジェクトを修復可能とすることも,例示するまでもなく周知の技術であった。そして,引用発明と上記周知技術等とが同様の技術分野に属することは明らかであるから,引用発明において記憶するデータに対し,「システムクラッシュの後に前記データオブジェクトを修復することができるデータの可変値そして規定されたプロパティを含んでいる」よう構成すること,すなわち,相違点6に係る構成とすることは,当業者が容易に想到し得たことである。
よって,相違点6は,格別のものではない。

上記で検討したごとく,相違点1ないし6はいずれも格別のものではなく,そして,本願発明の構成によってもたらされる効果も,当業者であれば容易に予測できる程度のものであって,格別なものとは認められない。
よって,本願発明は,引用発明,引用文献4に記載の事項,及び,周知の技術に基づいて当業者が容易に発明をすることができたものである。


第6.むすび
したがって,本願は,特許法第36条第4項第1号及び第6項第1号,第2号に規定する要件を満たしていない。
更に,本願の請求項1に係る発明は,本願の特許出願前に日本国内又は外国において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて,当業者が容易に発明をすることができたものであるので,特許法第29条第2項の規定により特許を受けることができない。

よって,結論のとおり審決する。
 
審理終結日 2014-07-16 
結審通知日 2014-07-22 
審決日 2014-08-05 
出願番号 特願2007-554441(P2007-554441)
審決分類 P 1 8・ 536- WZ (G06F)
P 1 8・ 121- WZ (G06F)
P 1 8・ 537- WZ (G06F)
最終処分 不成立  
前審関与審査官 漆原 孝治  
特許庁審判長 金子 幸一
特許庁審判官 仲間 晃
辻本 泰隆
発明の名称 トランザクション情報を処理するためのトランザクションシステム、及びトランザクションを遂行する方法  
代理人 矢野 寿一郎  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ