IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社グーフの特許一覧

<>
  • 特許-印刷発注システム及びプログラム 図1
  • 特許-印刷発注システム及びプログラム 図2
  • 特許-印刷発注システム及びプログラム 図3
  • 特許-印刷発注システム及びプログラム 図4
  • 特許-印刷発注システム及びプログラム 図5
  • 特許-印刷発注システム及びプログラム 図6
  • 特許-印刷発注システム及びプログラム 図7
  • 特許-印刷発注システム及びプログラム 図8
  • 特許-印刷発注システム及びプログラム 図9
  • 特許-印刷発注システム及びプログラム 図10
  • 特許-印刷発注システム及びプログラム 図11
  • 特許-印刷発注システム及びプログラム 図12
  • 特許-印刷発注システム及びプログラム 図13
  • 特許-印刷発注システム及びプログラム 図14
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-03-31
(45)【発行日】2022-04-08
(54)【発明の名称】印刷発注システム及びプログラム
(51)【国際特許分類】
   G06Q 50/10 20120101AFI20220401BHJP
   G05B 19/418 20060101ALI20220401BHJP
【FI】
G06Q50/10
G05B19/418 Z
【請求項の数】 6
(21)【出願番号】P 2019144482
(22)【出願日】2019-08-06
(65)【公開番号】P2021026535
(43)【公開日】2021-02-22
【審査請求日】2020-07-03
(73)【特許権者】
【識別番号】515067457
【氏名又は名称】株式会社グーフ
(74)【代理人】
【識別番号】100103528
【弁理士】
【氏名又は名称】原田 一男
(72)【発明者】
【氏名】岡本 幸徳
【審査官】渡邉 加寿磨
(56)【参考文献】
【文献】特開2013-206384(JP,A)
【文献】特開2004-54910(JP,A)
【文献】特開2002-32641(JP,A)
【文献】特開2010-9596(JP,A)
【文献】特開2012-128794(JP,A)
【文献】特開2001-322339(JP,A)
【文献】特開2007-72900(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06Q 10/00-99/00
G16H 10/00-80/00
B41J 29/38
G05B 19/418
G06F 3/12
(57)【特許請求の範囲】
【請求項1】
工場に印刷を発注する印刷発注システムであって、
工場毎の用紙在庫のデータと、実際に使用された用紙の種類及び量のデータとを、工場のコンピュータから収集した情報に基づき特定し、データ格納部に格納する手段と、
ユーザの端末から受信した印刷の依頼に対して、前記データ格納部に格納されている前記工場毎の用紙在庫のデータに少なくとも基づき、発注先の工場を決定し、前記印刷の依頼に対する発注に関するデータを、前記データ格納部に蓄積する手段と、
前記データ格納部に格納されている、前記実際に使用された用紙の種類及び量のデータを、前記実際に使用された用紙を供給した用紙供給元又は他の事業者のコンピュータに送信する手段と、
前記データ格納部に蓄積された前記発注に関するデータと、前記工場のコンピュータから収集した情報に基づき特定される、印刷の依頼毎又は印刷ジョブ毎の実際に使用された用紙の種類及び量のデータとに基づき、用紙の需要予測を実行する手段と、
を有する印刷発注システム。
【請求項2】
前記他の事業者は、印刷を受注した事業者を含む
請求項1記載の印刷発注システム。
【請求項3】
前記用紙の需要予測を実行する手段は、
工場別、印刷を受注する事業者別、又は用紙供給元別に、用紙の需要予測を実行する
請求項1又は2記載の印刷発注システム。
【請求項4】
前記発注先の工場を決定する手段が、
前記ユーザについて予め登録されている又は前記印刷の依頼に含まれる要求仕様を満たす工場を特定する手段と、
特定された前記工場が、前記印刷の依頼を実行するのに十分な用紙の在庫を有しているか否かを、前記データ格納部に格納されている用紙在庫のデータを参照して判断する手段と、
特定された前記工場が前記印刷の依頼を実行するのに十分な用紙の在庫を有していない場合、特定された前記工場に対して用紙を供給する用紙供給元から当該工場への配送にかかる時間を加味して、用紙の補充に伴う納期の超過時間を予測する手段と、
予測された前記超過時間が、前記要求仕様に予め含まれる、納期遅れの許容期間以内であるか否かを判断する手段と、
予測された前記超過時間が前記納期遅れの許容期間以内である場合には、特定された前記工場を発注先の工場として決定し、当該工場のコンピュータに前記印刷の依頼についてデータを送信する手段と、
を有する請求項1乃至3のいずれか1つ記載の印刷発注システム。
【請求項5】
工場に印刷を発注する印刷発注システムに、
工場毎の用紙在庫のデータと、実際に使用された用紙の種類及び量のデータとを、工場のコンピュータから収集した情報に基づき特定し、データ格納部に格納するステップと、
ユーザの端末から受信した印刷の依頼に対して、前記データ格納部に格納されている前記工場毎の用紙在庫のデータに少なくとも基づき、発注先の工場を決定し、前記印刷の依頼に対する発注に関するデータを、前記データ格納部に蓄積するステップと、
前記データ格納部に格納されている、前記実際に使用された用紙の種類及び量のデータを、前記実際に使用された用紙を供給した用紙供給元又は他の事業者のコンピュータに送信するステップと、
前記データ格納部に蓄積された前記発注に関するデータと、前記工場のコンピュータから収集した情報に基づき特定される、印刷の依頼毎又は印刷ジョブ毎の実際に使用された用紙の種類及び量のデータとに基づき、用紙の需要予測を実行するステップと、
を実行させるためのプログラム。
【請求項6】
工場毎の用紙在庫のデータと、実際に使用された用紙の種類及び量のデータとを、工場のコンピュータから収集した情報に基づき特定し、データ格納部に格納するステップと、
ユーザの端末から受信した印刷の依頼に対して、前記データ格納部に格納されている前記工場毎の用紙在庫のデータに少なくとも基づき、発注先の工場を決定し、前記印刷の依頼に対する発注に関するデータを、前記データ格納部に蓄積するステップと、
前記データ格納部に格納されている、前記実際に使用された用紙の種類及び量のデータを、前記実際に使用された用紙を供給した用紙供給元又は他の事業者のコンピュータに送信するステップと、
前記データ格納部に蓄積された前記発注に関するデータと、前記工場のコンピュータから収集した情報に基づき特定される、印刷の依頼毎又は印刷ジョブ毎の実際に使用された用紙の種類及び量のデータとに基づき、用紙の需要予測を実行するステップと、
を含み、工場に印刷を発注する印刷発注システムにより実行される方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、印刷発注システム及びプログラムに関する。
【背景技術】
【0002】
現在、インターネットを通じて印刷の依頼を受け付け、指定された配送先に指定された期日に印刷物を納品するサービスが実用化されている。
このサービスを実現する手法には、印刷を受け付けた事業者が自社の印刷設備を用いて対応する手法、受け付けた依頼を提携する複数の印刷事業者に提供し、最初に受託を表明した印刷事業者に印刷を発注する手法などがある。
この他、特許文献1(特開2013-16159号公報)には、インターネットを通じて印刷の依頼を受け付けた事業者が提携する印刷事業者の中から最適な一社を選択して発注するシステムが記載されている。
【先行技術文献】
【特許文献】
【0003】
【文献】特開2013-16159号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
現在、事業として印刷物を印刷する印刷事業者は、製紙会社から買い取った用紙を工場内で保管し、例えば受注の見込みと用紙の在庫量とに基づいて、製紙会社に発注する用紙の数量を決定している。このように、印刷事業者における用紙の購入は印刷の受注に先立って行われており、見込み通りの受注が得られなかった場合、用紙の代金を回収できるまでの期間が長くなり、経営上の負担となる。このため、用紙の発注がギリギリになる傾向がある。一方、製紙会社には、受注の度に遅滞なく用紙を配送することが求められるが、用紙の受注が集中した場合、用紙の配送に用いるトラックの手配が難しくなる。また、製紙会社は計画的に用紙を製造するため、急な発注への対応が難しいことがある。
このため、印刷事業者と製紙会社の双方の利益に供するビジネスモデルが求められる。
【0005】
本発明は、各工場が用紙の在庫を個別に管理して用紙の供給元に用紙を発注し、用紙の発注を受け付けた用紙の供給元が個別に用紙を配送する場合とは異なり、用紙の種類別の使用量の管理を可能にすることを目的とする。
【課題を解決するための手段】
【0006】
第1の発明は、工場に印刷を発注する印刷発注システムであって、工場から収集される情報に基づいて、工場で使用された用紙の種類と使用された用紙の量を特定し、特定された用紙の種類と用紙の量を、使用された用紙の供給元に送信する印刷発注システムである。
第2の発明は、特定された用紙の種類と用紙の量は、印刷の発注別、印刷ジョブ別、印刷装置別、工場別、又は、印刷を受注する事業者別に集計される、第1の発明に係る印刷発注システムである。
第3の発明は、特定された用紙の種類と用紙の量は、用紙を使用した工場又は印刷を受注した事業者に送信される、第1又は2の発明に係る印刷発注システムである。
第4の発明は、発注の履歴と、発注別に計算された用紙の使用量とに基づいて、用紙の需要量を予測し、予測された需要量を前記供給元に提供する、第1の発明に係る印刷発注システムである。
第5の発明は、前記用紙の需要量は、工場別、印刷を受注する事業者別、又は、用紙の供給元別に予想される、第4の発明に係る印刷発注システムである。
第6の発明は、工場毎に、用紙の種類別の残量を送信する、第4又は5の発明に係る印刷発注システムである。
第7の発明は、発注に対して、ユーザが希望する工場内の用紙の在庫が不足する場合でも、ユーザが定めた条件を満たすときには、当該工場に印刷を発注する、第1の発明に係る印刷発注システムである。
第8の発明は、ユーザが定めた前記条件は、予想される納期の遅延に関する範囲である、第7の発明に係る印刷発注システムである。
第9の発明は、工場に印刷を発注する印刷発注システムのコンピュータに、工場から収集される情報に基づいて、工場で使用された用紙の種類と使用された用紙の量を特定する機能と、特定された用紙の種類と用紙の量を、使用された用紙の供給元に送信する機能と、を実現させるプログラムである。
【発明の効果】
【0007】
第1の発明によれば、各工場が用紙の在庫を個別に管理して用紙の供給元に用紙を発注し、用紙の発注を受け付けた用紙の供給元が個別に用紙を配送する場合とは異なり、用紙の種類別の使用量の管理を可能にできる。
第2の発明によれば、用紙の使用量の分析が容易になる。
第3の発明によれば、用紙を使用する工場と用紙の供給元とで情報を共有できる。
第4の発明によれば、需要量の予測の精度を高めることができる。
第5の発明によれば、供給元による用紙の計画的な生産や配送が可能になる。
第6の発明によれば、供給元による用紙の管理が容易になる。
第7の発明によれば、発注時に用紙が不足する場合にもユーザの希望する工場に発注される可能性を高めることができる。
第8の発明によれば、予想される納期の遅延がユーザの定めた条件を満たせば、ユーザの希望する工場に印刷を発注できる。
第9の発明によれば、工用紙の供給元が用紙の発注を受け付けることを条件として発注元である工場に用紙を配送する場合とは異なり、用紙の種類別の使用量の管理を可能にできる。
【図面の簡単な説明】
【0008】
図1】ネット印刷システムの例を概念的に説明する図である。
図2】工場内の接続関係及び工場と印刷受発注サーバ等との接続関係の例を説明する図である。
図3】印刷受発注サーバのハードウェア上の構成例を示す図である。
図4】工場データベースに蓄積されるデータの一部を説明する図である。
図5】用紙データベースに蓄積されるデータの一部を説明する図である。
図6】予測需要データベースに蓄積されるデータの一部を説明する図である。
図7】印刷受発注サーバの機能上の構成例を示す図である。
図8】データ収集サーバのハードウェア上の構成例を示す図である。
図9】データ収集サーバの機能上の構成例を示す図である。
図10】工場内で発生する動的なデータの収集を説明する図である。
図11】印刷オーダの受信から発注に伴うデータの流れを説明する図である。
図12】印刷の発注後に発注先の工場で故障などのイベントが発生した場合の再発注を自動的に実行する例を説明する図である。
図13】ダイレクトメールの印刷が依頼された場合における分散的な発注の例を説明する図である。
図14】実施の形態2における発注先の決定方法を説明するフローチャートである。
【発明を実施するための形態】
【0009】
以下、図面を参照して、本発明の実施の形態を説明する。
【0010】
<実施の形態1>
<システム全体の構成>
本実施の形態に係るシステム全体の構成を図1及び図2を用いて説明する。
図1は、ネット印刷システム1の例を概念的に説明する図である。図2は、工場400内の接続関係及び工場400と印刷受発注サーバ300等との接続関係の例を説明する図である。
なお、図1及び図2は概念図であり、実際の構成や接続関係は図1及び図2に示す内容に限らない。
ネット印刷システム1は、インターネット100経由で印刷を依頼するユーザが操作するユーザ端末200と、ユーザ端末200から印刷の依頼を受け付ける印刷受発注サーバ300と、製紙会社Pに設けられる用紙管理サーバ350と、印刷受発注サーバ300から発注を受けた印刷を実行する工場400とで構成される。
【0011】
ユーザ端末200は、印刷を依頼するユーザが操作するインターネット端末である。もっとも、印刷受発注サーバ300による印刷の依頼の受付は、インターネット100経由に限らない。例えばネット印刷システム1を通じて提供されるネット印刷サービスを提供する窓口事業者の従業員が、印刷受発注サーバ300に接続された不図示の端末を操作して印刷の依頼を印刷受発注サーバ300に入力してもよい。
本実施の形態の場合、ネット印刷システム1を構成する工場400の全ては、1つの国又は地域に存在する必要はなく、複数の国又は地域に分散して存在してもよい。図1の場合、6つの工場400は、日本とアメリカに分散して存在している。
【0012】
本実施の形態において、工場400とは、印刷物の生産に用いられる装置(以下「生産装置」ともいう。)が配置されている場所の意味で使用する。従って、工場400は、生産装置が1台だけ配置されている印刷所や事業所も含む。
また、工場400は、印刷専用の場所である必要はなく、区画の一部に生産装置が配置されている場所でもよい。例えば配送事業者、郵便事業者、電気事業者、ガス事業者、公益法人、医療事業者等の施設や事業所も、区画の一部に印刷物の生産装置が配置されていれば、本実施の形態における工場400に含まれる。換言すると、印刷物の生産装置を配置していれば、事業者の業種は問わない。この意味で、配送事業者、郵便事業者、電気事業者、ガス事業者、公益法人、医療事業者等も印刷事業者に含まれる。
【0013】
本実施の形態の場合、工場400は、複数の印刷事業者が管理している。図1の場合、印刷事業者W、X、Y、Zの4社である。これは、紙面の制約のためであり、実際には数の制約はない。なお、印刷事業者W、X、Y、Zは、異なる法人である。また、印刷事業者W、X、Y、Zは、資本関係や系列関係などの業務上の関係を有する必要はない。むしろ本実施の形態では、資本関係や系列関係などの業務上の関係を有しない印刷事業者W、X、Y、Zを想定する。
なお、印刷事業者は工場400を所有している必要はなく、印刷物を生産する生産装置を所有している必要もない。
また、本実施の形態の場合、印刷受発注サーバ300に接続される工場400の数は印刷事業者毎に異なってよい。
図1の場合、印刷事業者W、X、Zが接続する工場400の数は1つであるが、印刷事業者Yが接続する工場400の数は3つである。すなわち、各印刷事業者が印刷受発注サーバ300に接続する工場400の数は任意である。
【0014】
本実施の形態の場合、工場400には、印刷に関連する情報を収集して印刷受発注サーバ300に登録するデータ収集サーバ500と、印刷物を生産する印刷装置600と、印刷物に加工を施す加工装置700と、印刷のスケジュールを管理するワークフロー管理装置800と、消耗品の在庫を管理する在庫管理装置900と、印刷物の品質、工場内の環境、工場内の人の動き等を検知するセンサ1000が配置されている。なお、工場400には、生産装置を操作する人員の出勤等を管理する装置が配置されてもよい。
ここでの印刷装置600と加工装置700は、いずれも生産装置の一例である。図1の例では、印刷装置600と加工装置の700の両方が工場に配置されているが、いずれか一方だけが工場400に配置されてもよい。換言すると、工場400は、印刷専用の工場でもよいし、加工専用の工場でもよい。
【0015】
また、ワークフロー管理装置800は、生産管理装置の一例である。また、在庫管理装置900は、在庫管理装置の一例である。
なお、本実施の形態では、印刷受発注サーバ300と用紙管理サーバ350とデータ収集サーバ500とで構成されるシステムを印刷受発注管理システムと呼ぶ。もっとも、印刷受発注サーバ300とデータ収集サーバ500とで構成されるシステム、又は、印刷受発注サーバ300だけを印刷受発注管理システムと呼ぶこともある。
図1の場合、用紙管理サーバ350を1台だけ描いているが、これは作図上の制約によるものであり、配置される台数は任意である。なお、用紙管理サーバ350は、いわゆるサーバである必要はなく、業務に使用する端末であればよい。
また、図1の場合、用紙管理サーバ350は、製紙会社Pが管理しているが、勿論、製紙会社は複数でもよい。製紙会社が複数の場合、用紙管理サーバ350も複数である。なお、工場400に用紙を供給する事業者は、製紙会社に限らず、卸問屋等でもよい。本実施の形態では、工場400に用紙を供給する事業者を総称して「用紙の供給元」ともいう。
【0016】
本実施の形態の場合、データ収集サーバ500は、印刷受発注サーバ300を運用する窓口事業者が各工場400に設置する。
図1の場合、工場400内には印刷装置600を1台だけ描いているが、これは作図上の制約によるものであり、配置される台数は任意である。従って、工場400に配置される印刷装置600の台数は1台でもよいし、複数台でもよい。印刷装置600の製造メーカは、工場400毎に異なってもよい。また、工場400内には、複数の製造メーカの印刷装置600が混在してもよい。なお、印刷装置600には、それぞれ専用の装置ID(=IDentifier)が付されており、印刷ジョブの実行に関する情報や各装置の稼働に関する情報が1台毎に管理される。
加工装置700についても、印刷装置600と同様である。すなわち、加工装置700は、工場400内に1台に限る必要はなく、複数台でもよい。また、加工装置700の製造メーカは、工場400毎に異なってもよい。また、工場400内には、複数の製造メーカの加工装置700が混在してもよい。
【0017】
ワークフロー管理装置800は、工場内での生産を一括管理する装置である。例えばワークフロー管理装置800は、印刷ジョブの受注処理、同じ仕様の印刷ジョブをまとめた面付け処理、印刷スケジュールや加工スケジュールの管理、印刷や加工の進捗管理、工場内で使用された用紙の量を管理する処理等を実行する。工場内で使用された用紙の量を管理する処理には、受注された印刷オーダ単位の管理、印刷ジョブ単位の管理、印刷事業者単位の管理を含めてもよい。受注された印刷オーダ単位の用紙の使用量や印刷ジョブ単位の用紙の使用量は、データ収集サーバ500を通じて取得された印刷装置600の動作の状況や動作の履歴、印刷スケジュール、用紙の交換や補充の記録等に基づいて計算される。本実施の形態の場合、用紙の使用量は、印刷装置600から取得されるデータに基づいてリアルタイムで計算される。もっとも、リアルタイムの計算に限定されない。なお、用紙の使用量を管理する処理は、データ収集サーバ500側で実行してもよい。
ワークフロー管理装置800は、工場内のネットワークを通じて、印刷装置600や加工装置700と接続され、各種のデータを受け渡しする。例えば受信した印刷データ(原稿データ、版データを含む)は、印刷スケジュールに従って、ワークフロー管理装置800から印刷装置600に送信される。
本実施の形態におけるワークフロー管理装置800は、(i) 用紙等が印刷の過程で搬送される経路上に配置され、印刷の不良や異常を検知するセンサ1000からの出力データ、(ii)印刷物が加工の過程で搬送される経路上に配置され、加工の不良や異常を検知するセンサ1000からの出力データ、(iii) 完成品としての印刷物の汚れや不良等の品質を管理するセンサ1000からの出力データ等も管理する。
【0018】
ここでのセンサ1000は、印刷装置600や加工装置700の筐体内に配置されていてもよいし、印刷装置600や加工装置700とは別に配置されていてもよい。これらセンサ1000から出力されるデータの形式は、センサ1000の種類や製造メーカによって異なる。
また、本実施の形態におけるワークフロー管理装置800は、生産された商品(加工を別工場で行う場合には加工前の印刷物)の納品に使用する配送サービス会社の情報も管理する。配送サービス会社の情報には、配送サービスを提供する事業者の名称、サービスの名称、配送サービスの詳細、出荷日、出荷番号、発注単位の請求額、発注元単位の総請求額、工場外での利用を禁止する情報を指定する情報等も管理する。
ワークフロー管理装置800は、これらの情報の管理や機能の提供をコンピュータ上で動作するアプリケーションプログラムを通じて実現する。
また、センサ1000は、作業員が作業に用いる機材に取り付けられていてもよい。
【0019】
本実施の形態における在庫管理装置900は、印刷装置600で消費される用紙、インク、トナー、加工装置700で消費されるフィルム等の部材の在庫に関する情報を管理する。なお、在庫に関する情報は、在庫を識別する符号(すなわち在庫ID)、部材の名称、部材のカテゴリ、在庫数、部材を供給する事業者を識別する符号(すなわちサプライヤID)、事業者の名称、事業者が供給する部材のタイプ等を含んでよい。
在庫に関する情報は、例えば在庫を識別する符号を部材の消費時に読み取ることにより更新される。また、在庫や在庫の包装に付されているICタグに記録されている情報の読み取りにより更新される。
【0020】
本実施の形態の場合、工場400の敷地内や近隣の倉庫等に保管されている用紙は製紙会社の所有物である。すなわち、本実施の形態における印刷事業者は、印刷を受注する前に用紙を購入するのではなく、印刷後に使用した分の代金又は対価を支払うビジネスモデルを採用する。すなわち、従量課金を想定する。
なお、用紙の支払い方法はビジネス上の取り決めにより定まる。例えば用紙の代金を製紙会社に直接支払う方法に限らず、用紙の代金を控除した金額を、印刷の依頼主や印刷受発注サーバ300を運営する事業者から受け取ることも可能である。もっとも、用紙の一部又は全部は、印刷の実績とは関係なく事前に購入されていてもよい。
本実施の形態の場合、印刷事業者が管理する在庫管理装置900を用いて用紙の在庫を管理するが、在庫管理装置900は製紙会社Pが管理してもよい。
【0021】
データ収集サーバ500は、印刷装置600、加工装置700、ワークフロー管理装置800、在庫管理装置900、センサ1000と通信し、各装置から印刷に関する各種の情報を収集する。ここでの通信は、有線によっても無線によっても構わない。
データ収集サーバ500は、例えば印刷装置600から、装置を識別する符号(すなわち装置ID)、装置名、装置のスペック情報、装置のステータス、ステータスの詳細、印刷の種類(タイプ)、印刷の速度、速度の単位、取扱可能な用紙の最大サイズと最小サイズ、色空間と色基準の情報、日次生産能力、受注した印刷オーダ又は印刷ジョブ毎に使用された用紙の種類、受注した印刷オーダ又は印刷ジョブ毎に使用された用紙の量等の情報を収集する。使用された用紙の量等は、例えば印刷装置600等に設けられているセンサ1000から取得されるデータに基づいて自動的に計算される。
【0022】
ここでのステータスは、例えばアイドル状態、故障、使用中、メンテナンス中によって特定される。これらの情報の記述の形式は、印刷装置600の製造メーカによって異なり、同じ製造メーカでも機種によって異なる場合がある。
受注された印刷オーダ又は印刷ジョブ毎に使用された用紙の種類や使用された用紙の量の情報には、供給元である製紙会社に関する情報が含まれる。なお、用紙の種類に関する情報には、カット紙、ロール紙等の分類、仕様、用途等が含まれる。ここで、印刷ジョブの管理IDは、印刷オーダの管理IDと紐付けられている。このため、印刷ジョブ毎に使用された用紙の情報は、印刷オーダに紐づけて管理される。なお、印刷中に発生する無駄紙も印刷ジョブに紐づけて管理される。
用紙がロール紙の場合、印刷ジョブ毎に使用された用紙の量は、印刷に使用された用紙の長さ、重さ、ロールの数等で特定される。また、用紙がカット紙の場合、印刷ジョブ毎に使用される用紙の量は、例えば枚数で特定される。なお、1枚の用紙に印刷オーダを異にする複数の版が割り付けられている場合には、印刷オーダ毎に換算された枚数等を用いることも可能である。これらの計算は、前述したように、ワークフロー管理装置800等で実行してもよい。
【0023】
また、データ収集サーバ500は、例えば加工装置700から、装置を識別する符号(すなわち装置ID)、装置名、装置のスペック情報、装置のステータス、ステータスの詳細、加工の種類(タイプ)、加工の速度、速度の単位、日次生産能力等の情報を収集する。
ここでのステータスは、印刷装置600の場合と同じである。また、加工の種類には、例えば折り加工、角丸加工、孔開け加工、ミシン加工、スジ入れ加工、表面加工、箔押し加工、パネル加工、型抜き加工等がある。これらの情報の記述の形式は、印刷装置600の製造メーカによって異なり、同じ製造メーカでも機種によって異なる場合がある。
【0024】
また、データ収集サーバ500は、例えばワークフロー管理装置800から、受注情報、印刷スケジュール、加工スケジュール、各スケジュールの進捗情報、各生産装置の稼働状況、各生産装置の稼働率、各生産装置のメンテナンス記録等の情報を取得する。
また、データ収集サーバ500は、在庫管理装置900から、生産装置で消費される消耗品の在庫に関する情報を収集する。本実施の形態の場合、消耗品の在庫に関する情報には、製紙会社別に用紙の種類毎の在庫の情報が含まれる。
【0025】
データ収集サーバ500は、各装置やセンサ1000における情報の発生と同時に取得する。すなわち、本実施の形態におけるデータ収集サーバ500は、工場内での生産に伴い発生し、時間とともに変化する情報を自動的に収集する。
また、本実施の形態におけるデータ収集サーバ500は、収集した情報を機種の違いを問わない形式の情報に整備(クレンジング)する機能を備え、クレンジング後(整備後)の情報を印刷受発注サーバ300に送信する。ここでの機種の違いには、製造メーカの違いが含まれる。
本実施の形態の場合、データ収集サーバ500は、クレンジング後(整備後)の情報を分析した情報もセキュリティが確保された回線を通じて印刷受発注サーバ300に送信する。クレンジング後(整備後)の情報を分析した情報も、機種の違いを問わない形式の情報の一例である。なお、クレンジング後(整備後)の情報を分析した情報には、例えば生産装置の現在時点での稼働空き状況、生産装置の将来時制での稼働空き状況の予測、在庫量の予測等が含まれてもよい。稼働空き状況の計算には、メンテナンスの予定や休日等も反映される。本実施の形態の場合、クレンジング(整備)の機能をデータ収集サーバ500に設けているが、クレンジングは印刷受発注サーバ300側で実行してもよい。この場合、印刷受発注サーバ300は、フィルタ処理後の生データの一部を、セキュリティの確保された経路を通じて受信する。
本実施の形態の場合、印刷データは、印刷受発注サーバ300からワークフロー管理装置800に直接送信されているが、データ収集サーバ500を経由してワークフロー管理装置800に与えることも可能である。
なお、本実施の形態における印刷受発注サーバ300は、単独で、又は、データ収集サーバ500と協働で印刷発注システムを構成する。
【0026】
<各サーバの構成>
<印刷受発注サーバの構成>
ここでは、印刷受発注サーバ300の構成について説明する。
図3は、印刷受発注サーバ300のハードウェア上の構成例を示す図である。
図3に示すように、印刷受発注サーバ300は、プログラム(基本ソフトウェアを含む)の実行を通じて装置全体を制御するCPU(Central Processing Unit)301と、BIOS(Basic Input Output System)を記憶するROM(Read Only Memory)302と、プログラムの実行領域として使用されるRAM(Random Access Memory)303とを有している。
CPU301、ROM302、RAM303は、いわゆるコンピュータを構成し、各種の情報処理を実行する。なお、ROM302は、例えば不揮発性の半導体メモリによって構成される。
【0027】
ハードディスク装置(HDD)304は、基本ソフトウェア、各工場400のデータ収集サーバ500からアップロードされた情報を解析するアプリケーションプログラム、ユーザが指定した印刷の条件を満たす工場400を決定するアプリケーションプログラム、受注した印刷の依頼を管理する情報、各工場400に関する情報等を記憶する。
本実施の形態では、情報の解析に人工知能を使用する。もっとも、予め定めた規則に従って情報を解析するアプリケーションプログラムでもよい。
受注した印刷の依頼を管理する情報には、例えば受注ID、依頼者に関する情報、依頼時に指定された条件、印刷データに関する情報、請求ID、請求に関する情報、受注した印刷の進捗状況等が含まれる。図3の場合、依頼者に関する情報は、依頼者データベース(依頼者DB)304Aに記憶される。また、依頼時に指定された条件、請求に関する情報、受注した印刷の進捗状況等の情報は、依頼データベース(依頼DB)304Bに記憶される。依頼者データベース(依頼者DB)304Aと依頼データベース(依頼DB)304Bは、ハードディスク装置304の記憶領域の一部に記憶される。
【0028】
ここでの依頼者に関する情報には、例えば依頼者を識別する符号(すなわち顧客ID)、依頼者の名称、依頼者の居住地又は所在地、依頼者側の担当者に関する情報、依頼者の連絡先、依頼者の業種、顧客別に用意されたサービス上の管理番号、請求先の情報等が含まれる。
依頼時に指定された条件には、例えば希望の納期、希望の印刷事業者、希望の工場、印刷を実行する国又は地域、希望のアプリケーション、希望の金額、希望の配送方法、希望の用紙の種類、用紙の重量、希望の色プロファイル、希望の生産数量、仕上がりサイズ、片面又は両面印刷の指定、加工のタイプ、文書レイアウトのセクションの指定、製品の形態、単商品又は複数商品等を含む。ここでのアプリケーションは、例えばダイレクトメール、本等の印刷物の種別の指定に用いられる。
なお、製品の形態には、例えば書籍、ポストカード、ちらし、名刺、チケット、カタログ、伝票、封筒、シール、ラベル、袋、箱(パッケージ)等がある。
印刷データに関する情報には、例えば印刷データ、印刷データのファイルフォーマット等がある。
【0029】
本実施の形態の場合、データ収集サーバ500から受信される情報は、ハードディスク装置304の一部の記憶領域である工場データベース(工場DB)304Cに記憶される。工場データベース(工場DB)304Cは、蓄積手段及び蓄積装置の一例である。
本実施の形態の場合、工場データベース304Cには、データ収集サーバ500からアップロードされる新たな情報が自動的に蓄積され更新される。
工場データベース304Cには、データ収集サーバ500からアップロードされた情報に基づいて印刷受発注サーバ300が算出する情報も記録される。
データ収集サーバ500からアップロードされた情報に基づいて算出される情報には、例えば各工場の品質を評価した情報、各工場の過去の状態や現在の状況、過去の実績から計算される生産能力、予測されるスケジュール等が含まれる。
また、工場データベース304Cには、工場400の所在地、営業日等の登録情報も記録される。ここでの登録情報は時間の経過に伴って変化しない、いわゆる静的な情報である。
また、工場データベース304Cには、印刷の依頼者であるユーザによる工場400の評価、インターネット等を通じて受け付けた印刷をサービスに参加する工場400に発注する事業者による工場400の評価、過去の納期での遅延に関する記録、過去の納品に対して確認された品質の不良に関する記録等も記録される。
【0030】
本実施の形態の場合、これらの情報の算出にも、人工知能を使用する。もっとも、予め定めた規則に従って情報を算出するアプリケーションプログラムを用いてもよい。
後述するように、データ収集サーバ500は、新たなデータが発生するたび、又は、事象の変化が検知されるたび、それらの情報を印刷受発注サーバ300にアップロードする。このため、工場データベース304Cの情報は、本実施の形態に係るネット印刷サービスに参加する工場400の状況をリアルタイムで反映している。換言すると、工場データベース304Cの情報と工場400内の状況は同期関係にある。
【0031】
本実施の形態における工場データベース304Cには、印刷オーダや印刷ジョブで使用された用紙に関する情報も記憶される。
図4は、工場データベース304Cに蓄積されるデータの一部を説明する図である。(A)は、実行済みの印刷ジョブと印刷に使用された用紙との関係を記録したテーブルT1であり、(B)は、印刷事業者Xの用紙別の総使用量を記録したテーブルT2である。
図4の場合、テーブルT1には、管理番号、印刷事業者ID、工場ID、印刷装置ID、印刷ジョブID、印刷オーダID、用紙ID、製紙会社ID、使用量等が記録される。用紙IDは、使用された用紙の種類を特定できればよく、例えば製紙会社が使用するIDを用いる。
また、テーブルT2には、管理番号、対象期間、製紙会社ID、用紙ID、総使用量等が記録される。対象期間は、用紙別の総使用量を集計する期間である。図4の場合、対象期間は月単位で指定されている。もっとも、対象期間は、取引上の取り決めに従って指定が可能でもよい。
【0032】
図3の例では、工場データベース304Cをハードディスク装置304に記憶しているが、工場データベース304Cは、クラウドサーバ上に記憶してもよい。
なお、クラウドサーバに記憶する場合、印刷受発注サーバ300と工場データベース304Cとは同じ国又は地域に存在する必要はなく、異なる国又は地域に分散してもよい。
また、本実施の形態におけるハードディスク装置304には、印刷の依頼者が指定した条件を満たす発注先を決定する際に使用する受発注関係の学習済みモデル304Dが記憶されている。
学習済みモデル304Dは、工場データベース304Cで管理される工場400の中から印刷の条件に適合する発注先を決定するための規則を与える。本実施の形態の場合、学習済みモデル304Dは、蓄積された受発注の記録、決定された依頼者による発注先に対する評価の登録や更新、印刷受発注サーバ300内で計算される工場に対する評価の登録や更新等を学習する人工知能により常に更新される。
【0033】
この他、ハードディスク装置304には、用紙データベース304Eと予測需要データベース304Fが記憶されている。
図5は、用紙データベース304Eに蓄積されるデータの一部を説明する図である。図5に示すテーブルには、管理番号、製紙会社ID、用紙ID、工場別在庫量、単価、特約等が記録される。単価は、使用量に応じた代金の計算に用いられる。
【0034】
図6は、予測需要データベース304Fに蓄積されるデータの一部を説明する図である。(A)は印刷事業者別の用紙の予測需要のテーブルT4を示し、(B)は製紙会社別の総予測需要のテーブルT5である。
図6の場合、テーブルT4には、管理番号、対象期間、製紙会社ID、用紙ID、予測需要等が記録される。印刷事業者別の予測需要は、依頼DB304B(図3参照)に記録されている取引の実績や工場DB304C(図3参照)に記録されている用紙の使用量等に基づいて、印刷受発注サーバ300にインストールされているアプリケーションプログラムや人工知能により予測される。需要の予測であるので、対象期間には未来の日が入力される。図6の場合、半年後を想定しているが、1月後等でもよい。本実施の形態の場合、対象期間は、ユーザが指定する。もっとも、対象期間は、アプリケーションプログラムで定める既定値でもよい。テーブルT4には、印刷事業者が取引する製紙会社の情報が全て含まれる。また、図6の場合には、印刷事業者を単位としているが工場400(図1参照)を単位とした予測需要を管理するテーブルが用意されてもよい。
また、テーブルT5には、管理番号、対象期間、用紙ID、総予測需要等が記録される。図6の場合には、製紙会社別の総予測需要であるが、製紙会社を問わない用紙の需要を予測したテーブルを用意してもよい。
【0035】
この他、印刷受発注サーバ300(図3参照)には、CPU301(図3参照)で実行されるアプリケーションプログラムの操作画面の表示に用いられる表示部305(図3参照)、当該操作画面を操作する作業者の入力に用いられる操作入力部306(図3参照)、インターネット100(図1参照)との通信に用いられる通信インタフェース(通信IF)307(図3参照)が設けられている。
ここでの表示部305及び操作入力部306は、印刷受発注サーバ300の筐体に対して外付けされていてもよい。また、印刷受発注サーバ300には、不図示の印刷装置が接続されていてもよい。
図3に示す各部は、不図示のバスや不図示の通信線を通じて互いに接続されている。
【0036】
図7は、印刷受発注サーバ300の機能上の構成例を示す図である。
図7に示す機能上の構成は、CPU301(図3参照)によるプログラムの実行を通じて実現される。ここでの機能上の構成は、単一のプログラムに限らず、複数のプログラムの連携によって実現されてもよい。
機能面から見た印刷受発注サーバ300は、印刷の依頼を受け付けるオーダ受付部311と、受け付けた依頼の条件に対して最適な発注先を自動的に決定する発注先決定部312と、決定された発注先である1つ又は複数の工場400(図1参照)に対して印刷を発注する発注部313と、過去の受発注関係を学習して学習済みモデル304Dを更新する受発注関係学習部(AI)314と、工場データベース(工場DB)304Cに蓄積する分析データを計算する分析データ計算部315、分析データ計算部315で計算された用紙の使用量や予測需要等を印刷事業者や製紙会社等に提供する情報提供部316としての機能を有している。
【0037】
オーダ受付部311は、Webサーバ等を通じて印刷の依頼を受け付ける受付手段の一例であり、受け付けた印刷の依頼を受注IDによって管理する。オーダ受付部311は、依頼者データベース304Aに依頼者に関する情報を登録し、又は、登録されている依頼者の情報を読み出す。
また、オーダ受付部311は、受け付けた依頼の条件等を依頼データベース304Bで管理する。依頼の条件には、印刷物を納品する場所、すなわち納品地の希望が含まれる。また、納品地とは別に、印刷に使用する工場400が存在する場所の希望が含まれてもよい。ここでの希望は、例えば国又は地域、国又は地域内の行政単位、行政単位の集合を表現する名称等で指定してもよい。なお、行政単位の階層的な構造や各階層の呼び方は国や地域によっても異なる。
【0038】
発注先決定部312は、依頼の条件を満たす工場400(図1参照)を発注先として決定する。発注先決定部312は、決定手段の一例である。発注先として決定される工場400は、1つの依頼に対して1つの場合もあれば、1つの依頼に対して複数の場合もあり得る。本実施の形態の場合、依頼の条件に含まれる納品地に近い工場400への発注を優先する。
発注先の決定には、工場データベース304Cと学習済みモデル304Dが用いられる。学習済みモデル304Dには、より適切な発注先を決定するためのモデルが記録されている。また、工場データベース304Cには、工場400側と同期する情報(状態、生産能力、スケジュール)に加え、工場400(図1参照)の品質に対する評価、過去の受発注の記録等が蓄積されている。ここでの評価は品質情報の一例である。
【0039】
発注部313は、発注先に決定された工場400(図1参照)に配置されているデータ収集サーバ500に対して発注情報(例えば印刷のアプリケーション、加工の内容、部数、納品先、価格情報等)を送信するとともに、ワークフロー管理装置800(図1参照)に対して印刷データを送信する。ここでの発注部313は、発注手段の一例である。また、発注情報は、発注データの一例である。前述したように、発注部313は、印刷データをデータ収集サーバ500に送信してもよい。
本実施の形態における受発注関係学習部314は、人工知能(AI)の機能を用いて工場データベース304Cに記憶されている印刷の条件に対して決定された発注先、発注先としての工場を評価した情報等の関係を学習し、学習の成果を学習済みモデル304Dに反映する。
なお、工場データベース304Cに記憶されている情報は、機種の違いを問わない形式の情報に整備された後のデータ又はそれらを処理したデータであるので学習の精度が高まり易い。また、印刷受発注サーバ300は、印刷を依頼する不特定のユーザと多数の印刷事業者との間の取引を中継するバブとして機能するので、取引の履歴や工場400内における印刷の進行に関する情報を大量に収集できる。このため、学習の速度が上がり、同時に精度の向上も加速される。
【0040】
分析データ計算部315は、各工場400から自動的に工場データベース304Cに蓄積される生産装置の稼働の状態、生産能力、スケジュール等の情報に基づいて、各生産装置についての現在及び過去の稼働の状態、生産装置の将来時制での稼働空き状況の予測、将来の在庫量等を分析する。
また、分析データ計算部315は、各工場400から自動的に工場データベース304Cに蓄積される印刷ジョブ毎に使用された用紙の種類や使用量に基づいて、各印刷事業者が製紙会社に支払う用紙の代金の計算も実行する。
また、分析データ計算部315は、過去の受発注の履歴や対応する用紙の使用量等の記録に基づいて将来の需要を予測する処理も実行する。予測された需要は、予測需要データベース304Fに記録される。
因みに、印刷受発注サーバ300が印刷の依頼者から一括して料金を受領する場合には、分析データ計算部315が、印刷事業者や製紙会社に支払う金額を計算してもよい。
なお、データ収集サーバ500(図1参照)で同等の分析処理が実行されている場合には、分析データ計算部315を設けなくてもよい。
情報提供部316は、ネット印刷システム1(図1参照)に参加する製紙会社に対して予測された需要を提供する他、印刷事業者が消費した用紙の量や代金の情報を製紙会社や印刷事業者に提供する。
【0041】
<管理サーバの構成>
用紙管理サーバ350(図1参照)は、前述した印刷受発注サーバ300と同様のハードウェア構成を有している。すなわち、用紙管理サーバ350は、プログラムの実行を通じて装置全体を制御するCPUと、BIOS等を記憶するROMと、プログラムの実行領域として使用されるRAMと、各種のプログラムや用紙の在庫情報や取引情報が記憶されるハードディスク装置と、各種の情報の表示に用いられる表示部と、作業者による操作の入力に用いられる操作入力部と、インターネット100(図1参照)との通信に用いられるインタフェースとを有している。
用紙管理サーバ350は、インターネット100を通じて接続された印刷受発注サーバ300(図1参照)から、例えば印刷事業者が使用した自社の用紙の使用量や代金に関する情報、各工場に保管している自社の用紙の在庫の情報、印刷事業者別又は工場別の用紙の予測需要の情報等の通知を受ける。
なお、印刷事業者に請求する用紙の代金は、通知を受けた用紙の使用量に基づいて、用紙管理サーバ350が計算してもよい。
【0042】
<データ収集サーバの構成>
次に、データ収集サーバ500の構成について説明する。
図8は、データ収集サーバ500のハードウェア上の構成例を示す図である。
図8に示すように、データ収集サーバ500は、プログラム(基本ソフトウェアを含む)の実行を通じて装置全体を制御するCPU501と、BIOSを記憶するROM502と、プログラムの実行領域として使用されるRAM503とを有している。
CPU501、ROM502、RAM503は、いわゆるコンピュータを構成し、各種の情報処理を実行する。なお、ROM502は、例えば不揮発性の半導体メモリによって構成される。
【0043】
ハードディスク装置504は、基本ソフトウェア、印刷受発注サーバ300から受信された発注情報、工場400内から収集された生データが記憶される生データデータベース(生データDB)504A、生データを機種の違いを問わない形式の情報に整備(クレンジング)した後の生データが記録されるクレンジング済み生データデータベース(クレンジング済み生データDB)504B、クレンジング済みの生データを分析した結果が記憶される分析結果データベース(分析結果DB)504C等を記憶する。
本実施の形態では、データ収集サーバ500が、工場内から収集するデータを生データという。
【0044】
印刷装置600からは、製造メーカや機種に依存したデータ形式により、例えば装置ID、装置名、装置のスペック情報、装置のステータス、ステータスの詳細、印刷の種類(タイプ)、印刷の速度、速度の単位、取扱可能な用紙の最大サイズと最小サイズ、色空間と色基準の情報、日次生産能力、印刷オーダや印刷ジョブ毎に使用された用紙の情報、印刷ジョブ毎に使用された用紙の量等の情報が工場内ネットワークを通じて自動的に収集される。
加工装置700からは、製造メーカや機種に依存したデータ形式により、例えば装置ID、装置名、装置のスペック情報、装置のステータス、ステータスの詳細、加工の種類(タイプ)、加工の速度、速度の単位、日次生産能力等の情報が工場内ネットワークを通じて自動的に収集される。
【0045】
ワークフロー管理装置800からは、データを管理するアプリケーションプログラムに依存したデータ形式により、例えば受注情報、印刷スケジュール、スケジュールの進捗情報、各生産装置の稼働状況、各生産装置の稼働率、各生産装置のメンテナンス記録等の情報が工場内ネットワークを通じて自動的に収集される。
在庫管理装置900からは、データを管理するアプリケーションプログラムに依存したデータ形式により、生産装置で消費される消耗品の在庫に関する情報が工場内ネットワークを通じて自動的に収集される。
また、不図示の検査装置等に搭載されるセンサ1000からは、製造メーカや機種に依存したデータ形式により、各センサの出力がIoTネットワーク等を通じて自動的に収集される。
【0046】
本実施の形態の場合、分析結果データベース504Cには、例えば生産装置の現在時点での稼働空き状況、生産装置の将来時制での稼働空き状況の予測、在庫量の予測、生産装置の稼働スケジュール等が分析結果として記憶される。分析結果の内容やデータの形式は、工場400の違いによらず統一した内容と形式で記録される。
なお、生データのクレンジング(整備)やクレンジング後(整備後)の生データの分析には、人工知能を使用してもよい。もっとも、予め定めた規則に従って情報を解析するアプリケーションプログラムを使用してもよい。
【0047】
この他、データ収集サーバ500には、CPU501で実行されるアプリケーションプログラムの操作画面の表示に用いられる表示部505、当該操作画面を操作する作業者の入力に用いられる操作入力部506、インターネット100や不図示の工場内ネットワークとの通信に用いられる通信インタフェース(通信IF)507が設けられている。
ここで、工場内ネットワークとの通信には、例えばLAN(Local Area Network)を使用する。工場内ネットワークとの通信に用いられる通信インタフェース507のうちデータの収集に用いられる通信部は、第1の通信手段の一例である。工場内ネットワークとの通信に用いられる通信インタフェース507のうち発注情報の送信に用いられる通信部は、第2の通信手段の一例である。
ここでの表示部505及び操作入力部506は、データ収集サーバ500の筐体に対して外付けされていてもよい。
図8に示す各部は、不図示のバスや不図示の通信線を通じて互いに接続されている。
【0048】
図9は、データ収集サーバ500の機能上の構成例を示す図である。
図9に示す機能上の構成は、CPU501(図8参照)によるプログラムの実行を通じて実現される。ここでの機能上の構成は、単一のプログラムに限らず、複数のプログラムの連携によって実現されてもよい。
機能面から見たデータ収集サーバ500は、工場400内の印刷装置600、加工装置700、ワークフロー管理装置800、在庫管理装置900、センサ1000との通信により各装置やセンサから発注先の決定に使用される情報を生データとして収集する生データ収集部511と、収集された生データを機種の違いを問わない形式にクレンジング(整備)するクレンジング部512と、クレンジング済みの生データを分析して発注先の決定や各工場400に固有の問題の改善に有用な情報を生成するデータ分析部513と、クレンジング済みの生データや分析結果を印刷受発注サーバ300(図1参照)にアップロードするデータアップロード部514と、印刷受発注サーバ300から発注情報を受信する発注情報受信部515としての機能を有している。
【0049】
生データ収集部511は、工場内の生産装置等との通信により、生産装置等の状況、生産能力、スケジュール等を表す情報をリアルタイムで収集する。データの収集は、生データ収集部511による生産装置等への送信指示に対する応答として実現してもよいし、生産装置等から一方的に出力されるデータの受信によって実現してもよい。
収集の対象とするデータは、基本的に、時間の経過に伴って動的に変化する。もっとも、変化の周期はデータの種類によって異なる。
なお、生産装置等で発生又は管理される情報の全てを収集してもよいが、変化が検知された情報だけを選択的に収集してもよい。変化を検知する機能は、生データ収集部511に設けられてもよいし、生産装置等に設けられてもよい。
【0050】
クレンジング部512は、製造メーカや機種等に依存するデータの形式等の違いを予め定めたデータの形式にクレンジング(整備)する。クレンジングでは、例えばデータフォーマットの変換だけでなく、表記の揺れや情報の重複が取り除かれる。クレンジング部512は、整備手段の一例である。
クレンジング部512は、作業員の個人情報の匿名化、印刷受発注サーバ300(図1参照)への情報の提供を禁止する情報の除去等を実行してもよい。なお、印刷受発注サーバ300へのアップロードは禁止するが、データ収集サーバ500によるデータ分析での使用が許可されているデータについては、クレンジング部512が印刷受発注サーバ300への送信を禁止するフラグ等を付した上でクレンジング(整備)を行ってもよい。
【0051】
データ分析部513は、クレンジング後の生データを分析し、個々の生産装置又は工場全体での稼働率、生産装置の故障の予測、メンテナンスの予測、エラーパターンの予測、生産装置の状態、生産装置の生産能力、生産能力を向上させるスケジュール案、利益率を向上させるスケジュール案等を出力する。
データ分析部513は、分析の結果を表示部505(図5参照)の作業画面に表示する機能も備えている。
【0052】
データアップロード部514は、クレンジング済みの生データやその分析結果を印刷受発注サーバ300に自動的にアップロードする。
このうち、クレンジング済みの生データは、データ処理の後、遅滞なく自動的にアップロードされる。このアップロードにより、印刷受発注サーバ300が発注先の決定に使用する工場データベース304C(図4参照)のデータと、アップロード元である工場400(図1参照)内のデータとが同期される。
前述したように、印刷受発注サーバ300へのアップロードが禁止されているデータは、アップロードの対象から除外される。本実施の形態の場合、データアップロード部514には、例えば予め定めた情報以外の情報がアップロードされないようにフィルタリングする機能が設けられている。
本実施の形態におけるデータアップロード部514は、通信内容の安全が保たれた状態で印刷受発注サーバ300との通信を実行する。
発注情報受信部515は、印刷受発注サーバ300からの発注情報の通知を受信する。発注情報受信部515は、ワークフロー管理装置800(図1参照)と連携し、発注情報の一部をワークフロー管理装置800と共有する。
【0053】
<印刷受発注管理方法の例>
以下では、ネット印刷システム1(図1参照)において実行される印刷受発注管理方法の例を説明する。
図10は、工場400内で発生する動的なデータの収集を説明する図である。
図10には、工場400内に存在するデータ収集サーバ500で収集されたデータが、インターネット上に存在する印刷受発注サーバ300に集約されるまでのデータの流れと対象期間内に集計された用紙の総使用量等が通知される様子を概念的に示している。
図10における生産装置等は、印刷装置600(図1参照)、加工装置700(図1参照)、ワークフロー管理装置800(図1参照)、在庫管理装置900(図1参照)、センサ1000(図1参照)である。
【0054】
図10の場合、生産装置等でデータの発生や変化を検知するイベントが発生すると、イベントに関する生データが生産装置等からデータ収集サーバ500に自動的に送信される。ここでのイベントには、印刷装置600への用紙の補充や交換、印刷ジョブの実行に伴い使用された用紙の量等の情報の更新、在庫管理装置900で管理されている用紙の在庫量の更新等も含まれる。
データ収集サーバ500は、受信した生データを蓄積した後、クレンジング(整備)し、更に分析して印刷受発注サーバ300にアップロードする。印刷受発注サーバ300は、新たに受信されたデータで蓄積データを更新する。
【0055】
図中のアップロード#1では、分析処理の実行後にアップロードを実行しているが、分析処理の実行前にクレンジング後の生データをアップロードしてもよい。アップロード#2は、クレンジング(整備)後のデータを分析前にアップロードしている。なお、分析結果のアップロードは、アップロード#2-1として別途実行される。
また、図10では、イベント単位でアップロードを実行しているが、複数のイベントに対応する生データをまとめてアップロードしてもよい。
ただし、印刷受発注サーバ300に蓄積されるデータと工場400内のデータとを同期させる観点からは、イベントの発生からアップロードまでの時間は短いほど好ましい。
【0056】
また、図10に示すデータ収集サーバ500は、対象期間内に使用された用紙の量の集計を更新すると、用紙の使用実績を用紙管理サーバ350及びデータ収集サーバ500に通知する。図10の場合、用紙の使用実績の通知は、蓄積データの更新回毎ではなく、予め定めた条件を満たすタイミングで実行している。このため、図中の3回目の更新回にのみ用紙の使用実績の通知が実行されている。もっとも、用紙の使用実績の通知は、蓄積データの更新回毎に実行してもよい。なお、予め定めた条件には、例えば対象期間の経過を用いてもよい。
また、図10の場合には、印刷受発注サーバ300で集計された用紙の使用実績を工場400内のデータ収集サーバ500に通知しているが、ワークフロー管理装置800(図1参照)に通知してもよい。また、用紙の使用実績は、印刷事業者の本社等に設置されている不図示の管理端末に通知されてもよい。
【0057】
本実施の形態の場合、印刷ジョブに関連付けて各種の情報が紐付けられて管理されるため、印刷ジョブ単位又は印刷オーダ単位による用紙の使用量、工場400単位での用紙の使用量、印刷事業者単位での用紙の使用量等を、印刷受発注サーバ300において正確に把握することができる。また、印刷受発注サーバ300が、印刷事業者における用紙の正確な使用量を管理できることで、製紙会社は製造した用紙を工場400の敷地内等に保管しておけば、工場400内で使用された用紙の量に応じた金額を受け取ることができるようになる。また、印刷事業者においても、印刷を請け負う前に用紙を買い取る必要がなくなる。結果的に、用紙の従量課金が可能になる。換言すると、製紙会社と印刷事業者の双方に利益のあるビジネスモデルが実現される。
【0058】
なお、用紙の種類毎の単価の情報が製紙会社から印刷受発注サーバ300に提供されている場合には、使用量に応じた用紙の代金なども、印刷受発注サーバ300から製紙会社と印刷事業者の双方に通知することが可能である。これらの情報を決裁システムに与えれば、当事者間の決裁も可能である。
また、図10に示すデータ収集サーバ500は、過去の受発注の履歴や工場400から逐次通知される用紙の使用量や用紙の在庫等の情報に基づいて、将来の用紙の需要を予測し、予測された需要を製紙会社に通知する。通知される予測需要には、工場400別の用紙の予測需要、印刷事業者別の用紙の予測需要、製紙会社別の予測需要等が含まれる。
本実施の形態における印刷受発注サーバ300は、インターネットを使用して印刷を依頼する不特定のユーザとネット印刷システム1に参加する多数の印刷事業者との間の取引を中継するハブとして機能する。このため、印刷受発注サーバ300には、受発注の記録だけでなく、個々の受発注に対して使用された用紙の量等も大量に蓄積されている。受発注の履歴が蓄積されるほど、将来の受発注の予測や用紙の需要の予測の精度が向上する。
このため、予測需要の通知を受ける製紙会社では、用紙を計画的に製造することができる。
【0059】
図11は、印刷オーダの受信から発注に伴うデータの流れを説明する図である。
図12には、印刷受発注サーバ300で印刷オーダが受信されてから発注先が決定されて、発注情報が工場400側のデータ収集サーバ500に送信されるまでのデータの流れを概念的に示している。工場データベース304C(図3参照)を参照して発注先を決定する。工場データベース304Cでは、工場400内に配置された生産装置等の最新の情報が、機種の違いを問わない形式で管理されている。
【0060】
図11に示す印刷オーダ#1の事例は、1つの工場400Aが発注先#1に決定される場合に対応する。このため、発注#1が工場400Aに配置されたデータ収集サーバ500に送信されている。
なお、データ収集サーバ500は、連携するワークフロー管理装置800(図1参照)等に受信した発注情報を転送する。
図11に示す印刷オーダ#2の事例は、2つの工場400A及び400Bが発注先#2に決定される場合に対応する。1つの印刷オーダを複数の発注に分割する事例は、例えば1つの工場だけでは、印刷オーダで指定された印刷の条件を満たすことができない場合、後述するように納品先が複数の地域に分散している場合等に発生する。
図11の例では、発注#2Aが工場400Aのデータ収集サーバ500に送信され、発注#2Bが工場400Bのデータ収集サーバ500に送信されている。
【0061】
次に、印刷の発注後に発注先の工場で納期や品質に影響を及ぼす事象が発生した場合の動作について説明する。
従前のシステムの場合、ユーザから印刷の依頼を受け付ける事業者は、発注後に発注先の工場内部で納期や品質に影響する事象が発生しても、影響が確定して印刷事業者側から連絡を受けない限り知り得ない。また、知り得る場合でも、人手を介して情報が更新される分、対応が遅れてしまう。
図12は、印刷の発注後に発注先の工場で故障などのイベントが発生した場合の再発注を自動的に実行する例を説明する図である。
図12には、図11との対応部分に対応する符号を付して示している。
図12の場合も、印刷オーダ#1を受信した印刷受発注サーバ300は、発注先#1として工場400Aを決定し、そのデータ収集サーバ500に発注#1を送信する点で、図11の例と共通する。
勿論、データ収集サーバ500は、受信した発注#1をワークフロー管理装置800(図1参照)等に転送し、印刷のスケジュールを更新する。
【0062】
ここでは、発注#1に対応する印刷のスケジュールが登録された後に、工場400A内の印刷装置600(図1参照)や加工装置700(図1参照)に故障などのイベントが発生した場合を想定する。
故障は、納期や品質に影響を及ぼす事象の一例である。なお、故障は、発注#1に対応する印刷を開始する前に発生するかもしれないし、印刷の途中で発生するかもしれないし、印刷は終了しているが加工が開始する前に発生するかもしれないし、加工の途中で発生するかもしれない。
また、故障の発生は、発注#1に対応する印刷が予定されている印刷装置600で発生した場合や同じく加工が予定されている加工装置700で発生した場合に限らない。印刷や加工が予定されている生産装置とは別の生産装置で故障が発生した場合でも、工場側の事情でスケジュール自体が変更され、その結果、発注#1の納期や品質に影響が及ぶ可能性もある。
また、工場400Aが発注先#1として決定された理由の1つに、技能が高い特定の作業員が勤務している時間帯での印刷等の実行が可能であることが含まれる場合、該当する作業員が発注#1の印刷等の実行時に作業に従事しないことも、図12で想定する故障などのイベントに含まれる。
【0063】
いずれにしても、納期や品質に影響が及ぶ事象の発生は、データ収集サーバ500が工場内から自動的に収集する生データの数値の変化として現れる。故障などの種類や内容によっては、センサ1000(図1参照)によって直接検知される。
前述したように、データ収集サーバ500は、収集された生データを即座にクレンジング(整備)し、クレンジング後(整備後)の生データ又は分析結果を自動的に印刷受発注サーバ300にアップロードする。すなわち、自動アップロードする。
事象の発生から自動アップロードまでに人手が介在しないので、極めて短時間のうちに印刷受発注サーバ300に情報が伝達される。
この自動アップロードにより、印刷受発注サーバ300の工場データベース304C(図3参照)の蓄積データが更新される。
印刷受発注サーバ300の発注先決定部312(図4参照)は、決定された発注先に印刷を発注した後も、工場データベース304Cの蓄積データを通じて、納期や品質に影響が及ぶ事象の発生を監視している。
【0064】
図12の場合には、故障などのイベントの影響が及ぶ印刷オーダ#1について、その依頼の条件を満たす新しい発注先#1を決定する。図12では、工場400Bが新しい発注先#1である。
よって、印刷受発注サーバ300は、工場400Bのデータ収集サーバ500に対して新しい発注#1を送信する。この新しい発注#1は、工場400Bのデータ収集サーバ500で受信され、ワークフロー管理装置800(図1参照)等に転送される。
ここでの新しい発注#1の内容は、工場400A内での印刷や加工の進捗の状況によって異なる。例えば工場400Aでの印刷が開始される前であれば、全ての印刷が新しく決定された工場400Bに発注される。また例えば工場400Aでの印刷の一部が既に終了している場合には、残りの印刷と加工が新しく決定された工場400Bに発注される。この場合も、工場400Aで使用された用紙の量の情報は、印刷受発注サーバ300に送信され、課金の対象として記録される。
なお、印刷が既に開始している場合における残りの印刷の発注は、完全な意味での残りとするか、依頼していた印刷の全体を再発注するかは、予め定めた規則に基づいて決定する。
勿論、加工についても同様である。
【0065】
図12の場合、印刷受発注サーバ300は、新しい発注#1の送信後に、故障などのイベントが発生した工場400Aに対して発注#1の取り消しを送信している。発注#1が取り消されても使用された用紙の情報は、工場400Aに関連付けて記録される。
なお、工場400Aに対する発注#1の取り消しの送信を、工場400Bに対する新しい発注#1の送信よりも前又は同時に実行してもよい。
発注#1の取り消しを受信した工場400Aのデータ収集サーバ500は、受信した発注#1の取り消しをワークフロー管理装置800等に転送し、印刷のスケジュール等を更新する。
【0066】
図13は、ダイレクトメールの印刷が依頼された場合における分散的な発注の例を説明する図である。
図13には、図1との対応部分に対応する符号を付して示している。
ここでは、ユーザ端末200の1つから宛先を1000名とするダイレクトメールの印刷が印刷受発注サーバ300に依頼されている。
印刷受発注サーバ300は、例えばダイレクトメールを送付する宛先の情報に基づいて地域別の印刷オーダに分割する。図13の例では、地域AAに対応する150名分の印刷オーダと、地域BBに対応する500名分の印刷オーダと、地域CCに対応する300名分の印刷オーダと、地域DDに対応する50名分の印刷オーダに分割している。
因みに、地域AA、BB、CCは日本であり、地域DDはアメリカである。
【0067】
図13の場合、地域BBに対応する500名分の印刷オーダは、印刷事業者Yの工場1に対する400名分の印刷オーダと、印刷事業者Zの工場1に対する100名分の印刷オーダに更に分割される。
結果的に、印刷事業者Xには150名分の印刷オーダが発注され、印刷事業者Yには700名分の印刷オーダが発注され、印刷事業者Zには100名分の印刷オーダが発注され、印刷事業者Wには50名分の印刷オーダが発注される。
ここで、印刷の条件を満たす1つの印刷事業者に発注する場合であれば、印刷事業者Yが発注先に決定されたかもしれないが、本実施の形態の場合には、送付先に近い工場に印刷オーダが分散されて発注される。この結果、印刷後の送付に要する時間や配送等に要する費用の削減が可能になる。
【0068】
<実施の形態2>
続いて、実施の形態1で説明したネット印刷システム1(図1参照)を活用した他の実施の形態について説明する。
実施の形態1のネット印刷システム1を活用すると、依頼者の要求を満たすと同時に、印刷物の納品地に近い立地の1つ又は複数の工場400(図1参照)に対して、発注を割り当てることも可能になる。ここでの要求には、特定の印刷事業者や工場の指定も含めることが可能である。
一方で、この仕組が実用化されると、窓口事業者が印刷の依頼を受け付けた時点における各工場400の状況により発注の割り当て先が自動的に決定される。このため、印刷の依頼者が希望する印刷事業者や工場400であっても、用紙の在庫が不足すれば、発注先の候補から一律に除外されてしまう。
【0069】
ただし、該当する工場400が用紙を補充するために発生する納期の遅れの日数や時間を依頼者が許容できる場合がある。
そこで、本実施の形態では、印刷の依頼者が希望する工場400への発注が行えない理由が用紙の在庫の不足の場合でも、用紙の補充に伴う納期の遅れの予測が依頼者の定めた範囲内の場合には、他の工場400ではなく、依頼者が希望した工場400に優先的に発注できる機能を印刷受発注サーバ300に設ける場合について説明する。
なお、基本的なシステム構成は、実施の形態1と同様であるため、以下では、本実施の形態に特有の処理手順について説明する。
図14は、実施の形態2における発注先の決定方法を説明するフローチャートである。なお、図中のSはステップを意味する。
図14に示す処理は、印刷受発注サーバ300(図1参照)が、インターネット経由で印刷オーダを受信することで開始される。
【0070】
CPU301(図3参照)は、印刷オーダを受信すると、印刷オーダの依頼主を読み出す(ステップ101)。
次に、CPU301は、読み出された依頼主の要求仕様に希望の工場の登録があるか否かを判定する(ステップ102)。依頼主の要求仕様は、印刷オーダに含まれていてもよいし、事前に依頼者データベース304A(図7参照)に登録されていてもよい。本実施の形態の場合、要求仕様には、依頼者が印刷の発注先として希望する工場400が優先順位付きで登録されている。以下では、優先順位が1位の工場400をプライマリ工場、優先順位が2位の工場400をセカンダリ工場ともいう。プライマリ工場やセカンダリ工場は、地域別に与えられてもよい。例えば地域AAと地域BBとでプライマリ工場やセカンダリ工場が異なってもよい。なお、希望の工場の登録数は3つ以上でもよい。
なお、要求仕様には、納期の遅れを許容する場合の日数や時間等も含まれる。
要求仕様に希望の工場の登録がない場合、CPU301は、ステップ102で否定結果を得る。この場合、CPU301は、印刷オーダを満たす工場を発注先に決定する(ステップ103)。このステップ103の処理は、実施の形態1で説明した処理と同じである。
【0071】
要求仕様に希望の工場の登録がある場合、CPU301は、ステップ102で肯定結果を得る。この場合、CPU301は、依頼主が希望する工場を読み出す(ステップ104)。
まず、CPU301は、優先順位が1位の工場の最新情報を取得する(ステップ105)。すなわち、CPU301は、プライマリ工場の最新の情報を工場データベース304C(図4参照)から取得する。
次に、CPU301は、プライマリ工場の用紙の在庫が印刷オーダの実行に十分か否かを判定する(ステップ106)。なお、図14では、用紙の在庫が印刷オーダの実行に十分であれば、依頼者が指定した納期は満たすものと仮定している。例えば用紙の在庫は十分でも、印刷のスケジュールに空きがなければ納期内での印刷の完了は見込めないが、図14では、用紙の在庫以外は印刷オーダを満たすものと仮定している。
【0072】
説明を続ける。
用紙の在庫が印刷オーダを満たす場合、CPU301は、ステップ106で肯定結果を得る。この場合、CPU301は、プライマリ工場を発注先に決定する(ステップ107)。用紙の在庫が印刷オーダを満たすので、別の工場への発注を検討することなく、発注先の決定が確定する。
用紙の在庫が印刷オーダを満たさない場合、CPU301は、用紙の補充に伴う納期の予想超過時間を計算する(ステップ108)。
予想超過時間は、製紙会社等から用紙の補充を受けた工場で発注された印刷が完了すると予想される時刻が、依頼者が指定した納期を超過する時間長として計算される。この計算には、用紙が製紙会社等から工場400に配送されるまでの時間も含まれる。CPU301は、印刷が完了する予想の時刻を、プライマリ工場から取得しているスケジュールに基づいて予測する。
【0073】
次に、CPU301は、超過時間が要求仕様を満たすか否かを判定する(ステップ109)。依頼主が指定した納期の超過時間が要求仕様を満たす場合、CPU301は、ステップ109で肯定結果を得る。この場合、CPU301は、製紙会社に用紙の補充を発注する(ステップ110)。用紙の発注先となる製紙会社は、プライマリ工場の過去の発注の履歴や登録情報に基づいて決定される。この後、CPU301は、ステップ107に移動する。このように、用紙の在庫が不足する場合でも、用紙の補充に伴う納期の遅れが依頼主の定めた条件を満たす場合には、依頼者の希望を優先した発注が可能になる。この例の場合、用紙の配送先は、プライマリ工場である。
一方、ステップ108で計算された超過時間が要求仕様を満たさない場合、CPU301は、ステップ109で否定結果を得る。この場合、CPU301は、次の優先順位の工場があるか否かを判定する(ステップ111)。
ステップ111で否定結果が得られた場合、CPU301は、依頼者の希望する工場への発注を断念し、ステップ103に移行する。
【0074】
これに対し、ステップ111で肯定結果が得られた場合、CPU301は、次の優先順位の工場の最新情報を取得する(ステップ112)。例えばセカンダリ工場についての最新情報が取得されると、CPU301は、ステップ106に移動し、プライマリ工場と同様の処理を繰り返す。
すなわち、セカンダリ工場における用紙の在庫が印刷オーダの実行に十分である場合には、セカンダリ工場が発注先に決定される。また、セカンダリ工場における用紙の在庫が印刷オーダの実行に不足する場合でも、用紙の補充に伴う納期の超過が依頼主の定めた条件を満たす場合には、セカンダリ工場が発注先に決定される。
図14の場合には、印刷オーダを1つの工場に発注する前提で説明されているが、1つの印刷オーダをプライマリ工場とセカンダリ工場に分割して発注することも可能である。
この場合、個々の工場では印刷オーダを満たす用紙の在庫がなくても、2つの工場の用紙の在庫を足し合わせれば印刷オーダを満たす可能性もある。そこで、ステップ111で否定結果が得られた場合には、プライマリ工場とセカンダリ工場の両方の在庫が印刷オーダの実行に十分か否かを判定してもよい。以下の動作は、単一の工場を対象とした処理動作と同じである。
【0075】
<他の実施形態>
以上、本発明の実施の形態について説明したが、本発明の技術的範囲は上述の実施の形態に記載の範囲に限定されない。上述の実施の形態に、種々の変更又は改良を加えたものも、本発明の技術的範囲に含まれることは、特許請求の範囲の記載から明らかである。
【0076】
例えば前述の実施の形態では、印刷や加工を行う印刷事業者の工場400(図1参照)内に配置したデータ収集サーバ500(図1参照)が工場400内に配置された生産装置等で発生した又は管理される情報等を収集して印刷受発注サーバ300にアップロードしているが、アップロードする情報に生産された印刷物の出荷スケジュールを含めてもよい。
また、データ収集サーバ500を、工場400からの印刷物の出荷や配送を請け負う各地域の配送事業者の事業所内に設け、集配スケジュールや配送に従事する従業員の出勤スケジュール等を収集し、印刷受発注サーバ300(図1参照)にアップロードしてもよい。
この場合、印刷受発注サーバ300は、工場400からの出荷スケジュールや配送事業者の事業所毎の集配スケジュールも含め、印刷の発注先を決定することが可能になる。この例の場合、印刷受発注サーバ300は、配送事業者についての遅延の履歴や評価の情報も管理する。
【0077】
また、前述の実施の形態では、クレンジング(整備)をデータ収集サーバ500(図1参照)で実行しているが、データ収集サーバ500で収集された生データをセキュリティが確保された回線等を通じて印刷受発注サーバ300(図1参照)に送信し、印刷受発注サーバ300側でクレンジング(整備)を実行してもよい。クラウドサーバへの生データ等の送信には、クレンジング機能を有しないデータ収集サーバ500を用いてもよいし、ワークフロー管理装置800(図1参照)や不図示の端末装置を用いてもよい。
または、工場内で自動的に収集された生データを蓄積するクラウドサーバ上でクレンジング(整備)を実行し、クレンジング後のデータを印刷受発注サーバ300に送信してもよい。ここでのクラウドサーバは、データ収集サーバ500の一形態である。
【0078】
前述の実施の形態では、印刷受発注サーバ300で予測した用紙の需要を製紙会社Pに提供し、用紙の補充や配送を製紙会社Pの管理に委ねているが、予測された用紙の需要や各工場の用紙の在庫に基づいて、工場400に対する用紙の補充や配送を、印刷の発注とは無関係に印刷受発注サーバ300が手配してもよい。
この仕組の採用により、用紙の在庫不足を原因とする工場400の受注機会の損失の減少、印刷物の納期遅れの発生の減少、納期遅れの期間の短縮等が可能になる。
また、用紙の在庫不足を原因として別の工場400に印刷が発注されることで発生する追加の費用の抑制が可能になる。例えば製紙会社Pが受注した印刷の単位で用紙を発注する仕組みの場合には、印刷を発注する時点において、依頼者が指定した工場400で用紙が不足し、かつ、特急処理等の要望を満たすために依頼者の指定とは異なる工場400に印刷を発注されることがあり、依頼者が想定していない輸送料などの追加の費用が発生する可能性がある。また例えば印刷を発注する時点では、依頼者が指定した工場400における用紙の在庫が印刷に対して十分でも、機械の故障や印刷ミス等に起因して用紙の無駄(いわゆるヤレ)が発生する場合には、不足する用紙の調達や別の工場400への再発注等の費用が発生する可能性がある。しかし、印刷の発注とは無関係に用紙の補充を印刷受発注サーバ300が手配する場合には、前述したように、依頼者の希望する工場400に印刷が発注される可能性が高くなるので、追加の費用の発生を抑制することができる。 また、前述の実施の形態では、各工場400からリアルタイムで収集されるデータや印刷の受発注の履歴等を利用して用紙の需要を予測しているが、印刷受発注とは関係ないオープンデータ(例えば天候、物流、消費動向等のビッグデータ)も人工知能に与えて用紙の需要を学習すれば、予測の精度を一段と高めることができる。
【符号の説明】
【0079】
1…ネット印刷システム、100…インターネット、200…ユーザ端末、300…印刷受発注サーバ、304A…依頼者データベース、304B…依頼データベース、304C…工場データベース、304D…学習済みモデル、304E…用紙データベース、304F…予測需要データベース、311…オーダ受付部、312…発注先決定部、313…発注部、314…受発注関係学習部、315…分析データ計算部、316…情報提供部、350…用紙管理サーバ、400…工場、500…データ収集サーバ、504A…生データデータベース、504B…クレンジング済み生データデータベース、504C…分析結果データベース、511…生データ収集部、512…クレンジング部、513…データ分析部、514…データアップロード部、515…発注情報受信部、600…印刷装置、700…加工装置、800…ワークフロー管理装置、900…在庫管理装置、1000…センサ
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14