• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない。 G06Q
審判 査定不服 特17条の2、3項新規事項追加の補正 特許、登録しない。 G06Q
管理番号 1208582
審判番号 不服2006-26388  
総通号数 122 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2010-02-26 
種別 拒絶査定不服の審決 
審判請求日 2006-11-24 
確定日 2009-12-10 
事件の表示 特願2002-253688「サービス提供システム」拒絶査定不服審判事件〔平成16年 3月25日出願公開、特開2004- 94508〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 1.手続の経緯
本願は,平成14年8月30日の出願であって,平成17年8月16日付けで拒絶理由通知がなされ,同年10月19日付けで意見書の提出と共に手続補正がなされたが,平成18年10月6日付けで拒絶査定がなされ,これに対し,平成18年11月24日付けで拒絶査定不服審判が請求され,同年12月22日付けで手続補正がなされたものである。

2.平成18年12月22日付けの補正について
平成18年12月22日付けの手続補正(以下,「本件補正」という。)により,特許請求の範囲は,次のとおりに補正された。
「【請求項1】ネットワーク上に開設されている複数のサービスシステムが提供するサービス情報を取得しておき,利用者端末からの所望のサービス要求を受け付けて,前記所望のサービス要求に応じて,前記サービス情報に基づいて複数のサービスを組み合わせて組み合わせサービスを提供するサービス提供システムにおいて,
前記複数のサービスの各々の内容と前記複数のサービスの各々の付加情報とをサービス情報としてサービス毎に記憶するサービスデータベースと,
利用者端末からのサービス要求の内容を含むサービス要求情報を受け付け,前記サービス要求情報に基づいて前記サービスデータベースに記憶されている前記サービス情報を抽出し,前記サービス要求情報に対応する前記組み合わせサービスを構成するサービス作成部と,
利用者端末から受け付けた評価基準に基づいて,作成された前記組み合わせサービスの順位付けを前記サービス要求に応じて行うサービス評価部と,
前記サービス評価部でなされた順位付けされた前記組み合わせサービスの順位付け情報に基づいて,順位付け情報が下位に順序付けされた組み合わせサービスについては,上位に順序付けされた組み合わせサービスよりも,前記サービスデータベースに記憶されている前記組み合わせサービスを構成するサービス情報に含まれる前記付加情報を多く取得する付加情報取得手段と,
前記サービス作成部で構成された前記組み合わせサービスと前記サービス評価部でなされた順位付けされた前記組み合わせサービスの順位付け情報と前記付加情報取得手段にて取得された前記付加情報とを,前記利用者端末に送信する送信部とを有することを特徴とするサービス提供システム。
【請求項2】請求項1に記載のサービス提供システムにおいて,前記送信部から前記利用者端末に出力された前記組み合わせサービスのいずれかを選択する旨の前記利用者端末からの応答に基づき前記組み合わせサービスを前記利用者端末が利用したかの有無を含む履歴情報を履歴記憶部に記憶し,または前記履歴記憶部に記憶された前記履歴情報を前記組み合わせサービスの個々のサービスシステムに通知し,前記通知した履歴情報に基づき前記個々のサービスシステムから送信されてきたサービス内容の変更を伴うサービス情報,または前記履歴記憶部に記憶されている履歴情報に基づき,前記サービス作成部で作成する組み合わせサービスを変更することを特徴とするサービス提供システム。
【請求項3】請求項1または請求項2に記載のサービス提供システムにおいて,前記送信部から利用者端末に出力された前記組み合わせサービスを前記利用者端末から選択する旨の選択信号を前記サービス提供システムが受信したときに,前記送信した組み合わせサービスを提供する個々の業者へ発注処理をすることを特徴とするサービス提供システム。
【請求項4】ネットワーク上に開設されている複数のサービスシステムが各々のサービスを提供するサービス群と前記サービス群のサービスを組み合わせる請求項1乃至請求項3に記載のいずれかのサービス提供システムであって,
前記利用者端末によって選択された前記サービス作成部で構成された前記組み合わせサービスの個々のサービスの評価点を予め記憶されている一定の規則によって前記サービス作成部で算出し,該算出された評価点を前記個々のサービスを提供する個々の業者へ通知することを特徴とするサービス提供システム。
【請求項5】請求項1乃至請求項4に記載のサービス提供システムにおいて,
前記サービス提供システムは,前記個々のサービスシステムからサービス情報または前記サービス情報に関わる情報を受信する際の前記サービスシステムからの応答のレスポンスの良否またはエラー頻度に応じて,前記サービス作成部において前記サービスシステムの評価点データを記憶する評価点記憶部を有することを特徴とするサービス提供システム。」

