JP7549075B2 - 情報処理装置 - Google Patents

Description

本発明は、情報処理装置に関する。

自家用車を所有することは、自動車を利用する頻度がそれほど高くない者にとっては、不経済である。
そこで、従来より、マンション等で、一台の自動車を複数のユーザで共同使用するカーシェアリングサービスが存在していた（例えば、特許文献１、２参照）。

特開平１１－３３７３５４号公報 特開２０１２－１１８７０５号公報

しかしながら、従来のようなカーシェアリングサービスは、ユーザ自身が運転者となることが前提であり、高齢者等の場合に自動車を自ら運転することができなかったり、運転できたとしても安全上の懸念が有ることが、課題となっていた。

本発明は、このような状況に鑑みてなされたものであり、高齢者等が利用しやすいサービスを提供することを目的とする。

上記目的を達成するため、本発明の一態様の情報処理装置は、
移動対象を乗せて移動体が所定エリア内で移動した際の対価が、所定の時間単位では、複数の区分のうち設定された区分が同一の対価支払者にとって一定となるサービスの提供を支援する情報処理装置であって、
複数の対価支払者から、前記移動体の利用の要請の夫々を受け付ける要請受付手段と、
前記複数の対価支払者の夫々からの前記要請の内容及び当該複数の対価支払者の夫々に設定された前記区分に基づいて、前記移動体による輸送の計画を立案する輸送計画手段と、
を備える。

本発明によれば、高齢者等が利用しやすいサービスを提供することができる。

本発明の一実施形態に係る定額タクシーの配車対応地域について説明する図である。 本発明の一実施形態に係る情報処理システムの構成を示す図である。 図２の情報処理システムのうちサーバのハードウェア構成を示すブロック図である。 図３のサーバの機能的構成を示す機能ブロック図である。 図４の機能的構成を有するサーバ１により実現される本サービスが提供されるユーザの対価の第１の例を説明する図である。 図２の情報処理システムが適用されたタクシーシェアリングサービスの概要を示す図である。 図６のタクシーシェアリングサービスの利用料金体系の概要を示す図である。 図６のタクシーシェアリングサービスが提供される場合における図３のサーバの機能的構成を示す機能ブロック図である。 図８の機能的構成を有するサーバの一連の処理のうち、乗車ポイント算出処理の流れの一例を説明するフローチャートである。 図８の機能的構成を有するサーバの一連の処理のうち、予約ポイント算出処理の流れの一例を説明するフローチャートである。

ここで、本発明の実施形態について、説明するに先立ち、簡単に本発明の前提となるサービス全般について説明する。

日本は４人に１人が６５歳以上という超高齢化社会を迎え、医療や福祉などに関する問題だけでなく、交通に関する問題も生じるようになっている。具体的に例えば、国土交通省による調査結果によれば、６５歳から７４歳では、一日に５００ｍ程度以上の歩行が困難な割合が２割程度、７５歳以上では、５割に程度に上るとされている。

他方、高齢者の運転による交通事故は年々増加しており、今後も増加すると予測される。高齢化の進展と共に７５歳以上の運転免許保有者数は、２０１８年には５３３万人に達すると予測されており、高齢者が運転をしなくても問題なく生活できる環境作りについて対策する必要がある。その対策の１つとして、たとえば、中心部に様々な機能を集約し、市街地をコンパクトな規模に収めた都市形態（コンパクトシティー）が考えられるが、特に地方部では各種拠点や住居が散在しているため、実現が難しい。

このような状況のため、特に地方の高齢者においては、「加齢とともに歩いて移動できる距離が短くなる」、「交通事故は怖いが、車を運転できないと生活に支障をきたす」、「近所づきあいがなく家に閉じこもったり、何かあったときに頼れる人がいない」等の問題や悩みを抱えている場合が多い。

さらに言えば、高齢者は勿論、一般の人々にとって、自家用車の購入や維持には、高額の費用が掛かるのが通常である。

そこで、高齢者の地域生活支援のため、見守り支援、地域生活支援、地域移動支援（自由に地域内を移動）の価値を提供するプラットフォームを構築し、高齢者向けに複合的なサービスを提供することが求められている。

本発明に係る一実施形態の情報処理システムの適用対象となるサービス（以下、「本サービス」と呼ぶ）は、高齢者を初めとするユーザにとっては、「自由で欲のある生活」や「生きがいあふれる人生」を実現し、サービスを提供する者（後述するサービス提供者の従業員等）にとっては、「活かされている」、「実感・やりがい」を持ってサービスを実施するような「生きがいの循環」を目指すものである。

続いて、このような「生きがいの循環」を目指すにあたり、構築される地域生活支援プラットフォームについて、簡単に説明する。
地域生活支援プラットフォームとは、本サービスの提供者等により提案されたサービスであり、他の事業者等と連携し、高齢者等向けに複合的サービスを提供するサービス提供プラットフォームである。
即ち、「見守り支援」、「地域生活支援」、「所定の地域内を自由に移動」といった価値を高齢者等に対して提供する。
具体的に、地域生活支援プラットフォームには、例えば、「コンシェルジュ」、「地域移動支援」、「地域情報の集約・提供」、「お出かけチケット（地域通貨）提供」等のサービスが含まれる。

以上、本発明の一実施形態の説明に先立ち、簡単に本発明の前提となるサービス全般について説明した。なお、以降の説明においては、上述の各種サービスのうち「地域移動支援」に関連する「定額タクシー」のサービスを採用した場合の例を中心として説明する。

ここで、定額タクシーについて説明する。地域移動支援サービスにおいて、所定のタクシーを利用して所定地域内で移動する際の対価は、当該所定地域内で一律に設定されている。このように、対価が一律に設定されているタクシーを定額タクシーと称する。
ここで、一律とは、乗客を乗せてタクシーが所定地域内で移動した際の対価が、所定の時間単位（例えば１ヶ月）では一定となることをいう。ただし、所定の時間単位（例えば１ヶ月）あたりの対価は、全ての人にとって同一でなく、松竹梅の３区分等のように複数区分が設定されている場合には、区分毎に異なることになる。
なお、以下の例では、本サービスを利用する者（以下、「ユーザ」と呼ぶ）は、毎月一定の金額（例えば、区分毎に決定される金額）を支払うことで、定額タクシーを利用するものとする。
これによりユーザは、月々決まった金額を支払うだけで、所定の地域内であれば、料金を気にせず、自由に定額タクシーを利用して移動することができる。

