JP7415321B2 - 制御装置、及び制御プログラム - Google Patents

Description

本発明の技術は、制御装置、及び制御プログラムに関する。

ソーシャルネットワーキングサービス(Social Networking Service：ＳＮＳ)を用いてサーバに情報を登録し、必要に応じて登録した情報をサーバからダウンロードして、ダウンロードした情報に対して予め定めた特定の処理を実行するサービスが展開されている。

特許文献１には、写真をアップロード可能なＳＮＳの情報に基づいてアルバムを作成する処理を行なう画像処理装置であって、前記ＳＮＳの投稿期間を指定するユーザ操作を受け付けるための第１の指定手段と、前記ＳＮＳへの投稿元の写真の画像データを格納している第１のメモリ装置から、前記投稿期間に前記ＳＮＳに投稿された写真のうちの１枚以上の写真それぞれに対応した画像データを取得するための第１の取得手段と、前記１枚以上の写真の画像データと前記アルバムの作成条件によって指定されるパターンとに基づいて、前記アルバムを印刷するためのデータを生成するための生成手段と、前記アルバムを印刷するためのデータをプリンターに出力するための出力手段とを備える画像処理装置が開示されている。

特許文献２には、記憶手段にアクセス可能なコンピュータを、ＳＮＳに投稿されたメッセージ、当該メッセージを投稿したユーザのユーザ識別情報を少なくとも含む投稿データを取得する取得手段、前記取得手段により取得された投稿データに画像データが含まれている場合、当該画像データに対する処理を識別する処理識別番号を発行し、その処理識別番号と画像データとを対応付けして前記記憶手段に登録する登録手段、前記登録手段により処理識別番号が発行された場合、その処理識別番号を含む処理識別通知メッセージを、当該処理識別番号が当該メッセージを投稿したユーザに少なくとも通知されるよう前記ＳＮＳに投稿する投稿手段として機能させるためのプログラムが開示されている。

特開２０１７－４５１８１号公報 特開２０１６－６２４８２号公報

互いに関連したファイルを対応付けてＳＮＳに投稿する場合、関連したファイルをまとめて１度に投稿すればよいが、ＳＮＳの中には、１度の投稿で１つのファイルしか投稿できないサービスも存在する。したがって、１度の投稿で１つのファイルしか投稿できないサービスにおいて、ユーザがファイルを含む情報を複数投稿した場合、サーバ側ではそれぞれのファイルを関連付けて管理した方がよいのか、それとも個別に管理した方がよいのか判断できないことがある。そのため、サーバは情報が投稿される毎に、投稿された情報をまとめて管理したいのか否かを情報の投稿者に確認して、管理する情報の範囲を確定している。

本発明は、情報を受信する毎に、受信した情報を他の情報とまとめて管理するか情報の投稿者に確認する場合と比較して、情報の投稿に係る投稿者の操作性を低下させることなく、情報を単独で管理するか、それともまとめて管理するか切り換えることができる制御装置、及び制御プログラムを提供することを目的とする。

第１態様に係る制御装置は、チャットに投稿された複数の情報を情報毎に管理する第１のモードと、複数の情報を１つの情報群にまとめて管理する第２のモードを備え、複数の情報を受け付けた場合、複数の情報を前記第１のモードで管理するか、または前記第２のモードで管理するかを切り替える制御を行う制御部を備える。

第２態様に係る制御装置は、第１態様に係る制御装置において、前記制御部が、チャットの形態が個別チャットの場合に投稿された複数の情報に対して、前記第１のモードに切り換える制御を行い、チャットの形態がグループチャットの場合に投稿された複数の情報に対しては、前記第２のモードに切り換える制御を行う。

第３態様に係る制御装置は、第２態様に係る制御装置において、前記制御部が、グループチャットに参加するメンバーによって共通の話題を投稿する投稿場所が作成されている場合、前記投稿場所に投稿された各々の画像を第２のモードによる情報の管理対象とする。

第４態様に係る制御装置は、第３態様に係る制御装置において、前記制御部が、前記投稿場所の閉鎖が行われるまでに前記投稿場所に投稿された各々の画像を、第２のモードによる情報の管理対象とする。

第５態様に係る制御装置は、第１態様に係る制御装置において、前記制御部が、以降の情報の受信に備えて待機しない設定が行われている場合、前記第１のモードに切り換える制御を行い、以降の情報の受信に備えて待機する設定が行われている場合、前記第２のモードに切り換える制御を行う。

第６態様に係る制御装置は、第５態様に係る制御装置において、前記制御部が、第２のモードに切り換える制御を行った場合、最初の情報を受け付けてから予め設定された期間以内に受け付けた各々の情報を前記第２のモードによる情報の管理対象とすると共に、前記予め設定された期間を超えて受け付けた先頭の情報を前記最初の情報に設定し、前記第２のモードによる情報の管理対象を更新する制御を行う。

第７態様に係る制御装置は、第６態様に係る制御装置において、前記制御部が、前記最初の情報を受け付けてからの経過時間が前記予め設定された期間を超えた場合、情報の投稿者に前記予め設定された期間を超えたことを通知する通知情報を前記チャットに投稿すると共に、前記通知情報に対する応答として情報の投稿者から、１つの情報群にまとめて管理したい情報がまだ存在することを知らせる応答情報が投稿された場合、前記予め設定された期間を延長する制御を行う。

第８態様に係る制御装置は、第１態様に係る制御装置において、情報の範囲指定が、範囲を指定する予め定めた区切り情報の投稿によって行われる場合、最初の情報が投稿されてから前記区切り情報が投稿される前までを情報の管理範囲とし、前記制御部は、前記管理範囲に複数の情報が含まれる場合、前記管理範囲に含まれる複数の情報を前記第２のモードによる情報の管理対象とする制御を行う。

第９態様に係る制御装置は、第１態様に係る制御装置において、情報の範囲指定が、範囲を表す予め定めた区切り情報の投稿によって行われる場合、前記区切り情報が投稿された後に投稿された情報から前記区切り情報が再び投稿される前までを情報の管理範囲とし、前記制御部は、前記管理範囲に複数の情報が含まれる場合、前記管理範囲に含まれる複数の情報を前記第２のモードによる情報の管理対象とする制御を行う。

第１０態様に係る制御装置は、第１態様に係る制御装置において、前記制御部が、投稿された情報の容量の合計が予め定めた上限容量を超えた場合、前記上限容量を超えるまでに受信した情報の各々を前記第２のモードによる情報の管理対象とすると共に、投稿された情報のうち、前記第２のモードによる情報の管理対象に含まれなかった残りの情報から前記上限容量との比較を順次行い、前記第２のモードによる情報の管理対象を更新する制御を行う。

第１１態様に係る制御装置は、第１０態様に係る制御装置において、前記制御部が、１つの情報の容量が前記上限容量を超える場合、前記１つの情報を前記第１のモードによる情報の管理対象とする制御を行う。

第１２態様に係る制御装置は、第１態様に係る制御装置において、前記制御部が、情報の投稿数が予め定めた規定数に達した場合で、かつ、前記規定数が２以上に設定されている場合、前記規定数の情報の各々を前記第２のモードによる情報の管理対象とすると共に、情報の管理対象確定後から情報の投稿数を計測し直して前記規定数との比較を順次行い、前記第２のモードによる情報の管理対象を更新する制御を行う。

第１３態様に係る制御装置は、第１２態様に係る制御装置において、前記制御部が、前記規定数が１に設定されている場合、投稿された情報の各々を前記第１のモードによる情報の管理対象とする制御を行う。

第１４態様に係る制御装置は、第１態様に係る制御装置において、前記制御部が、投稿された情報が文書ファイルである場合、前記文書ファイルを前記第１のモードによる情報の管理対象とし、投稿された情報が画像ファイルである場合、前記画像ファイルを前記第２のモードによる情報の管理対象とする制御を行う。

第１５態様に係る制御装置は、第１態様に係る制御装置において、前記制御部が、情報の内容が形成される記録媒体の種別に応じて、複数の情報を前記第１のモードで管理するか、または前記第２のモードで管理するかを切り替える制御を行う。

第１６態様に係る制御装置は、第１５態様に係る制御装置において、前記制御部が、前記記録媒体として写真用紙が指定されている場合、投稿された各々の情報を前記第２のモードによる情報の管理対象とすると共に、前記記録媒体として写真用紙以外の用紙が指定されている場合には、投稿された各々の情報を前記第１のモードによる情報の管理対象とする制御を行う。

第１７態様に係る制御装置は、第１態様～第１６態様の何れかの態様に係る制御装置において、前記制御部が、情報の投稿者の指示に従って、第２のモードの実行によってまとめて管理される情報群に、新たに投稿された情報を追加する制御を行う。

第１８態様に係る制御装置は、第１態様～第１７態様の何れかの態様に係る制御装置において、前記制御部が、情報の投稿者の指示によって第１のモードに切り換えた場合と、前記第２のモードに切り換えた場合とで、情報の投稿者が操作する情報機器に表示される、投稿する情報を選択する選択画面の動作が異なるように前記情報機器を制御する。

第１９態様に係る制御プログラムは、コンピュータを、第１態様～第１８態様の何れかの態様に係る制御装置の制御部として機能させるためのプログラムである。

第１態様、及び第１９態様によれば、情報を受信する毎に、受信した情報を他の情報とまとめて管理するか情報の投稿者に確認する場合と比較して、情報の投稿に係る投稿者の操作性を低下させることなく、情報を単独で管理するか、それともまとめて管理するか切り換えることができる、という効果を有する。

第２態様によれば、チャットに参加する人数に応じて、情報を単独で管理するか、それともまとめて管理するか切り換えることができる、という効果を有する。

第３態様によれば、ユーザが情報の管理モードを明示的に指示しない場合であっても、共通の話題に関連した情報をまとめて管理することができる、という効果を有する。

第４態様によれば、ユーザが情報の取りまとめを行う開始時期を明示的に指示しない場合であっても、共通の話題に関連した情報の集約範囲を決定した上で、情報をまとめて管理することができる、という効果を有する。

第５態様によれば、後続の情報を待機する場合、先に投稿された情報を後続の情報とまとめて管理することができる、という効果を有する。

第６態様によれば、最初に受信した情報からの時間間隔に応じて、まとめて管理する情報の範囲を設定することができる、という効果を有する。

第７態様によれば、情報をまとめて管理する期間を経過した後であっても、ユーザはまとめて管理したい情報を追加することができる、という効果を有する。

第８態様によれば、まとめて管理する情報の開始位置にも区切り情報を必要とする場合と比較して、情報の範囲指定に要する操作数を少なくすることができる、という効果を有する。

第９態様によれば、まとめて管理する情報の終了位置だけに区切り情報を必要とする場合と比較して、チャットの表示画面を見た場合に、まとめて管理される情報の範囲が分かりやすく表示される、という効果を有する。

第１０態様によれば、複数の情報が投稿された場合であっても、情報の投稿順に従って、管理単位毎の情報の容量が上限容量にできるだけ近づくように情報をまとめて管理することができる、という効果を有する。

