JPWO2002011007A1 - レンタルシステム - Google Patents

Abstract

本発明の目的は、レンタル会社が保有する全てのレンタル品を一元管理することで、効率の高いレンタル品の運用を可能にするコンピュータ利用のレンタルシステムを提供する。レンタル品、例えば建設車両１０１、１０１、…の現在位置及び稼動状態を実時間で把握して、ネットワーク４００を通じて、レンタル会社システム１００に通知する。レンタル会社システム１００の基幹サーバ１０８は、建設車両１０１、１０１、…の現在位置及び稼動状態、並びにレンタル状況や整備状況などを一元的に管理して、各支店のサーバ１１１などの提供する。支店では、端末コンピュータ１１２や、営業員が携帯する携帯電話１０４やＰＤＡ１０４などを用いて、現在の建設車両１０１、１０１、…の最新の上記諸状態を参照して、建設車両１０１、１０１、…のレンタル受注や移動や整備などの様々な処理を行う。

Description

技術分野
本発明は、機械や物品のレンタル業務を支援するためのコンピュータ処理システム及びその処理方法に関する。
技術背景
建設車両のレンタルを例に取り以下説明するが、本明細書の説明は建設車両以外の機械や物品のレンタルにもあてはまるものである。
建設車両のレンタル会社は、通常、異なる場所に複数の支店を配し、各支店がそれぞれ独自に、複数台の建設車両を保有し整備し運用するという営業形態を採用している。本社は、車両の管理や保全や運用は個々の各支店に任せ、支店の営業成績や経理情報を主として管理している。各支店や本社の業務処理を支援するためのコンピュータシステムも導入されているであろう。しかし、従来のそうしたコンピュータシステムは当然に、上述した営業形態に適合した機能、つまり、各支店ごとの車両管理機能、或いは、本社での営業成績や経理情報の管理機能しかもたないはずである。
また、営業員は、顧客から引き合いが合ったとき、それぞれの出先場所から支店のオフィスに電話をかけるなどして、オフィスの担当員に現在の車両運用状況を問い合わせたり、車両のレンタル予約を依頼したりしている。
また、車両を顧客に貸し出した後、顧客から戻って来るまでは、何処でどのように使われているか、調子は良好か否かなどの車両の現況について、顧客から報告のない限り、レンタル会社がそれを知ることはできない。
従来のレンタル会社が抱える一つの問題は、会社全体として最も高い効率での車両のレンタルや搬送などの運用ができない点である。これは、支店毎に独立した運営を行う営業形態に起因している。例えば、Ａ支店では或る機種に多くの引き合いが来て車両が不足しているにもかかわらず、Ｂ支店では同じ機種に引き合いがなく車両が車庫で遊んでいるというケースが発生し得る。また、Ａ支店が先の顧客から車両を受けとって、次の顧客へ貸出そうとするとき、その車両を先の顧客の現場からＡ支店の車庫へ戻すより、Ｂ支店の車庫へ戻して次の顧客の現場へ送った方が、搬送の距離や時間やコストがより小さくなるという場合があっても、現実には貸出し元のＡ支店の車庫にその車両を戻すという非効率な運用を行っている。
また、別の問題は、顧客のニーズに迅速に対応することが難しい点である。その原因の一は、上述した支店毎に独立した営業形態のために、会社全体での最適な車両振り当てを顧客に対しできないからである。もう一つの原因は、営業員が、支店オフィスに電話をかけない限り、車両の運用状況を把握したり、レンタル予約を入れたりすることができず、そうした情報処理を何処からでも何時でも直接に営業員が行える手段がないからである。
さらに別の問題は、最適なメンテナンスが難しい点である。すなわち、顧客に貸し出し中の車両については、その車両が使われている現場や車両の状態をレンタル会社が自主的に把握することができないので、その現場に適切な時期にレンタル会社から自発的に人を派遣して車両にメンテナンスをほどこすということができない。
また別の問題は、どの車両の品質も均一な水準に維持されるような品質管理が難しい点である。このことは、また、会社がレンタルに使った車両を後に中古車市場に出すときに、中古車の買い手に車両の品質を保証することが難しいという問題につながる。その原因は、各車両の稼動時間やメンテナンス履歴などを明確に判るように管理して、その結果に応じて各車両の運用を制御することが従来全くなされていないからである。
従って、本発明の目的は、レンタル会社が保有する全てのレンタル品を一元管理することで、効率の高いレンタル品の運用を可能にするコンピュータ利用のレンタルシステムを提供することにある。
本発明の別の目的は、顧客のニーズに営業員が迅速に対応することを可能にするコンピュータ利用のレンタルシステムを提供することにある。
本発明のまた別の目的は、レンタル品に効率的にメンテナンスを施すことを可能にするコンピュータ利用のレンタルシステムを提供することにある。
本発明の更に別の目的は、レンタル品の品質管理を容易にし、後にレンタル品を中古品市場に出したときに買い手に中古品の品質を保証することを可能にするコンピュータ利用のレンタルシステムを提供することにある。
発明の開示
本発明の第１の観点に従うレンタルシステムは、複数のレンタル品の情報を管理する基幹サーバシステムと、この基幹サーバシステムと通信接続することが可能な業務システムとを備える。そして、基幹サーバまたは業務システムが、レンタル品の顧客との授受を管理する管理手段を有する。さらに、業務システムが、レンタル品について
（１）　前記基幹サーバシステムが管理する情報を表示する手段と
（２）　顧客からのレンタル注文を受付ける手段
を有している。
このレンタルシステムによれば、基幹サーバシステムが、レンタル会社が保有する複数のレンタル品を一元的に管理しており、業務システムは、基幹サーバシステムで一元管理されているレンタル品の情報を表示して、その表示された情報に基づいて、顧客からの注文に最適なレンタル品を選んで顧客に提供することができる。結果として、効率的なレンタル品の運用が可能である。
好適な実施形態では、レンタル品の情報は、レンタル品の商品名をベースとして基幹サーバシステムに蓄積されている。よって、レンタル品の商品名を検索キーにして、その商品名をもつ全てのレンタル品の情報を検索して表示することができる。
好適な実施形態では、基幹サーバシステムが、レンタル品の場所間の移動のスケジュールを処理する手段を有している。この手段により、レンタル品を前の顧客から返却されて次の顧客へ貸し渡すための移動スケジュールが処理できるので、移動スケジュールが無駄の少ない効率的なものになるよう、レンタル品をどの顧客に何時貸し出すかという点を判断してコントロールできるようになる。
好適な実施形態では、基幹サーバシステムで管理されているレンタル品の情報が、レンタル品の貸し出し中または運搬中の情報を含んでいる。そのため、あるレンタル品について顧客から引き合いがあったとき、そのレンタル品が貸し出し中か運搬中かの情報を表示して、引き合いに応じることができるかを迅速に判断することができる。
好適な実施形態では、基幹サーバシステムで管理されているレンタル品の情報が、レンタル品の貸し出し期間の情報を含んでいる。そのため、あるレンタル品について顧客から引き合いがあったとき、そのレンタル品が貸し出し中又は貸し出し予約済みであっても貸し出し期間が分るため、いつ返却されるか予測できるので、引き合いに応じることができるかを的確に判断することができる。
好適な実施形態では、基幹サーバシステムで管理されているレンタル品の情報が、レンタル品の入出庫情報を含んでいる。そのため、あるレンタル品について顧客から引き合いがあったとき、そのレンタル品が入庫したか出庫したかの情報を表示して、引き合いに応じることができるかを迅速に判断することができる。
好適な実施形態では、基幹サーバシステムで管理されているレンタル品の情報が、レンタル品の位置情報を含んでいる。また、この位置情報を随時または定期的に更新する手段が備えられている。そのため、あるレンタル品について顧客から引き合いがあったとき、そのレンタル品の位置情報を表示して、引き合いに応じることができるかを迅速に判断することができる。また、あるレンタル品についてメンテナンスが必要になったとき、そのレンタル品の位置情報を表示して、サービスマンを派遣するなど必要な措置をとることができる。
好適な実施形態では、基幹サーバシステムで管理されているレンタル品の情報が、レンタル品の稼動状況を表す情報を含んでいる。そのため、各レンタル品の稼動情報を表示して、稼動が多すぎて過度に消耗したりすることがないように、レンタル品の運用をコントロールすることが可能となる。このことは、レンタル品を後に中古品市場へ出したときの品質保証を容易にする。
好適な実施形態では、基幹サーバシステムで管理されているレンタル品の情報が、レンタル品たる機械のエンジン油圧またはエンジン回転数または作業機油温または作業機油圧またはラジエータ水温または作業機負荷に関する情報を含んでいる。これらの情報を表示することで、レンタル品のメンテナンスや修理が必要か否かの判断が可能となる。
好適な実施形態では、業務システムが、基幹サーバシステムと随時に無線通信接続することが可能な携帯情報処理システム（例えば、携帯電話）を有している。各営業員が携帯情報処理システムを携帯して、それにレンタル品の情報を表示することで、場所や時間に制限されずに顧客のニーズに迅速に対応擦ることが可能となる。
好適な実施形態では、基幹サーバシステムが、レンタル品の情報（例えば、顧客からの注文情報など）を随時にまたは定期的に更新する手段を有する。これにより、業務システムでは、常にレンタル品の最新の情報を表示することができる。
好適な実施形態では、業務システムが、顧客からの注文引き合いの情報を受付ける手段を有している。
好適な実施形態では、レンタル品は、位置情報と現在の稼働状態情報を検出するセンサシステムを有している。そして、基幹サーバシステムは、レンタル品のセンサシステムと遠隔無線通信網を通じて通信可能であり、レンタル品のセンサシステムより随時または定期的にレンタル品の最新の位置情報と稼働状態情報を受信して、基幹サーバシステムが管理するレンタル品の位置情報と稼働状態情報を更新している。これにより、業務システムやメンテナンスシステムが、レンタル品の現在の位置と現在の稼働状態とを実質的に実時間で把握することが可能となり、顧客からの引合いへの対応やメンテナンスなどを迅速、的確かつ効率よく行うことが可能となる。
好適な実施形態では、基幹サーバシステムで管理されているレンタル品の情報が、レンタル品の品種と空き状態と自動振り当て規制の有無を示すデータを含んでいる。そして、顧客からの注文を受け、基幹サーバシステム内の情報に基づいて複数のレンタル品の中から顧客の要求に合うレンタル品を検索し、検索されたレンタル品の中のいずれかを顧客からの注文を割り当てる注文処理システムが設けられている。
好適な実施形態では、上記注文処理システムが、複数のレンタル品の中から任意のレンタル品を指定して、指定したレンタル品について、基幹サーバシステム内の前記自動振り当て規制の有無を示すデータを更新する自動振り当て制御システムを有している。
好適な実施形態では、上記自動振り当て制御システムが、前記検索されたレンタル品の中から前記顧客からの注文に振り当てられるレンタル品を選定する方法として、自動的に選定する方法とオペレータがマニュアルで選定する方法のいずれを採用するかを制御する。このように、注文が来さえすれば自動的に無制限に貸し出すようにするか、自動的な貸出しを制限して、オペレータの判断で貸出しを許可するか否かを決めるのかを、各レンタル品ごとに制御することで、各レンタル品のトータルの稼動時間や仕様量や消耗度合いを調節できる。その結果、各レンタル品を一定期間後に中古品市場へ出したとき、その品質を一定水準にすることができ、中古品の顧客に対して品質保証ができるようになる。品質保証ができる結果として、各レンタル品について、それを中古市場に出す時期よりずっと以前の時点で、中古品の顧客から購入予約を受けることも可能である。
好適な実施形態では、基幹サーバシステムが、レンタル品の画像情報を記憶する手段を有している。この画像情報は、レンタル品が顧客に貸し出される時または返却される時に、そのレンタル品を撮影して得た写真データである。このように、各レンタル品が顧客へ貸し出されるときや顧客から返却されたときに撮影した写真データを保管することで、レンタル中にレンタル品の損傷が生じたか否かの判断が正確に行え、そのような事故への適切な対応が採り易くなる。更に、そのレンタル品を後に中古品市場へ出したときに、中古品の顧客に対して、それらの写真データを中古品の品質保証の証拠として提供することができるので、高い信頼を得ることできる。
本発明の第２の観点に従うレンタルシステムは、複数のレンタル品の情報を管理する基幹サーバシステムと、この基幹サーバシステムと通信接続することが可能な業務システムとを備える。基幹サーバシステムには、レンタル品の現在の位置情報と、現在の稼働状態情報と、メンテナンス履歴またはメンテナンススケジュールに関するメンテナンス情報が記憶されている。また、メンテナンス実施部門にはメンテナンスシステムが設けられている。このメンテナンスシステムは、基幹サーバシステムと通信接続することが可能で、基幹サーバシステムに記憶された位置情報と稼働情報とメンテナンス情報を取得して表示する手段を備える。
このレンタルシステムによれば、メンテナンス実施部門では、どのレンタル品についても、それが現在在庫中であるか顧客にレンタル中であるかに関わらず、現在の位置情報と現在の稼動状態情報とメンテナンス情報を随時に参照することができる。そのため、メンテナンス実施部門では、各レンタル品のメンテナンスの必要性の判断や、メンテナンス作業のスケジューリングや、サービスマンを派遣する必要がある場合には誰を何処へ派遣すべきかなのかなどの判断を、容易且つ適切に行うことができる。
発明を実施するための最良の形態
図１は、建設車両のレンタル会社を支援するための本発明の一実施形態にかかるレンタルシステムの全体的システム構成を示す。
このシステムは、レンタル会社内の情報処理を行うコンピュータシステム（以下、レンタル会社システムという）１００と、レンタル品たる多数の建設車両１０１、１０１、…と、これらの建設車両１０１、１０１、…の位置や稼動状態などを遠隔で把握するＴＭＳ（Ｔｅｌｅ−Ｍａｎａｇｅｍｅｎｔ　Ｓｙｓｔｅｍ）メールサーバ３００とを備える。
建設車両１０１、１０１、…とＴＭＳメールサーバ３００とは、例えば衛星通信システム２００のような非常に広域で場所を選ばない無線通信システムを通じて、原則として何処に建設車両１０１、１０１、…が居ようとも、何時でも、通信できるようになっている。建設車両１０１、１０１、…の各々は、ＧＰＳ装置や、車両内各部の状態を把握する各種のセンサを搭載しており、ＧＰＳ装置が把握した現在位置や、各種センサが把握した稼動情報（稼動時間、故障・異常内容、エンジン油圧、エンジン回転数、作業機油温、作業機油圧、ラジエータ水温、作業機負荷、燃料残量など）を、衛星通信システム２００を通じて、ＴＭＳメールサーバ３００を随時に通知することができる。
ＴＭＳサーバ３００とレンタル会社システム１００は、例えばインターネット４００のようなコンピュータ間通信網を通じて、何時でも通信できるようになっている。ＴＭＳメールサーバ３００は、建設車両１０１、１０１、…の最新の位置情報や稼動情報を収集し、それを例えば電子メールの形でレンタル会社システム１００に随時に又は定期的に通知する。
レンタル会社システム１００は、会社建物内に配備された各種のコンピュータ１０５〜１１２と、営業員１０２、１０２、…がそれぞれ携帯する携帯情報処理端末、例えば携帯電話１０３、１０３…及びＰＤＡ（Ｐｅｒｓｏｎａｌ　Ｄｉｇｉｔａｌ　Ａｓｓｉｓｔａｎｔｓ）１０４、１０４、…とを備える。なお、図示のシステム構成は一例に過ぎず、他の構成が採用可能であることは言うまでもない。例えば、各営業員１０２は携帯電話１０３とＰＤＡ１０４の２台の装置を携帯するが、それは、本願の出願時点で携帯電話１０３は情報処理及び表示機能において不充分な面があり、ＰＤＡ１０４は通信機能において不充分な面があるためであり、よって、両機能に十分優れた携帯端末が将来利用可能になればそれ１台で十分である。
レンタル会社システム１００のファイヤウォール１０５の内側では、メールサーバ１０６が、ＴＭＳメールサーバ３００から送られてくる建設車両１０１、１０１、…の最新の位置情報や稼動情報を記述した電子メール（以下、ＴＭＳメールという）を受信し蓄積する。ＴＭＳデータ処理サーバ１０７が、メールサーバ１０６に蓄積されたＴＭＳメールを受け取り、その電子メールから建設車両１０１、１０１、…の最新の位置情報や稼動情報を表すデータ（以下、ＴＭＳデータという）を取り出し、そのＴＭＳデータを基幹サーバ１０８に送る。
基幹サーバ１０８は、レンタル会社システム１００が必要とする全てのデータを蓄積したデータベースを有する。このデータベースに蓄積されているデータ（以下、マスタデータという）の詳細は後に説明する。基幹サーバ１０８は、ＴＭＳデータを受信すると、それを用いて、建設車両１０１、１０１、…の位置情報や稼動情報に関するマスタデータを更新する。基幹サーバ１０８は、社内ネットワークを通じて、このレンタル会社がもつ多数の支店の各々に配備された支店サーバ１１１、１１１、…と接続されており、支店サーバ１１１、１１１、…に対してそれぞれの支店の業務で必要となるマスタデータを定期的又は随時に送信する。基幹サーバ１０８は、また、社内ネットワークを通じて、このレンタル会社の本部に設置された本部サーバ１１３とも接続されており、本部サーバ１１３に対して本部の業務で必要となるマスタデータを定期的又は随時に送信する。支店や本部の業務の詳細については、後に説明する。
携帯電話コンテンツサーバ１０９が基幹サーバ１０８に接続されている。携帯電話コンテンツサーバ１０９は、例えばインターネット４００を通じて、営業員１０２、１０２、…がもつ携帯電話１０３、１０３、…のウェブブラウザと通信することができ、それにより、それら携帯電話１０３、１０３、…のウェブブラウザに各種のデータを所定形式の携帯電話コンテンツとして送信したり、そのウェブブラウザから所定のデータを受信したりすることができる。
携帯電話コンテンツとして携帯電話１０３、１０３、…に提供できるデータの種類には、例えば、各建設車両のレンタルの空き状況や予約状況、各顧客の貸出し実績、各建設車両の稼動率、各レンタル契約の状況、出庫車両の状況などがある。携帯電話コンテンツサーバ１０９は、まず、各営業員１０２の携帯電話１０３から特定の携帯電話コンテンツに対する検索要求を受け、次に、その要求された携帯電話コンテンツに必要な最新のマスタデータの検索要求を基幹サーバ１０８に送り、続いて、基幹サーバ１０８から検索結果のデータを受け取り、そして、その最新データを基に要求された携帯電話コンテンツを作成して、その携帯電話コンテンツをその営業員１０２の携帯電話１０３に送信して表示させる。
また、携帯電話コンテンツサーバ１０９が各営業員１０２の携帯電話１０３から受信するデータには、特定の建設車両に対するレンタルの仮予約データがある。携帯電話コンテンツサーバ１０９は、その仮予約データを受けると、それを基幹サーバ１０８へ送る。
レンタル会社の各支店では、支店サーバ１１１が、基幹サーバ１０８からダウンロードした最新のマスタデータを保有しており、この支店サーバ１１１に接続された何台かの端末コンピュータ１１２、１１２、…の各々には、支店業務を行うための支店業務アプリケーションが搭載されている。支店業務アプリケーションは、必要なマスタデータを支店サーバ１１１から端末コンピュータ１１２にダウンロードして、そのデータにアクセスしながら業務処理を行う。その業務処理の詳細は後に説明する。
また、支店の各端末コンピュータ１１２には、各営業員１０２、１０２、…がもつＰＤＡ１０４、１０４、…を随時に接続することができる。各ＰＤＡ１０４には、営業員１０２の出先での業務を支援するＰＤＡ業務アプリケーションが搭載されている。このＰＤＡ業務アプリケーションは、ＰＤＡ１０４が端末コンピュータ１１２に接続されたとき、端末コンピュータ１１２から例えば車両情報、債権情報、顧客情報などの所定種類のデータをダウンロードし、また、例えば休車情報、受入点検情報、受注伺い情報などの営業員１０２の活動でＰＤＡ１０４に入力されたデータを端末コンピュータ１１２にアップロードする。例えば、各営業員１０２、１０２、…は、毎日の始業時に各々のＰＤＡ１０４、１０４、…を各端末コンピュータ１１２に接続して最新の情報の端末コンピュータ１１２からダウンロードし、また、毎日の終業時に各々のＰＤＡ１０４、１０４、…を端末コンピュータ１１２に接続してその日の営業で入力したデータを端末コンピュータ１１２にアップロードする。
端末コンピュータ１１２に入力されたデータ（支店業務アプリケーションの業務処理で入力されたデータや、ＰＤＡ１０４、１０４、…からアップロードされたデータ）で、基幹サーバ１０８のマスタデータに反映されるべきデータは、随時に又は定期的に支店サーバ１１１を介して基幹サーバ１０８へアップロードされ、そのデータに基づいて基幹サーバ１０８内のマスタデータが更新される。
この会社の本部では、本部サーバ１１３に何台かの端末コンピュータ１１４が接続されている。端末コンピュータ１１４に搭載された本部用の業務アプリケーションを用いて、本部での業務処理が行われる。本部での業務処理で端末コンピュータ１１４に入力されたデータのうち、基幹サーバ１０８のマスタデータに反映されるべきデータは、随時に又は定期的に本部サーバ１１３を介して基幹サーバ１０８へアップロードされ、そのデータに基づいて基幹サーバ１０８内のマスタデータが更新される。
さらに、レンタル会社システム１００は、建設車両の特定自主検査や修理などのメンテナンスなどを行う社外のメンテナンス機関のサーバ１１５との接続されている。
以上のような構成をもつレンタルシステムによれば、レンタル会社がもつ全ての建設車両１０１、１０１、…の情報（例えば、現在位置、稼動情報、レンタル空き状況や予約状況、メンテナンス履歴など）が、レンタル会社システム１００内の基幹サーバ１０８で一元的に管理されており、その情報は常に最新のものに更新されている。そして、その情報を、どの支店の端末コンピュータ１１２からでも、どの営業員１０３のＰＤＡ１０４又は携帯電話１０３からでも参照して、それに基づいて営業活動を実施することができる。
その結果、全ての建設車両１０１、１０１、…を効率良く運用することが可能になる。何故なら、従来の営業形態に存在していた支店間の障壁が無くなるので、全ての営業員が、全ての支店に置いてある全ての建設車両についても営業を行うことができ、しかも、全ての建設車両の中から、顧客の要求に適合し且つ配車の面でも有利な状態（例えば、現在位置、稼動状態及びレンタル状況）にある車両を選択して受注することができるからである。
また、本実施形態のシステムによれば、顧客のニーズに営業員が迅速に対応することが可能になる。何故なら、上述したように、顧客の要求に適合し且つ配車の面でも有利な状態にある車両を全車両の中から選択できると共に、ＰＤＡや携帯電話を活用して何時でも何処でも各車両の現在状態をチェックすることができ、適当な車両が見つかれば携帯電話から仮予約を入れることができるからである。
また、本実施形態のシステムによれば、レンタル中の車両に対しても適切にメンテナンスを施すことが可能である。何故なら、レンタル中の車両であっても、その現在位置や稼動状態をＴＭＳデータを通じて把握できるので、ＴＭＳデータに基づいてレンタル会社側で自主的にメンテナンスの必要性やメンテナンスに必要な資材や人員を判断し、適切な人員をその稼動現場へ派遣することが可能だからである。建設機械の場合、辺鄙な山中などで稼動していることが多いため、このことの利点は大きい。
さらに、本実施形態のシステムによれば、建設車両の品質を制御して、中古車市場に出したときに一定品質を保証することが可能である。何故なら、全ての建設車両の状態（例えば、現在位置、稼動情報、レンタル空き状況や予約状況、メンテナンス履歴など）が把握できるので、その状態に基づいて、全ての車両が適切にメンテナンスが受けられるようメンテナンスのスケジュールを組んだり、中古車市場に出す時点でのアワメータ（積算稼動時間）が適当値になるようにレンタルのスケジュールを調整したりすることができるからである。
以下、レンタル会社システム１００について詳細に説明する。
図２は、レンタル会社システム１００の基幹サーバ１０８がもつデータベースの主な内容を示す。図２において、テーブル間の矢印は、テーブル間で共通するデータ項目において、矢印の元側のテーブル内のデータが先側のテーブルに反映されていることを意味する。また、テーブル間の二本線は、テーブル間でデータがリンクしていることを意味する。
図２に示すように、このデータベースには、レンタル品たる建設車両の各々の情報を記録した機番マスタテーブル１２０と、建設車両の各機種の情報を記録した機械マスタテーブル１２１と、営業員などの社員の情報を記録した担当マスタテーブル１２２と、各支店や本部の情報を記録した支店マスタテーブル１２３と、各顧客の情報を記録した顧客マスタテーブル１２４とがある。
また、このデータベースには、「伺い」（顧客からのレンタルの引き合い又は注文について、支店又は営業員が発した受入依頼）に関する基本情報を記録した伺い基本情報テーブル１２５と、伺いの明細情報を記録した伺い明細テーブル１２６と、終了した過去の伺いについての伺い明細テーブル１２６の内容を保存した明細履歴テーブル１２７とがある。
また、このデータベースには、建設車両の地点間の移動作業に関する基本情報を記録した運搬基本情報テーブル１２８と、移動作業の明細情報を記録した運搬明細テーブル１２９と、移動作業のスケジュールに関する情報を記録した運搬スケジュールテーブル１３０とがある。
また、このデータベースには、レンタルの開始時に建設車両を顧客へ渡すために車庫から出す（出庫）手続と、レンタルの終了時に建設車両を顧客から車庫へ受け入れる（入庫）手続とに関する基本情報を記録した入出庫基本情報テーブル１３２と、出庫手続の詳細情報を記録した出庫テーブル１３３と、終了した過去のレンタル契約についての出庫テーブル１３３の内容を保存した出庫履歴テーブル１３４と、入庫手続の詳細情報を記録した入庫テーブル１３６と、終了した過去のレンタル契約についての入庫テーブル１３６の内容を保存した入庫履歴テーブル１３７と、入出庫時に行われる建設車両の点検に関する情報を記録した入出庫点検テーブル１３８とがある。入出庫点検テーブル１３８には、入出庫点検時にデジタルカメラで撮影した建設車両の写真のデータを保存した写真ベース１３９がリンクされている。
また、このデータベースには、レンタル契約の明細情報を記録した契約明細テーブル１３５と、仮売上の情報を記録した仮売上テーブル１４０と、仮売上の明細情報を記録した仮売上明細テーブル１４１と、売上の情報を記録した売上テーブル１４２と、売上の明細情報を記録した売上明細テーブル１４３と、建設車両の稼動と休車に関する情報を記録した稼動・休車テーブル１４４がある。
さらに、このデータベースには、建設車両のレンタルの仮予約に関する情報を記録した仮予約テーブル１５１と、営業員が携帯電話で入れたレンタル予約に関する情報を記録した携帯予約テーブル１５２と、建設車両の修理に関する情報を記録した修理テーブル１５３と、建設車両の特定自主検査に関する情報を記録した特定自主検査テーブル１５４と、建設車両の次回のオイル交換に関する情報を記録した次回オイル交換テーブル１５５とがある。
これらのマスタデータを記録したテーブル１２０〜１５５の中から、後述する業務処理の説明に直接関連するテーブルだけをピックアップして、そこに記録されているデータの項目を以下に示す。
（１）機番マスタテーブル１２０
ここには、レンタル対象の建設車両１０１、１０１、…の各車について、固有の「管理番号」、それを保有している支店の「支店コード」と「支店名」、「機種」、固有の「機械番号」、「仕様」、「型式」、「購入年月日」、「原価」、「アワメータ」、「アワメータ更新日」、「検索キーワード」、「自主検査実施日」、「自主検査実施期限」、仮予約の有無を示す「仮予約区分」、正常か修理中かを示す「修理区分」、入庫点検が未点検か点検済みか未定かを示す「入庫点検区分」、「入庫点検日」、予約制限の有無を示す「予約制限フラグ」、及び、移動制限の有無を示す「移動制限フラグ」などが記録されている。
（２）機械マスタテーブル１２１
ここには、レンタル対象の建設車両の各機種について、その機種を表す「機械コード」と「機械名」と「機械略称」、及び、予約制限の有無を示す「予約制限フラグ」などが記録されている。
（３）伺い基本情報テーブル１２５
ここには、伺い（レンタルの引き合い又は注文の依頼）の各々について、固有の「伺い番号」、「受付日」、顧客の「顧客コード」と「顧客名」、伺いを発した支店の「支店コード」と「支店名」と営業員の「担当者コード」と「担当者名」、レンタル対象の車両を出庫する支店（出庫ポイント）を示す「出庫ポイントコード」と「出庫ポイント名」、その伺いが受注に繋がることが確実か否かを示す「伺いフラグ」、顧客の「出庫希望日」と「出庫希望時刻」、出庫希望日・時刻が不変か調整可能かを示す「出庫希望区分」、顧客の「返却予定日」、返却予定日が不変か調整可能かを示す「返却予定区分」、日極めか週極めか月極めかなどを示す「契約形態」、「契約日数」、及び、レンタル金額の予定額とその予定単価を示す「受注予定金額」と「受注予定単価」などが記録されている。
（４）伺い明細テーブル１２６
ここには、伺いの各々について、伺い基本情報テーブル１２４からコピーした「伺い番号」と「受付日」と「担当コード」と「担当者名」、レンタル対象の車両の「管理番号」と「機種」と「機番」、特殊仕様の要求があった場合のその「特殊仕様」を示す情報、「操作タイプ」や「シュー」や「ツース盤」や「ツース」などの各種仕様を示す情報、代用機種の有無を示す「代用可否」、代用機種が有る場合のその「代用機種」、及び、その伺いが未だ伺い段階であるか破棄されたか差し戻されたか予約されたか出庫済みであるかを示す「予約区分」などが記録されている。
（５）運搬基本情報テーブル１２８
ここには、各建設車両の支店間の運搬について、固有の「運搬指示番号」、運搬を指示した支店とその担当者を示す「指示支店コード」と「指示支店名」と「指示担当者コード」と「指示担当者名」、及び、その運搬が特定の伺いに対応する場合には、その伺いの「伺い番号」と、その伺いを発した支店と担当者を示す「依頼元支店コード」と「依頼元支店名」と「依頼元担当者コード」と「依頼元担当者名」と、その伺いの「顧客コード」と「顧客名」などが記録されている。
（６）運搬明細テーブル１２９
ここには、各建設車両の支店間の運搬の依頼について、運搬基本情報テーブル１２８からコピーした「運搬指示番号」、入出庫基本情報テーブル１３２からコピーした「入出庫番号」、運搬済みか未運搬かを示す「運搬確認フラグ」、対応する伺いがある場合には伺い明細テーブル１２５からコピーした対応する伺いの「伺い番号」と「管理番号」と「機種」と「機番」、運搬する建設車両の「前の在庫ポイントコード」と「前の在庫ポイント名」、出発した支店を示す「出発ポイントコード」、到着する支店を示すの「到着ポイントコード」、「出発場所」、「出発時刻」、「到着場所」、「到着時刻」、「運搬予定時間」、「運送業社名」、「運転手」、「運搬日付」、システムの運搬スケジューリングに移行したか否かを示す「スケジュール移行フラグ」などが記録されている。
（７）運搬スケジュールテーブル１３０
ここには、各建設車両の支店間の運搬について、運搬基本情報テーブル１２８からコピーした「運搬指示番号」、入出庫基本情報テーブル１３２からコピーした「入出庫番号」、運搬済みか未運搬かを示す「運搬確認フラグ」、対応する伺いがある場合には伺い明細テーブル１２５からコピーした対応する伺いの「伺い番号」と「管理番号」と「機種」と「機番」、運搬する建設車両の「前の在庫ポイントコード」と「前の在庫ポイント名」、出発した支店を示す「出発ポイントコード」、到着する支店を示すの「到着ポイントコード」、「出発場所」、「出発時刻」、「到着場所」、「到着時刻」、「運搬予定時間」、「運送業社名」、「運転手」、「運搬日付」、システムの運搬スケジューリングに移行したか否かを示す「スケジュール移行フラグ」などが記録されている。
（８）入出庫基本情報テーブル１３２
ここには、各伺いから生じたレンタル契約における各建設車両の入出庫について、伺い基本情報テーブル１２４から伺い番号をコピーした「入出庫番号」、伺い基本情報テーブル１２４内の対応項目をコピーしたものである「顧客コード」と「顧客名」と「支店コード」と「支店名」と「担当者コード」と「担当者コード」と「契約形態」と「契約日数」と「受注予定金額」と「受注予定単価」、及び、伺い基本情報テーブルからコピーした「出庫予定日」と「返却予定日」などが記録されている。
（９）出庫テーブル１３３
ここには、各建設車両の出庫について、入出庫基本情報テーブル１３２からコピーした「入出庫番号」、出庫する建設車両やアタッチメントの「管理番号」、出庫を入力した日付を示す「受付日」、出庫する支店を示す「出庫ポイントコード」と「出庫ポイント名」、出庫伝票を印刷する支店とその担当者を示す「出庫支店コード」と「出庫支店名」と「出庫担当者コード」と「出庫担当者名」、出庫する建設車両の「機種」と「機番」、出庫の日付を示す「出庫日」、入出庫基本情報テーブル１３２からコピーした「返却予定日」、レンタル先の現場を示す「現場名」、出庫時のアワメータ値を示す「出庫時アワメータ」、出庫時の「操作タイプ」や「シュー」や「ツース盤」や「ツース」などの各種仕様を示す情報、及び、入庫予定日が未定か確定かを示す「入庫予定日区分」などが記録されている。
（１０）入庫テーブル１３６
ここには、各建設車両の入庫について、入出庫基本情報テーブル１３２からコピーした「入出庫番号」、入庫する建設車両やアタッチメントの「管理番号」、入庫を入力した日付を示す「受付日」、入庫する支店を示す「入庫ポイントコード」と「入庫ポイント名」、入庫伝票を印刷する支店とその担当者を示す「入庫支店コード」と「入庫支店名」と「入庫担当者コード」と「入庫担当者名」、入庫する建設車両の「機種」と「機番」、入庫の日付を示す「入庫日」、並びに、出庫テーブル１３３からコピーした「出庫時アワメータ」及び「操作タイプ」や「シュー」や「ツース盤」や「ツース」などの各種仕様の情報などが記録されている。
（１１）入出庫点検テーブル１３８
ここには、各建設車両の出庫時点検と入庫時点検の各々について、入出庫基本情報テーブル１３２からコピーした「入出庫番号」、出庫時点検か入庫時点検かを示す「入出庫区分」、各種の点検項目の「項目ＩＤ」、各種点検項目について点検結果が良か不良かを示す「結果」、各種点検項目について部品を交換したか修理したか清掃したか給油水したか異常なしかなどを示す「処置」、点検時に撮影した建設車両の写真データを指し示す「写真ポインタ」などが記録されている。
（１２）写真ベース１３９
ここには、出庫時点検と入庫時点検でそれぞれ撮影された写真データが記録されている。各写真データは、入出庫点検テーブル１３８内の対応する点検データに、上述した「写真ポインタ」によってリンクされている。
（１３）仮予約テーブル１５１
ここには、各レンタルの仮予約について、仮予約された車両の「管理番号」、仮予約の受付日を示す「受付日」、仮予約した顧客の「顧客コード」と「顧客目」、仮予約を扱った支店と営業員の「支店コード」と「支店名」と「担当者コード」と「担当者名」などが記録されている。
（１４）携帯予約テーブル１５２
ここには、携帯電話から入れられた各予約について、予約された車両の「管理番号」、予約の受付日を示す「受付日」、予約を入れた営業員の「担当者コード」などが記録されている。
（１５）修理テーブル１５３
ここには、建設車両に対する各修理について、その建設車両の「管理番号」、その修理の「修理報告番号」と「修理着手日」と「完成予定日」と「見積状況」と「保険手続区分」と「状況詳細」と「写真区分」と「依頼支店」と「依頼先担当者」、修理の原因となった顧客の「顧客コード」と「顧客名」などが記録されている。
（１６）特定自主検査テーブル１５４
ここには、各建設車両に対する各特定自主検査について、その建設車両の「管理番号」、「記録簿入力日」、「前回実施日」、「特定自主検査実施時のアワメータ」、「特定自主検査実施支店コード」、「エンジン型式」、「エンジン番号」、「証券番号」、「証券支店コード」、「証券日」、「記録簿イメージデータ」などが記録されている。
（１７）次回オイル交換テーブル１５５
ここには、各建設車両に対する次回のオイル交換について、その建設車両の「管理番号」と「機械コード」と「機種」と「機番」と「前回交換時のアワメータ」と「前回交換日」と「次回交換予定のアワメータ」と「現在のアワメータ」と「現在のアワメータ更新日」と「保有支店コード」と「保有支店名」と「担当者コード」と「担当者名」などが記録されている。
以下、上述したデータベースを用いてレンタル会社システム１００で行われる業務処理の流れを説明する。
図３は、このシステムで行われる業務処理のうち、建設車両の在庫照会から移動依頼までの業務処理の全体的流れを示す。図４は、図３の流れの後に続く、建設車両の運搬スケジューリングから入庫までの業務処理の全体的流れを示す。図５は、建設車両のメンテナンスに関する業務処理の全体的流れを示す。
図３に示すように、本部では随時に、予約／移動規制の処理（ステップＳ１）を行うことができる。この処理Ｓ１では、任意の建設車両を指定して、その建設車両に予約規制又は移動規制をかけたり、或いは、既に予約規制又は移動規制がかかっている任意の建設車両に対してその規制を解除したりすることができる。ここで、「予約規制」とは、営業員の携帯電話などからの依頼に応じてその車両に自動的に予約を入れることを禁止する（つまり、支店のオペレータが予約の可否を判断してマニュアルで予約をいれない限り予約できない）措置である。また、「移動規制」とは、その車両の支店間の移動（ポイント間移動）の決定を自動的に出来ないようにする措置である。これら予約規制と移動規制とを総称するときは「自動振り当て規制」という。
「自動振り当て規制」とは要するに、或るレンタル注文に対してその車両をシステムが自動的に振り当てることを規制する（つまり、支店のオペレータが振り当て可否を判断してマニュアルで振り当てをしない限り振り当てできない）措置である。この「自動振り当て規制」を個々の車両に課すことができることによって、各車両の稼動時間やメンテナンスのスケジュールを意図的にコントロールすることができるようになり、もって、所定の時期に各車両を中古車市場に出したとき、その車両のアワメータや各種の品質を一定の水準で保証することができるようになる。
図３に示すように、各支店では、顧客から引き合いがあったときなどの随時に、在庫紹介の処理（Ｓ２）を行うことができる。この処理Ｓ２では、任意の機種の車両について、在庫中か予約中か修理中かなどの空き状態、出庫ポイント、仕様、自動振り当て規制がかかっているか否かなどの各種状態を確認することができる。
また、外出している営業員は、外出先で顧客から引き合いがあったときなどの随時に、携帯電話によるリアルタイム検索及び仮予約の処理（Ｓ５）を行うことができる。この処理Ｓ５では、携帯電話からレンタル会社システムの携帯電話コンテンツサーバに接続することにより、任意の機種の現在の在庫車両（自動振り当て規制がかかっていない車両のみ）を検索して確認したり、その結果に基づいて、特定の車両に対して仮予約を発したりすることができる。
支店では、顧客から引き合いや注文があったときなどに、伺い書作成の処理（Ｓ３、Ｓ６）を行うことができる。前述した在庫照会（Ｓ２）を行った結果、自動振り当て規制のかかっている車両については、通常は確認した上で、自動振り当て規制機種用の伺い書作成処理（Ｓ３）を行う。前述した在庫照会（Ｓ２）を行った結果、自動振り当て規制のかかっていない車両については、自動振り当て規制なし機種用の伺い書作成処理（Ｓ６）を行う。また、前述した携帯電話によるリアルタイム検索及び仮予約処理（Ｓ５）で仮予約が入った車両（自動振り当て規制なし）についても、自動振り当て規制なし機種用の伺い書作成処理（Ｓ６）を行う。
支店では、自動振り当て規制機種用の伺い書作成処理（Ｓ３）を行った車両に対して、次に、振り当て処理（Ｓ４）を行う。この振り当て処理（Ｓ４）によって、その自動振り当て規制のかかった車両に対する予約が確定する。一方、自動振り当て規制のかかっていない車両については、自動振り当て規制なし機種用の伺い書作成処理（Ｓ６）を行った段階で予約が確定する。
支店及び本部では、予約の確定した車両について、ポイント間移動依頼の処理（Ｓ７）を行う。この処理Ｓ７では、各車両のポイント間移動（現在の車庫から顧客に渡すまでの運搬）に関し、運搬手段や運搬日のレンジなどの大枠の内容を決める。
次に、図４に示すように、本部にて、ポイント間移動依頼処理（Ｓ７）の終わった車両について、運搬スケジューリングの処理（Ｓ８）を行う。この処理Ｓ８では、各車両の部隊的な運搬スケジュールを決定する。
支店では、決まった運転スケジュールに従って、車両の実際の出庫と出庫時点検とポイント間移動とを実施し（Ｓ９）、それに伴って、出庫処理（Ｓ１０）、出庫時の画像データ及び点検情報の入力処理（Ｓ１１）を行う。
支店では、また、レンタルが終わって顧客から帰ってきた車両について、入庫時点検を行うと共に、入庫時の画像データ及び点検情報の入力処理（Ｓ１２）と入庫処理（Ｓ１３）を行う。
また、図５に示すように、レンタル会社の支店又は本部と、社外のメンテナンス機関では、定期的又は随時に、建設車両の特定自主検査管理の処理（Ｓ１４）を行う。この処理Ｓ１４では、特定自主検査を行う対象の建設車両を特定し、その車両に対して実施した特定自主検査の結果を入力して特定自主検査管理記録簿を作る。その後、支店では、特定自主検査管理記録簿の出力処理（Ｓ１５）を行い、出力（プリントアウト）した特定自主検査管理記録簿を保管する。
また、社外のメンテナンス機関では、定期的又は随時に、各車両の整備履歴照会処理（Ｓ１６）、オイル管理処理（Ｓ１７）及び修理状況紹介（Ｓ１８）などを行って、各車両の整備やオイル交換や修理が適正に行われるよう管理する。
以下、図３〜図５に示した各処理の具体的な流れを、図７以下のフローチャートとユーザインタフェース画面の絵を用いて説明する。
なお、図６は、図７以下のフローチャートのための凡例である。ここに示すように、図７以下のフローチャートにおいて、実線矢印は処理ステップの進む方向を意味し、角が尖ったブロックはシステムによる処理ステップを意味し、角の丸いブロックは人による処理を意味し、テーブル「Ａ」に向う破線の片矢印はテーブル「Ａ」に新規レコードを生成することを意味し、テーブル「Ａ」に向う破線の両矢印はテーブル「Ａ」の特定のレコードを更新することを意味し、テーブル「Ａ」から出る破線の片矢印はテーブル「Ａ」のレコードの読み込み／照会を意味している。
図７は、図３のステップＳ１の「予約／移動規制」の処理の流れを示す。図８〜図１４は、この処理で用いるユーザインタフェース画面を示す。
本部の端末コンピュータに表示された図８に示すメニュー画面において、オペレータが「マスタ管理」及び「機械機番」を順次マウスでクリックすると、システムは図９に示す機番検索画面を表示する。そして、図７のステップＳ１０１にて、オペレータは図９の機番検索画面に規制をかけたい車両の管理番号（例えば、「ＰＳ０６００」）を入力して「検索」をクリックすると、図７のステップＳ１０２にて、システムが、入力された管理番号と同一の管理番号をもつ車両のレコードを機番マスタテーブル１２０（図２参照）から検索して、そのレコード内容を図１０に示すように機番検索画面に表示する。次に、図７のステップＳ１０３で、オペレータが図１０の画面に表示されたレコードを選択して「修正」をクリックすると、図７のステップＳ１０４で、システムが、選択されたレコードの車両についての更に詳細な情報を機番マスタテーブル１２０から読み出して、図１１に示すようにその詳細情報を機械機番画面に表示する。
次に、図７のステップＳ１０５で、オペレータが、図１１の画面の右下端にある「予約制限」又は「移動制限」の選択ボックス２０１、２０２を操作することで、その車両に予約制限または移動制限をかける（又は制限を解除する）ことを選択して「ＯＫ」をクリックする。すると、図７のステップＳ１０６で、システムが、機番マスタテーブル１２０上のその車両の予約制限フラグ又は移動制限フラグを更新する。
上記手順は、管理番号を指定して車両毎に予約規制又は移動規制をかけるものであるが、機種毎に予約規制をかけることもできる。
その場合には、オペレータは、図８のメニュー画面で「機械マスタ（予約制限）」をクリックする。すると、システムは図１２に示すような機械検索画面を表示するので、オペレータはその画面に機種コード（例えば、「ＰＣ２００｝）を入力して「検索」をクリックする。すると、システムが、入力された機種に該当する機種のレコードを機械マスタテーブル１２１（図２参照）から検索して図１３に示すように機械検索画面に表示するので、オペレータはその中から規制をかけたい機種を選択して「修正」をクリックする。すると、システムが、図１４に示すように選択した機種のレコード内容を機械マスタ画面に表示するので、オペレータが、この画面中の「予約制限」の選択ボックス２０３を操作して予約制限をかけて（又は制限を解除して）、「ＯＫ」をクリックすれば、システムが、機械マスタテーブル１２１上でその機種の予約制限フラグを更新し、併せて、機番デーブル１２０上でその機種に該当する各車両の予約制限フラグも更新する。
図１５は、図３のステップＳ２の「在庫照会」の処理の流れを示す。図１６及び図１７は、この処理で用いるユーザインタフェース画面を示す。
支店の端末コンピュータに表示された図１６に示すようなメニュー画面で、オペレータが「受注／伺い　出庫　入庫」及び「機械状況照会」を順にクリックすると、システムが図１７に示すような機械状況照会画面（どのエントリフィールドもブランクになっているもの）を表示する。そして、図１５のステップＳ１１０で、オペレータが図１７の機械状況照会画面に検索キーとして照会したい機種の機械コード（例えば、「ＰＣ２００」）又は照会したい車両の管理番号などを入力すると、ステップＳ１１で、システムが、入力された検索キーに該当する全ての車両のレコードを機番マスタテーブル１２０から抽出して、そのレコード内容を図１７に示すように機械状況照会画面に表示する。表示された各車両のレコード内容には、空き状態（在庫中か、予約済みか、仮予約中か、修理中か、出庫中か）や、自動振り当て制限の有無（図１７の例では、「空き」の表示マークの色で示す）や、管理番号や、仕様や、出庫ポイントなどが含まれているので、ステップ１１２でオペレータは、この画面上で予約を所望する車両について、空き状態や自動振り当て制限の有無などを確認する。その結果、所望車両が「在庫中」でなければ（ステップＳ１１３で「なし」）、どのように対応するかを検討する。また、所望車両が「在庫中」であれば（ステップＳ１１３で「あり」）、その所望車両に自動振り当て規制がかかっていれば（ステップＳ１１４で「あり」）、図３のステップＳ３の「伺い書作成（自動振り当て規制の場合）『仮予約』」の処理に進み、その所望車両に自動振り当て規制がかかってなければ（ステップＳ１１４で「なし」）、図３のステップＳ６の「伺い書作成（自動振り当て規制なしの場合）『予約』」の処理に進む。
図１８は、図３のステップＳ３の「伺い書作成（自動振り当て規制の場合）『仮予約』」の処理の流れを示す。図１９と図２０は、この処理で用いるユーザインタフェース画面を示す。
支店の端末コンピュータに表示された図１６に示すようなメニュー画面で、オペレータが「受注／伺い　出庫　入庫」及び「伺い入力」を順にクリックすると、システムが図１９に示すような受注・伺い画面（どのエントリフィールドもブランクになっているもの）を表示する。続いて、図１８のステップＳ１３０でオペレータが、図１９の受注・伺い画面に、伺い書の基礎情報（例えば、依頼元、出庫値、担当コード、顧客コード、出庫予定・予定返却日など）を入力する。
続いて、図１８のステップＳ１３１でオペレータが、この受注・伺い画面の「対象」の欄の「予約／移動制限ありの場合」の欄に、所望の機種を特定する情報（例えば、機械コード（機械ＣＤ）、仕様（操作パターン、履帯の種類など）、他機種が代用可能か否か、代用可能機種名など）を入力する。また、図１８のステップＳ１３２でオペレータが、この受注・伺い画面の「アタッチメント」をクリックすることで図２０に示すような「アタッチメント」ボックスを開き、そこに所望のアタッチメントを特定する情報（例えば、そのアタッチメントの管理番号など）を入力する。
さらに、図１８のステップＳ１３３〜１３４でオペレータが、この受注・伺い画面に、契約条件（例えば、契約形態（日／月極めなど）、契約金額、契約日数／月数など）、及びその他の項目（例えば、出庫希望日が調整可能か否か、競合条件など）を入力する。最後に、オペレータが「ＯＫ」をクリックすると、図１８のステップＳ１３５でシステムが、この伺い書に伺い番号を割り当て、上記入力内容の伺い書レコードを作成して、伺い基本情報テーブル１２５及び伺い明細テーブル１２６に登録する。
上述の「伺い書作成（自動振り当て規制の場合）『仮予約』」の処理では、所望の車両に自動振り当て規制がかかっているため、その車両と同じ機種に対して「仮予約」をしただけであり、特定の車両に対して「予約」をしたことにはなっていない、その後に、図３に示すステップＳ４の「振り当て処理（自動振り当て規制の場合）『予約』」を行って初めて、その機種の特定の車両に対して「予約」をすることができる。
図２１と図２２は、この図３のステップＳ４の「割り当て処理（自動振り当て規制の場合）『予約』」の流れを示す。図２３から図２５は、この処理で用いるユーザインタフェース画面を示す。
まず、図２１のステップ１４０で、支店のオペレータは支店の端末コンピュータに、図２３に示すような新着情報画面を開く。この新着情報画面には、伺い基本情報テーブル１２５及び伺い明細テーブル１２６より、上述した「伺い書作成（自動振り当て規制の場合）『仮予約』」の処理で新規入力された伺い書のレコードが、「伺い」表に表示される。
なお、この新着情報画面には、そのほかに、「携帯仮予約」表に、図３のステップＳ５の「携帯電話によるリアルタイム検索及び仮予約」の処理（その手順は後述する）で入力された携帯電話からの仮予約のレコードが表示され、「予約」表には、図３のステップＳ６の「伺い書作成（自動振り当て規制なしの場合）」の処理（その手順は後述する）又は今ここで説明している「割り当て処理（自動振り当て規制の場合）『予約』」の処理で入力された予約のレコードが表示される。
さて、支店のオペレータは、図２３の新着情報画面中の「伺い」の表を見て、この表に記載された伺い書情報（例えば、伺い書番号、機械コード、出庫希望日、返却予定日、価格など）を確認し、振り当て処理を行うべき伺い書の伺い書番号や機械コードなどをメモ用紙などに控える。次に、図２１のステップＳ１４１で、オペレータは、図２４に示すメニュー画面をコンピュータ端末に表示して「振当て　運搬　運搬計画」及び「予約　仮予約」を順にクリックすることで、図２５に示すような「機械の振当て処理」画面を開く（まだ、エントリフィールドはブランクになっている）。そして、オペレータは、この「機械の振当て処理」画面に、メモしてある機械コード（機械ＣＤ）などを検索条件として入力する。
すると、図２１のステップＳ１４２〜Ｓ１４４で、システムが、入力された検索条件に合致する全車両の中から、振り当てが可能な車両だけを抽出して、その車両のレコードを、図２５に示すように「機械の振当て処理」画面に表示する。ここで、振り当てが可能な車両を抽出する処理は、例えば次のような手順で行う。まず、図２１のステップＳ１４２において、機番マスタテーブル１２０を参照して、入力された検索条件（例えば、入力された機械コードの機種）に合致する車両を抽出し、その中の出庫中の車両の各々について、最新ＴＭＳ情報（稼動情報や現在の位置情報）に基づいて、特定期日（例えば、出庫希望日の２日前）までの「返却可能性」を計算する（例えば、返却予定日が過ぎており、且つ、最近数日間全く稼動していない車両は、「返却可能性」が高いと判断する）。さらに、ステップＳ１４３において、上記出庫中の車両の各々について、営業員から入力された「返却確度情報」（いつまでにどれくらいの確度で返却されそうか）を抽出する。そして、ステップＳ１４４で、上記検索条件に合致する車両の中で、在庫中の車両と、出庫中ではあるが上記「返却可能性」が大又は上記「返却確度情報」が大である車両とを、振当て可能な車両として抽出し、それらの車両の情報を機番マスタテーブル１２０、伺い基本情報テーブル１２５、仮予約テーブル１５１、出庫テーブル１３３、入庫テーブル１３６などから読み込んで、図２５の「機械の振当て処理」画面に表示する。
振当て可能な車両の情報が図２５の「機械の振当て処理」画面に表示されると、次に、図２２のステップＳ１４５及びＳ１４６で、オペレータはそれらの車両の中から振り当てるべき車両を選択し、画面中のその選択した車両の「伺いＮｏ．入力」フィールドに、先ほどメモした伺い書番号をエントリして、「予約」をクリックする。すると、ステップＳ１４７で、システムが、伺い基本情報テーブル１２５の当該伺い書番号のレコードに、その車両の管理番号の情報を付加する。これにより、その車両に対して「予約」なされたことになる。
次に、ステップＳ１４８で、システムは、その予約された車両についてポイント間移動が必要か否かを判断する。その車両の在庫地とその伺いの出庫ポイントが同一地であれば、ポイント間移動は不用と判断し、違っていればポイント間移動が必要と判断する。ポイント間移動が不用と判断した場合には、システムは当面何もせず、支店側の担当者が出庫日に合わせて外部運搬業者を手配したりする。ポイント間移動が必要と判断した場合には、ステップＳ１４９で、システムは、運搬依頼情報を生成して運搬基本テーブル１２８や運搬明細テーブル１２９に登録するとともに、担当の営業員に電子メールで運搬依頼情報を通知する。
図２６は、図３のステップＳ５の「携帯電話によるリアルタイム検索及び仮予約」の処理の流れを示す。図２７は、営業員の携帯電話に表示される携帯電話コンテンツの画面の種類とその遷移を示す。なお、図２７で、白丸印が左に付いている事項は、画面への入力項目である。
図２６に示す「携帯電話によるリアルタイム検索及び仮予約」の処理は、前述したように、外出先で営業員が携帯電話を用いて、車両の空き状況を参照したり車両の仮予約を行ったりするための処理である。
この処理に入るために、営業員はまず、携帯電話に図２７に示すメニュー画面３００を表示させ、そのメニュー画面３００中の「［１］空き状況＆予約」を選択することで、「車両状況照会」画面３０２を表示させる。そして、図２６のステップＳ１５０で、営業員は、検索条件として機械コード（つまり、機種）などを「車両状況照会」画面３０２に入力する。すると、図２６のステップＳ１５１で、システムが、機番マスタテーブル１２０、伺い基本情報テーブル１２５、仮予約テーブル１５１、出庫テーブル１３３及び入庫テーブル１３６などを参照して、入力された検索条件に合致し、且つ、在庫中であって自動振り当て規制がかかっていない車両を抽出し、それらの車両の台数（保有機数）を支店毎に集計して、その集計結果を図２７の「店舗別車両状況表示」画面３０４として作成して、これを携帯電話に送り表示させる。
次に、図２６のステップＳ１５２で、営業員が、「店舗別車両状況表示」画面３０４上で出庫する支店を選択する。すると、図２６のステップＳ１５３で、システムが、機番マスタテーブル１２０、伺い基本情報テーブル１２５、仮予約テーブル１５１、出庫テーブル１３３及び入庫テーブル１３６などを参照して、選択された支店に保有されていて、且つ、在庫中で自動振り当て規制のかかっていない車両を抽出し、それら車両の管理番号のリストを図２７の「店舗別車両詳細情報表示」画面３０５として作成して、これを携帯電話に送り表示させる。
次に、図２６のステップＳ１５４で、営業員が、「店舗別車両状況表示」画面３０５上で仮要約したい車両の管理番号を選択する。すると、次に、その選択した管理番号の車両について図２７の「管理番号別車両詳細情報表示」画面３０６が出るので、営業員はその画面３０６に、担当者コードや出庫予定地などを入れて入力を完了する。すると、図２７の「仮予約確認」画面３０７が出るので、営業員はその画面３０７上で「ＯＫ」を選択する。すると、システムが、入力された事項を基に、携帯予約レコード及び仮予約レコードを作成して携帯予約テーブル１５２及び仮予約テーブル１５１にそれぞれ登録する。
このようにして、携帯電話によってなされた仮予約の内容（例えば、車両の管理番号、機種，機番、在庫地、担当者など）、既に説明した図２３の「新着情報」画面を開くことで、その「携帯仮予約」表に表示される。支店では、この「携帯仮予約」表をオペレータが見て、そこにリストされた各仮予約について、図３のステップＳ６の「伺い書作成（自動振り当て規制なしの場合）『予約』」の処理を行う。
この「伺い書作成（自動振り当て規制なしの場合）『予約』」の処理は、基本的には、図１８〜図２０を参照して説明した「伺い書作成（自動振り当て規制ありの場合）『仮予約』」とほぼ同じである。異なる点は、この「伺い書作成（自動振り当て規制なしの場合）『予約』」の処理で、特定の車両に対する「予約」が確定する点である。すなわち、この処理では、オペレータは、図２８に示すように「受注・伺」画面上で、「対象」欄の「制限なしの場合」欄に仮予約した車両の管理番号を入力し、そして、その他の必要事項も入力した上で「ＯＫ」をクリックする。すると、すれば、既に図２１〜図２２を参照して説明した「振り当て処理（自動振り当て規制機種の場合）」のステップＳ１４７以降と同様に、システムによってその管理番号の車両が自動的に振り当てられ、伺い書の内容が伺い基本情報テーブル１２５や伺い明細テーブル１２６に登録され、さらに、その車両のポイント間移動が必要か否か判断され、必要な場合には運搬依頼情報が生成されて運搬基本情報テーブル１２８や運搬明細テーブル１２９に登録され、且つ、担当者に電子メールで通知される。
以上のようにして、特定の車両に対してレンタルの「予約」が確定すると、次に、既に説明したとおり、図３のステップＳ７の「ポイント移動依頼」の処理が行われる。
図２９は、この「ポイント移動依頼」の処理の流れを示す。図３０と図３１は、この処理で用いるユーザインタフェース画面を示す。
まず、支店の端末コンピュータ上で、図２４に示したメニュー画面の「振当て　運搬　運搬計画」及び「運搬一覧と在庫地管理」を順にクリックして、更に図示しない「レンタル運搬」をクリックすると、図３０に示した「レンタル運搬」画面が表示される。まず、図２のステップＳ１６０で、オペレータは、対象の車両の管理番号を「レンタル運搬」画面に入力する。すると、ステップＳ１６１で、システムが、入力された管理番号の運転指示情報の内容（例えば、依頼元、担当など）を運搬基本情報テーブル１２８及び運搬明細テーブル１２９から読み出して、図３０に示すように「レンタル運搬」画面に表示する。次に、図２９のステップＳ１６２で、オペレータが、ポイント間移動の運送手段（例えば、顧客が取りに来る、自社便、業者便など）を「レンタル運搬」画面に入力して、「ＯＫ」をクリックする。すると、ステップＳ１６３で、システムが、運搬基本情報テーブル１２８及び運搬明細テーブル１２９内の該当する管理番号の運搬依頼情報レコードに、入力された運送手段の情報を付加する。
次に、本部において、図２４に示したメニュー画面の「振当て　運搬　運搬計画」及び「運搬一覧と在庫地管理」を順にクリックすると、図３１に示した「運搬一覧と在庫地管理」画面が表示される。まず、図２９のステップＳ１６４で、オペレータが、ポイント間移動が必要な運搬日のレンジを「運搬一覧と在庫地管理」画面に入力する。すると、ステップＳ１６５で、システムが、入力されたレンジに入る運搬日をもつ全ての運搬依頼情報の内容を、運搬基本情報テーブル１２８及び運搬明細テーブル１２９から読み出して、図３１に示すように「運搬一覧と在庫地管理」画面に表示する。
次に、ステップＳ１６６で、オペレータが、「運搬一覧と在庫地管理」画面に表示された運搬依頼情報の中から、スケジューリングすべき運搬依頼情報を選択し、その選択した運搬依頼情報の画面中の「スケジュール」のフラグを立て、「スケジュールへ追加」をクリックする。すると、ステップＳ１６７で、システムが、その「スケジュール」フラグを立てた運搬依頼情報について、運搬スケジュールレコードを作成して運搬スケジュールテーブル１３０に登録する。これにより、その運搬依頼情報についてシステム上でスケジューリングが可能となる。
図３２は、図４のステップＳ８の「運搬スケジューリング（ポイント間移動時）」の処理の流れを示す。図３３と図３４は、この処理で用いるユーザインタフェース画面を示す。
この処理は、図４に示したように本部で行う。まず、図３２のステップＳ１７０で、本部のオペレータが端末コンピュータで、図２４に示したメニュー画面の「振当て　運搬　運搬計画」及び「運搬スケジュール」を順にクリックすることで、図３３に示すような「運搬スケジュール」画面を表示して（エントリフィールドがブランクになもの）、その「運搬スケジュール」画面に、運搬日のレンジを入力する。すると、ステップＳ１７１で、システムが、入力されたレンジに当てはまる運搬スケジュールレコードを運搬スケジュールテーブル１３０から抽出し、図３３に示すように表示する。
次に、ステップＳ１７２で、オペレータが、「運搬スケジュール」画面で各運搬スケジュールの出発場所（出庫地）、到着場所、到着日時などを確認し、更にステップＳ１７３で、日時別及び運転手別の運搬スケジュールを確認し、特定日時の運転手の空き具合を判断する。次に、ステップＳ１７４で、オペレータは、特定の運搬スケジュールを「運搬スケジュール」画面から選択して、「編集」をクリックする。すると、ステップＳ１７５で、システムが、その選択された運搬スケジュールの諸情報（例えば、出庫場所、お届け先など）を運搬スケジュールテーブル１３０から読み出し、図３４に示すように「運搬の振当処理」画面に表示する。
次に、ステップＳ１７６で、オペレータが、「運搬の振当処理」画面で、その運搬スケジュールについて「運転手名称」等を入力し、「ＯＫ」をクリックする。すると、ステップＳ１７７で、システムが、運搬スケジュールテーブル１３０のその運転スケジュールレコードに、入力された「運転手名称」等を追加する。
図３５と図３６は、図４のステップＳ１０の「出庫（ポイント間移動時）」の処理の流れを示す。図３７から図４４は、この処理で用いるユーザインタフェース画面を示す。
図３５のステップＳ１８０で、支店のオペレータは、端末コンピュータの図１６に示したメニュー画面で「受注／伺い　出庫　入庫」及び「出庫入力」を順にクリックして、図３７に示す出庫入力画面を表示させ、その画面の「予約車両から追加」をクリックして、図３８に示す「予約車両」画面を表示させ（エントリフィールドがブランクなもの）、この「予約車両」画面に検索条件として出庫ポイントコード（出庫ポイントＣＤ）を入力する。すると、ステップＳ１８１で、システムが、入力された検索条件に合致する予約（伺い）のレコードを伺い基本情報テーブル１２５及び伺い明細テーブル１２６から抽出して、図３８に示すように表示する。
次に、ステップＳ１８２で、オペレータが、出庫を希望する予約を「予約車両」画面上で選択し、「ＯＫ］をクリックする。すると、ステップＳ１８２で、システムが、その選択された予約の詳細な情報を伺い基本情報テーブル１２５及び伺い明細テーブル１２６から読み出して、図３９〜図４３に示すように「出庫内容」画面に表示する。
次に、ステップＳ１８４で、オペレータが、図３９〜図４３の「出庫内容」画面で、その予約の詳細情報を確認し、必要に応じその詳細情報に新情報を入力して更新する。すると、システムが、ステップＳ１８５で、入力された情報を、伺い基本情報テーブル１２５及び伺い明細テーブル１２６内のその予約のレコードに追加し、そしてステップＳ１８６で、伺い基本情報テーブル１２５及び伺い明細テーブル１２６内のその予約のレコードを基に出庫レコードを作成して、その出庫レコードを入出庫基本情報テーブル１３２及び出庫テーブル１３３に登録する。続いて図３６のステップＳ１８７へ進み、システムが、仮売上データを作成して、仮売上テーブル１４０に登録する。
次に、ステップＳ１８８で、オペレータが、図３９〜図４３の「出庫内容」画面の「戻る」をクリックして図３８の「予約車両」画面に戻り、更に「予約車両」画面の「戻る」をクリックして「出庫入力」画面に戻ると、図４４に示すように「出庫入力」画面には、上記出庫レコードの内容が表示されているので、これを確認し、「伝票印刷」をクリックする。すると、ステップＳ１８９〜Ｓ１９０で、システムが、その出庫レコードに基づく出庫伝票を印刷する。
図４５は、図４のステップＳ１１及びＳ１２の出庫時及び入庫時の「画像データ及び点検情報の入力」の処理の流れを示す。図４６〜図５０は、この処理で用いるＰＤＡのユーザインタフェース画面を示す。
まず、支店の点検者が、デジタルカメラ付きのＰＤＡを点検対象の車両の場所で持っていき、図４５のステップＳ２００で、そのＰＤＡの業務アプリケーションを起動して図４６に示すようなメニュー画面を開き、メニュー画面の「受入点検」を選択して図４７に示すような「受入点検入力」画面を開き、「受入点検入力」画面に点検対象車両の管理番号（又は機種と機番）を入力して「受入点検入力」画面を図４８に示すような内容に切り換え、この図４８の「受入点検入力」画面で「点検項目入力」を選択する。
すると、ステップＳ２０１で、ＰＤＡが図４９に示すような「点検項目入力」画面を表示するので、ステップＳ２０２で、点検者は、各点検項目ごとに車両を点検してその評価結果を「点検項目入力」画面にマルかバツかで入力して、「確認」を選択する。すると、ステップ２０３で、ＰＤＡが、入力された点検結果の評価情報をＰＤＡの一時ファイルに保存する。
次に、ステップＳ２０４で、点検者は、ＰＤＡの画面を図４８の「受入点検入力」画面に戻して「写真」を選択することで、図５０に示すような写真画面を開き、そして、ＰＤＡに付属のデジタルカメラを用いて、点検対象車両の要所要所の写真を撮影する。すると、ＰＤＡが、ステップＳ２０５で、撮影されたデジタル写真を図５０に示すように写真画面に表示するとともに、ＰＤＡ内の一時ファイルに保存する。
ＰＤＡへの点検入力が終わると、ステップＳ２０６で、点検者はＰＤＡを支店の端末コンピュータに接続し、ＰＤＡの画面を図４８の「受入点検入力」画面にして「登録」を選択することで、ＰＤＡの一時ファイルに保存してあった点検結果の評価情報や写真データを支店の端末コンピュータに転送する。すると、ステップＳ２０７で、システムが、その点検結果の評価情報を基に点検情報レコードを作成して、その点検情報レコードを入出庫点検情報テーブル１３８に登録し、且つ、その点検情報レコードにリンクさせた形で、その写真データを写真ベース１３９に登録する。
図５１は、図４のステップＳ１３の「入庫」の処理の流れを示す。図５２〜図５７は、この処理で用いるユーザインタフェース画面を示す。
図５１のステップＳ２１０で、支店のオペレータは、端末コンピュータの図１６に示したメニュー画面で「受注／伺い　出庫　入庫」及び「入庫入力」を順にクリックして、図５２に示す「入庫入力」画面を表示させ、その画面に検索条件として入庫する車両の「管理番号」を入力する。すると、ステップＳ２１１で、システムが、入力された検索条件に合致する出庫レコードを入出庫基本情報テーブル１３２及び出庫テーブル１３６から抽出して、図５３〜図５６に示すように「入庫内容」画面に表示する。
次に、ステップＳ２１２で、オペレータが、図５３〜図５５の「入庫内容」画面に、入庫情報（例えば、入庫場所、入庫日、アワーメータ値、運転業者名など）を入力する。すると、システムが、ステップＳ２１３で、入出庫基本情報テーブル１３２及び出庫テーブル１３６から読み込んだ上記出庫レコード及び「入庫内容」画面に入力された入庫情報を基に、入庫データを作成して入庫テーブル１３３に登録する。
この後、オペレータが「入庫入力」画面に戻ると、図５７に示すようにその「入庫入力」画面に上記入庫レコードの内容が表示されているので、これを確認し、「伝票印刷」をクリックすると、その入庫レコードに基づく入庫伝票が印刷される。
図５８は、図５のステップＳ１４の「特定自主検査」の処理の流れを示す。図５９〜図６２は、この処理で用いるユーザインタフェース画面を示す。
車両の特定自主検査や整備などを行う社外の所定のメンテナンス機関（勿論、レンタル会社内でそれらのメンテナンスを行うことができれば、レンタル会社の支店や本部やサービス工場などでもよい）において、まず、図５８に示すステップＳ２２０で、オペレータが端末コンピュータに図５９に示す「特定自主検査管理」画面を表示し、この画面に検査期限を入力して「検索」をクリックする。すると、ステップＳ２２１で、システムが、入力された検査期限までに特定自主検査を行う必要がある（つまり、前回の特定自主検査日の１年後の日が、入力された検査期限の前にある）車両についての特定自主検査レコードを、特定自主検査テーブル１５４から検索して、図６０に示すように「特定自主検査管理」画面に表示する。
或いは、検査対象の車両が始めから特定されている場合には、オペレータは図６１に示すように「特定自主検査管理」画面にその車両の管理番号を入力して「検索」をクリックし、すると、システムはその管理番号に該当する特定自主検査レコードを特定自主検査テーブル１５４から検索して、図６２に示すように「特定自主検査管理」画面に表示する。
こうして「特定自主検査管理」画面に検査すべき車両の特定自主検査レコードが表示されると、次に、ステップＳ２２２で、メンテナンス機関は、それら特定自主検査レコードの表示された車両に対して検査期限までに特定自主検査を実施し、そしてステップＳ２２３で法定の特定自主検査記録簿を作成して、その記録簿をレンタル会社の支店又は本部へファクシミリ送信する。
レンタル会社の支店又は本部では、ステップＳ２２４で、オペレータが、ファクシミリ受信した記録簿を、端末コンピュータに接続したイメージスキャナで読み込み、車両の管理番号と検査実施日を端末コンピュータに入力して、登録を指示する。すると、ステップＳ２２５で、システムが、入力された管理番号に該当する特定自主検査テーブル１５４内のレコードに対し、検査実施日及び記録簿イメージデータを付加する。
図６３は、図５のステップＳ１５の「特定自主検査記録簿出力」の処理の流れを示す。図６４は、この処理で用いられるユーザインタフェース画面を示す。
まず、ステップＳ２３０で、支店のオペレータが、端末コンピュータに所定の「特定自主検査管理」画面（図示せず）を表示して、この画面に記録簿を出力したい車両の管理番号を入力する。すると、ステップＳ２３１で、システムが、その管理番号に対応するレコードを特定自主管理テーブル１５４から読み出し、そのレコード内の記録簿に関連する情報を「特定自主検査管理」画面に表示する。
次に、ステップＳ２３２で、オペレータが、「特定自主検査管理」画面上で「記録簿表示」を選択すると、ステップＳ２３３で、システムが、その管理番号に対応する記録簿イメージデータを特定自主検査テーブル１５４から読み出し、図６３に示すように、所定の「記録簿イメージ表示」画面（図示せず）を開いて、その「記録簿イメージ表示」画面に記録簿イメージを表示する。
次に、ステップＳ２３４で、オペレータが、図６３の「記録簿イメージ表示」画面上で印刷を指示すると、ステップＳ２３５で、その記録簿イメージが印刷される。
図６５は、図５のステップＳ１６の「整備履歴照会」の処理の流れを示す。図６６〜図６８は、この処理で用いるユーザインタフェース画面を示す。
メンテナンス機関において、図６５のステップＳ２４０で、オペレータは、端末コンピュータに図６６に示す「整備履歴」画面を表示して、この画面に検索条件として、参照したい車両の管理番号を入れるか、又は、この画面の「機種／機番検索」をクリックして図６７に示す画面を表示して、この画面に検索条件として、参照したい車両の機種及び機番を入力して、「検索」をクリックする。すると、ステップＳ２４１で、システムが、入力された検索条件に対応するレコードを機番マスタテーブル１２０及び修理テーブル１５３から抽出し、そのレコード内の整備履歴に関する情報を図６８に示すように「整備履歴」画面に表示するので、ステップＳ２４２で、オペレータは「整備履歴」画面で整備履歴を確認する。
図６９は、図５のステップＳ１７の「オイル交換」の処理の流れを示す。図７０〜図７１は、この処理で用いるユーザインタフェース画面を示す。
メンテナンス機関において、図６９のステップＳ２５０で、オペレータは、端末コンピュータに図７０に示す「オイル交換管理」画面を表示して、この画面の「未交換検索」をクリックする。すると、ステップＳ２５１で、システムが、オイル交換の必要な（つまり、最新のサービスメータ値が、前回オイル交換時のサービスメータ値にオイル種類に応じた所定のオイル交換必要インターバルを加えた値を超えている）車両のレコードを、機番マスタテーブル１２０及び次回オイル交換テーブル１５５から読み出して、図７１に示すように「オイル未交換管理」画面に表示するので、ステップＳ２５２で、オペレータはリストされた車両を確認する。そして、ステップＳ２５３で、それらの車両のオイル交換を実施する。
図７２は、図５のステップＳ１８の「修理状況照会」の処理の流れを示す。図７３〜図７４は、この処理で用いるユーザインタフェース画面を示す。
メンテナンス機関において、図７２のステップＳ２６０で、オペレータは、端末コンピュータに図７１に示す「修理状況照会」画面を表示して、この画面に「管理番号」を入力して「照会」をクリックする。すると、ステップＳ２６で、システムが、入力された管理番号に対応するレコードを機番マスタテーブル１２０及び修理テーブル１５３から読み出して、図７４に示すように「修理状況照会」画面に表示するので、ステップＳ２６２で、オペレータは修理状況を確認する。
以上、１つの実施形態を説明したが、上記実施形態には、種々の改良を加えることができる。以下、上記実施形態に適用できる幾つかの改良について説明する。
（Ａ）第１の改良
第１の改良は、上記実施形態における振り当て処理において、在庫中がゼロの車両であっても、返却日が或る程度正確に予測できる車両（例えば、貸し出し中であって返却日が或る程度正確に予測できる車両や、点検中であって点検終了日が或る程度正確に予測できる車両など）は、事前に振り当てる（以下、これを「事前予約」と言う）ことができるようにしたことである。上記実施形態では、図１５のＳ１１３を見てわかるように、在庫中がゼロでない車両だけにしか振り当て処理が行えないが、この改良により、在庫中がゼロの車両も、入庫予定予測に基づいて振り当てることができる。これにより、繁忙期で車両が不足し在庫中ゼロの車両が増えてしまっても、それに影響することなく入庫予定予測に基づいて車両を振り当てられるので、効率的な貸し出しが図れる。以下、事前予約の流れを説明する。
営業員が、例えば毎日、自分が担当する車両の返却予定日を確認し、返却予定日が間近になった各車両（例えば返却予定日が後２日後になった車両、以下、返却予定日間近車両）について、各車両の貸出先の顧客と連絡をとることで、返却予定日間近車両の返却確度をそれぞれ推測し入力する。
具体的には、支店の端末コンピュータ１１２に表示された図１６に示すようなメニュー画面で、営業員（オペレータ）が「受注／伺い　出庫　入庫」及び「機械状況照会」を順にクリックすると、システムが、図７５に示すような「機械状況照会」画面（どのエントリフィールドもブランクになっているもの）を表示する（具体的には、図７５の「機械状況照会」画面は、図１７の「機械状況照会」画面に表示される表の項目に、「次回の特自検査日」が追加されたものである）。そして、営業員が図７５の「機械状況照会」画面に検索キーとして照会したい機種の機械コード（例えば、「ＰＣ１２０」）又は照会したい車両の管理番号などを入力すると、システムが、入力された検索キーに該当する全ての車両のレコードを機番マスタテーブル１２０から抽出して、そのレコード内容を図７５に示すように「機械状況照会」画面に表示する。
この画面上で、営業員は、返却予定日間近車両の返却予定日の欄（例えば、返却予定日が「２００１／０５／１４」になっている欄９９９）をダブルクリックする。すると、システムが、図７６に示すように、「機械状況照会」画面上に、返却確度として「確実」、「多分」、及び「わからない」を入力できる返却予定日ダイアログボックス１０００を表示する。営業員は、この返却予定日ダイアログボックス１０００に、返却予定日間近車両の返却確度を入力する。具体的には、例えば、既に登録されている返却予定日（図７６で言えば「２００１／５／１４」）に車両が確実に返却されると推測されれば、営業員は、「確実」のラジオボタンにチェックマークを入力して「ＯＫ」ボタンをクリックする。別の例として、「２００１／５／１４」には無理であるが、「２００１／５／２２」には確実に返却されると推測されれば、営業員は、ダイアログボックス１０００上の入力欄１００１に、「２００１／５／２２」を入力し、且つ、「確実」のラジオボタンにチェックマークを入力して「ＯＫ」ボタンをクリックする。このダイアログボックス１０００で入力された情報は、例えば、入出庫基本情報テーブル１３２に更新される。
一方、本部のコンピュータ端末のオペレータ（以下、本部オペレータ）は、定期的に或いは随時に、各車両の在庫状況を確認し、必要に応じて、上記実施形態で説明した方法で「予約規制」をかけて、営業員の携帯電話などからの依頼に応じて予約を入れられないようにする。
また、本部オペレータは、図２４に示すメニュー画面を端末コンピュータ１１４に表示して「振当て　運搬　運搬計画」及び「受注状況の確認」を順にクリックする。すると、レンタル会社システムが、そのコンピュータ端末に、図７７に示すような「受注状況確認」画面（どのエントリフィールドもブランクになっているもの）を表示する。そして、本部オペレータが、その「受注状況確認」画面で、所望の伺い受付日（例えば、２００１／０７／１６〜２００１／０７／２３）を入力し、且つ、見たい情報項目に対応したラジオボタンにチェックマークを入れて「実行」ボタンをクリックすると、図７７に示すように、システムが、入力された日に受付けた伺い書の一覧で表示する（既に事前予約がされている伺い書に対しては、例えば「代用可能機種区分」の欄に「事前予約」が表示される）。この画面で、本部オペレータが、所望の伺い書を選択して「事前予約」ボタンをクリックすると、システムが、図７８に示すように、本部オペレータに選択された伺い書に対する「事前予約」画面を表示する。この画面には、上記選択された伺い書に記載されている伺い対象の車両の在庫や返却確度の情報が表示されている。本部オペレータは、この「事前予約」画面上で、所望の日付と所望の在庫地とに対応する欄を選択して、「事前予約」ボタンをクリックする。これにより、図７７の「受注状況確認」画面で選択した伺い書に対して、たとえ在庫中がゼロであってもその車両が事前予約として振り当てられる（つまり、返却された時点でその車両は予約済みとなる）。
以上が、第１の改良についての説明である。なお、上記の説明では、手動で伺い書に事前予約を割当てるが、これを自動で行ってもよい。具体的には、例えば、本部オペレータが、各車両の在庫及び返却確度を確認し、所望の車両に対して「事前予約」の実行をシステムに指示する。システムは、その指示を受けたら、各車両の在庫や返却確度、及び、伺い基本情報テーブル１２５や伺い明細テーブル１２６に記録されている情報を基に（又は、これに加えて、顧客の優先度など別の情報も加味して）、事前予約を実行する。具体的には、例えば、システムは、或る月日の或る在庫地において、在庫中がゼロでも、返却確度「確実」が５台ある車両は、上記或る月日の翌日を「出庫希望日」とし、且つ、上記或る在庫地を「出庫地」とする伺いに対して、「確実」であっても返却が遅れてしまう可能性があることを考慮し、５台のうちの３台を振り当てる。
（Ｂ）第２の改良
第２の改良は、支店（又は本部）の人間が、自社又は他社（例えば、上述したメンテナンス機関）に依頼した修理の進捗状況を一目で把握できるようにしたことである。以下、具体的に説明する。
図７９は、支店の人間が修理の進捗状況を把握できるようになるための処理流れを示す。
まず、支店のオペレータ（例えば車両の点検者）は、例えば図４５を参照して説明した方法で、点検結果を端末コンピュータ１１２に入力する（Ｓ３０１）。そして、支店のオペレータは、入力した点検結果が不良有りで修理の必要があれば（このとき、例えば、図８０に示すメニュー画面で「点検　修理など」及び「入出庫点検照会」を順にクリックすることでシステムが表示する図８１の「点検結果紹介」画面を用いて、点検結果を確認することができる）（Ｓ３０２でＹｅｓ）、図８２に示す「車両点検入力・修理車両管理」画面を端末コンピュータ１１２に表示させて、この画面上で、「事故報告書」及び「事故報告書作成」を順次クリックする。すると、システムが事故報告書作成用画面（図示せず）を端末コンピュータ１１２に表示するので、支店のオペレータは、その画面に必要な報告内容を入力する（Ｓ３０３）。
そして、支店のオペレータは、上記不良に関する修理を自社で行うときには、（Ｓ３０４でＮｏ）、その旨を端末コンピュータ１１２に入力する。この場合、システムは、Ｓ３０３で入力された事故報告内容（以下、これを事故報告書と言う）を自社用事故報告書テーブル１００９（このテーブルは例えば基幹サーバ１０８が持つ）に登録すると共に、その事故報告書に関する特定の情報（例えば、修理の「依頼先」、「発注番号」、「入出庫番号」、「機種」、「修理区分」、及び「修理状況」など）を修理テーブル１５３に登録する（Ｓ３０９）。
一方、支店のオペレータは、上記不良に関する修理を他社（例えば上述したメンテナンス機関）に依頼するときには、（Ｓ３０４でＹｅｓ）、その旨を端末コンピュータ１１２に入力する。この場合、システムは、Ｓ３０３で入力された事故報告書をメンテナンス機関のサーバ１１５に送信すると共に、その事故報告書に関する特定の情報（例えば、修理の「依頼先」、「発注番号」、「入出庫番号」、「機種」、「修理区分」、及び「修理状況」など）を修理テーブル１５３に登録する（Ｓ３０５）。
メンテナンス機関のサーバ１１５は、支店の端末コンピュータ１１２から事故報告書を受信したときは、受付処理を実行する（Ｓ３０６）。具体的には、メンテナンス機関のサーバ１１５は、受信した事故報告書を、このサーバ１１５が有する修理受付テーブル１００３に登録する。また、サーバ１１５は、修理受付テーブル１００３に登録されている事故報告情報を基にした修理情報の入力をメンテナンス機関のオペレータから受けて、入力された修理情報を、このサーバ１１５が有する修理受付明細テーブル１００５に登録する。なお、ここで言う修理情報は、例えば、修理の種類、作業内容、及び、修理にかかる予想所要時間長（又は所要工数）等である。
メンテナンス機関の修理担当者は、修理受付明細テーブル１００５に登録されている修理情報を基に修理を行い、例えば仕事終了時に、修理日報として、今日１日に行った修理の内容及び修理をした時間長（又は工数）をサーバ１１５に入力する。サーバ１１５は、入力された修理日報を、サーバ１１５が有する修理日報１００７に登録する（Ｓ３０８）。メンテナンス機関の修理担当者は、完全に修理を終えるまで、修理日報の入力を欠かさず行う。
図８３は、支店（又は本部）のオペレータが各修理の進捗状況を確認するための処理流れを示す。
まず、支店のオペレータ（例えば営業員）は、端末コンピュータ１１２に、修理報告書状況照会画面の表示を要求する（Ｓ３１０）。すると、システムが、修理テーブル１５３に登録されている情報を基に、図８４に示すような「修理報告書状況照会」画面を端末コンピュータ１１２に表示する。
そして、支店のオペレータは、修理の進捗状況を確認したければ、図８４の「修理報告書状況照会」画面に表示された表の所望の欄、すなわち、進捗状況を確認したい修理に対応する「修理状況」の欄をダブルクリックする（Ｓ３１２）。
システムは、ダブルクリックされた欄に関する修理の依頼先がメンテナンス機関（他社）であれば（Ｓ３１３でＮｏ）、メンテナンス機関の修理日報テーブル１００７に記録されている修理日報のうち、上記ダブルクリックされた欄に関する修理の修理日報を基に、図８５に示すような「修理状況照会」画面を端末コンピュータ１１２に表示する（Ｓ３１４）。この画面には、修理に関する諸情報（発注番号、指示番号、発注先など）や、修理日報に記録されている情報、すなわち、修理に関する作業名称や、修理担当者や、これまでに行われた修理作業時間長が表示される。また、修理日報に記録されている作業時間長と、修理にかかる予想所要時間長とを基に、修理の進捗率も表示される。この画面を見れば、支店のオペレータは、どのような修理が行われ、担当者が誰で、進捗状況はどのようになっているかが一目でわかる。
一方、システムは、Ｓ３１２でダブルクリックされた欄に関する修理の依頼先が自社であれば（Ｓ３１３でＹｅｓ）、自社における修理に関する修理状況照会画面（図示せず）を端末コンピュータ１１２に表示する。なお、この画面は、例えば、図８５の修理状況照会画面と同様に、支店の修理担当者に修理日報を入力させ、その修理日報を基に作成される画面であっても良いし、別の方法で作成される画面であっても良い。
（Ｃ）第３の改良
第３の改良は、特定自主検査記録表を簡単な操作で表示したり、それを印刷したりすることができるようにしたことである。具体例としては、支店の端末コンピュータ１１２で、所望の車両の特定自主検査記録表が見たいときは、図７５に示した機械状況照会画面上で、所望の車両の「次回の特自検査日」が記録されている欄をダブルクリックすると、システムが、図６４に示したような特定自主検査記録表のイメージを表示する（勿論、オペレータの要求に応じて印刷することもできる）。なお、特定自主検査記録表のイメージは、ＰＤＡ等の他のコンピュータシステムでも表示可能である。
（Ｄ）第４の改良
第４の改良は、衛星通信システム２００を通じて収集された各車両１０１、１０１、…の稼動情報に含まれている稼働時間情報を基に、車両の貸し出しの請求金額を制御できるようにしたことである。以下、それの処理流れを説明する。
まず、支店又は本部のオペレータが、端末コンピュータ１１２に表示された図８６に示すようなメニュー画面上で、「仕入　売上　請求」及び「稼動　休車　入力」を順にクリックすると、システムが、図８７に示すような「稼動状況検索」画面（どのエントリフィールドもブランクになっているもの）を表示する。そして、オペレータが、図８４に検索画面に検索キーとして顧客ＣＤ等を入力すると、システムが、入力された検索キーに該当する全ての車両のレコードを稼動・休車テーブル１４４から抽出して、そのレコード内容を基に検索結果を表示する。稼動・休車テーブル１４４には、稼動と休車に関する情報として、例えば、上述した稼動情報と、「管理番号」、「機種／機番商品名」、「入出庫番号」、「現場」、「契約形態」、「売上開始日（これは、ＴＭＳメールデータから初めて稼動が検出された日に自動又は手動で設定して良い）」、及び「売上終了予定日」を含む情報とが記録されている。
検索結果が表示された図８７の画面上で、オペレータが、稼動状況を入力した車両の「選択」の欄（例えば欄９９８）にチェックマークを入れて「ＯＫ」ボタンをクリックすると、システムが、稼動・休車テーブル１４４を参照し、チェックマークを入れられた欄に対応する車両の稼動情報（特に、稼動開始時刻、稼動終了時刻、及び稼動時間長）を用いて、図８８に示すような「稼動状況入力」画面を端末コンピュータ１１２に表示する。
この画面には、貸し出した期間におけるオペレータ所望の月（この図では２００１年６月）のカレンダーが表示され、そのカレンダーには、その月の各日付が書かれた欄と、各日付に対応し所望の稼動状況マークが入力可能な空欄（例えば上下２段に分かれている、以下、稼動状況マーク入力欄）とが設けられている。上段にある稼動状況マーク入力欄のうち、稼動時間長がゼロ又は僅か（例えば１時間以下）であった日に対応する欄は、例えば斜線で表示される（勿論、表示形態はこれに限らず、例えば、上段の全ての稼動状況マーク入力欄には、稼動時間長を示す数字が表示されても良い）。このカレンダーには、稼動状況マークのうち、例えば、出庫日を示すマーク「→」と入庫日を示すマーク「←」は、出庫テーブル１３３に記録されている「出庫日」及び入庫テーブル１３６に記録されている「入庫日」を基に自動で表示され、入力区分を示すマーク（休車を示す黒丸印や、半日稼動を示す黒三角印など）は、上記稼動情報を基に手動で入力される（勿論自動で入力することもできる）。
システムは、この「稼動状況入力」画面に入力された情報を基に、貸し出された車両の料金計算を行う。
以上が、第４の改良についての説明である。なお、この第４の改良に係る実施形態では、システムが自動的に料金計算を行う代わりに、「稼動状況入力」画面の情報を基に、人が計算を行っても良い。また、稼動開始時刻、稼動終了時刻、及び稼動時間長の代わりに、アワメータの増加数など別の種類の稼動状況を基に「稼動状況入力」画面が作成されても良い。
以上、本発明の実施形態を説明したが、これは本発明の説明のための例示にすぎず、本発明をこの実施形態にのみ限定する趣旨ではない。よって、本発明は、他のさまざまな形態で実施することができる。
例えば、上記実施形態では、各レンタル会社は複数の支店を持っていて、各支店にレンタル車両を置き、各支店で車両を出庫したり入庫したりしている。しかし、本発明のシステムを十分に活用して最大効率の運用を行うことで、レンタル車両を前のレンタル先の現場から次のレンタル先の現場へ直接運搬したり、レンタル車両のメンテナンスや修理もレンタル先の現場か又は社外のメンテナンス業者方で行うなどの営業形態、すなわち、レンタル会社としては空き車両を置いておく格別の車庫を持つ必要のない（または、極めて小容量の車庫だけ持てば十分である）実質的な無店舗式の営業も可能となる。
また、建設車両１０１、１０１、・・・とＴＭＳメールサーバ３００との間の通信は、携帯電話のデータ通信サービスを利用することも可能である。
また、本発明のシステムは、建設車両だけでなく、他の様々な機械や物品のレンタル業にも適用することができる。
【図面の簡単な説明】
図１は、本発明の一実施形態にかかるを示すブロック図である。
図２は、レンタル会社システム１００の基幹サーバ１０８がもつデータベースの内容を示すブロック図である。
図３は、このシステムで行われる業務処理のうち、建設車両の在庫照会から移動依頼までの業務処理の全体的流れを示すフローチャートである。
図４は、図３の流れの後に続く、建設車両の運搬スケジューリングから入庫までの業務処理の全体的流れを示すフローチャートである。
図５は、建設車両のメンテナンスに関する業務処理の全体的流れを示すフローチャートである。
図６は、図７以下のフローチャートのための凡例を示す図である。
図７は、図３のステップＳ１の「予約／移動規制」の処理の流れ（車両毎に行う場合）を示すフローチャートである。
図８は、予約／移動規制の処理で用いるメニュー画面を示す。
図９は、車両毎の予約／移動規制の処理で用いる機番検索画面を示す。
図１０は、車両毎の予約／移動規制の処理で用いる機番検索画面（検索結果）を示す。
図１１は、車両毎の予約／移動規制の処理で用いる機械機番画面を示す。
図１２は、車種毎の予約／移動規制の処理で用いる機械検索画面を示す。
図１３は、車種毎の予約／移動規制の処理で用いる機械検索画面（検索結果）を示す。
図１４は、車種毎の予約／移動規制の処理で用いる機械マスタ画面を示す。
図１５は、図３のステップＳ２の「在庫照会」の処理の流れを示すフローチャートである。
図１６は、在庫照会の処理に入るためのメニュー画面を示す。
図１７は、在庫照会の処理で用いる機械状況照会画面を示す。
図１８は、図３のステップＳ３の「伺い書作成（自動振り当て規制の場合）」の処理の流れを示すフローチャートである。
図１９は、伺い書作成（自動振り当て規制の場合）の処理で用いる受注・伺い画面を示す。
図２０は、伺い書作成（自動振り当て規制の場合）の処理で用いるアタッチメントボックスを示す。
図２１は、図３のステップＳ４の「振り当て処理（自動振り当て規制の場合）」の流れを示すフローチャート（前半部分）である。
図２２は、図３のステップＳ４の「振り当て処理（自動振り当て規制の場合）」の流れを示すフローチャート（後半部分）である。
図２３は、振り当て処理（自動振り当て規制の場合）で用いる新着情報画面を示す。
図２４は、振り当て処理（自動振り当て規制の場合）に入るためのメニュー画面を示す。
図２５は、振り当て処理（自動振り当て規制の場合）で用いる機械の振り当て処理画面を示す。
図２６は、図３のステップＳ５の「携帯電話によるリアルタイム検索及び仮予約」の処理の流れを示すフローチャート。
図２７は、営業員の携帯電話に表示される携帯電話コンテンツの画面の種類とその遷移を示す。
図２８は、図３のステップＳ６の「伺い書作成（自動振り当て規制なしの場合）『予約』」の処理で用いられる「受注・伺」画面を示す。
図２９は、図３のステップＳ７の「ポイント移動依頼」の処理の流れを示すフローチャート。
図３０は、ポイント移動依頼の処理で用いる「レンタル運搬」画面を示す。
図３１は、ポイント移動依頼の処理で用いる「運搬一覧と在庫地管理」画面を示す。
図３２は、図４のステップＳ８の「運搬スケジューリング（ポイント間移動時）」の処理の流れを示すフローチャート。
図３３は、運搬スケジューリングの処理で用いる「運搬スケジュール」画面を示す。
図３４は、運搬スケジューリングの処理で用いる「運搬の振当処理」画面を示す。
図３５は、図４のステップＳ１０の「出庫（ポイント間移動時）」の処理の流れを示すフローチャート（前半部分）。
図３６は、図４のステップＳ１０の「出庫（ポイント間移動時）」の処理の流れを示すフローチャート（後半部分）。
図３７は、出庫の処理で用いる「出庫入力」画面を示す。
図３８は、出庫の処理で用いる「予約車両」画面を示す。
図３９は、出庫の処理で用いる「出庫内容」画面を示す。
図４０は、出庫の処理で用いる「出庫内容」画面を示す。
図４１は、出庫の処理で用いる「出庫内容」画面を示す。
図４２は、出庫の処理で用いる「出庫内容」画面を示す。
図４３は、出庫の処理で用いる「出庫内容」画面を示す。
図４４は、出庫の処理で用いる「出庫入力」画面を示す。
図４５は、図４のステップＳ１１及びＳ１２の出庫時及び入庫時の「画像データ及び点検情報の入力」の処理の流れを示すフローチャート。
図４６は、「画像データ及び点検情報の入力」の処理に入るためのＰＤＡのメニュー画面を示す。
図４７は、「画像データ及び点検情報の入力」の処理で用いる「受入点検入力」画面を示す。
図４８は、「画像データ及び点検情報の入力」の処理で用いる「受入点検入力」画面を示す。
図４９は、「画像データ及び点検情報の入力」の処理で用いる「点検項目入力」画面を示す。
図５０は、「画像データ及び点検情報の入力」の処理で用いる「写真」画面を示す。
図５１は、図４のステップＳ１３の「入庫」の処理の流れを示すフローチャート。図５２〜図５７は、この処理で用いるユーザインタフェース画面を示す。
図５２は、入庫の処理で用いる「入庫入力」画面を示す。
図５３は、入庫の処理で用いる「入庫内容」画面を示す。
図５４は、入庫の処理で用いる「入庫内容」画面を示す。
図５５は、入庫の処理で用いる「入庫内容」画面を示す。
図５６は、入庫の処理で用いる「入庫内容」画面を示す。
図５７は、入庫の処理で用いる「入庫入力」画面を示す。
図５８は、図５のステップＳ１４の「特定自主検査」の処理の流れを示すフローチャートである。
図５９は、特定自主検査の処理で用いる「特定自主検査管理」画面を示す。
図６０は、特定自主検査の処理で用いる「特定自主検査管理」画面を示す。
図６１は、特定自主検査の処理で用いる「特定自主検査管理」画面を示す。
図６２は、特定自主検査の処理で用いる「特定自主検査管理」画面を示す。
図６３は、図５のステップＳ１５の「特定自主検査記録簿出力」の処理の流れを示すフローチャートである。
図６４は、特定自主検査記録簿出力の処理で用いる記録簿イメージ表示画面を示す。
図６５は、図５のステップＳ１６の「整備履歴照会」の処理の流れを示すフローチャート。
図６６は、整備履歴照会の処理で用いる「整備履歴」画面を示す。
図６７は、整備履歴照会の処理で用いる「整備履歴」画面を示す。
図６８は、整備履歴照会の処理で用いる「整備履歴」画面を示す。
図６９は、図６のステップＳ１７の「オイル交換」の処理の流れを示すフローチャートである。
図７０は、オイル交換の処理で用いる「オイル交換管理」画面を示す。
図７１は、オイル交換の処理で用いる「オイル未交換管理」画面を示す。
図７２は、図５のステップＳ１８の「修理状況照会」の処理の流れを示すフローチャートである。
図７３は、修理状況照会の処理で用いる「修理状況照会」画面を示す。
図７４は、修理状況照会の処理で用いる「修理状況照会」画面を示す。
図７５は、第１の改良に係る実施形態で用いられる「機械状況照会」画面を示す。
図７６は、図７５の「機械状況照会」画面の上に表示される「返却予定日」ダイアログボックスを示す。
図７７は、「受注状況確認」画面を示す。
図７８は、「事前予約」画面を示す。
図７９は、第２の改良に係る実施形態における、支店の人間が修理の進捗状況を把握できるようになるための処理流れを示す。
図８０は、第２の改良に係る実施形態におけるメニュー画面を示す。
図８１は、「点検結果紹介」画面を示す。
図８２は、「車両点検入力・修理車両管理」画面を示す。
図８３は、支店（又は本部）のオペレータが各修理の進捗状況を確認するための処理流れを示す。
図８４は、「修理報告書状況照会」画面を示す。
図８５は、「修理状況照会」画面を示す。
図８６は、第４の改良に係る実施形態におけるメニュー画面を示す。
図８７は、「稼動状況検索」画面を示す。
図８８は、「稼動状況入力」画面を示す。