以下、図面を参照しながら、本発明の第一実施形態について説明する。

図１は、本発明の一実施形態に係る定額タクシーの配車対応地域について説明する図である。
図１では、地域Ａ１，Ａ２が示されている。なお、地域は例示であって、これに限定されず、任意の範囲の領域、即ち「エリア」であってよい。

ここで、定額タクシーの夫々は、予め決められた地域を担当し、その地域内を移動するようになっている。例えば、図１の場合では、地域Ａ１に配車された定額タクシーは地域Ａ１内を移動し、地域Ａ２に配車された定額タクシーＴ－１，Ｔ－２は地域Ａ２内を移動する。
定額タクシーの運転手も、予め決められた地域を担当し、原則として、当該地域を担当する定額タクシーを運転するものとする。例えば、地域Ａ２では、３人の運転手が交代で、定額タクシーＴ－１，Ｔ－２の夫々を運転するものとする。
ユーザは、自宅等が含まれる地域（例えば地域Ａ２）を設定し、毎月一定の金額（例えば、３万円）を支払うことで、設定した地域を担当する定額タクシー（例えば地域Ａ２では定額タクシーＴ－１，Ｔ－２）に限り、設定した地域内で（区分毎に設定された乗り方の範囲内で）自由に利用することができる。

図１では、地域Ａ２を担当する定額タクシーＴ－１、Ｔ－２のみが図示されているが、地域Ａ１にも、同様に所定台数（例えば２台）の定額タクシーが担当する。
地域Ａ２の例では、例えば運転手３名が交代で、定額タクシーＴ－１、Ｔ－２の２台を運転する。
この様に、運転手は、所定の一地域のみを担当させ、かつ、ある程度少数の者に限定とする好適である。ユーザと運転手とにおいて濃い人間関係を形成し、ユーザに安心感を与えることが可能となるからである。

図２は、本発明の一実施形態に係る情報処理システムの構成を示す図である。

情報処理システムは、図２に示すように、本サービスの提供者により管理されるサーバ１と、ユーザ端末２－１乃至２－ｍ（ｍは任意の整数）と、定額タクシーＴ－１乃至Ｔ－ｎ（ｎは任意の整数）の夫々に搭載されているタクシー端末３－１乃至３－ｎ（ｎは任意の整数）とを含むように構成される。

サーバ１と、ユーザ端末２－１乃至２－ｍの夫々と、タクシー端末３－１乃至３－ｎの夫々とは、インターネット等の所定のネットワークＮを介して相互に接続される。

なお、以下、ユーザ端末２－１乃至２－ｍの夫々を個々に区別する必要がない場合、これらをまとめて「ユーザ端末２」と呼ぶ。また、定額タクシーＴ－１乃至Ｔ－ｎの夫々を個々に区別する必要がない場合、これらをまとめて「定額タクシーＴ」と呼ぶ。定額タクシーＴと呼んでいる場合には、タクシー端末３－１乃至３－ｎをまとめて「タクシー端末３」と呼ぶ。

図３は、図２の情報処理システムのうちサーバのハードウェア構成を示すブロック図である。

サーバ１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１２と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１３と、バス１４と、入出力インターフェース１５と、出力部１６と、入力部１７と、記憶部１８と、通信部１９と、ドライブ２０とを備えている。

ＣＰＵ１１は、ＲＯＭ１２に記録されているプログラム、又は、記憶部１８からＲＡＭ１３にロードされたプログラムに従って各種の処理を実行する。

ＲＡＭ１３には、ＣＰＵ１１が各種の処理を実行する上において必要なデータ等も適宜記憶される。

ＣＰＵ１１、ＲＯＭ１２及びＲＡＭ１３は、バス１４を介して相互に接続されている。このバス１４にはまた、入出力インターフェース１５も接続されている。入出力インターフェース１５には、出力部１６、入力部１７、記憶部１８、通信部１９、ドライブ２０が接続されている。

出力部１６は、スピーカや表示部等から構成され、各種情報を画像や音声として出力する。
入力部１７は、キーボードやマウス等から構成され、各種情報を入力する。

記憶部１８は、ＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等で構成され、各種データを記憶する。
通信部１９は、インターネットを含むネットワークＮを介して他の装置（図２の例ではユーザ端末２及びタクシー端末３）との間で行う通信を制御する。

ドライブ２０には、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリ等よりなる、リムーバブルメディア３１が適宜装着される。ドライブ２０によってリムーバブルメディア３１から読み出されたプログラムは、必要に応じて記憶部１８にインストールされる。また、リムーバブルメディア３１は、記憶部１８に記憶されている各種データを、記憶することができる。

ユーザ端末２又はタクシー端末３の構成は、タッチパネルディスプレイを備える場合が有る点を除いてサーバ１の構成と基本的に同様であるので、ここではそれらの説明は省略する。

図４は、図３のサーバの機能的構成を示す機能ブロック図である。
サーバ１のＣＰＵ１１においては、要請受付部４１と、配車計画部４２と、配車指示部４３とが機能する。
記憶部１８の一領域として、ユーザＤＢ５１と、要請ＤＢ５２と、配車計画ＤＢ５３とが設けられている。

要請受付部４１は、複数の対価支払者（ここでは、所定の地域を設定した複数のユーザ）から、定額タクシーＴの利用の要請の夫々を受け付ける。
即ち、要請受付部４１は、通信部１９を介して、複数のユーザの夫々のユーザ端末２から、定額タクシーＴの利用の要請（要請には、事前予約も、即時乗車希望も含む）の夫々を受け付け、複数のユーザの夫々の区分と対応付けて要請ＤＢ５２に蓄積する。なお、区分は、詳細について後述するが、各ユーザの属性情報の１つとしてユーザＤＢ５１に記憶されている。

配車計画部４２は、複数のユーザの夫々からの要請の内容及び当該複数のユーザの夫々に設定された区分に基づいて、所定の地域における定額タクシーＴによる輸送の計画を立案し、配車計画ＤＢ５３に記憶させる。
また、配車計画部４２は、通信部１９を介して、複数のユーザの夫々のユーザ端末２に対して、要請の可否を通知する。

配車指示部４３は、所定の地域における定額タクシーＴによる輸送の計画を配車計画ＤＢ５３から参照して、これに基づいて当該所定の地域を担当する定額タクシーＴの配車の指示を生成し、当該定額タクシーＴのタクシー端末３に対して通信部１９を介して通知する。

