WO2012153362A1

WO2012153362A1 - マッシュアップサーバ

Info

Publication number: WO2012153362A1
Application number: PCT/JP2011/002563
Authority: WO
Inventors: 洋子衣川; 俊介秋藤
Original assignee: 株式会社日立製作所
Priority date: 2011-05-09
Filing date: 2011-05-09
Publication date: 2012-11-15

Abstract

ユーザ端末の画面表示領域の制限やアプリケーションの利用段階の変化により、或る端末に不要となる情報であるにも関わらず、当該端末に配信されてしまうことを解決すること。マッシュアップ・サーバ上に、ユーザ端末の端末状態を記憶する端末状態記憶装置と、ユーザ端末への更新要否を判定するための判定基準を記憶する判定基準記憶装置と、ユーザ端末への更新要否を判定するプログラムである更新要否判定プログラムを設ける。データ更新発生時等に、更新要否判定装置がユーザ端末への更新要否を判定し、更新対象端末に必要なデータのみを配信する。

Description

マッシュアップサーバ

　インターネット上で公開される複数のサービスを組み合わせて新規にアプリケーションを作成するマッシュアップ技術に関する。

　インターネット上では様々なサービスが利用可能である。近年、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ　Ｐｒｏｇｒａｍｍｉｎｇ　Ｉｎｔｅｒｆａｃｅ）やライブラリを公開するサービスの増加に伴い、ユーザがＡＰＩやライブラリを駆使して新規にアプリケーションを作成する、マッシュアップと呼ばれる開発手法がある。公開されるＡＰＩやライブラリの形式は様々である。例えば、マッシュアップの代表格である地図サービスの場合、地図の描画やマーカーの配置といった表示系の処理や、描画した地図上で発生したイベントのハンドリングといった処理が、メソッド呼び出し形式のＡＰＩやライブラリとして備えられていることが一般的である。一方、店舗検索のような情報検索サービスや、Ｔｗｉｔｔｅｒに代表されるＳＮＳで公開されているＡＰＩやライブラリは、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）やＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ　Ｏｂｊｅｃｔ　Ｎｏｔａｔｉｏｎ）等のデータ形式で情報を取得するような情報操作に関わるものが一般的である。

　マッシュアップは既存のサービスを利用するため、ユーザは既存のサービスを組み合わせることにより、容易に独自のアプリケーションを作成することができる。

　マッシュアップ・アプリケーションにおいて或るイベントが発生すると、当該アプリケーションがそのイベントに対して必要なデータを複数の異なるサーバ上のサービスから取得する。これらのサービスは、ＡＴＯＭ、ＲＳＳのようなＸＭＬ形式、ＪＳＯＮ、メソッド呼び出しのように様々な言語、仕様により記述されている。

　このようなマッシュアップ・アプリケーションの例として、特許文献１では、ユーザが対話的に地図上にコメントを配置できるコミュニケーション技術が開示されている。また、特許文献２では、Ｗｅｂページの内容が変更されると、表示される広告も変更される技術が開示されている。

　一方、非特許文献１で紹介されるＷｅｂＳｏｃｋｅｔのように、サーバとクライアントの間での双方向通信を行う技術がある。このような技術により、サーバとクライアントとの間でのリアルタイム通信が可能となり、引いてはサーバ上のサービスに接続する全てのクライアント間でリアルタイムにデータを共有することが可能となる。

　マッシュアップ・アプリケーション開発の潮流として、上記のＷｅｂＳｏｃｋｅｔのような技術を組み合わせたアプリケーションが出現しつつある。例えば配送業者が提供する集荷支援のためのアプリケーションを例にとる。集荷支援アプリケーションは、道路地図サービス、配車情報サービス、および道路情報サービスのマッシュアップ・アプリケーションである。アプリケーションの概要は、道路地図サービスが提供する地図上に、配送車の位置を配車情報サービスを利用して重ね合わせて表示するともに、道路情報サービスが提供する渋滞等の交通状況を重ね合わせて表示するものである。配送車は自身の位置を定期的にアプリケーションに通知し、地図上での位置は逐次更新される。交通状況も同様に逐次更新される。集荷を依頼したいユーザが端末から集荷を依頼すると、その依頼は配送業者の配送センターに通知され、配送センターは、集荷に訪れる予定の配送車を決定し、ユーザの端末に配信する。

　このようなアプリケーションとＷｅｂＳｏｃｋｅｔのようなリアルタイム通信技術の組み合わせにより、集荷を依頼したユーザは、近隣の配送車の位置や交通状況を把握できるため、集荷を依頼するかどうかの判断基準とすることができる。また、集荷依頼後は、集荷予定の配送車の位置を逐次確認することができる。そして、集荷依頼時または待機中に端末から配送伝票に必要事項を入力する。これにより、到着時に速やかに荷物の引渡しを行ったり、送付先への運送手配を事前に進めることができるため、配送業者側のコストも削減できる。

