IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 山口 松之進の特許一覧

<>
  • 特開-情報処理装置 図1
  • 特開-情報処理装置 図2
  • 特開-情報処理装置 図3
  • 特開-情報処理装置 図4
  • 特開-情報処理装置 図5
  • 特開-情報処理装置 図6
  • 特開-情報処理装置 図7
  • 特開-情報処理装置 図8
  • 特開-情報処理装置 図9
  • 特開-情報処理装置 図10
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023090903
(43)【公開日】2023-06-29
(54)【発明の名称】情報処理装置
(51)【国際特許分類】
   G06Q 50/10 20120101AFI20230622BHJP
【FI】
G06Q50/10
【審査請求】有
【請求項の数】11
【出願形態】OL
(21)【出願番号】P 2023077433
(22)【出願日】2023-05-09
(62)【分割の表示】P 2018174266の分割
【原出願日】2018-09-18
(71)【出願人】
【識別番号】514274753
【氏名又は名称】山口 松之進
(74)【代理人】
【識別番号】100205659
【弁理士】
【氏名又は名称】齋藤 拓也
(74)【代理人】
【識別番号】100154748
【弁理士】
【氏名又は名称】菅沼 和弘
(72)【発明者】
【氏名】山口 松之進
(57)【要約】
【課題】高齢者等が利用しやすいサービスを提供すること。
【解決手段】サーバ1は、ユーザを乗せて定額タクシーが所定エリア内で移動した際の対価が、所定の時間単位(例えば1ヶ月単位)では、複数の区分のうち設定された区分が同一のユーザにとって一定となるサービスの提供を支援する。具体的には、要請受付部41は、複数のユーザから、定額タクシーの利用の要請(要請には、事前予約も、即乗車希望も含む)の夫々を受け付ける。配車計画部42は、複数のユーザの夫々からの要請の内容及び当該複数のユーザの夫々に設定された区分に基づいて、定額タクシーによる輸送の計画を立案する。
【選択図】図4
【特許請求の範囲】
【請求項1】
移動対象を乗せて移動体が所定エリア内で移動した際の対価が、所定の時間単位では、複数の区分のうち設定された区分が同一の対価支払者にとって一定となるサービスの提供を支援する情報処理装置であって、
複数の対価支払者から、前記移動体の利用の要請の夫々を受け付ける要請受付手段と、
前記複数の対価支払者の夫々からの前記要請の内容及び当該複数の対価支払者の夫々に設定された前記区分に基づいて、前記移動体による輸送の計画を立案する輸送計画手段と、
を備える情報処理装置。
【請求項2】
前記移動対象は、前記対価支払者である、
請求項1に記載の情報処理装置。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、情報処理装置に関する。
【背景技術】
【0002】
自家用車を所有することは、自動車を利用する頻度がそれほど高くない者にとっては、不経済である。
そこで、従来より、マンション等で、一台の自動車を複数のユーザで共同使用するカーシェアリングサービスが存在していた(例えば、特許文献1、2参照)。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開平11-337354号公報
【特許文献2】特開2012-118705号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら、従来のようなカーシェアリングサービスは、ユーザ自身が運転者となることが前提であり、高齢者等の場合に自動車を自ら運転することができなかったり、運転できたとしても安全上の懸念が有ることが、課題となっていた。
【0005】
本発明は、このような状況に鑑みてなされたものであり、高齢者等が利用しやすいサービスを提供することを目的とする。
【課題を解決するための手段】
【0006】
上記目的を達成するため、本発明の一態様の情報処理装置は、
移動対象を乗せて移動体が所定エリア内で移動した際の対価が、所定の時間単位では、複数の区分のうち設定された区分が同一の対価支払者にとって一定となるサービスの提供を支援する情報処理装置であって、
複数の対価支払者から、前記移動体の利用の要請の夫々を受け付ける要請受付手段と、
前記複数の対価支払者の夫々からの前記要請の内容及び当該複数の対価支払者の夫々に設定された前記区分に基づいて、前記移動体による輸送の計画を立案する輸送計画手段と、
を備える。
【発明の効果】
【0007】
本発明によれば、高齢者等が利用しやすいサービスを提供することができる。
【図面の簡単な説明】
【0008】
図1】本発明の一実施形態に係る定額タクシーの配車対応地域について説明する図である。
図2】本発明の一実施形態に係る情報処理システムの構成を示す図である。
図3図2の情報処理システムのうちサーバのハードウェア構成を示すブロック図である。
図4図3のサーバの機能的構成を示す機能ブロック図である。
図5図4の機能的構成を有するサーバ1により実現される本サービスが提供されるユーザの対価の第1の例を説明する図である。
図6図2の情報処理システムが適用されたタクシーシェアリングサービスの概要を示す図である。
図7図6のタクシーシェアリングサービスの利用料金体系の概要を示す図である。
図8図6のタクシーシェアリングサービスが提供される場合における図3のサーバの機能的構成を示す機能ブロック図である。
図9図8の機能的構成を有するサーバの一連の処理のうち、乗車ポイント算出処理の流れの一例を説明するフローチャートである。
図10図8の機能的構成を有するサーバの一連の処理のうち、予約ポイント算出処理の流れの一例を説明するフローチャートである。
【発明を実施するための形態】
【0009】
ここで、本発明の実施形態について、説明するに先立ち、簡単に本発明の前提となるサービス全般について説明する。
【0010】
日本は4人に1人が65歳以上という超高齢化社会を迎え、医療や福祉などに関する問題だけでなく、交通に関する問題も生じるようになっている。具体的に例えば、国土交通省による調査結果によれば、65歳から74歳では、一日に500m程度以上の歩行が困難な割合が2割程度、75歳以上では、5割に程度に上るとされている。
【0011】
他方、高齢者の運転による交通事故は年々増加しており、今後も増加すると予測される。高齢化の進展と共に75歳以上の運転免許保有者数は、2018年には533万人に達すると予測されており、高齢者が運転をしなくても問題なく生活できる環境作りについて対策する必要がある。その対策の1つとして、たとえば、中心部に様々な機能を集約し、市街地をコンパクトな規模に収めた都市形態(コンパクトシティー)が考えられるが、特に地方部では各種拠点や住居が散在しているため、実現が難しい。
【0012】
このような状況のため、特に地方の高齢者においては、「加齢とともに歩いて移動できる距離が短くなる」、「交通事故は怖いが、車を運転できないと生活に支障をきたす」、「近所づきあいがなく家に閉じこもったり、何かあったときに頼れる人がいない」等の問題や悩みを抱えている場合が多い。
【0013】
さらに言えば、高齢者は勿論、一般の人々にとって、自家用車の購入や維持には、高額の費用が掛かるのが通常である。
【0014】
そこで、高齢者の地域生活支援のため、見守り支援、地域生活支援、地域移動支援(自由に地域内を移動)の価値を提供するプラットフォームを構築し、高齢者向けに複合的なサービスを提供することが求められている。
【0015】
本発明に係る一実施形態の情報処理システムの適用対象となるサービス(以下、「本サービス」と呼ぶ)は、高齢者を初めとするユーザにとっては、「自由で欲のある生活」や「生きがいあふれる人生」を実現し、サービスを提供する者(後述するサービス提供者の従業員等)にとっては、「活かされている」、「実感・やりがい」を持ってサービスを実施するような「生きがいの循環」を目指すものである。
【0016】
続いて、このような「生きがいの循環」を目指すにあたり、構築される地域生活支援プラットフォームについて、簡単に説明する。
地域生活支援プラットフォームとは、本サービスの提供者等により提案されたサービスであり、他の事業者等と連携し、高齢者等向けに複合的サービスを提供するサービス提供プラットフォームである。
即ち、「見守り支援」、「地域生活支援」、「所定の地域内を自由に移動」といった価値を高齢者等に対して提供する。
具体的に、地域生活支援プラットフォームには、例えば、「コンシェルジュ」、「地域移動支援」、「地域情報の集約・提供」、「お出かけチケット(地域通貨)提供」等のサービスが含まれる。
【0017】
以上、本発明の一実施形態の説明に先立ち、簡単に本発明の前提となるサービス全般について説明した。なお、以降の説明においては、上述の各種サービスのうち「地域移動支援」に関連する「定額タクシー」のサービスを採用した場合の例を中心として説明する。
【0018】
ここで、定額タクシーについて説明する。地域移動支援サービスにおいて、所定のタクシーを利用して所定地域内で移動する際の対価は、当該所定地域内で一律に設定されている。このように、対価が一律に設定されているタクシーを定額タクシーと称する。
ここで、一律とは、乗客を乗せてタクシーが所定地域内で移動した際の対価が、所定の時間単位(例えば1ヶ月)では一定となることをいう。ただし、所定の時間単位(例えば1ヶ月)あたりの対価は、全ての人にとって同一でなく、松竹梅の3区分等のように複数区分が設定されている場合には、区分毎に異なることになる。
なお、以下の例では、本サービスを利用する者(以下、「ユーザ」と呼ぶ)は、毎月一定の金額(例えば、区分毎に決定される金額)を支払うことで、定額タクシーを利用するものとする。
これによりユーザは、月々決まった金額を支払うだけで、所定の地域内であれば、料金を気にせず、自由に定額タクシーを利用して移動することができる。
【0019】
以下、図面を参照しながら、本発明の第一実施形態について説明する。
【0020】
図1は、本発明の一実施形態に係る定額タクシーの配車対応地域について説明する図である。
図1では、地域A1,A2が示されている。なお、地域は例示であって、これに限定されず、任意の範囲の領域、即ち「エリア」であってよい。
【0021】
ここで、定額タクシーの夫々は、予め決められた地域を担当し、その地域内を移動するようになっている。例えば、図1の場合では、地域A1に配車された定額タクシーは地域A1内を移動し、地域A2に配車された定額タクシーT-1,T-2は地域A2内を移動する。
定額タクシーの運転手も、予め決められた地域を担当し、原則として、当該地域を担当する定額タクシーを運転するものとする。例えば、地域A2では、3人の運転手が交代で、定額タクシーT-1,T-2の夫々を運転するものとする。
ユーザは、自宅等が含まれる地域(例えば地域A2)を設定し、毎月一定の金額(例えば、3万円)を支払うことで、設定した地域を担当する定額タクシー(例えば地域A2では定額タクシーT-1,T-2)に限り、設定した地域内で(区分毎に設定された乗り方の範囲内で)自由に利用することができる。
【0022】
図1では、地域A2を担当する定額タクシーT-1、T-2のみが図示されているが、地域A1にも、同様に所定台数(例えば2台)の定額タクシーが担当する。
地域A2の例では、例えば運転手3名が交代で、定額タクシーT-1、T-2の2台を運転する。
この様に、運転手は、所定の一地域のみを担当させ、かつ、ある程度少数の者に限定とする好適である。ユーザと運転手とにおいて濃い人間関係を形成し、ユーザに安心感を与えることが可能となるからである。
【0023】
図2は、本発明の一実施形態に係る情報処理システムの構成を示す図である。
【0024】
情報処理システムは、図2に示すように、本サービスの提供者により管理されるサーバ1と、ユーザ端末2-1乃至2-m(mは任意の整数)と、定額タクシーT-1乃至T-n(nは任意の整数)の夫々に搭載されているタクシー端末3-1乃至3-n(nは任意の整数)とを含むように構成される。
【0025】
サーバ1と、ユーザ端末2-1乃至2-mの夫々と、タクシー端末3-1乃至3-nの夫々とは、インターネット等の所定のネットワークNを介して相互に接続される。
【0026】
なお、以下、ユーザ端末2-1乃至2-mの夫々を個々に区別する必要がない場合、これらをまとめて「ユーザ端末2」と呼ぶ。また、定額タクシーT-1乃至T-nの夫々を個々に区別する必要がない場合、これらをまとめて「定額タクシーT」と呼ぶ。定額タクシーTと呼んでいる場合には、タクシー端末3-1乃至3-nをまとめて「タクシー端末3」と呼ぶ。
【0027】
図3は、図2の情報処理システムのうちサーバのハードウェア構成を示すブロック図である。
【0028】
サーバ1は、CPU(Central Processing Unit)11と、ROM(Read Only Memory)12と、RAM(Random Access Memory)13と、バス14と、入出力インターフェース15と、出力部16と、入力部17と、記憶部18と、通信部19と、ドライブ20とを備えている。
【0029】
CPU11は、ROM12に記録されているプログラム、又は、記憶部18からRAM13にロードされたプログラムに従って各種の処理を実行する。
【0030】
RAM13には、CPU11が各種の処理を実行する上において必要なデータ等も適宜記憶される。
【0031】
CPU11、ROM12及びRAM13は、バス14を介して相互に接続されている。このバス14にはまた、入出力インターフェース15も接続されている。入出力インターフェース15には、出力部16、入力部17、記憶部18、通信部19、ドライブ20が接続されている。
【0032】
出力部16は、スピーカや表示部等から構成され、各種情報を画像や音声として出力する。
入力部17は、キーボードやマウス等から構成され、各種情報を入力する。
【0033】
記憶部18は、DRAM(Dynamic Random Access Memory)等で構成され、各種データを記憶する。
通信部19は、インターネットを含むネットワークNを介して他の装置(図2の例ではユーザ端末2及びタクシー端末3)との間で行う通信を制御する。
【0034】
ドライブ20には、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリ等よりなる、リムーバブルメディア31が適宜装着される。ドライブ20によってリムーバブルメディア31から読み出されたプログラムは、必要に応じて記憶部18にインストールされる。また、リムーバブルメディア31は、記憶部18に記憶されている各種データを、記憶することができる。
【0035】
ユーザ端末2又はタクシー端末3の構成は、タッチパネルディスプレイを備える場合が有る点を除いてサーバ1の構成と基本的に同様であるので、ここではそれらの説明は省略する。
【0036】
図4は、図3のサーバの機能的構成を示す機能ブロック図である。
サーバ1のCPU11においては、要請受付部41と、配車計画部42と、配車指示部43とが機能する。
記憶部18の一領域として、ユーザDB51と、要請DB52と、配車計画DB53とが設けられている。
【0037】
要請受付部41は、複数の対価支払者(ここでは、所定の地域を設定した複数のユーザ)から、定額タクシーTの利用の要請の夫々を受け付ける。
即ち、要請受付部41は、通信部19を介して、複数のユーザの夫々のユーザ端末2から、定額タクシーTの利用の要請(要請には、事前予約も、即時乗車希望も含む)の夫々を受け付け、複数のユーザの夫々の区分と対応付けて要請DB52に蓄積する。なお、区分は、詳細について後述するが、各ユーザの属性情報の1つとしてユーザDB51に記憶されている。
【0038】
配車計画部42は、複数のユーザの夫々からの要請の内容及び当該複数のユーザの夫々に設定された区分に基づいて、所定の地域における定額タクシーTによる輸送の計画を立案し、配車計画DB53に記憶させる。
また、配車計画部42は、通信部19を介して、複数のユーザの夫々のユーザ端末2に対して、要請の可否を通知する。
【0039】
配車指示部43は、所定の地域における定額タクシーTによる輸送の計画を配車計画DB53から参照して、これに基づいて当該所定の地域を担当する定額タクシーTの配車の指示を生成し、当該定額タクシーTのタクシー端末3に対して通信部19を介して通知する。
【0040】
以下、図4の機能的構成を有するサーバ1により実現される本サービスが提供されるユーザの対価の各種例について説明する。
【0041】
図5は、図4の機能的構成を有するサーバ1により実現される本サービスが提供されるユーザの対価の第1の例を説明する図である。
第1の例では、所定の地域での定額タクシーTを利用するに際し、月額固定の利用プランに複数の区分を設ける料金体系が採用されている。ユーザは、会費とサービス内容とを比較考慮して、自身に適した区分を自由に選択することができる。なお、複数の地域からユーザの定額タクシーTを利用する地域として当該ユーザにより選択された地域は、図5の例では「適用地域」とされている。
図5の例では、月額固定の利用プランにおける区分として、特松(プレミアム会員、月額7万円)、松(通常会員、月額3万円)、竹(タブレット会員、月額2万円)、及び梅(無料会員、月額0円)の4区分が設定されている。
【0042】
例えば、月額7万円の特松プランでは、ユーザは、プレミアム会員として、適用地域内であれば、いつでも定額タクシーTが乗り放題となる。
【0043】
また例えば、月額3万円の松プランでは、ユーザは通常会員として、適用地域内であれば、次のような第1乃至第3の利用方法で定額タクシーTを利用できる。第1の利用方法は、前月までの事前予約タクシー乗り放題となるものである。第2の利用方法は、前日までの事前予約タクシーも、随時乗車可能となるものである。第3の利用方法は、当日の依頼でも、随時乗車可能となるものである。
【0044】
また例えば、月額2万円の竹プランでは、ユーザはタブレット会員として、適用地域であれば、次のような第4乃至第6の利用方法で定額タクシーTを利用できる。第4の利用方法は、前月までの事前予約タクシー乗り放題となるものである。第5の利用方法は、前日までの事前予約タクシーも、随時乗車可能となるものである。第6の利用方法は、当日の依頼も、随時乗車可能となるものである。
【0045】
また例えば、無料の梅プランにおいては、ユーザは、無料会員として、定額タクシーTの乗車はできないものの、ユーザ端末2がスマートフォン等である場合にそれにインストールされるアプリケーション(図5の例では「スマホ用アプリ」と記載)を用いて、ユーザ登録情報に向けた(マッチングさせた)地域情報の提供を受けることができる。
【0046】
以上まとめると、図5の例のように複数の区分が設けられた本サービスの提供を可能となる情報処理装置は、上述の実施形態のサーバ1を含め各種各様な実施形態を取ることができる。
ここで、本発明が適用される情報処理装置が提供可能なサービスとしては、上述の例では、定額タクシーTを利用する本サービスを採用したがこれに限定されず、移動対象を乗せて移動体が所定エリア内で移動した際の対価が、所定の時間単位では、複数の区分のうち設定された区分が同一の対価支払者にとって一定となるサービスであれば足り、任意のサービスを提供することができる。
【0047】
即ち、本サービスが提供される情報処理装置は、
移動対象を乗せて移動体(例えば図2の定額タクシーT-1,T-2)が所定エリア(例えば図1の地域A2)内で移動した際の対価が、所定の時間単位(例えば1ヶ月単位)では、複数の区分(例えば図5の例の区分)のうち設定された区分が同一の対価支払者(例えばユーザ)にとって一定となるサービス(例えば定額タクシーTを利用する本サービス)の提供を支援する情報処理装置(例えば図3のサーバ1)であって、
複数の対価支払者から、前記移動体の利用の要請(要請には、事前予約も、即乗車希望も含む)の夫々を受け付ける要請受付手段(例えば図4の要請受付部41)と、
前記複数の対価支払者の夫々からの前記要請の内容及び当該複数の対価支払者の夫々に設定された前記区分に基づいて、前記移動体による輸送の計画を立案する輸送計画手段(例えば図4の配車計画部42)と、
を備えれば足りる。
これにより、区分に応じて利便性を享受することができる定額輸送サービスを提供することができる。
【0048】
ここで、定額タクシーTに一度に乗れるユーザを1人に限定した場合、同一の地域内の同一時間帯に、当該地域に配置される定額タクシーTの台数を超えるユーザからの要請があった場合、全ての要請に応えることはできない。
かかる場合に、配車計画部42は、所定のルールに基づき、一部の要請を却下して、定額タクシーTによる輸送の計画を立案することができる。
所定のルールとしては、例えばユーザの区分を優先するルールを採用することができるが、特に限定されない。
その他、例えば、相乗りを許す場合の相乗り乗車人数、先行要請期間(早期予約)、乗降車地点(タクシー乗り場利用等)、利用目的の緊急度、ユーザの身体的不自由度や健康状態、年齢、性別、居所の利便性等を考慮した任意のルールを採用することができる。
【0049】
ここで、定額タクシーTに乗れるユーザの人数は、1人に限定される必要は特になく、複数人でよい。
【0050】
ここで、複数人を輸送するサービスとしては、カーシェアリングサービスが存在する。しかしながら、カーシェアリングサービスは、高齢者等を対象とするサービスとしては不適である。高齢者等が、自動車を自ら運転することには安全上の懸念があるためである。
そこで、このような高齢者等のために、上述の定額タクシーTを、同一の適用地域内の複数のユーザでシェアして乗車することが可能なサービス(以下、「タクシーシェアリングサービス」と呼ぶ)が好適である。
【0051】
なお、タクシーシェアリングサービスは、定額タクシーTのみならず、通常のタクシー料金の体系、即ち、乗車距離と乗車時間との連動性で料金を演算する体系を採用したタクシーを利用することもできる。
ただし、タクシーシェアリングサービスに対して、通常のタクシー料金の体系をそのまま適用するのは不適である。即ち、従来のタクシー料金の演算手法を、タクシーシェアリングサービスにそのまま採用すると、タクシー会社としては需要ピーク時の収益機会を奪われることとなり、ユーザにとっても経済的にメリットが薄くなってしまう。
【0052】
そこて、本実施形態では、定額タクシーTを集団で共用しつつ、更にポイント制を導入することにより、一部のユーザによる独占的利用を制限しつつ、閑散時の余剰台数の活用を図ることにしている。
つまり、第一に、一部のユーザばかりに利用が集中すると、コミュニティ内に不公平感が生じることとなる。
また、第二に、タクシー会社側とユーザの双方が経済的恩恵を享受したい。
そのため、本実施形態では、ポイント消費量のベースとして乗車距離と乗車時間を採用しつつ、その他の要素(コンテクスト、予約有無)を加味して、消費ポイントが変動するポイント制が採用されている。
【0053】
なお、本明細書においては、コンテクスト(context)とは、定額タクシーTの内的状態および外的状態の全てを指す。定額タクシーTの内的状態とは、定額タクシーTの車種、年式、型式、または、運転手の体調、運転技能若しくは接客態度等を指す。また、定額タクシーTの外的状態とは、定額タクシーTの稼働状況、道路交通状況、路面状況、空間的または時間的な配置位置(時間的な配置位置とは、例えば、現在時刻を指す)の他、定額タクシーTの周囲の空間方向若しくは時間方向に分布する(または、いずれの方向にも分布する)所定の状態も指す。
【0054】
ここで、本実施例においては、タクシーシェアリングサービスの地理的提供範囲は、地域限定とする。
この様にすることにより、ユーザと提供者、及びユーザ同士において、濃い人間関係が形成されることとなり、ユーザに安心感を与えることができる。
【0055】
また、本実施例においては、タクシーシェアリングサービスの対価は、定額ポイント制とする。定額ポイント制については、例えば月額制であって良く、ヘビーユーザ向けの高額プランからライトユーザ向けの低額プランまで、複数の定額料金プランを設定することができる。
本実施例においては、高額プランのユーザと低額プランのユーザで配車要請又は予約が競合した場合は、高額プランのユーザの配車要請等が優先される。
【0056】
ここで、ポイントは必ずしも定額タクシーTの利用により消費するものではなく、他のサービスに流用するものでもよい。
例えば、ユーザが定額タクシーTを利用して通院した際に、ユーザが受診する間の時間を利用した買い物等の代行サービスを運転手に依頼して、ポイントを消費できて良い。
この様にすることにより、ユーザは、定額タクシーTを単なる移動手段ではなく、ポイントを消費して多様な要求に柔軟に応じる便利屋(介助屋)の如きサービスとして、利用できることとなる。
また、ユーザは、運転手を指名できることとし、サービスを利用する度に要求を伝達する手間を省くことを、可能として良い。
この様にすることにより、ユーザは運転手とは次第に懇意となり、運転手は当該ユーザの様々な事情を理解でき、その事情に応じた様々なサービスの提案をしていくことが、可能となる。
なお、ユーザによる運転手の指名については、ポイントを消費させることとして良い。
また更に、前回乗車時の話題、依頼等に基づいて話題を提供する、支援システムを導入して良い。
【0057】
図6は、図2の情報処理システムが適用されたタクシーシェアリングサービスの概要を示す図である。
図6においては、タクシーシェアリングサービスの一例として、同一領域内の10人のユーザからなるコミュニティCで、n台(nは、1以上の任意の整数値)の定額タクシーT-1乃至T-nが利用される例を示している。
ここで、定額タクシーT-1乃至T-(a-1)(aは、1以上n以下の任意の整数値)は乗客が乗車中であり、定額タクシーT-a乃至T-nは、運転手のみが乗車する空車状態であることを示している。
1台の定額タクシーT-1には、コミュニティCのユーザU1乃至U3の3人が相乗りをしている。
この場面において、コミュニティCの別のユーザU4が乗車を希望する場合、乗車中状態の定額タクシーT-1乃至T-(a-1)への相乗りが可能であれば、消費対価量(例えばポイント)を低く抑えることができる。
一方、空車状態である定額タクシーT-a乃至T-nへの単独乗車が可能であれば、空車状態であるタクシーの中から、例えば最も早くユーザU4を乗車させることができる1台として定額タクシーT-aが選出され、速やかに目的地まで移動することができる。
図6の一例ではユーザU4は、空車状態である定額タクシーT-aに単独乗車し、一人でタクシー1台分の消費対価量を負担する。
一方、1台の定額タクシーT-1に相乗りしているユーザU1乃至U3の3人は、タクシー1台分の消費対価量を分担して負担することができる。
なお、本明細書において相乗りとは、同時乗車同時下車の場合に限定せず、途中乗車又は途中下車による相乗りを含む。
【0058】
図7は、図6のタクシーシェアリングサービスの利用料金体系の概要を示す図である。
図7(a)は、タクシーシェアリングサービスを利用した一のユーザについての利用状況とこれに対応する消費ポイント明細を示す図である。
タクシーに乗車したユーザが消費するポイントについては、例えば乗車距離や乗車時間等に連動する任意の算定方式を採用して良い。
以下では、1Km(2分)の乗車で1ポイントを消費するものとして、説明する。
また、N台のタクシーのコンテクスト(状況)により、消費ポイントが増減調整される。
【0059】
図7(b)は、消費ポイント調整表の具体例を示す。
消費ポイント調整表における「+α」とは、乗車距離と乗車時間を基準としたベースとなるポイント消費量に対して加える増減の調整量を表し、「+」付きの数値はポイント消費量を加増させる量であることを意味し、「-」付きの数値はポイント消費量を減少させる量であることを意味する。
【0060】
図7(a)の消費ポイント明細に戻り、「time」項目は、昇順の時系列を意味する。
time=1において、ユーザは急いでいた為、優先的な配車を要請し、10Km、20分間の乗車をし、その対価として40ポイントを消費したことを、示している。
本実施例においては、ユーザは急ぎ度に応じて、消費ポイントを割高とすることにより優先的な配車を要請できることとしている。この急ぎ度は、0~1の値で指定する。
配車要請に際しては、前もって定額タクシーTの現在使用状況を表示させ、確認することができる。
また、n台の定額タクシーTがフル稼働となり配車を待たされる場合や、キャンセル等により、配車要請が可能となった場合等には、ユーザに報知を行う。
なお、年金支給情報等のユーザが関心を持つと考えられるイベント情報についても、ユーザに表示又は報知を行う。
10Km(20分間)の乗車により発生した10ポイントを基に、優先配車によるポイントが別途発生しているためである。
【0061】
図7(b)の消費ポイント調整表によれば優先配車による発生ポイントは30ポイントである為、消費ポイントの合計は40ポイントとなっている。
time=2において、ユーザは通勤時間帯の40分間に20Kmの乗車をし、その対価として30ポイントを消費したことを、示している。
20Km(40分間)の乗車により発生した20ポイントを基に、通勤時間帯利用によるポイントが別途発生しているためである。
図7(b)の消費ポイント調整表によれば通勤時間帯利用による発生ポイントは10ポイントである為、消費ポイントの合計は10ポイントとなっている。
【0062】
ここで、高齢者には時間的束縛が少ない者が多く、本実施例においては閑散時間帯のポイント消費量を低く抑えて設定することにより、閑散時間帯の余剰台数の活用を図るが、有効期間内にポイントを消費する機会が無く、このままでは消滅してしまうポイントを余らせている場合も有る。
また、高齢者と言っても様々で、時間的束縛が多く、割高なポイント消費が苦にならない経済状況の者も居るので、その様な場合には割高であっても、経済性を度外視して時間帯制限が無く利用できる方が、ユーザにとっては便宜である。
本実施例は、上記の点を考慮したものとなっている。
【0063】
time=3において、ユーザは閑散時間帯の60分間に30Kmの乗車をし、その対価として20ポイントを消費したことを、示している。
30Km(60分間)の乗車により発生した30ポイントを基に、閑散時間帯利用によるポイントが差し引かれているためである。
図7(b)の消費ポイント調整表によれば閑散時間帯利用による発生ポイントはマイナス10ポイントである為、消費ポイントの合計は20ポイントとなっている。
time=4において、ユーザは閑散時間帯の40分間に20Kmの乗車をし、その対価として30ポイントを消費したことを、示している。
20Km(40分間)の乗車により発生した20ポイントを基に、当日予約によるポイントが別途発生し、閑散時間帯利用によるポイントが、差し引かれているためである。
【0064】
本実施例において予約とは、申し込みにより、タクシー車両の利用を事前に確保しておくことをいう。
本実施例における予約は、利用日時、利用台数、乗車人数、乗車地、降車地等を指定して申し込み、利用日時までの期間が長い程、予約に伴う消費ポイントは少なくなる。
予約には、例えば利用日時に5時間等の調整幅を設けて申し込むことができ、当該調整幅が大きいほど、予約に伴う消費ポイントは少なくなる。
予約に際しては、前もって定額タクシーTの予測使用状況及び予約状況を表示させ、予約可能時間を確認することができる。
また、n台の定額タクシーTがフル稼働となり予約出来ない場合や、キャンセル等により、予約が可能となった場合等には、ユーザに報知を行う。
【0065】
図7(b)の消費ポイント調整表によれば当日予約による発生ポイントは20ポイントであり、閑散時間帯利用による発生ポイントはマイナス10ポイントである為、消費ポイントの合計は30ポイントとなっている。
time=3において、ユーザは60分間に30Kmの他2名との相乗り乗車をし、その対価として10ポイントを消費したことを、示している。
30Km(60分間)の乗車により発生した30ポイントが、乗車人数により3等分されているためである。
【0066】
なお、図7(b)の消費ポイント調整表には他にも、前日予約による発生ポイントは10ポイントであり、前々日予約による発生ポイントは5ポイントであり、所定のタクシー乗り場の利用による発生ポイントはマイナス5ポイントであり、要介助の乗客による発生ポイントは10ポイントであり、バトンタッチ乗降車(前の乗客と次の乗客が時間を置かず同じ場所で入れ替わり乗降車する)による発生ポイントはマイナス10ポイントであり、時刻調整幅3時間以上の乗車予約による発生ポイントはマイナス5ポイントであり、時刻調整幅5時間以上の乗車予約による発生ポイントはマイナス10ポイントであることが示されている。
また、消費ポイントの調整、上記の例では加減算により行ったが、例えば1.1を乗算(一割増し)する等の他の様々な演算により行って良い。
【0067】
図7(c)は、タクシーシェアリングサービスを利用した一のユーザについての消費ポイントと、利用金額との関係を示す図である。
所定の期間中に任意の消費ポイントまでは金額は一定であるが、それ以上の消費ポイントについては金額が連動して増加する。
図7(c)の例では100ポイントまでが定額利用となることを示している。
図7(a)の消費ポイント明細の例においては、time=1においては40ポイントを消費し、定額利用の制限内となっている。
time=2においては30ポイントを消費し、累計消費ポイントは70ポイントとなる。この時点においても、定額利用の制限内となっている。
time=3においては更に20ポイントを消費し、累計消費ポイントは90ポイントとなる。この時点においても、定額利用の制限内となっている。
time=4においては更に30ポイントを消費し、累計消費ポイントは120ポイントとなる。この時点で、定額利用の制限である100ポイントを超過する為、当該ユーザは20ポイント分の料金を追加負担することとなる。
【0068】
図8は、タクシーシェアリングサービスが提供される場合における図3のサーバの機能的構成を示す機能ブロック図である。
なお、タクシーシェアリングサービスは、本実施形態では定額タクシーTが前提となっているため、サーバ1のCPU11において、上述の図4の機能ブロックも適宜機能する。
サーバ1のCPU11においては、ポイント管理部150と、送迎実績取得部151と、コンテクスト取得部152と、乗車内容取得部153と、予約受付部154と、消費量算出部155と、コンテクスト提示部156とが機能する。
記憶部18の一領域として、タクシー車両管理DB171と、ポイント管理DB172とが設けられている。
【0069】
ポイント管理部150は、ポイント付与部161と、ポイント消費部162を更に備え、タクシーのサービスに対する乗客が支払う対価として使用可能なポイントを、乗客となり得るユーザ毎に管理する。
ポイント付与部161は、ユーザ毎に、料金プランに応じたポイントを付与する。
ポイント消費部162は、ユーザ毎に、後述する消費量算出部155により算出されたポイントを消費する。
【0070】
送迎実績取得部151は、通信部19を介して、タクシー端末3から定額タクシーTの送迎実績情報を取得し、タクシー車両管理DB171に蓄積する。
コンテクスト取得部152は、タクシー車両管理DB171に蓄積された送迎実績情報から、定額タクシーTに関するコンテクストを取得する。
乗車内容取得部153は、タクシー車両管理DB171に蓄積された送迎実績情報から、乗客が乗車している定額タクシーTについての、乗車距離及び乗車時間を取得する。
予約受付部154は、タクシーの利用予約を通信部19を介して、ユーザ端末2から受け付ける。
【0071】
消費量算出部155は、コンテクスト取得部152及び乗車内容取得部153からコンテクスト、乗車距離、及び乗車時間を入力パラメータとして受け付け、乗客が支払う対価としての消費対価量(例えばポイント)を出力する所定の関数に基づいて、消費対価量(例えばポイント)を算出する。
また、消費量算出部155は、コンテクスト取得部152から受け付けたコンテクストに基づいて、予約受付部154から受け付けられた利用予約について、ユーザが支払う予約手数料としての消費対価量(例えばポイント)を算出する。
【0072】
コンテクスト提示部156は、コンテクスト取得部152から受け付けたコンテクストの内容を、通信部19を介して、ユーザ端末2へ送信する。
【0073】
タクシー車両管理DB171は、タクシー車両を識別する情報と、タクシー車両に関する情報とを関連付けて記憶する。
ポイント管理DB172は、ユーザを識別する情報と、ユーザが保有するポイント情報とを関連付けて記憶する。
【0074】
図9は、図8の機能的構成を有するサーバの処理のうち、乗車ポイント算出処理の流れの一例を説明するフローチャートである。
【0075】
ステップS11において、ポイント管理部150は、タクシーのサービスに対する乗客が支払う対価として使用可能な対価量(例えばポイント)を、乗客となり得るユーザ毎に管理する。
【0076】
ステップS12において、CPU11は、所定のユーザが定額タクシーTを利用したか否かを判定する。
定額タクシーTの利用が無い場合、ステップS12においてNOであると判定されて、処理はステップS11に戻され、それ以降の一連の処理が繰り返される。
これに対して、定額タクシーTの利用が有る場合、ステップS12においてYESであると判定されて、処理はステップS13に進む。
【0077】
ステップS13において、コンテクスト取得部152は、タクシー車両管理DB171に蓄積された送迎実績情報から、定額タクシーTに関するコンテクストを取得する。
ステップS14において、乗車内容取得部153は、タクシー車両管理DB171に蓄積された送迎実績情報から、乗客が乗車している定額タクシーTについての、乗車距離及び乗車時間を取得する。
ステップS15において、消費量算出部155は、コンテクスト、乗車距離、及び乗車時間を入力パラメータとして受け付け、乗客が支払う対価としての消費ポイントを出力する所定の関数に基づいて、当該消費ポイントを算出する。
【0078】
ステップS16において、CPU11は、処理終了指示が有るか否かを判定する。
処理終了指示は特に限定されず、例えばスリープの指示を処理終了指示として採用することができる。
処理終了指示が無い場合、ステップS16においてNOであると判定されて、処理はステップS11に戻され、それ以降の一連の処理が繰り返される。
これに対して、処理終了指示が有る場合、ステップS16においてYESであると判定されて、サーバ1の処理は終了する。
【0079】
図10は、図8の機能的構成を有するサーバの処理のうち、予約ポイント算出処理の流れの一例を説明するフローチャートである。
【0080】
ステップS21において、ポイント管理部150は、定額タクシーTのサービスに対する乗客が支払う対価として使用可能なポイントを、乗客となり得るユーザ毎に管理する。
【0081】
ステップS22において、CPU11は、所定のユーザが定額タクシーTを利用したか否かを判定する。
定額タクシーTの利用が無い場合、ステップS12においてNOであると判定されて、処理はステップS21に戻され、それ以降の一連の処理が繰り返される。
これに対して、定額タクシーTの利用が有る場合、ステップS22においてYESであると判定されて、処理はステップS23に進む。
【0082】
ステップS23において、予約受付部154は、定額タクシーTの利用予約を通信部19を介して、ユーザ端末2から受け付ける。
ステップS24において、コンテクスト取得部152は、タクシー車両管理DB171に蓄積された送迎実績情報から、定額タクシーTに関するコンテクストを取得する。
ステップS25において、消費量算出部155は、コンテクスト取得部152から受け付けたコンテクストに基づいて、予約受付部154から受け付けられた利用予約について、ユーザが支払う予約手数料としての消費ポイントを算出する。
【0083】
ステップS26において、CPU11は、処理終了指示が有るか否かを判定する。
処理終了指示は特に限定されず、例えばスリープの指示を処理終了指示として採用することができる。
処理終了指示が無い場合、ステップS26においてNOであると判定されて、処理はステップS21に戻され、それ以降の一連の処理が繰り返される。
これに対して、処理終了指示が有る場合、ステップS26においてYESであると判定されて、サーバ1の処理は終了する。
【0084】
なお、タクシーシェアリングサービスは、上述の実施形態に限定されるものではなく、定額タクシーT以外の任意のタクシーを用いるサービスとしても実現可能である。
換言すると、タクシーシェアリングサービスのユーザは、所定地域内の高齢者等に特に限定されない。自動車運転免許を取得していない者や、自動車運転に自信が無い初心者及びペーパー運転手等もタクシーシェアリングサービスのユーザとなり得る。
また、消費対価量(例えばポイント)を算出する際に、乗車距離以外の距離や、乗車時間以外の時間を考慮することとしても良い。例えば乗車前後の回送距離や回送時間や、途中下車から再乗車までの時間等を考慮することとしても良い。更には例えば病院等の目的地で下車して往復の為再乗車までの時間中に、ユーザに代わって買い物を代行する等のサービスを提供しても良い。
【0085】
更にいえば、タクシーを用いるサービスのみならず、乗客輸送サービスに対しても、上述のタクシーシェアリングサービスと同様のものが提供可能になる。
【0086】
以上まとめると、
乗客輸送サービスに対する乗客が支払う対価を演算する情報処理装置は、次のような装置であれば足りる。
即ち、情報処理装置は、
前記対価として使用可能な対価量(例えばポイント)を、乗客となり得るユーザ毎に管理する管理手段(例えば図8のポイント管理部150)と、
乗客輸送体に関するコンテクストを取得するコンテクスト取得手段(例えば図8のコンテクスト取得部152)と、
前記乗客が乗車した前記乗客輸送体についての、乗車距離及び乗車時間を取得する乗車内容取得手段(例えば図8の乗車内容取得部153)と、
前記コンテクスト、前記乗車距離、及び前記乗車時間を入力パラメータとして、前記乗客が支払う対価としての消費対価量(例えばポイント)を出力する所定の関数に基づいて、当該消費対価量(例えばポイント)を算出する消費量算出手段(例えば図8の消費量算出部155)と、
を備えることができる。
これにより、閑散時のタクシーの余剰台数を有効に活用して、収益を上げることができ、高齢者等が利用しやすいタクシーのシェアリングサービスを提供することを可能とする技術を確立することができる。
【0087】
また、上述の情報処理装置は、
前記コンテクスト取得手段(例えば図8のコンテクスト取得部152)は、前記コンテクストとして、乗車人数を少なくとも取得し、
前記消費量算出手段(例えば図8の消費量算出部155)は、前記所定の関数として、乗客1人当たりの前記消費対価量を出力する関数を用いて、当該消費対価量を算出することができる。
これにより、ユーザにより相乗りの利用が進むこととなり、更に収益を上げることができ、高齢者等が利用しやすいタクシーのシェアリングサービスを提供することを可能とする技術を確立することができる。
【0088】
また更に、上述の情報処理装置は、
前記コンテクスト取得手段(例えば図8のコンテクスト取得部152)は、前記コンテクストとして、乗車時間帯を少なくとも取得し、
前記消費量算出手段(例えば図8の消費量算出部155)は、前記所定の関数として、前記乗車距離及び前記乗車時間が同一条件であっても、前記乗車時間帯に応じて異なる前記消費対価量を出力する関数を用いて、当該消費対価量を算出することができる。
これにより、ユーザによりピーク時の利用は控えられ、その分閑散時の利用が進むこととなり、更に閑散時のタクシーの余剰台数を有効に活用して、収益を上げることができ、高齢者等が利用しやすいタクシーのシェアリングサービスを提供することを可能とする技術を確立することができる。
【0089】
また、情報処理装置は、次のような構成を取ることもでき、上述の実施形態を含め各種各様な実施形態を取ることができる。
即ち、乗客輸送サービスに対する乗客が支払う対価を演算する情報処理装置は、
前記対価として使用可能な対価量(例えばポイント)を、乗客となり得るユーザ毎に管理する管理手段(例えば図8のポイント管理部150)と、
乗客輸送体の利用予約をユーザから受け付ける予約受付手段(例えば図8の予約受付部154)と、
乗客輸送体に関するコンテクストを取得するコンテクスト取得手段(例えば図8のコンテクスト取得部152)と、
前記コンテクストに基づいて、受け付けられた前記利用予約について、前記ユーザが支払う予約手数料としての消費対価量(例えばポイント)を算出する消費量算出手段(例えば図8の消費量算出部155)と、
を備えることができる。
これにより、ユーザにより事前予約での利用が進むこととなり、閑散時のタクシーの余剰台数を有効に活用して、収益を上げることができ、高齢者等が利用しやすいタクシーのシェアリングサービスを提供することを可能とする技術を確立することができる。
【0090】
また、上述の情報処理装置は、
取得された前記コンテクストの内容をユーザへ提示する提示手段(例えば図8のコンテクスト提示部156)をさらに備えることができる。
これにより、ユーザは予測使用状況及び予約状況を確認の上、事前予約を行うことが可能となり、ユーザによる事前予約での利用を更に進めることができる。
【0091】
また更に、上述の情報処理装置は、
前記消費量算出手段(例えば図8の消費量算出部155)は、前記コンテクストに加えてさらに、急ぎ度に基づいて、前記消費対価量を算出することができる。
これにより、乗車を優先させるべきユーザを優先させることができ、ユーザの利便性を向上させることができる。
【0092】
また更に、上述の情報処理装置は、
前記消費量算出手段(例えば図8の消費量算出部155)は、前記コンテクストに加えてさらに、調整幅に基づいて、前記消費対価量を算出することができる。
これにより、異なるユーザによる予約同士の競合を適切に解消できることとなり、事前予約によるユーザの利便性を向上させることができる。
【0093】
また更に、上述の情報処理装置は、
前記消費量算出手段(例えば図8の消費量算出部155)は、前記コンテクストに加えてさらに、先行期間に基づいて、前記消費対価量を算出することができる。
これにより、ユーザが早い時期から他人の予約動向を把握できることとなり、事前予約によるユーザの利便性を向上させることができる。
【0094】
なお、本発明は、上述の実施形態に限定されるものではなく、本発明の目的を達成できる範囲での変形、改良等は本発明に含まれるものである。
【0095】
例えば、上述した一連の処理は、ハードウェアにより実行させることもできるし、ソフトウェアにより実行させることもできる。
換言すると、図4又は図8の機能的構成は例示に過ぎず、特に限定されない。即ち、上述した一連の処理を全体として実行できる機能がサーバ1に備えられていれば足り、この機能を実現するためにどのような機能ブロックを用いるのかは特に図4又は図8の例に限定されない。
また、1つの機能ブロックは、ハードウェア単体で構成してもよいし、ソフトウェア単体で構成してもよいし、それらの組合せで構成してもよい。
【0096】
一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、コンピュータ等にネットワークや記録媒体からインストールされる。
コンピュータは、専用のハードウェアに組み込まれているコンピュータであってもよい。また、コンピュータは、各種のプログラムをインストールすることで、各種の機能を実行することが可能なコンピュータ、例えば汎用のパーソナルコンピュータであってもよい。
【0097】
このようなプログラムを含む記録媒体は、ユーザにプログラムを提供するために装置本体とは別に配布される図3のリムーバブルメディア31により構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに提供される記録媒体等で構成される。リムーバブルメディア31は、例えば、磁気ディスク(フロッピディスクを含む)、光ディスク、又は光磁気ディスク等により構成される。光ディスクは、例えば、CD-ROM(Compact Disk-Read Only Memory),DVD(Digital Versatile Disk)等により構成される。光磁気ディスクは、MD(Mini-Disk)、等により構成される。また、装置本体に予め組み込まれた状態でユーザに提供される記録媒体は、例えば、プログラムが記録されている図3のROM12及び図3のROM12や、図3の記憶部18及び図3の記憶部18に含まれるハードディスク等で構成される。
【0098】
なお、本明細書において、本アプリケーションから他アプリケーションの順にされる実行処理は、その順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的或いは個別に実行される処理をも含むものである。
また、本明細書において、システムの用語は、複数の装置や複数の手段等より構成される全体的な装置を意味するものとする。
【符号の説明】
【0099】
1・・・サーバ、2・・・ユーザ端末、3・・・タクシー端末、11・・・CPU、12・・・ROM、13・・・RAM、14・・・バス、15・・・入出力インターフェース、16・・・入力部、17・・・表示部、18・・・記憶部、19・・・通信部、20・・・ドライブ、31・・・リムーバブルメディア、41・・・要請受付部、42・・・配車計画部、43・・・配車指示部、51・・・利用者DB、52・・・要請DB、53・・・配車計画DB、150・・・ポイント管理部、151・・・送迎実績取得部、152・・・コンテクスト取得部、153・・・乗車内容取得部、154・・・予約受付部、155・・・消費量算出部、156・・・コンテクスト提示部、161・・・ポイント付与部、162・・・ポイント消費部、171・・・タクシー車両管理DB、172・・・ポイント管理DB、N・・・ネットワーク、T・・・定額タクシー
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
【手続補正書】
【提出日】2023-06-06
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
乗客輸送サービスに対する乗客が支払う対価を演算する情報処理装置において、
前記対価として使用可能な対価量を、乗客となり得るユーザ毎に管理する管理手段と、
前記乗客が乗車した乗客輸送体についての、乗車距離及び乗車時間を取得する乗車内容取得手段と、
前記乗車距離及び前記乗車時間を入力パラメータとして、前記乗客が支払う対価としての消費対価量を出力する所定の関数に基づいて、当該消費対価量を算出する消費量算出手段と、
を備える情報処理装置。
【請求項2】
前記乗客輸送体に関するコンテクストを取得するコンテクスト取得手段をさらに備え、
前記消費量算出手段は、さらに前記コンテクストを前記入力パラメータとして、前記消費対価量を算出する、
請求項1に記載の情報処理装置。
【請求項3】
前記コンテクスト取得手段は、前記コンテクストとして、乗車人数を少なくとも取得し、
前記消費量算出手段は、前記所定の関数として、乗客1人当たりの前記消費対価量を出力する関数を用いて、当該消費対価量を算出する、
請求項2に記載の情報処理装置。
【請求項4】
前記コンテクスト取得手段は、前記コンテクストとして、乗車時間帯を少なくとも取得し、
前記消費量算出手段は、前記所定の関数として、前記乗車距離及び前記乗車時間が同一条件であっても、前記乗車時間帯に応じて異なる前記消費対価量を出力する関数を用いて、当該消費対価量を算出する、
請求項2に記載の情報処理装置。
【請求項5】
前記乗客輸送体の利用予約を前記ユーザから受け付ける予約受付手段をさらに備え、
前記消費量算出手段は、さらに、受け付けられた前記利用予約について、前記ユーザが支払う予約手数料としての前記消費対価量を算出する、
請求項2に記載の情報処理装置。
【請求項6】
取得された前記コンテクストの内容をユーザへ提示する提示手段をさらに備える、
請求項5に記載の情報処理装置。
【請求項7】
前記消費量算出手段は、前記コンテクストに加えてさらに、急ぎ度に基づいて、前記消費対価量を算出する、
請求項5に記載の情報処理装置。
【請求項8】
前記消費量算出手段は、前記コンテクストに加えてさらに、調整幅に基づいて、前記消費対価量を算出する、
請求項5に記載の情報処理装置。
【請求項9】
前記消費量算出手段は、前記コンテクストに加えてさらに、先行期間に基づいて、前記消費対価量を算出する、
請求項5に記載の情報処理装置。
【請求項10】
乗客輸送サービスに対する乗客が支払う対価を演算する情報処理装置が実行する情報処理方法において、
前記対価として使用可能な対価量を、乗客となり得るユーザ毎に管理する管理ステップと、
前記乗客が乗車した乗客輸送体についての、乗車距離及び乗車時間を取得する乗車内容取得ステップと、
前記乗車距離及び前記乗車時間を入力パラメータとして、前記乗客が支払う対価としての消費対価量を出力する所定の関数に基づいて、当該消費対価量を算出する消費量算ステップと、
を含む情報処理方法。
【請求項11】
乗客輸送サービスに対する乗客が支払う対価を演算するコンピュータに、
前記対価として使用可能な対価量を、乗客となり得るユーザ毎に管理する管理ステップと、
前記乗客が乗車した乗客輸送体についての、乗車距離及び乗車時間を取得する乗車内容取得ステップと、
前記乗車距離及び前記乗車時間を入力パラメータとして、前記乗客が支払う対価としての消費対価量を出力する所定の関数に基づいて、当該消費対価量を算出する消費量算ステップと、
を含む制御処理を実行させるプログラム。