以下、図４の機能的構成を有するサーバ１により実現される本サービスが提供されるユーザの対価の各種例について説明する。

図５は、図４の機能的構成を有するサーバ１により実現される本サービスが提供されるユーザの対価の第１の例を説明する図である。
第１の例では、所定の地域での定額タクシーＴを利用するに際し、月額固定の利用プランに複数の区分を設ける料金体系が採用されている。ユーザは、会費とサービス内容とを比較考慮して、自身に適した区分を自由に選択することができる。なお、複数の地域からユーザの定額タクシーＴを利用する地域として当該ユーザにより選択された地域は、図５の例では「適用地域」とされている。
図５の例では、月額固定の利用プランにおける区分として、特松（プレミアム会員、月額７万円）、松（通常会員、月額３万円）、竹（タブレット会員、月額２万円）、及び梅（無料会員、月額０円）の４区分が設定されている。

例えば、月額７万円の特松プランでは、ユーザは、プレミアム会員として、適用地域内であれば、いつでも定額タクシーＴが乗り放題となる。

また例えば、月額３万円の松プランでは、ユーザは通常会員として、適用地域内であれば、次のような第１乃至第３の利用方法で定額タクシーＴを利用できる。第１の利用方法は、前月までの事前予約タクシー乗り放題となるものである。第２の利用方法は、前日までの事前予約タクシーも、随時乗車可能となるものである。第３の利用方法は、当日の依頼でも、随時乗車可能となるものである。

また例えば、月額２万円の竹プランでは、ユーザはタブレット会員として、適用地域であれば、次のような第４乃至第６の利用方法で定額タクシーＴを利用できる。第４の利用方法は、前月までの事前予約タクシー乗り放題となるものである。第５の利用方法は、前日までの事前予約タクシーも、随時乗車可能となるものである。第６の利用方法は、当日の依頼も、随時乗車可能となるものである。

また例えば、無料の梅プランにおいては、ユーザは、無料会員として、定額タクシーＴの乗車はできないものの、ユーザ端末２がスマートフォン等である場合にそれにインストールされるアプリケーション（図５の例では「スマホ用アプリ」と記載）を用いて、ユーザ登録情報に向けた（マッチングさせた）地域情報の提供を受けることができる。

以上まとめると、図５の例のように複数の区分が設けられた本サービスの提供を可能となる情報処理装置は、上述の実施形態のサーバ１を含め各種各様な実施形態を取ることができる。
ここで、本発明が適用される情報処理装置が提供可能なサービスとしては、上述の例では、定額タクシーＴを利用する本サービスを採用したがこれに限定されず、移動対象を乗せて移動体が所定エリア内で移動した際の対価が、所定の時間単位では、複数の区分のうち設定された区分が同一の対価支払者にとって一定となるサービスであれば足り、任意のサービスを提供することができる。

即ち、本サービスが提供される情報処理装置は、
移動対象を乗せて移動体（例えば図２の定額タクシーＴ－１，Ｔ－２）が所定エリア（例えば図１の地域Ａ２）内で移動した際の対価が、所定の時間単位（例えば１ヶ月単位）では、複数の区分（例えば図５の例の区分）のうち設定された区分が同一の対価支払者（例えばユーザ）にとって一定となるサービス（例えば定額タクシーＴを利用する本サービス）の提供を支援する情報処理装置（例えば図３のサーバ１）であって、
複数の対価支払者から、前記移動体の利用の要請（要請には、事前予約も、即乗車希望も含む）の夫々を受け付ける要請受付手段（例えば図４の要請受付部４１）と、
前記複数の対価支払者の夫々からの前記要請の内容及び当該複数の対価支払者の夫々に設定された前記区分に基づいて、前記移動体による輸送の計画を立案する輸送計画手段（例えば図４の配車計画部４２）と、
を備えれば足りる。
これにより、区分に応じて利便性を享受することができる定額輸送サービスを提供することができる。

ここで、定額タクシーＴに一度に乗れるユーザを１人に限定した場合、同一の地域内の同一時間帯に、当該地域に配置される定額タクシーＴの台数を超えるユーザからの要請があった場合、全ての要請に応えることはできない。
かかる場合に、配車計画部４２は、所定のルールに基づき、一部の要請を却下して、定額タクシーＴによる輸送の計画を立案することができる。
所定のルールとしては、例えばユーザの区分を優先するルールを採用することができるが、特に限定されない。
その他、例えば、相乗りを許す場合の相乗り乗車人数、先行要請期間（早期予約）、乗降車地点（タクシー乗り場利用等）、利用目的の緊急度、ユーザの身体的不自由度や健康状態、年齢、性別、居所の利便性等を考慮した任意のルールを採用することができる。

ここで、定額タクシーＴに乗れるユーザの人数は、１人に限定される必要は特になく、複数人でよい。

ここで、複数人を輸送するサービスとしては、カーシェアリングサービスが存在する。しかしながら、カーシェアリングサービスは、高齢者等を対象とするサービスとしては不適である。高齢者等が、自動車を自ら運転することには安全上の懸念があるためである。
そこで、このような高齢者等のために、上述の定額タクシーＴを、同一の適用地域内の複数のユーザでシェアして乗車することが可能なサービス（以下、「タクシーシェアリングサービス」と呼ぶ）が好適である。

なお、タクシーシェアリングサービスは、定額タクシーＴのみならず、通常のタクシー料金の体系、即ち、乗車距離と乗車時間との連動性で料金を演算する体系を採用したタクシーを利用することもできる。
ただし、タクシーシェアリングサービスに対して、通常のタクシー料金の体系をそのまま適用するのは不適である。即ち、従来のタクシー料金の演算手法を、タクシーシェアリングサービスにそのまま採用すると、タクシー会社としては需要ピーク時の収益機会を奪われることとなり、ユーザにとっても経済的にメリットが薄くなってしまう。

そこて、本実施形態では、定額タクシーＴを集団で共用しつつ、更にポイント制を導入することにより、一部のユーザによる独占的利用を制限しつつ、閑散時の余剰台数の活用を図ることにしている。
つまり、第一に、一部のユーザばかりに利用が集中すると、コミュニティ内に不公平感が生じることとなる。
また、第二に、タクシー会社側とユーザの双方が経済的恩恵を享受したい。
そのため、本実施形態では、ポイント消費量のベースとして乗車距離と乗車時間を採用しつつ、その他の要素（コンテクスト、予約有無）を加味して、消費ポイントが変動するポイント制が採用されている。