本件補正は,請求項1について,
「前記サービスデータベースに記憶されている前記組み合わせサービスを構成するサービス情報に含まれる前記付加情報を取得する付加情報取得手段」という事項を,
「前記サービス評価部でなされた順位付けされた前記組み合わせサービスの順位付け情報に基づいて,順位付け情報が下位に順序付けされた組み合わせサービスについては,上位に順序付けされた組み合わせサービスよりも,前記サービスデータベースに記憶されている前記組み合わせサービスを構成するサービス情報に含まれる前記付加情報を多く取得する付加情報取得手段」(補正箇所を示す下線は,手続補正書記載のものを援用した。)と補正する事項(以下,「補正事項」という。)を含んでいる。
当該補正事項について,願書に最初に添付した明細書又は図面を参酌すると,同明細書の段落【0033】に「さらにあるキーで順序付けされた複数の組み合わせサービスにおいて,順位に応じて表示できる情報量を変化させてもよい。たとえば下位に順序付けされた組み合わせサービスほど多くの付加情報を表示できるようにしておくと,順序付けされた上位の組み合わせサービスだけが単純に選択されることを防ぎ,利用者の要求から外れた組み合わせサービスであっても,利用者にとって有用な,あるいは,興味をひく付加情報のある下位組み合わせサービスが利用者に選択される機会が多くなり,ひいては利用者に選択されるサービスが分散しやすくなる。」ことや,同明細書の段落【0043】に「さらに,画面表示の一例を示す図9のように,下位に順序づけられたチェーンほど多くの付加情報(aa1,bb2,cc2など)を表示することにより,利用者が明に要求していなかったが,興味の対象とする情報が見つけられる可能性が増え,図9ではS2などの下位のバリューチェーンにも商機が生まれる。」ことが記載され,特定の組み合わせサービスについて,順位に応じて表示できる付加情報の情報量を変化させることが記載されているが,特定の組み合わせサービスについて付加情報取得手段が付加情報を多く取得することにより,当該情報量の変化を実現することは何ら記載されておらず,同明細書又は図面の記載から自明のことでもない。したがって,当該補正事項を含む本件補正は,当初明細書等のすべての記載を総合することにより導かれる技術的事項との関係において,新たな技術的事項を導入するものである。

以上のとおりであるから,本件補正は,平成14年法律第24号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第3項の規定に違反するので,同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。

3.本願発明について
上述のとおり,平成18年12月22日付けの手続補正は上記のとおり却下されたので,本願の請求項1に係る発明(以下「本願発明」という。)は,平成17年10月19日付けの手続補正書の特許請求の範囲の請求項1に記載された事項により特定される,次のとおりのものである。

「ネットワーク上に開設されている複数のサービスシステムが提供するサービス情報を取得しておき,利用者端末からの所望のサービス要求を受け付けて,前記所望のサービス要求に応じて,前記サービス情報に基づいて複数のサービスを組み合わせて組み合わせサービスを提供するサービス提供システムにおいて,
前記複数のサービスの各々の内容と前記複数のサービスの各々の付加情報とをサービス情報としてサービス毎に記憶するサービスデータベースと,
利用者端末からのサービス要求の内容を含むサービス要求情報を受け付け,前記サービス要求に応じるために前記サービスデータベースに記憶されている前記サービス情報を組み合わせて,前記サービス要求に応じる前記組み合わせサービスを構成するサービス作成部と,
構成された前記組み合わせサービスの順位付けを前記サービス要求に応じて行うサービス評価部と,
前記サービスデータベースに記憶されている前記組み合わせサービスを構成するサービス情報に含まれる前記付加情報を取得する付加情報取得手段と,
前記サービス作成部で構成された前記組み合わせサービスと前記サービス評価部でなされた順位付けされた前記組み合わせサービスの順位付け情報と前記組み合わせサービスの順位付け情報に応じて選択された前記付加情報とを,前記利用者端末に送信する送信部とを有することを特徴とするサービス提供システム。」

4.原査定の拒絶の理由について

原査定の平成17年8月16日付けの拒絶理由通知書により通知した拒絶の理由Cの概要は,以下のとおりである。
『C.この出願の下記の請求項に係る発明は,その出願前日本国内又は外国において頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて,その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により特許を受けることができない。
記 (引用文献等については引用文献等一覧参照)
請求項1乃至5
引用文献1乃至5
引用文献1には,組合せサービスを構成するサービス提供システムが記載されている。
引用文献2,3には,複数のサービスを評価情報等と共に表示し,サービスを選択する点が記載されている。また,利用履歴情報によってサービスの内容を変更する技術は,引用文献4,5に例示するように周知の技術である。
引用文献1乃至5より本願発明とすることは容易になしうるものである。

引 用 文 献 等 一 覧
1.インターネットサービス連携システムにおけるサービスレベルを考慮した運用管理方法,情報処理学会研究報告,社団法人情報処理学会,2001年11月30日,第2001巻第119号,7?12頁
2.特開2002-163337号公報
3.特開2002-236736号公報
4.特開2001-273420号公報
5.特開2002-49815号公報』