Claims (24)

1. 複数のレンタル品の情報を管理する基幹サーバシステムと、
   前記基幹サーバシステムと通信接続することが可能な業務システムと
   を備え、
   前記基幹サーバまたは前記業務システムが、前記レンタル品の顧客との授受を管理する管理手段を有し、
   前記業務システムが、前記レンタル品について
   （１）　前記基幹サーバシステムが管理する情報を表示する手段と
   （２）　顧客からのレンタル注文を受付ける手段
   を有したレンタルシステム。
2. 前記レンタル品の情報が、前記レンタル品の商品名をベースとして基幹サーバシステムに蓄積されている請求項１記載のレンタルシステム。
3. 前記基幹サーバシステムが前記レンタル品の場所間の移動のスケジュールを処理する手段を有する請求項１または２記載のレンタルシステム。
4. 前記レンタル品の情報が、前記レンタル品の貸し出し中または運搬中の情報を含んでいる請求項１または２記載のレンタルシステム。
5. 前記レンタル品の情報が、前記レンタル品の貸し出し期間の情報を含んでいる請求項１または２記載のレンタルシステム。
6. 前記レンタル品の情報が前記レンタル品の入出庫情報を含む請求項１または２記載のレンタルシステム。
7. 前記レンタル品の情報が前記レンタル品の位置情報を含む請求項１または２記載のレンタルシステム。
8. 前記位置情報を随時または定期的に更新する手段を備えた請求項７記載のレンタルシステム。
9. 前記レンタル品の情報が前記レンタル品の稼動状況を表す情報を含む請求項１または２記載のレンタルシステム。
10. 前記レンタル品の情報が前記レンタル品たる機械のエンジン油圧またはエンジン回転数または作業機油温または作業機油圧またはラジエータ水温または作業機負荷に関する情報を含む請求項１または２記載のレンタルシステム。
11. 前記業務システムが、前記基幹サーバシステムと随時に無線通信接続することが可能な携帯情報処理システムを有する請求項１または２記載のレンタルシステム。
12. 前記基幹サーバシステムが、前記レンタル品の情報を随時にまたは定期的に更新する手段を有する請求項１または２記載のレンタルシステム。
13. 更新される前記レンタル品の情報が顧客からの注文情報を含む請求項１２記載のレンタルシステム。
14. 前記業務システムが、顧客からの注文引き合いの情報を受付ける手段を有する請求項１または２記載のレンタルシステム。
15. 複数のレンタル品の情報を管理する基幹サーバシステムと、
    前記基幹サーバシステムと通信接続することが可能な業務システムと
    を備え、
    前記基幹サーバシステムには、前記レンタル品の現在の位置情報と、現在の稼働状態情報と、メンテナンス履歴またはメンテナンススケジュールに関するメンテナンス情報が記憶されており、
    前記基幹サーバシステムと通信接続することが可能で、前記基幹サーバシステムに記憶された前記位置情報と前記稼働情報と前記メンテナンス情報を取得して表示する手段を備えた、メンテナンス実施部門に設けられたメンテナンスシステムを備えたレンタルシステム。