米国特許公開番号２００９－０２５４８４０米国特許公開番号２０１０－０１１４７２０

ｈｔｔｐ：／／ｄｅｖ．ｗ３．ｏｒｇ／ｈｔｍｌ５／ｗｅｂｓｏｃｋｅｔｓ

　しかしながら、このようなアプリケーションには、以下のような課題がある。

　例えば、各配送車の位置は定期的に更新され、アプリケーションに接続している全ユーザの端末に配信されるため、或るユーザの端末に表示されていない領域に存在する配送車の位置情報まで配信されてしまう。ユーザ端末が、処理性能が低く画面表示領域も狭い携帯端末のような環境で実行される場合、不要な情報を受信・処理するために貴重なリソースを消費することになる。また、不要な情報を配信するために、無駄なネットワーク・トラフィックが発生することになる。配送車の数が多い程、これらの課題は無視できないものとなる。

　また、上記のような不要な情報配信は、端末の画面表示領域の制限によってのみ発生するものではなく、アプリケーションの利用段階の変化によっても発生し得る。例えば、上記の集荷支援アプリケーションの例では、ユーザが集荷依頼を決定するまでは、近隣の全ての配送車の情報を確認できることが望ましいが、一旦集荷依頼を行えば、集荷予定の配送車の情報のみ把握できれば良く、それ以外の配送車の情報は、不要なばかりか、必要な情報の把握を妨げることになってしまう。
従来のマッシュアップ技術には、端末の画面表示領域の制限やアプリケーションの利用段階の変化により、一部の端末には不要である情報が当該端末に配信されてしまうという課題がある。

　マッシュアップサーバは、ユーザ端末と、各々ユーザ端末に対して情報を提供する複数のサービスサーバとに通信可能に接続されており、ユーザ端末の端末状態を記憶する端末状態記憶装置と、複数のサービスサーバから受け取ったサービスの実行結果情報のうち、ユーザ端末へ配信すべき実行結果情報を選択する際に用いる判定基準を記憶する判定基準記憶装置と、処理装置とを有している。処理装置は、端末状態と判定基準とを用いて、複数のサービスサーバ各々について、当該サービスサーバから受信した実行結果情報のうちユーザ端末に配信すべき情報を選択し、選択された各実行結果情報が合わせてユーザ端末の画面に表示されるよう当該ユーザ端末へ配信する。

　上記構成によれば、端末の画面表示領域やアプリケーションの利用段階に応じて、必要な情報のみをユーザ端末に返すことができる。

ハードウェア構成の例を示す図である。ソフトウェア構成の例を示す図である。マッシュアップ・アプリケーションの画面例を示す図である。マッシュアップ・アプリケーションの画面例を示す図である。マッシュアップ・アプリケーションの画面例を示す図である。端末状態記憶装置に記憶されたユーザ端末の端末状態の例を示す図である。端末状態記憶装置に記憶されたユーザ端末の端末状態の例を示す図である。判定基準記憶装置に記憶された判定基準の例を示す図である。判定基準記憶装置に記憶された判定基準の例を示す図である。更新要否判定プログラムが実行する処理の一例を説明する図である。マッシュアップ・アプリケーションの画面例を示す図である。マッシュアップ・アプリケーションの画面例を示す図である。

以下、本発明の実施の形態を説明する。

　図１は、ハードウェア構成の例を示す図である。

　１００、１１０は、マッシュアップ・アプリケーションを実行するユーザ端末である。３００、３１０，３２０は、各種サービスを提供するサービス提供サーバである。２００は、ユーザ端末１００、１１０とサービス提供サーバ３００、３１０，３２０の間に設けられたマッシュアップ・サーバである。

　各装置の構成を次に説明する。１０１０、１１１０、２０１０、３０１０、３１１０、３２１０はＣＰＵである。１０２０、１１２０、２０２０、３０２０、３１２０，３２２０はメモリである。１０３０、１１３０、２０３０、３０３０、３１３０，３２３０はハードディスク等の外部記憶装置である。１０４０、１１４０、２０４０、３０４０、３１４０，３２４０は通信装置である。１０５０、１１５０、２０５０、３０５０、３１５０，３２５０はそれらを接続するバスである。１０６０、１１６０はキーボード、１０７０、１１７０はマウス、１０８０、１１８０は表示装置であり、１０９０、１１９０はそれら入出力デバイスを制御する入出力装置である。４００は、それぞれ、ユーザ端末１００、１１０とマッシュアップ・サーバ２００、サービス提供サーバ３００、３１０，３２０とを接続するネットワークである。

　図２は、ソフトウェア構成の例を示す図である。

