JP6432253B2 - 順序情報提供プログラム、方法、システム、及び装置 - Google Patents

順序情報提供プログラム、方法、システム、及び装置 Download PDF

Info

Publication number
JP6432253B2
JP6432253B2 JP2014198596A JP2014198596A JP6432253B2 JP 6432253 B2 JP6432253 B2 JP 6432253B2 JP 2014198596 A JP2014198596 A JP 2014198596A JP 2014198596 A JP2014198596 A JP 2014198596A JP 6432253 B2 JP6432253 B2 JP 6432253B2
Authority
JP
Japan
Prior art keywords
unit
date
order
candidates
time
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2014198596A
Other languages
English (en)
Other versions
JP2016071515A (ja
Inventor
中野　智之
智之 中野
坂田　憲治
憲治 坂田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2014198596A priority Critical patent/JP6432253B2/ja
Publication of JP2016071515A publication Critical patent/JP2016071515A/ja
Application granted granted Critical
Publication of JP6432253B2 publication Critical patent/JP6432253B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Description

本発明は、訪問順を決定する技術に関する。
店舗、施設等の混雑状況を照会することで、訪問者の混雑を緩和させる技術が知られている。
例えば、サービスの日時ごとの混雑状況を示す混雑指数を管理する管理サーバによって、店舗に足を運ばずに遠隔から店舗の混雑状況を照会し、指定日時におけるサービスの予約を可能とする技術、過去の混雑状況だけでなく、施設を利用しようと考えている利用者の数、の変動に応じて、未来の混雑状況をリアルタイムに予測する技術等が提案されている。
特開２００５−５６２８０号公報 特開２００６−２６８１３７号公報
上記従来技術では、サービスの日時ごと及びリアルタイムの混雑状況を知ることができるが、訪問者が、複数のサービスを受ける場合には、訪問者が、サービスごとの混雑状況から、サービスを受ける順番を自身で判断しなければならない。
したがって、１つの側面では、本発明は、混雑状況に基づいて、複数の訪問先の順路を決定することを目的とする。
一態様によれば、複数の手続きと、日にちを特定する特定条件とを指定した入力を受け付け、各単位の処理件数を時間単位毎に記録した履歴データベースを参照して、判断基準に基づいて、前記入力で受け付けた前記複数の手続に対応する複数の単位それぞれの、処理件数の少ない日にち及び時間帯を取得して、該日にち及び時間帯に基づいて、前記複数の単位の順を入れ替えて候補を生成し、前記複数の単位の順を入れ替えて生成した訪問順序の候補において、前記特定条件を満たす候補に対して、該単位毎の処理件数を合計して総処理件数を算出し、算出した前記総処理件数が少ない順に前記候補を出力する処理をコンピュータに実行させる順序情報提供プログラムが提供される。
また、上記課題を解決するための手段として、順序情報提供方法、及び、システムとすることもできる。
混雑状況に基づいて、複数の訪問先の順路を決定することができる。
本実施例におけるシステムのネットワーク構成例を示す図である。 サーバ装置のハードウェア構成を示す図である。 ユーザ端末のハードウェア構成を示す図である。 サーバ装置の機能構成例を示す図である。 手続き情報テーブルのデータ構成例を示す図である。 課情報テーブルのデータ構成例を示す図である。 カレンダー情報ＤＢのデータ構成例を示す図である。 天気予報情報ＤＢのデータ構成例を示す図である。 戸籍課履歴ＤＢのデータ構成例を示す図である。 市民課履歴ＤＢのデータ構成例を示す図である。 国民健康保険課履歴ＤＢのデータ構成例を示す図である。 全体処理の概要を説明するためのフローチャート図である。 順路候補提供部による順路候補提供処理を説明するためのフローチャート図である。 図１３のステップＳ３５の処理を説明するためのフローチャート図である。 図１３のステップＳ３６の処理を説明するためのフローチャート図である。 パターンＡの場合の画面例を示す図である。 パターンＢの場合の画面例を示す図である。 パターンＣの場合の画面例を示す図である。 パターンＤの場合の画面例を示す図である。 特定条件が指定された場合の画面例を示す図である。
以下、本発明の実施の形態を図面に基づいて説明する。図１は、本実施例におけるシステムのネットワーク構成例を示す図である。図１に示すシステム１０００は、サーバ装置１００と、複数のユーザ端末３とを有し、サーバ装置１００と各ユーザ端末３とはネットワーク２を介して接続される。
サーバ装置１００は、種々の業務を行う施設に係る混雑状況を把握し、各ユーザ端末３からの訪問条件４に応じて、訪問条件４を満たす同日に複数の業務部門を訪問するための順路を検索し、その検索結果５をユーザ端末３へ提供する。ユーザ端末３には、検索結果５によって、順路候補が示される。
施設は、複数の手続きを行い、訪問者の申請等に応じた手続きを行う、役所、医療機関、金融機関、アトラクション施設等である。ユーザ、住民、来庁者、患者、来場者、来園者等は、訪問者に相当する。また、役所の場合には課、金融機関の場合には窓口種別、病院の場合には科等が、手続きが発生する単位に相当する。以下の説明では、役所を施設の例として説明するが、これに限定するものではない。
ユーザ端末３は、来庁者となり得るユーザが使用する端末であり、パーソナルコンピュータ、ノートブック型、タブレット型、携帯電話等の端末である。ユーザは、ユーザ端末３を用いて、サーバ装置１００に接続することで、サーバ装置１００から提供されユーザ端末３に表示された画面から訪問条件４を入力して、順路候補をユーザ端末３に表示させる。ユーザは、ユーザ端末３に表示された順路候補を参考にして、役所へ来庁し、複数の課を訪れて、業務を依頼する。
来庁者は、訪問条件４を満たす順路候補が表示されることで、混雑状況において無駄な時間を過ごすことを最小限にして所望の業務課を訪問し、効率的に各業務課での手続きを行うことができる。
図２は、サーバ装置のハードウェア構成を示す図である。図２において、サーバ装置１００は、コンピュータであって、ＣＰＵ（Central Processing Unit）１１ａと、主記憶装置１２ａと、補助記憶装置１３ａと、入力装置１４ａと、表示装置１５ａと、通信Ｉ／Ｆ（インターフェース）１７ａと、ドライブ装置１８ａとを有し、それらのユニットがバスＢ１に接続されている。
ＣＰＵ１１ａは、主記憶装置１２ａに格納されたプログラムに従ってサーバ装置１００を制御する。主記憶装置１２ａには、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）等が用いられ、ＣＰＵ１１ａにて実行されるプログラム、ＣＰＵ１１ａでの処理に必要なデータ、ＣＰＵ１１ａでの処理にて得られたデータ等を記憶又は一時保存する。
補助記憶装置１３ａには、ＨＤＤ（Hard Disk Drive）等が用いられ、各種処理を実行するためのプログラム等のデータを格納する。補助記憶装置１３ａに格納されているプログラムの一部が主記憶装置１２にロードされ、ＣＰＵ１１ａに実行されることによって、各種処理が実現される。記憶部１３０ａは、主記憶装置１２ａ及び／又は補助記憶装置１３ａを有する。
入力装置１４ａは、マウス、キーボード等を有し、ユーザがサーバ装置１００による処理に必要な各種情報を入力するために用いられる。表示装置１５ａは、ＣＰＵ１１ａの制御のもとに必要な各種情報を表示する。通信Ｉ／Ｆ１７ａは、有線又は無線などによりネットワーク２を通じて通信を行う。通信Ｉ／Ｆ１７ａによる通信は無線又は有線に限定されるものではない。ネットワーク２は、Local Area Network（ＬＡＮ）、Wide Area Network（ＷＡＮ）、及び／又はインターネット等を含む。
サーバ装置１００ａによって行われる処理を実現するプログラムは、例えば、ＣＤ−ＲＯＭ（Compact Disc Read-Only Memory）等の記憶媒体１９ａによってサーバ装置１００に提供される。
ドライブ装置１８ａは、ドライブ装置１８ａにセットされた記憶媒体１９ａ（例えば、ＣＤ−ＲＯＭ等）とサーバ装置１００とのインターフェースを行う。
また、記憶媒体１９ａに、後述される本実施の形態に係る種々の処理を実現するプログラムを格納し、この記憶媒体１９ａに格納されたプログラムは、ドライブ装置１８ａを介してサーバ装置１００にインストールされる。インストールされたプログラムは、サーバ装置１００により実行可能となる。
尚、プログラムを格納する媒体としてＣＤ−ＲＯＭに限定するものではなく、コンピュータが読み取り可能な媒体であればよい。コンピュータ読取可能な記憶媒体として、ＣＤ−ＲＯＭの他に、ＤＶＤディスク、ＵＳＢメモリ等の可搬型記録媒体、フラッシュメモリ等の半導体メモリであっても良い。
図３は、ユーザ端末のハードウェア構成を示す図である。図３では、ユーザ端末３が、タブレット型、携帯電話等の情報処理端末である場合のハードウェア構成を示す。ユーザ端末３は、ＣＰＵ（Central Processing Unit）１１ｂと、主記憶装置１２ｂと、ユーザＩ／Ｆ（インターフェース）１６ｂと、通信Ｉ／Ｆ１７ｂと、ドライブ装置１８ｂとを有し、バスＢ２に接続される。
ＣＰＵ１１ｂは、主記憶装置１２ｂに格納されたプログラムに従ってユーザ端末３を制御する。主記憶装置１２ｂには、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）等が用いられ、ＣＰＵ１１ｂにて実行されるプログラム、ＣＰＵ１１ｂでの処理に必要なデータ、ＣＰＵ１１ｂでの処理にて得られたデータ等を記憶又は一時保存する。主記憶装置１２ｂに格納されているプログラムが、ＣＰＵ１１ｂに実行されることによって、各種処理が実現される。
ユーザＩ／Ｆ１６ｂは、ＣＰＵ１１ｂの制御のもとに必要な各種情報を表示し、また、ユーザによる操作入力を可能とするタッチパネル等である。通信Ｉ／Ｆ１７ｂによる通信は無線又は有線に限定されるものではない。
ユーザ端末３によって行われる処理を実現するプログラムは、ネットワーク２を介してサーバ装置１００からダウンロードされる、例えば、ユーザ端末３のＷｅｂブラウザ上で動作するJavaScript（登録商標）（ジャバスクリプト）等である。
ドライブ装置１８ｂは、ドライブ装置１８ｂにセットされた記憶媒体１９ｂ（例えば、ＳＤ（Secure Digital）メモリカード等）とユーザ端末３とのインターフェースを行う。主記憶装置１２ｂ及び／又は記憶媒体１９ｂが記憶部１３０ｂに相当する。
パーソナルコンピュータ、ノートブック型のユーザ端末３のハードウェア構成は、図２のハードウェア構成と同様であるので、その説明を省略する。以下の説明では、図３のハードウェア構成を有するユーザ端末３とする。
図４は、サーバ装置の機能構成例を示す図である。図４において、サーバ装置１００は、自治体業務処理部５０と、順路候補提供部６０とを有する。また、記憶部１３０には、戸籍課履歴ＤＢ３１、市民課履歴ＤＢ３２、国民健康保険課履歴ＤＢ３３、手続き情報テーブル７１、課情報テーブル７２、カレンダー情報ＤＢ７３、天気予報情報ＤＢ７４等が記憶される。
自治体業務処理部５０は、役所業務を行う戸籍課、市民課、国民健康保険課等の各課の業務処理を管理し、自治体業務システムを役所に提供する。各課で行った業務の履歴は対応する履歴ＤＢに記憶される。
戸籍課で行った業務の履歴は単位時間毎に処理件数が集計されて戸籍課履歴ＤＢ３１に記憶され、市民課で行った業務の履歴は単位時間毎に処理件数が集計されて市民課履歴ＤＢ３２に記憶され、国民健康保険課で行った業務の履歴は単位時間毎に処理件数が集計されて国民健康保険課履歴ＤＢ３３に記憶される。以下、戸籍課履歴ＤＢ３１、市民課履歴ＤＢ３２、国民健康保険課履歴ＤＢ３３を総称して、履歴ＤＢ３０という場合がある。
順路候補提供部６０は、ユーザ端末３からの訪問条件４に基づいて、混雑状況を考慮した各課へ訪問する場合の順路候補を検索してユーザ端末３へ提供する。順路候補提供部６０は、更に、訪問条件受信部６１と、窓口特定部６２と、推奨日時抽出部６３と、混雑状況算出部６４と、順路候補決定部６５とを有する。これらの各部は、サーバ装置１００にインストールされた一以上のプログラムが、ＣＰＵ１１ａに実行させる処理によって実現される。
訪問条件受信部６１は、ユーザ端末３から訪問条件４を受信する。訪問条件４には、来庁目的、来庁日、特定条件等が含まれる。来庁目的には、１以上の手続き内容が指定される。来庁日には、来庁を希望する日又は２日以上で示される期間が指定される。特定条件には、来庁時間、曜日（月、火、水、木、金、土、日）、天候（晴、雨、曇、雪）、六曜（先勝、友引、先負、仏滅、大安、赤口）等の１つ以上が指定される。特定条件は指定がなくても良い。
窓口特定部６２は、ユーザ端末３から受信した訪問条件４の来庁目的に基づいて、対象となる窓口（課）を特定する。
推奨日時抽出部６３は、窓口特定部６２によって特定された課毎に、対応するデータベースから、処理件数の少ない日にち及び／又は時間帯（時間帯の開始時間でも良い）を推奨日時として抽出する。
混雑状況算出部６４は、推奨日時抽出部６３によって抽出した各課の推奨日時における処理件数を比較し、処理件数の少ない順に順路を決定する。
順路候補決定部６５は、受信した訪問条件４の来庁日及び特定条件を満たす場合に、総処理件数の少ない順に３つの順路候補を決定してユーザ端末３に検索結果５として表示させる。検索結果５では、最大３つの順路候補がユーザ端末３に表示される。なお、順路候補の個数は、３に限定されない。
記憶部１３０に記憶される、本実施例に係るテーブル及びデータベースのデータ構成例について図５から図１１で説明する。
図５は、手続き情報テーブルのデータ構成例を示す図である。図５において、手続き情報テーブル７１は、手続き内容毎に対応する課を示すテーブルであり、手続きＩＤ、課ＩＤ、手続き内容等の項目を有する。
手続きＩＤは、手続き内容を特定するための識別情報を示す。課ＩＤは、手続き内容に係る業務を行う課の識別情報を示す。手続き内容は、来庁者が役所へ行う手続きの内容を示す。
図５の例では、手続きＩＤ「Ｋ００１」で特定される手続き内容は「出生届」であり、「出生届」の業務を行う課は課ＩＤ「000001」で特定される。また、手続きＩＤ「Ｓ００２」で特定される手続き内容は「転入届」であり、「転入届」の業務を行う課は課ＩＤ「000002」で特定される。
図６は、課情報テーブルのデータ構成例を示す図である。図６において、課情報テーブル７２は、各課の情報を管理するテーブルであり、課ＩＤ、課名等の項目を有する。課ＩＤは、課の識別情報を示す。課名は、課の名称を示す。課ＩＤによって、課情報テーブル７２は、手続き情報テーブル７１と関連付けされる。
図６の例では、課ＩＤ「000001」は「戸籍課」であり、課ＩＤ「000002」は「市民課」であり、課ＩＤ「000003」は「国民健康保険課」であることを示している。
図７は、カレンダー情報ＤＢのデータ構成例を示す図である。図７において、カレンダー情報ＤＢ７３は、１年間分のカレンダー情報を管理するデータベースであり、年、月日、曜日、六曜等の項目を有する。カレンダー情報ＤＢ７３は、月次で更新され、当月から未来の１年間分のカレンダー情報を管理する。
年は、西暦を示す。月日は、月及び日にちを示す。曜日は、年及び月日に対応する曜日を示し、月、火、水、木、金、土、日のいずれかを示す。六曜は、年及び月日に対応する曜日を示し、大安、友引、先勝、先負、仏滅、赤口のいずれかを示す。
図７の例では、「２０１３」年の月日「１１２１」は、「木」曜日であり、「仏滅」であることを示している。
図８は、天気予報情報ＤＢのデータ構成例を示す図である。図８において、天気予報情報ＤＢ７４は、一週間分の天気予報を管理するデータベースであり、年、月日、時間、天気等の項目を有する。
年は、西暦を示す。月日は、月及び日にちを示す。時間は、予測した天気の時間帯を示す。３時間毎の天気が予測される場合は、３時間の幅で示され、２４時間表記で示される。なお、３時間に限定されるものではない。天気は、予測された天気を示し、晴、雨、曇、又は雪等を示す。
図８の例では、「２０１３」年の月日「１１２１」の「６−９」の時間において、天気は「雨」であると予測されたことを示している。「６−９」は、午前６時から午前９時を示している。また、「１５−１８」を示す時間では、１５時から１８時（即ち、午後３時から午後６時）を示している。他も同様である。
図９は、戸籍課履歴ＤＢのデータ構成例を示す図である。図９において、戸籍課履歴ＤＢ３１は、単位時間毎の、戸籍課で処理された処理件数を示す履歴情報を管理するデータベースであり、年月日、開始時間、終了時間、処理件数等を有する。
年月日は、西暦及び月日とを示す。開始時間は、所定単位時間の開示時刻を示し、終了時間は、所定単位時間の終了時刻を示す。処理件数は、開始時間から終了時間までの所定単位時間で行われた処理件数を示す。
図９の例では、年月日「20121121」について、開始時間「0830」から終了時間「0930」までの処理件数は「６件」であり、開始時間「1230」から終了時間「1330」までの処理件数は「９件」であったことを示している。
一方、年月日の異なる「20121122」の同じ開始時間「0830」から終了時間「0930」までの処理件数は「１８件」であり、開始時間「1230」から終了時間「1330」までの処理件数は「３３件」であったことを示している。月日によって、処理件数に大幅な違いがあることが分かる。
図１０は、市民課履歴ＤＢのデータ構成例を示す図である。図１０において、市民課履歴ＤＢ３２は、単位時間毎の、市民課で処理された処理件数を示す履歴情報を管理するデータベースであり、年月日、開始時間、終了時間、処理件数等を有する。市民課履歴ＤＢ３２の項目は、戸籍課履歴ＤＢ３１と同様であるので、その説明を省略する。
図１０の例では、年月日「20121121」について、開始時間「1230」から終了時間「1330」までの処理件数は「１８件」であり、開始時間「1630」から終了時間「1730」までの処理件数は「９件」であったことを示している。
一方、年月日の異なる「20121122」の同じ開始時間「1230」から終了時間「1330」までの処理件数は「１５件」であり、開始時間「1630」から終了時間「1730」までの処理件数は「９件」であったことを示している。昼前後に処理が集中し、夕方に減少することが分かる。
図１１は、国民健康保険課履歴ＤＢのデータ構成例を示す図である。図１０において、国民健康保険課履歴ＤＢ３３は、単位時間毎の、国民健康保険課で処理された処理件数を示す履歴情報を管理するデータベースであり、年月日、開始時間、終了時間、処理件数等を有する。市民課履歴ＤＢ３２の項目は、戸籍課履歴ＤＢ３１と同様であるので、その説明を省略する。
図１１の例では、年月日「20121121」について、開始時間「1230」から終了時間「1330」までの処理件数は「９件」であり、開始時間「1630」から終了時間「1730」までの処理件数は「４件」であったことを示している。
一方、年月日の異なる「20121122」の同じ開始時間「1230」から終了時間「1330」までの処理件数は「１５件」であり、開始時間「1630」から終了時間「1730」までの処理件数は「６件」であったことを示している。昼前後に処理が集中し、夕方に減少することが分かる。昼前後に処理が集中し、夕方に減少することが分かる。
次に、システム１０００において、サーバ装置１００とユーザ端末３とで行われる全体処理の概要について説明する。図１２は、全体処理の概要を説明するためのフローチャート図である。図１２において、ユーザがユーザ端末３で訪問条件４を入力すると（ステップＳ１１）、訪問条件４がユーザ端末３からサーバ装置１００へと送信される。
サーバ装置１００では、訪問条件受信部６１がユーザ端末３から訪問条件４を受信すると（ステップＳ１２）、窓口特定部６２が訪問条件４で示される来庁目的に基づいて、１以上の課を特定し、特定した各課の時間単位毎の過去の処理件数を、課の履歴ＤＢから取得する（ステップＳ１３）。過去は、訪問条件で指定される来庁日のうち年号を除いた月日に相当する。指定された同一の月日の過去の処理件数が取得される。
推奨日時抽出部６３は、窓口特定部６２が取得した処理件数から処理件数が所定数より少ない日時を推奨日時として抽出する（ステップＳ１４）。所定数は、予め設定された数値である。推奨日時は、時間帯、又は、日にちを特定した時間帯を示す。推奨日時における時間帯は、時間帯の開始時間を示すことでも良い。所定数より少ない日時を推奨日時として抽出する代わりに、処理件数の少ない順に所定数の日時を推奨日時として抽出してもよい。
その後、混雑状況算出部６４が、各課の混雑状況を算出する（ステップＳ１５）。混雑状況算出部６４は、推奨日時において、処理件数の少ない順に順路を仮決定する。
そして、順路候補決定部６５が、訪問条件の来庁日に基づいて、順路候補を決定する（ステップＳ１６）。順路候補決定部６５は、訪問条件４の特定条件で指定される曜日、六曜、及び／又は天気が当てはまる場合に、順路候補が決定される。順路候補を示す検索結果５が、訪問条件４に対する検索結果としてユーザ端末３に送信される。
ユーザ端末３は、サーバ装置１００から検索結果５を受信すると、検索結果５をユーザＩ／Ｆ１６ｂに表示する（ステップＳ１７）。
上述したサーバ装置１００による訪問条件４に基づく順路候補決定において、来庁日で指定される日にちと来庁目的とに応じて、以下のパターンＡ、Ｂ、Ｃ、及びＤが存在する。
パターンＡ：日にちが１つ、且つ、来庁目的が１つの場合である。一例として、図１６に示す、来庁日が「2013年11月22日」、且つ、来庁目的が「婚姻届」の場合がある。
パターンＢ：日にちが１つ、且つ、来庁目的が複数の場合である。一例として、図１７に示す、来庁日が「2013年11月21日」、且つ、来庁目的が「婚姻届」、「住民票受取」、及び「資格変更届」の場合がある。
パターンＣ：日にちが複数、且つ、来庁目的が１つの場合である。一例として、図１８に示す、来庁日が「2013年11月21日〜2013年11月22日」、且つ、来庁目的が「婚姻届」の場合がある。
パターンＤ：日にちが複数、且つ、来庁目的が複数の場合である。一例として、図１９に示す、来庁日が「2013年11月21日〜2013年11月22日」、且つ、来庁目的が「婚姻届」、「住民票受取」、及び「資格変更届」の場合がある。
以下に、サーバ装置１００における順路候補提供部６０による詳細な順路候補提供処理について、図１３〜図１５で説明する。図１３は、順路候補提供部による順路候補提供処理を説明するためのフローチャート図である。
図１３において、順路候補提供部６０の訪問条件受信部６１が、訪問条件４をユーザ端末３から受信すると（ステップＳ３１）、窓口特定部６２は、手続き情報テーブル７１及び課情報テーブル７２を参照して、訪問条件４で指定される来庁目的に基づいて、１以上の窓口（課）を特定する。
来庁目的が「婚姻届」の場合、手続き情報テーブル７１を参照することで、課ＩＤ「000002」を得る。取得した課ＩＤ「000001」を用いて、課情報テーブル７２を参照することで、対応する課名「戸籍課」が特定できる。来庁目的が１つであれば、一の課が特定されるが、来庁目的が複数指定される場合には、１以上の課が特定される。
来庁目的に「婚姻届」、「住民票受取」、及び「資格変更届」の複数指定されている場合、夫々に対して、手続き情報テーブル７１を参照することで課ＩＤ「000001」、課ＩＤ「000002」、及び課ＩＤ「000003」を取得し、課情報テーブル７２を参照することで、対応する課名「戸籍課」、「市民課」、及び「国民健康保険課」を特定できる。
そして、窓口特定部６２は、特定した各課の履歴ＤＢを用いて、時間単位毎の過去の処理件数を取得する（ステップＳ３３）。過去とは、訪問条件で指定される来庁日のうち年号を除いた月日が相当する。指定された同一の月日の過去の処理件数が取得される。来庁日「2013年11月21日」が指定された場合、履歴ＤＢ３０から、年号を除いた「11月21日」が一致するレコードを抽出して、時間単位毎の処理件数を取得する。
その後、順路候補提供部６１は、来庁日で指定された日にちは１つか否かを判断する（ステップＳ３４）。順路候補提供部６１は、推奨日時抽出部６３と混雑状況算出部６４とによって、ステップＳ３５又はＳ３６の仮決定処理を行う。来庁日で指定された日にちが１つの場合、パターンＡ又はパターンＢの処理が行われる（ステップＳ３５）。一方、来庁日で指定された日にちが複数の場合、パターンＣ又はパターンＤの処理が行われる（ステップＳ３６）。
ステップＳ３５又はＳ３６の仮決定処理が終了すると、順路候補決定部６５は、仮決定された順路候補の日にちが特定条件（来庁時間、曜日、天気、六曜）を満たすか否かを判断する（ステップＳ３７）。
特定条件として、曜日が指定されている場合、順路候補決定部６５は、カレンダー情報ＤＢ７３において順路候補の日にちに対応付けられる曜日が、特定条件で指定される曜日と一致するか否かを判断する。
特定条件として、天気が指定されている場合、順路候補決定部６５は、天気予報情報ＤＢ７４を順路候補の日にちに対応付けられる天気が、特定条件で指定される天気と一致するか否かを判断する。
特定条件として、六曜が指定されている場合、順路候補決定部６５は、カレンダー情報ＤＢ７３において順路候補の日にちに対応付けられる六曜が、特定条件で指定される六曜と一致するか否かを判断する。
また、特定条件に値が存在しない場合、無条件で特定条件を満たすと判断し、ステップＳ３５又はＳ３６で得た順路候補の全てを対象として、以下のステップＳ３８〜Ｓ４０を行う。
順路候補の日にちが特定条件を満たさない場合、順路候補決定部６５による順路候補決定処理は行わず、順路候補提供部６１は、この順路候補提供処理を終了する。
一方、順路候補の日にちが特定条件を満たす場合、順路候補決定部６５は、特定条件を満たす順路候補のうち、総処理件数の少ない順に３つの順路候補を選択する（ステップＳ３８）。順路候補決定部６５は、特定条件を満たす順路候補毎に、課毎の処理件数を合計して総処理件数を算出する。
そして、順路候補決定部６５は、選択した３つの順路候補を、「処理件数」、「日次」の小さい順に並べ替えて（ステップＳ３９）、ユーザ端末３に検索結果を表示する（ステップＳ４０）。
図１４は、図１３のステップＳ３５の処理を説明するためのフローチャート図である。図１４において、推奨日時抽出部６３は、訪問条件４の来庁目的は１つか否かを判断する（ステップＳ５１）。
来庁目的が１つの場合、推奨日時抽出部６３は、パターンＡの処理を行う。推奨日時抽出部６３は、ステップＳ３３で抽出したレコードから、処理件数の少ない、時間帯の開始時間を抽出して推奨日時とする（ステップＳ５２）。推奨日時（日にち及び時間帯の開始時間）と、１つの来庁先とを示す情報により、順路候補の仮決定となる。但し、パターンＡでは、推奨日時の日にちは全て同日である。その後、ステップＳ３５での仮判定処理は終了する。
一方、日にちが複数の場合、推奨日時抽出部６３は、ステップＳ５３からＳ５７によるパターンＢの処理を行う。推奨日時抽出部６３は、ステップＳ３３で抽出したレコードから、各課で処理件数の少ない、日にち及び時間帯の開始時間の組を抽出して推奨日時とする（ステップＳ５３）。
その後、混雑状況算出部６４は、訪問条件４の来庁目的に「転入」が含まれているか否かを判断する（ステップＳ５４）。来庁目的に「転入」が含まれている場合、混雑状況算出部６４は、転入を扱う市民課を１番目の来庁先に設定する（ステップＳ５５）。
そして、混雑状況算出部６４は、推奨日時毎に、市民課以外の各課について、推奨日時毎に処理件数を比較し、処理件数の少ない順に順路候補を仮決定する（ステップＳ５６）。推奨日時（日にち及び時間帯の開始時間）と、複数の来庁先への順路とを示す情報により、順路候補の仮決定となる。但し、この場合、各順路候補の１番目の来庁先は市民課を示す。
一方、パターンＢにおいて、来庁目的に「転入」が含まれていない場合、推奨日時毎に各課の処理件数を比較し、処理件数の少ない順に順路候補を仮決定する（ステップＳ５７）。推奨日時（日にち及び時間帯の開始時間）と、複数の来庁先への順路とを示す情報により、順路候補の仮決定となる。その後、ステップＳ３５での仮判定処理は終了する。
図１５は、図１３のステップＳ３６の処理を説明するためのフローチャート図である。図１５において、推奨日時抽出部６３は、訪問条件４の来庁目的は１つか否かを判断する（ステップＳ７１）。
来庁目的が１つの場合、推奨日時抽出部６３は、パターンＣの処理を行う。推奨日時抽出部６３は、ステップＳ３３で抽出したレコードから、処理件数の少ない、日にち及び時間帯の開始時間の組を抽出して推奨日時とする（ステップＳ７２）。推奨日時（日にち及び時間帯の開始時間）と、１つの来庁先とを示す情報により、順路候補の仮決定となる。その後、ステップＳ３６での仮判定処理は終了する。
一方、日にちが複数の場合、推奨日時抽出部６３は、ステップＳ５３からＳ５７によるパターンＤの処理を行う。推奨日時抽出部６３は、ステップＳ３３で抽出したレコードから、各課で処理件数の少ない、日にち及び時間帯の開始時間の組を抽出して推奨日時とする（ステップＳ７３）。
その後、混雑状況算出部６４は、訪問条件４の来庁目的に「転入」が含まれているか否かを判断する（ステップＳ７４）。来庁目的に「転入」が含まれている場合、混雑状況算出部６４は、転入を扱う市民課を１番目の来庁先に設定する（ステップＳ７５）。
そして、混雑状況算出部６４は、推奨日時毎に、市民課以外の各課について、推奨日時毎に処理件数を比較し、処理件数の少ない順に順路候補を仮決定する（ステップＳ７６）。推奨日時（日にち及び時間帯の開始時間）と、複数の来庁先への順路とを示す情報により、順路候補の仮決定となる。但し、この場合、各順路候補の１番目の来庁先は市民課を示す。
一方、パターンＤにおいて、来庁目的に「転入」が含まれていない場合、推奨日時毎に各課の処理件数を比較し、処理件数の少ない順に順路候補を仮決定する（ステップＳ７７）。推奨日時（日にち及び時間帯の開始時間）と、複数の来庁先への順路とを示す情報により、順路候補の仮決定となる。その後、ステップＳ３６での仮判定処理は終了する。
ステップＳ３５での処理（図１４）又はステップＳ３５（図１５）での処理により仮決定された順路候補が、更に、特定条件を満たす順路候補に絞られ、総処理件数の少ない順路候補がユーザ端末３に表示される。
次に、パターンＡ、Ｂ、Ｃ、及びＤでのユーザ端末３に表示される画面例について図１６〜図２０で説明する。図１６は、パターンＡの場合の画面例を示す図である。図１６において、画面８０Ａは、ユーザ端末３に表示された初期状態では、訪問条件４を入力する条件入力領域８２と、入力した内容を決定する決定ボタン８３とを有する。
条件入力領域８２は、条件毎に選択肢を有する。条件は、来庁日、曜日、来庁時間、来庁目的、天気、六曜等である。来庁日の選択肢では、年月日の設定が可能である。曜日の選択肢では、月、火、水、木、金、土、日から１又は複数の選択が可能である。来庁時間の選択肢では、来庁するであろう時間帯の選択が可能である。
来庁目的の選択肢では、出生届、死亡届、婚姻届、附表受取、変更届、住民票受取、転入届、転出届、転居届、変更届、資格取得届、資格喪失届、資格変更届等の選択が可能である。
天気の選択肢では、晴、雨、曇、雪等から１又は複数の選択が可能である。六曜の選択肢では、先勝、友引、先負、仏滅、大安、赤口等から１又は複数の選択が可能である。
パターンＡの例として、ユーザが画面８０Ａにおいて、条件入力領域８２から来庁日に「2013年11月22日〜2013年11月22日」を選択し、来庁目的に婚姻届を選択した後、決定ボタン８３をクリックすると、ユーザが選択した値を示す訪問条件４がサーバ装置１００へ送信され、サーバ装置１００は訪問条件４に対する検索結果５をユーザ端末３は送信する。画面８１Ａがユーザ端末３に表示される。
画面８１Ａは、画面８０Ａの構成に加えて、検索結果８４を表示する表示領域８４を含む。表示領域８４は、条件入力領域８２で入力された訪問条件４に対する検索結果５を示す。表示領域８４には、順路候補毎に、来庁日、来庁時間、来庁先等の情報が示される。
この例では、順路候補１から順路候補３までが示されている。来庁目的は婚姻届１つであったため、いずれの順路候補においても戸籍課のみしか示されない。
順路候補１では、来庁日「2013年11月22日（金） 大安」の来庁時間「８時３０分 晴」が、第１に推奨される日時であることを示している。
順路候補２では、来庁日「2013年11月22日（金） 大安」の来庁時間「９時３０分 晴」が、第２に推奨される日時であることを示している。
順路候補３では、来庁日「2013年11月22日（金） 大安」の来庁時間「１６時３０分 晴」が、第３に推奨される日時であることを示している。
ユーザは、順路候補１〜３で示された来庁時間を参考にして、待ち時間の短い時間に役所へ訪問することができる。
図１７は、パターンＢの場合の画面例を示す図である。図１７において、画面８０Ｂは、図１６の画面８０Ａと同様の構成であるのでその説明を省略する。
パターンＢの例として、ユーザが画面８０Ｂにおいて、条件入力領域８２から来庁日に「2013年11月21日〜2013年11月21日」を選択し、来庁目的に婚姻届、住民票受取、資格変更届を選択した後、決定ボタン８３をクリックすると、ユーザが選択した値を示す訪問条件４がサーバ装置１００へ送信され、サーバ装置１００は訪問条件４に対する検索結果５をユーザ端末３は送信する。画面８１Ｂがユーザ端末３に表示される。
画面８１Ｂの構成は、図１６の画面８０Ａの構成と同様であるので、その説明を省略する。この例では、順路候補１から順路候補３までが示されている。来庁目的は、婚姻届、住民票受取、資格変更届の複数であったため、推奨される順路が示されている。
順路候補１では、来庁日「2013年11月21日（木） 仏滅」の来庁時間「１６時３０分 曇」が、第１に推奨される日時であることを示し、順路には、国民健康保険課（資格変更届）−＞戸籍課（婚姻届）−＞市民課（住民票受取）が示されている。
順路候補２では、来庁日「2013年11月21日（木） 仏滅」の来庁時間「８時３０分 雨」が、第２に推奨される日時であることを示し、順路には、戸籍課（婚姻届）−＞国民健康保険課（資格変更届）−＞市民課（住民票受取）が示されている。
順路候補３では、来庁日「2013年11月21日（木） 仏滅」の来庁時間「８時３０分 雨」が、第３に推奨される日時であることを示し、順路には、国民健康保険課（資格変更届）−＞戸籍課（婚姻届）−＞市民課（住民票受取）が示されている。
ユーザは、順路候補１〜３で示された来庁時間及び順路を参考にして、役所での待ち時間の短いタイミングで訪問することができる。
図１８は、パターンＣの場合の画面例を示す図である。図１８において、画面８０Ｃは、図１６の画面８０Ａと同様の構成であるのでその説明を省略する。
パターンＣの例として、ユーザが画面８０Ｃにおいて、条件入力領域８２から来庁日に「2013年11月21日〜2013年11月22日」を選択し、来庁目的に婚姻届を選択した後、決定ボタン８３をクリックすると、ユーザが選択した値を示す訪問条件４がサーバ装置１００へ送信され、サーバ装置１００は訪問条件４に対する検索結果５をユーザ端末３は送信する。画面８１Ｃがユーザ端末３に表示される。
画面８１Ｃの構成は、図１６の画面８０Ａの構成と同様であるので、その説明を省略する。この例では、順路候補１から順路候補３までが示されている。来庁目的は婚姻届１つであったため、いずれの順路候補においても戸籍課のみしか示されない。しかしながら、来庁日が複数日（２日）を指定しているため、より混雑していない「2013年11月21日」が推奨されている。
順路候補１では、来庁日「2013年11月21日（木） 仏滅」の来庁時間「８時３０分 雨」が、第１に推奨される日時であることを示している。
順路候補２では、来庁日「2013年11月21日（木） 仏滅」の来庁時間「１６時３０分 曇」が、第２に推奨される日時であることを示している。
順路候補３では、来庁日「2013年11月21日（木） 仏滅」の来庁時間「１０時３０分 雨」が、第３に推奨される日時であることを示している。
ユーザは、順路候補１〜３で示された来庁時間及び順路を参考にして、役所での待ち時間の短いタイミングで訪問することができる。
図１９は、パターンＤの場合の画面例を示す図である。図１９において、画面８０Ｄは、図１６の画面８０Ａと同様の構成であるのでその説明を省略する。
パターンＤの例として、ユーザが画面８０Ｄにおいて、条件入力領域８２から来庁日に「2013年11月21日〜2013年11月22日」を選択し、来庁目的に婚姻届、住民票受取、資格変更届を選択した後、決定ボタン８３をクリックすると、ユーザが選択した値を示す訪問条件４がサーバ装置１００へ送信され、サーバ装置１００は訪問条件４に対する検索結果５をユーザ端末３は送信する。画面８１Ｄがユーザ端末３に表示される。
画面８１Ｄの構成は、図１６の画面８０Ａの構成と同様であるので、その説明を省略する。この例では、順路候補１から順路候補３までが示されている。来庁日が複数日（２日）を指定しているため、より混雑していない「2013年11月21日」が推奨されている。来庁目的は、婚姻届、住民票受取、資格変更届の複数であったため、推奨される順路が示されている。
順路候補１では、来庁日「2013年11月21日（木） 仏滅」の来庁時間「１６時３０分 曇」が、第１に推奨される日時であることを示し、順路には、国民健康保険課（資格変更届）−＞戸籍課（婚姻届）−＞市民課（住民票受取）が示されている。
順路候補２では、来庁日「2013年11月21日（木） 仏滅」の来庁時間「８時３０分 雨」が、第２に推奨される日時であることを示し、順路には、戸籍課（婚姻届）−＞国民健康保険課（資格変更届）−＞市民課（住民票受取）が示されている。
順路候補３では、来庁日「2013年11月21日（木） 仏滅」の来庁時間「８時３０分 雨」が、第３に推奨される日時であることを示し、順路には、国民健康保険課（資格変更届）−＞戸籍課（婚姻届）−＞市民課（住民票受取）が示されている。
ユーザは、順路候補１〜３で示された来庁時間及び順路を参考にして、役所での待ち時間の短いタイミングで訪問することができる。
図２０は、特定条件が指定された場合の画面例を示す図である。図２０において、画面８０Ｄ及び画面８１Ｄは、図１９と同様であるのでその説明を省略する。特定条件が指定された場合をパターンＤの例で説明する。図１９の画面８０Ｄへの設定に加えて、ユーザは天気「晴」を指定し、決定ボタン８３をクリックする。ユーザが選択した値を示す訪問条件４がサーバ装置１００へ送信され、サーバ装置１００は訪問条件４に対する検索結果５をユーザ端末３は送信する。画面８１Ｄがユーザ端末３に表示される。
図１９の例と同様に順路候補１から順路候補３までが示される。来庁日が複数日（２日）を指定されているが、天気「晴」の指定により、「晴」の予測の「2013年11月22日」が推奨されている。また、図１９の例と同様に来庁目的は、婚姻届、住民票受取、資格変更届の複数であったため、推奨される順路が示されている。
順路候補１では、来庁日「2013年11月22日（金） 大安」の来庁時間「８時３０分 晴」が、第１に推奨される日時であることを示し、順路には、国民健康保険課（資格変更届）−＞市民課（住民票受取）−＞戸籍課（婚姻届）が示されている。
順路候補２では、来庁日「2013年11月22日（金） 大安」の来庁時間「１６時３０分 晴」が、第２に推奨される日時であることを示し、順路には、国民健康保険課（資格変更届）−＞市民課（住民票受取）−＞戸籍課（婚姻届）が示されている。
順路候補３では、来庁日「2013年11月22日（金） 大安」の来庁時間「１４時３０分 晴」が、第３に推奨される日時であることを示し、順路には、市民課（住民票受取）−＞国民健康保険課（資格変更届）−＞戸籍課（婚姻届）が示されている。
上述より、サーバ装置１００を利用するユーザである住民は、来庁する前に、役所の各窓口の混雑状況を避けることのできる日にち及び時間帯を知ることができ、本人が来庁する適切なタイミングおよび順路を住民に提示し、役所の訪問後に住民が無駄な時間をすごすといった問題を緩和することができる。
従って、役所の複数の窓口（課）毎の混雑状況を考慮した、窓口を回る順序の候補を提供することができる。なお、本実施例は、役所に限定されない。
本発明は、具体的に開示された実施例に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。
以上の実施例を含む実施形態に関し、更に以下の付記を開示する。
（付記１）
手続きが発生する複数の単位と、日にちを特定する特定条件とを指定した入力を受け付け、
前記複数の単位の順を入れ替えて生成した訪問順序の候補において、前記特定条件を満たす候補に対して、該単位毎の処理件数を合計して総処理件数を算出し、
算出した前記総処理件数が少ない順に前記候補を出力する
処理をコンピュータに実行させる順序情報提供プログラム。
（付記２）
各単位は１以上の手続きを含み、
前記複数の単位は、前記入力の複数の手続きによって指定され、
前記コンピュータに、
前記入力で指定される各手続きに対応する単位を、該手続きと該単位とを対応付けた手続き情報テーブルを参照することにより特定し、
各単位の処理件数を時間単位毎に記録した履歴データベースを参照して、判断基準に基づいて処理件数の少ない日にち及び時間帯を取得して、該日にち及び時間帯に基づいて、特定した前記単位の順を入れ替えて候補を生成する
処理を実行させることを特徴とする付記１記載の順序情報提供プログラム。
（付記３）
特定の手続きが前記入力で指定されている場合、該特定の手続きが発生する単位を１番目とする
処理を前記コンピュータに実行させることを特徴とする付記２記載の順序情報提供プログラム。
（付記４）
前記特定条件に値がない場合、前記特定条件に値が存在しない場合、無条件で特定条件を満たすとどの候補も該特定条件を満たすと判断する
処理を前記コンピュータに実行させることを特徴とする付記２記載の順序情報提供プログラム。
（付記５）
手続きが発生する複数の単位と、日にちを特定する特定条件とを指定した入力を受け付け、
前記複数の単位の順を入れ替えて生成した訪問順序の候補において、前記特定条件を満たす候補に対して、該単位毎の処理件数を合計して総処理件数を算出し、
算出した前記総処理件数が少ない順に前記候補を出力する
処理をコンピュータが行う順序情報提供方法。
（付記６）
端末と、サーバ装置とがネットワークを介して接続される順序情報提供システムにおいて、
前記端末が、
手続きが発生する複数の単位と、日にちを特定する特定条件とを指定した入力を送信する入力送信部を有し、
前記サーバ装置が、
前記複数の単位の順を入れ替えて生成した訪問順序の候補において、前記特定条件を満たす候補に対して、該単位毎の処理件数を合計して総処理件数を算出する算出部と、
算出した前記総処理件数が少ない順に前記候補を出力して、前記端末に送信する候補決定部とを有する
ことを特徴とする順序情報提供システム。
２ ネットワーク
３ ユーザ端末
４ 訪問条件
５ 検索結果（順路候補）
１１ａ、１１ｂ ＣＰＵ
１２ａ、１２ｂ 主記憶装置
１３ａ 補助記憶装置
１４ａ 入力装置
１５ａ 表示装置
１６ｂ ユーザＩ／Ｆ
１７ａ、１７ｂ 通信Ｉ／Ｆ
１８ａ、１８ｂ ドライブ
１９ａ、１９ｂ 記憶媒体
３１ 戸籍課履歴ＤＢ
３２ 市民課履歴ＤＢ
３３ 国民健康保険課履歴ＤＢ
５０ 自治体業務処理部
６０ 順路候補提供部
６１ 訪問条件受信部
６２ 窓口特定部
６３ 推奨日時抽出部
６４ 混雑状況算出部
６５ 順路候補決定部
７１ 手続き情報テーブル
７２ 課情報テーブル
７３ カレンダー情報ＤＢ
７４ 天気予報情報ＤＢ
１００ サーバ装置
１３０ 記憶部

Claims (8)

  1. 複数の手続きと、日にちを特定する特定条件とを指定した入力を受け付け、
    各単位の処理件数を時間単位毎に記録した履歴データベースを参照して、判断基準に基づいて、前記入力で受け付けた前記複数の手続に対応する複数の単位それぞれの、処理件数の少ない日にち及び時間帯を取得して、該日にち及び時間帯に基づいて、前記複数の単位の順を入れ替えて候補を生成し、
    前記複数の単位の順を入れ替えて生成した訪問順序の候補において、前記特定条件を満たす候補に対して、該単位毎の処理件数を合計して総処理件数を算出し、
    算出した前記総処理件数が少ない順に前記候補を出力する
    処理をコンピュータに実行させる順序情報提供プログラム。
  2. 前記コンピュータに、
    前記入力で指定される各手続きに対応する単位を、該手続きと該単位とを対応付けた手続き情報テーブルを参照することにより特定する
    処理を実行させることを特徴とする請求項１記載の順序情報提供プログラム。
  3. 特定の手続きが前記入力で指定されている場合、該特定の手続きが発生する単位を１番目とする
    処理を前記コンピュータに実行させることを特徴とする請求項２記載の順序情報提供プログラム。
  4. 複数の手続きと、日にちを特定する特定条件とを指定した入力を受け付け、
    各単位の処理件数を時間単位毎に記録した履歴データベースを参照して、判断基準に基づいて、前記入力で受け付けた前記複数の手続に対応する複数の単位それぞれの、処理件数の少ない日にち及び時間帯を取得して、該日にち及び時間帯に基づいて、前記複数の単位の順を入れ替えて候補を生成し、
    前記複数の単位の順を入れ替えて生成した訪問順序の候補において、前記特定条件を満たす候補に対して、該単位毎の処理件数を合計して総処理件数を算出し、
    算出した前記総処理件数が少ない順に前記候補を出力する
    処理をコンピュータが行う順序情報提供方法。
  5. 端末と、サーバ装置とがネットワークを介して接続される順序情報提供システムにおいて、
    前記端末が、
    複数の手続きと、日にちを特定する特定条件とを指定した入力を送信する入力送信部を有し、
    前記サーバ装置が、
    各単位の処理件数を時間単位毎に記録した履歴データベースを参照して、判断基準に基づいて、前記入力で受け付けた前記複数の手続に対応する複数の単位それぞれの、処理件数の少ない日にち及び時間帯を取得して、該日にち及び時間帯に基づいて、前記複数の単位の順を入れ替えて候補を生成する候補生成部と、
    前記複数の単位の順を入れ替えて生成した訪問順序の候補において、前記特定条件を満たす候補に対して、該単位毎の処理件数を合計して総処理件数を算出する算出部と、
    算出した前記総処理件数が少ない順に前記候補を出力して、前記端末に送信する候補決定部とを有する
    ことを特徴とする順序情報提供システム。
  6. 複数の手続きと、日にちを特定する特定条件とを指定した入力を受け付け、
    前記入力で指定される前記複数の手続きに対応する複数の単位を、該手続きと該単位とを対応付けた手続き情報テーブルを参照することにより特定し、
    各単位の処理件数を時間単位毎に記録した履歴データベースを参照して、判断基準に基づいて処理件数の少ない日にち及び時間帯を取得して、該日にち及び時間帯に基づいて、特定した前記複数の単位の順を入れ替えて候補を生成し、
    前記複数の単位の順を入れ替えて生成した訪問順序の候補において、前記特定条件を満たす候補に対して、該単位毎の処理件数を合計して総処理件数を算出し、
    算出した前記総処理件数が少ない順に前記候補を出力する
    処理をコンピュータに実行させる順序情報提供プログラム。
  7. 手続きと、日にちを特定する特定条件とを指定した入力を受け付け、
    前記入力で指定される前記手続きに対応する複数の単位を、該手続きと該単位とを対応付けた手続き情報テーブルを参照することにより特定し、
    各単位の処理件数を時間単位毎に記録した履歴データベースを参照して、判断基準に基づいて処理件数の少ない日にち及び時間帯を取得して、該日にち及び時間帯に基づいて、特定した前記複数の単位の順を入れ替えて候補を生成し、
    前記複数の単位の順を入れ替えて生成した訪問順序の候補において、前記特定条件を満たす候補に対して、該単位毎の処理件数を合計して総処理件数を算出し、
    算出した前記総処理件数が少ない順に前記候補を出力する
    処理をコンピュータに実行させる順序情報提供方法。
  8. 手続きと、日にちを特定する特定条件とを指定した入力を受け付ける受付部と、
    前記入力で指定される前記手続きに対応する複数の単位を、該手続きと該単位とを対応付けた手続き情報テーブルを参照することにより特定する特定部と、
    各単位の処理件数を時間単位毎に記録した履歴データベースを参照して、判断基準に基づいて処理件数の少ない日にち及び時間帯を取得して、該日にち及び時間帯に基づいて、特定した前記複数の単位の順を入れ替えて候補を生成する生成部と、
    前記複数の単位の順を入れ替えて生成した訪問順序の候補において、前記特定条件を満たす候補に対して、該単位毎の処理件数を合計して総処理件数を算出する算出部と、
    算出した前記総処理件数が少ない順に前記候補を出力する出力部と、
    を有する順序情報提供装置。
JP2014198596A 2014-09-29 2014-09-29 順序情報提供プログラム、方法、システム、及び装置 Active JP6432253B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2014198596A JP6432253B2 (ja) 2014-09-29 2014-09-29 順序情報提供プログラム、方法、システム、及び装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2014198596A JP6432253B2 (ja) 2014-09-29 2014-09-29 順序情報提供プログラム、方法、システム、及び装置

Publications (2)

Publication Number Publication Date
JP2016071515A JP2016071515A (ja) 2016-05-09
JP6432253B2 true JP6432253B2 (ja) 2018-12-05

Family

ID=55866917

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2014198596A Active JP6432253B2 (ja) 2014-09-29 2014-09-29 順序情報提供プログラム、方法、システム、及び装置

Country Status (1)

Country Link
JP (1) JP6432253B2 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022074722A1 (ja) * 2020-10-06 2022-04-14 日本電気株式会社 情報処理システム、情報処理方法及びプログラム記憶媒体

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003047783A (ja) * 2001-05-24 2003-02-18 Matsushita Electric Ind Co Ltd アトラクション利用スケジュール構築装置、予約情報入力装置及びそれらを用いたシステム
JP2004102437A (ja) * 2002-09-05 2004-04-02 Funai Electric Co Ltd 施設利用者支援システム及び施設利用者支援サーバ
JP2006134260A (ja) * 2004-11-09 2006-05-25 Nec Commun Syst Ltd モデルコース配信システムおよびモデルコース配信方法
JP5405222B2 (ja) * 2009-07-16 2014-02-05 株式会社東芝 健診支援システム
GB201216133D0 (en) * 2012-09-11 2012-10-24 Hassan Gokhan Theme park queue/guest management, park loading & navigation system
JP6172981B2 (ja) * 2013-03-14 2017-08-02 日本ソフトウェアマネジメント株式会社 窓口の巡回経路を算出する装置、業務端末および複数窓口連携システム

Also Published As

Publication number Publication date
JP2016071515A (ja) 2016-05-09

Similar Documents

Publication Publication Date Title
Cordeau et al. Improved tabu search algorithm for the handling of route duration constraints in vehicle routing problems with time windows
WO2019184833A1 (zh) 旅游信息推荐方法和装置
Fleischman et al. Predicting ambulance time of arrival to the emergency department using global positioning system and Google maps
JP6828682B2 (ja) 情報処理装置、情報処理方法、およびプログラム
JP2018180815A (ja) 融資額判定システム、融資額判定方法、及びそのプログラム
Devasahay et al. Predicting appointment misses in hospitals using data analytics
ES2926005T3 (es) Sistema y método para entregar contenido dinámicamente
Damas de Matos Firm heterogeneity and immigrant wage assimilation
JP2011221805A (ja) 情報投稿制御システム、情報投稿制御方法
JP5847122B2 (ja) 評価装置、情報提供システム、評価方法および評価プログラム
EP3293692A1 (en) Sales promotion processing system and sales promotion processing program
Lancee et al. Does rural origin affect immigrants' contact with natives? A study of Turks in six European countries
JP2009129308A (ja) サービス時間割当方法及びサービス時間割当装置
US10699252B2 (en) Schedule management method and schedule management device
JP6432253B2 (ja) 順序情報提供プログラム、方法、システム、及び装置
JP6649235B2 (ja) 業務支援システム、業務支援装置、及びプログラム
US20230079825A1 (en) Systems, methods, and user interfaces in a patent management system
JP5579308B1 (ja) 承認時間予測装置、承認時間予測方法及び承認時間予測プログラム
JP7146966B2 (ja) 情報処理装置、プログラム、および情報処理方法
KR20160107605A (ko) 가계부 서비스 제공 장치 및 방법
Handel et al. Association among emergency department volume changes, length of stay, and leaving before treatment complete
JP6839353B2 (ja) イベント管理装置、イベント管理プログラム、及びイベント管理方法
KR101745606B1 (ko) 지출 관리에 관한 정보를 제공하기 위한 방법, 시스템 및 비일시성의 컴퓨터 판독 가능한 기록 매체
JP6844157B2 (ja) 情報処理装置及びプログラム
Palmer et al. Modelling changes in healthcare demand through geographic data extrapolation

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20170605

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20180427

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20180508

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180709

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20181009

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20181022

R150 Certificate of patent or registration of utility model

Ref document number: 6432253

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150