(57)【要約】  生産側又は物流側でない者（荷主や第三者）で物流計画を立案することを可能とするための技術を提供すること。  受注情報取得部６１は、荷主Ｓ側の受注情報（顧客Ｃからの注文情報やベンダーＶ（製造供給元）への発注情報等）を、荷主端末３又はベンダー端末４から通信部１９を介して取得する。受注物流変換部６２は、取得された受注情報を、物流情報（ベンダーＶ（製造供給元）からの入荷情報、顧客Ｃへの出荷情報）に変換する。パラメータ取得部６３は、納期、コスト、及び品質（事故率）を少なくとも含むパラメータを、パラメータＤＢ７１から取得する。物流計画生成部６４は、受注物流変換部６２により変換された物流情報と、パラメータ取得部６３により取得されたパラメータとに基づいて、物流計画（いつ、どこに、誰が）を生成する。
2018155718.tif 000002
【特許請求の範囲】
【請求項１】
荷主側の受注情報を、荷主端末又はベンダー端末から取得する受注情報取得手段と、
取得された前記受注情報を、物流情報に変換する受注物流変換手段と、
納期、コスト、及び品質を少なくとも含むパラメータを取得するパラメータ取得手段と、
変換された前記物流情報と、取得された前記パラメータとに基づいて、物流計画を生成する物流計画生成手段と、
を備える情報処理システム。
【請求項２】
前記物流計画に基づく物流実績を取得する実績取得手段と、
前記物流計画と前記物流実績との比較結果に基づいて、前記荷主側で前記システムを導入するタイミングを報知する報知手段と、
をさらに備える請求項１に記載された情報処理システム。
【請求項３】
前記物流計画に基づく実際の物流実績を取得する実績取得手段と、
前記物流計画と前記物流実績との比較結果に基づいて、前記荷主の物流に関するレポートを作成するレポート作成手段と、
をさらに備える請求項１に記載された情報処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理システムに関する。
【背景技術】
【０００２】
近年、物流システムの重要性は、益々、高まっており、日々の生活において、物流システムは、欠かすことが出来ない重要な技術である。
そのため、物流システムを利用するためのコストや品質についても、人々の関心は高く、効率的に物流システムを運用する技術の開発が望まれている。
この点、物流業務の計画および計画に沿った作業の実行および実績を管理するための技術についても提案がなされている（例えば、特許文献１参照）。
上述の特許文献１に記載の技術によれば、複数の仕入先から部品を納入させ完成品を生産する際の部品の運搬を計画する。  このような技術は、生産者が物流側として物流計画を立案するような場合には、非常に有用である。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１４−２１４０２２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、上述の特許文献１に記載の技術は、生産側又は物流側の者しか物流計画を立案することができず、この為、生産側又は物流側でない者（荷主や第三者）は、各種各様なシミュレーションや分析等を通じ、物流マーケティング等を行うことができなかった。【０００５】
本発明は、このような状況に鑑みてなされたものであり、荷主側の上位の情報（受注情報）を下位の物流情報に変換することができるので、生産側又は物流側でない者（荷主や第三者）で物流計画を立案することを可能とするための技術を提供することを目的とする。
これにより、各種各様なシミュレーションや分析等を通じ、物流マーケティング等が可能になる。
【課題を解決するための手段】
【０００６】
上記目的を達成するため、本発明の一態様の情報処理システムは、
荷主側の受注情報（顧客からの注文情報や製造供給元への発注情報等）を、荷主端末又はベンダー（製造供給元）端末から取得する受注情報取得手段と、
取得された前記受注情報を、物流情報（製造供給元からの入荷情報、顧客への出荷情報）に変換する受注物流変換手段と、
納期、コスト、及び品質（事故率）を少なくとも含むパラメータを取得するパラメータ取得手段と、
変換された前記物流情報と、取得された前記パラメータとに基づいて、物流計画（いつ、どこに、誰が）を生成する物流計画生成手段と、
を備える。
【発明の効果】
【０００７】
本発明によれば、荷主側の上位の情報（受注情報）を下位の物流情報に変換することにより、物流側でない者（荷主や第三者）で物流計画を立案することを可能とするための技術を提供することができる。
【図面の簡単な説明】
【０００８】
【図１】本発明の一実施形態に係る情報処理システムの構成を示すブロック図である。
【図２】図１の情報処理システムのうち、本発明の一実施形態のサーバのハードウェア構成を示すブロック図である。
【図３】図２のサーバ、顧客端末、荷主端末、ベンダー端末及び物流業者端末の機能的構成例を示す機能ブロック図である。
【図４】図３のサーバが実行する物流計画生成処理に基づいて立案した物流計画を実施する物流サービスの全体像を示す図である。
【図５】図３のサーバが実行する物流計画生成処理の流れを説明するフローチャートである。
【図６】図３のサーバが実行する物流計画生成処理を実施するサービス提供者の行うサービスのうち、図４とは異なるサービスの一例を示す図である。
【発明を実施するための形態】
【０００９】
以下、本発明の実施形態について、図面を用いて説明する。
【００１０】
図１は、本発明の一実施形態に係る情報処理システムの構成を示している。
【００１１】
本実施形態の情報処理システムは、図１に示すように、荷物の輸送サービスの提供者により管理されるサーバ１と、ｍ人の（ｍは、１以上の任意の整数値）顧客Ｃの夫々により使用される顧客端末２−１乃至２−ｍと、ｍ人の（ｍは、１以上の任意の整数値）荷主Ｓの夫々により使用される荷主端末３−１乃至３−ｎと、ｍ人の（ｍは、１以上の任意の整数値）べンダーＶの夫々により使用されるべンダー端末４−１乃至４−ｐと、ｍ人の（ｍは、１以上の任意の整数値）物流業者Ｌの夫々において使用される物流業者端末５−１乃至５−ｍとを含むように構成される。
サーバ１と、顧客端末２−１乃至２−ｍの夫々と、荷主端末３−１乃至３−ｍの夫々と、べンダー端末４−１乃至４−ｍの夫々と、物流業者端末５−１乃至３−ｍの夫々とはインターネット等の所定のネットワークＮを介して相互に接続されている。
【００１２】
なお、以下、顧客端末２−１乃至２−ｍの夫々を個々に区別する必要がない場合、これらをまとめて「顧客端末２」と呼び、荷主端末３−１乃至３−ｍの夫々を個々に区別する必要がない場合、これらをまとめて「荷主端末３」と呼び、べンダー端末４−１乃至４−ｍの夫々を個々に区別する必要がない場合、これらをまとめて「べンダー端末４」と呼び、さらに、以下、物流業者端末５−１乃至５−ｍの夫々を個々に区別する必要がない場合、これらをまとめて「物流業者端末５」と呼ぶ。
ここで、本実施形態では、顧客Ｃ、荷主Ｓ、べンダーＶ、物流業者Ｌは、全て同人数として説明しているが、特にこれに限定されない。即ち、各者の人数は、異なっていて良い。
また、本実施形態では、顧客端末２、荷主端末３、ベンダー端末４及び物流業者端末５は、全て同数存在することとして説明しているが、特にこれに限定されない。即ち、各種端末の個数は、異なっていてもよく、本サービスの提供者が自由に設定することができる。
また、本実施形態では、ｍ人の顧客Ｃがｍ台の顧客端末２を使用するとして説明しているが、特にこれに限定されない。即ち、顧客Ｃと顧客端末２の数は異なっていてもよい。荷主Ｓと荷主端末３、ベンダーＶとベンダー端末４、物流業者Ｌと物流業者端末５についても同様である。
また、本発明における「べンダー」とは、商品の製造供給元のことをいう。
【００１３】
図２は、図１の情報処理システムのうちサーバ１のハードウェア構成を示すブロック図である。
【００１４】
サーバ１は、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）１１と、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）１２と、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）１３と、バス１４と、入出力インターフェース１５と、出力部１６と、入力部１７と、記憶部１８と、通信部１９と、ドライブ２０とを備えている。
【００１５】
ＣＰＵ１１は、ＲＯＭ１２に記録されている各種プログラム、又は、記憶部１８からＲＡＭ１３にロードされた各種プログラムに従って各種の処理を実行する。
ＲＡＭ１３には、ＣＰＵ１１が各種の処理を実行する上において必要なデータ等も適宜記憶される。
【００１６】
ＣＰＵ１１、ＲＯＭ１２及びＲＡＭ１３は、バス１４を介して相互に接続されている。このバス１４にはまた、入出力インターフェース１５も接続されている。入出力インターフェース１５には、出力部１６、入力部１７、記憶部１８、通信部１９及びドライブ２０が接続されている。
【００１７】
出力部１６は、各種液晶ディスプレイ等で構成され、各種情報を出力する。
入力部１７は、各種ハードウェア等で構成され、各種情報を入力する。
記憶部１８は、ハードディスクやＤＲＡＭ（Ｄｙｎａｍｉｃ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）等で構成され、各種データを記憶する。
通信部１９は、インターネットを含むネットワークＮを介して他の装置（例えば、図１の荷主端末３、物流業者端末５等）との間で行う通信を制御する。
【００１８】
ドライブ２０は、必要に応じて設けられる。ドライブ２０には磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリ等よりなる、リムーバブルメディア２１が適宜装着される。ドライブ２０によってリムーバブルメディア２１から読み出されたプログラムは、必要に応じて記憶部１８にインストールされる。またリムーバブルメディア２１は、記憶部１８に記憶されている各種データも、記憶部１８と同様に記憶することができる。
【００１９】
顧客端末２、荷主端末３、べンダー端末４及び物流業者端末５の構成は、サーバ１の構成と基本的に同様であるので、ここではそれらの説明は省略する。
【００２０】
このような図２のサーバ１、顧客端末２、荷主端末３、べンダー端末４及び物流業者端末５の各種ハードウェアと各種ソフトウェアとの協働により、次のような一連の処理（以下、「物流計画生成処理」と呼ぶ）の実行が可能となる。
【００２１】
即ち、所定の顧客Ｃが所有する顧客端末２−Ｐ（Ｐは１乃至ｍのうち何れかの整数値）は、当該顧客Ｃにより入力された情報を注文情報として受け付け、荷主端末３へと送信する。
ここで注文情報とは、注文対象の商品の種類、数量、納品先、注文対象の商品を納品先に納品する期日（以下、「納期」と呼ぶ）等の荷主及びサービス提供者の設定した所定の項目についての顧客の入力結果（要望、希望）に関する情報である。
次に、当該荷主端末３を所有する荷主Ｓが、注文情報に基づき、必要に応じて情報を入力すると、当該荷主端末３は当該入力された情報を発注情報として受け付け、当該注文情報と共にべンダー端末４及びサーバ１へと送信する。
ここで発注情報とは、発注対象の商品の種類、数量、納期等のべンダー及びサービス提供者の設定した所定の項目についての荷主の入力結果（要望、希望）に関する情報である。
なお、サービス提供者とは、物流計画生成サービスの提供者であり、上述の注文情報及び発注情報を基に、商品の配送における物流計画を生成する事業者等である。
サーバ１は、少なくとも、輸送対象となる商品の特性を示す情報（例えば、大きさ、重量、冷蔵・冷凍品か否か等の情報であり、以下、「荷物特性情報」と呼ぶ）、輸送を行う移動体の特徴を示す情報（例えば、４ｔ車か１０ｔ車等のサイズ、路線便や貸切便の種類等の情報であり、以下、「移動体特徴情報」と呼ぶ）を含む、荷物の輸送に関する各種情報、顧客からのフィードバック情報及び物流業者からのフィードバック情報を取得し、管理する。
さらに、サーバ１は、上述の各種情報（入荷情報、出荷情報）を変換して生成した入荷情報及び出荷情報を物流業者端末５へと送信する。
入荷情報とは、発注対象の商品の種類、数量、入荷先、入荷日等の物流業者及びサービス提供者の設定した所定の項目についての変換情報である。
出荷情報とは、発注対象の商品の種類、数量、納品先、納期等の物流業者及びサービス提供者の設定した所定の項目についての変換情報である。
そして、サーバ１は、取得したパラメータに基づいて、変換して得られた物流情報を構成する各入出荷のそれぞれについて物流業者を割り当てることにより、「いつ」、「どこに」、「誰が」についてを決定し、物流計画を生成する。サーバ１が、上述の「いつ」、「どこに」、「誰が」についてを決定する方法については、任意の方法を採ることが出来る。
【００２２】
このような一連の処理が物流計画生成処理である。この物流計画生成処理を実現すべく、サーバ１、顧客端末２、荷主端末３、べンダー端末４及び物流業者端末５は、図３に示すような機能的構成を有している。
図３は、図２のサーバ１、顧客端末２、荷主端末３、べンダー端末４及び物流業者端末５の機能的構成例を示す機能ブロック図である。
【００２３】
顧客端末２においては、注文部３１と、フィードバック部３２とが機能する。
荷主端末３においては、発注部４１が機能する。
べンダー端末４においては、受注部５１が機能する。
物流業者端末５においては、物流計画取得部８１と、実績記録部８２と、フィードバック部８３とが機能する。
サーバ１のＣＰＵ１１においては、受注情報取得部６１と、受注物流変換部６２と、パラメータ取得部６３と、物流計画生成部６４とが機能する。
サーバ１の記憶部１８の一領域として、パラメータＤＢ７１が設けられている。
【００２４】
顧客端末２の注文部３１は、図示せぬ入力部を介して、顧客Ｃの操作により入力された情報を、注文情報として受付ける。
即ち、注文部３１は、注文対象の商品の種類、数量、納品先、納期等の荷主及びサービス提供者の設定した所定の項目についての注文情報を受付ける。
更に注文部３１は、入力部により受付けられた注文情報を、図示せぬ通信部を介して荷主端末３へ送信するための制御を実行する。
この様にして、荷主端末３へと送信された注文情報は、荷主端末３によって取得される。そして、荷主端末３は、その注文情報と、在庫情報と組み合わせて、不足分を算出し、その算出した不足分を補う為に必要であると荷主端末３又は荷主Ｓが判断した分量に基づく情報を、発注情報として生成又は受付ける。更に発注部４１は、発注情報を、図示せぬ通信部を介してべンダー端末４及びサーバ１へ送信するための制御を実行する。これと同時に、注文情報を、図示せぬ通信部を介してサーバ１へ送信するための制御を実行する。
フィードバック部３２は、図示せぬ入力部を介して、顧客Ｃの操作により入力された物流業者Ｌに対する評価情報を、フィードバック情報として受付ける。
また、フィードバック部３２は、入力部により受付けられたフィードバック情報を、図示せぬ通信部を介してサーバ１へ送信するための制御を実行する。サーバ１ではフィードバック情報はパラメータＤＢ７１に蓄積される。
【００２５】
サーバ１の受注情報取得部６１は、荷主Ｓ側の受注情報（顧客Ｃからの注文情報やベンダーＶ（製造供給元）への発注情報等）を、荷主端末３又はベンダー端末４から通信部１９を介して取得する。
また、受注物流変換部６２は、取得された受注情報を、物流情報（ベンダーＶ（製造供給元）からの入荷情報、顧客Ｃへの出荷情報）に変換する。
具体的には、発注情報を入荷情報に、注文情報を出荷情報にそれぞれ変換する。
さらに、パラメータ取得部６３は、納期、コスト、及び品質（事故率）を少なくとも含むパラメータを、パラメータＤＢ７１から取得する。
【００２６】
物流計画生成部６４は、受注物流変換部６２により変換された物流情報と、パラメータ取得部６３により取得されたパラメータとに基づいて、物流計画（いつ、どこに、誰が）を生成する。
物流計画生成部６４は、生成した物流計画を、通信部１９を介して物流業者端末５に送信する。
実績取得部６５は、物流業者端末５から送信されてきた物流実績を、通信部１９を介して取得する。
報知部６６は、物流計画と物流実績との比較結果に基づいて、荷主Ｓ側で本発明に係るシステムを導入するタイミングを報知する。
レポート作成部６７は、物流計画と物流実績との比較結果に基づいて、荷主Ｓの物流に関するレポートを作成する。
【００２７】
物流業者端末５の物流計画取得部８１は、少なくとも、入荷情報及び出荷情報を含む荷物の輸送に関する各種情報を取得し、管理する。
実績記録部８２は、入荷情報及び出荷情報に基づく配送実績に関する各種情報を記録し、更に送信するための制御を実行する。
フィードバック部８３は、図示せぬ入力部を介して、物流業者Ｌの操作により入力された荷主Ｓに対する評価情報を、フィードバック情報として受付ける。
また、フィードバック部８３は、入力部により受付けられたフィードバック情報を、図示せぬ通信部を介してサーバ１へ送信するための制御を実行する。サーバ１ではフィードバック情報はパラメータＤＢ７１に蓄積される。
【００２８】
次に、図４を用いて、サービス提供者の提供するサービスの一例について説明する。
【００２９】
図４は、図３のサーバが実行する物流計画生成処理を実施するサービス提供者の行うサービスの一例を示す図である。
図４を見ると、顧客Ｃと、荷主Ｓと、ベンダーＶと、物流業者Ｌと、サーバ１と、荷主端末３と、物流業者端末５と、配送情報ＤＩと、商品Ｇと、移動体Ｔが存在する。
【００３０】
更にサーバ１には、受注情報取得部６１と、物流計画生成部６４とが内在する。
更に荷主端末３は、注文情報ＯＩ１と、発注情報ＯＩ２を包含する。
更に物流業者端末５は、入荷情報ＡＩと、出荷情報ＳＩを包含する。
顧客Ｃは、図示せぬ顧客端末２を操作して、注文情報ＯＩ１を荷主端末３に送信し、商品Ｇの提供を要求する。商品Ｇを受け取ると、配送情報ＤＩ及び物流業者Ｌに対する評価情報をフィードバック情報として、サーバ１に送信する。配送情報ＤＩは顧客端末２を操作してサーバ１で生成しても良い。
【００３１】
荷主Ｓは、荷主端末３を操作して、注文情報ＯＩ１に応じて発注情報ＯＩ２を生成し、ベンダーＶに商品Ｇを供給させ、物流業者Ｌに商品Ｇを配送させる。
ベンダーＶは、発注情報ＯＩ２に応じて商品Ｇを供給し、物流業者Ｌに引き渡す。
【００３２】
物流業者Ｌは、入荷情報ＡＩに応じてベンダーＶから商品Ｇを受け取り、荷主Ｓに対する評価情報をフィードバック情報として、サーバ１に送信する。また、移動体Ｔに商品Ｇを積載し、出荷情報ＳＩに応じて顧客Ｃに配送する。
サービス提供者は、まず、荷主端末３等から注文情報ＯＩ１と、発注情報ＯＩ２をサーバ１に受信させ、入荷情報ＡＩと、出荷情報ＳＩに変換する。次に、顧客Ｃ、荷主Ｓ及び物流業者Ｌの要望に応じていつ、どこに、誰が移動体Ｔを向かわせるのかを、決定するサービス（物流計画生成処理）を実施する。
【００３３】
本サービスを利用する荷主Ｓ等のユーザは、商品Ｇの配送に際して、荷主Ｓ側の上位の情報（受注情報）を下位の物流情報変換することができるので、物流側でない者（荷主や第三者）で物流計画を立案することができる。
これにより、各種各様なシミュレーションや分析等を通じ、物流マーケティング等が可能になる。事前に輸送物流計画の生成（試算）をすることができるため、複数の輸送ルートや条件に応じて、最適な輸送方法を選択することができるのである。
【００３４】
次に、図５を参照して、図３の機能的構成を有するサーバ１が実行する物流計画生成処理について説明する。
図５は、サーバ１が実行するルート決定処理の流れを説明するフローチャートである。
【００３５】
ステップＳ１において、受注情報取得部６１は、荷主側の受注情報（注文情報や発注情報等）を取得する。
ステップＳ２において、サーバ１のＣＰＵ１１は、受注情報の取得に成功したか判定する。
荷主端末３−１乃至３−ｍの何れからも受注情報が送信されてこなければ、ステップＳ２においてＮＯであると判定されて、処理はステップＳ１に戻される。
これに対して、荷主端末３−Ｐから受注情報が送信されていれば、ステップＳ２においてＹＥＳであると判定されて、処理はステップＳ３に進む。
【００３６】
ステップＳ３において、受注物流変換部６２は、取得された受注情報を、物流情報（製造供給元からの入荷情報、顧客への出荷情報）に変換する。
ステップＳ４において、パラメータ取得部６３は、納期、コスト、及び品質（事故率）を少なくとも含むパラメータを取得する。
【００３７】
ステップＳ５において、物流計画生成部６４は、ステップＳ３で変換された物流情報と、ステップＳ４で取得されたパラメータとに基づいて、物流計画（いつ、どこに、誰が）を生成する。
なお、前述の通り、物流計画生成部６４が物流計画を生成するための手法は、特に限定されず、サービス提供者が自由に選択することができる。
さらに、ステップＳ６において、サーバ１のＣＰＵ１１は、処理の終了指示が有ったか否かを判断する。ここで、処理の終了指示は、特に限定されないが、本実施形態ではサーバ１の電源遮断が採用されている。つまり、サーバ１において電源が遮断されると、ステップＳ６においてＹＥＳであると判断されて、サーバ１の処理は終了になる。
これに対して、サーバ１において電源が遮断されない限り、ステップＳ６においてＮＯであると判断されて処理はステップＳ１に戻され、それ以降の処理が繰り返される。
【００３８】
以上、本発明の実施形態について説明したが、本発明は前述した実施形態に限るものではない。
また、本実施形態に記載された効果は、本発明から生じる最も好適な効果を列挙に過ぎず、本発明による効果は、本実施形態に記載されたものに限定されるものではない。
【００３９】
上述の実施形態では、注文情報として、商品の種類、数量、納品先、納期の項目を選択していたが、これらは説明のための例示に過ぎず、特にこれに限定されない。
【００４０】
また、例えば、上述の実施形態では、発注情報として、例えば、発注対象の商品の種類、数量、納期等の情報が例示されているが、これらは説明のための例時に過ぎず、特にこれに限定されない。
【００４１】
また、例えば、上述の実施形態では、移動体特徴情報として、例えば、その移動体の容量（４ｔ車か１０ｔ車等のサイズ）の情報や路線便や貸切便の種類等の情報が例示されているが、これらは説明のための例示に過ぎず、特にこれに限定されない。
例えば、移動体の車種や燃費等、移動体の特徴を示すいかなる情報を利用することもできる。
また例えば、移動体情報には、その移動体の運転手の情報、例えば運転手のコンプライアンス（労働条件を含む）も含めることができる。
さらに言えば、物流計画の生成に、入力情報、荷物特性情報及び移動体特徴情報以外の全く異なる情報を組み合わせて物流計画を生成することも出来る。
【００４２】
また、例えば、上述の実施形態では、物流計画の生成方法について、特段言及をしていないが、サービス提供者は、どのような方法により物流計画の生成を行っても良い。
例えば、特定の条件を満たした場合には荷役料を割り引くという設定を追加したり、特定の地方で荷物を保管する場合には、保管料を割り引くという設定を追加することも出来る。
このように、サービス提供者は、自身のサービスに最適な方法で物流計画の生成を行うことで、よりユーザにとって利便なサービスを提供することができる。
【００４３】
また、例えば、物流計画の候補は、複数でも構わない。
物流計画の候補が複数ある場合には、同一画面に複数の物流計画の候補を表示させてもよいし、別途、他の物流計画の候補を表示させてもよい。
【００４４】
また、上述の実施形態では、本発明の情報処理装置は、サーバ１、顧客端末２、荷主端末３、ベンダー端末４、物流業者端末５により構成されていたが、本発明の目的を達成するための例示に過ぎず、特に限定されない。
例えば、集荷拠点や移動体Ｔに端末を設置し、本発明の構成に加えることもできる。
【００４５】
また、倉庫会社に端末を設置して、本発明の構成に加えることもできる。
この場合、例えば上述の物流計画生成処理を実行するサービス提供者の行うサービスとして、図４の例とは異なるサービスを提供することができる。そこで、以下、図６を参照しつつ、図４とは異なるサービスの例について説明する。
【００４６】
図６は、図３のサーバ１が実行する物流計画生成処理を実施するサービス提供者の行うサービスのうち、図４とは異なるサービスの一例を示す図である。
【００４７】
図６を見ると、顧客Ｃと、ベンダーＶと、倉庫会社Ｂと、物流業者Ｌとが存在する。顧客Ｃと、ベンダーＶと、倉庫会社Ｂと、物流業者Ｌとの夫々は、顧客端末２と、ベンダー端末４と、倉庫会社端末６と、物流業者端末５との夫々を操作することで各種の処理を行う。
【００４８】
図６に示すサービスの概要は、まず顧客ＣからベンダーＶに対し商品Ａ（図示せず）について注文がなされると、ベンダーＶが商品Ａを製造する。ベンダーＶによって製造された商品Ａは、倉庫会社Ｂにおいて保管、荷役、流通加工、包装等され、物流業者Ｌによって顧客Ｃに届けられる。
【００４９】
即ち、図６には図示しないが、サーバ１の受注情報取得部６１は、荷主Ｓ側の受注情報（顧客Ｃからの注文情報やベンダーＶ（製造供給元）への発注情報等）を、荷主端末３又はベンダー端末４から通信部１９を介して取得する。
また、受注物流変換部６２は、取得された受注情報を、物流情報に変換する。
図６の例では、物流情報には、物流業者Ｌが利用する情報の他、倉庫会社Ｂが利用する情報も含まれる。
物流業者Ｌが利用する情報は、トラックによる貨物の積込み場所が、上述の他の例の場合ベンダーＶの指定場所であったものが、図６の例では倉庫会社Ｂにより管理される倉庫になる点では異なるが、その他の点は同様である。つまり、納期、コスト、及び品質（事故率）に基づき、物流計画（いつ、どこに、誰が）が生成される。
倉庫会社Ｂが利用する情報は、倉庫の在庫に関する情報を含む、保管、荷役、流通加工、包装等に必要な各種情報である。具体的には例えば、次のような在庫管理システムで用いる情報が、倉庫会社Ｂが利用する情報の一例である。
【００５０】
ここで、倉庫会社Ｂの倉庫会社端末６は、商品Ａを含む、倉庫会社Ｂの倉庫で保管している商品すべてについて、サーバ１が提供する在庫管理システムを利用して管理している。
在庫管理システムは、倉庫会社Ｂの倉庫の稼働率に関する情報から、倉庫会社Ｂの倉庫に、貨物を保管するための空きスペースがどの程度存在するのかを演算し、演算により得られた情報を倉庫稼働情報として管理する。
また、在庫管理システムは、商品Ａを含む、倉庫会社Ｂの倉庫で保管している商品すべてについての荷動きを定期観測し、季節性の需要要因を商品毎に把握する。在庫管理システムは、この季節性の需要要因に関する情報を、季節情報として管理する。例えば、商品が缶ジュースであれば、夏季に荷動きが盛んであるという情報が、季節性の需要要因に関する情報として管理される。また、商品がお餅であれば、正月付近に荷動きが盛んであるという情報が、季節性の需要要因に関する情報として管理される。
在庫管理システムは、倉庫稼働情報と、季節情報とに基づいて、倉庫毎の稼働率を上げることを支援する支援情報を生成する。
生成された支援情報は、倉庫会社端末６を介して倉庫会社Ｂに提供される。
【００５１】
また、倉庫の稼働率が落ちそうな場合や、既に落ちている場合に、倉庫の空きスペースの利用に関する情報を、顧客端末２を介して顧客Ｃに提供してもよい。例えば、倉庫の空きスペースを、物流上のＨＵＢ（ハブ）として一定期間（例えば３か月等の短期間）利用できるようにしてもよい。倉庫料金は、サービス提供者及びサービス利用者のネットワークを活用したオークション形式としてもよい。
このように、これまで顧客Ｃと、ベンダーＶと、倉庫会社Ｂと、物流業者Ｌとの夫々でバラバラに管理されていた情報をシステムに一極集中させることにより、倉庫業者Ｂの倉庫の空きスペースの短期的な有効利用を図ることができる。その結果、倉庫の空きスペースを、物流上のＨＵＢ（ハブ）として活用することもできるので、パンク状態にある路線業者を含む物流業者Ｌの輸送の効率化を図ることができる。
【００５２】
また、図２に示す各ハードウェア構成は、本発明の目的を達成するための例示に過ぎず、特に限定されない。
【００５３】
また、図３に示す機能ブロック図は、例示に過ぎず、特に限定されない。即ち、上述した一連の処理を全体として実行できる機能が情報処理システムに備えられていれば足り、この機能を実現するためにどのような機能ブロックを用いるのかは、特に図３の例に限定されない。
【００５４】
また、機能ブロックの存在場所も、図３に限定されず、任意で良い。例えばサーバ１側の機能ブロックの少なくとも一部を顧客端末２、荷主端末３、べンダー端末４、物流業者端末５のいずれかの側に設けても良いし、その逆でも良い。
そして、１つの機能ブロックは、ハードウェア単体で構成しても良いし、ソフトウェア単体との組み合わせで構成しても良い。
【００５５】
また、上述の実施形態では顧客端末２、荷主端末３、べンダー端末４及び物流業者端末５はスマートフォンで構成されていたが、スマートフォンだけでなく、タブレットや今後の新しいデバイスを含めた任意の装置で構成することもできる。
【００５６】
各機能ブロックの処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、コンピュータ等にネットワークや記録媒体からインストールされる。
コンピュータは、専用のハードウェアに組み込まれているコンピュータであっても良い。また、コンピュータは、各種のプログラムをインストールすることで、各種の機能を実行することが可能なコンピュータ、例えばサーバの他汎用のスマートフォンやパーソナルコンピュータであっても良い。
【００５７】
このようなプログラムを含む記録媒体は、各ユーザにプログラムを提供するために装置本体とは別に配布される、リムーバブルメディアにより構成されるだけではなく、装置本体に予め組み込まれた状態で各ユーザに提供される記録媒体等で構成される。
【００５８】
なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、その順序に添って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的或いは個別に実行される処理をも含むものである。
【００５９】
以上まとめると、本発明が適用される情報処理装置は、次のような構成を取れば足り、各種各様な実施形態を取ることができる。
即ち、本発明が適用される情報処理システムは、
荷主側の受注情報（顧客からの注文情報や製造供給元への発注情報等）を、荷主端末又はベンダー（製造供給元）端末から取得する受注情報取得手段（例えば、図３の受注情報取得部６１）と、
取得された前記受注情報を、物流情報（製造供給元からの入荷情報、顧客への出荷情報）に変換する受注物流変換手段（例えば、図３の受注物流変換部６２）と、
納期、コスト、及び品質（事故率）を少なくとも含むパラメータを取得するパラメータ取得手段（例えば、図３のパラメータ取得部６３）と、
変換された前記物流情報と、取得された前記パラメータとに基づいて、物流計画（いつ、どこに、誰が）を生成する物流計画生成手段（例えば、図３の物流計画生成部６４）と、
を備える情報処理装置であれば足りる。
このような情報処理装置を適用することで、サービス提供者は、荷主側の上位の情報（受注情報）を下位の物流情報変換することができるので、物流側でない者（荷主Ｓや第三者）で物流計画を立案する際の物流計画を生成する技術を提供することができる。
これにより、各種各様なシミュレーションや分析等を通じ、物流マーケティング等が可能になるのである。
【符号の説明】
【００６０】
１・・・サーバ、２、２−１乃至２−ｍ・・・顧客端末、３、３−１乃至３−ｍ・・・荷主端末、４、４−１乃至４−ｍ・・・べンダー端末、５、５−１乃至５−ｍ・・・物流業者端末、１１・・・ＣＰＵ、１８・・・記憶部、１９・・・通信部、３１・・・注文部、３２・・・フィードバック部、４１・・・発注部、５１・・・受注部、６１・・・受注情報取得部、６２・・・受注物流変換部、６３・・・パラメータ取得部、６４・・・物流計画生成部、６５・・・実績取得部、６６・・・報知部、６７・・・レポート作成部、７１・・・パラメータＤＢ、８１・・・物流計画取得部、８２・・・実績記録部、８３・・・フィードバック部、Ｃ・・・顧客、Ｓ・・・荷主、Ｖ・・・べンダー、Ｌ・・・物流業者、Ｇ・・・商品、Ｔ・・・移動体
【図１】
2018155718.tif 000003
【図２】
2018155718.tif 000004
【図３】
2018155718.tif 000005
【図４】
2018155718.tif 000006
【図５】
2018155718.tif 000007
【図６】
2018155718.tif 000008
【国際調査報告】
2018155718.tif 000009
2018155718.tif 000010
2018155718.tif 000011
2018155718.tif 000012