なお、本明細書においては、コンテクスト（ｃｏｎｔｅｘｔ）とは、定額タクシーＴの内的状態および外的状態の全てを指す。定額タクシーＴの内的状態とは、定額タクシーＴの車種、年式、型式、または、運転手の体調、運転技能若しくは接客態度等を指す。また、定額タクシーＴの外的状態とは、定額タクシーＴの稼働状況、道路交通状況、路面状況、空間的または時間的な配置位置（時間的な配置位置とは、例えば、現在時刻を指す）の他、定額タクシーＴの周囲の空間方向若しくは時間方向に分布する（または、いずれの方向にも分布する）所定の状態も指す。

ここで、本実施例においては、タクシーシェアリングサービスの地理的提供範囲は、地域限定とする。
この様にすることにより、ユーザと提供者、及びユーザ同士において、濃い人間関係が形成されることとなり、ユーザに安心感を与えることができる。

また、本実施例においては、タクシーシェアリングサービスの対価は、定額ポイント制とする。定額ポイント制については、例えば月額制であって良く、ヘビーユーザ向けの高額プランからライトユーザ向けの低額プランまで、複数の定額料金プランを設定することができる。
本実施例においては、高額プランのユーザと低額プランのユーザで配車要請又は予約が競合した場合は、高額プランのユーザの配車要請等が優先される。

ここで、ポイントは必ずしも定額タクシーＴの利用により消費するものではなく、他のサービスに流用するものでもよい。
例えば、ユーザが定額タクシーＴを利用して通院した際に、ユーザが受診する間の時間を利用した買い物等の代行サービスを運転手に依頼して、ポイントを消費できて良い。
この様にすることにより、ユーザは、定額タクシーＴを単なる移動手段ではなく、ポイントを消費して多様な要求に柔軟に応じる便利屋（介助屋）の如きサービスとして、利用できることとなる。
また、ユーザは、運転手を指名できることとし、サービスを利用する度に要求を伝達する手間を省くことを、可能として良い。
この様にすることにより、ユーザは運転手とは次第に懇意となり、運転手は当該ユーザの様々な事情を理解でき、その事情に応じた様々なサービスの提案をしていくことが、可能となる。
なお、ユーザによる運転手の指名については、ポイントを消費させることとして良い。
また更に、前回乗車時の話題、依頼等に基づいて話題を提供する、支援システムを導入して良い。

図６は、図２の情報処理システムが適用されたタクシーシェアリングサービスの概要を示す図である。
図６においては、タクシーシェアリングサービスの一例として、同一領域内の１０人のユーザからなるコミュニティＣで、ｎ台（ｎは、１以上の任意の整数値）の定額タクシーＴ－１乃至Ｔ－ｎが利用される例を示している。
ここで、定額タクシーＴ－１乃至Ｔ－（ａ－１）（ａは、１以上ｎ以下の任意の整数値）は乗客が乗車中であり、定額タクシーＴ－ａ乃至Ｔ－ｎは、運転手のみが乗車する空車状態であることを示している。
１台の定額タクシーＴ－１には、コミュニティＣのユーザＵ１乃至Ｕ３の３人が相乗りをしている。
この場面において、コミュニティＣの別のユーザＵ４が乗車を希望する場合、乗車中状態の定額タクシーＴ－１乃至Ｔ－（ａ－１）への相乗りが可能であれば、消費対価量（例えばポイント）を低く抑えることができる。
一方、空車状態である定額タクシーＴ－ａ乃至Ｔ－ｎへの単独乗車が可能であれば、空車状態であるタクシーの中から、例えば最も早くユーザＵ４を乗車させることができる１台として定額タクシーＴ－ａが選出され、速やかに目的地まで移動することができる。
図６の一例ではユーザＵ４は、空車状態である定額タクシーＴ－ａに単独乗車し、一人でタクシー１台分の消費対価量を負担する。
一方、１台の定額タクシーＴ－１に相乗りしているユーザＵ１乃至Ｕ３の３人は、タクシー１台分の消費対価量を分担して負担することができる。
なお、本明細書において相乗りとは、同時乗車同時下車の場合に限定せず、途中乗車又は途中下車による相乗りを含む。

図７は、図６のタクシーシェアリングサービスの利用料金体系の概要を示す図である。
図７（ａ）は、タクシーシェアリングサービスを利用した一のユーザについての利用状況とこれに対応する消費ポイント明細を示す図である。
タクシーに乗車したユーザが消費するポイントについては、例えば乗車距離や乗車時間等に連動する任意の算定方式を採用して良い。
以下では、１Ｋｍ（２分）の乗車で１ポイントを消費するものとして、説明する。
また、Ｎ台のタクシーのコンテクスト（状況）により、消費ポイントが増減調整される。

図７（ｂ）は、消費ポイント調整表の具体例を示す。
消費ポイント調整表における「＋α」とは、乗車距離と乗車時間を基準としたベースとなるポイント消費量に対して加える増減の調整量を表し、「＋」付きの数値はポイント消費量を加増させる量であることを意味し、「－」付きの数値はポイント消費量を減少させる量であることを意味する。

図７（ａ）の消費ポイント明細に戻り、「ｔｉｍｅ」項目は、昇順の時系列を意味する。
ｔｉｍｅ＝１において、ユーザは急いでいた為、優先的な配車を要請し、１０Ｋｍ、２０分間の乗車をし、その対価として４０ポイントを消費したことを、示している。
本実施例においては、ユーザは急ぎ度に応じて、消費ポイントを割高とすることにより優先的な配車を要請できることとしている。この急ぎ度は、０～１の値で指定する。
配車要請に際しては、前もって定額タクシーＴの現在使用状況を表示させ、確認することができる。
また、ｎ台の定額タクシーＴがフル稼働となり配車を待たされる場合や、キャンセル等により、配車要請が可能となった場合等には、ユーザに報知を行う。
なお、年金支給情報等のユーザが関心を持つと考えられるイベント情報についても、ユーザに表示又は報知を行う。
１０Ｋｍ（２０分間）の乗車により発生した１０ポイントを基に、優先配車によるポイントが別途発生しているためである。

図７（ｂ）の消費ポイント調整表によれば優先配車による発生ポイントは３０ポイントである為、消費ポイントの合計は４０ポイントとなっている。
ｔｉｍｅ＝２において、ユーザは通勤時間帯の４０分間に２０Ｋｍの乗車をし、その対価として３０ポイントを消費したことを、示している。
２０Ｋｍ（４０分間）の乗車により発生した２０ポイントを基に、通勤時間帯利用によるポイントが別途発生しているためである。
図７（ｂ）の消費ポイント調整表によれば通勤時間帯利用による発生ポイントは１０ポイントである為、消費ポイントの合計は１０ポイントとなっている。