第１１態様によれば、１つの情報が複数の管理単位に分散して管理されないようにすることができる、という効果を有する。

第１２態様によれば、複数の情報が投稿された場合であっても、情報の投稿順に従って、管理単位毎の情報の数が同じになるように情報をまとめて管理することができる、という効果を有する。

第１３態様によれば、設定する規定数によって、情報を単独で管理するか、それともまとめて管理するか切り換えることができる、という効果を有する。

第１４態様によれば、情報の内容を参照することなく、情報を単独で管理するか、それともまとめて管理するか切り換えることができる、という効果を有する。

第１５態様によれば、情報の投稿者が情報の管理モードを指示することなく、情報の管理モードを切り換えることができる、という効果を有する。

第１６態様によれば、画像をまとめて記録媒体に形成することができる、という効果を有する。

第１７態様によれば、情報がまとめて管理された後であっても、ユーザはまとめて管理したい情報を追加することができる、という効果を有する。

第１８態様によれば、チャットに情報を投稿する場合に、第１のモードと第２のモードで同じ動作を伴う情報の選択画面を用いる場合と比較して、選択画面の操作が行いやすくなる、という効果を有する。

制御システムの概略構成例を示す図である。 トークルームサーバのハードウェア構成例を示すブロック図である。 制御装置のハードウェア構成例を示すブロック図である。 トークルームサーバの機能構成例を示すブロック図である。 制御装置の機能構成例を示すブロック図である。 トークルームでの画像の投稿例を示す図である。 画像の管理モードの設定処理の一例を示すフローチャートである。 画像の管理処理の一例を示すフローチャートである。 画像の管理モードがモード１に設定されている場合におけるトークルームの表示例を示す図である。 画像の管理モードがモード２に設定されている場合におけるトークルームの表示例を示す図である。 画像の管理モードがモード１に設定された場合の画像の選択画面の一例を示す図である。 画像の管理モードがモード２に設定された場合の画像の選択画面の一例を示す図である。 画像の印刷処理の一例を示すフローチャートである。 最初の画像を受け付けてからの投稿間隔に従って画像の集約範囲を決定する画像の管理処理の一例を示すフローチャートである。 最初の画像の投稿から予め定めた時間を越えた場合に、チャットボットが追加したい画像があるか問い合わせを行うトークルームの一例を示す図である。 区切り情報を用いる画像の管理処理の一例を示すフローチャートである。 区切り情報を用いて画像の管理処理が実行された場合のトークルームの一例を示す図である。 １つにまとめたい画像を区切り情報で囲んだトークルームの一例を示す図である。 画像の投稿数を用いる画像の管理処理の一例を示すフローチャートである。 画像の投稿数を用いて画像の管理処理が実行された場合のトークルームの一例を示す図である。 画像の容量を用いる画像の管理処理の一例を示すフローチャートである。 画像の容量を用いて画像の管理処理が実行された場合のトークルームの一例を示す図である。 チャットの形態を用いる画像の管理処理の一例を示すフローチャートである。 投稿された情報と対応付けられた属性と属性条件を用いた画像の分類処理の一例を示すフローチャートである。 情報の作成日による情報の分類例を示す図である。

以下、本発明の技術の実施形態の一例を、図面を参照しながら説明する。なお、各図面において同一又は等価な構成要素及び処理には同一の参照符号を付与し、重複する説明を省略する。また、図面の寸法比率は、説明の都合上誇張されており、実際の比率とは異なる場合がある。

＜第１実施形態＞
図１は、本発明の実施形態に係る制御システムの概略構成例を示す図である。

制御システムは、ユーザ端末１０、トークルームサーバ２０、制御装置３０、及び情報処理装置４０を含む。ユーザ端末１０、トークルームサーバ２０、制御装置３０、及び情報処理装置４０は通信回線５０により相互に接続されている。制御装置３０は、後述するようにトークルームで行われるチャットでのチャットボットサーバとして動作する。

ユーザ端末１０は、ユーザが使用する端末であって、デスクトップ型コンピュータ、ノートパソコン、タブレット、又はスマートフォン等のいかなる端末であってもよい。図１においては、ユーザＡがユーザ端末１０Ａを、ユーザＢがユーザ端末１０Ｂを使用しているものとする。以降では、ユーザ端末１０Ａ、１０Ｂを総称して「ユーザ端末１０」と呼ぶ。説明の便宜上、図１にはユーザＡ及びユーザＢの２名しか記載していないが、制御システムに参加するユーザは１名であっても３名以上であってもよく、この場合、ユーザの人数に応じた数のユーザ端末１０が通信回線５０に接続される。

トークルームサーバ２０は、トークルームを提供する。トークルームは、少なくとも１人のユーザと後述するチャットボットが参加して、チャットにより投稿したファイルによって表される情報を共有する仮想空間であり、情報の投稿場所として用いられる。

ここで、「ファイル」とは、何らかの情報を表すデータの単位であり、「チャット」とは、コンピュータネットワーク上でリアルタイムに複数の構成員が情報を入力してやりとりを交わすこと、又はそれをするための環境を指す。「構成員」とは、実在する人物と関連付けられたユーザと、特定の規則に従って動作するソフトウェアロボットの両方を含む。また、「チャットボット」とは、トークルーム上でユーザから投稿された情報に基づいて特定処理の実行がなされるように制御するソフトウェアロボットである。

ユーザは、ユーザ端末１０を通じて、トークルームにファイルを投稿する。ここで「ファイルを投稿する」とは、チャットにおいて情報を入力する行為をいう。ファイルを投稿したユーザは「投稿者」とも呼ばれる。

ファイルによって表される情報には、例えば画像や文字が含まれる。画像は静止画であっても動画であってもよい。また、ファイルは音声ファイルであってもよい。換言すれば「ファイルを投稿する」とは、画像、音声、及び文字によって表される各種指示や情報をチャットに入力する行為ということになる。

トークルーム内では、ユーザ同士でファイルによって表される情報を共有し、更に、チャットボットがユーザの情報に応答する。また、ユーザがトークルーム内において、チャットボットに対して、情報処理装置４０に予め定めた特定処理を実行させるための指示を与えることも可能である。チャットボットは、例えば、自然言語処理により、投稿されたファイルによって表される情報に含まれる指示を抽出する他、投稿されたファイルによって表される情報の種類が画像である場合には、投稿された画像を管理して、情報処理装置４０に特定処理を実行させるように制御する。なお、トークルームには、ユーザとチャットボットが１対１で参加したり、複数のユーザとチャットボット、または複数のユーザが参加したりすることが可能である。

２人のユーザがトークルームに参加して行うチャットは「個別チャット」と呼ばれ、３人以上のユーザがトークルームに参加して行うチャットは「グループチャット」と呼ばれる。なお、チャットに参加するユーザの１人は、チャットボットであってもよい。以降では、個別チャット及びグループチャットにチャットボットが参加しているものとして説明を行う。なお、トークルームは開設された数だけ複数存在しうる。

制御装置３０は、チャットボットを制御すると共に、ユーザ端末１０からトークルームに投稿されたファイルを管理する。また、制御装置３０は、情報処理装置４０からユーザの要求を受け付けた場合、管理するファイルに対して特定処理が実行されるように、情報処理装置４０と連携して特定処理を実行する制御を行う。チャットボットは上述したように、トークルームに参加して、投稿者が投稿したファイルによって表される情報に応答する。

投稿者が投稿するファイルによって表される情報の種類に制約はないが、ここでは一例として画像を投稿する例について説明する。画像は本実施の形態における「情報」の一例である。

制御装置３０はチャットを通じて投稿された画像を取得し、取得した画像を記憶装置に記憶して管理する。「画像を管理する」とは、ユーザが指定した画像に対して、例えば画像の取得、削除、及びコピー等、ユーザが指定した処理が実行されるように画像の取り扱いを制御することをいう。以降では、制御装置３０が画像を記憶装置に記憶することを「画像を登録する」ということがある。

制御装置３０は、チャットに投稿された複数の画像を画像毎に管理する第１のモードと、複数の画像を１つの画像群にまとめて管理する第２のモードを備える。

ユーザは、画像毎に画像を管理したい場合には、第１のモードで画像を登録するように制御装置３０に指示する。

これに対して、互いに関連する画像は、例えば関連する画像をひとまとめにして管理すれば１度の指定で関連する画像の各々が取得されるようになるため、個別に管理された画像をそれぞれ指定して関連する画像の各々を取得するよりも、ユーザの操作性が向上することになる。したがって、ユーザは、制御装置３０に関連する画像をまとめて管理してもらいたい場合には、第２のモードで画像を管理するように制御装置３０に指示する。すなわち、第１のモードの場合には１つの画像が管理単位となり、第２のモードの場合には複数の画像が管理単位となる。以降では第１のモードを「モード１」、第２のモードを「モード２」と表すことにする。

なお、後述するように、ユーザが画像の管理モードを指示しない場合であっても、制御装置３０はユーザが予め設定した画像の集約に関する基準に従って、画像を単独で管理するか、それともまとめて管理するか切り換えることがある。「画像の集約に関する基準」とは、画像をどのような観点に基づいてモード１で管理するのか、それともモード２で管理するのか判断する判断基準を規定した基準であり、以降では「集約基準」と呼ぶ。制御装置３０は複数の集約基準に対応しており、制御装置３０が用いる集約基準は、例えばユーザがトークルームを通じて指示することで変更される。

また、制御装置３０は、画像の管理単位毎に、管理された画像または画像群を一意に識別する識別情報を対応付け、画像または画像群に対応付けた識別情報を、画像の登録を受け付けた応答としてチャットに参加しているユーザに宛てて投稿する。

チャットを通じて識別情報を受け取ったユーザ、または当該ユーザから、例えば別のトークルームのチャットを通じて識別情報を受け取った他のユーザは、後述する情報処理装置４０に識別情報を入力することで、入力した識別情報と対応付けられた画像に対して特定処理の開始を指示する。

情報処理装置４０は、ユーザの指示に従って制御装置３０と連携して情報処理を行なう装置である。「情報処理」とは、例えば、文字データ又は画像データ等の印刷及び表示を実行する処理、情報処理装置４０が備える設備を用いてデータを生成又は加工等する処理、及び情報処理装置４０と他の機器との間でデータを授受する処理等を含む。

以下では、情報処理装置４０が画像形成装置であり、情報処理装置４０で実行される特定処理が、制御装置３０で管理される画像を用紙等の記録媒体に形成させる処理である例について説明を行うが、必ずしも特定処理が画像の形成に限られるわけではない。例えば特定処理は、制御装置３０で管理される画像のファイルを、ユーザによって指定された装置に配信する処理であってもよい。

制御装置３０で管理される画像のように何からの情報を記録媒体に形成し、視覚または触覚を通じてユーザに情報の内容を把握させる処理のことを「印刷」という。画像形成装置は情報処理装置４０の一例であることから、画像形成装置に対しても符号４０を付して説明を行うことにする。

