【事件の表示】
　特願２００２−２５３６８８「サービス提供システム」拒絶査定不服審判事件〔平成１６年　３月２５日出願公開、特開２００４−　９４５０８〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は，平成１４年８月３０日の出願であって，平成１７年８月１６日付けで拒絶理由通知がなされ，同年１０月１９日付けで意見書の提出と共に手続補正がなされたが，平成１８年１０月６日付けで拒絶査定がなされ，これに対し，平成１８年１１月２４日付けで拒絶査定不服審判が請求され，同年１２月２２日付けで手続補正がなされたものである。
　 
２．平成１８年１２月２２日付けの補正について
　平成１８年１２月２２日付けの手続補正（以下，「本件補正」という。）により，特許請求の範囲は，次のとおりに補正された。
 「【請求項１】ネットワーク上に開設されている複数のサービスシステムが提供するサービス情報を取得しておき，利用者端末からの所望のサービス要求を受け付けて，前記所望のサービス要求に応じて，前記サービス情報に基づいて複数のサービスを組み合わせて組み合わせサービスを提供するサービス提供システムにおいて，
　前記複数のサービスの各々の内容と前記複数のサービスの各々の付加情報とをサービス情報としてサービス毎に記憶するサービスデータベースと，
　利用者端末からのサービス要求の内容を含むサービス要求情報を受け付け，前記サービス要求情報に基づいて前記サービスデータベースに記憶されている前記サービス情報を抽出し，前記サービス要求情報に対応する前記組み合わせサービスを構成するサービス作成部と，
　利用者端末から受け付けた評価基準に基づいて，作成された前記組み合わせサービスの順位付けを前記サービス要求に応じて行うサービス評価部と，
　前記サービス評価部でなされた順位付けされた前記組み合わせサービスの順位付け情報に基づいて，順位付け情報が下位に順序付けされた組み合わせサービスについては，上位に順序付けされた組み合わせサービスよりも，前記サービスデータベースに記憶されている前記組み合わせサービスを構成するサービス情報に含まれる前記付加情報を多く取得する付加情報取得手段と，
　前記サービス作成部で構成された前記組み合わせサービスと前記サービス評価部でなされた順位付けされた前記組み合わせサービスの順位付け情報と前記付加情報取得手段にて取得された前記付加情報とを，前記利用者端末に送信する送信部とを有することを特徴とするサービス提供システム。
【請求項２】請求項１に記載のサービス提供システムにおいて，前記送信部から前記利用者端末に出力された前記組み合わせサービスのいずれかを選択する旨の前記利用者端末からの応答に基づき前記組み合わせサービスを前記利用者端末が利用したかの有無を含む履歴情報を履歴記憶部に記憶し，または前記履歴記憶部に記憶された前記履歴情報を前記組み合わせサービスの個々のサービスシステムに通知し，前記通知した履歴情報に基づき前記個々のサービスシステムから送信されてきたサービス内容の変更を伴うサービス情報，または前記履歴記憶部に記憶されている履歴情報に基づき，前記サービス作成部で作成する組み合わせサービスを変更することを特徴とするサービス提供システム。
【請求項３】請求項１または請求項２に記載のサービス提供システムにおいて，前記送信部から利用者端末に出力された前記組み合わせサービスを前記利用者端末から選択する旨の選択信号を前記サービス提供システムが受信したときに，前記送信した組み合わせサービスを提供する個々の業者へ発注処理をすることを特徴とするサービス提供システム。
【請求項４】ネットワーク上に開設されている複数のサービスシステムが各々のサービスを提供するサービス群と前記サービス群のサービスを組み合わせる請求項１乃至請求項３に記載のいずれかのサービス提供システムであって，
　前記利用者端末によって選択された前記サービス作成部で構成された前記組み合わせサービスの個々のサービスの評価点を予め記憶されている一定の規則によって前記サービス作成部で算出し，該算出された評価点を前記個々のサービスを提供する個々の業者へ通知することを特徴とするサービス提供システム。
【請求項５】請求項１乃至請求項４に記載のサービス提供システムにおいて，
　前記サービス提供システムは，前記個々のサービスシステムからサービス情報または前記サービス情報に関わる情報を受信する際の前記サービスシステムからの応答のレスポンスの良否またはエラー頻度に応じて，前記サービス作成部において前記サービスシステムの評価点データを記憶する評価点記憶部を有することを特徴とするサービス提供システム。」 
　
　本件補正は，請求項１について，
「前記サービスデータベースに記憶されている前記組み合わせサービスを構成するサービス情報に含まれる前記付加情報を取得する付加情報取得手段」という事項を，
「
前記サービス評価部でなされた順位付けされた前記組み合わせサービスの順位付け情報に基づいて，順位付け情報が下位に順序付けされた組み合わせサービスについては，上位に順序付けされた組み合わせサービスよりも，
多く
　当該補正事項について，願書に最初に添付した明細書又は図面を参酌すると，同明細書の段落【００３３】に「さらにあるキーで順序付けされた複数の組み合わせサービスにおいて，順位に応じて表示できる情報量を変化させてもよい。たとえば下位に順序付けされた組み合わせサービスほど多くの付加情報を表示できるようにしておくと，順序付けされた上位の組み合わせサービスだけが単純に選択されることを防ぎ，利用者の要求から外れた組み合わせサービスであっても，利用者にとって有用な，あるいは，興味をひく付加情報のある下位組み合わせサービスが利用者に選択される機会が多くなり，ひいては利用者に選択されるサービスが分散しやすくなる。」ことや，同明細書の段落【００４３】に「さらに，画面表示の一例を示す図９のように，下位に順序づけられたチェーンほど多くの付加情報（ａａ１，ｂｂ２，ｃｃ２など）を表示することにより，利用者が明に要求していなかったが，興味の対象とする情報が見つけられる可能性が増え，図９ではＳ２などの下位のバリューチェーンにも商機が生まれる。」ことが記載され，特定の組み合わせサービスについて，順位に応じて表示できる付加情報の情報量を変化させることが記載されているが，特定の組み合わせサービスについて付加情報取得手段が付加情報を多く取得することにより，当該情報量の変化を実現することは何ら記載されておらず，同明細書又は図面の記載から自明のことでもない。したがって，当該補正事項を含む本件補正は，当初明細書等のすべての記載を総合することにより導かれる技術的事項との関係において，新たな技術的事項を導入するものである。
　
　以上のとおりであるから，本件補正は，平成１４年法律第２４号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第３項の規定に違反するので，同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
３．本願発明について
　上述のとおり，平成１８年１２月２２日付けの手続補正は上記のとおり却下されたので，本願の請求項１に係る発明（以下「本願発明」という。）は，平成１７年１０月１９日付けの手続補正書の特許請求の範囲の請求項１に記載された事項により特定される，次のとおりのものである。
　
「ネットワーク上に開設されている複数のサービスシステムが提供するサービス情報を取得しておき，利用者端末からの所望のサービス要求を受け付けて，前記所望のサービス要求に応じて，前記サービス情報に基づいて複数のサービスを組み合わせて組み合わせサービスを提供するサービス提供システムにおいて，
　前記複数のサービスの各々の内容と前記複数のサービスの各々の付加情報とをサービス情報としてサービス毎に記憶するサービスデータベースと，
　利用者端末からのサービス要求の内容を含むサービス要求情報を受け付け，前記サービス要求に応じるために前記サービスデータベースに記憶されている前記サービス情報を組み合わせて，前記サービス要求に応じる前記組み合わせサービスを構成するサービス作成部と，
　構成された前記組み合わせサービスの順位付けを前記サービス要求に応じて行うサービス評価部と，
　前記サービスデータベースに記憶されている前記組み合わせサービスを構成するサービス情報に含まれる前記付加情報を取得する付加情報取得手段と，
　前記サービス作成部で構成された前記組み合わせサービスと前記サービス評価部でなされた順位付けされた前記組み合わせサービスの順位付け情報と前記組み合わせサービスの順位付け情報に応じて選択された前記付加情報とを，前記利用者端末に送信する送信部とを有することを特徴とするサービス提供システム。」
　
４．原査定の拒絶の理由について
　
　原査定の平成１７年８月１６日付けの拒絶理由通知書により通知した拒絶の理由Ｃの概要は，以下のとおりである。　
『Ｃ．この出願の下記の請求項に係る発明は，その出願前日本国内又は外国において頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて，その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
　　　　　記　　　（引用文献等については引用文献等一覧参照）
請求項１乃至５
引用文献１乃至５
　引用文献１には，組合せサービスを構成するサービス提供システムが記載されている。
　引用文献２，３には，複数のサービスを評価情報等と共に表示し，サービスを選択する点が記載されている。また，利用履歴情報によってサービスの内容を変更する技術は，引用文献４，５に例示するように周知の技術である。
　引用文献１乃至５より本願発明とすることは容易になしうるものである。
　
　　　　　　　　　　　引　用　文　献　等　一　覧
１．インターネットサービス連携システムにおけるサービスレベルを考慮した運用管理方法，情報処理学会研究報告，社団法人情報処理学会，２００１年１１月３０日，第２００１巻第１１９号，７〜１２頁
２．特開２００２−１６３３３７号公報
３．特開２００２−２３６７３６号公報
４．特開２００１−２７３４２０号公報
５．特開２００２−４９８１５号公報』
　
　また，平成１８年１０月６日付けの拒絶査定により示された拒絶の理由の概要は，以下のとおりである。
　『この出願については，平成１７年　８月１６日付け拒絶理由通知書に記載した理由Ａ，Ｃによって，拒絶をすべきものである。
　なお，意見書並びに手続補正書の内容を検討したが，拒絶理由を覆すに足りる根拠が見いだせない。
　
備考
（中略）
（理由Ｃについて）
　出願人は意見書にて『引用文献１：「インターネットサービス連携システムにおけるサービスレベルを考慮した運用管理方法」は，サービス連携システムにおいて，インターネット上のサービスフローの制御やサイトの新規参入など動的な変化に対応する技術に関するものであります。
　しかしながら，本願発明が着目した「価格競争力の無いサービス業者は脱落してしまい，ＷＥＢサービス市場では，一部の業者の独占状態が発生する可能性がある。この様な状態が生じる可能性があると，小規模なサービス業者の参入が難しいばかりではなく，サービスの利用者にとっても選択の余地のないサービスがなされることになる。」との問題点の指摘，またはその示唆もなく，さらに，「前記組み合わせサービスの順位付け情報に応じ選択された前記付加情報とを，前記利用者端末に送信する前記利用者端末に送信する送信部」との構成については，記載及び示唆はありません。』と主張している。
　検討するに，引用文献１は，「条件に対して，複数のサービス候補を検索することが可能である。」，「シナリオ実行の管理シナリオには利用するＳＴが定義されている。同一のＳＴに属する個別ＳＰは複数存在し，連携サービス実行時に個別ＳＰを動的に選択する。」（第１０頁参照）と記載されていることから，要求に対して，複数のサービス組合せを作成可能であることは，容易に着想可能である。一方，引用文献２，３に示すように，複数のサービスを順位付けて表示することは周知の技術であり，また，引用文献２（第３４，３５段落，図８等参照）には，サービスのリストともに，該サービスの付加情報を提供する技術が記載されているものである。
　よって，引用文献１記載のシステムに，引用文献２，３の技術を採用して，組み合わせサービスと順位付け情報と前記組み合わせサービスの付加情報とを，利用者端末に送信する構成を着想することは，容易になしうることにすぎない。そして，付加情報を「サービスの順位付け情報に応じて選択」する点については記載されていないが，請求項の記載からでは，願望的な漠然とした機能を特定しているにすぎずないものであるから，この点については設計事項にすぎないものである（「サービスの順位付け情報に応じて選択」をするための，技術的な事項（コンピュータのハードウエア資源を用いた具体的な情報処理）が記載されているものでなく，付加情報を選択する方法を取り決めた程度の記載にすぎないことから，このような漠然とした機能を設けることは，設計事項にすぎないものである。）。
　なお，引用文献１に引用文献２，３の技術を採用して，順位付け情報，付加情報，サービス組合せを提示し，該提示された情報からユーザが希望するサービスの組合せを選択するシステムとすれば，出願人が主張する『一部の業者の独占状態が発生する可能性がある。この様な状態が生じる可能性があると，小規模なサービス業者の参入が難しいばかりではなく，サービスの利用者にとっても選択の余地のないサービスがなされることになる。』という問題が解決できるものとなることは予測できる程度のことであるから，問題点の相違については特段のものではない。
　よって，本願請求項１−５は，依然として先に提示した引用文献より容易に発明をすることができたものである。』
　
５．当審の判断
５−１．引用例について
（１）引用例１について
　原査定の拒絶理由通知で引用した「インターネットサービス連携システムにおけるサービスレベルを考慮した運用管理方法，情報処理学会研究報告，社団法人情報処理学会，２００１年１１月３０日，第２００１巻第１１９号，７〜１２頁」（以下「引用例１」という。）には，図面とともに以下のことが記載されている。
　
（ア）「複数サービスを連携し，新たなサービスを生み出すというような差異化要素が必要となる。具体例として，フライトの予約，ゴルフ場の予約，ホテルの予約というサービスを一連の処理で行うことで，ひとつの旅行サービスが提供できる。このように，Ｗｅｂサービス等を組み合わせて新たなサービスを創り出す仕組みを，筆者らはサービス連携［１］と呼ぶことにする。このサービス連携を実現するには，サービスのフローを制御する仕組みや，インターネット上のサービスを検索する技術が必要となる。」第８頁左欄第２４〜３４行
　
（イ）「２．サービス連携の概要
　本章では，サービス連携の概念を説明し，さらにサービス連携システムの実現のための要件について述べる。
２．１サービス連携とは
サービス連携においては，図１に示すように”サービス利用者”，”連携サービスプロバイダ（ＣＳＰ）”，”個別サービスプロバイダ（ＩＳＰ）”の３つの立場に分類できる。以下，それぞれの立場について説明する。
○サービス利用者
　連携サービスプロバイダが提供するサービスの利用者である。連携サービスプロバイダを使うメリットとして，利用者自身が個別サービスの所在やサービス内容を把握している必要が無く，連携サービスプロバイダが仲介役としてサービスの検索や予約処理などを行った結果をサービスとして受けられる点があげられる。
○連携サービスプロバイダ
　サービス利用者の希望条件を収集し，実際のサービスのブローカリング（検索など）および実際のサービスのアクセス（実行依頼）を仲介する。従来のサービス提供者を募って作成されたポータルサイトと異なる点は，ＵＤＤＩ［２］／ＳＯＡＰ［３］／ｅｂＸＭＬ［４］といったＷｅｂサービスを実現する仕様に準拠した個別サービスプロバイダに対し，逐次システムを接続することを可能としている点である。この特徴により，利用者は希望条件に最も近いサービスを享受することが可能となる。（中略）（以下，連携サービスプロバイダを簡単のため，連携ＳＰ又はＣＳＰと記述する。）
○個別サービスプロバイダ
　主にインターネット上でサービスを提供するプロバイダを想定している。従来，Ｗｅｂページによりサービスを提供して来たプロバイダは，Ｗｅｂサービスに対応したインタフェースをＷｅｂページと同様に準備することで，個別サービスプロバイダとなることが可能となる。（中略）（以下，個別サービスプロバイダを簡単のため，個別ＳＰまたはＩＳＰと記述する。）（中略）ここで示した，サービス連携システムのモデルでは，複数の独立したシステムが疎結合によりサービスを提供することになる。」第８頁左欄第４５行〜右欄第３８行
　
（ウ）「サービス連携を実現するための構成要素を図２に示す。図中の各用語は，以下のように定義する。
連携サービスプロバイダ（連携ＳＰ）：サービス連携システムのポータルとして，利用者からの要求を受け付け，連携サービスを提供するサーピスプロバイダ。
個別サービスプロバイダ（個別ＳＰ）：ネット上に分散し，個々にサービスを提供するサービスプロバイダ。
シナリオ：連携サービスを構成するサービスの組合せおよび実行順序の定義。
シナリオインスタンス：利用者の要求ごとに，シナリオから作成される連携サービスの実体。
サービス連携エンジン：利用者の要求に従い，シナリオからシナリオインスタンスを作成し，連携サービスの実行を制御する。
サービスタイプ（ＳＴ）：航空機予約やホテル予約など，サービスの種類でまとめた個別ＳＰのグループ。
サービスブローカリング／アクセス部：サービス連携のための基本的な機能を提供する。主に以下の構成要素からなる。
個別ＳＰリポジトリ：個別ＳＰが提供するサービスやそのサービスタイプを格納したデータベース。
サービス仲介部：サービス連携エンジンからの要求に従い，個別ＳＰリポジトリからの個別ＳＰの検索およびサービスの実行を行う。
サービスアクセス部：連携ＳＰと個別ＳＰとの通信を行う。ルーティングやセキュリティ機能を提供する。」第９頁左欄第６〜３７行
　
（エ）「３．１．２シナリオ実行の管理
　シナリオには利用するＳＴが定義されている。同一のＳＴに属する個別ＳＰは複数存在し，連携サービス実行時に個別ＳＰを動的に選択する。そのため，同一シナリオでも実行条件により連携する個別ＳＰが異なる。したがって，個別ＳＰの可用性・性能情報を用いて，個々の連携サービスの可用性・性能を監視し，必要に応じて個別ＳＰの選択および再選択や実行中止などの制御を行う必要がある。
（中略）
３．２運用管理の要件
（中略）
（２）状態監視：個別ＳＰの稼動・非稼動の監視のために定期的なポーリングおよび非同期なイベントの受信を行う。また，実際の連携サービスおよび個別ＳＰの性能を測定する。
（３）障害・性能分析：シナリオおよび実行中の連携サービスごとに個別ＳＰ障害の影響を分析する。また，シナリオ実行と個別ＳＰの応答時間の関係を統計的に分析し，シナリオ実行の所要時間を推定する。
（中略）
３．３実現方式
（３）障害・性能分析
（ａ）個別ＳＰ障害の影響分析：構成情報および監視情報を用いて，シナリオおよび実行中のシナリオインスタンスヘの影響を分析する。分析項目および判断基準を表３に示す。（ｂ）性能分析：連携サービスおよび個別ＳＰの応答時間を統計手法により解析し，予め決められた時間内にサービスを終了することが可能な個別ＳＰを選択するなどに用いる。」第１０頁右欄第２１行〜第１１頁左欄
　
　上記摘記事項（ア）乃至（エ）によれば，引用例１には，以下の発明（以下「引用例１発明」という。）が開示されている。
　
「複数サービスを連携し，新たなサービスを生み出すことが必要であり，具体例として，フライトの予約，ゴルフ場の予約，ホテルの予約というサービスを一連の処理で行うことで，ひとつの旅行サービスが提供できるのであって，このように，Ｗｅｂサービス等を組み合わせて新たなサービスを創り出す仕組みを，サービス連携と呼ぶことにし，このサービス連携を実現するには，サービスのフローを制御する仕組みや，インターネット上のサービスを検索する技術が必要となること，
　サービス連携においては，”サービス利用者”，”連携サービスプロバイダ（ＣＳＰ）”，”個別サービスプロバイダ（ＩＳＰ）”の３つの立場があること，サービス利用者は，連携サービスプロバイダが提供するサービスの利用者であり，連携サービスプロバイダは，サービス利用者の希望条件を収集し，実際のサービスのブローカリング（検索など）および実際のサービスのアクセス（実行依頼）を仲介し，個別サービスプロバイダは，主にインターネット上でサービスを提供するプロバイダを想定していること，
　また，連携サービスプロバイダ（連携ＳＰ）は，サービス連携システムのポータルとして，利用者からの要求を受け付け，連携サービスを提供するサーピスプロバイダであり，個別サービスプロバイダ（個別ＳＰ）は，ネット上に分散し，個々にサービスを提供するサービスプロバイダであること，
　サービスブローカリング／アクセス部が，サービス連携のための基本的な機能を提供するものであり，主に，個別ＳＰリポジトリとサービス仲介部の構成要素からなり，個別ＳＰリポジトリが，個別ＳＰが提供するサービスやそのサービスタイプを格納したデータベースであり，サービス仲介部が，サービス連携エンジンからの要求に従い，個別ＳＰリポジトリからの個別ＳＰの検索およびサービスの実行を行うこと，
　また，サービス連携エンジンとは，利用者の要求に従い，シナリオからシナリオインスタンスを作成し，連携サービスの実行を制御することであり，ここで，シナリオとは，連携サービスを構成するサービスの組合せおよび実行順序の定義であって，シナリオインスタンスとは，利用者の要求ごとに，シナリオから作成される連携サービスの実体であること，
　個別ＳＰの可用性・性能情報を用いて，個々の連携サービスの可用性・性能を監視し，必要に応じて個別ＳＰの選択および再選択や実行中止などの制御を行う必要があるために，運用管理の要件の実現方式として，性能分析を行うこと，その内容としては，連携サービスおよび個別ＳＰの応答時間を統計手法により解析し，予め決められた時間内にサービスを終了することが可能な個別ＳＰを選択するなどに用いること，
　サービス利用者が，サービスの検索や予約処理などを行った結果をサービスとして受けられること。」
　
（２）引用例２について
　原査定の拒絶理由通知で引用した「特開２００２−１６３３３７号公報」（以下「引用例２」という。）には，図面とともに以下のことが記載されている。
　
（オ）「【０００１】
【発明の属する技術分野】
　本発明は，国際輸送サービス選択システムに係り，特に，荷送人が適切な国際輸送サービスを選択できる国際輸送サービス選択システムに関する。
（中略）
【００３３】図８は，輸送サービスデータの一覧の例を示す説明図である。図８に示す例では，日本国からアメリカ国への輸出で，神奈川県藤沢市内を集荷地として，カリフォルニア州内を配達地とする輸送サービスの一覧であり，図５に示すアメリカ西海岸ゾーン（USA-A2）に属する輸送サービスの一覧である。この図８に示す輸送サービスデータは，図１に示す輸送サービスＤＢ４に登録されている。運賃，所要日数，付加価値及びコメントは各提供者によって登録される。
【００３４】（中略）一方，提供者は，輸出先毎に強み，弱みがある。例えば，提供者又はその輸送サービスは，カリフォルニア州には自社での倉庫があるとか，ドイツ国に提携している物流センターがあるとか，食品の輸出入の取り扱いに長けているとか，荷物に関する機密保持契約を締結し秘密を保持した状態で輸送できるなどの特徴を有する。これらの特徴を荷送人に伝達するために，図８に示す例では，輸送サービスの付加価値と，荷送人から見たメリット等を輸送サービスの特徴として輸送サービスデータに含めている。この付加価値を運賃等と共に比較検討することで，荷送人は多数の国際輸送サービスから最適な輸送サービスを選択することができる。また，提供者側にとっても，付加価値等の欄を用いて，自らのサービスの運賃設定の理由を荷送人に伝達することができる。
（中略）
【００３７】また，図８に示すように，輸送サービスＤＢが，前記輸送サービスの特徴として前記国際輸送サービスの付加価値サービスデータを記憶する例では，国際輸送サービス情報抽出部が，前記荷送人端末の操作に応じて前記付加価値サービスをキーとして当該国際輸送サービスを並べ替えるソート機能１４Ｅを備えると良い。
（中略）
【００４２】（中略）輸送サービスデータを含む輸送サービス選択ページ６Ｃの例を図１１に示す。ここでは，ソート機能１４Ｅにより，図１０にて入力した精密機器の取り扱い実績が多いＡ社のサービスを先頭に位置づけた。荷送人は，「精密機器実績多」であるＡ社のサービスを，他の輸送サービスよりも高価であるにもかかわらず選択する（ステップＳ６）（以下，略）」明細書段落【０００１】〜【００６６】
　
　上記摘記事項（オ）によれば，引用例２には，以下の発明（以下「引用例２発明」という。）が開示されている。
　「サービスの選択システムにおいて，サービスの付加価値を記憶した輸送サービスＤＢと，当該輸送サービスＤＢに記憶されている付加価値を取得する国際輸送サービス情報抽出部と，当該付加価値を輸送サービスデータを含む輸送サービス選択ページに送信する手段とを有する国際輸送サービス選択システム。」
　
（３）引用例３について
　原査定の拒絶理由通知で引用した「特開２００２−２３６７３６号公報」（以下「引用例３」という。）には，図面とともに以下のことが記載されている。
　
（カ）「【０００１】
【発明の属する技術分野】
　本発明は，ビル等の群管理サービス支援方法及び支援装置に係り，特に，オフィスやマンションなどの複数のビルに対して設備や建物を統合的に管理するのに好適な，ビル等の群管理サービス支援方法及び支援システムに関する。
（中略）
【００２２】（中略）まず，管理者装置は端末事業者との間で，サービス評価処理（７０１）を実施する。これは事業者端末の過去のサービス内容を評価する手続きである。つぎに，管理者装置と所有者端末との間で，７０１の評価結果に基づいて保守プランの提案及び保守プラン選定処理（７０２）が行われる。管理者装置はコスト，工期，品質な，サービス等種々の観点で作成されたすべての保守プランを所有者端末に提示し，その中から所有者端末が希望条件にあった保守プランの選択をする。
（中略）
【００２７】シーケンス２０１は，管理者装置が保守事業者の初期評価をするシーケンスで，５０４の記録を参照して，保守事業者のサービスの格付けを行なう。たとえばサービスを幾つかのランクに分けて，分類した結果はシステムにより保守事業者の評価ファイル（５０５）のサービス評価の項目として記録される。
【００２８】シーケンス２０２では，管理者装置が，保守事業者の初期組み合わせを決定する。これは２０１の評価結果から各保守事業者のサービスの特性を把握し，特性別にいくつかの保守プランを考え，その保守プランを構成するのに最適な保守事業者の初期の組み合わせを決定する。この決定結果は，システムにより保守事業者の組み合わせファイル（５０６）の保守プランの項目として記録される。このプランの例として，コストを重視したプラン，性能を重視したプラン，すべてに平均的なプランなどを管理者装置は用意する。
【００２９】シーケンス２０３では，管理者装置が所有者端末に，保守プランを提示する。ここではシステムにより５０６の保守プランが示される。
【００３０】シーケンス３０１では，所有者端末が，保守プランの選択をする。（以下，略）」明細書段落【０００１】〜【００６５】
　
　上記摘記事項（カ）によれば，引用例３には，以下の発明（以下「引用例３発明」という。）が開示されている。
　「保守プランの選択のためのサービスの支援システムにおいて，保守事業者を組み合わせた保守プランの最適なプランの選択を要求が見込まれるプラン毎に応じて行う群管理サービス支援システム。」
　
５−２．対比
　本願発明と，上記引用例１発明とを比較する。
　
（１）引用例１発明において，「サービス連携システムの実現のため」の一つの要件である「連携サービスプロバイダ」は，「ネット上に分散し，個々にサービスを提供」している「個別サービスプロバイダ」が提供する「実際のサービス」を「利用者からの要求を受け付け」て「サービス利用者の希望条件を収集」することに応じて，「ブローカリング（検索など）および実際のサービスのアクセス（実行依頼）を仲介」するのであり，第１図及び第２図より，「ネット」とは，インターネットのことであって，「利用者からの要求」は，利用者端末によりなされていると考えるのが自然である。また，第２図より，「連携サービスプロバイダ」に含まれる「サービスブローカリング／アクセス部」に「個別ＳＰが提供するサービスやそのサービスタイプを格納したデータベース」である「個別ＳＰリポジトリ」が構成されていることから，「連携サービスプロバイダ」が「利用者からの要求を受け付け」に先だって，「個別ＳＰが提供するサービスやそのサービスタイプ」を取得しておくと考えるのが自然である。さらに，「連携サービスプロバイダ」が仲介するのは，「利用者からの要求を受け付け，連携サービスを提供する」ことにより，「複数サービスを連携し，新たなサービスを生み出す」ことと記載されている。よって，引用例１発明と本願発明とは，「インターネット上に開設されている複数の個別サービスプロバイダのシステムが提供するサービスの情報を取得しておき，利用者端末からの所望のサービス要求を受け付けて，前記所望のサービス要求に応じて，前記サービスの情報に基づいて複数のサービスを組み合わせて連携サービスを提供するサービス連携システムにおいて，前記複数のサービスの各々の情報をサービスの情報としてサービス毎に記憶するデータベースと，を有することを特徴とするサービス連携システム。」である点で共通する。
　
（２）引用例１発明において，「連携サービスプロバイダ」に含まれる「サービスブローカリング／アクセス部」に，「個別ＳＰが提供するサービスやそのサービスタイプを格納したデータベース」である「個別ＳＰリポジトリ」と，「利用者の要求に従い，シナリオ（連携サービスを構成するサービスの組合せおよび実行順序の定義）からシナリオインスタンス（連携サービスの実体）を作成し，連携サービスの実行を制御」する「サービス連携エンジン」からの要求に従い，「個別ＳＰリポジトリからの個別ＳＰの検索およびサービスの実行」を行う「サービス仲介部」が構成されていることから，引用例１発明と本願発明とは，「利用者端末からのサービス要求の内容を含むサービス要求情報を受け付け，前記サービス要求に応じるために前記データベースに記憶されている前記サービスの情報を組み合わせて，前記サービス要求に応じる前記連携サービスを構成するサービス連携エンジンとサービス仲介部」を有している点で共通する。
　
（３）引用例１発明のサービス連携システムは，運用管理の目的で，「連携サービスおよび個別ＳＰの応答時間を統計手法により解析し，予め決められた時間内にサービスを終了することが可能な個別ＳＰを選択する」という性能分析の機能を備えていること，当該性能分析は，第６図より，「連携サービスプロバイダ」の「運用管理モジュール」で行われるのであり，さらに，「連携サービス」は，利用者の要求に従って「サービス連携エンジン」で作成されるのであるから，引用例１発明と本願発明とは，「構成された前記連携サービスの評価を前記サービス要求に応じて行う運用管理モジュール」を有している点で共通する。
　
（４）引用例１発明において，サービス利用者は，「サービスの検索や予約処理などを行った結果をサービスとして受けられる」のであり，第１図及び第２図より，利用者は，利用者端末を用いるのであるから，当該検索の結果を利用者端末に表示させるための送信部が備えられていると考えるのが自然である。そうすると，引用例１発明と本願発明とは，「前記サービス作成部で構成された前記組み合わせサービスを，前記利用者端末に送信する送信部」を有している点で共通する。
　
　ここで，これら引用例１発明の「インターネット」，「個別サービスプロバイダのシステム」，「連携サービス」，「サービス連携エンジンとサービス仲介部」は，それぞれ本願発明の「ネットワーク」，「サービスシステム」，「組み合わせサービス」，「サービス作成部」にそれぞれ対応している。
　また，これら引用例１発明の「サービスの情報」，「データベース」，「運用管理モジュール」「サービス連携システム」は，以下の相違点があるものの，それぞれ本願発明の「サービス情報」，「サービスデータベース」，「サービス評価部」，「サービス提供システム」と共通した機能を備えている点で，それぞれ対応している。
　
　以上のとおりであることから，引用例１発明と本願発明とは，
　
「ネットワーク上に開設されている複数のサービスシステムが提供するサービス情報を取得しておき，利用者端末からの所望のサービス要求を受け付けて，前記所望のサービス要求に応じて，前記サービス情報に基づいて複数のサービスを組み合わせて組み合わせサービスを提供するサービス連携システムにおいて，
　前記複数のサービスの各々の情報をサービス情報としてサービス毎に記憶するサービスデータベースと，
　利用者端末からのサービス要求の内容を含むサービス要求情報を受け付け，前記サービス要求に応じるために前記サービスデータベースに記憶されている前記サービス情報を組み合わせて，前記サービス要求に応じる前記組み合わせサービスを構成するサービス作成部と，
　構成された前記組み合わせサービスの評価を前記サービス要求に応じて行うサービス評価部と，
　前記サービスデータベースに記憶されている前記組み合わせサービスを構成するサービス情報に含まれる前記付加情報を取得する付加情報取得手段と，
　前記サービス作成部で構成された前記組み合わせサービスを，前記利用者端末に送信する送信部とを有することを特徴とするサービス提供システム。」
　
である点で一致し，以下の点で相違する。
　
［相違点１］
　本願発明の「サービスデータベース」に記憶する「サービス情報」が「前記複数のサービスの各々の内容と前記複数のサービスの各々の付加情報」であって，本願発明が「前記サービスデータベースに記憶されている前記組み合わせサービスを構成するサービス情報に含まれる前記付加情報を取得する付加情報取得手段」を有すると共に，「送信部」が，「前記付加情報」を送信しているのに対し，引用例１発明の「サービス情報」には，「前記複数のサービスの各々の情報」であるものの，「前記複数のサービスの各々の付加情報」が含まれておらず，引用例１発明には，「前記サービスデータベースに記憶されている前記組み合わせサービスを構成するサービス情報に含まれる前記付加情報を取得する付加情報取得手段」を有しておらず，「送信部」が，「前記付加情報」を送信していない点。
　
［相違点２］
　本願発明の「サービス評価部」が，組み合わせサービスの「順位付け」を行っており，「送信部」が「前記サービス評価部でなされた順位付けされた前記組み合わせサービスの順位付け情報」を送信すると共に，送信する「付加情報」が「前記組み合わせサービスの順位付け情報に応じて選択された」ものであるのに対して，引用例１発明では，性能分析を行うことで組み合わせサービスの評価をしているものの，「順位付け」を行うことが記載されておらず，送信部もそのような機能を有していない点。
　
５−３．判断
［相違点１］について。
　引用例２発明は，サービスの選択システムに関する発明であって，サービスの付加価値を記憶した輸送サービスＤＢと，当該輸送サービスＤＢに記憶されている付加価値を取得する国際輸送サービス情報抽出部と，当該付加価値を輸送サービスデータを含む輸送サービス選択ページに送信する手段とにより，引用例２段落【００４２】に記載されているように，サービスの選択に際して，サービス情報の内容に関する情報と共に，付加情報を利用者に提供することにより，価格等によらない選択を可能とする発明であり，サービスの選択システムの設計に際して，利用者の選択の幅を広げたり，選択を容易とすることは，当業者が通常考慮することであるので，引用例１発明のサービス提供システムに，公知の引用例２発明を組み合わせることが当業者にとって格別な技術力を要するものとは認められない。
　すなわち，引用例１発明の「サービス情報」に「前記複数のサービスの各々の付加情報」を含ませ，「前記サービスデータベースに記憶されている前記組み合わせサービスを構成するサービス情報に含まれる前記付加情報を取得する付加情報取得手段」を構成し，「送信部」を「前記付加情報」を送信するよう構成することは，当業者が容易に想到することができたものである。
　
［相違点２］について
　引用例１発明では，５−２．（３）や，上記摘記事項（エ）に示したとおり，予め決められた時間内にサービスを終了することが可能な個別ＳＰを選択するなどに用いるために，連携サービスの応答時間を解析しているので，各連携サービスの応答時間を計算することが開示されている。引用例３発明には，引用例１発明と同様のサービスの選択を行うシステムの技術分野において，サービスの組み合わせである保守プランの選択を支援するために，保守プランの最適なプランの選択を要求が見込まれるプラン毎に応じて行っているので，引用例１発明の連携サービスの性能分析の評価をする際に，引用例３発明に開示された順位付けによる最適な連携サービスを選択するよう構成することは，当該技術分野の当業者にとって容易である。さらに，引用例１発明においては，利用者のサービス要求を検索した結果の連携サービスを利用者が受け取るのであるから，利用者端末に送信された連携サービスを参照するために，利用者端末に連携サービスが何らかの形式で表示されていることが示唆されており，何らかの基準で順位付けした検索結果の表示において，利用者にとってニーズの高いと想定される順位で表示することは，システムの設計に際して当業者が通常考慮する周知の事項であり，順位付けに応じて付加情報の内容を選択することも，例えば，伊藤  智洋，発表２００１年下半期ネット証券総合ランキング，日経ネットトレーディング  ２００１年  Ｖｏｌ．６  第８巻  第１８号，日経ＢＰ社，２００１年１２月１５日，ｐ．９４−９５（以下，「周知例１」という。）に，順位で上位５社については点数と共にコメントを掲載し，６位以下については点数のみを掲載しているように，順位の表示においては一般的になされている周知の事項であり，また，システム上の表示においても，例えば，特開２００１−２１６２４４号公報（以下，「周知例２」という。）の段落【０１２３】−【０１２６】及び第１０図に，検索条件に完全に一致する結果についてはメッセージを表示せず，代替候補の結果についてはメッセージを表示することや，特開２００１−２６５８１１号公報（以下，「周知例３」という。）段落【００５３】及び第１７図に，信頼度の低い順位の検索結果のみに参考となるイメージを表示することが記載されていることなど，コンピュータシステムにおける表示の際に，順位に応じて付加情報の内容を選択することは当業者に周知の技術であり，どのような内容を選択するかは，検索の目的や表示の対象に応じて当業者が適宜選択し得ることである。
　したがって，引用例１発明において，「サービス評価部」に，組み合わせサービスの「順位付け」を行わせ，「送信部」を「前記サービス評価部でなされた順位付けされた前記組み合わせサービスの順位付け情報」を送信させるよう構成すると共に，送信する「付加情報」を「前記組み合わせサービスの順位付け情報に応じて選択された」ものとすることは，当業者が容易に想到することができたものである。
　
　以上判断したとおり，本願発明における上記［相違点１］乃至［相違点２］に係る発明特定事項は，いずれも当業者が容易に想到することができたものであり，上記各相違点を総合しても，想到することが困難な格別の事項は見いだせない。
　また，本願発明の作用効果も，各引用例１〜３発明及び各周知の事項から当業者が予測できる範囲のものである。
　
５−４．まとめ
　
　したがって，本願発明は，上記引用例１〜３発明及び各周知の事項に基づいて，当業者が容易に発明をすることができたものである。
　
６．むすび
　以上のとおり，本願発明は，各引用例１〜３発明及び周知の事項に基づいて，当業者が容易に発明をすることができたものであり，特許法第２９条第２項の規定により特許を受けることができない。
　
　よって，結論のとおり審決する。