また,平成18年10月6日付けの拒絶査定により示された拒絶の理由の概要は,以下のとおりである。
『この出願については,平成17年 8月16日付け拒絶理由通知書に記載した理由A,Cによって,拒絶をすべきものである。
なお,意見書並びに手続補正書の内容を検討したが,拒絶理由を覆すに足りる根拠が見いだせない。

備考
(中略)
(理由Cについて)
出願人は意見書にて『引用文献1:「インターネットサービス連携システムにおけるサービスレベルを考慮した運用管理方法」は,サービス連携システムにおいて,インターネット上のサービスフローの制御やサイトの新規参入など動的な変化に対応する技術に関するものであります。
しかしながら,本願発明が着目した「価格競争力の無いサービス業者は脱落してしまい,WEBサービス市場では,一部の業者の独占状態が発生する可能性がある。この様な状態が生じる可能性があると,小規模なサービス業者の参入が難しいばかりではなく,サービスの利用者にとっても選択の余地のないサービスがなされることになる。」との問題点の指摘,またはその示唆もなく,さらに,「前記組み合わせサービスの順位付け情報に応じ選択された前記付加情報とを,前記利用者端末に送信する前記利用者端末に送信する送信部」との構成については,記載及び示唆はありません。』と主張している。
検討するに,引用文献1は,「条件に対して,複数のサービス候補を検索することが可能である。」,「シナリオ実行の管理シナリオには利用するSTが定義されている。同一のSTに属する個別SPは複数存在し,連携サービス実行時に個別SPを動的に選択する。」(第10頁参照)と記載されていることから,要求に対して,複数のサービス組合せを作成可能であることは,容易に着想可能である。一方,引用文献2,3に示すように,複数のサービスを順位付けて表示することは周知の技術であり,また,引用文献2(第34,35段落,図8等参照)には,サービスのリストともに,該サービスの付加情報を提供する技術が記載されているものである。
よって,引用文献1記載のシステムに,引用文献2,3の技術を採用して,組み合わせサービスと順位付け情報と前記組み合わせサービスの付加情報とを,利用者端末に送信する構成を着想することは,容易になしうることにすぎない。そして,付加情報を「サービスの順位付け情報に応じて選択」する点については記載されていないが,請求項の記載からでは,願望的な漠然とした機能を特定しているにすぎずないものであるから,この点については設計事項にすぎないものである(「サービスの順位付け情報に応じて選択」をするための,技術的な事項(コンピュータのハードウエア資源を用いた具体的な情報処理)が記載されているものでなく,付加情報を選択する方法を取り決めた程度の記載にすぎないことから,このような漠然とした機能を設けることは,設計事項にすぎないものである。)。
なお,引用文献1に引用文献2,3の技術を採用して,順位付け情報,付加情報,サービス組合せを提示し,該提示された情報からユーザが希望するサービスの組合せを選択するシステムとすれば,出願人が主張する『一部の業者の独占状態が発生する可能性がある。この様な状態が生じる可能性があると,小規模なサービス業者の参入が難しいばかりではなく,サービスの利用者にとっても選択の余地のないサービスがなされることになる。』という問題が解決できるものとなることは予測できる程度のことであるから,問題点の相違については特段のものではない。
よって,本願請求項1-5は,依然として先に提示した引用文献より容易に発明をすることができたものである。』

5.当審の判断
5-1.引用例について
(1)引用例1について
原査定の拒絶理由通知で引用した「インターネットサービス連携システムにおけるサービスレベルを考慮した運用管理方法,情報処理学会研究報告,社団法人情報処理学会,2001年11月30日,第2001巻第119号,7?12頁」(以下「引用例1」という。)には,図面とともに以下のことが記載されている。

(ア)「複数サービスを連携し,新たなサービスを生み出すというような差異化要素が必要となる。具体例として,フライトの予約,ゴルフ場の予約,ホテルの予約というサービスを一連の処理で行うことで,ひとつの旅行サービスが提供できる。このように,Webサービス等を組み合わせて新たなサービスを創り出す仕組みを,筆者らはサービス連携[1]と呼ぶことにする。このサービス連携を実現するには,サービスのフローを制御する仕組みや,インターネット上のサービスを検索する技術が必要となる。」第8頁左欄第24?34行