図１の制御システムの例では、画像形成装置４０Ａ及び画像形成装置４０Ｂが、通信回線５０に接続されている。特に断りがなければ、画像形成装置４０Ａ及び画像形成装置４０Ｂを総称して「画像形成装置４０」と呼ぶ。図１の例では、画像形成装置４０は通信回線５０を通じて制御装置３０と接続されているが、通信回線５０と異なる図示しない通信回線を通じて、制御装置３０と接続されてもよい。また、３台以上の画像形成装置４０が通信回線５０と接続されてもよい。画像形成装置４０の設置場所に制約はないが、一例として画像形成装置４０は誰でも訪れることができる場所、例えばコンビニエンスストアのような店舗に設置される。

ユーザが何れかの画像形成装置４０に識別情報を入力することで、識別情報と対応付けられた画像が記録媒体に印刷される。

次に、トークルームサーバ２０及び制御装置３０のハードウェア構成について説明する。

図２は、トークルームサーバ２０のハードウェア構成例を示すブロック図である。

図２に示すように、トークルームサーバ２０は、ＣＰＵ(Central Processing Unit)２１、ＲＯＭ(Read Only Memory)２２、ＲＡＭ(Random Access Memory)２３、ストレージ２４、入力部２５、表示部２６、及び通信Ｉ／Ｆ(Interface)２７の各構成を有する。各構成は、バス２９を介して相互に通信可能に接続されている。

ＣＰＵ２１は、中央演算処理ユニットであり、各種プログラムを実行したり、各部を制御したりする制御部として機能する。すなわち、ＣＰＵ２１は、ＲＯＭ２２又はストレージ２４からプログラムを読み出し、ＲＡＭ２３を作業領域としてプログラムを実行する。ＣＰＵ２１は、ＲＯＭ２２又はストレージ２４に記録されているプログラムに従って、上記各構成の制御及び各種の演算処理を行う。本実施形態では、ＲＯＭ２２にトークルームを提供するトークルーム提供プログラムが格納されているものとする。

ＲＯＭ２２は、各種プログラム及び各種データを格納する。ＲＡＭ２３は、作業領域として一時的にプログラム又はデータを記憶する。ストレージ２４は、ＨＤＤ(Hard Disk Drive)又はＳＳＤ(Solid State Drive)により構成され、オペレーティングシステムを含む各種プログラム、及び各種データを格納する。

入力部２５は、マウス等のポインティングデバイス、及びキーボードを含み、各種の入力を行うために使用される。

表示部２６は、例えば液晶ディスプレイまたは有機ＥＬ(Electro Luminescence)ディスプレイ等のように各種情報を表示する表示装置を含み、ＣＰＵ２１によって処理された情報を表示する。表示部２６は、タッチパネル方式を採用して、入力部２５として機能してもよい。

通信Ｉ／Ｆ２７は、通信回線５０を介して、他の機器と通信するためのインタフェースであり、例えばイーサネット（登録商標）、ＦＤＤＩ、Ｗｉ－Ｆｉ（登録商標）、及びブルートゥース（登録商標）等の規格が用いられる。

図３は、制御装置３０のハードウェア構成例を示すブロック図である。

図３に示すように、制御装置３０は、ＣＰＵ３１、ＲＯＭ３２、ＲＡＭ３３、ストレージ３４、入力部３５、表示部３６、及び通信Ｉ／Ｆ３７の各構成を有する。各構成は、バス３９を介して相互に通信可能に接続されている。制御装置３０の各構成は、図２のトークルームサーバ２０の各構成と同様の機能を有する。

次に、トークルームサーバ２０及び制御装置３０の機能構成について説明する。

図４は、トークルームサーバ２０の機能構成例を示すブロック図である。

図４に示すように、トークルームサーバ２０は、機能構成として、提供部２０１を有する。機能構成は、ＣＰＵ２１がＲＯＭ２２に記憶されたトークルーム提供プログラムを読み出して、ＲＡＭ２３に展開して実行することにより実現される。

提供部２０１は、ユーザが参加し、ファイルを投稿可能なトークルームを提供する。トークルームサーバ２０は、提供部２０１の機能を用いて、個別チャットが行われるトークルーム、及び、グループチャットが行われるトークルームを提供する。

トークルームは、ユーザからの開設要求に従い、複数開設されうる。また、例えばあるユーザがトークルームサーバ２０にアクセスしてトークルームに開設要求を行い、特定のトークルームを開設した場合、開設者であるユーザは、開設したトークルームに他のユーザを招待し、参加させる事ができる。或いは、トークルームに参加中のユーザであれば、トークルームに参加していない他のユーザをトークルームへ招待して、新たに参加させる事もできる。

図５は、制御装置３０の機能構成例を示すブロック図である。図５に示すように、制御装置３０は、受信部３０１、制御部３０２、統合部３０３、生成部３０４、印刷処理部３０５、及び送信部３０６の各機能部を含む。各機能部は、ＣＰＵ３１がＲＯＭ３２に記憶された制御プログラムを読み出して、ＲＡＭ３３に展開して実行することにより実現される。

受信部３０１は、通信Ｉ／Ｆ３７を通じて通信回線５０と接続されるユーザ端末１０、トークルームサーバ２０、及び画像形成装置４０から各種情報を受信する。受信部３０１が受信する情報には、例えばユーザ端末１０からトークルームサーバ２０を中継して送信される画像、及び画像形成装置４０から送信される識別情報等が含まれる。

制御部３０２は、トークルームサーバ２０から複数の画像を受け付けた場合、複数の画像をモード１で管理するか、またはモード２で管理するかを、画像の集約基準に従って切り替える。また、制御部３０２は、制御プログラムで規定される内容に従って受信部３０１、並びに、後述する統合部３０３、生成部３０４、印刷処理部３０５、及び送信部３０６を制御して、制御装置３０の動作を制御する。

統合部３０３は、制御部３０２によって画像の管理モードがモード２に切り換えられた場合に、モード２による管理対象となった複数の画像を１つの画像群に統合する。

生成部３０４は、画像の管理単位毎に一意に対応付けられる識別情報を生成する。モード１によって管理される画像の管理単位は各々の画像となり、モード２によって管理される画像の管理単位は複数の画像をまとめた画像群となる。

印刷処理部３０５は、生成部３０４で生成した識別情報を受信部３０１で受信した場合、特定処理の一例である識別情報と対応付けられた画像または画像群の印刷処理が、識別情報の送信元である画像形成装置４０で行われるように処理する。

送信部３０６は、識別情報を含む各種情報を、画像を投稿した投稿者が使用するユーザ端末１０に送信すると共に、受信した識別情報と対応付けられた画像または画像群を画像形成装置４０に送信する。

図６は、トークルームでの画像の投稿例を示す図であり、投稿者が情報Ｍ１０、Ｍ２０、及びＭ３０でそれぞれ画像を投稿し、チャットボットがそれぞれの画像を受け付けた状況を表している。

制御装置３０は複数の画像が投稿された場合、画像の集約基準に従って複数の画像をモード１で管理するか、またはモード２で管理するかを切り替える制御を行う。その上で制御装置３０は、画像の管理モードに従った画像の管理単位毎に識別情報を生成し、チャットボットを通じて画像の投稿者に識別情報を投稿する。図６の例では、情報Ｍ１０、Ｍ２０、及びＭ３０に含まれる各々の画像が１つの画像群にまとめられて管理されたため、チャットボットが識別情報を１つだけ投稿している状況を表している。

次に、本実施の形態に係る制御装置３０の動作について詳細に説明する。

図７は、トークルームを通じて画像の投稿者から画像の管理モードを指定するモード指定を受け付けた場合に、ＣＰＵ３１によって実行される画像の管理モードの設定処理の一例を示すフローチャートである。

図７に示す画像の管理モードの設定処理を規定する制御プログラムは、例えば制御装置３０のＲＯＭ３２に予め記憶されている。制御装置３０のＣＰＵ３１は、ＲＯＭ３２に記憶される制御プログラムを読み込み、画像の管理モードの設定処理を実行する。

ステップＳ１０において、ＣＰＵ３１は、受信したモード指定が画像の管理モードとしてモード１を指定したものであるか否かを判定する。モード１が指定されている場合にはステップＳ２０に移行し、ステップＳ２０において、ＣＰＵ３１は、画像の管理モードをモード１に設定する。

一方、受信したモード指定が画像の管理モードとしてモード１を指定したものではない場合、すなわち、モード２が指定されている場合にはステップＳ３０に移行し、ステップＳ３０において、ＣＰＵ３１は、画像の管理モードをモード２に設定する。

ステップＳ２０またはステップＳ３０を実行した後、ステップＳ４０において、ＣＰＵ３１は設定した管理モードを、チャットボットを通じてトークルームに投稿し、制御装置３０に設定された画像の管理モードをモード指定の投稿を行った投稿者に通知する。以上により図７に示した画像の管理モードの設定処理を終了する。

このように、制御装置３０は、ユーザから画像の管理モードの指定を受け付ける。

画像の管理モードがモード２に設定された場合、制御装置３０は、トークルームに投稿された複数の画像をまとめて管理することになるが、どの画像をまとめて１つの画像群とするのかといった画像の集約範囲は、画像の集約基準によって変化する。制御装置３０は複数の画像の集約基準に対応しており、モード指定のようにユーザが適用する画像の集約基準をトークルームに投稿することで、制御装置３０で用いられる画像の集約基準が設定される。以降では、様々な集約基準に従った画像の集約方法について説明する。

図８は、画像の投稿時間によって画像の集約範囲を規定した集約基準に従って実行される画像の管理処理の一例を示すフローチャートである。具体的には、画像の投稿間隔に基づいて画像の集約範囲を決定する集約基準に従った画像の管理処理を示している。

図８に示す画像の管理処理は、図７に示した画像の管理モードの設定処理が行われた後に実行される。図８に示す画像の管理処理を規定する制御プログラムは、例えば制御装置３０のＲＯＭ３２に予め記憶されている。制御装置３０のＣＰＵ３１は、ＲＯＭ３２に記憶される制御プログラムを読み込み、図８に示す画像の管理処理を実行する。

ステップＳ１００において、ＣＰＵ３１は、画像の投稿間隔を計測するタイマＴＡを起動する。タイマＴＡは、例えばＣＰＵ３１に内蔵されるタイマ機能が用いられるが、ＣＰＵ３１は、通信Ｉ／Ｆ３７を介して通信回線５０に接続される図示しない外部装置に備えられたタイマ機能を利用してもよい。タイマＴＡを起動することで、タイマＴＡを起動した時点からの経過時間が計測される。

ステップＳ１１０において、ＣＰＵ３１は、トークルームを通じて画像を受信したか否かを判定する。画像を受信していない場合にはステップＳ１６０に移行する。

ステップＳ１６０において、ＣＰＵ３１は、タイマＴＡの値が時間Ｔ１以下であるか否かを判定する。時間Ｔ１は、画像の投稿間隔の上限時間を表す値であり、例えば予めストレージ３４に記憶されている。時間Ｔ１は、例えばユーザが時間Ｔ１の値を指定する投稿をトークルームに行うことで変更可能である。

