(57)【要約】【課題】  データ処理の各工程に適した単位でデータを管理するための技術を提供すること。【解決手段】  一連の処理で用いられるデータが第１の単位で第１のディレクトリに格納されている状態で、該一連の処理における第１の工程が完了したとする。このとき、該データを、該第１の工程の次の工程である第２の工程に応じた第２の単位で、該第１のディレクトリとは異なる第２のディレクトリに格納する。【選択図】  図１
2017134543.tif 000002
【特許請求の範囲】
【請求項１】
一連の処理で用いられるデータが第１の単位で第１のディレクトリに格納されている状態で、該一連の処理における第１の工程が完了すると、該データを、該第１の工程の次の工程である第２の工程に応じた第２の単位で、該第１のディレクトリとは異なる第２のディレクトリに格納する格納制御手段を備えることを特徴とする情報処理システム。
【請求項２】
前記第２のディレクトリは、前記情報処理システムと、前記データを前記第２の単位で用いて前記第２の工程を行う装置と、がアクセス可能なディレクトリであることを特徴とする請求項１に記載の情報処理システム。
【請求項３】
前記格納制御手段は、前記第１のディレクトリにデータの保持期限が設定されてない場合には、前記データを前記第２のディレクトリに格納したあと、該データを前記第１のディレクトリから削除することを特徴とする請求項１又は２に記載の情報処理システム。
【請求項４】
前記格納制御手段は、フォトブックのデータを作成する外部装置から該データを注文データとして受信すると、該注文データをフォトブック単位でディレクトリＡに格納することを特徴とする請求項１乃至３の何れか１個に記載の情報処理システム。
【請求項５】
前記格納制御手段は、前記ディレクトリＡに格納されている注文データについて決済が完了した旨を、決済処理を行う外部装置から受信すると、該注文データを注文単位でディレクトリＢに格納することを特徴とする請求項４に記載の情報処理システム。
【請求項６】
前記格納制御手段は、前記ディレクトリＢに格納されている注文データについて注文の受付が完了した旨を、決済処理を行う外部装置から受信すると、該注文データをフォトブックの製本及び出荷を行う業者単位でディレクトリＣに格納することを特徴とする請求項５に記載の情報処理システム。
【請求項７】
前記格納制御手段は、前記ディレクトリＣに格納されている注文データについて出荷が完了した旨を、前記業者の外部装置から受信すると、該注文データを該業者単位でディレクトリＤに格納することを特徴とする請求項６に記載の情報処理システム。
【請求項８】
単一または複数の装置によって構成されることを特徴とする請求項１乃至７の何れか１項に記載の情報処理システム。
【請求項９】
一連の処理で用いられるデータが第１の単位で第１のディレクトリに格納されている状態で、該一連の処理における第１の工程が完了すると、該データを、該第１の工程の次の工程である第２の工程に応じた第２の単位で、該第１のディレクトリとは異なる第２のディレクトリに格納することを特徴とする情報処理方法。
【請求項１０】
コンピュータを、請求項１乃至８の何れか１項に記載の情報処理システムの格納制御手段として機能させるためのコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データの管理技術に関するものである。
【背景技術】
【０００２】
近年、ウェブサイト上のオンライン店舗を介して商品の注文を受け付け、実物の商品を配送するサービス（オンラインショッピング）が盛んに行われている。オンラインショッピングにおいては、既製品をオンライン店舗で販売するものもあるが、ユーザの要望にあった商品、いわゆるオーダーメイド品を扱うサービスもある。例えば、予め用意されたアルバムテンプレートをユーザが選択し、ユーザが撮影した写真をアップロードすることで、ユーザ独自の写真アルバムを作成して配送するフォトブック作成サービスも行われている。
【０００３】
このようなオーダーメイド品を扱う場合、ユーザから注文データを受け付け、決済処理を行い、注文内容通りに商品を作成し、配送するといった一連の流れにおいて、様々なシステムが連携する必要がある。そして、各システムにおいて、注文データの扱い方にも違いがあるため、注文受付から配送までの各ステータスに応じて適切なデータ管理が求められる。
【０００４】
特許文献１には、文書データの承認ステータスに応じて保管エリアを分ける仕組みについて開示されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１４―１８２６０３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
上述の通り、フォトブック作成サービスは、フォトブックの作成から配送までを実現するために複数のシステムによって成り立っている。具体的には、フォトブックの編集、注文を行うシステム、注文と決済を管理するシステム、フォトブックの印刷、配送を管理するシステム、各システムを仲介する管理システム等がある。
【０００７】
このように、例えばフォトブック作成サービスにおいては、各ステータスにおいて連携するシステムが異なることから、連携先のシステムによってデータが管理される際の適切なデータ単位が、連携先のシステムに応じて異なる場合がある。
【０００８】
本発明は上記の問題に鑑みてなされたもので、データ処理の各工程に適した単位でデータを管理するための技術を提供する。
【課題を解決するための手段】
【０００９】
本発明の一様態は、一連の処理で用いられるデータが第１の単位で第１のディレクトリに格納されている状態で、該一連の処理における第１の工程が完了すると、該データを、該第１の工程の次の工程である第２の工程に応じた第２の単位で、該第１のディレクトリとは異なる第２のディレクトリに格納する格納制御手段を備えることを特徴とする。
【発明の効果】
【００１０】
本発明の構成によれば、データ処理の各工程に適した単位でデータを管理することができる。
【図面の簡単な説明】
【００１１】
【図１】システムの構成例を示すブロック図。
【図２】システムの動作の概略を示すシーケンス図。
【図３】管理システム４０が行う処理のフローチャート。
【図４】各ディレクトリを説明する図。
【図５】ディレクトリ、格納データ単位、ステータスの関係を説明する図。
【図６】削除処理のフローチャート。
【図７】注文のキャンセル指示を受けた場合に行う処理のフローチャート。
【図８】注文データのダウンロード処理の一例のフローチャート。
【図９】ラボ管理アプリ３０による出荷完了通知の送信を説明する図。
【図１０】コンピュータ装置のハードウェア構成例を示すブロック図。
【発明を実施するための形態】
【００１２】
以下、添付図面を参照し、本発明の実施形態について説明する。なお、以下説明する実施形態は、本発明を具体的に実施した場合の一例を示すもので、特許請求の範囲に記載した構成の具体的な実施例の１つである。
【００１３】
［第１の実施形態］
本実施形態では、フォトブック（アルバム）の作成サービスを提供するシステムについて説明する。先ず、フォトブックの作成サービスを提供するシステムの構成例について、図１のブロック図を用いて説明する。図１のシステムは、ユーザからフォトブックの作成依頼を受けると、該作成依頼に基づいてフォトブックを作成し、該作成したフォトブックを該作成依頼に応じた出荷先に出荷するための一連のシーケンスを実現するための複数の装置によって構成される。
【００１４】
ユーザ端末は、フォトブックの作成及び作成依頼を行うためにユーザが操作する装置であり、ＰＣ（パーソナルコンピュータ）、スマートフォン、タブレット端末装置などの装置によって構成されている。このユーザ端末には、フォトブックの作成及び作成依頼を行うためのアプリケーションソフトウェアとして、編集・注文アプリ１０がインストールされている。
【００１５】
ＥＣサイト２０は、ユーザ端末から作成依頼されたフォトブックに対する決済を管理するためのシステムであり、単一の装置で構成しても良いし、複数の装置で構成しても良い。
【００１６】
ラボは、作成依頼されたフォトブックを作成して出荷するためのシステムであり、単一若しくは複数の装置によって構成されている。ラボには、作成依頼されたフォトブックの作成及び出荷を管理するためのアプリケーションソフトウェアとして、ラボ管理アプリ３０がインストールされている。
【００１７】
上記のユーザ端末、ＥＣサイト２０、ラボは何れもインターネットなどのネットワークに接続されている。なお、図１には、ユーザ端末、ＥＣサイト２０、ラボはそれぞれ１つとしているが、複数であっても良い。
【００１８】
管理システム４０は、ユーザ端末からの作成依頼を管理し、上記のユーザ端末とＥＣサイト２０とラボとの間の連携を仲介することで、フォトブックの作成及び出荷をサポートする情報処理システムの一例であり、単一若しくは複数の装置によって構成される。管理システム４０は、制御部４１とファイルサーバ４２とを有する。
【００１９】
先ず、制御部４１について説明する。制御部４１は、編集・注文アプリ連携部４１１、ＥＣサイト連携部４１２、ダウンロード連携部４１３を有する。編集・注文アプリ連携部４１１は、ユーザ端末に係るデータ処理、ＥＣサイト連携部４１２は、ＥＣサイト２０に係るデータ処理、ダウンロード連携部４１３は、ラボに係るデータ処理、を行う。
【００２０】
次に、ファイルサーバ４２について説明する。ファイルサーバ４２は、ユーザ端末から受信したフォトブックの作成依頼のデータ（注文データ）を、該フォトブックの作成の進行の度合いに応じて管理するべく、複数のディレクトリを有している。この複数のディレクトリには、アップロードディレクトリ４２１、注文完了ディレクトリ４２２、ダウンロードディレクトリ４２３、出荷完了ディレクトリ４２４、が含まれている。
【００２１】
なお、図１では、制御部４１とファイルサーバ４２とは別個の装置として示しているが、制御部４１とファイルサーバ４２とを１台の装置で構成しても良い。また、管理システム４０もまた、上記のネットワークに接続されている。
【００２２】
次に、図１のシステムの動作の概略について、図２のシーケンス図を用いて説明する。図２では、ユーザ端末からの作成依頼に基づいてフォトブックを作成して出荷するまでの一連のシーケンスにおいて、ユーザ端末（編集・注文アプリ１０）、ＥＣサイト２０、管理システム４０、ラボ、ラボ管理アプリ３０のそれぞれの動作を示している。なお、以下では、アプリケーションソフトウェアを処理の主体として説明する場合があるが、実際には、該アプリケーションソフトウェアがインストールされた装置のプロセッサが該アプリケーションソフトウェアを実行することで対応する機能が実現される。
【００２３】
＜Ｓ１０１＞
編集・注文アプリ１０は、ユーザ端末に対するユーザの操作に応じて、フォトブックの作成や編集を行う。例えば、編集・注文アプリ１０は、フォトブックのページにレイアウトする画像の配置パターンを示すテンプレートを複数枚、ユーザ端末の表示画面に一覧表示してユーザによる選択操作を受け付ける。また、編集・注文アプリ１０は、フォトブックのページにレイアウトする画像の候補をユーザ端末の表示画面に一覧表示してユーザによる選択操作を受け付ける。そして、編集・注文アプリ１０は、ユーザが選択したテンプレートにユーザが選択した画像をレイアウトしてフォトブックのページを作成する。このように編集・注文アプリ１０は、ユーザがフォトブックのページを作成するための様々な機能を提供する。
【００２４】
＜Ｓ１０２＞
ユーザがユーザ端末を用いてフォトブックの作成完了を示す指示を入力すると、編集・注文アプリ１０は、ユーザが作成したフォトブックのデータを注文データとして管理システム４０に対して送信（アップロード）する。このデータには、テンプレートのデータや該テンプレートにレイアウトする画像のデータなど、フォトブックの作成依頼に必要な様々なデータが含まれている。
【００２５】
管理システム４０（編集・注文アプリ連携部４１１）は、ユーザ端末からアップロードされた注文データを、アップロードディレクトリ４２１に格納する。このアップロードディレクトリ４２１は、管理システム４０以外ではユーザ端末のみがアクセス可能なディレクトリであって、ＥＣサイト２０、ラボなど、他の装置からはアクセスできないように設定されているディレクトリである。
【００２６】
＜Ｓ１０３＞
管理システム４０（編集・注文アプリ連携部４１１）は、編集・注文アプリ１０から注文データのアップロード完了通知を受けると、アップロード完了処理を行う。アップロード完了処理については、図３を用いて後述する。
【００２７】
＜Ｓ１０４＞
ユーザがユーザ端末を操作して、先にアップロードした注文データに対する決済指示をＥＣサイト２０に対して行うと、ＥＣサイト２０は、該注文データに対する決済処理を行う。なお、この決済指示には、フォトブックの配送先に関する情報（氏名や住所など）、成果物（フォトブック）に関する情報、発注者に関する情報（住所や氏名など）を含む注文情報が含まれているものとする。そしてＥＣサイト２０は、決済処理が完了すると、決済処理完了の旨を管理システム４０に対して通知する。
【００２８】
＜Ｓ１０５＞
管理システム４０（ＥＣサイト連携部４１２）は、決済処理完了の旨をＥＣサイト２０から受信すると、仮注文受付完了処理を行う。仮注文受付完了処理については、図３を用いて後述する。
【００２９】
＜Ｓ１０６＞
ＥＣサイト２０は、Ｓ１０４においてユーザ端末から受信した注文情報を管理システム４０に対して送信する。
【００３０】
＜Ｓ１０７＞
管理システム４０（ＥＣサイト連携部４１２）は、ＥＣサイト２０から注文情報を受信すると、注文受付完了処理を行う。注文受付完了処理については、図３を用いて後述する。
【００３１】
＜Ｓ１０８＞
ラボ（ラボ管理アプリ３０）は、管理システム４０から注文データ及び注文情報をダウンロードする。以下では、特に断らない限りは、「注文データのダウンロード」には、対応する注文情報のダウンロードも含まれているものとする。
【００３２】
＜Ｓ１０９＞
ラボ管理アプリ３０は、注文データ及び注文情報のダウンロードが完了すると、管理システム４０に対してダウンロード完了通知を送信する。管理システム４０（ダウンロード連携部４１３）は、ラボ管理アプリ３０からダウンロード完了通知を受信すると、ダウンロード完了処理を実行する。ダウンロード完了処理については、図３を用いて後述する。
【００３３】
＜Ｓ１１０＞
ラボは、ダウンロードした注文データに基づいて印刷処理、製本処理を行ってフォトブック（成果物）を作成する。そしてラボは、作成したフォトブックを注文情報に基づく配送先に配送するための処理を行う。
【００３４】
＜Ｓ１１１＞
ラボ（ラボ管理アプリ３０）は、フォトブックの出荷が完了すると、管理システム４０に対して出荷完了通知を送信する。例えば、フォトブックの出荷が完了すると、その旨をユーザがラボに入力し、これを受けてラボ管理アプリ３０は管理システム４０に対して出荷完了通知を送信する。
【００３５】
＜Ｓ１１２＞
管理システム４０（ダウンロード連携部４１３）は、ラボ管理アプリ３０から送信された出荷完了通知を受信すると、出荷完了処理を行う。出荷完了処理については、図３を用いて後述する。
【００３６】
次に、上記のアップロードディレクトリ４２１、注文完了ディレクトリ４２２、ダウンロードディレクトリ４２３、出荷完了ディレクトリ４２４について、図４を用いて説明する。
【００３７】
アップロードディレクトリ４２１とは、ユーザ端末からアップロードされた注文データを保持するためのディレクトリであり、アップロードディレクトリ４２１に格納された注文データのステータスは「アップロード完了」（ＳＴ１）に設定される。また、このアップロードディレクトリ４２１へは、管理システム４０以外では編集・注文アプリ１０のみがアクセス可能であり、それ以外の装置（アプリケーションソフトウェア）はアクセスできない。また、アップロードディレクトリ４２１は、注文データを、格納日時から７日間（データ保持期限）は保持し続けることができるが、格納日時から７日以上が経過した注文データはアップロードディレクトリ４２１から削除される。
【００３８】
注文完了ディレクトリ４２２とは、アップロードディレクトリ４２１に格納されている注文データのうちＥＣサイト２０による決済処理が完了した注文データをコピーして保持するためのディレクトリである。アップロードディレクトリ４２１から注文完了ディレクトリ４２２にコピーされた注文データのステータスは「仮注文受付完了」（ＳＴ２）となる。そして、後述する注文情報を受領した注文データについては、そのステータスは「注文受付完了」（ＳＴ３）となり、ダウンロードディレクトリ４２３にコピーされる。注文完了ディレクトリ４２２へは、管理システム４０のみがアクセス可能となり、それ以外の装置（アプリケーションソフトウェア）はアクセスできない。また、注文完了ディレクトリ４２２のデータ保持期限は無期限に設定されており、これは、注文完了ディレクトリ４２２のデータ保持期限は設定されていないことを示している。
【００３９】
ダウンロードディレクトリ４２３とは、上記の通り、注文情報を受領した注文データを保持するためのディレクトリであり、ダウンロードディレクトリ４２３に格納された注文データのステータスは「ダウンロード待ち」（ＳＴ４）となる。そして、ダウンロードディレクトリ４２３に格納されている注文データのうちラボによってダウンロードされた注文データについては、そのステータスは「ダウンロード完了」（ＳＴ５）となる。ダウンロードディレクトリ４２３へは、管理システム４０以外ではラボ管理アプリ３０のみがアクセス可能となり、それ以外の装置（アプリケーションソフトウェア）はアクセスできない。また、ダウンロードディレクトリ４２３のデータ保持期限は無期限に設定されており、これは、ダウンロードディレクトリ４２３のデータ保持期限は設定されていないことを示している。なお、注文の前提として、１注文につき複数のアルバムを注文可能であり、配送先は１アルバムごとに選択可能である。
【００４０】
出荷完了ディレクトリ４２４とは、ダウンロードディレクトリ４２３に格納されている注文データのうち、ラボから出荷が完了したフォトブックの注文データをコピーして保持するためのディレクトリである。出荷完了ディレクトリ４２４に格納された注文データのステータスは「出荷完了」（ＳＴ６）となる。出荷完了ディレクトリ４２４へは、管理システム４０以外ではラボ管理アプリ３０のみがアクセス可能となり、それ以外の装置（アプリケーションソフトウェア）はアクセスできない。また、出荷完了ディレクトリ４２４は、注文データを、格納日時から３０日間（データ保持期限）は保持し続けることができるが、格納日時から３０日以上が経過した注文データは出荷完了ディレクトリ４２４から削除される。
【００４１】
なお、何れのディレクトリについても、データ保持期限については、管理システム４０のユーザが不図示の操作部を操作して設定しても良いし、予め設定されていても良い。なお、図４に示したデータ保持期限は一例であり、これに限るものではない。
【００４２】
このように、各ディレクトリにアクセス制御をかけることで、連携しない装置（アプリケーションソフトウェア）からの誤ったアクセスを防ぐことが可能となり、情報漏洩等を低減させることが可能となる。
【００４３】
次に、上記のＳ１０３、Ｓ１０５、Ｓ１０７、Ｓ１０９、Ｓ１１２の各処理を含む、管理システム４０が行う処理について、図３のフローチャートを用いて説明する。
【００４４】
＜Ｓ２０１＞
編集・注文アプリ連携部４１１は、ユーザ端末から注文データを受信すると、該受信した注文データをアップロードディレクトリ４２１に格納する。ユーザ端末からの注文データのアップロード方法として、例えば、管理システム４０から予めアップロードディレクトリ４２１のＵＲＬをユーザ端末に対して送信しておく。そして、ユーザ端末側で該ＵＲＬを指定してアップロード操作を行うことで、注文データをアップロードディレクトリ４２１にアップロードする。
【００４５】
＜Ｓ２０２＞
編集・注文アプリ連携部４１１は、Ｓ２０１においてアップロードディレクトリ４２１に格納した注文データのステータスを「アップロード完了」（ＳＴ１）に設定する。例えば、ユーザ端末は注文データのアップロードが完了すると、管理システム４０に対してアップロード完了通知を送信する。編集・注文アプリ連携部４１１は該アップロード完了通知を受信すると、Ｓ２０１においてアップロードディレクトリ４２１に格納した注文データのステータスを「アップロード完了」（ＳＴ１）に設定する。
【００４６】
アップロードディレクトリ４２１には図５に示す如く、フォトブック（アルバム）単位で注文データが格納され、アップロードディレクトリ４２１に格納された注文データのステータスは「アップロード完了」（ＳＴ１）に設定される。図５ではアルバム１〜４の４つのアルバムの注文データがアルバム単位で格納されている。また、上記の通り、このアップロードディレクトリ４２１は、管理システム４０以外では編集・注文アプリ１０のみがアクセス可能なディレクトリである。然るに編集・注文アプリ１０は、アップロードディレクトリ４２１にアップロードした注文データを適宜編集することができる。
【００４７】
＜Ｓ２０３＞
ＥＣサイト連携部４１２は、決済処理完了の旨（仮注文受付完了の通知）をＥＣサイト２０から受信したか否かを判断する。この判断の結果、受信した場合には、処理はＳ２０４に進み、受信していない場合には、処理はＳ２０３で待機する。
【００４８】
＜Ｓ２０４＞
ＥＣサイト２０から受信した「仮注文受付完了の通知」には、決済処理がなされた注文データを特定する特定情報が含まれている。特定情報は、決済単位でＥＣサイト２０から発行されるもので、１つのアルバムＸについての決済が完了した場合には、該アルバムＸを特定する特定情報がＥＣサイト２０から発行される。また、複数のアルバムＹ，Ｚ，Ｗをまとめて決済した場合には、該アルバムＹ，Ｚ，Ｗを特定する特定情報がＥＣサイト２０から発行される。ＥＣサイト連携部４１２は、ＥＣサイト２０から発行された特定情報が示す注文データ（群）を１つの注文グループにグループ化する。
【００４９】
＜Ｓ２０５＞
ＥＣサイト連携部４１２は、上記注文グループを、アップロードディレクトリ４２１から注文完了ディレクトリ４２２に格納（コピー）する。これにより注文完了ディレクトリ４２２には、決済単位で注文データが管理されることになる。
【００５０】
＜Ｓ２０６＞
編集・注文アプリ連携部４１１は、アップロードディレクトリ４２１のデータ保持期限が設定されているか否かを判断する。この判断の結果、アップロードディレクトリ４２１のデータ保持期限が設定されている場合には、処理はＳ２０８に進み、設定されていない場合には、処理はＳ２０７に進む。図４の例では、アップロードディレクトリ４２１にはデータ保持期限として「７日間」が設定されているため、処理はＳ２０８に進むことになる。
【００５１】
＜Ｓ２０７＞
編集・注文アプリ連携部４１１は、コピー元となるアップロードディレクトリ４２１内の上記注文グループを削除する。なお、図３では触れていないが、データ保持期限が設定されている場合、編集・注文アプリ連携部４１１は、格納日時からの経過時間がデータ保持期限を越えていれば、同様に削除を行う。これについては図６を用いて後述する。
【００５２】
＜Ｓ２０８＞
ＥＣサイト連携部４１２は、Ｓ２０５で注文完了ディレクトリ４２２に格納した注文グループに属するそれぞれの注文データのステータスを「仮注文受付完了」（ＳＴ２）に設定する。注文完了ディレクトリ４２２には図５に示す如く、注文単位で注文データが格納され、注文完了ディレクトリ４２２に格納された注文データのステータスは「仮注文受付完了」（ＳＴ２）に設定される。図５ではアルバム１〜３をまとめて決済し、アルバム４については別途決済している。そのため、アルバム１〜３の注文データを１つの注文グループ（注文１）とし、アルバム４の注文データを別の１つの注文グループ（注文２）として管理している。また、上記の通り、この注文完了ディレクトリ４２２は、管理システム４０のみがアクセス可能なディレクトリである。
【００５３】
＜Ｓ２０９＞
ＥＣサイト連携部４１２は、ＥＣサイト２０から注文情報を受信したか否かを判断する。この判断の結果、受信した場合には、処理はＳ２１０に進み、受信していない場合には、処理はＳ２０９で待機する。図５の例では、上記の如く、アルバム１〜３をまとめて１つの注文グループ（注文１）として決済し、アルバム４については別途、１つの注文グループ（注文２）とし決済している。そのため、ＥＣサイト２０からは、注文１についての注文情報と、注文２についての注文情報と、を受信することになる。注文１についての注文情報には、アルバム１〜３のそれぞれの配送先として、配送先１、配送先２、配送先１が指定されており、注文２についての注文情報には、アルバム４の配送先として配送先２が指定されている。
【００５４】
＜Ｓ２１０＞
ＥＣサイト連携部４１２は、注文情報を受信した注文グループ（注文情報を受領した注文グループ）に属する注文データのステータスを「注文受付完了」（ＳＴ３）に設定する。
【００５５】
＜Ｓ２１１＞
ＥＣサイト連携部４１２は、注文グループごとに、該注文グループに属する注文データを、注文先のラボが同じ注文データのグループに分割する。ユーザ端末のユーザは、どのラボにフォトブックの作成を依頼するのかを、注文データ単位で指定することができる。ユーザ端末のユーザが、フォトブックの依頼先のラボを指定して注文データの送信指示を入力すると、ユーザ端末は、フォトブックの依頼先のラボを特定するための情報（ラボ情報）を含む注文データを管理システム４０に対して送信する。然るにＥＣサイト連携部４１２は、注文グループに属する注文データ群を、同じラボ情報を含む注文データのグループに分割する。
【００５６】
＜Ｓ２１２＞
ダウンロード連携部４１３は、Ｓ２１１で分割したそれぞれの分割グループ（分割できなかったグループについては該分割していない元のグループ）をダウンロードディレクトリ４２３に格納（コピー）する。
【００５７】
＜Ｓ２１３＞
ＥＣサイト連携部４１２は、注文完了ディレクトリ４２２のデータ保持期限が設定されているか否かを判断する。この判断の結果、注文完了ディレクトリ４２２のデータ保持期限が設定されている場合には、処理はＳ２１５に進み、設定されていない場合には、処理はＳ２１４に進む。図４の例では、注文完了ディレクトリ４２２にはデータ保持期限として「無期限」が設定されているため、処理はＳ２１４に進むことになる。
【００５８】
＜Ｓ２１４＞
ＥＣサイト連携部４１２は、コピー元となる注文完了ディレクトリ４２２内の上記注文グループを削除する。なお、図３では触れていないが、データ保持期限が設定されている場合、ＥＣサイト連携部４１２は、格納日時からの経過時間がデータ保持期限を越えていれば、同様に削除を行う。これについては図６を用いて後述する。
【００５９】
＜Ｓ２１５＞
ダウンロード連携部４１３は、Ｓ２１２でダウンロードディレクトリ４２３に格納した注文グループに属するそれぞれの注文データのステータスを「ダウンロード待ち」（ＳＴ４）に設定する。
【００６０】
図５では、注文１の注文グループは、「ラボ１」をフォトブックの依頼先として指定したアルバム１，２の注文データのグループと、「ラボ２」をフォトブックの依頼先として指定したアルバム３の注文データのグループと、に分割して管理されている。また、注文２の注文グループには、１つの注文データしか属していないため、グループ分割は行わず、注文２の注文グループは、「ラボ１」をフォトブックの依頼先として指定したアルバム４の注文データのグループとして管理される。
【００６１】
＜Ｓ２１６＞
ダウンロード連携部４１３は、ラボからダウンロード完了通知を受けたか否かを判断する。この判断の結果、ダウンロード完了通知を受けた場合には、処理はＳ２１７に進み、受けていない場合には、処理はＳ２１６で待機する。ここで、管理システム４０とラボとの間で行われる、注文データのダウンロード処理の一例について、図８のフローチャートを用いて説明する。
【００６２】
＜Ｓ５０１＞
ラボ管理アプリ３０は定期的若しくは不定的に、ステータスが「ダウンロード待ち」の注文データの識別情報（注文ＩＤ）のリスト、「ダウンロード完了」の注文データの注文ＩＤのリスト、「出荷完了」の注文データの注文ＩＤのリストを要求する。要求先は管理システム４０である。
【００６３】
＜Ｓ５０２＞
制御部４１は、要求されたそれぞれのリストの格納先を示すＵＲＬをラボ管理アプリ３０に対して送信する。
【００６４】
＜Ｓ５０３＞
ラボ側のユーザが、管理システム４０から送信されたそれぞれのＵＲＬのうち何れかを指定すると、ラボ管理アプリ３０は、指定されたＵＲＬにアクセスする。
【００６５】
＜Ｓ５０４＞
ラボ管理アプリ３０は、Ｓ５０３においてアクセスしたＵＲＬに格納されているリストを、管理システム４０からダウンロードする。なお、注文ＩＤやそのリストは、管理システム４０に格納されていても良いし、管理システム４０がアクセス可能な外部装置に格納されていても良い。
【００６６】
＜Ｓ５０５＞
ラボ側の表示画面には、Ｓ５０４でダウンロードしたリストが表示される。ユーザはこのリストを参照してダウンロードしたい注文データを指定する。ダウンロードしたい注文データの指定がなされると、ラボ管理アプリ３０は、指定された注文データのＵＲＬを要求する。要求先は管理システム４０である。
【００６７】
＜Ｓ５０６＞
制御部４１は、要求されたそれぞれの注文データの格納先を示すＵＲＬをラボ管理アプリ３０に対して送信する。
【００６８】
＜Ｓ５０７＞
ラボ側のユーザが、管理システム４０から送信されたそれぞれのＵＲＬのうち何れかを指定すると、ラボ管理アプリ３０は、指定されたＵＲＬにアクセスする。
【００６９】
＜Ｓ５０８＞
ラボ管理アプリ３０は、Ｓ５０７においてアクセスしたＵＲＬに格納されている注文データを、管理システム４０からダウンロードする。そしてラボ管理アプリ３０は、ダウンロードが完了すると、管理システム４０に対してダウンロード完了通知を送信する。
【００７０】
なお、一度ダウンロードが完了したあとも、ラボからユーザに対する配送不備などで再度注文データの取得が必要になることがある。その場合は、Ｓ５０５〜Ｓ５０８の処理を再度実行することで、再度注文データをダウンロードする。なお、管理システム４０は、ラボ管理アプリ３０により指定された注文データが存在しない場合は、ＵＲＬは発行せずにエラーを返す。
【００７１】
＜Ｓ２１７＞
ダウンロード連携部４１３は、ダウンロードディレクトリ４２３に保持されている注文データのうち、ラボ管理アプリ３０によってダウンロードされた注文データのステータスを「ダウンロード完了」（ＳＴ５）に設定する。
【００７２】
＜Ｓ２１８＞
ダウンロード連携部４１３は、ラボ管理アプリ３０から出荷完了通知を受信したか否かを判断する。この判断の結果、受信した場合には、処理はＳ２１９に進み、受信していない場合には、処理はＳ２１８で待機する。ラボ管理アプリ３０による出荷完了通知の送信について、図９を用いて説明する。
【００７３】
＜Ｓ６０１＞
ラボ管理アプリ３０は、フォトブックの出荷が完了すると、管理システム４０に対して出荷完了通知を送信する。この出荷完了通知には、出荷元（ラボ）を特定するための情報（ラボＩＤ）、出荷したフォトブックの注文データを特定するための情報（例えば注文ＩＤ）、発送番号、などが含まれている。
【００７４】
＜Ｓ６０２＞
ダウンロード連携部４１３は、ラボ管理アプリ３０から送信された出荷完了通知を受信すると、該出荷完了通知をラボ配送データＤ１として登録する。ラボ配送データＤ１は、例えば、Ｄ１０で示すラボＩＤ、Ｄ１１で示す注文ＩＤ、Ｄ１２で示す発送番号、Ｄ１３で示す出荷完了日時、を含む。
【００７５】
＜Ｓ６０３＞
ダウンロード連携部４１３は、Ｓ６０２の登録処理が完了すると、ラボ管理アプリ３０に対して、出荷完了受付処理が完了した旨を通知する。
【００７６】
＜Ｓ２１９＞
ダウンロード連携部４１３は、ダウンロードディレクトリ４２３に保持されている注文データのうち、出荷完了通知に含まれている注文ＩＤに対応する注文データを、出荷完了ディレクトリ４２４に格納（コピー）する。
【００７７】
＜Ｓ２２０＞
ダウンロード連携部４１３は、ダウンロードディレクトリ４２３のデータ保持期限が設定されているか否かを判断する。この判断の結果、ダウンロードディレクトリ４２３のデータ保持期限が設定されている場合には、処理はＳ２２２に進み、設定されていない場合には、処理はＳ２２１に進む。図４の例では、ダウンロードディレクトリ４２３にはデータ保持期限として「無期限」が設定されているため、処理はＳ２２１に進むことになる。
【００７８】
＜Ｓ２２１＞
ダウンロード連携部４１３は、コピー元となるダウンロードディレクトリ４２３内の注文データを削除する。なお、図３では触れていないが、データ保持期限が設定されている場合、ダウンロード連携部４１３は、格納日時からの経過時間がデータ保持期限を越えていれば、同様に削除を行う。これについては図６を用いて後述する。
【００７９】
＜Ｓ２２２＞
ダウンロード連携部４１３は、出荷完了ディレクトリ４２４に格納されているそれぞれの注文データのステータスを「出荷完了」（ＳＴ６）に設定する。
【００８０】
次に、ディレクトリにデータ保持期限が設定されている場合に、該ディレクトリ内の注文データの格納日時からの経過時間がデータ保持期限を越えているか否かに応じて該注文データの削除の可否を制御する処理について図６のフローチャートを用いて説明する。なお、図６のフローチャートにおいて、Ｓ３０１〜Ｓ３０９のループ処理は、ディレクトリごとに行われる処理である。Ｓ３０４〜Ｓ３０８のループ処理は、該ディレクトリに格納されているそれぞれの注文データについて行われる処理である。また、図６のフローチャートに従った処理は、例えば、図３のフローチャートに従った処理とは別のスレッドにおいて実行されている。
【００８１】
Ｓ３０１では、未選択のディレクトリを選択ディレクトリとし、Ｓ３０２では、選択ディレクトリのデータ保持期限を取得し、Ｓ３０３では、該取得したデータ保持期限が無期限であるか否かを判断する。該取得したデータ保持期限が無期限である、すなわち、データ保持期限が無い場合には、処理はＳ３０９に進み、その後、Ｓ３０１以降の処理を行う。一方、該取得したデータ保持期限が無期限ではない、すなわち、データ保持期限がある場合には、処理はＳ３０４に進む。Ｓ３０４では、選択ディレクトリに格納されているそれぞれの注文データのうち未選択の注文データを選択注文データとして選択し、Ｓ３０５では、該選択注文データの格納日時を取得する。ディレクトリへのデータの格納日時については、ＯＳ（オペレーティングシステム）等が管理しているため、これを取得する。データの格納日時の取得方法はこれに限るものではない。そして、Ｓ３０６では、取得した格納日時からの経過時間が、選択ディレクトリのデータ保持期限を越えているか否かを判断する。この判断の結果、超えている場合には、処理はＳ３０７に進む。一方、超えていない場合には、処理はＳ３０８に進み、その後、Ｓ３０４以降の処理を行う。Ｓ３０７では、選択注文データを削除する。
【００８２】
次に、管理システム４０が注文のキャンセル指示を受けた場合に行う処理について、図７のフローチャートを用いて説明する。図７のフローチャートに従った処理は例えば、注文データをユーザ端末から管理システム４０にアップロードした後、ユーザがユーザ端末を操作して、該注文データに基づくフォトブックの注文をキャンセルする指示を管理システム４０に送信した場合に行われる。また、該アップロードから所定時間が経過するまでに支払いがなかった（ユーザ端末から決済指示が無かった、決済指示は有ったものの、何らかの理由で決済処理が失敗した等）とする。このような場合、ＥＣサイト連携部４１２は、この注文データに基づくフォトブックの注文をキャンセルする指示を管理システム４０に送信するので、図７のフローチャートは、このようなケースにおいても実行可能である。
【００８３】
Ｓ４０１では、編集・注文アプリ連携部４１１やＥＣサイト連携部４１２は、キャンセル指示（キャンセル通知）を受け付けている。Ｓ４０２では、キャンセル指示を受けた機能部（編集・注文アプリ連携部４１１若しくはＥＣサイト連携部４１２）は先ず、受け付けたキャンセル指示の対象となっている注文データのステータスを取得する。そして該機能部は、該取得したステータスが、キャンセル可能なステータスか否かを判断する。例えば、すでにキャンセルされたことを示すステータス、支払期限が超過したことを示すステータス、製造不可のステータス、等のステータスが設定されている注文データについてはキャンセル不可能とする。すでにキャンセルされたことを示すステータス、支払期限が超過したことを示すステータス、製造不可のステータス、のようなステータスについては、例えば、管理システム４０が、対応する状況が発生した場合に適宜設定する。また、それ以外のステータスの注文データについてはキャンセル可能とする。このように、どのようなステータスの注文データをキャンセル可能／不可能とするのか、については、特定のケースに限るものではなく、例えば、管理システム４０のユーザが適宜設定しても良い。
【００８４】
Ｓ４０２の判断の結果、キャンセル可能であれば、処理はＳ４０３に進み、キャンセル不可能であれば、図６のフローチャートに従った処理は完了する。Ｓ４０３では、キャンセル指示を受けた機能部は、受け付けたキャンセル指示の対象となっている注文データのステータスと、キャンセル指示の種別と、から、該注文データが格納されているディレクトリを特定する。例えば、キャンセル指示の種別が支払期限超過によるキャンセルの場合、該キャンセル指示は決済処理が完了するまでの注文データに対するキャンセル指示であるから、注文データはアップロードディレクトリか注文完了ディレクトリの何れかに格納されている。そして、キャンセル対象の注文データのステータスがＳＴ１であれば、該注文データはアップロードディレクトリ４２１に格納されていることを特定でき、ＳＴ２であれば、該注文データは注文完了ディレクトリ４２２に格納されていることを特定できる。
【００８５】
また、ユーザ端末からのキャンセル指示は、どのステータスの注文データに対してもキャンセルをすることが可能であるため、キャンセル指示の種別からは格納先のディレクトリを特定できない。そのため、アップロードディレクトリ４２１、注文完了ディレクトリ４２２、ダウンロードディレクトリ４２３、出荷完了ディレクトリ４２４のすべてをＳ４０４の対象として特定する。
【００８６】
なお、キャンセル指示の対象となっている注文データが格納されているディレクトリを特定するための処理はこれに限るものではない。たとえば、キャンセル指示によって一意に注文データが特定可能であれば、該キャンセル指示を用いてキャンセル指示の対象となっている注文データを特定しても良い。
【００８７】
Ｓ４０４では、キャンセル指示を受けた機能部は、Ｓ４０３において特定されたディレクトリに、キャンセル指示の対象となっている注文データが格納されているか否かを判断する。注文データを格納しているディレクトリについてはＳ４０５，Ｓ４０６の処理を行い、注文データを格納していないディレクトリについてはＳ４０５、Ｓ４０６の処理は行わない。Ｓ４０５では、キャンセル対象となっている注文データのステータスとして「キャンセル済み」を設定する。Ｓ４０６では、Ｓ４０４において特定されたディレクトリから、キャンセル指示の対象となっている注文データを削除する。
【００８８】
Ｓ４０５、Ｓ４０６の処理により、注文データは削除されるが、ステータス「キャンセル済み」を示す情報が、例えば注文ＩＤと対応付けられてディレクトリに保存される。そのため、例えば当該ディレクトリにアクセス可能な装置が、キャンセルされた注文に対応する注文ＩＤをキャンセルの履歴として確認することができる。なお、ステータス「キャンセル済み」を示す情報が、Ｓ４０３で特定されたディレクトリにおいて設定されてもよい。また、図１では不図示の「キャンセルディレクトリ」を設け、そのキャンセルディレクトリにステータス「キャンセル済み」を示す情報が保存されてもよい。キャンセルディレクトリへアクセス可能な装置については適宜設定されてよい。例えばユーザ端末がキャンセルディレクトリへアクセス可能な装置として設定された場合、ユーザは、編集・注文アプリ１０により、キャンセルした注文の履歴を参照することができる。またステータス「キャンセル済み」を設定する際に、キャンセル前のステータスに応じて異なるステータスが設定されてもよい。これにより例えばユーザ端末がキャンセルの履歴を参照する際に、ユーザ端末は、どの工程においてキャンセルとなったのか確認することができる。
【００８９】
このように、本実施形態では、フォトブックのデータを作成する外部装置から該データを注文データとして受信すると、該注文データをフォトブック単位でディレクトリＡに格納する。そして、ディレクトリＡに格納されている注文データについて決済が完了した旨を、決済処理を行う外部装置から受信すると、該注文データを注文単位でディレクトリＢに格納する。そして、ディレクトリＢに格納されている注文データについて注文の受付が完了した旨を、決済処理を行う外部装置から受信すると、該注文データをフォトブックの製本及び出荷を行う業者単位でディレクトリＣに格納する。そして、ディレクトリＣに格納されている注文データについて出荷が完了した旨を、業者の外部装置から受信すると、該注文データを該業者単位でディレクトリＤに格納する。
【００９０】
次に、管理システム４０、ユーザ端末、ＥＣサイト２０、ラボ（製本装置などの実際の製本処理を行う機器を除くコンピュータ装置）に適用可能なコンピュータ装置のハードウェア構成例について、図１０のブロック図を用いて説明する。
【００９１】
ＣＰＵ２０１は、ＲＯＭ２０２やＲＡＭ２０３に格納されているコンピュータプログラムやデータを用いて処理を実行する。これによりＣＰＵ２０１は、コンピュータ装置全体の動作制御を行うと共に、該コンピュータ装置を適用した図１の各装置が行うものとして上述した各処理を実行する。ＣＰＵ２０１は、例えば、上記の制御部４１に対応する。
【００９２】
ＲＯＭ２０２には、書き換え不要の設定データ（ＢＩＯＳ（Ｂａｓｉｃ  Ｉｎｐｕｔ／Ｏｕｔｐｕｔ  Ｓｙｓｔｅｍ））やブートプログラムなどが格納されている。
【００９３】
ＲＡＭ２０３は、ＲＯＭ２０２や記憶装置２０４や外部メモリ２１３からロードされたコンピュータプログラムやデータ、キーボード２１０により入力された指示入力、を格納するためのエリアを有する。また、ＲＡＭ２０３は、通信Ｉ／Ｆコントローラ２０９を介して外部から受信したコンピュータプログラムやデータを格納するためのエリア、ＣＰＵ２０１が各種の処理を実行する際に用いるワークエリアを有する。このようにＲＡＭ２０３は、各種のエリアを適宜提供することができる。
【００９４】
記憶装置２０４は、ハードディスクドライブ装置に代表される大容量情報記憶装置である。記憶装置２０４には、ＯＳや、コンピュータ装置を適用した図１の各装置が行うものとして上述した各処理をＣＰＵ２０１に実行させるためのコンピュータプログラムやデータが保存されている。本コンピュータ装置を管理システム４０に適用した場合、このコンピュータプログラムには、制御部４１の機能をＣＰＵ２０１に実行させるためのコンピュータプログラムが含まれている。また、本コンピュータ装置をユーザ端末に適用した場合、このコンピュータプログラムには、編集・注文アプリ１０が含まれている。また、本コンピュータ装置をラボ（製本装置などの実際の製本処理を行う機器を除くコンピュータ装置）に適用した場合、このコンピュータプログラムには、ラボ管理アプリ３０が含まれている。また、このデータには、上記の説明において既知の情報として説明したものも含まれている。記憶装置２０４に保存されているものとして説明した各種の情報は、ＣＰＵ２０１による制御に従って適宜ＲＡＭ２０３にロードされ、ＣＰＵ２０１による処理対象となる。
【００９５】
入力コントローラ２０５は、キーボード２１０の動作制御を行う。キーボード２１０は、ユーザが操作することで各種の指示をＣＰＵ２０１に対して入力することができるユーザインターフェースの一例である。
【００９６】
音声入力コントローラ２０６は、マイク２１１の動作制御を行う。マイク２１１は、コンピュータ装置に音声入力を行うためのユーザインターフェースの一例である。なお、スピーカ等の音声出力装置をコンピュータ装置の構成に加えても良い。
【００９７】
ビデオコントローラ２０７は、ディスプレイ２１２の動作制御を行う。ディスプレイ２１２は、ＣＲＴや液晶画面などにより構成されており、ＣＰＵ２０１による処理結果を画像や文字などでもって表示する。なお、ディスプレイ２１２の代わりに若しくは加えて、画像や文字を投影するプロジェクタなどの投影装置を、コンピュータ装置の構成に加えても良い。また、キーボード２１０及びディスプレイ２１２の代わりに、タッチパネルを採用しても構わない。
【００９８】
メモリコントローラ２０８は、外部メモリ２１３に対する情報の読み書きを制御する。外部メモリ２１３は、外付けのメモリ装置であり、例えば、ハードディスクドライブ装置、ＵＳＢメモリである。また、外部メモリ２１３は、フレキシブルディスク（ＦＤ）、ＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）メモリ等である。
【００９９】
なお、図１の各装置が保持するものとして説明した様々な情報は、ＲＡＭ２０３、記憶装置２０４、外部メモリ２１３等に格納されることになる。例えば、これらの記憶装置は、図１のファイルサーバ４２として利用することができる。
【０１００】
通信Ｉ／Ｆコントローラ２０９は、ネットワークＩ／Ｆ２１４が接続されているＬＡＮやインターネットなどのネットワークを介して外部機器とのデータ通信を制御するものであり、例えば、ＴＣＰ／ＩＰを用いた通信等を行うことができる。
【０１０１】
ＣＰＵ２０１、ＲＯＭ２０２、ＲＡＭ２０３、記憶装置２０４、入力コントローラ２０５、音声入力コントローラ２０６、ビデオコントローラ２０７、メモリコントローラ２０８、通信Ｉ／Ｆコントローラ２０９は何れもシステムバス２００に接続されている。
【０１０２】
なお、図１の各装置は、図１０に示した全ての構成を必ず有すること限らず、一部の構成を必要に応じて省略しても良いし、新たな構成を追加しても良い。また、図１の各装置は同じ構成を有していても良いし、異なる構成を有していても良い。
【０１０３】
［第２の実施形態］
第１の実施形態では、フォトブックを作成するシステムについて説明した。しかし、このシステムは、一連の処理で用いられるデータが第１の単位で第１のディレクトリに格納されている状態で、該一連の処理における第１の工程が完了すると、該データを、該第１の工程の次の工程である第２の工程に応じた第２の単位で、該第１のディレクトリとは異なる第２のディレクトリに格納する（格納制御）、という構成の一例であり、このような構成に基づくのであれば、他の実施形態も考えられる。
【０１０４】
例えば、文書決裁システムにおいて、課長、部長、本部長と承認を進めることで決裁処理が完了するシステムが考え得る。文書決裁の申請がなされると、課長がアクセスできるディレクトリに文書が格納され、該文書を課長承認待ちのステータスとして管理する。課長による承認処理が行われると、該文書は部長がアクセスできるディレクトリに格納され、部長による承認待ちのステータスとして管理する。部長による承認処理が行われると、該文書は本部長がアクセスできるディレクトリに格納され、本部長による承認待ちのステータスとして管理する。このように、複数のシステムや人物によりアクセスがなされ、各システムや人物による処理が順次行われていくシステムであれば、どのようなシステムであっても良い。
【０１０５】
（その他の実施例）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【符号の説明】
【０１０６】
４１１：編集・注文アプリ連携部  ４１２：ＥＣサイト連携部  ４１３：ダウンロード連携部
【図１】
2017134543.tif 000003
【図２】
2017134543.tif 000004
【図３】
2017134543.tif 000005
【図４】
2017134543.tif 000006
【図５】
2017134543.tif 000007
【図６】
2017134543.tif 000008
【図７】
2017134543.tif 000009
【図８】
2017134543.tif 000010
【図９】
2017134543.tif 000011
【図１０】
2017134543.tif 000012