ここで、高齢者には時間的束縛が少ない者が多く、本実施例においては閑散時間帯のポイント消費量を低く抑えて設定することにより、閑散時間帯の余剰台数の活用を図るが、有効期間内にポイントを消費する機会が無く、このままでは消滅してしまうポイントを余らせている場合も有る。
また、高齢者と言っても様々で、時間的束縛が多く、割高なポイント消費が苦にならない経済状況の者も居るので、その様な場合には割高であっても、経済性を度外視して時間帯制限が無く利用できる方が、ユーザにとっては便宜である。
本実施例は、上記の点を考慮したものとなっている。

ｔｉｍｅ＝３において、ユーザは閑散時間帯の６０分間に３０Ｋｍの乗車をし、その対価として２０ポイントを消費したことを、示している。
３０Ｋｍ（６０分間）の乗車により発生した３０ポイントを基に、閑散時間帯利用によるポイントが差し引かれているためである。
図７（ｂ）の消費ポイント調整表によれば閑散時間帯利用による発生ポイントはマイナス１０ポイントである為、消費ポイントの合計は２０ポイントとなっている。
ｔｉｍｅ＝４において、ユーザは閑散時間帯の４０分間に２０Ｋｍの乗車をし、その対価として３０ポイントを消費したことを、示している。
２０Ｋｍ（４０分間）の乗車により発生した２０ポイントを基に、当日予約によるポイントが別途発生し、閑散時間帯利用によるポイントが、差し引かれているためである。

本実施例において予約とは、申し込みにより、タクシー車両の利用を事前に確保しておくことをいう。
本実施例における予約は、利用日時、利用台数、乗車人数、乗車地、降車地等を指定して申し込み、利用日時までの期間が長い程、予約に伴う消費ポイントは少なくなる。
予約には、例えば利用日時に５時間等の調整幅を設けて申し込むことができ、当該調整幅が大きいほど、予約に伴う消費ポイントは少なくなる。
予約に際しては、前もって定額タクシーＴの予測使用状況及び予約状況を表示させ、予約可能時間を確認することができる。
また、ｎ台の定額タクシーＴがフル稼働となり予約出来ない場合や、キャンセル等により、予約が可能となった場合等には、ユーザに報知を行う。

図７（ｂ）の消費ポイント調整表によれば当日予約による発生ポイントは２０ポイントであり、閑散時間帯利用による発生ポイントはマイナス１０ポイントである為、消費ポイントの合計は３０ポイントとなっている。
ｔｉｍｅ＝３において、ユーザは６０分間に３０Ｋｍの他２名との相乗り乗車をし、その対価として１０ポイントを消費したことを、示している。
３０Ｋｍ（６０分間）の乗車により発生した３０ポイントが、乗車人数により３等分されているためである。

なお、図７（ｂ）の消費ポイント調整表には他にも、前日予約による発生ポイントは１０ポイントであり、前々日予約による発生ポイントは５ポイントであり、所定のタクシー乗り場の利用による発生ポイントはマイナス５ポイントであり、要介助の乗客による発生ポイントは１０ポイントであり、バトンタッチ乗降車（前の乗客と次の乗客が時間を置かず同じ場所で入れ替わり乗降車する）による発生ポイントはマイナス１０ポイントであり、時刻調整幅３時間以上の乗車予約による発生ポイントはマイナス５ポイントであり、時刻調整幅５時間以上の乗車予約による発生ポイントはマイナス１０ポイントであることが示されている。
また、消費ポイントの調整、上記の例では加減算により行ったが、例えば１．１を乗算（一割増し）する等の他の様々な演算により行って良い。

図７（ｃ）は、タクシーシェアリングサービスを利用した一のユーザについての消費ポイントと、利用金額との関係を示す図である。
所定の期間中に任意の消費ポイントまでは金額は一定であるが、それ以上の消費ポイントについては金額が連動して増加する。
図７（ｃ）の例では１００ポイントまでが定額利用となることを示している。
図７（ａ）の消費ポイント明細の例においては、ｔｉｍｅ＝１においては４０ポイントを消費し、定額利用の制限内となっている。
ｔｉｍｅ＝２においては３０ポイントを消費し、累計消費ポイントは７０ポイントとなる。この時点においても、定額利用の制限内となっている。
ｔｉｍｅ＝３においては更に２０ポイントを消費し、累計消費ポイントは９０ポイントとなる。この時点においても、定額利用の制限内となっている。
ｔｉｍｅ＝４においては更に３０ポイントを消費し、累計消費ポイントは１２０ポイントとなる。この時点で、定額利用の制限である１００ポイントを超過する為、当該ユーザは２０ポイント分の料金を追加負担することとなる。

図８は、タクシーシェアリングサービスが提供される場合における図３のサーバの機能的構成を示す機能ブロック図である。
なお、タクシーシェアリングサービスは、本実施形態では定額タクシーＴが前提となっているため、サーバ１のＣＰＵ１１において、上述の図４の機能ブロックも適宜機能する。
サーバ１のＣＰＵ１１においては、ポイント管理部１５０と、送迎実績取得部１５１と、コンテクスト取得部１５２と、乗車内容取得部１５３と、予約受付部１５４と、消費量算出部１５５と、コンテクスト提示部１５６とが機能する。
記憶部１８の一領域として、タクシー車両管理ＤＢ１７１と、ポイント管理ＤＢ１７２とが設けられている。

ポイント管理部１５０は、ポイント付与部１６１と、ポイント消費部１６２を更に備え、タクシーのサービスに対する乗客が支払う対価として使用可能なポイントを、乗客となり得るユーザ毎に管理する。
ポイント付与部１６１は、ユーザ毎に、料金プランに応じたポイントを付与する。
ポイント消費部１６２は、ユーザ毎に、後述する消費量算出部１５５により算出されたポイントを消費する。

送迎実績取得部１５１は、通信部１９を介して、タクシー端末３から定額タクシーＴの送迎実績情報を取得し、タクシー車両管理ＤＢ１７１に蓄積する。
コンテクスト取得部１５２は、タクシー車両管理ＤＢ１７１に蓄積された送迎実績情報から、定額タクシーＴに関するコンテクストを取得する。
乗車内容取得部１５３は、タクシー車両管理ＤＢ１７１に蓄積された送迎実績情報から、乗客が乗車している定額タクシーＴについての、乗車距離及び乗車時間を取得する。
予約受付部１５４は、タクシーの利用予約を通信部１９を介して、ユーザ端末２から受け付ける。