(イ)「2.サービス連携の概要
本章では,サービス連携の概念を説明し,さらにサービス連携システムの実現のための要件について述べる。
2.1サービス連携とは
サービス連携においては,図1に示すように”サービス利用者”,”連携サービスプロバイダ(CSP)”,”個別サービスプロバイダ(ISP)”の3つの立場に分類できる。以下,それぞれの立場について説明する。
○サービス利用者
連携サービスプロバイダが提供するサービスの利用者である。連携サービスプロバイダを使うメリットとして,利用者自身が個別サービスの所在やサービス内容を把握している必要が無く,連携サービスプロバイダが仲介役としてサービスの検索や予約処理などを行った結果をサービスとして受けられる点があげられる。
○連携サービスプロバイダ
サービス利用者の希望条件を収集し,実際のサービスのブローカリング(検索など)および実際のサービスのアクセス(実行依頼)を仲介する。従来のサービス提供者を募って作成されたポータルサイトと異なる点は,UDDI[2]/SOAP[3]/ebXML[4]といったWebサービスを実現する仕様に準拠した個別サービスプロバイダに対し,逐次システムを接続することを可能としている点である。この特徴により,利用者は希望条件に最も近いサービスを享受することが可能となる。(中略)(以下,連携サービスプロバイダを簡単のため,連携SP又はCSPと記述する。)
○個別サービスプロバイダ
主にインターネット上でサービスを提供するプロバイダを想定している。従来,Webページによりサービスを提供して来たプロバイダは,Webサービスに対応したインタフェースをWebページと同様に準備することで,個別サービスプロバイダとなることが可能となる。(中略)(以下,個別サービスプロバイダを簡単のため,個別SPまたはISPと記述する。)(中略)ここで示した,サービス連携システムのモデルでは,複数の独立したシステムが疎結合によりサービスを提供することになる。」第8頁左欄第45行?右欄第38行

(ウ)「サービス連携を実現するための構成要素を図2に示す。図中の各用語は,以下のように定義する。
連携サービスプロバイダ(連携SP):サービス連携システムのポータルとして,利用者からの要求を受け付け,連携サービスを提供するサーピスプロバイダ。
個別サービスプロバイダ(個別SP):ネット上に分散し,個々にサービスを提供するサービスプロバイダ。
シナリオ:連携サービスを構成するサービスの組合せおよび実行順序の定義。
シナリオインスタンス:利用者の要求ごとに,シナリオから作成される連携サービスの実体。
サービス連携エンジン:利用者の要求に従い,シナリオからシナリオインスタンスを作成し,連携サービスの実行を制御する。
サービスタイプ(ST):航空機予約やホテル予約など,サービスの種類でまとめた個別SPのグループ。
サービスブローカリング/アクセス部:サービス連携のための基本的な機能を提供する。主に以下の構成要素からなる。
個別SPリポジトリ:個別SPが提供するサービスやそのサービスタイプを格納したデータベース。
サービス仲介部:サービス連携エンジンからの要求に従い,個別SPリポジトリからの個別SPの検索およびサービスの実行を行う。
サービスアクセス部:連携SPと個別SPとの通信を行う。ルーティングやセキュリティ機能を提供する。」第9頁左欄第6?37行

(エ)「3.1.2シナリオ実行の管理
シナリオには利用するSTが定義されている。同一のSTに属する個別SPは複数存在し,連携サービス実行時に個別SPを動的に選択する。そのため,同一シナリオでも実行条件により連携する個別SPが異なる。したがって,個別SPの可用性・性能情報を用いて,個々の連携サービスの可用性・性能を監視し,必要に応じて個別SPの選択および再選択や実行中止などの制御を行う必要がある。
(中略)
3.2運用管理の要件
(中略)
(2)状態監視:個別SPの稼動・非稼動の監視のために定期的なポーリングおよび非同期なイベントの受信を行う。また,実際の連携サービスおよび個別SPの性能を測定する。
(3)障害・性能分析:シナリオおよび実行中の連携サービスごとに個別SP障害の影響を分析する。また,シナリオ実行と個別SPの応答時間の関係を統計的に分析し,シナリオ実行の所要時間を推定する。
(中略)
3.3実現方式
(3)障害・性能分析
(a)個別SP障害の影響分析:構成情報および監視情報を用いて,シナリオおよび実行中のシナリオインスタンスヘの影響を分析する。分析項目および判断基準を表3に示す。(b)性能分析:連携サービスおよび個別SPの応答時間を統計手法により解析し,予め決められた時間内にサービスを終了することが可能な個別SPを選択するなどに用いる。」第10頁右欄第21行?第11頁左欄

上記摘記事項(ア)乃至(エ)によれば,引用例1には,以下の発明(以下「引用例1発明」という。)が開示されている。

