【事件の表示】
　特願２００７−　５０５９６「サービスコンポーネント発見システム及びサービスコンポーネント発見プログラム」拒絶査定不服審判事件〔平成２０年　９月１８日出願公開、特開２００８−２１７１５９〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１　手続の経緯・本願発明
　本願は平成１９年２月２８日の出願であって，平成２２年４月１５日付けの拒絶理由の通知に対し，平成２２年６月１８日付けで手続補正がなされたが，平成２２年８月９日付けで拒絶査定がされ，これに対し，平成２２年１１月１６日に審判請求がなされるとともに手続補正がなされ，平成２４年４月６日付けで審尋がなされ，これに対して平成２４年６月５日付けで回答書が提出されたものである。
　
２　補正の目的の適否についての判断
（１）平成２２年１１月１６日付けの手続補正（以下，「本件補正」という。）により，特許請求の範囲の請求項１の記載は，次のとおり補正された。
「ユーザ端末から指定されたサービスシナリオに基づいて，サービスコンポーネント提供装置によってサービスコンポーネントを連携した連携サービスを提供する際に，サービス連携装置によって前記サービスシナリオとのメタデータマッチングを行うことにより，前記サービスコンポーネントを発見するサービスコンポーネント発見システムであって，
　前記サービス連携装置は，
　前記サービスコンポーネントを検索する際に，前記サービスコンポーネントのプロセスメタデータ（Ｐｒｏｃｅｓｓ　Ｍｏｄｅｌ記述）とインタフェース情報（ＷＳＤＬ）と前記プロセスメタデータと前記インタフェース情報との対応関係を公開するマッピング情報を含むＧｒｏｕｎｄｉｎｇ記述とに基づいて，マッチングした前記サービスコンポーネントに対応するオペレーションが実装されているか否かを前記マッピング情報を含むＧｒｏｕｎｄｉｎｇ記述の参照により検証する検索検証手段を具備することを特徴とするサービスコンポーネント発見システム。」　
　
（２）本件補正は，平成２２年６月１８日付けの手続補正による特許請求の範囲の請求項１に記載された，「プロセスメタデータとインタフェース情報とマッピング情報に基づいて，マッチングした前記サービスコンポーネントに対応するオペレーションが実装されているか否かを検証する検索検証手段」を，「プロセスメタデータ（Ｐｒｏｃｅｓｓ　Ｍｏｄｅｌ記述）とインタフェース情報（ＷＳＤＬ）と前記プロセスメタデータと前記インタフェース情報との対応関係を公開するマッピング情報を含むＧｒｏｕｎｄｉｎｇ記述とに基づいて，マッチングした前記サービスコンポーネントに対応するオペレーションが実装されているか否かを前記マッピング情報を含むＧｒｏｕｎｄｉｎｇ記述の参照により検証する検索検証手段」とする補正を含むものであり，明りょうでない記載の釈明（拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る。）を目的とするものに該当し，平成１８年法律第５５号改正附則３条１項によりなお従前の例によるとされる同法による改正前の特許法１７条の２第４項に規定する要件を満たすものであり，適法な補正である。
　
３　本願発明について
（１）本願発明
　本願の請求項１に係る発明（以下「本願発明」という。）は，本件補正後の明細書，特許請求の範囲及び図面の記載からみて，上記２（１）の特許請求の範囲の請求項１に記載された事項により特定されるとおりのものである。
　
（２）引用例
ア　原査定の拒絶の理由に引用された，山登庸次他「ユビキタス環境で動的にサービス実現するためのサービス合成技術」，情報処理学会論文誌，社団法人情報処理学会，平成１９年２月１５日（発行日），第４８巻第２号，５６２頁〜５７７頁（以下，「引用例」という。）には，次の事項が記載されている。なお，同刊行物に記載された丸付き数字は，括弧付き数字で代替表記した。
　
・記載事項ａ
　「本研究は，サービス合成技術の研究であり，その特徴としてサービスフロー（本稿ではサービステンプレート：ＳＴと呼ぶ）を意味的メタデータを用いて抽象記述し，ユーザの利用時に状況・嗜好に応じて適切なサービスコンポーネント（本稿ではサービスエレメント：ＳＥと呼ぶ）を動的に発見し，バインドして実行することで，個人個人に適切なサービス提供することを目指している．なお，意味的メタデータとは，サービスコンポーネントがどのように動作するか，どのような性質を持つかなどを示すメタデータである．」（５６２頁左欄１４行〜右欄８行）
・記載事項ｂ
　「本研究の目的は，ユーザが，個人端末やサーバに搭載されたサービス合成エンジンを用いて，ユーザ状況に応じてＳＥを合成し，適切なサービスを利用可能にする技術の確立である．」（５６３頁左欄４行〜７行）
・記載事項ｃ
　「２．２意味的メタデータを用いたＳＴ，ＳＥ記述
　ＢＰＥＬの課題を解決するため，著者らはサービスフローであるＳＴに個々のＳＥのインタフェース名を記述するのではなく，欲する機能の意味的メタデータを用いて抽象的に記述し，インタフェース名は異なるが機能は同等なＳＥ群を発見し選択可能にすることで，状況に応じたサービスの実現を目指している（図１参照）．図１の，丸，四角，六角形は意味的に同等な機能，矢印は制御の順番を示す．ＢＰＥＬでは，１つ１つのＷＳを厳密に指定した制御フローを記述する必要があるが，ＳＴでは同等なＳＥから選択できる．
　・・・
　ここで，メタデータを用いてＳＴを記述して，サービス合成することを考えた場合，欲する機能にマッチするＳＥを数多く発見し利用できること（多くの候補により選択肢が増え，カスタマイズ性，耐障害性に優れる）が課題であり，以下の３つが必要となる．
●ＳＴ記述者が個々のＳＥの詳細実装を意識せず記述できるよう，統一的形式で記述が可能であること．
●既存コンポーネントをそのまま利用できるように，ＳＥの記述は標準または標準候補の記述を採用すること．
●メタデータの語彙定義を統一的に定めるのは困難であるため，語彙の違いを解決し，同等機能ならば利用可能であること（例：車とcarは両方利用可能）．
　・・・
　上記の３つの条件から，ＳＥ記述に近年進んできたSemantic Web Services技術・・・のＯＷＬ−Ｓ（Web Ontology Language for Services）を用いて設計，実装を行った．ＯＷＬ−Ｓは，３つの記述からなり，Profile記述はどのようなサービスを提供するかを記述し，Process記述はどのように動くかの抽象的Processの入出力や条件，効果を記述し，Grounding記述はどのようにアクセスするかの抽象Processと実際のオペレーションのマッピングを記述する．
　・・・
　このような理由から，ＳＥはＯＷＬ−Ｓをネットワークに公開することとし，それに対応してＳＴは以下のように記述する．ＳＴは利用するＳＥの機能を，カテゴリ名（同等ＳＥ機能をカテゴライズした単位）とオペレーションメタデータで指定し，指定した各カテゴリ間の情報引継ぎをあわせて記述する．ここで，オペレーションメタデータは，ＯＷＬ−ＳのProcessとそのパラメータにあたる．カテゴリ間の情報引継ぎには，前のカテゴリのパラメータを，別カテゴリのどのパラメータに入れるかのマッピングが記述される．
　ユーザがサービスを利用する際は，サービス合成する合成エンジンにＳＴを入力すると，合成エンジンが，ＳＴに記述されたメタデータを用いて同等なＳＥ群を検索し発見する．次に発見されたＳＥ群のProfileとユーザコンテキストを用いて点数付けをしてユーザ状況に適切なＳＥを選択する．利用するＳＥが決定された段階で，合成エンジンは，選択したＳＥのGrounding記述を用いてＳＥの実際のインタフェース（ＷＳＤＬやＵＰｎＰ）に変換して，ＳＥをバインド・実行する．図２は，メタデータから実際のオペレーションに変換する過程を示した図である．なお，同等機能でも異なる語彙で定義されたメタデータが振られている場合（例：車とcarなど）は，次節で提案するカテゴリツリーのリンクをたどり語彙変換することで同等機能として発見可能である。語彙変換により，代替候補ＳＥ数を増やし，発見の柔軟性を確保することができる．」（５６３頁右欄５行〜５６４頁右欄４行）
・記載事項ｄ
　「なお，ＳＴによるサービス合成は，実行時までＳＥが決まらないため以下の３つの不安要素がある．これらについて補足説明する．
（１）選択したＳＥが故障などで利用できない不安．
（２）選択したＳＥが必要な機能を持っていない不安．
（３）選択したＳＥがユーザにとって適切でない不安．
　まず，（１）に関しては，ＷＳなどの通常の分散システムでも同様の問題があり，故障の際は例外処理を行うが，基本的にはそのコンポーネントの利用は諦めるしかない．サービス合成も同様の考えで，エラーが返ってきたら，新しいＳＥを選択する形を想定している．
　次に，（２）に関しては，ＳＴに記述したAtomic Processと同等機能を実装しているＳＥを，メタデータ管理ＤＢとＳＥ−ＤＢを用いて検索するため，ＯＷＬリンクおよびＯＷＬ−Ｓ記述が正確であれば，この問題は防げる．問題は不整合がある場合だが，カテゴリどうしのＯＷＬ記述の不整合がある際は，マッピング機能などを用いて定期的にアップデートすることで整合をとる．また，ＳＥのＯＷＬ−Ｓ記述が不正の場合は，ＳＥ−ＤＢ管理者に不正登録として通知して削除してもらうか，あるいは，ＳＥ−ＤＢに登録する際にＳＯＡＰレイヤでの到達性をツールで確認してから登録させる方法が考えられる．」（５６９頁右欄４５行〜５７０頁左欄２１行）
　
イ　これらの記載から，引用例に記載された技術は，サービスフロー，すなわちサービステンプレートＳＴ（以下，「ＳＴ」と略す。）を意味的メタデータを用いて抽象記述し，ユーザの利用時に状況・嗜好に応じて適切なサービスコンポーネント，すなわちサービスエレメントＳＥ（以下，「ＳＥ」と略す。）を動的に発見し，バインドして実行することで，個人個人に適切なサービス提供するものであり（記載事項ａ），ユーザが，個人端末やサーバに搭載されたサービス合成エンジンを用いて，ユーザ状況に応じてＳＥを合成し，適切なサービスを利用可能にするための技術であることから（記載事項ｂ），「サービステンプレートＳＴ（サービスフロー）を意味的メタデータを用いて抽象記述し，ユーザの利用時に状況・嗜好に応じて適切なサービスエレメントＳＥ（サービスコンポーネント）を動的に発見し，バインドして実行するシステム」に係る技術ということができる。
　ＯＷＬ−Ｓ（Web Ontology Language for Services）は，どのようなサービスを提供するかを記述するProfile記述，どのように動くかの抽象的Processの入出力や条件，効果を記述するProcess記述，及びどのようにアクセスするかの抽象Processと実際のオペレーションのマッピングを記述するGrounding記述からなり，ＳＥ記述にＯＷＬ−Ｓを用いた場合，ＳＴは，利用するＳＥの機能を，同等ＳＥ機能をカテゴライズした単位であるカテゴリ名と，ＯＷＬ−ＳのProcessとそのパラメータにあたるオペレーションメタデータで指定するように記述するものであり，ユーザがサービスを利用するために合成エンジンにＳＴを入力すると，合成エンジンは，ＳＴに記述されたメタデータを用いて同等なＳＥ群を検索して発見し，発見されたＳＥ群のProfileとユーザコンテキストを用いてユーザ状況に適切なＳＥを選択し，選択したＳＥのGrounding記述を用いてＳＥの実際のインタフェースに変換して，ＳＥをバインド・実行する（記載事項ｃ）。
　
ウ　以上を総合すれば，引用例には以下の発明（以下，「引用発明」という。）が記載されていると認められる。
「サービステンプレートＳＴ（サービスフロー）を意味的メタデータを用いて抽象記述し，ユーザの利用時に状況・嗜好に応じて適切なサービスエレメントＳＥ（サービスコンポーネント）を動的に発見し，バインドして実行するシステムであって，
　ＯＷＬ−Ｓ（Web Ontology Language for Services）は，どのようなサービスを提供するかを記述するProfile記述，どのように動くかの抽象的Processの入出力や条件，効果を記述するProcess記述，及びどのようにアクセスするかの抽象Processと実際のオペレーションのマッピングを記述するGrounding記述からなり，
　ＳＥ記述にＯＷＬ−Ｓを用いた場合，ＳＴは，利用するＳＥの機能を，同等ＳＥ機能をカテゴライズした単位であるカテゴリ名と，ＯＷＬ−ＳのProcessとそのパラメータにあたるオペレーションメタデータで指定するように記述し，
　ユーザがサービスを利用するために合成エンジンにＳＴを入力すると，合成エンジンは，ＳＴに記述されたメタデータを用いて同等なＳＥ群を検索して発見し，発見されたＳＥ群のProfileとユーザコンテキストを用いてユーザ状況に適切なＳＥを選択し，選択したＳＥのGrounding記述を用いてＳＥの実際のインタフェースに変換して，ＳＥをバインド・実行する，
　システム。」
　
（３）対比
　本願発明と引用発明とを対比する。（なお，以下，「Profile」，「Process Model」，「Grounding」等は，原則として半角文字で表記する。）
ア　引用発明は，「サービステンプレートＳＴ（サービスフロー）を意味的メタデータを用いて抽象記述し，ユーザの利用時に状況・嗜好に応じて適切なサービスエレメントＳＥ（サービスコンポーネント）を動的に発見し，バインドして実行するシステム」に係るものであり，他方，本願発明は，「本発明は，ネットワーク上のサービス機能要素であるサービスコンポーネントを，サービスコンポーネントの機能種別を表すサービスカテゴリの接続関係を記述したサービスシナリオに基づいて，メタデータマッチングにより発見するサービスコンポーネント発見方法，サービスコンポーネント発見システム及びサービスコンポーネント発見プログラムに関する」ものであるから，両者は，いずれも「サービスコンポーネント発見システム」の技術分野に属するものである。
　
イ　引用発明における「サービステンプレートＳＴ（サービスフロー）」，「サービスエレメントＳＥ（サービスコンポーネント）」は，それぞれ本願発明における「サービスシナリオ」，「サービスコンポーネント」に相当する。
　また，引用発明のシステムにおける「合成エンジン」は，「ＳＴに記述されたメタデータを用いて同等なＳＥ群を検索して発見し，発見されたＳＥ群のProfileとユーザコンテキストを用いてユーザ状況に適切なＳＥを選択し，選択したＳＥのGrounding記述を用いてＳＥの実際のインタフェースに変換して，ＳＥをバインド・実行する」ものであり，その機能からみて，本願発明の「サービス連携装置」に相当する。
　これらのことから，本願発明と引用発明とは，「ユーザ端末から指定されたサービスシナリオに基づいて，サービスコンポーネント提供装置によってサービスコンポーネントを連携した連携サービスを提供する際に，サービス連携装置によって前記サービスシナリオとのメタデータマッチングを行うことにより，前記サービスコンポーネントを発見するサービスコンポーネント発見システム」である点で一致する。
　
ウ　引用発明のシステムは，ＳＥ記述に，どのようなサービスを提供するかを記述するProfile記述，どのように動くかの抽象的Processの入出力や条件，効果を記述するProcess記述，及びどのようにアクセスするかの抽象Processと実際のオペレーションのマッピングを記述するGrounding記述からなるＯＷＬ−Ｓを用いるものである。
　他方，本願発明における「サービス連携装置」は，「サービスコンポーネントを検索する際に，前記サービスコンポーネントのプロセスメタデータ（Process Model記述）とインタフェース情報（WSDL）と前記プロセスメタデータと前記インタフェース情報との対応関係を公開するマッピング情報を含むGrounding記述」を用いるものであり，明細書の記載を参照すれば，従来技術として，「他のメタデータマッチングによりサービスコンポーネントを発見するサービスコンポーネント発見技術としては，利便性を高める観点からサービスコンポーネントのメタデータの記述に，ＯＷＬ−Ｓ（Web Ontology Language for Services：例えば，非特許文献１参照）を適用しているものがある。ＯＷＬ−Ｓは，profile（プロファイル）と，process model（プロセスモデル）と，grounding（グランディング）との３つの記述からなる。」（【０００５】），「profile記述には，どのようなサービスを提供するかを記述し，process model記述には，どのように動くかの抽象的なプロセスの入出力，条件，効果等を記述し，grounding記述には，どのようにアクセスするかの，process mode1と実際のオペレーションのインタフェース情報とのマッピング情報を記述する。process model記述は，実際のオペレーションのメタデータ（プロセスメタデータ）として使われ，サービスシナリオ記述者は，サービスコンポーネントの詳細実装を意識せずにサービスシナリオが記述できるようになる。ＯＷＬ−Ｓは，ネットワーク上に公開される。」（【０００６】）と記載されており，本願発明の実施形態として記載された技術は，いずれもサービスコンポーネントの記述にＯＷＬ−Ｓを用いたものである。
　これらのことから，本願発明と引用発明とは，「サービス連携装置は，前記サービスコンポーネントのプロセスメタデータ（Process Model記述）とインタフェース情報（WSDL）と前記プロセスメタデータと前記インタフェース情報との対応関係を公開するマッピング情報を含むGrounding記述とに基づいて，サービスコンポーネントを検索する」ものである点で共通する。
　
エ　以上のことから，本願発明と引用発明との一致点及び相違点は，次のとおりである。
【一致点】
　ユーザ端末から指定されたサービスシナリオに基づいて，サービスコンポーネント提供装置によってサービスコンポーネントを連携した連携サービスを提供する際に，サービス連携装置によって前記サービスシナリオとのメタデータマッチングを行うことにより，前記サービスコンポーネントを発見するサービスコンポーネント発見システムであって，
　前記サービス連携装置は，
　前記サービスコンポーネントのプロセスメタデータ（Process Model記述）とインタフェース情報（WSDL）と前記プロセスメタデータと前記インタフェース情報との対応関係を公開するマッピング情報を含むGrounding記述とに基づいて，サービスコンポーネントを検索する，
　サービスコンポーネント発見システム。
【相違点】
　本願発明の「サービス連携装置」は，「サービスコンポーネントを検索する際に，サービスコンポーネントのプロセスメタデータ（Process Model記述）とインタフェース情報（WSDL）とプロセスメタデータとインタフェース情報との対応関係を公開するマッピング情報を含むGrounding記述とに基づいて，マッチングしたサービスコンポーネントに対応するオペレーションが実装されているか否かをマッピング情報を含むGrounding記述の参照により検証する検索検証手段を具備する」のに対し，引用発明の「サービス連携装置」は，サービスコンポーネントのプロセスメタデータ（Process Model記述）とインタフェース情報（WSDL）とプロセスメタデータとインタフェース情報との対応関係を公開するマッピング情報を含むGrounding記述とに基づいてサービスコンポーネントを検索するものの，本願発明の「マッチングしたサービスコンポーネントに対応するオペレーションが実装されているか否かをマッピング情報を含むGrounding記述の参照により検証する検索検証手段」に相当する構成を有しない点。
　
（４）判断
ア　本願発明は，上記相違点に係る発明特定事項の「検索検証手段」を備えたものであり，明細書の記載を参照すれば，従来技術のサービスコンポーネント発見技術では，サービスシナリオに基づいて，メタデータマッチングによりサービスコンポーネントを発見する際に，メタデータに対応するオペレーションが実際に実装されているかが保証されず，連携サービスの提供に支障をきたす可能性があるという課題があったことから（【０００８】【０００９】），この課題を解決するために，本願発明の第１実施形態においては，検索検証部が，サービスコンポーネント選択部から供給されるサービスコンポーネントについて，Grounding記述を参照し，オペレーションが実装されているか否かを検証し，実装されていない場合には，実装されていないことをサービスコンポーネント選択部に通知し（【００３７】【００４１】），オペレーショシが実装されていない場合には，そのサービスコンポーネントを除外してサービスコンポーネントを選択し，サービスコンポーネントの実行・連携を行うように構成し（【００３６】【００４２】），選択されたサービスコンポーネントがオペレーションを実際に実装していることを保証することができるようにしたものである（【００４３】）。
　すなわち，本願発明は，サービスコンポーネントを検索する際，オペレーションが実装されているか否かを検証する構成を備えたことにより，選択されたサービスコンポーネントがオペレーションを実際に実装していることを保証することができるというものである（【００４３】）。
　
イ　他方，引用例の記載事項ｄに，ＳＴによるサービス合成は，実行時までＳＥが決まらないため，選択したＳＥが故障等で利用できない，あるいは選択したＳＥが必要な機能を持っていないという不安要素があることから，サービス合成の際，ＳＥが利用できない場合は，新しいＳＥを選択することを想定していたこと，また，カテゴリ同士のＯＷＬ記述に不整合がある際は，マッピング機能を用いて定期的にアップデートすることにより整合をとることが記載されていることからして，引用発明において，ＳＥを検索する際に，ＳＥに対応するオペレーションが実際に実装されているかが保証されないという課題があったことは，当然に認識されていたということができる。
　
ウ　オペレーションが実際に実装されているかが保証されない，という課題を解決するために，オペレーションが実際に実装されているか否かを検証するための構成を設けることは，当業者であれば直ちに考えることであり，そのために，引用発明のＯＷＬ−Ｓ記述に含まれる，「どのようにアクセスするかの抽象Processと実際のオペレーションのマッピングを記述するGrounding記述」を参照する構成とすることは，当業者が容易に想到し得たことと認められる。
　そして，本願発明の奏する作用効果は，引用発明の奏する作用効果から予測される範囲内のものにすぎず，格別顕著なものということはできない。
　したがって，本願発明は，引用発明に基づいて，当業者が容易に発明をすることができたものである。
　
４　むすび
　以上のとおり，本願発明は，特許法２９条２項の規定により特許を受けることができないから，本願は，他の請求項について検討するまでもなく，拒絶すべきものである。
　よって，結論のとおり審決する。