消費量算出部１５５は、コンテクスト取得部１５２及び乗車内容取得部１５３からコンテクスト、乗車距離、及び乗車時間を入力パラメータとして受け付け、乗客が支払う対価としての消費対価量（例えばポイント）を出力する所定の関数に基づいて、消費対価量（例えばポイント）を算出する。
また、消費量算出部１５５は、コンテクスト取得部１５２から受け付けたコンテクストに基づいて、予約受付部１５４から受け付けられた利用予約について、ユーザが支払う予約手数料としての消費対価量（例えばポイント）を算出する。

コンテクスト提示部１５６は、コンテクスト取得部１５２から受け付けたコンテクストの内容を、通信部１９を介して、ユーザ端末２へ送信する。

タクシー車両管理ＤＢ１７１は、タクシー車両を識別する情報と、タクシー車両に関する情報とを関連付けて記憶する。
ポイント管理ＤＢ１７２は、ユーザを識別する情報と、ユーザが保有するポイント情報とを関連付けて記憶する。

図９は、図８の機能的構成を有するサーバの処理のうち、乗車ポイント算出処理の流れの一例を説明するフローチャートである。

ステップＳ１１において、ポイント管理部１５０は、タクシーのサービスに対する乗客が支払う対価として使用可能な対価量（例えばポイント）を、乗客となり得るユーザ毎に管理する。

ステップＳ１２において、ＣＰＵ１１は、所定のユーザが定額タクシーＴを利用したか否かを判定する。
定額タクシーＴの利用が無い場合、ステップＳ１２においてＮＯであると判定されて、処理はステップＳ１１に戻され、それ以降の一連の処理が繰り返される。
これに対して、定額タクシーＴの利用が有る場合、ステップＳ１２においてＹＥＳであると判定されて、処理はステップＳ１３に進む。

ステップＳ１３において、コンテクスト取得部１５２は、タクシー車両管理ＤＢ１７１に蓄積された送迎実績情報から、定額タクシーＴに関するコンテクストを取得する。
ステップＳ１４において、乗車内容取得部１５３は、タクシー車両管理ＤＢ１７１に蓄積された送迎実績情報から、乗客が乗車している定額タクシーＴについての、乗車距離及び乗車時間を取得する。
ステップＳ１５において、消費量算出部１５５は、コンテクスト、乗車距離、及び乗車時間を入力パラメータとして受け付け、乗客が支払う対価としての消費ポイントを出力する所定の関数に基づいて、当該消費ポイントを算出する。

ステップＳ１６において、ＣＰＵ１１は、処理終了指示が有るか否かを判定する。
処理終了指示は特に限定されず、例えばスリープの指示を処理終了指示として採用することができる。
処理終了指示が無い場合、ステップＳ１６においてＮＯであると判定されて、処理はステップＳ１１に戻され、それ以降の一連の処理が繰り返される。
これに対して、処理終了指示が有る場合、ステップＳ１６においてＹＥＳであると判定されて、サーバ１の処理は終了する。

図１０は、図８の機能的構成を有するサーバの処理のうち、予約ポイント算出処理の流れの一例を説明するフローチャートである。

ステップＳ２１において、ポイント管理部１５０は、定額タクシーＴのサービスに対する乗客が支払う対価として使用可能なポイントを、乗客となり得るユーザ毎に管理する。

ステップＳ２２において、ＣＰＵ１１は、所定のユーザが定額タクシーＴを利用したか否かを判定する。
定額タクシーＴの利用が無い場合、ステップＳ１２においてＮＯであると判定されて、処理はステップＳ２１に戻され、それ以降の一連の処理が繰り返される。
これに対して、定額タクシーＴの利用が有る場合、ステップＳ２２においてＹＥＳであると判定されて、処理はステップＳ２３に進む。

ステップＳ２３において、予約受付部１５４は、定額タクシーＴの利用予約を通信部１９を介して、ユーザ端末２から受け付ける。
ステップＳ２４において、コンテクスト取得部１５２は、タクシー車両管理ＤＢ１７１に蓄積された送迎実績情報から、定額タクシーＴに関するコンテクストを取得する。
ステップＳ２５において、消費量算出部１５５は、コンテクスト取得部１５２から受け付けたコンテクストに基づいて、予約受付部１５４から受け付けられた利用予約について、ユーザが支払う予約手数料としての消費ポイントを算出する。

ステップＳ２６において、ＣＰＵ１１は、処理終了指示が有るか否かを判定する。
処理終了指示は特に限定されず、例えばスリープの指示を処理終了指示として採用することができる。
処理終了指示が無い場合、ステップＳ２６においてＮＯであると判定されて、処理はステップＳ２１に戻され、それ以降の一連の処理が繰り返される。
これに対して、処理終了指示が有る場合、ステップＳ２６においてＹＥＳであると判定されて、サーバ１の処理は終了する。

なお、タクシーシェアリングサービスは、上述の実施形態に限定されるものではなく、定額タクシーＴ以外の任意のタクシーを用いるサービスとしても実現可能である。
換言すると、タクシーシェアリングサービスのユーザは、所定地域内の高齢者等に特に限定されない。自動車運転免許を取得していない者や、自動車運転に自信が無い初心者及びペーパー運転手等もタクシーシェアリングサービスのユーザとなり得る。
また、消費対価量（例えばポイント）を算出する際に、乗車距離以外の距離や、乗車時間以外の時間を考慮することとしても良い。例えば乗車前後の回送距離や回送時間や、途中下車から再乗車までの時間等を考慮することとしても良い。更には例えば病院等の目的地で下車して往復の為再乗車までの時間中に、ユーザに代わって買い物を代行する等のサービスを提供しても良い。

更にいえば、タクシーを用いるサービスのみならず、乗客輸送サービスに対しても、上述のタクシーシェアリングサービスと同様のものが提供可能になる。