　１０１、１１１は、それぞれ異なるユーザ端末１００、１１０上で動作するソフトウェアであるブラウザである。ブラウザ１０１は、外部記憶装置１０３０に格納され、起動時にメモリ１０２０にロードされ、ＣＰＵ１０１０により実行される。同様に、ブラウザ１１１は、外部記憶装置１１３０に格納され、起動時にメモリ１１２０にロードされ、ＣＰＵ１１１０により実行される。

　３０１、３１１、３２１は、それぞれ異なるサービス提供サーバ３００、３１０，３２０上で動作する各種サービスプログラム（以下、単にサービスとも呼ぶ）である。サービスプログラム３０１は、外部記憶装置３０３０に格納され、起動時にメモリ３０２０にロードされ、ＣＰＵ３０１０により実行される。同様に、サービス３１１プログラムは、外部記憶装置３１３０に格納され、起動時にメモリ３１２０にロードされ、ＣＰＵ３１１０により実行される。サービスプログラム３２１は、外部記憶装置３２３０に格納され、起動時にメモリ３２２０にロードされ、ＣＰＵ３２１０により実行される。

　２１０は、マッシュアップ・サーバ２００上で動作するソフトウェアであるマッシュアップ・プログラムである。マッシュアップ・プログラム２１０は、外部記憶装置２０３０に格納され、起動時にメモリ２０２０にロードされ、ＣＰＵ２０２０により実行される。

　２３０は、ユーザ端末１００、１１０の端末状態を記憶する端末状態記憶装置である。端末状態記憶装置２３０は、メモリ２０２０または外部記憶装置２０３０上に実装される。

　２４０は、ユーザ端末１００、１１０への更新要否を判定するための判定基準を記憶する判定基準記憶装置である。判定基準記憶装置２０４０は、メモリ２０２０または外部記憶装置２０３０上に実装される。

　２２０は、ユーザ端末１００への更新要否を判定するプログラムである更新要否判定プログラムである。更新要否判定プログラム２２０はマッシュアップ・プログラム２１０の一コンポーネントとして本実施形態では実装されている。

　図３～図５は、マッシュアップ・プログラム２１０（以下マッシュアップ・アプリケーションとも呼ぶ）がユーザ端末へ提供する出力画面の例を示す図である。

　図３～図５に示すのは、配送業者がサービス提供サーバ３２０のサービスプログラム３２１から提供する集荷支援のための情報を、マッシュアップ・プログラム２１０が他のサービス提供サーバ３１０から得られる地図情報とマージしてユーザ端末１００へ提供する際の、マッシュアップ・サーバ２００からユーザ端末１００へ提供される出力画面例である。

　図３、図４は、ユーザ端末１００を利用するユーザが配送業者に集荷依頼する前の、当該ユーザ端末１００に表示される情報の例を示す図である。図３、図４に示す画面には、ユーザの位置を中心とし、近隣を走行中の配送車の位置が表示されている。ユーザが「集荷依頼」ボタン５００をクリックすると、集荷依頼が配送業者のサービス提供サーバ３００へ送信され、サービス提供サーバ３００から配送業者の配送センターに通知される。

　図５は、配送業者に集荷依頼した後の、ユーザ端末１００に表示される情報の例を示す図である。配送センターにおいて配車を行った結果がサービス提供サーバ３２０からマッシュアップ・サーバ２００へ通知され、その結果集荷に訪れる予定の配送車ＣＡＲ１(４０１)の位置がマッシュアップ・サーバ２００からユーザ端末１００へ出力されて、図５に示す画面のようにユーザ端末１００に表示される。集荷に使われる配送車ＣＡＲ１(４０１)が決定された時点で、それ以外の配送車ＣＡＲ２（４０２）およびＣＡＲ３（４０３）の情報は当該ユーザにとっては不要となるので、マッシュアップ・サーバは配送車ＣＡＲ２（４０２）やＣＡＲ３(４０３)の情報はユーザ端末１００には送らない。従ってこれらの配送車ＣＡＲ２（４０２）、ＣＡＲ３(４０３)の情報はユーザ端末１００には表示されない。

　図６、図７は、端末状態記憶装置２３０に記憶されたユーザ端末１００、１１０の端末状態の例を示す図である。端末状態は、アプリケーション実行中に、ユーザ端末１００からの接続要求や更新要求を受信する等のタイミングで、ユーザ端末１００、１１０毎に記憶される。端末状態としては、各ユーザ端末固有の識別子である端末識別子、当該ユーザ端末の存在位置を示す緯度および軽度、そして本実施例においては当該ユーザ端末の利用ユーザについての配車状態を示す情報が格納される。