画像の投稿間隔の上限時間は、次の画像の受信に備えて待機する上限時間であり、画像の管理モードがモード２の場合、ＣＰＵ３１は次の画像が投稿されるまでの投稿間隔が時間Ｔ１を超えた場合、投稿者による画像の投稿に一区切りついたと判定する。したがって、タイマＴＡの値が時間Ｔ１以下の場合にはステップＳ１１０に移行する。ＣＰＵ３１は、タイマＴＡの値が時間Ｔ１を越えるまでステップＳ１１０及びＳ１６０を繰り返し実行することで、ユーザからの画像の投稿を監視する。

ステップＳ１１０の判定処理で画像が受信されたと判定された場合には、ステップＳ１２０に移行する。

ステップＳ１２０において、ＣＰＵ３１は、画像の管理モードがモード１に設定されているか否かを判定する。画像の管理モードがモード１に設定されている場合には、ステップＳ１３０に移行する。

画像の管理モードがモード１の場合、受信した画像を個々に管理することから、ステップＳ１３０において、ＣＰＵ３１は、以降にトークルームに投稿される画像を待機することなく、受信した画像を単独で管理する。すなわち、ＣＰＵ３１は、各々の画像に対応付けられた識別情報を生成する。管理対象となる画像の記憶先に制限はなく、例えば通信Ｉ／Ｆ３７を通じて制御装置３０と異なる外部装置に記憶してもよいが、以降では一例としてストレージ３４に記憶するものとする。

一方、ステップＳ１２０の判定処理で画像の管理モードがモード１に設定されていないと判定された場合には、ステップＳ１４０に移行する。

この場合、画像の管理モードはモード２に設定されているため、受信した画像を以降に受信する画像とまとめて画像群を形成する。したがって、ステップＳ１４０において、ＣＰＵ３１は、受信した画像の各々を関連付けてＲＡＭ３３に記憶する。なお、最初に受信した画像の場合にはまだ関連付ける画像が存在しないため、そのままＲＡＭ３３に記憶する。

ステップＳ１３０またはステップＳ１４０を実行した後、ステップＳ１５０において、ＣＰＵ３１は、タイマＴＡを再起動する。これにより、制御装置３０で画像を受信する毎にタイマＴＡの値が“０”に戻され、画像を受信してからの経過時間を再び計測し始めた上でステップＳ１１０に移行し、次の画像の投稿を監視することになる。

すなわち、モード１の場合、トークルームに複数の画像が投稿されたとしても、個々の画像を画像の管理単位とし、モード２の場合、画像が投稿された後、時間Ｔ１が経過するまでは次の画像の投稿を待機して、時間Ｔ１以内に投稿された画像は、既に投稿された画像と関連付けてＲＡＭ３３に記憶する。

一方、ステップＳ１６０の判定処理で画像の投稿間隔が時間Ｔ１を越えたと判定された場合、投稿者による画像の投稿が一区切りついたと考えられるため、ステップＳ１７０に移行する。

ステップＳ１７０において、ＣＰＵ３１は、画像の管理モードがモード１に設定されているか否かを判定する。画像の管理モードがモード１に設定されている場合には、既にステップＳ１３０で画像を受信する度に画像の管理が行われるため、図８に示す画像の管理処理を終了する。

画像の管理モードがモード２に設定されている場合には、ステップＳ１８０に移行する。

ステップＳ１８０において、ＣＰＵ３１は、モード２において少なくとも１つの画像を受信したか否かを判定する。ステップＳ１８０は、画像が投稿されるのを待機していても、投稿者がいつまで経っても画像を１度も投稿しないことによってタイマＴＡが時間Ｔ１を越えてしまうことに対応した判定処理である。少なくとも１つの画像を受信している場合にはステップＳ１９０に移行し、ステップＳ１９０において、ＣＰＵ３１は、ステップＳ１４０で関連付けて記憶した画像群を１つの管理単位として確定し管理する。すなわち、ＣＰＵ３１は、まとめて管理される画像群に識別情報を生成して図８に示す画像の管理処理を終了する。

一方、ステップＳ１８０の判定処理で画像を１度も受信していないと判定された場合には管理する画像が存在しないため、ステップＳ１９０の処理を実行することなく図８に示す画像の管理処理を終了する。

図８に示した画像の管理処理では、画像の管理モードがモード２の場合、画像の投稿間隔が時間Ｔ１以内であれば複数の画像をまとめて管理することになるが、制御装置３０は、まとめて管理する画像の数に上限値を設定してもよい。まとめて管理する画像の数が上限値を超えた場合には、上限値で表される数の画像を１つの画像群として管理し、上限値を超えてしまった画像から、新たにまとめて管理する管理対象とすればよい。

なお、画像の管理モードがモード２に設定されている場合であっても、画像が１つしか投稿されずにタイマＴＡが時間Ｔ１を越えた場合には、単独の画像に対して識別情報が対応付けられるため、結果としてモード１での管理が行われることになる。

図９は、図８に示した画像の管理処理において、画像の管理モードがモード１に設定されている場合のユーザ端末１０におけるトークルームの表示例を示す図である。この場合、画像が投稿される毎にチャットボット、すなわち、制御装置３０が画像を登録し、各々の画像に対して識別情報を対応付けて管理することを通知する情報Ｍ１１、Ｍ２１、及びＭ３１をトークルームに投稿する。

一方、図１０は、図８に示した画像の管理処理において、画像の管理モードがモード２に設定されている場合のユーザ端末１０におけるトークルームの表示例を示す図である。この場合、直前に投稿された画像との投稿間隔が時間Ｔ１以内となる画像がまとめて管理される。したがって、情報Ｍ１０、Ｍ２０、及びＭ３０の各々の投稿間隔が時間Ｔ１以内であれば、図１０に示すように、チャットボットは情報Ｍ１０、Ｍ２０、及びＭ３０に含まれる各々の画像をまとめて登録したことを通知する情報Ｍ３２をトークルームに投稿する。

図７に示したように、制御装置３０では画像の管理モードをユーザが予め明示的に指示したモードに設定したが、画像の投稿と共に所望する画像の待機期間の長さを指定するようにしてもよい。例えば制御装置３０は、受信した画像に例えば「以降の画像の受信に備えて待機しない」との指定が行われている場合にはモード１に切り換え、「以降の画像の受信に備えて待機する」との指定が行われている場合にはモード２に切り換えてもよい。ユーザは、以降の画像の受信に備えて待機する場合には待機期間の長さを指定してもよく、待機期間の長さが指定されていない場合には、制御装置３０で予め用意している標準の時間Ｔ１を用いる。

ユーザが画像の管理モードをモード１に設定した場合と、第２モードに設定した場合とでは、ユーザ端末１０において、ユーザがトークルームに画像を投稿する際の画像の選択画面の動作が異なるようにする。

図１１は、画像の管理モードがモード１に設定された場合の画像の選択画面の一例を示す図である。画像の管理モードがモード１に設定された場合には、ユーザが画像を複数選択しても最後に選択された画像だけがトークルームに投稿される画像として選択される。選択済みの画像を再度選択すれば、選択状態が解除される。図１１の例では、最後に選択された領域１４に表示された画像だけが選択状態となっていることを表しており、ユーザが送信ボタン１２を押下することで、選択状態の画像がトークルームに投稿される。

なお、画像の選択画面において選択状態の画像と選択状態にない画像とが判別されるように、例えば選択状態の画像の縁の太さや色を選択状態にない画像の縁の太さや色と変えて表示してもよい。また、選択状態の画像にはチェックマークを表示してもよい。

一方、図１２は、画像の管理モードがモード２に設定された場合の画像の選択画面の一例を示す図である。画像の管理モードがモード２に設定された場合には、複数の画像がトークルームに投稿される画像として選択される。図１２の例では、領域１４Ａ、１４Ｂ、及び１４Ｃに表示された各々の画像が選択状態となっていることを表しており、ユーザが送信ボタン１２を押下することで、選択状態の各々の画像がトークルームに投稿される。

送信ボタン１２に、例えば選択状態にある画像の数を表示して、ユーザに画像の選択数を通知するようにしてもよいし、画像をまとめて管理する数に上限値が設けられている場合には、送信ボタン１２に例えば「（３／１０）」のように上限値を表示してもよい。この例では分子が選択状態の画像数を表し、分母がまとめて管理される画像の上限値を表している。

画像が上限値を超えて選択された場合には、画像の選択画面に警告メッセージを表示するようにしてもよく、また、画像の選択数が上限値に達した場合に、これ以上画像が選択できないことを通知する表示を画像の選択画面に表示してもよい。

ユーザ端末１０に表示される画面は制御装置３０によって生成され、ユーザ端末１０では、制御装置３０で生成された画面をダウンロードして表示する。制御装置３０ではユーザによる画面操作の内容を受信して、操作に応じた画面の切り替えや表示の変更を行う。しかしながら、ユーザ端末１０は、制御装置３０またはトークルームサーバ２０からダウンロードしたアプリケーションを起動して画面を表示し、ユーザの操作内容、及び画像の管理モードに応じた制御装置３０からの指示に従って、ユーザ端末１０が画面や操作処理の変更を行うようにしてもよい。

これまでは制御装置３０がトークルームで画像を受け付けた場合について説明したが、ここでは画像形成装置４０から識別情報を受け付けた場合における制御装置３０の動作について説明する。

図１３は、画像形成装置４０から識別情報を受け付けた場合に、ＣＰＵ３１によって実行される画像の印刷処理の一例を示すフローチャートである。図１３に示す画像の印刷処理を規定する制御プログラムは、例えば制御装置３０のＲＯＭ３２に予め記憶されている。制御装置３０のＣＰＵ３１は、ＲＯＭ３２に記憶される制御プログラムを読み込み、図１３に示す画像の印刷処理を実行する。

ステップＳ２００において、ＣＰＵ３１は、受け付けた識別情報と対応付けられて管理されている画像または画像群をストレージ３４から取得する。識別情報と対応付けられている画像が画像群である場合には、複数の画像が取得される。

ステップＳ２１０において、ＣＰＵ３１は、ステップＳ２００で取得した画像または画像群を、識別情報を送信してきた画像形成装置４０に送信して、図１３に示す画像の印刷処理を終了する。これにより、画像または画像群を受信した画像形成装置４０では、受信した画像または画像群を記録媒体に印刷する印刷処理が開始される。

画像の投稿時間によって画像の集約範囲を規定する集約基準の例として、図８のように直前に投稿された画像からの投稿間隔を用いる他に、一緒に管理される画像がまだ投稿されていないような初期状態から受け付けた画像、すなわち、最初の画像を受け付けてからの投稿時間を用いるようにしてもよい。

図１４は、最初の画像を受け付けてからの投稿時間に従って画像の集約範囲を決定する画像の管理処理の一例を示すフローチャートである。

図１４に示す画像の管理処理は、図７に示した画像の管理モードの設定処理が行われた後に実行される。図１４に示す画像の管理処理を規定する制御プログラムは、例えば制御装置３０のＲＯＭ３２に予め記憶されている。制御装置３０のＣＰＵ３１は、ＲＯＭ３２に記憶される制御プログラムを読み込み、図１４に示す画像の管理処理を実行する。