以上まとめると、
乗客輸送サービスに対する乗客が支払う対価を演算する情報処理装置は、次のような装置であれば足りる。
即ち、情報処理装置は、
前記対価として使用可能な対価量（例えばポイント）を、乗客となり得るユーザ毎に管理する管理手段（例えば図８のポイント管理部１５０）と、
乗客輸送体に関するコンテクストを取得するコンテクスト取得手段（例えば図８のコンテクスト取得部１５２）と、
前記乗客が乗車した前記乗客輸送体についての、乗車距離及び乗車時間を取得する乗車内容取得手段（例えば図８の乗車内容取得部１５３）と、
前記コンテクスト、前記乗車距離、及び前記乗車時間を入力パラメータとして、前記乗客が支払う対価としての消費対価量（例えばポイント）を出力する所定の関数に基づいて、当該消費対価量（例えばポイント）を算出する消費量算出手段（例えば図８の消費量算出部１５５）と、
を備えることができる。
これにより、閑散時のタクシーの余剰台数を有効に活用して、収益を上げることができ、高齢者等が利用しやすいタクシーのシェアリングサービスを提供することを可能とする技術を確立することができる。

また、上述の情報処理装置は、
前記コンテクスト取得手段（例えば図８のコンテクスト取得部１５２）は、前記コンテクストとして、乗車人数を少なくとも取得し、
前記消費量算出手段（例えば図８の消費量算出部１５５）は、前記所定の関数として、乗客１人当たりの前記消費対価量を出力する関数を用いて、当該消費対価量を算出することができる。
これにより、ユーザにより相乗りの利用が進むこととなり、更に収益を上げることができ、高齢者等が利用しやすいタクシーのシェアリングサービスを提供することを可能とする技術を確立することができる。

また更に、上述の情報処理装置は、
前記コンテクスト取得手段（例えば図８のコンテクスト取得部１５２）は、前記コンテクストとして、乗車時間帯を少なくとも取得し、
前記消費量算出手段（例えば図８の消費量算出部１５５）は、前記所定の関数として、前記乗車距離及び前記乗車時間が同一条件であっても、前記乗車時間帯に応じて異なる前記消費対価量を出力する関数を用いて、当該消費対価量を算出することができる。
これにより、ユーザによりピーク時の利用は控えられ、その分閑散時の利用が進むこととなり、更に閑散時のタクシーの余剰台数を有効に活用して、収益を上げることができ、高齢者等が利用しやすいタクシーのシェアリングサービスを提供することを可能とする技術を確立することができる。

また、情報処理装置は、次のような構成を取ることもでき、上述の実施形態を含め各種各様な実施形態を取ることができる。
即ち、乗客輸送サービスに対する乗客が支払う対価を演算する情報処理装置は、
前記対価として使用可能な対価量（例えばポイント）を、乗客となり得るユーザ毎に管理する管理手段（例えば図８のポイント管理部１５０）と、
乗客輸送体の利用予約をユーザから受け付ける予約受付手段（例えば図８の予約受付部１５４）と、
乗客輸送体に関するコンテクストを取得するコンテクスト取得手段（例えば図８のコンテクスト取得部１５２）と、
前記コンテクストに基づいて、受け付けられた前記利用予約について、前記ユーザが支払う予約手数料としての消費対価量（例えばポイント）を算出する消費量算出手段（例えば図８の消費量算出部１５５）と、
を備えることができる。
これにより、ユーザにより事前予約での利用が進むこととなり、閑散時のタクシーの余剰台数を有効に活用して、収益を上げることができ、高齢者等が利用しやすいタクシーのシェアリングサービスを提供することを可能とする技術を確立することができる。

また、上述の情報処理装置は、
取得された前記コンテクストの内容をユーザへ提示する提示手段（例えば図８のコンテクスト提示部１５６）をさらに備えることができる。
これにより、ユーザは予測使用状況及び予約状況を確認の上、事前予約を行うことが可能となり、ユーザによる事前予約での利用を更に進めることができる。

また更に、上述の情報処理装置は、
前記消費量算出手段（例えば図８の消費量算出部１５５）は、前記コンテクストに加えてさらに、急ぎ度に基づいて、前記消費対価量を算出することができる。
これにより、乗車を優先させるべきユーザを優先させることができ、ユーザの利便性を向上させることができる。

また更に、上述の情報処理装置は、
前記消費量算出手段（例えば図８の消費量算出部１５５）は、前記コンテクストに加えてさらに、調整幅に基づいて、前記消費対価量を算出することができる。
これにより、異なるユーザによる予約同士の競合を適切に解消できることとなり、事前予約によるユーザの利便性を向上させることができる。

また更に、上述の情報処理装置は、
前記消費量算出手段（例えば図８の消費量算出部１５５）は、前記コンテクストに加えてさらに、先行期間に基づいて、前記消費対価量を算出することができる。
これにより、ユーザが早い時期から他人の予約動向を把握できることとなり、事前予約によるユーザの利便性を向上させることができる。

なお、本発明は、上述の実施形態に限定されるものではなく、本発明の目的を達成できる範囲での変形、改良等は本発明に含まれるものである。

例えば、上述した一連の処理は、ハードウェアにより実行させることもできるし、ソフトウェアにより実行させることもできる。
換言すると、図４又は図８の機能的構成は例示に過ぎず、特に限定されない。即ち、上述した一連の処理を全体として実行できる機能がサーバ１に備えられていれば足り、この機能を実現するためにどのような機能ブロックを用いるのかは特に図４又は図８の例に限定されない。
また、１つの機能ブロックは、ハードウェア単体で構成してもよいし、ソフトウェア単体で構成してもよいし、それらの組合せで構成してもよい。

一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、コンピュータ等にネットワークや記録媒体からインストールされる。
コンピュータは、専用のハードウェアに組み込まれているコンピュータであってもよい。また、コンピュータは、各種のプログラムをインストールすることで、各種の機能を実行することが可能なコンピュータ、例えば汎用のパーソナルコンピュータであってもよい。

このようなプログラムを含む記録媒体は、ユーザにプログラムを提供するために装置本体とは別に配布される図３のリムーバブルメディア３１により構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに提供される記録媒体等で構成される。リムーバブルメディア３１は、例えば、磁気ディスク（フロッピディスクを含む）、光ディスク、又は光磁気ディスク等により構成される。光ディスクは、例えば、ＣＤ－ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｋ－Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ），ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）等により構成される。光磁気ディスクは、ＭＤ（Ｍｉｎｉ－Ｄｉｓｋ）、等により構成される。また、装置本体に予め組み込まれた状態でユーザに提供される記録媒体は、例えば、プログラムが記録されている図３のＲＯＭ１２及び図３のＲＯＭ１２や、図３の記憶部１８及び図３の記憶部１８に含まれるハードディスク等で構成される。