　図６は、ユーザが集荷依頼する前の端末状態を記憶した端末状態記憶装置２３０の例であり、配車状態の欄がブランクなので、配車は未決定の状態であることを示す。図７は、ユーザが集荷依頼した後の端末状態を記憶した端末状態記憶装置２３０の例であり、配車状態の欄にはユーザに割り当てられた車の識別情報が格納されているので既に配車が決定された状態であることを示す。

　図８、図９は、判定基準記憶装置２４０に記憶された判定基準の例を示す図である。図８には１つの、図９には２つの判定基準が記憶されている。判定基準は、アプリケーション実行前に作成しておくことも、アプリケーション実行中に作成することも可能である。

　図１０は、本発明の実施の形態において、更新要否判定プログラム２２０が実行する処理を説明する図である。

　以下、本発明の実施の形態を説明する。

　ユーザ端末１００は、アプリケーション接続時に、通信装置１０４０、２０４０を経由して、ユーザ端末１００の端末状態更新要求をマッシュアップ・プログラム２１０に送信する。この端末状態更新要求にはユーザ端末１００の端末状態が含まれており、ここでは端末状態として、例えば、ユーザ端末１００を識別する識別子（以下、端末識別子）と、位置情報をユーザ端末１００は送信する。

　待機状態にある更新要否判定プログラム２２０は、マッシュアップ・プログラム２１０がユーザ端末１００から端末状態更新要求を受信すると（ステップ１００１０：端末状態更新要求）、端末識別子をキーとして、受信した端末状態を、端末状態記憶装置２３０に記憶する（ステップ１００２０）。ここでは、図６に示すように、「端末識別子＝ＣＬＩＥＮＴ００３」、位置情報として「緯度＝３５．５５１４６７」と「経度＝１３９．６７３７７５」を端末状態記憶装置２３０に記憶する。

　次に、マッシュアップ・プログラム２１０が、各サービス提供サーバ３００、３１０、３２０に各サービス３０１、３１１，３２１の実行を要求し、実行結果を各サービスサーバ３００、３１０、３２０から取得する（ステップ１００３０）。ここでは、道路地図サービス(サービス３０１)が実行されてマッシュアップ・プログラム２１０は地図情報を取得し、道路情報サービス（サービス３１１）が実行されてマッシュアップ・プログラム２１０は渋滞等の交通状況情報を取得し、配車情報サービス（サービス３２１）が実行されてマッシュアップ・プログラム２１０は配送車の位置情報を取得する。

　更新要否判定プログラム２２０は、判定基準記憶装置２４０と端末状態記憶装置２３０を参照し、端末状態記憶装置２３０に記憶されたユーザ端末１００に対して配信すべき情報を更新する（ステップ１００４０）。即ちマッシュアップ・プログラム２１０は、ステップ１００３０で取得したサービス実行結果を用い、ユーザ端末１００に対して配信すべき情報を切り出しす（選択する）（ステップ１００４０）。そしてステップ１００４０の結果、配信すべき情報に更新があった端末にたいして、切り出された情報を通信装置２０４０、１０４０を経由して配信する（ステップ１００５０）。

　ここでは、図８に示すように、判定基準記憶装置２４０にはあらかじめ「ＤＩＳＴＡＮＣＥ（ＣＡＲ、ＣＬＩＥＮＴ）<=５ｋｍ」という判定基準が記憶されているとする。これは、「配送車とユーザ端末の距離が５ｋｍ以内の場合、当該配送車の情報を当該ユーザ端末に配信」することを意味する。また、ステップ１００３０において、配送車４０１“ＣＡＲ００１”、４０２“ＣＡＲ００２”、４０３“ＣＡＲ００３”の位置情報を取得したとする。このうち、４０１“ＣＡＲ００１”と４０２“ＣＡＲ００２”はユーザ端末１００“ＣＬＩＥＮＴ００３”の半径５ｋｍ以内に存在するが、４０３“ＣＡＲ００３”は半径５ｋｍ以内に存在しない場合、マッシュアップ・プログラム２１０は、ユーザ端末１００“ＣＬＩＥＮＴ００３”に対しては、配送車４０１“ＣＡＲ００１”と４０２“ＣＡＲ００２”の位置情報のみを切り出して（ステップ１００４０）配信する（ステップ１００５０）。同様に、道路情報サービスの実行結果のうち、ユーザ端末１００“ＣＬＩＥＮＴ００３”の半径５ｋｍ以内の交通状況を配信する。サービスの結果を受信したユーザ端末１００は、その内容をブラウザ１０１に表示する。例えば、ユーザ端末１００“ＣＬＩＥＮＴ００３”は、図３に示す情報を画面に表示する。

　これにより、ユーザ端末１００は、アプリケーション接続時に、近隣の情報だけを取得することができる。