「複数サービスを連携し,新たなサービスを生み出すことが必要であり,具体例として,フライトの予約,ゴルフ場の予約,ホテルの予約というサービスを一連の処理で行うことで,ひとつの旅行サービスが提供できるのであって,このように,Webサービス等を組み合わせて新たなサービスを創り出す仕組みを,サービス連携と呼ぶことにし,このサービス連携を実現するには,サービスのフローを制御する仕組みや,インターネット上のサービスを検索する技術が必要となること,
サービス連携においては,”サービス利用者”,”連携サービスプロバイダ(CSP)”,”個別サービスプロバイダ(ISP)”の3つの立場があること,サービス利用者は,連携サービスプロバイダが提供するサービスの利用者であり,連携サービスプロバイダは,サービス利用者の希望条件を収集し,実際のサービスのブローカリング(検索など)および実際のサービスのアクセス(実行依頼)を仲介し,個別サービスプロバイダは,主にインターネット上でサービスを提供するプロバイダを想定していること,
また,連携サービスプロバイダ(連携SP)は,サービス連携システムのポータルとして,利用者からの要求を受け付け,連携サービスを提供するサーピスプロバイダであり,個別サービスプロバイダ(個別SP)は,ネット上に分散し,個々にサービスを提供するサービスプロバイダであること,
サービスブローカリング/アクセス部が,サービス連携のための基本的な機能を提供するものであり,主に,個別SPリポジトリとサービス仲介部の構成要素からなり,個別SPリポジトリが,個別SPが提供するサービスやそのサービスタイプを格納したデータベースであり,サービス仲介部が,サービス連携エンジンからの要求に従い,個別SPリポジトリからの個別SPの検索およびサービスの実行を行うこと,
また,サービス連携エンジンとは,利用者の要求に従い,シナリオからシナリオインスタンスを作成し,連携サービスの実行を制御することであり,ここで,シナリオとは,連携サービスを構成するサービスの組合せおよび実行順序の定義であって,シナリオインスタンスとは,利用者の要求ごとに,シナリオから作成される連携サービスの実体であること,
個別SPの可用性・性能情報を用いて,個々の連携サービスの可用性・性能を監視し,必要に応じて個別SPの選択および再選択や実行中止などの制御を行う必要があるために,運用管理の要件の実現方式として,性能分析を行うこと,その内容としては,連携サービスおよび個別SPの応答時間を統計手法により解析し,予め決められた時間内にサービスを終了することが可能な個別SPを選択するなどに用いること,
サービス利用者が,サービスの検索や予約処理などを行った結果をサービスとして受けられること。」

(2)引用例2について
原査定の拒絶理由通知で引用した「特開2002-163337号公報」(以下「引用例2」という。)には,図面とともに以下のことが記載されている。

(オ)「【0001】
【発明の属する技術分野】
本発明は,国際輸送サービス選択システムに係り,特に,荷送人が適切な国際輸送サービスを選択できる国際輸送サービス選択システムに関する。
(中略)
【0033】図8は,輸送サービスデータの一覧の例を示す説明図である。図8に示す例では,日本国からアメリカ国への輸出で,神奈川県藤沢市内を集荷地として,カリフォルニア州内を配達地とする輸送サービスの一覧であり,図5に示すアメリカ西海岸ゾーン(USA-A2)に属する輸送サービスの一覧である。この図8に示す輸送サービスデータは,図1に示す輸送サービスDB4に登録されている。運賃,所要日数,付加価値及びコメントは各提供者によって登録される。
【0034】(中略)一方,提供者は,輸出先毎に強み,弱みがある。例えば,提供者又はその輸送サービスは,カリフォルニア州には自社での倉庫があるとか,ドイツ国に提携している物流センターがあるとか,食品の輸出入の取り扱いに長けているとか,荷物に関する機密保持契約を締結し秘密を保持した状態で輸送できるなどの特徴を有する。これらの特徴を荷送人に伝達するために,図8に示す例では,輸送サービスの付加価値と,荷送人から見たメリット等を輸送サービスの特徴として輸送サービスデータに含めている。この付加価値を運賃等と共に比較検討することで,荷送人は多数の国際輸送サービスから最適な輸送サービスを選択することができる。また,提供者側にとっても,付加価値等の欄を用いて,自らのサービスの運賃設定の理由を荷送人に伝達することができる。
(中略)
【0037】また,図8に示すように,輸送サービスDBが,前記輸送サービスの特徴として前記国際輸送サービスの付加価値サービスデータを記憶する例では,国際輸送サービス情報抽出部が,前記荷送人端末の操作に応じて前記付加価値サービスをキーとして当該国際輸送サービスを並べ替えるソート機能14Eを備えると良い。
(中略)
【0042】(中略)輸送サービスデータを含む輸送サービス選択ページ6Cの例を図11に示す。ここでは,ソート機能14Eにより,図10にて入力した精密機器の取り扱い実績が多いA社のサービスを先頭に位置づけた。荷送人は,「精密機器実績多」であるA社のサービスを,他の輸送サービスよりも高価であるにもかかわらず選択する(ステップS6)(以下,略)」明細書段落【0001】?【0066】

上記摘記事項(オ)によれば,引用例2には,以下の発明(以下「引用例2発明」という。)が開示されている。
「サービスの選択システムにおいて,サービスの付加価値を記憶した輸送サービスDBと,当該輸送サービスDBに記憶されている付加価値を取得する国際輸送サービス情報抽出部と,当該付加価値を輸送サービスデータを含む輸送サービス選択ページに送信する手段とを有する国際輸送サービス選択システム。」