図１４に示す画像の管理処理が図８に示した画像の管理処理と異なる点は、ステップＳ１２２～Ｓ１２８、及びステップＳ１３２が追加された点であり、他の処理は図８に示した画像の管理処理と同じである。

ステップＳ１２０の判定処理で画像の管理モードがモード２と判定された場合に、ステップＳ１２２が実行される。

ステップＳ１２２において、ＣＰＵ３１は、受信した画像が最初の画像であるか否かを判定する。最初の画像である場合にはステップＳ１２４に移行し、ステップＳ１２４において、ＣＰＵ３１はタイマＴＢを起動してからステップＳ１２６に移行する。タイマＴＢは最初の画像を受信してからの経過時間を計測するタイマであり、タイマＴＡと異なるタイマである。時間Ｔ２は、ユーザが時間Ｔ２の値を指定する投稿を行うことで設定され、ストレージ３４に記憶される。

一方、ステップＳ１２２の判定処理で、受信した画像が最初の画像ではなく、まだ管理対象の範囲が確定していない画像の後に受信した画像であると判定された場合には、ステップＳ１２４の処理を実行することなくステップＳ１２６に移行する。

ステップＳ１２６において、ＣＰＵ３１は、タイマＴＢの値が時間Ｔ２以下であるか否かを判定する。

時間Ｔ２は、最初の画像を受信してから他の画像の受信に備えて待機する待機期間の上限時間を表す値であり、例えば予めストレージ３４に記憶されている。時間Ｔ２は、時間Ｔ１よりも短く設定され、ＣＰＵ３１は、時間Ｔ２以内に受け付けた画像の各々を最初の画像と共にまとめて管理するように制御する。

受信した画像が最初の画像の投稿時間から時間Ｔ２を越えてから受信した画像であればステップＳ１２８に移行し、ステップＳ１２８において、ＣＰＵ３１は、最初の画像と共に時間Ｔ２以内に受け付けた画像の各々をまとめて１つの画像群に設定し、当該画像群に対して識別情報を生成する。これにより管理対象となる画像の範囲が確定されたことから、一緒に管理される画像がまだ投稿されていないような初期状態に戻る。

すなわち、タイマＴＢの値が時間Ｔ２を越えてから受信した先頭の画像は新たな最初の画像となり、当該最初の画像を含む新たな画像群を生成するために、ステップＳ１３２において、ＣＰＵ３１はタイマＴＢを再起動して画像の管理対象を更新する。

この場合、ステップＳ１４０では、受信した画像を新たな画像群に含まれる画像としてＲＡＭ３３に記憶する。

一方、ステップＳ１２６の判定処理で、画像を受信した際のタイマＴＢの値が時間Ｔ２以下であると判定された場合には、受信した画像は最初の画像とまとめて管理される画像ということになるためステップＳ１４０に移行する。

この場合、ステップＳ１４０では、受信した画像を最初の画像から時間Ｔ２以内に投稿された画像の各々と関連付けてＲＡＭ３３に記憶する。

画像を受信する毎にステップＳ１５０でタイマＴＡが再起動されるため、画像を受信してから時間Ｔ１以内に後続の画像を受信しなかった場合には、強制的に最初の画像を受信してから時間Ｔ２以内に受信した画像の各々が１つの管理単位としてまとめられることになる。

図１４に示した画像の管理処理では、最初の画像から時間Ｔ２を越えて投稿された画像は異なる管理単位にまとめられることになる。しかしながら、例えば本来は同じ画像群としてまとめたかったのに、画像の選択操作に手間取ってしまい、画像の投稿が最初の画像から時間Ｔ２を越えてしまったという状況が発生することがある。

したがって、ＣＰＵ３１は最初の画像の投稿から時間Ｔ２を越えたと判定した場合、例えばステップＳ１２８において、時間Ｔ２を越えたことを通知する通知情報をトークルームに投稿すると共に、最初の画像の投稿からＴ２以内に投稿された画像とまとめて管理したい画像が他にあるか問い合わせる情報をトークルームに投稿してもよい。

図１５は、最初の画像の投稿から時間Ｔ２を越えた場合に、チャットボットが追加したい画像が他にあるかユーザに問い合わせているトークルームの一例を示す図である。図１５の例では、情報Ｍ１０が投稿されてから時間Ｔ２以内に情報Ｍ２０が投稿されたが、以降は情報が投稿されることなく時間Ｔ２を越えた状況を示している。すなわち、情報Ｍ１０及びＭ２０に含まれる各々の画像が１つの画像群として管理されるが、情報Ｍ１０の投稿から時間Ｔ２を越えた場合に、チャットボットは「追加する画像がありますか？」というように、情報Ｍ１０及びＭ２０に含まれる各々の画像をまとめた画像群に追加して管理したい情報が存在するかを問い合わせる情報Ｍ２２をトークルームに投稿する。

制御装置３０は、情報Ｍ２２の投稿後にタイマＴＢの経過時間と比較する時間を時間Ｔ２から時間Ｔ３（Ｔ２＜Ｔ３）に延長して、１つの画像群にまとめられる画像の範囲を延長する。情報Ｍ２２の投稿を受けて、情報Ｍ１０及び情報Ｍ２０の投稿者が画像を含む情報Ｍ３０を時間Ｔ３以内に投稿した場合には、制御装置３０は、情報Ｍ３０に含まれる画像も情報Ｍ１０及び情報Ｍ２０の画像をまとめた画像群に追加して管理する。情報Ｍ３０は、既に管理対象が確定した情報群とまとめて管理したい情報が存在することを知らせる応答情報の一例である。

チャットボットは、情報Ｍ３０に含まれる画像も情報Ｍ１０及び情報Ｍ２０の画像をまとめた画像群に追加したことを画像の投稿者に通知するため、情報Ｍ３２をトークルームに投稿する。

このように本実施の形態に係る制御装置３０は、画像の管理モードとしてモード１及びモード２といった２つのモードを備える。画像の管理モードがモード２に切り換えられた場合、画像の投稿時間に基づいて画像の集約範囲を決定し、集約範囲内の画像を１つの画像群にまとめて管理する。

＜第１実施形態の変形例１＞
上記では、画像の投稿時間に基づいた集約基準に従って画像の集約範囲を決定する例について説明したが、画像の集約基準は時間を用いたものだけに限られない。以降では、様々な方法で画像の集約範囲を決定する制御装置３０について説明する。

まず、画像の集約範囲の指定に区切り情報を用いる制御装置３０の例について説明する。区切り情報とは、画像の集約範囲の開始及び終了を表す情報であり、どのような情報を区切り情報として用いるかは制御システムで予め定められている。

図１６は、トークルームに画像が投稿された場合に、ＣＰＵ３１によって実行される画像の管理処理の他の一例を示すフローチャートである。説明の便宜上、投稿者は区切り情報及び画像以外の情報はトークルームに投稿しないものとする。

ステップＳ３００おいて、ＣＰＵ３１は図８のステップＳ１４０と同様に、投稿された画像の各々を関連付けてＲＡＭ３３に記憶する。

ステップＳ３１０において、ＣＰＵ３１は画像に引き続き、何らかの情報を受信したか否かを判定する。情報を受信していない場合にはステップＳ３１０の判定処理を繰り返し実行して、トークルームへの情報の投稿を監視する。一方、何らかの情報を受信した場合にはステップＳ３２０に移行する。

ステップＳ３２０において、ＣＰＵ３１は、ステップＳ３１０で受信した情報が区切り情報か否かを判定する。受信した情報が区切り情報ではない場合、すなわち、受信した情報が画像である場合にはステップＳ３００に移行し、ステップＳ３１０で受信した画像をこれまでに受信した画像の各々と関連付けてＲＡＭ３３に記憶する。一方、受信した情報が区切り情報の場合にはステップＳ３３０に移行する。

ステップＳ３３０において、ＣＰＵ３１は、ステップＳ３００で関連付けて記憶した画像の各々を１つの画像群として管理し、図１６に示す画像の管理処理を終了する。

すなわち、ＣＰＵ３１は、トークルームに最初の画像が投稿されてから区切り情報が投稿される前までを画像の集約範囲として管理する。画像の集約範囲に複数の画像が含まれる場合にはモード２による画像の管理が行われ、最初の画像しか存在しない場合には、モード１による画像の管理が行われる。

図１７は、制御装置３０で図１６に示した画像の管理処理が実行される場合のトークルームの一例を示す図である。図１７の例では区切り情報として「投稿終了」が用いられているが、区切り情報を表す文字は「投稿終了」に限られない。また、区切り情報は文字に限られず画像であってもよい。

画像の投稿者が情報Ｍ３３で区切り情報を投稿した場合、チャットボットは、情報Ｍ３３が投稿されるまでにトークルームに投稿された情報Ｍ１０に含まれる最初の画像と情報Ｍ２０に含まれる次の画像を１つの画像群にまとめて管理したことを通知する情報Ｍ３４をトークルームに投稿する。図１５で説明したように、チャットボットは区切り情報が投稿された後、既に管理対象が確定した画像群に追加したい画像が存在するかを問い合わせてもよい。

なお、図１６に示した画像の管理処理では画像の集約範囲の終わりを指示するために区切り情報を用いたが、画像の集約範囲の始まりにも区切り情報を用いてもよい。

図１８は、１つにまとめたい画像を区切り情報で囲んだトークルームの一例を示す図である。図１８の例では画像の集約範囲の始まりを示す区切り情報として「投稿開始」が用いられているが、画像の集約範囲の始まりを示す区切り情報は「投稿開始」に限られない。また、区切り情報は文字に限られず画像であってもよい。

図１８の例の場合、画像の集約範囲の始まりを示す情報Ｍ１と、画像の集約範囲の終わりを示す区切り情報Ｍ３３によって囲まれた範囲が画像の集約範囲に設定され、集約範囲内に含まれる画像が１つの画像群にまとめられて管理される。画像の集約範囲に複数の画像が含まれる場合にはモード２による画像の管理が行われ、１つの画像しか存在しない場合には、モード１による画像の管理が行われる。すなわち、画像の管理モードを指定するモード指定が予め行われていなくても、区切り情報の投稿によって画像の管理モードが切り換えられる。

＜第１実施形態の変形例２＞
次に、画像の集約範囲の指定に画像の投稿数を用いる制御装置３０の例について説明する。

図１９は、トークルームに画像が投稿された場合に、ＣＰＵ３１によって実行される画像の管理処理の他の一例を示すフローチャートである。制御装置３０には、画像の投稿数を規定した規定数Ｎ（Ｎは１以上の整数）が予め設定され、例えばストレージ３４に記憶されている。

ステップＳ４００において、ＣＰＵ３１は図８のステップＳ１００の処理と同様に、タイマＴＡを起動する。

ステップＳ４１０において、受信した画像の数が規定数Ｎに達したか否かを判定する。受信した画像の数が規定数Ｎに達していない場合にはステップＳ４２０に移行する。

ステップＳ４２０において、ＣＰＵ３１は、図８のステップＳ１４０の処理と同様に、受信した画像の各々を関連付けてＲＡＭ３３に記憶する。