16. 前記レンタル品は、位置情報と現在の稼働状態情報を検出するセンサシステムを有し、
    前記基幹サーバシステムは、前記レンタル品の前記センサシステムと遠隔無線通信網を通じて通信可能であり、前記レンタル品の前記センサシステムより随時または定期的に前記レンタル品の最新の位置情報と稼働状態情報を受信して、前記基幹サーバシステムが管理するレンタル品の位置情報と稼働状態情報を更新する請求項１、２または１５記載のレンタルシステム。
17. 前記レンタル品の情報が前記レンタル品の品種と空き状態と自動振り当て規制の有無を示すデータを含んでおり、
    顧客からの注文を受け、前記基幹サーバシステム内の情報に基づいて複数の前記レンタル品の中から顧客の要求に合うレンタル品を検索し、検索されたレンタル品の中のいずれかを前記顧客からの注文を割り当てる注文処理システムを備えた請求項１または２記載のレンタルシステム。
18. 前記注文処理システムが、複数の前記レンタル品の中から任意のレンタル品を指定して、指定したレンタル品について前記基幹サーバシステム内の前記自動振り当て規制の有無を示すデータを更新する自動振り当て制御システムを有した請求項１７記載のレンタルシステム。
19. 前記自動振り当て制御システムが、前記検索されたレンタル品の中から前記顧客からの注文に振り当てられるレンタル品を選定する方法として、自動的に選定する方法とオペレータがマニュアルで選定する方法のいずれを採用するかを制御する請求項１８記載のレンタルシステム。
20. 前記基幹サーバシステムが前記レンタル品の画像情報を記憶する手段を有し、
    前記画像情報は前記レンタル品が顧客に貸し出される時または返却される時に、前記レンタル品を撮影して得た写真データである請求項１または２記載のレンタルシステム。
21. 前記業務システムが、前記レンタル品が或る予定時刻までに返却される可能性の返却確度の入力をオペレータから受け付ける手段を有し、
    前記基幹サーバシステム又は前記業務システムが、前記レンタル品が在庫に無い場合であっても、前記オペレータに入力された返却確度に基づいて、前記レンタル品の予約を受け付ける手段を有する請求項１記載のレンタルシステム。
22. 前記レンタル品の修理作業に関する修理作業情報の入力を受付ける手段と、
    前記入力された修理作業情報を基に修理の進捗状況を表す情報を表示する手段と
    を更に備える請求項１記載のレンタルシステム。
23. 前記レンタル品が貸し出されている間の各日の、前記レンタル品の稼動状況をそれぞれ検出する手段と、
    前記検出した前記各日の稼動状況を基に前記レンタル品の稼動状況情報を作成し表示する手段と
    を更に備える請求項１記載のレンタルシステム。
24. 前記稼動状況は、稼動開始時刻及び稼動終了時刻、又は、稼動時間長である請求項２３記載のレンタルシステム。

Images