(3)引用例3について
原査定の拒絶理由通知で引用した「特開2002-236736号公報」(以下「引用例3」という。)には,図面とともに以下のことが記載されている。

(カ)「【0001】
【発明の属する技術分野】
本発明は,ビル等の群管理サービス支援方法及び支援装置に係り,特に,オフィスやマンションなどの複数のビルに対して設備や建物を統合的に管理するのに好適な,ビル等の群管理サービス支援方法及び支援システムに関する。
(中略)
【0022】(中略)まず,管理者装置は端末事業者との間で,サービス評価処理(701)を実施する。これは事業者端末の過去のサービス内容を評価する手続きである。つぎに,管理者装置と所有者端末との間で,701の評価結果に基づいて保守プランの提案及び保守プラン選定処理(702)が行われる。管理者装置はコスト,工期,品質な,サービス等種々の観点で作成されたすべての保守プランを所有者端末に提示し,その中から所有者端末が希望条件にあった保守プランの選択をする。
(中略)
【0027】シーケンス201は,管理者装置が保守事業者の初期評価をするシーケンスで,504の記録を参照して,保守事業者のサービスの格付けを行なう。たとえばサービスを幾つかのランクに分けて,分類した結果はシステムにより保守事業者の評価ファイル(505)のサービス評価の項目として記録される。
【0028】シーケンス202では,管理者装置が,保守事業者の初期組み合わせを決定する。これは201の評価結果から各保守事業者のサービスの特性を把握し,特性別にいくつかの保守プランを考え,その保守プランを構成するのに最適な保守事業者の初期の組み合わせを決定する。この決定結果は,システムにより保守事業者の組み合わせファイル(506)の保守プランの項目として記録される。このプランの例として,コストを重視したプラン,性能を重視したプラン,すべてに平均的なプランなどを管理者装置は用意する。
【0029】シーケンス203では,管理者装置が所有者端末に,保守プランを提示する。ここではシステムにより506の保守プランが示される。
【0030】シーケンス301では,所有者端末が,保守プランの選択をする。(以下,略)」明細書段落【0001】?【0065】

上記摘記事項(カ)によれば,引用例3には,以下の発明(以下「引用例3発明」という。)が開示されている。
「保守プランの選択のためのサービスの支援システムにおいて,保守事業者を組み合わせた保守プランの最適なプランの選択を要求が見込まれるプラン毎に応じて行う群管理サービス支援システム。」

5-2.対比
本願発明と,上記引用例1発明とを比較する。

(1)引用例1発明において,「サービス連携システムの実現のため」の一つの要件である「連携サービスプロバイダ」は,「ネット上に分散し,個々にサービスを提供」している「個別サービスプロバイダ」が提供する「実際のサービス」を「利用者からの要求を受け付け」て「サービス利用者の希望条件を収集」することに応じて,「ブローカリング(検索など)および実際のサービスのアクセス(実行依頼)を仲介」するのであり,第1図及び第2図より,「ネット」とは,インターネットのことであって,「利用者からの要求」は,利用者端末によりなされていると考えるのが自然である。また,第2図より,「連携サービスプロバイダ」に含まれる「サービスブローカリング/アクセス部」に「個別SPが提供するサービスやそのサービスタイプを格納したデータベース」である「個別SPリポジトリ」が構成されていることから,「連携サービスプロバイダ」が「利用者からの要求を受け付け」に先だって,「個別SPが提供するサービスやそのサービスタイプ」を取得しておくと考えるのが自然である。さらに,「連携サービスプロバイダ」が仲介するのは,「利用者からの要求を受け付け,連携サービスを提供する」ことにより,「複数サービスを連携し,新たなサービスを生み出す」ことと記載されている。よって,引用例1発明と本願発明とは,「インターネット上に開設されている複数の個別サービスプロバイダのシステムが提供するサービスの情報を取得しておき,利用者端末からの所望のサービス要求を受け付けて,前記所望のサービス要求に応じて,前記サービスの情報に基づいて複数のサービスを組み合わせて連携サービスを提供するサービス連携システムにおいて,前記複数のサービスの各々の情報をサービスの情報としてサービス毎に記憶するデータベースと,を有することを特徴とするサービス連携システム。」である点で共通する。

(2)引用例1発明において,「連携サービスプロバイダ」に含まれる「サービスブローカリング/アクセス部」に,「個別SPが提供するサービスやそのサービスタイプを格納したデータベース」である「個別SPリポジトリ」と,「利用者の要求に従い,シナリオ(連携サービスを構成するサービスの組合せおよび実行順序の定義)からシナリオインスタンス(連携サービスの実体)を作成し,連携サービスの実行を制御」する「サービス連携エンジン」からの要求に従い,「個別SPリポジトリからの個別SPの検索およびサービスの実行」を行う「サービス仲介部」が構成されていることから,引用例1発明と本願発明とは,「利用者端末からのサービス要求の内容を含むサービス要求情報を受け付け,前記サービス要求に応じるために前記データベースに記憶されている前記サービスの情報を組み合わせて,前記サービス要求に応じる前記連携サービスを構成するサービス連携エンジンとサービス仲介部」を有している点で共通する。