ステップＳ４３０において、ＣＰＵ３１は、後続の別の画像を受信したか否かを判定する。別の画像を受信した場合にはステップＳ４５０に移行し、ステップＳ４５０において、ＣＰＵ３１は、タイマＴＡを再起動してからステップＳ４１０に移行する。

一方、ステップＳ４３０の判定処理で別の画像を受信していないと判定された場合にはステップＳ４４０に移行し、ステップＳ４４０において、ＣＰＵ３１は、タイマＴＡの値が時間Ｔ１以下であるか否かを判定する。タイマＴＡの値が時間Ｔ１以下の場合にはステップＳ４３０に移行する。すなわち、ＣＰＵ３１は、受信した画像数が規定数Ｎに達するまでステップＳ４１０～Ｓ４５０の各処理を繰り返し実行する。

これに対して、ステップＳ４１０の判定処理で受信した画像の数が規定数Ｎに達したと判定された場合、ステップＳ４６０に移行する。

ステップＳ４６０において、ＣＰＵ３１は起動しているタイマＴＡを停止し、ステップＳ４７０において、ステップＳ４２０で関連付けて記憶した画像の各々を１つの画像群として管理し、図１９に示す画像の管理処理を終了する。

また、ステップＳ４４０の判定処理でタイマＴＡの値が時間Ｔ１を越えた場合も、投稿者による画像の投稿に一区切りついたと判定されるため、ステップＳ４６０及びＳ４７０の処理を実行して図１９に示す画像の管理処理を終了する。

画像の管理対象が確定した後に新たな画像が投稿されると図１９に示す画像の管理処理が再開されるため、受信した画像の数と規定数Ｎとの比較が順次行われ、最大Ｎ枚の画像が含まれる画像群毎に画像が管理されることになる。

図２０は、制御装置３０で図１９に示した画像の管理処理が実行される場合のトークルームの一例を示す図である。図１９の例では規定数Ｎが“２”に設定されている。

したがって、それぞれ画像を含んだ情報Ｍ１０及びＭ２０がトークルームに投稿されると、制御装置３０は２つの画像をまとめて管理すると共に、チャットボットは、２つの画像を１つの画像群にまとめて管理したことを通知する情報Ｍ３４をトークルームに投稿する。

その後、画像を含む情報Ｍ３０が投稿されてから時間Ｔ１以内に後続の別の画像を含む情報が投稿されなかったため、制御装置３０は、受信した画像の数が２枚に達しない場合であっても情報Ｍ３０に含まれる１枚の画像だけを管理対象として識別情報を生成する。

この場合、チャットボットは、受信した画像数が規定数に達していないが、画像の投稿が途中で終了したと考えられため、これまでに投稿された画像を管理対象として管理したことを通知する情報Ｍ３５をトークルームに投稿する。

受信した画像の数によって画像の集約範囲を規定する場合、規定数Ｎを“１”に設定することでモード１による画像の管理が行われる。また、規定数Ｎを“２”以上に設定すればモード２による画像の管理が行われるが、必ずしもモード２以外の管理が行われないわけではなく、例えば１枚しか画像が投稿されない場合等、状況によってはモード１による画像の管理が行われることがある。

＜第１実施形態の変形例３＞
次に、画像の集約範囲の指定に画像の容量を用いる制御装置３０の例について説明する。画像の容量は、画像のデータサイズとも呼ばれる。

図２１は、トークルームに画像が投稿された場合に、ＣＰＵ３１によって実行される画像の管理処理の他の一例を示すフローチャートである。制御装置３０には、まとめて管理する画像の上限容量を規定した規定容量Ｌ（Ｌは正の実数）が予め設定され、例えばストレージ３４に記憶されている。

ステップＳ５００において、ＣＰＵ３１は図８のステップＳ１００の処理と同様に、タイマＴＡを起動する。

ステップＳ５１０において、ＣＰＵ３１は受信した画像の合計容量を算出する。なお、図２１に示す画像の管理処理が開始される毎に、ＣＰＵ３１は画像の合計容量を予め“０”に初期化している。

ステップＳ５２０において、ＣＰＵ３１は、ステップＳ５１０で算出した画像の合計容量が規定容量Ｌを超えたか否かを判定する。画像の合計容量が規定容量Ｌ以下である場合にはステップＳ５３０に移行する。

ステップＳ５３０において、ＣＰＵ３１は、図８のステップＳ１４０の処理と同様に、受信した画像の各々を関連付けてＲＡＭ３３に記憶する。

ステップＳ５４０において、ＣＰＵ３１は、後続の別の画像を受信したか否かを判定する。別の画像を受信した場合にはステップＳ５６０に移行し、ステップＳ５６０において、ＣＰＵ３１はタイマＴＡを再起動してからステップＳ５１０に移行する。

一方、ステップＳ５４０の判定処理で別の画像を受信していないと判定された場合にはステップＳ５５０に移行し、ステップＳ５５０において、ＣＰＵ３１は、タイマＴＡの値が時間Ｔ１以下であるか否かを判定する。タイマＴＡの値が時間Ｔ１以下の場合にはステップＳ５４０に移行する。すなわち、ＣＰＵ３１は、受信した画像の合計容量が規定容量Ｌを超えるまでステップＳ５１０～Ｓ５６０の各処理を繰り返し実行する。

これに対して、画像を受信したことによってステップＳ５２０の判定処理で画像の合計容量が規定容量Ｌを超えたと判定された場合には、ステップＳ５７０に移行する。

画像の合計容量が規定容量Ｌ以下となるような範囲が１つにまとめて管理される画像の集約範囲に設定されていることから、ステップＳ５７０において、ＣＰＵ３１は、受信した各々の画像を、受信したことで規定容量Ｌを超えることになってしまった最後の画像（「繰越画像」という）と、繰越画像を受信するまでに受信した画像に分離し、繰越画像を受信するまでに受信した画像の各々からなる画像群を１つの管理単位として管理する。

ステップＳ５８０において、ＣＰＵ３１は、繰越画像が存在するか否かを判定する。このように繰越画像が存在するか否かを判定する理由は、ステップＳ５５０の判定処理でタイマＴＡが時間Ｔ１を越えたと判定された場合には、繰越画像を受信しなくともステップＳ５８０の判定処理が実行されるためである。

繰越画像が存在する場合には、繰越画像を最初の画像とした新たな画像の管理を開始するため、ステップＳ５９０に移行する。

ステップＳ５９０において、ＣＰＵ３１は、画像の合計容量を繰越画像の容量に設定し、画像の合計容量を更新する。

ステップＳ６００において、ＣＰＵ３１はステップＳ５６０の処理と同様に、タイマＴＡを再起動してからステップＳ５４０に移行する。以降、新たな画像を受信する毎にステップＳ５１０で画像の合計容量が更新され、受信した画像の合計容量が規定容量Ｌを超える毎に、規定容量Ｌを超えるまでに受信した画像の各々からなる画像群が１つの管理単位として管理されることになる。

また、受信した画像の合計容量が規定容量Ｌを超えていない状況で後続の画像が投稿されず、タイマＴＡが時間Ｔ１を越えた場合にはステップＳ５８０の判定処理で繰越画像が存在しないと判定され、ステップＳ６１０に移行する。

この場合、受信した全ての画像に識別情報が対応付けられ、管理が行われていない画像が存在しないことから、ステップＳ６１０において、ＣＰＵ３１は、タイマＴＡを停止して図２１に示す画像の管理処理を終了する。

なお、最初の画像の容量が規定容量Ｌを超えるような画像である場合には、１つの画像だけで規定容量Ｌを超えることになる。この場合、最初の画像だけを管理対象とするモード１による画像の管理が行われる。すなわち、制御装置３０は、画像の管理モードを指定するモード指定が予め行われていなくても、受信した画像の容量に応じて、画像の管理モードをモード１またはモード２に切り換える制御を行う。

図２２は、制御装置３０で図２１に示した画像の管理処理が実行される場合のトークルームの一例を示す図である。図２２の例では、情報Ｍ１０に含まれる画像と情報Ｍ２０に含まれる各々の画像の合計容量は規定容量Ｌ以下であるが、情報Ｍ３０に含まれる画像の容量を加えると規定容量Ｌを超えてしまうような画像の投稿があった状況を表している。

したがって、制御装置３０はチャットボットを通じて、情報Ｍ１０に含まれる画像と情報Ｍ２０に含まれる画像をまとめて管理したことを通知する情報Ｍ３６をトークルームに投稿すると共に、情報Ｍ３０に含まれる画像だけを別の管理単位として管理したことを通知する情報Ｍ３７をトークルームに投稿している。

＜第１実施形態の変形例４＞
次に、チャットボットが参加しているチャットの形態に応じて画像の集約範囲を決定する制御装置３０の例について説明する。

図２３は、制御装置３０を起動した場合に、ＣＰＵ３１によって実行される画像の管理処理の他の一例を示すフローチャートである。

ステップＳ７００において、ＣＰＵ３１は、トークルームを通じて画像を受信したか否かを判定する。画像を受信していない場合にはステップＳ７１０に移行する。

トークルームは、例えば「卒業旅行に関する話題」というように、共通の話題に関して情報を記録したり交換したりする目的で開設され、必要がなくなれば閉鎖される。

したがって、ステップＳ７１０において、ＣＰＵ３１は、チャットボットとして参加し、画像の投稿を待ち受けているトークルームが閉鎖されたか否かを判定する。トークルームの閉鎖は、トークルームサーバ２０に対するユーザの設定により、トークルーム自体の閉鎖が指示される他、例えば最後に投稿された画像から予め定めた期間が経過しても、画像がまったく投稿されなかったことや、トークルームに例えば「このトークルームはもう使わない」というような、トークルームの閉鎖を意図する情報の投稿が行われていることによっても判定される。

したがって、ＣＰＵ３１は、トークルームサーバ２０にトークルームが閉鎖されたかを問い合わせたり、トークルームに投稿された最後の画像の投稿時間からの経過時間を算出したり、トークルームにトークルームの閉鎖を意図する情報の投稿が行われていないか確認することで、トークルームが閉鎖されたか否かを判定する。

また、卒業旅行のように実施日が決まっている事柄に対するトークルームの場合、実施日を過ぎるとトークルームへの画像の投稿が減少していき、誰もトークルームへの投稿を行わなくなるような状況になることがある。したがって、実施日が決まっている事柄に対するトークルームの場合、ＣＰＵ３１は、実施日からの経過時間を算出し、算出した経過時間をトークルームへの投稿が行われなくなる時間として予め設定された閉鎖時間と比較することで、トークルームが閉鎖されたか否かを判定してもよい。

トークルームが閉鎖されていないと判定された場合にはステップＳ７００に移行する。すなわち、ＣＰＵ３１は、トークルームが閉鎖されるまでトークルームへの画像の投稿を監視する。

ステップＳ７００の判定処理で画像を受信したと判定された場合には、ステップＳ７２０に移行する。