　また、ユーザが出先である場合等、ユーザ端末１００が移動することがある。この場合、ユーザ端末は最新の位置情報をマッシュアップ・サーバ２００へ知らせるために端末状態更新要求を送信する。マッシュアップ・プログラムがユーザ端末１００から端末状態更新要求を受信すると（ステップ１００１０：端末状態更新要求）、アプリケーション接続時と同様、ステップ１００２０～１００５０が実行される。

　これにより、ユーザ端末１００は、移動中の状態にあっても、移動先の位置において、近隣の情報だけを取得することができる。

　一方、各サービス３０１、３１１、３２１のデータは、定期的に更新される。例えば、各配送車は、定期的にサービス提供サーバ３２０の配車情報サービス（サービス３２１）に対して自身の位置を通知して位置情報を更新する。各サービスのデータが更新されると、サービス提供サーバはサービスのデータ更新要求をマッシュアップサーバ２００に送信する。マッシュアップ・プログラム２１０はサービス提供サーバ３２０からサービスのデータ更新の要求を受信すると（ステップ１００１０：サービスのデータ更新の要求）、要求元のサービス提供サーバ３２０にサービスを実行させて、実行結果を取得する（ステップ１００３０）。ここでは、配車情報サービス３２１をサービス提供サーバ３２０に実行させて各配送車の最新の位置情報を取得する。

　サービスデータが更新されると、更新要求判定プログラム２２０は、判定基準記憶装置２４０と端末状態記憶装置２３０を参照し、端末状態記憶装置２３０に記憶された各ユーザ端末に対して送信すべき情報を更新（選択）する（ステップ１００４０）。マッシュアップ・プログラム２１０は、送信すべき情報に更新のあったユーザ端末１００に対して、ステップ１００３０で取得したサービス実行結果のうち、ステップ１００４０で選択した情報を切り出して、通信装置２０４０、１０４０を経由して配信する（ステップ１００５０）。例えばここでは、図８に示すように、判定基準装置２４０には「ＤＩＳＴＡＮＣＥ（ＣＡＲ、ＣＬＩＥＮＴ）<=５ｋｍ」という判定基準が記憶されている。これは、「配送車とユーザ端末の距離が５ｋｍ以内の場合、当該配送車の情報を当該ユーザ端末に配信」することを意味する。また、ステップ９０３０において、配送車４０１“ＣＡＲ００１”、４０２“ＣＡＲ００２”、４０３“ＣＡＲ００３”の位置情報を取得したとする。このうち、４０１“ＣＡＲ００１”と４０３“ＣＡＲ００３”はユーザ端末１００“ＣＬＩＥＮＴ００３”の半径５ｋｍ以内に存在するが、４０２“ＣＡＲ００２”は半径５ｋｍ以内に存在しない場合、マッシュアップ・プログラム２１０は、ユーザ端末１００“ＣＬＩＥＮＴ００３”に対しては、配送車４０１“ＣＡＲ００１”と４０３“ＣＡＲ００３”の位置情報のみを切り出して配信する。サービスの結果を受信したユーザ端末１００は、その内容をブラウザ１０１に表示する。例えば、ユーザ端末１００“ＣＬＩＥＮＴ００３”は、図４に示す情報を画面に表示する。

　これにより、ユーザ端末１００は、配送車の位置等、サービスのデータが更新されると、更新されたデータのうち、自身の近隣に存在する配送車の情報だけを取得することができる。

　次に、集荷を依頼したいユーザが図３または図４に示す画面において「集荷依頼」ボタン５００をクリックしたとする。これを契機にユーザ端末から配送業者のサービス提供サーバ３２０にユーザ端末１００の端末識別子を含む配車要求が通知される。配送業者の配送センターではサービス提供サーバ３２０が受信した配車要求に従って、ユーザに対して配車を行い、ユーザに配車した配送車の識別情報を配車結果としてサービス提供サーバ３２０へ入力する。サービス提供サーバ３２０は配車情報サービス（サービス３２１）を実行し、マッシュアップ・プログラム２１０に対してユーザ端末１００の端末識別子とユーザに割り当てられた配送車の情報を通知し、ユーザ端末１００と当該配送車とを対応付ける判定基準の作成を要求する。更新要否判定プログラム２２０は、マッシュアップ・プログラム２１０が判定基準の作成要求を受信すると（ステップ１００１０：判定基準の作成要求）、新規の判定基準を作成して判定基準記憶装置２４０に記憶する（ステップ１００６０）とともに、必要に応じて端末状態記憶装置２３０に記憶された端末状態を更新する（１００７０）。