(3)引用例1発明のサービス連携システムは,運用管理の目的で,「連携サービスおよび個別SPの応答時間を統計手法により解析し,予め決められた時間内にサービスを終了することが可能な個別SPを選択する」という性能分析の機能を備えていること,当該性能分析は,第6図より,「連携サービスプロバイダ」の「運用管理モジュール」で行われるのであり,さらに,「連携サービス」は,利用者の要求に従って「サービス連携エンジン」で作成されるのであるから,引用例1発明と本願発明とは,「構成された前記連携サービスの評価を前記サービス要求に応じて行う運用管理モジュール」を有している点で共通する。

(4)引用例1発明において,サービス利用者は,「サービスの検索や予約処理などを行った結果をサービスとして受けられる」のであり,第1図及び第2図より,利用者は,利用者端末を用いるのであるから,当該検索の結果を利用者端末に表示させるための送信部が備えられていると考えるのが自然である。そうすると,引用例1発明と本願発明とは,「前記サービス作成部で構成された前記組み合わせサービスを,前記利用者端末に送信する送信部」を有している点で共通する。

ここで,これら引用例1発明の「インターネット」,「個別サービスプロバイダのシステム」,「連携サービス」,「サービス連携エンジンとサービス仲介部」は,それぞれ本願発明の「ネットワーク」,「サービスシステム」,「組み合わせサービス」,「サービス作成部」にそれぞれ対応している。
また,これら引用例1発明の「サービスの情報」,「データベース」,「運用管理モジュール」「サービス連携システム」は,以下の相違点があるものの,それぞれ本願発明の「サービス情報」,「サービスデータベース」,「サービス評価部」,「サービス提供システム」と共通した機能を備えている点で,それぞれ対応している。

以上のとおりであることから,引用例1発明と本願発明とは,

「ネットワーク上に開設されている複数のサービスシステムが提供するサービス情報を取得しておき,利用者端末からの所望のサービス要求を受け付けて,前記所望のサービス要求に応じて,前記サービス情報に基づいて複数のサービスを組み合わせて組み合わせサービスを提供するサービス連携システムにおいて,
前記複数のサービスの各々の情報をサービス情報としてサービス毎に記憶するサービスデータベースと,
利用者端末からのサービス要求の内容を含むサービス要求情報を受け付け,前記サービス要求に応じるために前記サービスデータベースに記憶されている前記サービス情報を組み合わせて,前記サービス要求に応じる前記組み合わせサービスを構成するサービス作成部と,
構成された前記組み合わせサービスの評価を前記サービス要求に応じて行うサービス評価部と,
前記サービスデータベースに記憶されている前記組み合わせサービスを構成するサービス情報に含まれる前記付加情報を取得する付加情報取得手段と,
前記サービス作成部で構成された前記組み合わせサービスを,前記利用者端末に送信する送信部とを有することを特徴とするサービス提供システム。」

である点で一致し,以下の点で相違する。

[相違点1]
本願発明の「サービスデータベース」に記憶する「サービス情報」が「前記複数のサービスの各々の内容と前記複数のサービスの各々の付加情報」であって,本願発明が「前記サービスデータベースに記憶されている前記組み合わせサービスを構成するサービス情報に含まれる前記付加情報を取得する付加情報取得手段」を有すると共に,「送信部」が,「前記付加情報」を送信しているのに対し,引用例1発明の「サービス情報」には,「前記複数のサービスの各々の情報」であるものの,「前記複数のサービスの各々の付加情報」が含まれておらず,引用例1発明には,「前記サービスデータベースに記憶されている前記組み合わせサービスを構成するサービス情報に含まれる前記付加情報を取得する付加情報取得手段」を有しておらず,「送信部」が,「前記付加情報」を送信していない点。

[相違点2]
本願発明の「サービス評価部」が,組み合わせサービスの「順位付け」を行っており,「送信部」が「前記サービス評価部でなされた順位付けされた前記組み合わせサービスの順位付け情報」を送信すると共に,送信する「付加情報」が「前記組み合わせサービスの順位付け情報に応じて選択された」ものであるのに対して,引用例1発明では,性能分析を行うことで組み合わせサービスの評価をしているものの,「順位付け」を行うことが記載されておらず,送信部もそのような機能を有していない点。