ステップＳ７２０において、ＣＰＵ３１は、トークルームで行われているチャットの形態が個別チャットであるか否かを判定する。具体的には、ＣＰＵ３１は、トークルームに参加しているユーザの数を確認し、トークルームに参加しているユーザの数がチャットボットを含めて２名である場合には個別チャット、３名以上である場合にはグループチャットと判定する。チャットの形態が個別チャットである場合には、ステップＳ７３０に移行する。

個別チャットの場合、トークルームに画像の投稿者以外から画像の投稿が行われることはなく、投稿者の画像を他のユーザの画像とまとめて管理する必要がない。したがって、ステップＳ７３０において、ＣＰＵ３１は受信した画像を単独で管理してステップＳ７００に移行し、次の画像の受信に備える。

また、ステップＳ７２０の判定処理でチャットの形態がグループチャットであると判定された場合には、ステップＳ７４０に移行する。

ステップＳ７４０において、ＣＰＵ３１は、受信した画像の各々を関連付けてＲＡＭ３３に記憶してステップＳ７００に移行し、次の画像の受信に備える。すなわち、チャットの形態がグループチャットの場合、トークルームに投稿された画像の各々が関連付けられてＲＡＭ３３に記憶される。

一方、ステップＳ７１０の判定処理でトークルームが閉鎖されたと判定された場合には、ステップＳ７５０に移行する。

ステップＳ７５０において、ＣＰＵ３１は、チャットの形態が個別チャットであるか否かを判定する。チャットの形態がグループチャットの場合には、受信した画像の各々がステップＳ７４０で関連付けられただけで、識別情報の対応付けが行われていないことからステップＳ７６０に移行する。

ステップＳ７６０において、ＣＰＵ３１は、図８のステップＳ１８０の処理と同様に、グループチャットにおいて少なくとも１つの画像を受信したか否かを判定する。少なくとも１つの画像を受信している場合にはステップＳ７７０に移行し、ステップＳ７７０において、ＣＰＵ３１は、ステップＳ７４０で関連付けて記憶した画像の各々を１つの画像群として管理し、図２３に示す画像の管理処理を終了する。

一方、ステップＳ７５０の判定処理でチャットの形態が個別チャットと判定された場合、またはステップＳ７６０の判定処理でグループチャットにおいて画像を１度も受信していないと判定された場合には、識別情報が対応付けられていない画像が存在しないため、ステップＳ７７０の処理を実行することなく図２３に示す画像の管理処理を終了する。

すなわち、制御装置３０に対して画像の管理モードを指定するモード指定が予め行われていなくても、チャットボットが参加しているチャット形態によって画像の管理モードが切り換えられる。また、トークルームには共通の話題が投稿されることから、トークルームの閉鎖を契機にして、トークルームに投稿された画像を１つの画像群にまとめて管理することで、共通の話題に関連した画像を含んだアルバム等が作成されることになる。

この他、制御装置３０は、トークルームに投稿される情報のファイル形式に応じて画像の管理モードを切り換えるようにしてもよい。

例えば、投稿された情報が画像ファイルの場合、画像ファイルでは１つのファイルに１つの画像しか含まれないため、情報の管理モードをモード２に切り換えてまとめて管理すれば、１つの識別情報で複数の画像が印刷されるようになる。一方、画像ファイルと異なるファイル、例えば文書作成アプリケーションが出力する文書ファイルでは、既に文書がページ単位にまとめられているため、画像ファイルに比べてまとめて管理したいというニーズが少ない。したがって、制御装置３０は、トークルームに投稿された情報が画像ファイルの場合には情報の管理モードをモード２に切り換え、トークルームに投稿された情報が文書ファイルの場合にはモード１に切り換える。情報のファイル形式の特定には、例えばファイル名の拡張子が用いられる。

また、制御装置３０は、トークルームに投稿される情報の内容が印刷される記録媒体の種類に応じて、画像の管理モードを切り換えるようにしてもよい。情報には、画像形成装置４０での印刷に用いられる記録媒体の種類を指定した項目が情報のプロパティとして付加されている場合がある。

例えば、情報がはがきに印刷したい内容や封筒の宛名である場合、記録媒体としてはがきや封筒が指定される。したがって、記録媒体の種類にはがきや封筒が指定されている場合には、１つのはがきにそれぞれ別の人に宛てた複数の内容が印刷されないように、情報をまとめて管理しない方が好ましい。

一方、情報と対応付けられた記録媒体の種類に、普通紙よりも色にじみが少なく発色のよい写真用紙が指定されている場合には、情報が画像であることが多い。情報が画像の場合には画像をまとめて印刷した方が、画像を個別に印刷するよりも写真用紙の使用枚数が少なくなるため印刷料金も低下することになる。

したがって、トークルームに投稿された情報の記録媒体として写真用紙が指定されている場合には、情報の管理モードをモード２に切り換え、普通紙、はがき、及び封筒のように写真用紙以外の用紙が指定されている場合には、情報の管理モードをモード１に切り換える。

なお、本実施の形態に示した画像の各管理処理では、図１５を用いて説明したように、画像の投稿者が画像の追加を指示した場合、既に集約範囲が確定してまとめて管理された画像群に、後から新たに投稿された画像を追加してもよい。

制御装置３０でどのような集約基準に従って画像を管理するかは、例えばユーザがトークルームを通じて制御装置３０に指示することによって設定される。

＜第２実施形態＞
第１実施形態で説明したように、制御装置３０ではトークルームに投稿された情報を画像の集約基準に従って情報群にまとめて管理する。こうした情報の管理機能を別の観点から見れば、情報の集約基準を適切に設定することで、情報の集約基準に応じた情報の分類が行われることになる。したがって、本実施の形態では、情報の分類を行う制御装置３０について説明する。

なお、本実施の形態に係る制御装置３０のハードウェア構成及び機能構成は、それぞれ図３、及び図５と同じ構成が用いられる。

制御装置３０は、投稿された情報と対応付けられた属性と属性条件を参照し、属性条件を満たす属性を有する情報毎にそれぞれ１つの情報群としてまとめて管理し、各々の情報群に対して対応する識別情報を生成する。「情報と対応付けられた属性」とは、情報の分類に用いられる項目のことであり、情報の特徴を示す項目、及び情報に対して実行される特定処理に関する項目を含む。

情報の特徴を示す項目としては、例えば情報の作成日、情報の更新日、情報の作成者、情報のファイル形式、情報に含まれる文字数、情報の表現に用いられている色数、情報の作成場所、及び情報に含まれる内容等が含まれる。また、情報に対して実行される特定処理に関する項目としては、特定処理が印刷処理の場合、例えば情報が印刷される記録媒体の種別等が含まれる。「属性条件」とは、対応する属性を用いて情報をどのように分類するかを規定した条件のことである。

第１実施形態の場合と同様に、以降の説明においても制御装置３０で扱う情報の一例として画像を例にした説明を行う。

図２４は、制御装置３０が起動した場合に、ＣＰＵ３１によって実行される画像の分類処理の一例を示すフローチャートである。図２４に示す画像の分類処理を規定する制御プログラムは、例えば制御装置３０のＲＯＭ３２に予め記憶されている。制御装置３０のＣＰＵ３１は、ＲＯＭ３２に記憶される制御プログラムを読み込み、図２４に示す画像の分類処理を実行する。

ユーザがトークルームに投稿する画像は、例えば未分類のままユーザ端末１０のフォルダに格納された画像であり、ユーザは所望する分類方法に応じて、画像の分類に用いられる画像と対応付けられた属性を、制御装置３０に予め設定しているものとする。画像と対応付けられた属性の設定は、ユーザが例えば分類に用いたい属性をトークルームに投稿することで設定される。ここでは画像と対応付けられた属性として「画像の作成日」が設定され、属性条件として「同じ画像をまとめる」といった条件が設定されているものとする。画像の作成日のような属性は、画像のプロパティとして画像に付加されている。

ステップＳ８００において、ＣＰＵ３１は、画像の投稿間隔を計測するタイマＴＡを起動する。

ステップＳ８１０において、ＣＰＵ３１は、トークルームを通じて画像を受信したか否かを判定する。画像を受信していない場合にはステップＳ８２０に移行し、ステップＳ８２０において、ＣＰＵ３１は、タイマＴＡの値が時間Ｔ１以下であるか否かを判定する。タイマＴＡの値が時間Ｔ１以下の場合にはステップＳ８１０に移行する。ＣＰＵ３１は、タイマＴＡの値が時間Ｔ１を越えるまでステップＳ８１０及びＳ８２０を繰り返し実行することで、ユーザによるトークルームへの画像の投稿を監視する。

一方、画像を受信した場合にはステップＳ８３０に移行し、ステップＳ８３０において、ＣＰＵ３１は、受信した画像の各々を関連付けてＲＡＭ３３に記憶する。

画像を受信したことによりステップＳ８４０において、ＣＰＵ３１は、タイマＴＡを再起動してからステップＳ８１０に移行する。すなわち、ＣＰＵ３１は、前の画像の投稿から時間Ｔ１以内に投稿された全ての画像を関連付けてＲＡＭ３３に記憶する。

ユーザによるトークルームへの画像の投稿が終了し、ステップＳ８２０の判定処理でタイマＴＡの値が時間Ｔ１を超えた場合には、ステップＳ８５０に移行する。

ステップＳ８５０において、ＣＰＵ３１はユーザによって設定された、画像と対応付けられた属性及び属性条件を参照する。この場合、画像と対応付けられた属性が「画像の作成日」で、属性条件が「同じ画像をまとめる」となっていることから、ＣＰＵ３１は、ステップＳ８３０で関連付けられた複数の画像を作成日が同じ画像同士に分類する。

ステップＳ８６０において、ＣＰＵ３１は、ステップＳ８５０で分類したそれぞれの画像群を管理単位とし、それぞれの管理単位に識別情報を対応付けてストレージ３４で管理する。以上により、図２４に示した画像の分類処理を終了する。

すなわち、制御装置３０では、作成日が同じ画像に対してはモード２による画像の管理が行われ、他の何れの画像とも作成日が異なる画像に対してはモード１による画像の管理が行われる。画像と対応付けられた属性、及び属性条件に応じて制御装置３０における画像の管理モードが切り換えられることから、画像と対応付けられた属性と属性条件は、画像の集約基準の一例でもある。

制御装置３０は、画像形成装置４０から識別情報を受信した場合、受信した識別情報と対応付けられて管理される画像群を識別情報の送信元である画像形成装置４０に送信することで、画像形成装置４０によって同じ日に作成された画像がまとめて印刷される。

図２５は、制御装置３０で図２４に示した画像の分類処理が実行された場合の画像の分類例を示す図である。画像Ａ～画像Ｈの８枚の画像のうち、画像Ａ～画像Ｃ、画像Ｄ及び画像Ｅ、画像Ｆ及び画像Ｇ、並びに、画像Ｈをそれぞれ同じ作成日の画像とする。

画像Ａ～画像Ｈがトークルームに投稿された場合、制御装置３０は、画像Ａ～画像Ｃを画像群α、画像Ｄ及び画像Ｅを画像群β、画像Ｆ及び画像Ｇを画像群γ、並びに、画像Ｈを画像群δとして分類し、各々の画像群を管理単位として管理する。画像群δには画像Ｈしか含まれないため、画像群δに対してはモード１による画像の管理が行われ、他の画像群に対してはモード２による画像の管理が行われることになる。