なお、本明細書において、本アプリケーションから他アプリケーションの順にされる実行処理は、その順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的或いは個別に実行される処理をも含むものである。
また、本明細書において、システムの用語は、複数の装置や複数の手段等より構成される全体的な装置を意味するものとする。

１・・・サーバ、２・・・ユーザ端末、３・・・タクシー端末、１１・・・ＣＰＵ、１２・・・ＲＯＭ、１３・・・ＲＡＭ、１４・・・バス、１５・・・入出力インターフェース、１６・・・入力部、１７・・・表示部、１８・・・記憶部、１９・・・通信部、２０・・・ドライブ、３１・・・リムーバブルメディア、４１・・・要請受付部、４２・・・配車計画部、４３・・・配車指示部、５１・・・利用者ＤＢ、５２・・・要請ＤＢ、５３・・・配車計画ＤＢ、１５０・・・ポイント管理部、１５１・・・送迎実績取得部、１５２・・・コンテクスト取得部、１５３・・・乗車内容取得部、１５４・・・予約受付部、１５５・・・消費量算出部、１５６・・・コンテクスト提示部、１６１・・・ポイント付与部、１６２・・・ポイント消費部、１７１・・・タクシー車両管理ＤＢ、１７２・・・ポイント管理ＤＢ、Ｎ・・・ネットワーク、Ｔ・・・定額タクシー

Claims (11)

1. 乗客輸送サービスに対する乗客であって、所定期間毎に定額の対価を支払うと、当該所定期間内においては、最大対価量までの範囲内で対価量を消費することで、当該所定期間に乗客輸送体に複数回乗車可能となるような契約であって、当該所定期間毎に当該最大対価量が付与される契約をしている当該乗客が、当該所定期間における各回の乗車毎に消費する対価量を消費対価量として演算する情報処理装置において、
   前記所定期間における前記最大対価量及び前記消費対価量の履歴を、前記乗客となり得るユーザ毎に管理する管理手段と、
   前記所定期間における所定回に前記乗客が乗車した前記乗客輸送体についての、乗車距離及び乗車時間を取得する乗車内容取得手段と、
   前記所定期間における前記所定回の前記乗車距離及び前記乗車時間を入力パラメータとして、前記契約により規定される、前記消費対価量を出力する所定の関数に基づいて、当該所定回の当該消費対価量を他回とは独立して算出する消費量算出手段と、
   を備える情報処理装置。
2. 前記乗客輸送体に関するコンテクストを取得するコンテクスト取得手段をさらに備え、
   前記消費量算出手段は、さらに前記コンテクストを前記入力パラメータとして、前記消費対価量を算出する、
   請求項１に記載の情報処理装置。
3. 前記コンテクスト取得手段は、前記コンテクストとして、乗車人数を少なくとも取得し、
   前記消費量算出手段は、前記所定の関数として、乗客１人当たりの前記消費対価量を出力する関数を用いて、当該消費対価量を算出する、
   請求項２に記載の情報処理装置。
4. 前記コンテクスト取得手段は、前記コンテクストとして、乗車時間帯を少なくとも取得し、
   前記消費量算出手段は、前記所定の関数として、前記乗車距離及び前記乗車時間が同一条件であっても、前記乗車時間帯に応じて異なる前記消費対価量を出力する関数を用いて、当該消費対価量を算出する、
   請求項２に記載の情報処理装置。
5. 前記乗客輸送体の利用予約を前記ユーザから受け付ける予約受付手段をさらに備え、
   前記消費量算出手段は、さらに、受け付けられた前記利用予約について、前記ユーザが支払う予約手数料としての前記消費対価量を算出する、
   請求項２に記載の情報処理装置。
6. 取得された前記コンテクストの内容を前記ユーザへ提示する提示手段をさらに備える、
   請求項５に記載の情報処理装置。
7. 前記消費量算出手段は、前記コンテクストに加えてさらに、急ぎ度に基づいて、前記消費対価量を算出する、
   請求項５に記載の情報処理装置。
8. 前記消費量算出手段は、前記コンテクストに加えてさらに、調整幅に基づいて、前記消費対価量を算出する、
   請求項５に記載の情報処理装置。
9. 前記消費量算出手段は、前記コンテクストに加えてさらに、先行期間に基づいて、前記消費対価量を算出する、
   請求項５に記載の情報処理装置。
10. 乗客輸送サービスに対する乗客であって、所定期間毎に定額の対価を支払うと、当該所定期間内においては、最大対価量までの範囲内で対価量を消費することで、当該所定期間に乗客輸送体に複数回乗車可能となるような契約であって、当該所定期間毎に当該最大対価量が付与される契約をしている当該乗客が、当該所定期間における各回の乗車毎に消費する対価量を消費対価量として演算する情報処理装置が実行する情報処理方法において、
    前記所定期間における前記最大対価量及び前記消費対価量の履歴を、前記乗客となり得るユーザ毎に管理する管理ステップと、
    前記所定期間における所定回に前記乗客が乗車した前記乗客輸送体についての、乗車距離及び乗車時間を取得する乗車内容取得ステップと、
    前記所定期間における前記所定回の前記乗車距離及び前記乗車時間を入力パラメータとして、前記契約により規定される、前記消費対価量を出力する所定の関数に基づいて、当該所定回の当該消費対価量を他回とは独立して算出する消費量算出ステップと、
    を含む情報処理方法。
11. 乗客輸送サービスに対する乗客であって、所定期間毎に定額の対価を支払うと、当該所定期間内においては、最大対価量までの範囲内で対価量を消費することで、当該所定期間に乗客輸送体に複数回乗車可能となるような契約であって、当該所定期間毎に当該最大対価量が付与される契約をしている当該乗客が、当該所定期間における各回の乗車毎に消費する対価量を消費対価量として演算するコンピュータに、
    前記所定期間における前記最大対価量及び前記消費対価量の履歴を、前記乗客となり得るユーザ毎に管理する管理ステップと、
    前記所定期間における所定回に前記乗客が乗車した前記乗客輸送体についての、乗車距離及び乗車時間を取得する乗車内容取得ステップと、
    前記所定期間における前記所定回の前記乗車距離及び前記乗車時間を入力パラメータとして、前記契約により規定される、前記消費対価量を出力する所定の関数に基づいて、当該所定回の当該消費対価量を他回とは独立して算出する消費量算出ステップと、
    を含む制御処理を実行させるプログラム。

Images