5-3.判断
[相違点1]について。
引用例2発明は,サービスの選択システムに関する発明であって,サービスの付加価値を記憶した輸送サービスDBと,当該輸送サービスDBに記憶されている付加価値を取得する国際輸送サービス情報抽出部と,当該付加価値を輸送サービスデータを含む輸送サービス選択ページに送信する手段とにより,引用例2段落【0042】に記載されているように,サービスの選択に際して,サービス情報の内容に関する情報と共に,付加情報を利用者に提供することにより,価格等によらない選択を可能とする発明であり,サービスの選択システムの設計に際して,利用者の選択の幅を広げたり,選択を容易とすることは,当業者が通常考慮することであるので,引用例1発明のサービス提供システムに,公知の引用例2発明を組み合わせることが当業者にとって格別な技術力を要するものとは認められない。
すなわち,引用例1発明の「サービス情報」に「前記複数のサービスの各々の付加情報」を含ませ,「前記サービスデータベースに記憶されている前記組み合わせサービスを構成するサービス情報に含まれる前記付加情報を取得する付加情報取得手段」を構成し,「送信部」を「前記付加情報」を送信するよう構成することは,当業者が容易に想到することができたものである。

[相違点2]について
引用例1発明では,5-2.(3)や,上記摘記事項(エ)に示したとおり,予め決められた時間内にサービスを終了することが可能な個別SPを選択するなどに用いるために,連携サービスの応答時間を解析しているので,各連携サービスの応答時間を計算することが開示されている。引用例3発明には,引用例1発明と同様のサービスの選択を行うシステムの技術分野において,サービスの組み合わせである保守プランの選択を支援するために,保守プランの最適なプランの選択を要求が見込まれるプラン毎に応じて行っているので,引用例1発明の連携サービスの性能分析の評価をする際に,引用例3発明に開示された順位付けによる最適な連携サービスを選択するよう構成することは,当該技術分野の当業者にとって容易である。さらに,引用例1発明においては,利用者のサービス要求を検索した結果の連携サービスを利用者が受け取るのであるから,利用者端末に送信された連携サービスを参照するために,利用者端末に連携サービスが何らかの形式で表示されていることが示唆されており,何らかの基準で順位付けした検索結果の表示において,利用者にとってニーズの高いと想定される順位で表示することは,システムの設計に際して当業者が通常考慮する周知の事項であり,順位付けに応じて付加情報の内容を選択することも,例えば,伊藤 智洋,発表2001年下半期ネット証券総合ランキング,日経ネットトレーディング 2001年 Vｏl.6 第8巻 第18号,日経BP社,2001年12月15日,ｐ.94-95(以下,「周知例1」という。)に,順位で上位5社については点数と共にコメントを掲載し,6位以下については点数のみを掲載しているように,順位の表示においては一般的になされている周知の事項であり,また,システム上の表示においても,例えば,特開2001-216244号公報(以下,「周知例2」という。)の段落【0123】-【0126】及び第10図に,検索条件に完全に一致する結果についてはメッセージを表示せず,代替候補の結果についてはメッセージを表示することや,特開2001-265811号公報(以下,「周知例3」という。)段落【0053】及び第17図に,信頼度の低い順位の検索結果のみに参考となるイメージを表示することが記載されていることなど,コンピュータシステムにおける表示の際に,順位に応じて付加情報の内容を選択することは当業者に周知の技術であり,どのような内容を選択するかは,検索の目的や表示の対象に応じて当業者が適宜選択し得ることである。
したがって,引用例1発明において,「サービス評価部」に,組み合わせサービスの「順位付け」を行わせ,「送信部」を「前記サービス評価部でなされた順位付けされた前記組み合わせサービスの順位付け情報」を送信させるよう構成すると共に,送信する「付加情報」を「前記組み合わせサービスの順位付け情報に応じて選択された」ものとすることは,当業者が容易に想到することができたものである。

以上判断したとおり,本願発明における上記[相違点1]乃至[相違点2]に係る発明特定事項は,いずれも当業者が容易に想到することができたものであり,上記各相違点を総合しても,想到することが困難な格別の事項は見いだせない。
また,本願発明の作用効果も,各引用例1?3発明及び各周知の事項から当業者が予測できる範囲のものである。

5-4.まとめ

したがって,本願発明は,上記引用例1?3発明及び各周知の事項に基づいて,当業者が容易に発明をすることができたものである。

6.むすび
以上のとおり,本願発明は,各引用例1?3発明及び周知の事項に基づいて,当業者が容易に発明をすることができたものであり,特許法第29条第2項の規定により特許を受けることができない。

よって,結論のとおり審決する。
 
審理終結日 2009-09-30 
結審通知日 2009-10-06 
審決日 2009-10-19 
出願番号 特願2002-253688(P2002-253688)
審決分類 P 1 8・ 561- Z (G06Q)
P 1 8・ 121- Z (G06Q)
最終処分 不成立  
前審関与審査官 小山 和俊  
特許庁審判長 清田 健一
特許庁審判官 山本 穂積
齋藤 哲
発明の名称 サービス提供システム  
代理人 横山 淳一  

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