(57)【要約】【課題】荷受人の在宅情報に応じた配送リストを生成する配送するシステムにおいて、配送状況に応じて更新される荷受人の情報を容易に確認可能な仕組みを提供すること。【解決手段】配送人の携帯端末と通信可能な情報処理装置とを含む情報処理システムであって、荷受人の在宅情報を取得し、当該情報処理システムは、取得した荷受人の在宅情報に応じて、在宅か否かを識別可能に表示するよう制御する。そして取得した在宅情報に変更があった場合には、変更に応じて在宅情報を表示するよう制御する。【選択図】図１１
2019109642.tif 000002
【特許請求の範囲】
【請求項１】
配送人の携帯端末と通信可能な情報処理装置とを含む情報処理システムであって、
荷受人の在宅情報を取得する取得手段と、
前記取得手段で取得した荷受人の在宅情報に応じて、在宅か否かを識別可能に表示するよう制御する表示制御手段と、
を備え、
前記表示制御手段は、前記取得手段で取得した在宅情報に変更があった場合には、変更に応じて前記在宅情報を表示するよう制御することを特徴とする情報処理システム。
【請求項２】
前記取得手段は、前記配送人の荷物の配送中に前記在宅情報を取得し、
前記表示制御手段は、前記取得手段で新しく取得した当該在宅情報による変更を反映して、当該在宅情報を識別可能に表示するよう制御することを特徴とする請求項１に記載の情報処理システム。
【請求項３】
前記情報処理システムは、前記取得手段で取得した在宅情報に基づいて前記荷受人の在宅情報を識別可能な画面を生成する生成手段を更に備え、
前記表示制御手段は、前記在宅情報の変更に応じて前記生成手段で生成した画面の表示を制御することを特徴とする請求項１または２に記載の情報処理システム。
【請求項４】
前記取得手段は、前記生成手段で生成された画面に表示された荷受人のうち、第１の荷受人への荷物の配送の完了を受け付けると、前記第１の荷受人と同じ画面に表示される第２の荷受人の在宅情報を取得することを特徴とする請求項３に記載の情報処理システム。
【請求項５】
前記取得手段は、前記第１の荷受人への荷物の配送の完了を受け付けると、前記第１の荷受人から2つ先に配送予定の荷受人の在宅情報を取得することを特徴とする請求項４に記載の情報処理システム。
【請求項６】
前記情報処理システムは、前記表示制御手段で表示された荷受人の在宅情報を削除する削除手段をさらに備え、
前記表示制御手段は、前記荷受人の在宅情報のうち、前記削除手段で削除した荷受人の在宅情報は表示しないよう制御することを特徴とする請求項１乃至５のいずれか１項に記載の情報処理システム。
【請求項７】
配送人の携帯端末と通信可能な情報処理装置とを含む情報処理システムの制御方法であって、
荷受人の在宅情報を取得する取得ステップと、
前記取得ステップで取得した荷受人の在宅情報に応じて、在宅か否かを識別可能に表示するよう制御する表示制御ステップと、
を備え、
前記表示制御ステップは、前記取得ステップで取得した在宅情報に変更があった場合には、変更に応じて前記在宅情報を表示するよう制御することを特徴とする情報処理システムの制御方法。
【請求項８】
配送人の携帯端末と通信可能な情報処理装置とを含む情報処理システムとして機能させるプログラムであって、
前記情報処理システムを、
荷受人の在宅情報を取得する取得手段と、
前記取得手段で取得した荷受人の在宅情報に応じて、在宅か否かを識別可能に表示するよう制御する表示制御手段
として機能させ、
前記表示制御手段を、前記取得手段で取得した在宅情報に変更があった場合には、変更に応じて前記在宅情報を表示するように制御するよう機能させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
情報処理システム、その制御方法、及びプログラムに関する。
【背景技術】
【０００２】
宅配便事業者が荷物を配送する際に、荷物を受け取る荷受人が不在であった場合は荷物の再配送が行われる。しかしながら、荷物の再配送は宅配便事業者に負担がかかり、配送効率も低下する。
【０００３】
そこで、荷受人が在宅しているか否かを判断し、再配送を抑止するため、在宅と判断された荷受人に対して荷物を配送するシステムが構築されている。
【０００４】
特許文献１では、配送センタサーバで配送を受けるユーザが在宅か否かの確認を行い、配送可能なもののみでスケジューリングを行い、その結果で配送車が配送を行う記載が示されている。また、配送予定に載らなかった家庭に関しては再度スケジューリングを実施し、予定を立て直すことも開示されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００１―２９４３０９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、特許文献１のようにあらかじめ配送するルートや配送する荷受人の予定を組んだとしても、実際に配送を行うタイミングによって荷受人が不在となり配送できない場合もある。そのため適宜荷物の配送を行いながら荷受人の状況を確認したいという配送人の要望がある。
【０００７】
そこで、本発明は、荷受人の在宅情報に応じた配送リストを生成する配送するシステムにおいて、配送状況に応じて更新される荷受人の情報を容易に確認可能な仕組みを提供することを目的とする。
【課題を解決するための手段】
【０００８】
本発明の情報処理システムは、配送人の携帯端末と通信可能な情報処理装置とを含む情報処理システムであって、荷受人の在宅情報を取得する取得手段と、前記取得手段で取得した荷受人の在宅情報に応じて、在宅か否かを識別可能に表示するよう制御する表示制御手段と、備え、前記表示制御手段は、前記取得手段で取得した在宅情報に変更があった場合には、変更に応じて前記在宅情報を表示するよう制御することを特徴とする。
【発明の効果】
【０００９】
本発明によれば、荷受人の在宅情報に応じた配送リストを生成する配送するシステムにおいて、配送状況に応じて更新される荷受人の情報を容易に確認可能な仕組みを提供することを目的とする。
【図面の簡単な説明】
【００１０】
【図１】本実施形態におけるシステム構成の一例を示す図である。
【図２】本実施形態におけるデータベースサーバ１０１ａ、データベースサーバ１０１ｂのハードウェア構成の一例を示す概念図である。
【図３】本実施形態におけるアプリケーションクライアント１０２ａ、アプリケーションクライアント１０２ｂのハードウェア構成の一例を示す概念図である。
【図４】データベースサーバ１０１ａ、データベースサーバ１０１ｂ、アプリケーションクライアント１０２ａ、アプリケーションクライアント１０２ｂの機能構成の一例を示す概念図である。
【図５】本実施形態におけるシステム全体の一例を示すフローチャートである。
【図６】配送ルート生成処理と荷受人情報チェック処理の一例を示すフローチャートである。
【図７】図６の荷受人情報チェック処理の続きを示すフローチャートである。
【図８】在宅判断処理の一例を示すフローチャートである。
【図９】配送処理の一例を示すフローチャートである。
【図１０】図９の配送処理の続きを示すフローチャートである。
【図１１】図１０の配送処理の続きを示すフローチャートである。
【図１２】配送方法切り替え処置の一例を示すフローチャートである。
【図１３】仮配送順序１３０１のデータテーブルの一例を示す図である。
【図１４】荷物情報１４０１のデータテーブルの一例を示す図である。
【図１５】アプリケーションステータス１５０１のデータテーブルの一例を示す図である。
【図１６】在宅確認リスト１６０１のデータテーブルの一例を示す図である。
【図１７】ユーザリスト１７０１のデータテーブルの一例を示す図である。
【図１８】配送画面１８０１の一例を示す図である。
【図１９】アプリケーションステータス１９０１のデータテーブルの一例を示す図である。
【発明を実施するための形態】
【００１１】
以下、図面を参照して、本発明の実施形態を詳細に説明する。
【００１２】
図１は、荷受人の位置情報を利用して在宅判断を行う配送システム（情報処理システムに相当する）において、その構成の一例を示すシステム構成図である。
【００１３】
図１に示すように、本配送システムでは、宅配便事業者が管理するデータベースサーバ１０１ａ、本配送システムで管理するデータベースサーバ１０１ｂ、宅配物を配送する配送人が配送時に携行するアプリケーションクライアント１０２ａ、1又は複数存在する荷受人が各自所有しているアプリケーションクライアント１０２ｂがワイドエリアネットワーク（ＷＡＮ）１０３、およびワイドエリアネットワーク（ＷＡＮ）１０４を介して接続されている。
【００１４】
配送人が携行するアプリケーションクライアント１０２ａには、データベースサーバ１０１ｂから取得した各荷受人の在宅状況が配送画面に表示される。なお、各荷受人の情報は配送人が配送する順序で並んでいる。
【００１５】
また、この荷受人の情報は、あくまでも再配送を抑止するシステムを利用している荷受人の情報に限られる。再配送を抑止するシステムとは、在宅状況を確認し在宅している荷受人にのみ配送するという本実施形態のシステムを指す。そのためこのシステムを利用しない、いわゆる従来の在宅状況の確認を行わない通常の配送を利用する荷受人の情報は表示しない。本実施形態では、再配送を抑止するシステムを利用する荷受人の在宅状況が取得できない場合に、在宅している荷受人にのみ配送する本システムの配送方法から、従来の通常の配送に荷物の配送方法を変更する内容について記載する。本実施形態では、本システムの配送方法で配送するよう荷物を管理するデータベース（配送リスト）と、通常の配送方法で配送するよう荷物を管理するデータベースとの間で、荷物の管理を変更することで配送方法の変更を実現する。
【００１６】
なお、ここでは従来の在宅状況の確認を行わない配送を「通常の配送」と称する。また、在宅状況を確認し在宅している荷受人にのみ配送する、再配送を抑止するシステムによる配送を「本システムの配送」と称するものとする。
【００１７】
荷受人が所有するアプリケーションクライアント１０２ｂは、データベースサーバ１０１ｂから受信する在宅確認の要求を受け取る。要求を受け取った後、アプリケーションクライアント１０２ｂは、アプリケーションクライアント１０２ｂが記憶する自宅住所とアプリケーションクライアント１０２ｂの現在地情報から、その２点間の距離を算出する。２点間の距離については、緯度と経度の情報を用いて、距離を算出する。アプリケーションクライアント１０２ｂは、算出した値が一定閾値の範囲内であれば在宅と判断し、一定閾値の範囲外であれば不在と判断し、その結果情報をデータベースサーバ１０１ｂへ送信する。
【００１８】
以上で、図１に示すシステム構成の説明を終了する。なお、本実施形態で説明したシステム構成は一例であって、用途や目的に応じて適宜変更されうるものである。
【００１９】
次に、図２を用いて、図１に示したデータベースサーバ１０１ａ、データベースサーバ１０１ｂ（位置情報取得可能な端末と通信可能な情報処理装置に相当する）のハードウェア構成について説明する。
【００２０】
図２に示すように、データベースサーバ１０１ａ及びデータベースサーバ１０１ｂは、システムバス２０４を介してＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）２０１、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）２０３、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）２０２、入力コントローラ２０５、ビデオコントローラ２０６、メモリコントローラ２０７、通信Ｉ／Ｆコントローラ２０８等が接続された構成を採る。
【００２１】
ＣＰＵ２０１は、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。
【００２２】
また、ＲＯＭ２０２あるいは外部メモリ２１１（記憶手段に相当する）には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ  Ｉｎｐｕｔ／Ｏｕｔｐｕｔ  Ｓｙｓｔｅｍ）やＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）や、各サーバあるいは各ＰＣが実行する機能を実現するために必要な後述する各種プログラム等が記憶されている。また、本発明を実施するために必要な情報が記憶されている。なお外部メモリはデータベースであってもよい。
【００２３】
ＲＡＭ２０３（記憶手段に相当する）は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＯＭ２０２あるいは外部メモリ２１１からＲＡＭ２０３にロードし、ロードしたプログラムを実行することで各種動作を実現する。
【００２４】
また、入力コントローラ２０５は、キーボード（ＫＢ）２０９や不図示のマウス等のポインティングデバイス等からの入力を制御する。
【００２５】
ビデオコントローラ２０６は、ディスプレイ２１０等の表示器への表示を制御する。尚、表示器は液晶ディスプレイ等の表示器でもよい。これらは、必要に応じて管理者が使用する。
【００２６】
メモリコントローラ２０７は、ブートプログラム、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、各種データ等を記憶する外部記憶装置（ハードディスク（ＨＤ））や、フレキシブルディスク（ＦＤ）へのアクセスを制御する。あるいは、メモリコントローラ２０７は、ＰＣＭＣＩＡ（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ  Ｍｅｍｏｒｙ  Ｃａｒｄ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ａｓｓｏｃｉａｔｉｏｎ）カードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）メモリ等の外部メモリ２１１（記憶手段に相当する）へのアクセスを制御する。
【００２７】
通信Ｉ／Ｆコントローラ２０８は、ネットワークを介して外部機器と接続・通信し、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）を用いた通信等が可能である。
【００２８】
尚、ＣＰＵ２０１は、例えばＲＡＭ２０３内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ディスプレイ２１０上に表示することが可能である。また、ＣＰＵ２０１は、ディスプレイ２１０上のマウスカーソル（図示しない）等によるユーザ指示を可能とする。
【００２９】
本発明を実現するための後述する各種プログラムは、外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０３にロードされることによりＣＰＵ２０１によって実行されるものである。
【００３０】
以上で図２に示すデータベースサーバ１０１ａ、データベースサーバ１０１ｂのハードウェア構成の説明を終了する。上記の構成は一例であって、目的や用途に応じて適宜変更されうる。
【００３１】
次に、図３を用いて、図１に示したアプリケーションクライアント１０２ａ、アプリケーションクライアント１０２ｂ、のハードウェア構成について説明する。
【００３２】
ＣＰＵ３０１は、システムバス３０４に接続される各デバイスやコントローラを統括的に制御する。
【００３３】
また、ＲＯＭ３０２あるいはフラッシュメモリ３１４には、ＣＰＵ３０１の制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ  Ｉｎｐｕｔ  ／  ＯｕｔｐｕｔＳｙｓｔｅｍ）やオペレーティングシステムプログラム（以下、ＯＳ）や、当該携帯端末が実行する機能を実現するために必要な、後述する各種プログラム等が記憶されている。ＲＡＭ３０３は、ＣＰＵ３０１の主メモリ、ワークエリア等として機能する。
【００３４】
ＣＰＵ３０１は、処理の実行に際して必要なプログラム等をＲＡＭ３０３にロードして、プログラムを実行することで各種動作を実現するものである。
【００３５】
また、入力コントローラ３０５は、タッチパネル３１０、マイク３１１、カメラ３１２からの入力を制御する。タッチパネル３１０からはユーザのタッチ操作に関する入力を制御し、マイク３１１からは音声の入力を制御し、カメラ３１２からは撮影された静止画、動画の入力を制御する。出力コントローラ３０６は、タッチパネル３１０、スピーカ３１３への出力を制御する。
【００３６】
タッチパネル３１０は、ユーザからのタッチ操作を検知すると共に、前述した出力コントローラ３０６から送られた映像を表示する。タッチパネル３１０は、表示器と位置入力装置とが一体となった部品である。複数の箇所に対するタッチ操作（以下、マルチタッチ）も検知可能である。
【００３７】
メモリコントローラ（ＭＣ）３０７は、ブートプログラム、ブラウザソフトウエア、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、各種データ等を記憶するフラッシュメモリ３１４へのアクセスを制御する。本実施形態においては、フラッシュメモリとして説明を行うが、ハードディスク（ＨＤ）やフレキシブルディスク（ＦＤ）或いはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるカード型メモリ等の記憶媒体であってもよい。
【００３８】
通信Ｉ／Ｆコントローラ３０９は、ネットワークを介して、外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いたインターネット通信等が可能である。
【００３９】
センサコントローラ３０８は、タブレット端末１０７が備えるセンサ３１５からの入力を制御する。タブレット端末１０７のセンサ３１５には様々なセンサが存在し、例えば方位センサ、加速度センサ、ＧＰＳ（Ｇｌｏｂａｌ  Ｐｏｓｉｔｉｏｎｉｎｇ  Ｓｙｓｔｅｍ）センサである。
【００４０】
尚、ＣＰＵ３０１は、例えばＲＡＭ３０３内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、タッチパネル３１０上での表示を可能としている。
【００４１】
本発明のアプリケーションクライアント１０２が後述する各種処理を実行するために用いられる各種プログラム等はフラッシュメモリ３１４に記録されており、必要に応じてＲＡＭ３０３にロードされることによりＣＰＵ３０１によって実行されるものである。さらに、本発明に係わるプログラムが用いる定義ファイルや各種情報テーブルはフラッシュメモリ３１４に格納されている。
【００４２】
以上で図３に示すアプリケーションクライアント１０２ａ、アプリケーションクライアント１０２ｂのハードウェア構成の説明を終了する。
【００４３】
次に、図４を用いて、本実施形態における各種装置の機能構成の一例を示す図について説明する。なお、データベースサーバ１０１ａとデータベースサーバ１０１ｂはそれぞれ同じ機能構成として、アプリケーションクライアント１０２ａとアプリケーションクライアント１０２ｂはそれぞれ同じ機能構成として説明する。そのため、データベースサーバ１０１ａとアプリケーションクライアント１０２ａの説明は省略する。
【００４４】
データベースサーバ１０１ｂは、記憶部４０１と、通信制御部４０２と、ステータス管理部４０３とを備える。
【００４５】
記憶部４０１は、荷受人の情報（ユーザ情報）や荷物の情報、各種データベースを記憶する機能である。記憶部４０１に記憶された情報は、適宜追加、更新される。
【００４６】
通信制御部４０２は、データベースサーバ１０１ｂと各種装置が通信するための機能部である。
【００４７】
ステータス管理部４０３は、荷受人が在宅となっているか不在となっているかの在宅状況のステータスを管理する機能部である。他に、荷物の配送状況や不在発生日の情報など、各種ステータスの状態と更新もステータス管理部で管理する。
【００４８】
アプリケーションクライアント１０２ｂは通信制御部４０４と、表示制御部４０５と、検知部４０６とを備える。
【００４９】
通信制御部４０４は、アプリケーションクライアント１０２ｂが各種装置と通信するための機能部である。例えば、荷受人の在宅状況をデータベースサーバ１０１ｂに送信する際にこの機能を用いて通信する。
【００５０】
表示制御部４０５は、アプリケーションクライアント１０２ｂのタッチパネル３１０に配送画面１８０１のような画面を表示するよう制御する機能部である。配送画面１８０１については後述する。
【００５１】
検知部４０６は、アプリケーションクライアント１０２ｂのタッチパネル３１０でユーザからのタッチ操作を検知するための機能部である。本実施形態では、アプリケーションクライアント１０２ｂはスマートフォンなどのタッチパネルを備えた携帯端末を示す。そのため検知部４０６ではタッチ操作を検知するが、ユーザからの指示を受け付けることができればタッチ操作ではなくキーボタンの押下による指示を受け付けてもよい。
【００５２】
以上で、各種装置の機能構成についての説明を終了する。
【００５３】
次に、図５から図１２のフローチャートを用いて配送方法切り替えの処理について説明する。
【００５４】
まず、図５のフローチャートを用いて本実施形態におけるシステム全体の流れについて説明を行う。図５のフローチャートは各装置が行うそれぞれの処理を示し、図５の処理の詳細については図６から図１２で後述する。
【００５５】
ステップＳ５０１では、アプリケーションクライアント１０２ａは、配送ルート生成処理を行う。アプリケーションクライアント１０２ａは、荷物の配送を行う配送業者の配送人が所持する携帯端末を示す。アプリケーションクライアント１０２ａから配送ルート生成処理を受け付けるとデータベースサーバ１０１ｂで配送ルート生成のための各種処理を行う。
【００５６】
ステップＳ５０２では、データベースサーバ１０１ｂはアプリケーションクライアント１０２ａから配送ルート生成要求を受け付け、配送ルート（配送リスト）生成のための荷受人情報のチェック処理を行う。荷受人情報のチェック処理とは、アプリケーションクライアント１０２ａから受け付けた配送ルートの荷受人の情報を抽出し、在宅確認を行うための処理を示す。
【００５７】
ステップＳ５０３とステップＳ５０４では、データベースサーバ１０１ｂとアプリケーションクライアント１０２ｂはステップＳ５０２でチェック処理を行った荷受人の在宅判断処理を行う。
【００５８】
ステップＳ５０５とステップＳ５０６、およびステップＳ５０７では、データベースサーバ１０１ｂとアプリケーションクライアント１０２ｂは、ステップＳ５０３とステップＳ５０４の在宅判断処理の結果をもとに配送ルートを生成する。そして当該配送ルートをアプリケーションクライアント１０２ａのタッチパネル３１０が表示し、配送の結果も当該タッチパネル３１０が受け付ける。さらにデータベースサーバ１０１ｂは、受け付けた配送の結果をもとに情報を更新して記憶する。また、データベースサーバ１０１ｂは、荷物の配送中もステップＳ５０７でアプリケーションクライアント１０２ｂと通信して在宅確認を行い、荷物の配送中もデータベースサーバ１０１ｂで情報を更新してアプリケーションクライアント１０２ａが表示する。配送ルートの生成から配送後の配送結果の受け付けまでをここでは配送処理と称する。
【００５９】
ステップＳ５０８では、データベースサーバ１０１ｂは、ステップＳ５０５とステップＳ５０６、およびステップＳ５０７の配送処理の結果をもとに不在もしくは在宅状況が確認できず配送できなかった荷物を本システムの配送から除外する。本システムの配送から除外された荷物は、所定の条件で通常の配送方法での配送に変更されてもよい。
【００６０】
次に、図６と図７のフローチャートを用いて配送ルート生成処理と荷受人情報チェック処理について説明する。
【００６１】
図６のステップＳ６０１では、アプリケーションクライアント１０２ａのＣＰＵ３０１は、配送人から荷物の配送ルートの選択を受け付ける。配送人は特定のエリアを担当することが多く、特定のエリアにおける配送ルートはあらかじめ設定されていることが多い。そのためアプリケーションクライアント１０２ａのＣＰＵ３０１は、表示制御部４０５の機能により当該配送ルートを表示するよう制御し、配送人から配送ルートの選択を受け付ける。
【００６２】
ステップＳ６０２では、アプリケーションクライアント１０２ａのＣＰＵ３０１は、ステップＳ６０１で選択した配送ルートを確定し、データベースサーバ１０１ｂへ選択した配送ルートの情報を送信する。この時、配送ルートは、配送ルートごとに一意となるルートＩＤを持っており、その情報も合わせて送信される。
【００６３】
ここで、図１３の仮配送順序１３０１について説明する。仮配送順序１３０１は配送人がステップＳ６０１で選択する配送ルートの詳細を示す。仮配送順序１３０１は配送ルートごとに識別するための一意のルートＩＤ１３０２、荷物の配送順序１３０３、荷受人のユーザＩＤ１３０４を含む。ステップＳ６０２では、ルートＩＤ１３０２がデータベースサーバ１０１ｂに送信される。なお、本実施形態の説明で用いる「ユーザ」は、以下荷受人のことを示す。
【００６４】
ステップＳ６０３では、データベースサーバ１０１ｂのＣＰＵ２０１は、アプリケーションクライアント１０２ａから送信されたルートＩＤ１３０２、および配送ルートの情報を受信する。
【００６５】
ステップＳ６０４では、データベースサーバ１０１ｂのＣＰＵ２０１は、該当する配送ルートと紐づいたルートＩＤ１３０２を用いて、仮配送順序を読み込む。図１３の仮配送順序１３０１の同一のルートＩＤ１３０２に紐づく配送順序１３０３の値は一意であり、配送順序１３０３の番号が小さいものから配送が行われることを意味している。また、同一のルートＩＤ１３０２は、同一の配送区域を表している。本ステップでの仮配送順序の読込とは、該当するルートＩＤ１３０２の配送順序１３０３およびユーザＩＤ１３０４を読み込むものである。
【００６６】
ステップＳ６０５からステップＳ６０９では、データベースサーバ１０１ｂのＣＰＵ２０１は、各荷受人の荷物情報チェック処理を行う。荷物情報チェック処理は、ステップＳ６０４で読み込んだ仮配送順序１３０１のユーザＩＤ１３０４ごとにステップＳ６０５からステップＳ６０９の処理を繰り替えす。
【００６７】
ステップＳ６０５では、データベースサーバ１０１ｂのＣＰＵ２０１は、ステップＳ６０４で読み込んだ仮配送順序１３０１からユーザＩＤ１３０４を１件取得する。
【００６８】
ステップＳ６０６では、データベースサーバ１０１ｂのＣＰＵ２０１は、ステップＳ６０５で取得したユーザＩＤ１３０４の荷物が図１４で示す荷物情報１４０１に存在するか否かを確認する。荷物情報とは、図１２で示すように荷物情報１４０１で管理されている。荷物が荷物情報１４０１に存在すると判定した場合にはステップＳ６０７に処理を進める。荷物が荷物情報１４０１に存在しないと判定した場合にはステップＳ６０９に処理を進める。
【００６９】
図１４の荷物情報１４０１は、荷物ごとに一意に割り振られる荷物ＩＤ１４０２、ユーザＩＤ１４０３、配送のステータスを示す配送ステータス１４０４で管理されている。配送ステータス１４０４において、配送開始前のステータスは０で示される。配送ステータス１４０４では、荷物を配送中のステータスは１で示し、荷受人が不在であり配送不可であれば２を格納する。配送ステータス１４０４で配送完了のステータスは３の値で示す。荷物が存在する場合は、荷物情報１４０１に該当ユーザＩＤ１４０３のレコードが存在する。
【００７０】
ステップＳ６０７では、データベースサーバ１０１ｂのＣＰＵ２０１は、ステップＳ６０６で確認した荷物情報１４０１の該当レコードにおいて、配送ステータス１４０４の値を確認する。このとき、配送ステータス１４０４の値が０もしくは２である場合は、まだ荷物の配送が行われていない状況である。配送ステータスの値が０もしくは２以外である場合は荷物の配送中か荷物の配送完了を示している。配送ステータス１４０４の値が０もしくは２の場合はステップＳ６０８へ進める。配送ステータスの値が０もしくは２以外の値であれば、ステップＳ６０９へ処理を進める。
【００７１】
ステップＳ６０８では、データベースサーバ１０１ｂのＣＰＵ２０１は、該当するユーザＩＤ１４０３を在宅確認リスト１６０１に追加する。在宅確認リスト１６０１とは、在宅の確認を実施するユーザのリストである。
【００７２】
図１６の在宅確認リスト１６０１は、荷受人の在宅確認情報を管理するデータテーブルの一例を示す。在宅確認リスト１６０１は、荷受人のユーザＩＤ１６０２、在宅か不在かを示す在宅フラグ１６０３、エラーステータス１６０４、および、宅配ボックス投函可能フラグ１６０５で構成されている。ユーザＩＤ１６０２はステップＳ６０８で書き込まれた荷物情報１４０１のユーザＩＤ１４０３と同じである。エラーステータス１６０４は、荷受人の在宅確認のためにデータベースサーバ１０１ｂがアプリケーションクライアント１０２ｂと通信した際のエラーのステータスを示す。宅配ボックス投函可能フラグ１６０５は、宅配ボックスに投函可能か否かを示す。ステップＳ６０８では、在宅確認リスト１６０１のユーザＩＤ１６０２に荷物情報１４０１のユーザＩＤ１４０３が格納される。なお、この段階では在宅フラグ１６０３、エラーステータス１６０４、および宅配ボックス投函可能フラグ１６０５には、値は入っていない。
【００７３】
ステップＳ６０９では、データベースサーバ１０１ｂのＣＰＵ２０１は、該当するユーザＩＤ１４０３は在宅確認リストに追加せず、処理を進める。なお、ステップＳ６０４の仮配送順序１３０１に存在するユーザＩＤ１３０４分のユーザは通常複数存在する。そのため未処理のユーザＩＤ１３０４が存在している場合は、次のユーザＩＤ１３０４に対してもステップＳ６０５から同様の処理を実施する。つまり、仮配送順序１３０１に存在するユーザＩＤ１３０４の数分、同様の処理を繰り返す。
【００７４】
次に、図７を用いて各ユーザのアプリケーションステータスのチェック処理を行う。尚、図７は図６の各荷受人の荷物情報チェック処理の続きである
アプリケーションステータスとは、図１５で示すようにアプリケーションステータス１５０１で管理されている。アプリケーションステータス１５０１は、ユーザＩＤ１５０２、アプリケーション状態１５０３、通常配送切り替え閾値１５０４、不在発生日１５０５、休暇開始日１５０６、および休暇終了日１５０７で構成されている。休暇開始日１５０６から休暇終了日１５０７の期間は、荷受人からあらかじめ受け付けた不在期間であり、アプリケーションクライアント１０２ｂで設定を受け付ける（受付手段）。このアプリケーション状態１５０３がＦＡＬＳＥとなったユーザは、通常の配送に切り替わった状態を意味する。通常配送切り替え閾値１５０４は、本システムの配送から通常の配送に切り替える閾値となる日数を示す。通常配送切り替え閾値１５０４は、荷受人が任意にアプリケーションクライアント１０２ｂで設定できるものとする。
【００７５】
ステップＳ７０１では、データベースサーバ１０１ｂのＣＰＵ２０１は、在宅確認リスト１６０１のユーザＩＤ１６０２からユーザＩＤを１件抽出する。
【００７６】
ステップＳ７０２では、データベースサーバ１０１ｂのＣＰＵ２０１は、アプリケーションステータス１５０１から該当するユーザＩＤ１５０２のアプリケーション状態１５０３を取得する。
【００７７】
ステップＳ７０３では、データベースサーバ１０１ｂのＣＰＵ２０１は、ステップＳ７０２で取得したアプリケーション状態１５０３の値を確認し、アプリケーション状態１５０３はＴＲＵＥか否かを判定する。データベースサーバ１０１ｂのＣＰＵ２０１は、アプリケーション状態１５０３がＴＲＵＥの場合はステップＳ７０４へ進み、アプリケーション状態１５０３がＦＡＬＳＥである場合は、ステップＳ７０５へ進む。
【００７８】
ステップＳ７０４では、データベースサーバ１０１ｂのＣＰＵ２０１は、該当するユーザＩＤ１５０２は本システムを利用して配送を行う荷受人であると判定し、在宅確認リスト１６０１からユーザＩＤ１６０２を削除せず、処理を進める。
【００７９】
ステップＳ７０５では、データベースサーバ１０１ｂのＣＰＵ２０１は、該当するユーザＩＤ１５０２は本システムを利用せず、通常の配送のシステムを利用する荷受人であると判定し、在宅確認リストからユーザＩＤ１６０２を削除する。
【００８０】
なお、アプリケーションステータス１５０１のチェックは、在宅確認リスト１６０１に存在するユーザＩＤ１６０２の数分だけ、ステップＳ７０１から同様の処理を繰り返す。全てのユーザＩＤ１６０２に対して処理が終了すると、宅配ボックスフラグのチェックを行うため、ステップＳ７０６へ進む。
【００８１】
ステップＳ７０６からステップＳ７０８では、宅配ボックスフラグチェック処理を行う。宅配ボックスフラグチェック処理は、宅配ボックスに荷物を預けてよいかのフラグが設定されているか否かを判定する。
【００８２】
ステップＳ７０６では、データベースサーバ１０１ｂのＣＰＵ２０１は、在宅確認リスト１６０１のユーザＩＤ１６０２からユーザＩＤを取得する。
【００８３】
ステップＳ７０７では、データベースサーバ１０１ｂのＣＰＵ２０１は、取得したユーザＩＤ１６０２を元に、図１７で示すユーザリスト１７０１を検索する。
【００８４】
ここで、図１７について説明する。図１７のユーザリスト１７０１は、荷受人のユーザ情報が管理されたテーブルである。ユーザリスト１７０１は、ユーザＩＤ１７０２、ユーザの姓名を示す氏名１７０３、ユーザの郵便番号１７０４、ユーザの住所１７０５、および宅配ボックス投函可能か否かを示す宅配ボックス投函可能フラグ１７０６で構成されている。ステップＳ７０７では、ユーザリスト１７０１内のユーザＩＤ１７０２から、取得ていたユーザＩＤ１６０２に該当するユーザＩＤ１７０２を見つけ出し、当該ユーザＩＤ１７０２の宅配ボックス投函可能フラグ１７０６を抽出する。
【００８５】
ステップＳ７０８では、データベースサーバ１０１ｂのＣＰＵ２０１は、ステップＳ７０７で抽出した宅配ボックス投函可能フラグ１７０６を、在宅確認リスト１６０１の該当ユーザＩＤ１６０２のレコードに書き込む。つまり、データベースサーバ１０１ｂのＣＰＵ２０１は、ステップＳ７０７で抽出した結果を宅配ボックス投函可能フラグ１６０５に書き込む。
【００８６】
なお、宅配ボックス投函可能フラグのチェックは、在宅確認リスト１６０１に存在するユーザＩＤ１６０２の数分だけ、ステップＳ７０６から同様の処理を繰り返す。全てのユーザＩＤ１６０２に対して処理が終了すると、次の処理へ進む。
【００８７】
次に図８で在宅確認リスト１６０１に存在するユーザＩＤ１６０２に対して、実際に在宅確認処理を行う。
【００８８】
ステップＳ８０１では、データベースサーバ１０１ｂのＣＰＵ２０１は、在宅確認リスト１６０１からユーザＩＤ１６０２を取得する。
【００８９】
ステップＳ８０２では、データベースサーバ１０１ｂのＣＰＵ２０１は、ステップＳ８０１で取得したユーザＩＤ１６０２の在宅確認リストの在宅フラグ１６０３にＯＦＦを初期値として設定し、さらにエラーステータス１６０４に１を初期値として設定する。
【００９０】
ステップＳ８０３では、データベースサーバ１０１ｂのＣＰＵ２０１は、荷受人が各自所有しているアプリケーションクライアント１０２ｂに対して、在宅確認通知を送信する。
【００９１】
ステップＳ８０４では、アプリケーションクライアント１０２ｂのＣＰＵ３０１は、在宅判断の処理が実施される。ステップＳ８０４では、データベースサーバ１０１ｂから在宅確認通知を受信したかの判断を行う。アプリケーションクライアント１０２ｂのＣＰＵ３０１は、在宅確認通知を受信したと判定した場合はステップＳ８０５へ進み、在宅確認通知が受信できなかったと判定した場合は、在宅判断の処理を終了する。在宅確認通知が受信できない場合は、例えば、アプリケーションクライアント１０２ｂの電源がＯＦＦになっていた場合や、アプリケーションクライアント１０２ｂを持つ荷受人が、ワイドエリアネットワーク（ＷＡＮ）の届かない地域にいる場合などが考えられる。
【００９２】
ステップＳ８０５では、アプリケーションクライアント１０２ｂのＣＰＵ３０１は、アプリケーションクライアント１０２ｂのＧＰＳ機能を利用して、現在地の情報を取得する。取得した現在地と、荷受人が登録した住所と突合し、その２点間の距離が一定値以内であれば、在宅と判断し、それ以外の場合は不在と判断する。なお、荷受人が登録した住所は、ユーザリスト１７０１内の住所１７０５と同じ値である。
【００９３】
ステップＳ８０６では、アプリケーションクライアント１０２ｂのＣＰＵ３０１は、在宅フラグとエラーステータスをデータベースサーバ１０１ｂへ送信する。ここで、在宅フラグ１６０３は、ステップＳ８０５で在宅と判断した場合はＯＮに設定され、不在と判断した場合はＯＦＦと設定される。また、エラーステータス１６０４は、正常に位置情報が取れた場合は０に設定され、アプリケーションクライアント１０２ｂの設定が起因して位置情報が取得できなかった場合は２に設定され、それ以外で位置情報が取れなかった場合は３に設定される。
【００９４】
ステップＳ８０７では、データベースサーバ１０１ｂのＣＰＵ２０１は、ステップＳ８０３の処理を実施後、アプリケーションクライアント１０２ｂからの応答を受けるまで一定時間待機する。アプリケーションクライアント１０２ｂから応答を受ける、もしくはアプリケーションクライアント１０２ｂから応答を受ける前に一定時間経過してしまった場合に、データベースサーバ１０１ｂのＣＰＵ２０１は、ステップＳ８０８へ進む。
【００９５】
ステップＳ８０８では、データベースサーバ１０１ｂのＣＰＵ２０１は、アプリケーションクライアント１０２ｂから応答があったか否かを判断する。データベースサーバ１０１ｂのＣＰＵ２０１は、応答があったと判定した場合にステップＳ８０９へ処理を進め、応答が無かったと判定した場合は、次のユーザＩＤ１６０２の在宅確認を判断するため、ステップＳ８０１に戻る。なお、在宅確認リスト１６０１内の全てのユーザＩＤ１６０２の在宅確認を実施するまで、同様の処理を繰り返す。
【００９６】
ステップＳ８０９では、データベースサーバ１０１ｂのＣＰＵ２０１は、アプリケーションクライアント１０２ｂから応答を受けた在宅フラグ１６０３とエラーステータス１６０４を受信する。
【００９７】
ステップＳ８１０では、データベースサーバ１０１ｂのＣＰＵ２０１は、ステップＳ８０９で取得した在宅フラグ１６０３とエラーステータス１６０４を該当ユーザＩＤ１６０２のレコードに書き込む。なお、ステップＳ８０２で、これらの値は既に初期値の設定が行われているため、本ステップでの処理は更新処理となる。ステップＳ８１０の処理が終了すると、次のユーザＩＤ１６０２の在宅確認を判断するため、データベースサーバ１０１ｂのＣＰＵ２０１は、ステップＳ８０１に戻る。この処理は、在宅確認リスト１６０１内の全てのユーザＩＤ１６０２の在宅確認が完了するまで繰り返し実施される。
【００９８】
次に図９から図１１を用いてデータベースサーバ１０１ｂとアプリケーションクライアント１０２ｂの配送処理についての一連の流れを説明する。
【００９９】
図９は、配送処理のうち、配送人が持つアプリケーションクライアント１０２ａに表示する配送画面１８０１の生成処理に関して記載する。
【０１００】
ステップＳ９０１では、データベースサーバ１０１ｂのＣＰＵ２０１は、データベースサーバ１０１ｂの記憶部４０１で記憶している在宅確認リスト１６０１の情報をアプリケーションクライアント１０２ａに送信する。
【０１０１】
ステップＳ９０２では、アプリケーションクライアント１０２ｂのＣＰＵ３０１は、データベースサーバ１０１ｂから送信された在宅確認リスト１６０１の情報を受信する。
【０１０２】
ステップＳ９０３では、アプリケーションクライアント１０２ｂのＣＰＵ３０１は、データベースサーバ１０１ｂから受信した在宅確認リスト１６０１の情報を用いて、配送画面の生成処理を開始する。
【０１０３】
ステップＳ９０４では、アプリケーションクライアント１０２ｂのＣＰＵ３０１は、在宅確認リスト１６０１でエラーステータス１６０４が０以外、かつ宅配ボックス投函可能フラグがＯＦＦのユーザについては、識別表示する。具体的には、アプリケーションクライアント１０２ｂのＣＰＵ３０１は、配送が不可である荷受人の表示に関しては、背景がグレー（グレーアウト表示）の不在表示１８０９として表示する。つまり、アプリケーションクライアント１０２ｂのＣＰＵ３０１は、在宅確認が取れない、もしくは荷受人が不在であり、宅配ボックス投函不可である荷受人をグレーアウト表示させる。なお、グレーアウト表示は不在を示す表示形態の一例であり、不在とわかるように識別可能に表示されていればよい。
【０１０４】
ここで、図１８に示す配送画面の一例について説明する。図１８に示す配送画面１８０１は、配送区域の住所１８０２、配送順序１８０３、荷受人の氏名１８０４、荷受人の住所１８０５、在宅状況を示すアイコン１８０６、宅配ボックス投函可能を示すアイコン１８０７を備える。また、配送画面１８０１は、配送が可能であるか否かを、配送が可能であることを示す背景が白色の在宅表示１８０８と、配送が不可であることを示す背景がグレーの不在表示１８０９とで表示する。さらに、配送画面１８０１は、配送人が配送開始時に押下する配送開始ボタン１８１０、配送後の結果として配送人が押下する完了ボタン１８１１、および配送後の結果として配送人が押下する不在ボタン１８１２で構成されている。不在表示１８０９については、配送開始ボタン１８１０を押下する前であれば、配送画面１８０１から削除することが可能であり、配送人が今回の配送において、その荷受人へは配送を行わないことを示唆するものである。また、配送中にも荷受人の在宅確認はデータベースサーバ１０１ｂとアプリケーションクライアント１０２ｂとで通信して行われる。不在であり配送不可と表示されていた不在表示１８０９も配送可能と情報が更新された場合には在宅表示１８０８に表示が変更される。配送中の在宅確認処理と配送画面１８０１の表示の更新については後述する。なお、在宅表示１８０８の背景を白色で表すのは表示の一例であり、荷受人が在宅であることが分かる表示であればどの表示の方法であってもよい。
【０１０５】
ステップＳ９０５では、アプリケーションクライアント１０２ｂのＣＰＵ３０１は、ステップＳ９０４でグレーアウト表示した不在表示１８０９を配送画面１８０１から削除するか否かを判定する。配送画面１８０１で配送人からの削除指示を受け付け、不在表示１８０９を削除すると判定した場合、アプリケーションクライアント１０２ｂのＣＰＵ３０１は、ステップＳ９０６へ処理を進める。アプリケーションクライアント１０２ｂのＣＰＵ３０１は、不在表示１８０９を削除すると判定しなかった場合は、ステップＳ９０７へ処理を進める。
【０１０６】
ステップＳ９０６では、アプリケーションクライアント１０２ｂのＣＰＵ３０１は、ステップＳ９０５で削除すると判定された該当ユーザＩＤ１６０２を不図示の配送非実施リストに格納する。なお、削除されたユーザＩＤ１６０２は複数件存在する可能性があり、その場合、削除された全てのユーザＩＤ１６０２が配送非実施リストに格納される。アプリケーションクライアント１０２ｂのＣＰＵ３０１は、削除したユーザＩＤ１６０２の情報は、配送画面１８０１に表示しない。
【０１０７】
ステップＳ９０７では、アプリケーションクライアント１０２ｂのＣＰＵ３０１は、配送開始ボタン１８１０の押下を検知し、配送内容を確定する。
【０１０８】
ステップＳ９０８では、アプリケーションクライアント１０２ｂのＣＰＵ３０１は、配送非実施リストと配送開始の通知をデータベースサーバ１０１ｂへ通知する。ステップＳ９０５で、削除されたリストが存在しない場合は、配送非実施リストに情報は存在しないため、この場合は空の配送非実施リストを送信する。
【０１０９】
ステップＳ９０９では、データベースサーバ１０１ｂのＣＰＵ２０１は、アプリケーションクライアント１０２ａから配送非実施リストと配送開始の通知を受信する。
【０１１０】
次に、ステップＳ９１０からステップＳ９１６では、配送非実施リストを利用して各荷受人の荷物情報確認処理を実施する処理の一連の流れを説明する。各荷受人の荷物情報確認処理では、荷受人の荷物情報の確認と不在発生日をセットする処理を実施する。
【０１１１】
ステップＳ９１０では、データベースサーバ１０１ｂのＣＰＵ２０１は、在宅確認リスト１６０１からユーザＩＤ１６０２を１件取得する。
【０１１２】
ステップＳ９１１では、データベースサーバ１０１ｂのＣＰＵ２０１は、ステップＳ９１０のユーザＩＤ１６０２を利用して、荷物情報１４０１からユーザＩＤ１６０２に対応する該当ユーザＩＤ１４０３の荷物ＩＤ１４０２を抽出する。また、合わせて配送ステータス１４０４の内容も確認し、配送ステータスが０もしくは２の値のみを抽出する。配送ステータスが０もしくは２の値を持つ荷物は、配送ステータスが配送開始前、もしくは配送不可（不在）となっている荷物である。なお、配送ステータスが１や３の内容は、既に配送が行われている荷物や、既に配送が終了している荷物であり、本ステップで抽出しない。
【０１１３】
ステップＳ９１２では、データベースサーバ１０１ｂのＣＰＵ２０１は、ステップＳ９１１で抽出した荷物情報の配送ステータスを１に変更する。つまり、これから配送へ行うことを示唆するステータスに変更する。
【０１１４】
ステップＳ９１３では、データベースサーバ１０１ｂのＣＰＵ２０１は、ステップＳ９１０で抽出したユーザＩＤ１４０３に対応するユーザが配送非実施リストに存在するか否かを確認する。データベースサーバ１０１ｂのＣＰＵ２０１は、該当するユーザＩＤ１４０３に対応するユーザが配送非実施リストに存在すると判定した場合は、ステップＳ９１４へ処理を進める。データベースサーバ１０１ｂのＣＰＵ２０１は、該当するユーザＩＤ１４０３に対応するユーザが配送非実施リストに存在しないと判定した場合はステップＳ９１０へ処理を戻す。ステップＳ９１０に処理を戻した場合は、データベースサーバ１０１ｂのＣＰＵ２０１は、在宅確認リスト１６０１から次のユーザＩＤ１６０２を抽出し、同様の処理を実施する。なお、在宅確認リスト１６０１の全てのユーザＩＤ１６０２に対して、同様の処理が実施される。
【０１１５】
ステップＳ９１４では、データベースサーバ１０１ｂのＣＰＵ２０１は、ステップＳ１００２で抽出した荷物ＩＤ１４０２に対して、配送ステータスを１から２に変更する。この処理は、該当するユーザが配送非実施リストに存在し、今回の配送タイミングで配送が実施されないためである。
【０１１６】
ステップＳ９１５では、データベースサーバ１０１ｂのＣＰＵ２０１は、アプリケーションステータス１５０１を確認し、ユーザＩＤ１４０３に対応するユーザＩＤ１５０２の不在発生日１５０５に日付が入っているか否かを確認する。不在発生日１５０５に日付が入っていない場合は、データベースサーバ１０１ｂのＣＰＵ２０１は、ステップＳ９１６へ処理を進める。不在発生日１５０５に日付が入っている場合は、アプリケーションクライアント１０２ｂのＣＰＵ３０１は、ステップＳ９１０へ戻り、在宅確認リスト１６０１内の全てのユーザＩＤ１６０２に対して同様の処理を繰り返す。
【０１１７】
ステップＳ９１６では、データベースサーバ１０１ｂのＣＰＵ２０１は、該当するユーザＩＤ１５０２の不在発生日１５０５に現在の日付を書き込む。その後、データベースサーバ１０１ｂのＣＰＵ２０１は、ステップＳ９１０へ戻り、データベースサーバ１０１ｂのＣＰＵ２０１は、在宅確認リスト１６０１内の全てのユーザＩＤ１６０２に対して同様の処理を繰り返す。データベースサーバ１０１ｂのＣＰＵ２０１は、全てのユーザＩＤ１６０２に対して同様の処理を繰り返した後、次の処理へ進む。
【０１１８】
なお、この配送画面１８０１は、配送人が配送を開始した後、配送人が配送を行っている最中においても、宅配物をまだ届けていない荷受人の在宅状況は都度確認が行われる。そして確認された荷受人の在宅状況は、アプリケーションクライアント１０２ａの配送画面１８０１に反映されて表示される。従って、配送人はこれから荷物を届ける荷受人が在宅しているか否かを配送中にも知りうることが可能となる。言い換えると、配送人は、常に最新の在宅状況が反映された配送画面をアプリケーションクライアント１０２a上で確認することができる。
【０１１９】
次に図１１で、配送人が実際に配送を行う際の、配送画面１８０１に基づいた配送ステータス更新処理に関して記載する。この場合においても、ユーザのアプリケーションステータス１５０１の不在発生日１５０５に日付が設定されるケースがある。
【０１２０】
ステップＳ１００１では、アプリケーションクライアント１０２ａのＣＰＵ３０１は、配送画面１８０１に表示されている荷受人のユーザＩＤ１６０２を１件抽出する。
【０１２１】
ステップＳ１００２では、アプリケーションクライアント１０２ａのＣＰＵ３０１は、ステップＳ１００１で抽出したユーザＩＤ１６０２のリストに対して完了ボタン１８１１が押下されたか否かを判定する。配送人は、アプリケーションクライアント１０２ａに表示される配送画面１８０１に従い配送を行う。配送画面１８０１のグレーの不在表示１８０９で示す荷受人は、不在、もしくは在宅確認が行えていない荷受人を示すため配送が行えない状態となっている。配送画面１８０１に示す荷受人に配送が行われた場合は、配送人から完了ボタン１８１１の押下を受け付ける。完了ボタン１８１１の押下を受け付けた場合はステップＳ１００３へ進み、一方で配送が行われず完了ボタン１８１１の押下を受け付けなかった場合はステップＳ１００４へ処理を進める。尚、ここでは、宅配ボックスへの荷物の投函は配送したとみなす。また、配送画面１８０１の在宅表示１８０８で示すユーザには基本的に配送を行うことができる。しかしながら、在宅確認後の配送直前に荷受人が不在となった場合や、荷受人が呼び出しに応じない場合など荷受人の何らかの事由により配送が行えなかった場合も、ステップＳ１００４に処理を進める。
【０１２２】
ステップＳ１００３では、アプリケーションクライアント１０２ａのＣＰＵ３０１は、配送情報として「完了」が設定され記憶される。
【０１２３】
ステップＳ１００４では、アプリケーションクライアント１０２ａのＣＰＵ３０１は、配送画面１８０１で不在ボタン１８１２の押下を受け付け、配送情報として「不在」が設定され記憶される。
【０１２４】
ステップＳ１００５では、アプリケーションクライアント１０２ａのＣＰＵ３０１は、ステップＳ１００３もしくはステップＳ１００４で設定され記憶された配送情報と、ステップＳ１００１で抽出したユーザIＤ１６０２をデータベースサーバ１０１ｂへ送信する。
【０１２５】
ステップＳ１００６では、データベースサーバ１０１ｂのＣＰＵ２０１は、アプリケーションクライアント１０２ａから送信されたユーザＩＤ１６０２と配送情報を受信する。
【０１２６】
ステップＳ１００７では、データベースサーバ１０１ｂのＣＰＵ２０１は、受信したユーザＩＤ１６０２の配送情報が完了か否かを確認し、完了である場合は、ステップＳ１１０８へ進み、不在である場合は、ステップＳ１０１０へ進む。
【０１２７】
ステップＳ１００８では、データベースサーバ１０１ｂのＣＰＵ２０１は、当該ユーザＩＤ１６０２の荷物情報１４０１の配送ステータス１４０４を、配送完了を示す３に変更する。
【０１２８】
ステップＳ１００９では、データベースサーバ１０１ｂのＣＰＵ２０１は、当該ユーザＩＤ１６０２の荷受人に配送が実施できたため、当該ユーザＩＤ１６０２のアプリケーションステータス１５０１の不在発生日１５０５を空にする。つまり、配送ができたタイミングで、不在発生日１５０５はリセットされる。
【０１２９】
ステップＳ１０１０では、データベースサーバ１０１ｂのＣＰＵ２０１は、当該ユーザＩＤ１６０２の荷物情報１４０１の配送ステータス１４０４を、配送ができなかったことを示す２に変更する。
【０１３０】
ステップＳ１０１１では、データベースサーバ１０１ｂのＣＰＵ２０１は、荷受人に配送が実施できなかったため、当該ユーザＩＤ１６０２のアプリケーションステータス１５０１の不在発生日１５０５に日付を書き込む。しかしながら、ここでは、既に不在発生日１５０５に日付が入っているか確認する。不在発生日１５０５に日付が入っていない場合は、ステップＳ１０１２へ進み、日付が入っている場合は、不在発生日１５０５の内容は変更を行わず、ステップＳ１０１３に処理を進める。
【０１３１】
ステップＳ１０１２では、データベースサーバ１０１ｂのＣＰＵ２０１は、該当ユーザＩＤ１６０２のアプリケーションステータス１５０１の不在発生日１５０５に日付を書き込む処理を実施する。
【０１３２】
ステップＳ１００６からステップＳ１０１２までの処理は配送人が配送処理を行った結果を登録する処理を示す。次のステップＳ１０１３から図１１のステップＳ１１１７までの処理は、荷物の配送中に直近に配送する荷受人の在宅確認を行い配送画面１８０１の表示に反映させる処理である。
【０１３３】
ステップＳ１０１３では、データベースサーバ１０１ｂのＣＰＵ２０１は、アプリケーションクライアント１０２ａから送信され、ステップＳ１００６で受信したユーザＩＤ１６０２を取得する。
【０１３４】
ステップＳ１０１４では、データベースサーバ１０１ｂのＣＰＵ２０１は、在宅確認リスト１６０１から該当するユーザＩＤ１６０２を探索し、該当するレコード番号（テーブルの上から数えた順序）を変数Ｒにセットする。この変数Ｒは、在宅確認を実施するユーザ情報を抽出する際に利用する値となる。
【０１３５】
ステップＳ１０１５では、データベースサーバ１０１ｂのＣＰＵ２０１は、在宅確認を実施したユーザ数をカウントするための変数Ｉに、Ｉ＝０をセットする。
【０１３６】
ステップＳ１０１６では、データベースサーバ１０１ｂのＣＰＵ２０１は、在宅確認リスト１６０１の次のレコード番号のユーザには、在宅確認を実施しないので、Ｒに１を加算する。
【０１３７】
以上で、図１０についての説明を終了する。
【０１３８】
次に、図１１を用いて図１０の続きの処理について説明する。
【０１３９】
ステップＳ１１０１では、データベースサーバ１０１ｂのＣＰＵ２０１は、在宅確認リスト１６０１のさらに次のレコード番号のユーザから在宅確認を実施するため、Ｒに１を加算する。
【０１４０】
ステップＳ１１０２では、データベースサーバ１０１ｂのＣＰＵ２０１は、在宅確認リスト１６０１から、変数Ｒに該当するユーザＩＤ１６０２を抽出する。
【０１４１】
ステップＳ１１０３では、データベースサーバ１０１ｂのＣＰＵ２０１は、ステップＳ１１０２で取得したユーザＩＤ１６０２が、配送非実施リストに存在するか確認する。ユーザＩＤ１６０２が配送非実施リストに存在する場合は、在宅確認を実施する必要が無いユーザであるため、ステップＳ１１０１へ戻る。一方、配送非実施リストに存在しない場合は、ステップＳ１１０４へ進む。
【０１４２】
ステップＳ１１０４では、データベースサーバ１０１ｂのＣＰＵ２０１は、該当するユーザＩＤ１６０２の在宅フラグ１６０３をＯＦＦ、エラーステータス１６０４に１を設定する。
【０１４３】
ステップＳ１１０５では、データベースサーバ１０１ｂのＣＰＵ２０１は、荷受人が各自所有しているアプリケーションクライアント１０２ｂに対して、在宅確認通知を送信する。
【０１４４】
ステップＳ１１０６では、アプリケーションクライアント１０２ｂでは、在宅判断の処理が実施される。ステップＳ１１０６では、データベースサーバ１０１ｂから在宅確認通知を受信したか判断を行う。在宅確認通知を受信した場合は、ステップＳ１１０７へ進み、在宅確認通知が受信できなかった場合は、在宅判断の処理を終了する。
【０１４５】
なお、在宅確認通知が受信できない場合は、例えばアプリケーションクライアント１０２ｂの電源がＯＦＦになっていた場合や、アプリケーションクライアント１０２ｂを持つ荷受人がワイドエリアネットワーク（ＷＡＮ）の届かない地域にいる場合が考えられる。
【０１４６】
ステップＳ１１０７では、アプリケーションクライアント１０２ｂのＣＰＵ３０１は、アプリケーションクライアント１０２ｂの位置情報取得機能を利用して、現在地の情報を取得する。アプリケーションクライアント１０２ｂは、例えばＧＰＳの機能を用いて自身の現在位置を取得する。位置情報はＧＰＳの機能に限らず、ＷｉＦｉやＢｌｕｅｔｏｏｔｈ（登録商標）などの無線通信、モバイルネットワークなどの様々な情報を利用して特定され、該特定された位置情報をアプリケーションクライアント１０２ｂが取得してもよい。取得した現在地と、荷受人が登録した住所を突合し、その２点間の距離が一定値以内であれば、在宅と判断し、それ以外の場合は不在と判断する。なお、荷受人が登録した住所は、ユーザリスト１７０１内の住所１７０５と同じ値である。
【０１４７】
ステップＳ１１０８では、アプリケーションクライアント１０２ｂのＣＰＵ３０１は、ステップＳ１１０７で在宅と判断した場合は在宅フラグがＯＮを、不在と判断した場合は在宅フラグＯＦＦをデータベースサーバ１０１ｂへ送信する。また、その状況に応じたエラーステータス１６０４も合わせて、データベースサーバ１０１ｂへ送信する。このエラーステータス１６０４は、正常に位置情報が取れた場合は０、アプリケーションクライアント１０２ｂの設定が起因して位置情報が取得できなかった場合は２、それ以外で位置情報が取れなかった場合は３が設定されるものとする。
【０１４８】
ステップＳ１１０９では、データベースサーバ１０１ｂのステップＳ１１０９では、ステップＳ１１０５の処理を実施後、アプリケーションクライアント１０２ｂからの応答を一定時間待機する。アプリケーションクライアント１０２ｂから応答を受ける、もしくはアプリケーションクライアント１０２ｂから応答を受ける前に一定時間経過してしまった場合に、ステップＳ１１１０へ進む。
【０１４９】
ステップＳ１１１０では、データベースサーバ１０１ｂのＣＰＵ２０１は、アプリケーションクライアント１０２ｂから応答があったか否かを判断し、応答があった場合にステップＳ１１１１へ進む。アプリケーションクライアント１０２ｂから応答が無かった場合は、在宅フラグ１６０３とエラーステータス１６０４の更新を行わないため、ステップＳ１１１３へ進む。
【０１５０】
ステップＳ１１１１では、データベースサーバ１０１ｂのＣＰＵ２０１は、アプリケーションクライアント１０２ｂから応答を受けた在宅フラグと１６０３エラーステータス１６０４を受信する。
【０１５１】
ステップＳ１１１２では、データベースサーバ１０１ｂのＣＰＵ２０１は、ステップＳ１１１０で取得した在宅フラグ１６０３とエラーステータス１６０４を該当ユーザのレコードに書き込む。なお、ステップＳ１１０４でこれらの値は既に設定が行われているため、本ステップでの処理は更新処理となる。
【０１５２】
ステップＳ１１１３では、データベースサーバ１０１ｂのＣＰＵ２０１は、ユーザに対して在宅確認を実施したので、在宅確認を実施したユーザ数を表す変数Ｉに１を加算する。
【０１５３】
ステップＳ１１１４では、データベースサーバ１０１ｂのＣＰＵ２０１は、ユーザＩＤ１６０２と在宅フラグ１６０３をアプリケーションクライアント１０２ａに送信し、またステップＳ１１０１に戻ってステップＳ１１０１からステップＳ１１１４を繰り返す。なお、ステップＳ１１０１からステップＳ１１１４の処理は、変数Ｉが３以上、もしくは変数Ｒが在宅確認リスト１６０１の最後のレコード番号になるまで繰り返される。本実施形態では、データベースサーバ１０１ｂのＣＰＵ２０１は、配送の完了を受け付けた荷受人の２つ先の荷受人から３人目までの荷受人の在宅確認を行っている。そのため変数Ｉが３以上であった場合は直近配送の荷受人への在宅確認処理を終了する。なお、一例として２つ先の荷受人から３人目までの荷受人の在宅確認を行っているが、在宅確認リスト１６０１のどの範囲の荷受人まで在宅確認を行うかは任意に設定できてよい。
【０１５４】
ステップＳ１１１５では、アプリケーションクライアント１０２ａは、ユーザＩＤ１６０２と在宅フラグ１６０３をデータベースサーバ１０１ｂから受信する。
【０１５５】
ステップＳ１１１６では、アプリケーションクライアント１０２ａは、ステップＳ１１１５で受信した該当ユーザＩＤ１６０２の在宅フラグ１６０３に変更があるか否かを判定する。変更があると判定した場合はステップＳ１１１７に処理を進める。該当ユーザＩＤ１６０２の在宅フラグ１６０３に変更がないと判定した場合は配送画面１８０１の表示の変更を行わないため、一連の処理を終了する。
【０１５６】
ステップＳ１１１７では、アプリケーションクライアント１０２ａは、ステップＳ１１１６で該当ユーザＩＤ１６０２の在宅フラグ１６０３の変更があると判定した場合に、変更に応じて図１８の配送画面１８０１の表示を変更する。在宅フラグ１６０３がＯＦＦからＯＮに変更されればグレーアウト表示から通常の白色の表示に変更する。在宅フラグ１６０３がＯＮからＯＦＦへの変更があれば、通常の白色表示から該当するユーザのリストをグレーアウト表示する。
【０１５７】
以上により、荷物の配送中に直近に配送する荷受人の在宅確認を行い配送画面１８０１の表示に反映させる処理の説明を終了する。この処理により、荷物の配送中であっても配送人がリアルタイムに配送画面１８０１で荷受人の在宅情報を容易に確認可能となる。
【０１５８】
また、本実施形態では、荷物の配送中に配送予定のすべての荷受人の在宅確認を行うのではなく、一部の荷受人に在宅確認を行っている。配送予定のすべての荷受人に所定のタイミングで在宅確認を行ってもよいが、一部の荷受人に在宅確認を行うことにより、通信負荷の低減と在宅確認の効率を上げる効果を奏する。
【０１５９】
次に図１２は、夜間バッチ処理などを利用して、データベースサーバ１０１ｂのＣＰＵ２０１が荷受人への荷物の配送を本システムの配送から通常の配送に変更する処理に関して記載する。データベースサーバ１０１ｂのＣＰＵ２０１は、図１５の不在発生日１５０５に格納された情報を用いて、配送が行われなかった期間を算出することが可能となる。通常配送切り替え閾値１５０４に示される閾値は、通常の配送に切り替える判断に用いるものであり、当該閾値以上荷受人の不在を確認した場合は、データベースサーバ１０１ｂのＣＰＵ２０１が当該荷受人の荷物を通常の配送に変更する。なお、本実施形態では不在の期間を用いて配送方法を変更するが不在期間ではなく、不在、もしくは在宅情報を取得できなかった回数を用いて配送方法を切り替えてもよい。詳しくは後述する。
【０１６０】
ステップＳ１２０１では、データベースサーバ１０１ｂのＣＰＵ２０１は、システムがアプリケーションステータス１５０１を確認し、不在発生日１５０５に不在の情報が格納されているユーザを１件抽出する。
【０１６１】
ステップＳ１２０２では、データベースサーバ１０１ｂのＣＰＵ２０１は、不在発生日１５０５に格納されている当該ユーザの不在発生日を抽出する。
【０１６２】
ステップＳ１２０３では、データベースサーバ１０１ｂのＣＰＵ２０１は、現在の日付を取得する。
【０１６３】
ステップＳ１２０４では、データベースサーバ１０１ｂのＣＰＵ２０１は、ステップＳ１２０２およびステップＳ１２０３の内容より、不在期間を算出する。この不在期間の算出は、現在の日付から不在発生日を引き算（減算）することで求められる。
【０１６４】
ステップＳ１２０５では、データベースサーバ１０１ｂのＣＰＵ２０１は、当該ユーザのアプリケーションステータス１５０１で、休暇開始日１５０６および休暇終了日１５０７が設定されているか確認する。休暇開始日１５０６および休暇終了日１５０７が設定されている場合は、データベースサーバ１０１ｂのＣＰＵ２０１は、ステップＳ１２０６へ進み、設定されていない場合はステップＳ１２０８へ進む。
【０１６５】
ステップＳ１２０６では、データベースサーバ１０１ｂのＣＰＵ２０１は、休暇開始日１５０６から休暇終了日１５０７までの期間と、不在発生日１５０５から現在の日付までの期間とで、重複期間があるか否かを判断する。重複期間がある場合は、重複期間の日数を算出し、ステップＳ１２０７へ進む。重複期間が無い場合は、ステップＳ１２０８へ進む。
【０１６６】
ステップＳ１２０７では、データベースサーバ１０１ｂのＣＰＵ２０１は、ステップＳ１２０４で算出した不在期間から、ステップＳ１２０６で算出した重複期間を引き算した値を算出する。そして、ステップＳ１２０４で算出した不在期間を、本ステップで算出した値に置き換える。
【０１６７】
ステップＳ１２０８では、ステップＳ１２０４もしくはＳ１２０７で算出した不在期間と、アプリケーションステータス１５０１の該当ユーザの通常配送切り替え閾値１５０４を比較する。比較した結果、ステップＳ１２０４もしくはＳ１２０７で算出し取得した不在期間が通常配送切り替え閾値１５０４の値(所定期間)以上である場合は（不在期間を所定期間以上取得）、データベースサーバ１０１ｂのＣＰＵ２０１は、ステップＳ１２０９へ進む。不在期間がその値を超えていない場合は、この一連の処理を終え、ステップＳ１２０１へ戻り、次にアプリケーションステータス１５０１の不在発生日１５０５に日付の情報が入っているユーザＩＤ１５０２を抽出し、同様の処理を繰り返す。この処理は不在発生日１５０５が存在するユーザ数分、実施される。
【０１６８】
ステップＳ１２０９では、データベースサーバ１０１ｂのＣＰＵ２０１は、アプリケーションステータス１５０１の該当ユーザのアプリケーション状態１５０３をＦＡＬＳＥに変更する。その後、ステップＳ１２０１へ戻り、次にアプリケーションステータス１５０１の不在発生日１５０５が入っているユーザを抽出し、同様の処理を繰り返す。この処理は不在発生日１５０５が存在するユーザ数分、実施される。ステップＳ１２０９では、データベースサーバ１０１ｂのＣＰＵ２０１は、アプリケーション状態１５０３をＦＡＬＳＥに変更することで、荷物の配送方法の管理を変更している。つまり、取得した不在期間が所定回数を以上である場合は本システムの配送から通常の配送の管理に荷物の管理の変更を決定している。
【０１６９】
なお、本実施形態では、不在発生日から現在の日付までの荷受人の不在の期間を用いて配送方法の変更（切り替え）を行ったが、荷受人が不在、もしくは在宅情報が取れないとデータベースサーバ１０１ｂが判断した回数を用いて配送方法を変更してもよい。図１９のアプリケーションステータス１９０１の不在回数１９０２は、荷受人が不在と判断された回数をカウントした値を格納する。例えば、図１２のステップＳ１２０８で、不在回数１９０２が、取得した通常配送切り替え閾値１５０４(所定回数)以上であるか否かを判定し、当該閾値を超えている場合（不在回数を所定回数取得）に配送方法を変更する。ここでいう通常配送切り替え閾値１５０４とは、不在回数の閾値を示す。不在回数を配送方法変更の判断基準とする際は、荷受人の不在期間は考慮しなくともよいし、不在回数と不在期間の両方の判断基準を用いながら配送方法を変更してもよい。
【０１７０】
図１２の処理により、不在期間や不在回数という所定の条件で荷物の配送方法が変更される。そのため、荷受人側のアプリケーションクライアント１０２ｂの設定が正しくない場合やアプリケーションクライアント１０２ｂが故障している場合に、在宅の情報が取得できずいつまでも荷物が配送されないといった問題の発生を抑止することが可能となる。また、本システムは、休暇開始日１５０６から休暇終了日１５０７までの期間と不在期間や不在回数とに応じて荷物の管理方法を変更し、本システムの配送方法から通常の配送方法へ配送方法の変更を実施する。従って、配送人が適宜荷物ごとに荷受人の不在情報を管理し、それぞれの荷物の配送方法を決定する手間を低減することが可能となる。
【０１７１】
また、図１２の処理により荷受人の不在期間を考慮して配送を行うことが可能となるため、荷受人は休暇終了日１５０７に設定された以降の日付で、本システムの在宅確認により在宅と判断されたときに荷物を受け取ることも可能となる。なお、データベースサーバ１０１ｂのＣＰＵ２０１は、不在期間の設定を受け付けた荷受人へは当該不在期間の間は在宅情報を取得せずに在宅確認を行わず、通信負荷を低減してもよい。
【０１７２】
以上により、本実施形態の荷物の配送方法を変更する処理についての説明を終了する。
【０１７３】
これにより、荷受人の在宅情報に応じた配送リストを生成する配送するシステムにおいて、配送状況に応じて更新される荷受人の情報を容易に確認可能な仕組みを提供することが可能となる。
【０１７４】
本発明は、例えば、システム、装置、方法、プログラム若しくは記憶媒体等としての実施形態も可能であり、具体的には、複数の機器から構成されるシステムに適用してもよいし、また、１つの機器からなる装置に適用してもよい。
【０１７５】
なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラムを、システム或いは装置に直接、或いは遠隔から供給するものを含む。そして、そのシステム或いは装置のコンピュータが前記供給されたプログラムコードを読み出して実行することによっても達成される場合も本発明に含まれる。
【０１７６】
したがって、本発明の機能処理をコンピュータで実現するために、前記コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。
【０１７７】
その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であってもよい。
【０１７８】
プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷなどがある。また、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などもある。
【０１７９】
その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続する。そして、前記ホームページから本発明のコンピュータプログラムそのもの、若しくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。
【０１８０】
また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。  また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせる。そして、ダウンロードした鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
【０１８１】
また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される。その他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現され得る。
【０１８２】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれる。その後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現される。
【０１８３】
なお、前述した実施形態は、本発明を実施するにあたっての具体化の例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。即ち、本発明はその技術思想、又はその主要な特徴から逸脱することなく、様々な形で実施することができる。
【符号の説明】
【０１８４】
１０１ａ  データベースサーバ
１０１ｂ  データベースサーバ
１０２ａ  アプリケーションクライアント
１０２ｂ  アプリケーションクライアント
２０１  ＣＰＵ
２０２  ＲＯＭ
２０３  ＲＡＭ
２１０  ディスプレイ
２１１  外部メモリ
【図１】
2019109642.tif 000003
【図２】
2019109642.tif 000004
【図３】
2019109642.tif 000005
【図４】
2019109642.tif 000006
【図５】
2019109642.tif 000007
【図６】
2019109642.tif 000008
【図７】
2019109642.tif 000009
【図８】
2019109642.tif 000010
【図９】
2019109642.tif 000011
【図１０】
2019109642.tif 000012
【図１１】
2019109642.tif 000013
【図１２】
2019109642.tif 000014
【図１３】
2019109642.tif 000015
【図１４】
2019109642.tif 000016
【図１５】
2019109642.tif 000017
【図１６】
2019109642.tif 000018
【図１７】
2019109642.tif 000019
【図１８】
2019109642.tif 000020
【図１９】
2019109642.tif 000021