【０００１】
【発明の属する技術分野】
本発明は、Ｗｅｂ端末、携帯電話または専用端末等によりタクシーの申し込みを行うとき、１つのタクシー業者を指定して申し込みを行う形態を採らず、複数のタクシー業者の中から、利用者が選択したあらかじめ指定された乗車位置への到着時間が最もはやいタクシー業者の車両を選択し、利用者が持つＷｅｂ端末、携帯電話または専用端末等に通知し、申し込みを成立させるシステムに関するものである。
【０００２】
【従来の技術】
従来のタクシーの申し込みは、タクシーの利用者がタクシー業者を指定することで成立するのが主であったが、利用者が一つのタクシー業者にこだわらず、複数のタクシー業者の中から最も待ち時間が少ないタクシー業者に対して配車依頼を行いたい場合に成す方法として、「特開２００２−１４０７９５」、「特開２００２−１３３５９２」号などがある。
【０００３】
【発明が解決しようとする課題】
上記した各従来方法は、利用者の持つ携帯端末により利用者の位置を探知し、その場所へ配車を行うものである。しかし、利用者の位置を探知し、その上で利用者の位置まで最も待ち時間が少なくて済むタクシー業者の車両を配車するということは、タクシー乗り場のように予め定められた場所と利用者の位置についてその距離や到着時間の計算を行う場合に比べて計算処理が複雑であり、また、利用者は申し込み時に既に乗車位置にいる必要があるのでこのことは利用者の行動を著しく制限する。
【０００４】
【課題を解決するための手段】
本発明の第一は、個人タクシー業者を含む複数のタクシー業者の車両の情報を蓄積する地域サーバを用意し、コンビニエンスストア、郵便局、バス停の如きタクシーの呼び出し場所として目標とし易い場所に登録名称、記号、番号等の識別子を与え、これをタクシーの乗車位置情報として予め上記地域サーバに登録しておき、タクシーの利用者はＷｅｂ端末、携帯電話または専用端末を含む呼び出し手段を用いて前記地域サーバにアクセスし、前記タクシーの乗車位置を指定、選択してタクシーの申し込みを行うことを特徴としたものである。
【０００５】
本発明の第二は、前記タクシー業者は、車両の位置、車両が空車状態であるかを含む車両情報を適宜タクシー業者のもつ端末または情報管理用サーバを介して前記地域サーバに送信することを特徴としたものである。
【０００６】
本発明の第三は、タクシーの乗車位置と配車可能である複数のタクシー業者の車両間の距離や車両がタクシーの乗車位置へ到着する時間の算出を前記地域サーバで行うことを特徴としたものである。
【０００７】
本発明の第四は、前記地域サーバは、一定の地域毎に設置し、予め登録するタクシーの乗車位置はその場所が含まれる地域に設置されている地域サーバにより管理され、且つタクシー業者の車両情報も当該タクシー業者が属する地域にある地域サーバを指定して登録、管理されることを特徴としたものである。
【０００８】
本発明の第五は、前記地域サーバは、一定の地域毎に設置し、各地域サーバ間で情報を交換することで、利用者から離れた地域の乗車位置であっても利用者が乗車位置として選択することができ、タクシーの呼び出しが可能であることを特徴としたものである。
【０００９】
本発明の第六は、前記地域サーバに登録するタクシーの乗車位置は、利用者がサーバに位置情報を登録することで追加登録することができ、登録以降その場所を乗車位置として選択することが可能となることを特徴としたものである。
【００１０】
本発明の第七は、前記地域サーバは、到着時間が最もはやい車両をもつタクシー業者のもつ端末または情報管理用サーバに対し配車依頼通知を行い、その回答が配車不可の場合はその次にはやく到着可能な車両に配車の権利を与え、その車両をもつタクシー業者の専用端末またはタクシー業者が持つ情報管理用のサーバへ配車依頼通知を行うことを特徴としたものである。
【００１１】
【発明の実施の形態】
図１は本発明の構成図を示したものである。利用者はタクシーの呼び出しを行うにあたり、固定端末（１１）、Ｗｅｂ端末（１２）、携帯電話（１３）等を用い、それらと地域サーバ（２１、２２、２３）間で呼び出しのためのデータの送受信を行う。タクシー業者は、タクシー業者個々が持つ管理用のサーバ（３２）を通じて、また、管理用のサーバを持たない個人タクシー業者等は端末（３１）を通じて地域サーバと車両の空車情報等のデータの送受信を行う。地域サーバは、複数のタクシー業者のサーバ、端末から送られてくる情報を一括管理し、また、利用者側から送られてくる呼び出し情報に基づき処理を行う。地域サーバはタクシーの利用者と複数のタクシー業者の間に入り、タクシー配車の契約を成立させる代理人の役割を果たす。
【００１２】
利用者、地域サーバ、タクシー業者の管理用のサーバ、端末（以下、供給者サーバと称す）の役割をふまえた上で、図２に示した本発明のタクシー呼び出し方法を示すフローについて説明する。図２の（ａ）、（ｂ）、（ｃ）はそれぞれ利用者、地域サーバ、供給者サーバのフローに該当する。
【００１３】
タクシーの利用者はタクシーの呼び出しを行うにあたり、携帯電話、Ｗｅｂ端末、固定端末等を用いてタクシーの呼び出しに必要なデータであるタクシーの車種、台数、乗車位置情報の入力をＳ１にて行う。タクシーの車種、乗車位置等の情報は上記端末から地域サーバへアクセスし端末上に表示されるものであるが、乗車位置の決定は端末に選択形式で表示された乗車位置リストを選択する方法のほか、数値、その他の情報を利用者が任意に入力することも可能である。ここでいう乗車位置情報は、コンビニエンスストア、郵便局、バス停の如きタクシーの呼び出し場所として目標とし易い場所に登録名称、記号、番号を与え、事前に地域サーバに登録しておくものであり、利用者が位置情報を追加登録することができ、登録以降はその場所も乗車位置として選択できる。
【００１４】
続いてＳ２においては、Ｓ１で利用者が入力したデータが正しい入力形式であるか判断し、データが不正であればＳ１へ戻りデータの再入力を行い、正しければＳ３の処理へ進む。
【００１５】
Ｓ３では、Ｓ２でデータの正当性が正しいと判断されたので、そのデータを地域サーバへ送信し、フロー上のＳ３２の処理へと進む。データが正常に送信されたかの判断はＳ４にて行い、送信が不正である場合にはＳ３の処理を繰り返す。なお、送信されるデータには申し込み毎に固有に割り当てられる申し込み番号が付加され、その上でデータが送信される。
【００１６】
ここで、地域サーバのフローＳ３２へ進んだデータの処理を説明する前に、地域サーバへデータを送信した後の利用者端末の処理を記す。
【００１７】
Ｓ４にて通信が正常に完了し、データが地域サーバへ送られたことを確認した後は、Ｓ５の処理を行い、利用者側の端末には通信中である旨の表示をしておく。
【００１８】
Ｓ６は、サーバからのデータ受信確認処理であり、ここでは地域サーバから送信される配車可否の回答データを受信する。
【００１９】
回答データを正常に受信できたかＳ７で判別処理を行い、受信不正であればＳ６へ戻り、受信完了であれば、Ｓ８へ進み、回答内容の表示を行う。
【００２０】
Ｓ８にて回答内容を確認し、呼び出し情報の変更等再入力が必要な場合はＳ１へ戻り呼び出しをやり直し、再入力が必要ない場合はＳ１０へ進み呼び出し完了となる。
【００２１】
次に地域サーバのフローについて説明する。
【００２２】
地域サーバにおいては、供給者サーバのフローＳ５５からＳ３１へ送られてくる空車情報変更通知に基づきデータは更新され、常に最新のデータを蓄積している。
【００２３】
また、Ｓ３２にて利用者端末からの受信処理、Ｓ３３にて受信チェックをする処理を備えているが、常に利用者端末から受信があるかどうかチェックし、受信がない場合はＳ３３からＳ３１へ処理を戻し、前記の通りＳ３１で空車情報の更新を行い最新のデータを蓄積しつつ、利用者の申し込みデータを受信すべく待機している。
【００２４】
利用者からのデータが受信された場合は、Ｓ３３で受信確認を行い、Ｓ３４でデータの正当性を判断する。正当性が認められない場合はＳ３５で利用者の端末に対して再送信要求処理が行われ、Ｓ３２に戻る。
【００２５】
データの正当性が認められた場合はＳ３６にて現在空車である車両が利用者が指定した乗車位置へ到着する到着時間の計算が行われる。
【００２６】
Ｓ３６にて一番到着時間がはやい車両が決定すると、Ｓ３７にて供給者サーバに配車依頼通知を送信し、供給者サーバは、Ｓ５１の処理を行う。なお、Ｓ３７の配車依頼通知は、Ｓ３８にて通信の正常完了か否か判断され、否の場合はＳ３７の処理を繰り返す。
【００２７】
Ｓ３８にて通信の正常完了が確認されると、Ｓ３９にて供給者サーバから配車回答を受信し、配車の可否による判断処理をＳ４０にて行う。
【００２８】
回答が否の場合はＳ４１で到着時間が一番はやい車両から２番目にはやい車両へと配車依頼を行う優先度を変更する処理を行い、Ｓ３７へ進み、また、回答が可の場合はＳ４２の処理へ進み、ここで利用者端末に回答通知処理を行う。回答受信処理は利用者端末のフローにおけるＳ６で行われる。
【００２９】
Ｓ４２における回答通知処理は、Ｓ４３にて通信が正常に完了したか確認され、正常に完了していない場合はＳ４２へ戻り処理を繰り返す。
【００３０】
回答通知処理が正常に完了した場合は、Ｓ４３からＳ４４へ進み、利用者端末、供給者サーバとの通信を終了する場合はＳ４５に進み、終了しない場合は、Ｓ３１へ戻り、再度呼び出しを受け付けるまでは空車情報等を更新しつつ待機している状態となる。
【００３１】
次に、供給者サーバのフローについて説明する。
【００３２】
供給者サーバでは、地域サーバから配車依頼通知がない間、車両の空車情報を更新し、地域サーバに送信するを処理を繰り返し、地域サーバから配車依頼通知を受信すると、その通知に対し、配車可否の回答を通知する処理を行っている。上記の内容についてステップ毎に説明する。
【００３３】
Ｓ５１は地域サーバのＳ３７から配車依頼通知を受信する処理である。
Ｓ５２では配車依頼の可否を判別し、否の場合は、Ｓ５３にて車種、車両の位置等の空車情報の更新を行い、Ｓ５４にて空車情報の変更があったかどうかを判別し、空車情報の変更がない場合はＳ５１へ、変更があった場合はＳ５５にて地域サーバのＳ３１へ空車情報変更通知を行った後Ｓ５１へ処理を戻す。
【００３４】
Ｓ５２で配車依頼があることが確認されると、次にＳ５６で空車があるかどうか確認する。Ｓ５６に基づきＳ５７で配車可否回答処理を行い、その回答は地域サーバのＳ３９へ送信される。Ｓ５７の情報送信が正常に完了したか否かの判断はＳ５８で成され、正常に送信が完了しなかった場合はＳ５７に戻り再送信を行う。
【００３５】
Ｓ５９では地域サーバとの通信処理を終了するか、それとも配車依頼通知を待機する状態に戻るどうかの選択処理を行い、前者の場合はＳ６０へ進み処理を終了とし、後者の場合はＳ５１へ戻り次に配車依頼通知が送られてくるまで自社の空車情報を更新、地域サーバに送信しつつ待機することとなる。
【００３６】
【発明の効果】
以上述べたように、本願発明は、従来のタクシーの呼び出し方法のようにタクシー乗り場に並んで待つような必要もなく、また、道端でいつ来るかわからないタクシーを待って呼び止める必要もないということに加え、タクシーの呼び出しをするにあたり予めデータベースに登録されている定められた乗車位置を指定して呼び出しを行うので、タクシー業者、タクシー利用者双方にとって乗車位置の把握を容易にし、タクシー業者にとっては配車位置が既知であることは目的地までの到達時間を短くすることができ、そのことはタクシー利用者にとっては待ち時間を減らすことになる。
【００３７】
また、本願発明はタクシーの呼び出し時、利用者の位置を探知し、その場所へ配車するような方法を採っていないので、タクシーの乗車位置は利用者の現在位置に左右されない。このことは例えば利用者がタクシーの乗車位置へ移動中である場合であってもタクシーの呼び出しが可能となるという効果を持つ。これは前記の予め定められた乗車位置を指定して呼び出しをとることの効果とあわせ従来にはない効果である。
また、本願実施例においては、利用者が入力した情報に基づき処理が行われていることを説明したが、地域サーバにコールセンターを設けることで、本システムにおいて音声通話による呼び出し、回答が可能となる。
【図面の簡単な説明】
【図１】本発明の構成図。
【図２】本発明のタクシー呼び出し方法を示すフロー。
【符号の説明】
１１…申し込み用固定端末
１２…Ｗｅｂ端末
１３…携帯電話
２１…地域サーバ
２２…地域サーバ
２３…地域サーバ
３１…タクシー業者用端末
３２…タクシー業者用管理サーバ
４１…車載端末[0001]
TECHNICAL FIELD OF THE INVENTION
According to the present invention, when applying for a taxi using a Web terminal, a mobile phone, a dedicated terminal, or the like, the user does not adopt a form in which one taxi company is designated and the application is selected from a plurality of taxi companies. The present invention relates to a system for selecting a vehicle of a taxi dealer who has the earliest arrival time at a pre-specified boarding position, informing the user of a Web terminal, a mobile phone or a dedicated terminal, and completing the application.
[0002]
[Prior art]
Conventional taxi applications have generally been established when the taxi user designates a taxi operator, but the user is not limited to one taxi operator and the most waiting time among multiple taxi operators There are methods disclosed in Japanese Patent Application Laid-Open No. 2002-140795 and Japanese Patent Application Laid-Open No. 2002-133592 as methods to be performed when it is desired to make a dispatch request to a taxi company with a small number of vehicles.
[0003]
[Problems to be solved by the invention]
In each of the conventional methods described above, the position of the user is detected by the mobile terminal of the user, and the vehicle is dispatched to that location. However, locating a user and then arranging a taxi operator's vehicle that requires the least waiting time to the user's position means that a predetermined location such as a taxi stand and the user's The calculation process is more complicated than the case of calculating the distance and the arrival time of the position, and the user must be already at the boarding position at the time of application, which significantly restricts the behavior of the user.
[0004]
[Means for Solving the Problems]
The first aspect of the present invention is to prepare a regional server that stores information of vehicles of a plurality of taxi companies including a personal taxi company, and to register a registered name in a place that is easily targeted as a taxi calling place, such as a convenience store, a post office, a bus stop. , Symbols, numbers, etc., are registered in advance in the above regional server as taxi ride position information, and taxi users can use the calling means including a Web terminal, a mobile phone or a dedicated terminal to call the local area. The present invention is characterized in that a server is accessed, a taxi ride position is designated and selected, and a taxi application is made.
[0005]
A second aspect of the present invention is that the taxi company transmits vehicle information including the location of the vehicle and whether the vehicle is empty to the regional server via a terminal or an information management server of the taxi company as appropriate. It is a characteristic.
[0006]
The third aspect of the present invention is characterized in that the local server calculates the distance between taxi ride locations and the distance between vehicles of a plurality of taxi companies that can be dispatched and the time at which vehicles arrive at taxi ride positions. It is.
[0007]
A fourth aspect of the present invention is that the regional server is installed for each predetermined area, and the boarding position of a taxi registered in advance is managed by a regional server installed in the area including the place, and the taxi company's vehicle The information is also characterized by being registered and managed by designating a regional server in the region to which the taxi company belongs.
[0008]
A fifth aspect of the present invention is that the regional server is installed in each fixed area, and information is exchanged between the regional servers. And a taxi can be called.
[0009]
In the sixth aspect of the present invention, the ride position of a taxi registered in the regional server can be additionally registered by the user by registering position information in the server, and after registration, the place can be selected as the ride position. The feature is that it becomes possible.
[0010]
A seventh aspect of the present invention is that the regional server sends a dispatch request notification to a terminal or an information management server of a taxi company having a vehicle with the earliest arrival time, and if the answer is that dispatch is impossible, then it is the next. A right of dispatch is given to a vehicle that can arrive, and a dispatch request notification is sent to a dedicated terminal of a taxi company having the vehicle or an information management server of the taxi company.
[0011]
BEST MODE FOR CARRYING OUT THE INVENTION
FIG. 1 shows a configuration diagram of the present invention. When calling a taxi, the user uses a fixed terminal (11), a Web terminal (12), a mobile phone (13), or the like, and transmits data for calling between them and the regional server (21, 22, 23). Send and receive. Taxi companies transmit and receive data such as vacant information of vehicles to / from local servers through the terminal (31) through the management server (32) of each taxi company, and individual taxi companies without the management server through the terminal (31). Do. The regional server collectively manages information sent from servers and terminals of a plurality of taxi operators, and performs processing based on call information sent from the user side. The regional server enters between the taxi user and the taxi operators and acts as an agent for signing a taxi dispatch contract.
[0012]
A flow of the taxi calling method of the present invention shown in FIG. 2 will be described based on the roles of a user, a regional server, a server for managing taxi companies, and a terminal (hereinafter, referred to as a supplier server). 2A, 2B, and 2C correspond to the flows of the user, the regional server, and the supplier server, respectively.
[0013]
In calling a taxi, the taxi user inputs information on the type of taxi, the number of taxis, and the boarding position information required for calling the taxi using a mobile phone, a Web terminal, a fixed terminal, or the like in S1. The information such as the type of taxi and the boarding position is displayed on the terminal by accessing the regional server from the terminal, but the determination of the boarding position is based on the method of selecting the boarding position list displayed on the terminal in a selection format. In addition, the user can arbitrarily input numerical values and other information. The boarding position information referred to here is to assign a registered name, symbol, and number to a place that is easy to target as a taxi calling place such as a convenience store, post office, bus stop, and to register it in advance on the regional server, The user can additionally register the location information, and after the registration, the location can be selected as the boarding position.
[0014]
Subsequently, in S2, it is determined whether or not the data input by the user in S1 is in a correct input format. If the data is incorrect, the process returns to S1 to re-enter the data. If the data is correct, the process proceeds to S3.
[0015]
In S3, since the validity of the data is determined to be correct in S2, the data is transmitted to the regional server, and the process proceeds to S32 in the flow. It is determined in S4 whether the data has been transmitted normally, and if the transmission is incorrect, the process of S3 is repeated. It should be noted that an application number uniquely assigned to each application is added to the transmitted data, and then the data is transmitted.
[0016]
Here, before describing the processing of the data that has proceeded to the flow S32 of the regional server, the processing of the user terminal after transmitting the data to the regional server will be described.
[0017]
After confirming that the communication has been normally completed in S4 and that the data has been sent to the regional server, the process of S5 is performed, and a message indicating that communication is in progress is displayed on the terminal on the user side.
[0018]
S6 is a process for confirming data reception from the server. Here, the response data indicating whether or not the vehicle can be dispatched is transmitted from the regional server.
[0019]
At S7, a determination process is performed to determine whether the answer data has been normally received. If the answer is incorrect, the process returns to S6, and if the reception is completed, the process proceeds to S8, and the answer content is displayed.
[0020]
In S8, the contents of the answer are confirmed. If re-input such as change of call information is necessary, the process returns to S1 and the call is redone. If no re-input is necessary, the process proceeds to S10 to complete the call.
[0021]
Next, the flow of the regional server will be described.
[0022]
In the regional server, the data is updated based on the empty vehicle information change notification sent from the flow S55 to S31 of the supplier server, and the latest data is always stored.
[0023]
In addition, a process for receiving from the user terminal in S32 and a process for checking reception in S33 are provided, but it is always checked whether or not there is reception from the user terminal. If there is no reception, the process proceeds from S33 to S31. As described above, in step S31, empty vehicle information is updated and the latest data is accumulated, and the system stands by to receive user application data.
[0024]
When the data is received from the user, the reception is confirmed in S33, and the validity of the data is determined in S34. If the validity is not recognized, a retransmission request process is performed on the user terminal in S35, and the process returns to S32.
[0025]
If the validity of the data is confirmed, the arrival time at which the currently empty vehicle arrives at the boarding position designated by the user is calculated in S36.
[0026]
When the vehicle with the earliest arrival time is determined in S36, a dispatch request notification is transmitted to the supplier server in S37, and the supplier server performs the process of S51. Note that the vehicle allocation request notification in S37 is determined in S38 as to whether or not the communication is normally completed. If not, the process in S37 is repeated.
[0027]
When the normal completion of the communication is confirmed in S38, a dispatch response is received from the supplier server in S39, and a determination process based on the propriety of dispatch is performed in S40.
[0028]
If the answer is no, the process of changing the priority of requesting a dispatch from the vehicle having the earliest arrival time to the vehicle having the second earliest arrival time in S41 is performed, and the process proceeds to S37. Proceed to the process, where the user terminal performs a response notification process. The answer receiving process is performed in S6 in the flow of the user terminal.
[0029]
In the answer notification process in S42, it is checked whether the communication has been completed normally in S43. If the communication has not been completed normally, the process returns to S42 and repeats the process.
[0030]
If the answer notifying process is completed normally, the process proceeds from S43 to S44. If the communication with the user terminal and the supplier server is to be ended, the process proceeds to S45. If not, the process returns to S31 and the call is received again. Is in a state of waiting while updating empty car information and the like.
[0031]
Next, the flow of the supplier server will be described.
[0032]
The supplier server repeats the process of updating the vacant vehicle information of the vehicle and transmitting the information to the regional server while there is no dispatch request notification from the regional server. Is notified. The above contents will be described for each step.
[0033]
S51 is a process of receiving a dispatch request notification from S37 of the regional server.
In S52, it is determined whether or not a vehicle allocation request can be made. If not, in S53, empty vehicle information such as a vehicle type and a vehicle position is updated. In S54, it is determined whether or not empty vehicle information has been changed. If there is no such information, the process returns to S51, and if there is a change, the process returns to S31 of the regional server in S55, and then returns to S51.
[0034]
If it is confirmed in S52 that there is a dispatch request, it is next confirmed in S56 whether there is an empty vehicle. Based on S56, a vehicle allocation permission / inhibition response process is performed in S57, and the response is transmitted to S39 of the regional server. The determination as to whether or not the information transmission in S57 has been completed normally is made in S58. If the transmission has not been completed normally, the process returns to S57 and retransmits.
[0035]
In S59, a process of selecting whether to end the communication process with the regional server or to return to the state of waiting for the vehicle allocation request notification is performed. In the former case, the process proceeds to S60 to end the process, and in the latter case, the process returns to S51 and returns to S51. Until the vehicle allocation request notification is sent to the company, the company updates its empty vehicle information and waits while transmitting it to the regional server.
[0036]
【The invention's effect】
As described above, according to the present invention, there is no need to wait in line at a taxi stand as in the conventional method of calling a taxi, and it is not necessary to wait for a taxi at a roadside to know when to come and stop. In addition, when calling a taxi, a specified ride position registered in the database is specified before calling, so that both taxi operators and taxi users can easily grasp the ride position, and taxi operators can dispatch Knowing the location can reduce the time to reach the destination, which in turn reduces waiting time for taxi users.
[0037]
In addition, the present invention does not employ a method of detecting the position of a user when calling a taxi and allocating the vehicle to that position, so the taxi ride position is not affected by the current position of the user. This has the effect, for example, that a taxi can be called even when the user is moving to the taxi ride position. This is an unprecedented effect in addition to the effect of taking a call by designating the predetermined boarding position.
Also, in the embodiment of the present application, it has been described that the processing is performed based on the information input by the user, but by providing a call center in the regional server, it is possible to call and answer by voice call in this system. .
[Brief description of the drawings]
FIG. 1 is a configuration diagram of the present invention.
FIG. 2 is a flowchart showing a taxi calling method according to the present invention.
[Explanation of symbols]
11 ... fixed terminal for application 12 ... Web terminal 13 ... mobile phone 21 ... regional server 22 ... regional server 23 ... regional server 31 ... taxi dealer terminal 32 ... taxi dealer management server 41 ... on-board terminal