　例えば、ユーザ端末１００“ＣＬＩＥＮＴ００３”のユーザが、集荷を依頼したとする。配送センターは、４０１“ＣＡＲ００１”を配車し、配車情報サービス(サービス３２１)は、マッシュアップ・プログラム２１０に対して、ユーザ端末１００“ＣＬＩＥＮＴ００３”と４０１“ＣＡＲ００１”を通知し、判定基準の作成を要求する。更新要否判定プログラム２２０は、図９に示すように＃２「ＩＳ＿ＡＬＬＯＣＡＴＥＤ（ＣＡＲ、ＣＬＩＥＮＴ）」という新規の判定基準を作成して判定基準記憶装置２４０に記憶する。これは、「ユーザに対して配送車が配車されている場合、当該配送車の情報を当該ユーザ端末に配信」することを意味する。要求更新判定プログラムはまた、端末状態記憶装置２３０に記憶された端末情報を更新する。ここでは、図７に示すように、端末識別番号“ＣＬＩＥＮＴ００３”のユーザ端末について、配車情報として「配車＝ＣＡＲ００１」を記憶する。

　次にマッシュアップ・プログラム２１０が、各サービス提供サーバ３００、３１０、３２０に各サービス３０１、３１１、３２１を実行させて、実行結果を取得する（ステップ１００３０）。ここでは、サービス提供サーバ３００に道路地図サービス３０１を実行させて地図情報を取得し、サービス提供サーバ３１０に道路情報サービス３１１を実行させて渋滞等の交通状況情報を取得し、サービス提供サーバ３２０に配車情報サービス３２１を実行させて配送車の位置情報を取得する。

　更新要否判定プログラム２２０は、判定基準記憶装置２４０と端末状態記憶装置２３０を参照し、端末状態記憶装置２３０に記憶された全てのユーザ端末１００に対して配信すべき情報を更新する（ステップ１００４０）。マッシュアップ・プログラム２１０は、情報の更新があったユーザ端末１００に対して、ステップ１００３０で取得したサービスの実行結果のうち１００４０で当該ユーザ端末用に切り出した情報を、通信装置２０４０、１０４０を経由して配信する（ステップ１００５０）。
例えばここでは、図９に示すように、判定基準装置２４０に、＃１「ユーザ端末の位置から半径５ｋｍ以内の配送車の情報を配信」と＃２「ＣＬＩＥＮＴ００３にはＣＡＲ００１を配車」という２つの判定基準が記憶されている。これらはそれぞれ、「配送車とユーザ端末の距離が５ｋｍ以内の場合、当該配送車の情報を当該ユーザ端末に配信」することと「ユーザに対して配送車が配車されている場合、当該配送車の情報を当該ユーザ端末に配信」することを意味する。また、ステップ９０３０において、配送車４０１“ＣＡＲ００１”、４０２“ＣＡＲ００２”、４０３“ＣＡＲ００３”の位置情報を取得したとする。このうち、判定基準＃１を満たす配送車として、４０１“ＣＡＲ００１”と４０３“ＣＡＲ００３”はユーザ端末１００“ＣＬＩＥＮＴ００３”の半径５ｋｍ以内に存在するとする。一方、判定基準＃２を満たす配送車は４０１“ＣＡＲ００１”であるため、更新要否判定プログラム２２０は、ユーザ端末１００“ＣＬＩＥＮＴ００３”に対しては、配送車４０１“ＣＡＲ００１”の位置情報を配信すると判定する。そこで、マッシュアップ・プログラム２１０は、ユーザ端末１００“ＣＬＩＥＮＴ００３”に対しては、配送車４０１“ＣＡＲ００１”の位置情報のみを切り出して配信する。サービスの実行結果を受信したユーザ端末１００は、その内容をブラウザ１０１に表示する。例えば、ユーザ端末１００“ＣＬＩＥＮＴ００３”は、図５に示す情報を画面に表示する。

　これにより、集荷依頼する前のユーザ端末１００には、近隣の全ての配送車の位置情報が表示されるが、集荷依頼後は、集荷に訪れる配送車の位置情報のみをユーザ端末に提示することができる。

　以上、図１から図１０を用いて、本発明の実施の形態を説明した。

　本実施形態によれば、ユーザ端末１００の近隣の情報のみ配信されるため、処理性能が低く画面表示領域が狭い携帯端末のような環境において不要な情報を受信・処理するためのリソースの消費を低減できる。また、不要な情報の配信を回避できるため、無駄なネットワーク・トラフィックの発生を低減できる。

　また、本実施形態によれば、アプリケーションの利用段階の変化に応じてユーザ端末１００が必要とする情報の変化に対応できるため、上記のリソースやネットワーク・トラフィックの低減といった効果以外に、不要な情報を除去できるという効果がある。

　また、本実施形態によれば、サービス提供サーバ３２０上で実行している配車情報サービス（サービス３２１）が、マッシュアップ・サーバに判定基準の作成を要求し、それによってユーザ端末１００に送信する情報を変更しているため、ユーザ端末上のブラウザで実行するプログラムの修正をしなくても、ブラウザに送信する必要のない情報を除去できるという効果がある。