なお、既に説明したように、画像と対応付けられた属性と属性条件は、ユーザが所望する分類方法に応じて変更される。

例えば画像と対応付けられた属性が上記の例と同じ「画像の作成日」であったとしても、属性条件を「３日以内の画像をまとめる」や「土曜に作成した画像をまとめる」というように変化させることで異なる分類が行われる。

また、画像と対応付けられた属性を「画像の撮影場所」とし、属性条件を「Ｘｋｍ（Ｘは正の実数）以内の画像をまとめる」と設定すれば、各々の画像の撮影場所からＸｋｍ以内の範囲で撮影された画像同士がまとめられて管理される。画像の撮影場所は、例えば画像に付加されるＥｘｉｆ(Exchangeable image file format)情報、またはＧＰＳ(Global positioning system)を参照することで得られる。

また、画像と対応付けられた属性を「画像の内容」とし、属性条件を「同じ人が写っている画像をまとめる」と設定すれば、同じ人が含まれている画像同士がまとめられて管理される。画像に写っている人や物の識別は公知の画像認識技術や、被写体と対応付けられ、被写体が誰かを示したタグ情報を参照することで行われる。属性条件を変更すれば、例えば３人以上写っている画像、屋内で撮影された画像、及び動物が写っている画像というように、画像の内容に応じた異なる分類が行われる。

なお、本実施の形態に示した画像の分類処理では、図１５を用いて説明したように、画像の投稿者が画像の追加を指示した場合、それぞれ分類された画像群に、後から新たに投稿された画像を追加してもよい。

以上、実施の形態を用いて本発明について説明したが、本発明は各実施の形態に記載の範囲には限定されない。本発明の要旨を逸脱しない範囲で各実施の形態に多様な変更又は改良を加えることができ、当該変更又は改良を加えた形態も本発明の技術的範囲に含まれる。例えば、本発明の要旨を逸脱しない範囲で処理の順序を変更してもよい。

本実施の形態では、一例として画像の管理モードの設定処理、画像の管理処理、画像の印刷処理、及び画像の分類処理をソフトウェアで実現する形態について説明したが、図７、図８、図１３、図１４、図１６、図１９、図２１、図２３、図２４に示したフローチャートと同等の処理を、例えばＡＳＩＣ（Application Specific Integrated Circuit）に実装し、ハードウェアで処理させるようにしてもよい。この場合、各処理をそれぞれソフトウェアで実現した場合と比較して、処理の高速化が図られる。

また、上述した実施の形態では、制御プログラムがＲＯＭ３２にインストールされている形態を説明したが、これに限定されるものではない。本発明に係る制御プログラムは、コンピュータで読み取り可能な記憶媒体に記録された形態で提供することも可能である。例えば、本発明に係る制御プログラムを、ＣＤ(Compact Disc)－ＲＯＭ、又はＤＶＤ(Digital Versatile Disc)－ＲＯＭ等の光ディスクに記録した形態で提供してもよい。また、本発明に係る制御プログラムを、ＵＳＢ(Universal Serial Bus)メモリ及びフラッシュメモリ等の半導体メモリに記録した形態で提供してもよい。更に、制御装置３０は、通信Ｉ／Ｆ３７を介して、通信回線５０に接続される外部装置から本発明に係る制御プログラムを取得するようにしてもよい。

１０（１０Ａ、１０Ｂ） ユーザ端末
１２ 送信ボタン
１４（１４Ａ、１４Ｂ、１４Ｃ） 領域
２０ トークルームサーバ
２１（３１） ＣＰＵ
２２（３２） ＲＯＭ
２３（３３） ＲＡＭ
２４（３４） ストレージ
２５（３５） 入力部
２６（３６） 表示部
２７（３７） 通信Ｉ／Ｆ
２９（３９） バス
３０ 制御装置
４０（４０Ａ、４０Ｂ） 情報処理装置（画像形成装置）
５０ 通信回線
２０１ 提供部
３０１ 受信部
３０２ 制御部
３０３ 統合部
３０４ 生成部
３０５ 印刷処理部
３０６ 送信部

Claims (20)

1. チャットのトークルームに投稿された情報を情報毎に管理する第１のモードと、前記トークルームに投稿された各々の情報を１つの情報群にまとめて管理する第２のモードの２つの管理モードを備え、
   前記トークルームに投稿された情報を受け付けた場合、受け付けた情報を前記第１のモードで管理するか、または前記第２のモードで管理するかを決定する制御を行う制御部
   を備えた制御装置。
2. 前記制御部は、チャットの形態が個別チャットの場合に前記トークルームに投稿された情報に対して、前記第１のモードによる管理を行い、チャットの形態がグループチャットの場合に前記トークルームに投稿された情報に対しては、前記第２のモードによる管理を行うように制御する
   請求項１記載の制御装置。
3. 前記制御部は、グループチャットに参加するメンバーによって共通の話題を投稿する投稿場所が作成されている場合、前記投稿場所に投稿された各々の画像を第２のモードによる情報の管理対象とする
   請求項２記載の制御装置。
4. 前記制御部は、前記投稿場所の閉鎖が行われるまでに前記投稿場所に投稿された各々の画像を、第２のモードによる情報の管理対象とする
   請求項３記載の制御装置。
5. 前記制御部は、前記トークルームに投稿される、以降の情報の受信に備えて待機しない設定が行われている場合、前記第１のモードによる情報の管理を行い、前記トークルームに投稿される、以降の情報の受信に備えて待機する設定が行われている場合、前記第２のモードによる情報の管理を行う
   請求項１記載の制御装置。
6. 前記制御部は、第２のモードによる情報の管理を行う場合、前記トークルームを通じて最初の情報を受け付けてから予め設定された期間以内に受け付けた各々の情報を前記第２のモードによる情報の管理対象とすると共に、前記予め設定された期間を超えて受け付けた先頭の情報を前記最初の情報に設定し、前記第２のモードによる情報の管理対象を更新する制御を行う
   請求項５記載の制御装置。
7. 前記制御部は、前記最初の情報を受け付けてからの経過時間が前記予め設定された期間を超えた場合、前記トークルームへの情報の投稿者に前記予め設定された期間を超えたことを通知する通知情報を前記トークルームに投稿すると共に、前記通知情報に対する応答として情報の投稿者から、１つの情報群にまとめて管理したい情報がまだ存在することを知らせる応答情報が投稿された場合、前記予め設定された期間を延長する制御を行う
   請求項６記載の制御装置。
8. 前記トークルームに投稿された情報の範囲指定が、範囲を指定する予め定めた区切り情報の投稿によって行われる場合、前記トークルームに最初の情報が投稿されてから前記区切り情報が投稿される前までを情報の管理範囲とし、
   前記制御部は、前記管理範囲に複数の情報が含まれる場合、前記管理範囲に含まれる複数の情報を前記第２のモードによる情報の管理対象とする制御を行う
   請求項１記載の制御装置。
9. 前記トークルームに投稿された情報の範囲指定が、範囲を表す予め定めた区切り情報の投稿によって行われる場合、前記区切り情報が投稿された後に前記トークルームに投稿された情報から前記区切り情報が再び投稿される前までを情報の管理範囲とし、
   前記制御部は、前記管理範囲に複数の情報が含まれる場合、前記管理範囲に含まれる複数の情報を前記第２のモードによる情報の管理対象とする制御を行う
   請求項１記載の制御装置。
10. 前記制御部は、前記トークルームに投稿された情報の容量の合計が予め定めた上限容量を超えた場合、前記トークルームを通じて前記上限容量を超えるまでに受信した情報の各々を前記第２のモードによる情報の管理対象とすると共に、前記トークルームに投稿された情報のうち、前記第２のモードによる情報の管理対象に含まれなかった残りの情報から前記上限容量との比較を順次行い、前記第２のモードによる情報の管理対象を更新する制御を行う
    請求項１記載の制御装置。
11. 前記制御部は、前記トークルームに投稿された１つの情報の容量が前記上限容量を超える場合、前記１つの情報を前記第１のモードによる情報の管理対象とする制御を行う
    請求項１０記載の制御装置。
12. 前記制御部は、前記トークルームに投稿された情報の投稿数が予め定めた規定数に達した場合で、かつ、前記規定数が２以上に設定されている場合、前記規定数の情報の各々を前記第２のモードによる情報の管理対象とすると共に、前記トークルームに投稿された情報の管理対象確定後から前記トークルームに投稿された情報の投稿数を計測し直して前記規定数との比較を順次行い、前記第２のモードによる情報の管理対象を更新する制御を行う
    請求項１記載の制御装置。
13. 前記制御部は、前記規定数が１に設定されている場合、前記トークルームに投稿された情報の各々を前記第１のモードによる情報の管理対象とする制御を行う
    請求項１２記載の制御装置。
14. 前記制御部は、前記トークルームに投稿された情報が文書ファイルである場合、前記文書ファイルを前記第１のモードによる情報の管理対象とし、前記トークルームに投稿された情報が画像ファイルである場合、前記画像ファイルを前記第２のモードによる情報の管理対象とする制御を行う
    請求項１記載の制御装置。
15. 前記制御部は、前記トークルームに投稿された情報の内容が形成される記録媒体の種別に応じて、前記トークルームに投稿された情報を前記第１のモードで管理するか、または前記第２のモードで管理するかを決定する制御を行う
    請求項１記載の制御装置。
16. 前記制御部は、前記記録媒体として写真用紙が指定されている場合、前記トークルームに投稿された各々の情報を前記第２のモードによる情報の管理対象とすると共に、前記記録媒体として写真用紙以外の用紙が指定されている場合には、前記トークルームに投稿された各々の情報を前記第１のモードによる情報の管理対象とする制御を行う
    請求項１５記載の制御装置。
17. 前記制御部は、前記トークルームへの情報の投稿者の指示に従って、第２のモードの実行によってまとめて管理される情報群に、前記トークルームに新たに投稿された情報を追加する制御を行う
    請求項１～請求項１６の何れか１項に記載の制御装置。
18. 前記制御部は、前記トークルームへの情報の投稿者の指示によって第１のモードによる情報の管理を行う場合と、前記第２のモードによる情報の管理を行う場合とで、前記トークルームへの情報の投稿者が操作する情報機器に表示される、前記トークルームに投稿する情報を選択する選択画面の動作が異なるように前記情報機器を制御する
    請求項１～請求項１７の何れか１項に記載の制御装置。
19. 前記第１のモードは、情報の各々が異なる投稿によって前記トークルームに投稿された場合、前記トークルームに投稿された各々の情報を情報毎に管理するモードであり、
    前記第２のモードは、情報の各々が異なる投稿によって前記トークルームに投稿された場合、前記トークルームに投稿された各々の情報を１つの情報群にまとめて管理するモードである
    請求項１記載の制御装置。
20. コンピュータを、請求項１～請求項１９の何れか１項に記載の制御装置の制御部として機能させるための制御プログラム。