　本実施形態の他の実施形態として、ステップ１００３０において、各サービス３０１、３１１，３２１のデータに更新がない場合は、サービスの実行ならびに結果の取得を行わず、前回の結果取得時にあらかじめメモリ２０２０または外部記憶装置２０３０に記憶したキャッシュデータを利用することも可能である。

　上記実施例では、集荷を依頼したいユーザが図３または図４に示す画面において「集荷依頼」ボタン５００をクリックし、ユーザ端末が、配送業者のサービス提供サーバ３２０にユーザ端末１００の端末識別子を通知しているが、配送業者の配送センターに集荷を依頼するとともにユーザ端末１００の端末識別子を伝えることができれば良いので、集荷依頼と端末識別子の通知は電話などの他の手段で行うこととしても良い。
以下、本発明の他の実施形態を説明する。
本実施形態において図１と図２、図５から図１０は、上記実施例と同じである。
図１１と図１２は、本実施形態におけるマッシュアップ・アプリケーションの出力画面例を示す図である。マッシュアップ・アプリケーションの一例として、配送業者が提供する集荷支援のためのマッシュアップ・アプリケーションを例に出力画面を示している。

　図１１は、配送業者に集荷依頼する前の、或るユーザ端末１００に表示される情報の例を示す図である。図１１に示す画面には、ユーザの位置を中心とし、近隣を走行中の配送車の位置が表示されている。

　図１２は、配送業者に集荷依頼した後の、ユーザ端末１００に表示される情報の例を示す図である。図１２に示す画面には、配送センターが配車を行った結果として、集荷に訪れる予定の配送車の位置が表示される。配送車が決定した時点で、それ以外の配送車の情報は不要となりユーザ端末１００には表示されない。

　以下、本発明の実施の形態を図１０を用いて説明する。尚、処理の大部分は実施例１と同様なので、以下実施例１とは異なる部分のみを説明する。
まずステップ１００５０でマッシュアップ・サーバ２００からユーザ端末１００に送信され、ユーザ端末上に表示される画面情報が本実施例では実施例１とは若干異なり、例えば、ユーザ端末１００“ＣＬＩＥＮＴ００３”は、図１１に示す画面を表示する。実施例１とは異なり、画面上に集荷依頼ボタン５００がない。

　集荷依頼ボタン５００がないので、集荷を依頼したいユーザは、配送業者の配送センターに、電話または電子メールを用いて、ユーザ端末１００の端末識別子を通知したとする。配送センターでは、配車を行い、ユーザから通知された端末識別子と当該ユーザに割り当てた配送車の識別情報とをサービス提供サーバ３２０に入力し、サービス提供サーバ３２０は配車情報サービス（サービス３２１）を実行し、マッシュアップ・プログラム２１０に対してユーザ端末１００の端末識別子と配送車の情報を通知し、ユーザ端末１００と配送車とを対応付ける判定基準の作成を要求する。その後の処理は実施例１と同様である。
マッシュアップサーバ２００においてステップ１００６０、１００７０、１００３０、１００４０、１００５０が実行された結果、本実施形態では例えば、ユーザ端末１００“ＣＬＩＥＮＴ００３”は、図１２に示す情報を画面に表示する。

　これにより、集荷依頼する前のユーザ端末１００には、近隣の全ての配送車の位置情報が表示されるが、集荷依頼後は、集荷に訪れる配送車の位置情報のみを取得することができる。

　以上、図１と図２、図５から図１０、図１１と図１２を用いて本発明の実施の形態を説明した。

　本実施形態によれば、上記、第一の実施例の効果があることは無論のこと、集荷支援のためのアプリケーションに組み込まれていない機能を反映した情報を得ることができる。本実施例の集荷支援のためのアプリケーションには、ユーザの集荷依頼を示す「集荷依頼」ボタン５００がなく、ユーザ端末１００の端末識別子を配送センターに伝えていない。これらの情報を他の手段で代替した場合でも、集荷依頼する前のユーザ端末１００には、近隣の全ての配送車の位置情報が表示されるが、集荷依頼後は、集荷に訪れる配送車の位置情報のみを取得することができる。

１０１、１０２…ブラウザ、
２１０…マッシュアップ・プログラム、
２２０…更新要否判定プログラム、
２３０…端末状態記憶装置、
２４０…判定基準記憶装置、
３０１、３１１、３２１…サービス

Claims

　ユーザ端末と、各々ユーザ端末に対して情報を提供する複数のサービスサーバとに通信可能に接続されるマッシュアップサーバであって、
　前記ユーザ端末の端末状態を記憶する端末状態記憶装置と、
　前記複数のサービスサーバから受け取ったサービスの実行結果情報のうち、前記ユーザ端末へ配信すべき実行結果情報を選択する際に用いる判定基準を記憶する判定基準記憶装置と、
　処理装置とを有しており、
　前記処理装置は、前記端末状態と前記判定基準とを用いて、前記複数のサービスサーバ各々について、当該サービスサーバから受信した実行結果情報のうち前記ユーザ端末に配信すべき情報を選択し、選択された各実行結果情報が合わせて前記ユーザ端末の画面に表示されるよう当該ユーザ端末へ配信することを特徴とするマッシュアップサーバ。
　請求項１記載のマッシュアップサーバであって、
　前記処理装置は、前記ユーザ端末から端末識別情報と当該端末の位置情報を受信すると、前記端末状態記憶装置に記憶された端末状態を更新し、
　更新された前記端末状態と前記判定基準とを用いて、前記複数のサービスサーバ各々について、当該サービスサーバから受信した実行結果情報のうち前記ユーザ端末に配信すべき実行結果情報を選択し、選択の結果前記ユーザ端末に配信すべき実行結果情報に更新が生じた場合に当該ユーザ端末へ選択された実行結果情報を配信することを特徴とするマッシュアップサーバ。
　請求項２記載のマッシュアップサーバであって、
　前記処理装置は、前記複数のサービスサーバ各々から、当該サービスサーバが提供するサービスの実行結果情報の更新を受けつけ、
　前記端末状態と前記判定基準とを用いて、更新された前記実行結果情報のうち前記ユーザ端末に配信すべき実行結果情報を選択し、選択の結果前記ユーザ端末に配信すべき実行結果情報に更新が生じた場合に当該ユーザ端末へ選択された実行結果情報を配信することを特徴とするマッシュアップサーバ。
　請求項３記載のマッシュアップサーバであって、
　前記処理装置は、前記判定基準の作成要求を受信して、当該作成要求に基いて前記判定基準記憶装置に記録されている前記判定基準を更新し、
　前記端末状態と更新された前記判定基準とを用いて、前記複数のサービスサーバ各々について、当該サービスサーバから受信した実行結果情報のうち前記ユーザ端末に配信すべき実行結果情報を選択し、選択の結果前記端末に配信すべき実行結果情報に更新が生じた場合に当該ユーザ端末へ選択された実行結果情報を配信することを特徴とするマッシュアップサーバ。
　請求項４記載のマッシュアップサーバであって、
　前記複数のサービス提供サーバには、地図情報を提供する地図情報提供サーバと、道路状態情報を提供する道路状態提供サーバと、配送車の所在地情報を提供する配送車情報提供サーバとが含まれており、
　前記処理装置は、前記ユーザ端末の位置情報を用いて、前記ユーザ端末から前記判定基準で示される距離以内の地図情報を前記地図情報提供サーバから受信した情報から選択し、
前記ユーザ端末から前記判定基準で示される距離以内の道路状態情報を前記道路状態提供サーバから受信した道路状態情報から選択し、
前記ユーザ端末から前記判定基準で示される距離以内のに存在する配送車の所在地情報を、前記配送車情報提供サーバから受信した所在地情報から選択し、
選択された情報を合わせて前記ユーザ端末に配信することを特徴とするマッシュアップサーバ。
　請求項５記載のマッシュアップサーバであって、
　前記処理装置は、前記ユーザ端末の位置情報が更新された場合に、更新後の前記位置情報を用いて、前記複数のサービス提供サーバ各々から受信した実行結果情報の内、前記ユーザ端末から前記判定基準で示される距離以内の地域に関する実行結果情報を選択し、選択された実行結果情報を合わせて前記ユーザ端末に配信することを特徴とするマッシュアップサーバ。
　請求項５記載のマッシュアップサーバであって、
　前記処理装置は、前記配送車情報提供サーバから前記配送車の所在地の更新情報を受信した場合に、更新された配送車の所在地情報に基いて、前記ユーザ端末から前記判定基準で示される距離以内に存在する配送車の所在地情報を選択し、選択された所在地情報を前記ユーザ端末に配信することを特徴とするマッシュアップサーバ。
　請求項５記載のマッシュアップサーバであって、
　前記処理装置は、前記配送車情報提供サーバから前記ユーザ端末の利用者に対して割り当てられた配送車の識別情報を受信した場合に、当該ユーザ端末に対して当該配送車の所在地情報を表示させるよう前記判定基準を更新し、
更新後の当該判定基準に基づいて、前記配送車情報提供サーバから受信した情報の内、前記ユーザ端末の利用者に割り当てられた前記配送車の所在地情報のみを前記ユーザ端末に配信することを特徴とするマッシュアップサーバ。