(57)【特許請求の範囲】
【請求項１】
複数のユーザ端末と、少なくとも１つ以上のセンタサーバと、それらをつなぐネットワークからなり、該センタサーバ内のネットワーク・フォルダ・サーバのストレージ上に任意のユーザ端末からDRAG&DROPされたファイルがそのまま、もしくは、処理を経た結果が蓄積されるシステムにおける注目フォルダの処理切り替え方法であって、
前記ユーザ端末において、
前記ユーザ端末から前記ネットワーク・フォルダ・サーバ側のフォルダ（注目フォルダ）に対する該ユーザ端末側のフォルダ（処理対象フォルダ）のDROP処理である場合は、処理対象データを指定するパス情報に対して、該注目フォルダの直後のフォルダ名区切り文字を「フォルダ名区切り文字」、「基点フォルダ文字「．」（ピリオド）」、「フォルダ名区切り文字」からなる３文字に置換し、該ネットワーク・フォルダ・サーバに送信する置換ステップを行う
ことを特徴とする注目フォルダの処理切り替え方法。
【請求項２】
複数のユーザ端末と、少なくとも１つ以上のセンタサーバと、それらをつなぐネットワークからなり、該センタサーバ内のネットワーク・フォルダ・サーバのストレージ上に任意のユーザ端末からDRAG&DROPされたファイルがそのまま、もしくは、処理を経た結果が蓄積されるシステムのネットワーク・フォルダ・サーバにおける注目フォルダの処理切り替え方法であって、
前記ユーザ端末から受け付けたリクエストに含まれる処理対象データを指定するパス情報に対して、該パス情報内に「フォルダ名区切り文字」、「基点フォルダ文字「．」（ピリオド）」、「フォルダ名区切り文字」からなる３文字が存在するかを走査するパス情報走査ステップと、
存在すれば、前記「基点フォルダ文字「．」（ピリオド）」を含む３文字の直前までに記載されているフォルダを、前記ユーザ端末側の注目フォルダとして抽出し、該注目フォルダを用いる処理を実行する注目フォルダ抽出ステップと、
を行うことを特徴とする注目フォルダの処理切り替え方法。
【請求項３】
前記「フォルダ名区切り文字」、「基点フォルダ文字「．」（ピリオド）」、「フォルダ名区切り文字」からなる３文字が、前記注目フォルダの直後には存在せず、  前記注目フォルダの直前に存在する
請求項１または２記載の注目フォルダの処理切り替え方法。
【請求項４】
前記「フォルダ名区切り文字」、「基点フォルダ文字「．」（ピリオド）」、「フォルダ名区切り文字」からなる３文字の代わりに、「フォルダ名区切り文字」、「上位フォルダ文字列「..」」、「フォルダ名区切り文字」、「注目フォルダ名」、「フォルダ名区切り文字」からなる文字列とする
請求項１または２記載の注目フォルダの処理切り替え方法。
【請求項５】
「フォルダ名区切り文字」、「基点フォルダ文字「．」（ピリオド）」、「フォルダ名区切り文字」からなる３文字と共に、「フォルダ名区切り文字」、「上位フォルダ文字列「..」」、「フォルダ名区切り文字」、「注目フォルダ名」、「フォルダ名区切り文字」からなる文字列とを用いることで互換性を維持したまま注目フォルダに対する情報を付与するために、
前記「基点フォルダ文字「．」（ピリオド）」を含む３文字と前記「上位フォルダ文字列「..」」を含む文字列を、それぞれ２進法の「０」と「１」に対応させる
請求項１ないし請求項４のいずれか１項に記載の注目フォルダの処理切り替え方法。
【請求項６】
複数のユーザ端末と、少なくとも１つ以上のセンタサーバと、それらをつなぐネットワークからなり、該センタサーバ内のネットワーク・フォルダ・サーバのストレージ上に任意のユーザ端末からDRAG&DROPされたファイルがそのまま、もしくは、処理を経た結果が蓄積されるシステムのユーザ端末であって、
当該ユーザ端末から前記ネットワーク・フォルダ・サーバ側のフォルダ（注目フォルダ）に対する該ユーザ端末側のフォルダ（処理対象フォルダ）のDROP処理である場合は、処理対象データを指定するパス情報に対して、
前記注目フォルダの直後のフォルダ名区切り文字を、「フォルダ名区切り文字」、「基点フォルダ文字「．」（ピリオド）」、「フォルダ名区切り文字」からなる３文字に置換する第１の置換手段と、
前記注目フォルダの直前のフォルダ名区切り文字を、「フォルダ名区切り文字」、「基点フォルダ文字「．」（ピリオド）」、「フォルダ名区切り文字」からなる３文字に置換する第２の置換手段と、
前記注目フォルダの直後のフォルダ名区切り文字を、「フォルダ名区切り文字」、「上位フォルダ文字列「..」」、「フォルダ名区切り文字」、「注目フォルダ名」、「フォルダ名区切り文字」からなる文字列に置換する第３の置換手段の、３つの置換手段のうちのいずれか１つの置換手段と、
前記置換手段が置換したパス情報を前記ネットワーク・フォルダ・サーバに送信する送信手段を有する
ことを特徴とするユーザ端末。
【請求項７】
前記「基点フォルダ文字「．」（ピリオド）」を含む３文字と前記「上位フォルダ文字列「..」」を含む文字列を、それぞれ２進法の「０」と「１」に対応させる
請求項６記載のユーザ端末。
【請求項８】
複数のユーザ端末と、少なくとも１つ以上のセンタサーバと、それらをつなぐネットワークからなり、該センタサーバ内のネットワーク・フォルダ・サーバのストレージ上に任意のユーザ端末からDRAG&DROPされたファイルがそのまま、もしくは、処理を経た結果が蓄積されるシステムのネットワーク・フォルダ・サーバであって、
前記ユーザ端末から受け付けたリクエストに含まれる処理対象データを指定するパス情報に対して、該パス情報内に、
「フォルダ名区切り文字」、「基点フォルダ文字「．」（ピリオド）」、「フォルダ名区切り文字」からなる３文字が存在するかを走査し、存在すれば、当該３文字の直前に記載されているフォルダを、前記ユーザ端末側の注目フォルダとして抽出する第１の注目フォルダ抽出手段と、
「フォルダ名区切り文字」、「基点フォルダ文字「．」（ピリオド）」、「フォルダ名区切り文字」からなる３文字が存在するかを走査し、存在すれば、当該３文字の直後に記載されているフォルダを、前記ユーザ端末側の注目フォルダとして抽出する第２の注目フォルダ抽出手段と、
「フォルダ名区切り文字」、「上位フォルダ文字列「..」」、「フォルダ名区切り文字」、「注目フォルダ名」、「フォルダ名区切り文字」からなる文字列が存在するかを走査し、存在すれば、当該「上位フォルダ文字列「..」」を含む文字列の直前に記載されているフォルダを、前記ユーザ端末側の注目フォルダとして抽出する第３の注目フォルダ抽出手段の、３つの注目フォルダ抽出手段のうちのいずれか１つの注目フォルダ抽出手段と、
前記注目フォルダ抽出手段が抽出した注目フォルダを用いる処理を実行する注目フォルダ実行手段と、
を有することを特徴とするネットワーク・フォルダ・サーバ。
【請求項９】
前記「基点フォルダ文字「．」（ピリオド）」を含む３文字と前記「上位フォルダ文字列「..」」を含む文字列を、それぞれ２進法の「０」と「１」に対応させる
請求項８記載のネットワーク・フォルダ・サーバ。
【請求項１０】
請求項６または７に記載のユーザ端末を構成する各手段としてコンピュータを機能させるための注目フォルダの処理切り替えプログラム。
【請求項１１】
請求項８または９に記載のネットワーク・フォルダ・サーバを構成する各手段としてコンピュータを機能させるための注目フォルダの処理切り替えプログラム。
【請求項１２】
請求項１０または１１に記載の注目フォルダの処理切り替えプログラムを格納したことを特徴とするコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、注目フォルダの処理切り替え方法及びユーザ端末及びネットワーク・フォルダ・サーバ及びプログラム及びコンピュータ読み取り可能な記録媒体に係り、特に、ユーザ端末側とサーバ側において、利用者によって選択された注目フォルダを伝達する際に、サーバ側において利用者の注目フォルダに応じた処理の切り替えを行うための注目フォルダの処理切り替え方法及びユーザ端末及びネットワーク・フォルダ・サーバ及びプログラム及びコンピュータ読み取り可能な記録媒体に関する。
【背景技術】
【０００２】
＜第１の従来技術＞
以下では、従来技術におけるフォルダと注目フォルダについて説明する。
【０００３】
従来のフォルダを使ったフィル管理のイメージを図５に示す。同図では、注目フォルダ名上に処理対象ファイルをDROPする例を示している。例えば、ファイル名が「lena.jpg」である写真画像ファイルを、注目フォルダであるフォルダ名「faceImage」のフォルダにDRAG&DROP（以下、単に「DROP」と記す）すると、「faceImage」のフォルダの中に、「lena.jpg」が生成（厳密には移動と複写の場合が存在するが、いずれでも構わない）される（同図（１））。これを操作ケース"Ａ"とする。
【０００４】
同様に、図５の左側の木状のビュー上の注目するフォルダ「faceImage」に写真画像ファイル「lena.jpg」をDROPしても同様の結果が得られた（同図（２））。これを操作ケース"Ｂ"とする。
【０００５】
さらに、図６に示すように、左側の木状のビュー上で注目フォルダ「faceImage」を選択すると、そのフォルダの内容が右側に表示される。図６の例では、そこは空の状態である（同図（３））。
【０００６】
そこに、写真画像ファイル「lena.jpg」をDROPすると、これも前述の２つの操作ケースと同様の結果が得られる。これを操作ケース"Ｃ"とする。
【０００７】
このように従来はフォルダへのデータの投入という意味に対して、複数の異なる操作の見え方が存在した。
【０００８】
従来のデスクトップ上のフォルダの延長上のケースとして、ネットワーク上に存在するフォルダ（以下、「ネットワーク・フォルダ」と記す）に対する操作も存在する。
【０００９】
以下、説明の簡単化のためネットワーク・フォルダとして、httpの拡張であるWebＤＡＶで考える。しかし他にもNFS(Network file system)やsamba、CIFS(Common Internet File System)など、多様な実装が存在するが、直接もしくは間接的にhttpプロトコルに変換可能で、かつ、階層的なリソース管理を行えるネットワーク・フォルダであれば同様である。
【００１０】
ネットワーク・フォルダに対して、先の操作ケース"Ａ"，"Ｂ"，"Ｃ"で示したファイル投入操作は、図７に示すようなhttpプロトコル上のput操作となる。なお、本明細書では、ファイルを転送する仕組みとしてputを使って説明を行うが、ファイルを転送する別のプロトコル、例えば、httpのpostやmove、copyなどであっても同様である。この場合は、httpサーバのドキュメント格納のルートが「/」で、WebDAVでドキュメントを格納できる領域は「/uploads/」の下だという環境だと仮定すると、先の操作ケースＡ，Ｂ，Ｃはいずれも
users/akama/faceImage
の下に「lena.jpg」を生成するので、putメソッドとしては、
put  /uploads/users/akama/faceImage/lena.jpg
というパス情報を持つことになる。これを操作ケース"Ｄ"と呼ぶ。
【００１１】
操作ケース"Ｄ"は操作ケースＡ，Ｂ，Ｃと同一の意味を持つ。
【００１２】
ネットワーク・フォルダであるか否かについては、実は、httpサーバを自端末上で起動させるか否かの違いだけであるので、本質的な差にはならない。
【００１３】
従来この操作ケース"Ａ"，"Ｂ"，"Ｃ"，"Ｄ"の見え方の差異は、ファイルを生成するだけの処理に適用している場合には問題になることはなかった。
【００１４】
＜第２の従来の技術＞
以下では、従来技術における、POLDERの単純な使い方について説明する。
【００１５】
フォルダ名に処理を割り当てておき、ファイルをその注目フォルダにDROPした際に、その処理が起動され、その結果のファイルがフォルダ内に格納される。
【００１６】
具体的な例で示すと、図５の状態で、「faceImage」に「画像中の顔の部分の矩形画像を抽出する処理」が割り当てられていたとして、注目フォルダである「faceImage」に対して、顔を含む画像「lena.jpg」をDROPすると、「faceImage」フォルダ中に「lena.jpg」から顔部分だけを抽出した画像「lena_fa1.jpg」が生成されることになる。
【００１７】
これを操作ケース"Ｄ"に相当するネットワーク・フォルダで実現する場合には、putメソッドとしては、
put  /uploads/users/akama/faceImage/lena.jpg
というパス情報がユーザ端末からネットワーク・ホルダ・サーバに送られてくる。
【００１８】
POLDERでは、このパス情報を解析しい、処理対象ファイルは、「lena.jpg」、注目フォルダは「faceImage」と判断し、注目フォルダである「faceImage」に処理が割り当てられていなければ、単にファイルを生成するだけで終了し、「faceImage」に処理が割り当てられている（本ケース）の場合には、処理対象「lena.jpg」に対して、その処理を実行し、その結果を「faceImage」フォルダ内に生成する。
【００１９】
この場合においてもフォルダ名区切り文字「／」で区切ったパスの下から２番目（つまり、「faceImage」）を注目フォルダとして自動的に決定することが可能であるため、特に不都合は生じていなかった（例えば、特許文献１、非特許文献１参照）。
【００２０】
＜第３の従来技術＞
以下では、従来技術における、POLDERの高度な使い方及びフォルダをDROPする場合について説明する。
【００２１】
以下では、POLDERでより複雑な処理を実行するケースを考える。
【００２２】
例えば、「mergeImage2」に「フォルダとして渡された２つの写真ファイルを１枚の写真ファイルにまとめる処理」を割り当てたとする。さらに、図５においてネットワーク・フォルダとして「faceImage」と並列する階層で「margeImage2」というフォルダを生成し、ユーザ端末側では「lena.jpg」と「baby.jpg」という２つの写真ファイルを「abc」というフォルダにまとめて、それを注目フォルダの「mergeImage2」にDROPする場合を考える。
【００２３】
この処理を操作ケース"Ｄ"に相当するネットワーク・フォルダ・サーバにて実行する場合には、putメソッドとしては２つのhttpリクエストに分解される。
【００２４】
これは、httpプロトコルがステートレスであって、それぞれの通信で完結するためである。具体的には以下の２つのhttpリクエストがユーザ端末からネットワーク・フォルダ・サーバに送られる。
【００２５】
put  /uploads/users/akama/mergeImage2/abc/lena.jpg
put  /uploads/users/akama/mergeImage2/abc/baby.jpg
このとき、POLDERでの処理動作は以下のようになる。フォルダ「abc」に処理が割り当てられていないため、この上位の「mergeImage2」を注目フォルダとして決定し、
/uploads/users/akama/mergeImage2/abc/lena.jpg
が生成された時点では、「mergeImage2」は何も反応せず、単にファイルを生成するだけで終了し、
/uploads/users/akama/mergeImage2/abc/baby.jpg
が生成された時点で、ファイル数が２になるため、「lena.jpg」と「baby.jpg」の写真合成を行い、結果の写真画像ファイル「abc.jpg」を「mergeImage2」フォルダ内に生成し、フォルダ「abc」は削除する。この場合も大きな不都合は生じない。
【００２６】
＜第４の従来技術＞
次に、これまでの説明の延長上で問題が生じるケースを説明する。以下では、フォルダをDROPするケースで、DROPするフォルダ名が処理名である場合について説明する。
【００２７】
上記の第３の従来技術では、ネットワーク・フォルダ・サーバに渡すデータは、ユーザ端末側の「abc」というフォルダの中にまず格納し、ネットワーク・フォルダ・サーバに対しては、注目フォルダ「mergeImage2」に対して、フォルダ「abc」をDROPすることを行った。
【００２８】
ここで、ユーザ端末側で作ったフォルダ名が「abc」ではなく、処理が登録されている「faceImage」だったとする。POLDERにおいて、どのフォルダ名に処理が割り当てられているかの全容を端末利用者が正確に把握することは難しく、また動的に増加することもあり得るため、結果として、ユーザ端末側で作成するフォルダ名が、サーバ側では既に処理登録されているというバッティングが発生する可能性がある。
【００２９】
その場合、
put  /uploads/users/akama/mergeImage2/faceImage/lena.jpg
put  /uploads/users/akama/mergeImage2/faceImage/baby.jpg
という２つのhttpリクエストがユーザ端末からネットワーク・フォルダ・サーバに送られる。このとき、httpリクエストから注目フォルダが失われていることに起因する問題が発生する。POLDERでの処理動作は、最初のhttpリクエスト
put  /uploads/users/akama/mergeImage2/faceImage/lena.jpg
を受け取った際、以下の２つの解釈Ａ，Ｂが可能になる。
【００３０】
解釈Ａとして、
・処理対象：lena.jpg
・注目フォルダ：faceImage
として顔部分を抽出する処理を実行すべき。
【００３１】
解釈Ｂとして、
・処理対象：faceImage/lena.jpg
・注目フォルダ：mergeImage2
として、もう一つのhttpリクエストによって「faceImage/baby.jpg」が生成されるまで「mergeImage2」の処理は実行しない。「faceImage/baby.jpg」が生成された後に写真合成処理を行い、結果写真ファイル「faceImage.jpg」を作成するべき。
【００３２】
この２つの解釈のうち、従来の処理互換を優先すれば、解釈Ａとなり、「mergeImage2」は起動されず、「faceImage」が「lena.jpg」と「baby.jpg」に各々処理された複数の顔画像ファイルが生成されることになり、結果として注目フォルダ「mergeImage2」に対して処理対象フォルダをDROPしたというユーザの意図とは異なった動作になってしまう。
【００３３】
しかし、そもそも、この複数の解釈が存在し得るケースは、システム側の問題であって、端末側の利用者は、注目フォルダが「mergeImage2」で、投入フォルダが「faceImage」という操作ケースと、注目フォルダが「faceImage」で、投入フォルダが「lena.jpg」かつ、注目フォルダが「faceImage」で、投入フォルダが「baby.jpg」という操作ケースとは、明確に区別しているはずであり、注目フォルダを何らかの方法で端末側から、ネットワーク・フォルダ・サーバ側に伝え、サーバ側では利用者の意図に応じた処理の実行をする必要があった。
【００３４】
この課題に対して、ユーザ端末とサーバ間で、注目フォルダのパス情報をやり取りする独自のプロトコルを設けることで対処することも可能である。例えば、httpプロトコルを独自に拡張してしまうというアプローチである。しかし、この場合では、その拡張の妥当性やその拡張がユーザ端末とサーバの相互に与える影響と互換性の問題、及び、他のネットワーク・フォルダ・サーバ（sambaなど）との相互と接続性の問題、などが存在している。
【００３５】
また、上記の解釈の混乱を避けるため、POLDERでは、フォルダを投入したい場合には、ZIP等で圧縮して１つのファイルにまとめてから渡すことも提案している。しかし、いちいちZIPに圧縮してからファイルを転送することは、普段のフォルダ操作に対して１ステップ余分な処理が入ってしまい、特に初心者にとっては手間となり、利便性が低下するという問題がある。
【先行技術文献】
【特許文献】
【００３６】
【特許文献１】特開２００９−１９９５５号公報
【非特許文献】
【００３７】
【非特許文献１】赤間浩樹、内藤一兵衛、他、「フォルダ・プログラミング環境「POLDER」」、情報処理学会論文誌、Vol. 50, No. 9, pp. 1798-1809 (Aug. 2009)
【発明の概要】
【発明が解決しようとする課題】
【００３８】
上記のように、現在は、端末側とサーバ側で注目フォルダを転送する仕組みが存在せず、サーバ側において端末側利用者の注目フォルダに応じた処理の切り替えができないという問題があった。
【００３９】
本発明は、上記の点に鑑みなされたもので、従来の多様なネットワーク・フォルダのプロトコルにも対応可能で、かつ、従来の端末やサーバ側との互換性も維持しながら、注目フォルダに関する情報を伝達し、サーバ側にその注目フォルダに応じた処理の切り替えを可能にする注目フォルダの処理切り替え方法及び装置及びプログラム及びコンピュータ読み取り可能な記録媒体を提供することを目的とする。
【課題を解決するための手段】
【００４０】
図１は、本発明の原理を説明するための図である。
【００４１】
本発明（請求項１）は、複数のユーザ端末と、少なくとも１つ以上のセンタサーバと、それらをつなぐネットワークからなり、該センタサーバ内のネットワーク・フォルダ・サーバのストレージ上に任意のユーザ端末からDRAG&DROPされたファイルがそのまま、もしくは、処理を経た結果が蓄積されるシステムにおける注目フォルダの処理切り替え方法であって、
ユーザ端末において、
ユーザ端末からネットワーク・フォルダ・サーバ側のフォルダ（注目フォルダ）に対する該ユーザ端末側のフォルダ（処理対象フォルダ）のDROP処理である場合は、処理対象データを指定するパス情報に対して、該注目フォルダの直後のフォルダ名区切り文字を「フォルダ名区切り文字」、「基点フォルダ文字「．」（ピリオド）」、「フォルダ名区切り文字」からなる３文字に置換し（ステップ１）、該ネットワーク・フォルダ・サーバに送信する（ステップ２）置換ステップを行う。
【００４２】
また、本発明（請求項２）は、複数のユーザ端末と、少なくとも１つ以上のセンタサーバと、それらをつなぐネットワークからなり、該センタサーバ内のネットワーク・フォルダ・サーバのストレージ上に任意のユーザ端末からDRAG&DROPされたファイルがそのまま、もしくは、処理を経た結果が蓄積されるシステムのネットワーク・フォルダ・サーバにおける注目フォルダの処理切り替え方法であって、
ユーザ端末から受け付けたリクエストに含まれる処理対象データを指定するパス情報に対して、該パス情報内に「フォルダ名区切り文字」、「基点フォルダ文字「．」（ピリオド）」、「フォルダ名区切り文字」からなる３文字が存在するかを走査するパス情報走査ステップ（ステップ３）と、
存在すれば、「基点フォルダ文字「．」（ピリオド）」を含む３文字の直前までに記載されているフォルダを、ユーザ端末側の注目フォルダとして抽出し、該注目フォルダを用いる処理を実行する注目フォルダ抽出ステップ（ステップ４）と、を行う。
【００４３】
また、本発明（請求項３）は、請求項１または２の注目フォルダの処理切り替え方法における、「フォルダ名区切り文字」、「基点フォルダ文字「．」（ピリオド）」、「フォルダ名区切り文字」からなる３文字が、注目フォルダの直後には存在せず、注目フォルダの直前に存在するものとする。
【００４４】
また、本発明（請求項４）は、請求項１または２記載の注目フォルダの処理切り替え方法における、「フォルダ名区切り文字」、「基点フォルダ文字「．」（ピリオド）」、「フォルダ名区切り文字」からなる３文字の代わりに、「フォルダ名区切り文字」、「上位フォルダ文字列「..」」、「フォルダ名区切り文字」、「注目フォルダ名」、「フォルダ名区切り文字」からなる文字列とする。
【００４５】
また、本発明（請求項５）は、請求項1乃至４のいずれか1項に記載の注目フォルダの切り替え方法における「フォルダ名区切り文字」、「基点フォルダ文字「．」（ピリオド）」、「フォルダ名区切り文字」からなる３文字と共に、「フォルダ名区切り文字」、「上位フォルダ文字列「..」」、「フォルダ名区切り文字」、「注目フォルダ名」、「フォルダ名区切り文字」からなる文字列とを用いることで互換性を維持したまま注目フォルダに対する情報を付与するために、前記「基点フォルダ文字「．」（ピリオド）」を含む３文字と前記「上位フォルダ文字列「．．」」を含む文字列を、それぞれ２進法の「０」と「１」に対応させる。
【００４６】
図２は、本発明の原理構成図である。
【００４７】
本発明（請求項６）は、複数のユーザ端末２００と、少なくとも１つ以上のセンタサーバと、それらをつなぐネットワークからなり、該センタサーバ内のネットワーク・フォルダ・サーバ３１０のストレージ３０５上に任意のユーザ端末からDRAG&DROPされたファイルがそのまま、もしくは、処理を経た結果が蓄積されるシステムのユーザ端末であって、
当該ユーザ端末２００からネットワーク・フォルダ・サーバ３１０側のフォルダ（注目フォルダ）に対する該ユーザ端末側のフォルダ（処理対象フォルダ）のDROP処理である場合は、処理対象データを指定するパス情報に対して、
注目フォルダの直後のフォルダ名区切り文字を、「フォルダ名区切り文字」、「基点フォルダ文字「．」（ピリオド）」、「フォルダ名区切り文字」からなる３文字に置換する第１の置換手段と、
注目フォルダの直前のフォルダ名区切り文字を、「フォルダ名区切り文字」、「基点フォルダ文字「．」（ピリオド）」、「フォルダ名区切り文字」からなる３文字（に置換する第２の置換手段と、
注目フォルダの直後のフォルダ名区切り文字を、「フォルダ名区切り文字」、「上位フォルダ文字列「..」」、「フォルダ名区切り文字」、「注目フォルダ名」、「フォルダ名区切り文字」からなる文字列に置換する第３の置換手段の、３つの置換手段のうちのいずれか１つの置換手段２２０と、
置換手段２２０が置換したパス情報をネットワーク・フォルダ・サーバ３１０に送信する送信手段を有する。
また、本発明（請求項７）は、請求項６に記載のユーザ端末において、「基点フォルダ文字「．」（ピリオド）」を含む３文字と「上位フォルダ文字列「..」」を含む文字列を、それぞれ２進法の「０」と「１」に対応させる。
【００４８】
本発明（請求項８）は、複数のユーザ端末２００と、少なくとも１つ以上のセンタサーバと、それらをつなぐネットワークからなり、該センタサーバ内のネットワーク・フォルダ・サーバ３１０のストレージ３０５上に任意のユーザ端末からDRAG&DROPされたファイルがそのまま、もしくは、処理を経た結果が蓄積されるシステムのネットワーク・フォルダ・サーバで３１０あって、
ユーザ端末２００から受け付けたリクエストに含まれる処理対象データを指定するパス情報に対して、該パス情報内に、
「フォルダ名区切り文字」、「基点フォルダ文字「．」（ピリオド）」、「フォルダ名区切り文字」からなる３文字が存在するかを走査し、存在すれば、当該３文字の直前に記載されているフォルダを、ユーザ端末側の注目フォルダとして抽出する第１の注目フォルダ抽出手段と、
「フォルダ名区切り文字」、「基点フォルダ文字「．」（ピリオド）」、「フォルダ名区切り文字」からなる３文字が存在するかを走査し、存在すれば、当該３文字の直後に記載されているフォルダを、ユーザ端末側の注目フォルダとして抽出する第２の注目フォルダ抽出手段と、
「フォルダ名区切り文字」、「上位フォルダ文字列「..」」、「フォルダ名区切り文字」、「注目フォルダ名」、「フォルダ名区切り文字」からなる文字列が存在するかを走査し、存在すれば、当該「上位フォルダ文字列「..」」を含む文字列の直前に記載されているフォルダを、ユーザ端末側の注目フォルダとして抽出する第３の注目フォルダ抽出手段の、３つの注目フォルダ抽出手段のうちのいずれか１つの注目フォルダ抽出手段３０４と、
注目フォルダ抽出手段３０４が抽出した注目フォルダを用いる処理を実行する注目フォルダ実行手段と、を有する。
また、本発明（請求項９）は、請求項８のネットワーク・フォルダ・サーバにおいて、「基点フォルダ文字「．」（ピリオド）」を含む３文字と「上位フォルダ文字列「..」」を含む文字列を、それぞれ２進法の「０」と「１」に対応させる。
【００４９】
本発明（請求項１０）は、請求項６または７に記載のユーザ端末を構成する各手段としてコンピュータを機能させるための注目フォルダの処理切り替えプログラムである。
【００５０】
本発明（請求項１１）は、請求項８または９に記載のネットワーク・フォルダ・サーバを構成する各手段としてコンピュータを機能させるための注目フォルダの処理切り替えプログラムである。
【００５１】
本発明（請求項１２）は、請求項１０または１１に記載の注目フォルダの処理切り替えプログラムを格納したことを特徴とするコンピュータ読み取り可能な記録媒体である。
【発明の効果】
【００５２】
上記のように本発明によれば、POLDERのように、注目フォルダを利用する処理において、端末側利用者の注目フォルダの意図に適合したサーバ側の処理を提供することができる。
【００５３】
本発明は、従来のパス表現と互換性があるため、従来の端末に問題が生じず、また、注目フォルダを明示的に送信することに対応する新たな端末との共存が可能である。また、逆に、注目フォルダを明示的に送信する新たな端末が、その注目フォルダの検出処理に対応していないサーバにリクエストを送っても、問題が生じない。
【００５４】
つまり、サーバに応じて、ユーザ端末側の切り替え処理も不要になる。
【図面の簡単な説明】
【００５５】
【図１】本発明の原理を説明するための図である。
【図２】本発明の原理構成図である。
【図３】本発明の一実施の形態におけるシステム構成図である。
【図４】本発明の一実施の形態におけるユーザ端末とネットワーク・フォルダ・サーバの動作のフローチャートである。
【図５】第１の従来技術を説明するための図（注目フォルダ名上に処理対象ファイルをDROPするケース）である。
【図６】第１の従来技術を説明するための図（注目フォルダ内に処理対象ファイルをDROPするケース）である。
【図７】第１の従来技術を説明するための図（ネットワーク・フォルダ・サーバにファイルを送信するケース）である。
【発明を実施するための形態】
【００５６】
以下、図面と共に本発明の実施の形態を説明する。
【００５７】
図３は、本発明の一実施の形態におけるシステム構成を示す。
【００５８】
同図に示すシステムは、複数のユーザ端末２００と、少なくとも１つ以上のセンタのサーバ３００と、それらをつなぐインターネットやイントラネットなどのネットワーク１００から構成される。
【００５９】
ユーザ端末２００は、ユーザが選択されたフォルダについて注目フォルダに対するフォルダのDSROP操作であるかを判定するDROP判定部２１０、注目フォルダ名と処理対象フォルダ名の間の区切り文字「/」を所定の３文字「/./」に置換する置換処理部２２０、センタのサーバ３００との間でデータを送受信する送受信部２３０を有する。
【００６０】
センタのサーバ３００には、ネットワーク・フォルダ・サーバ３１０が動作している。ネットワーク・フォルダ・サーバ３１０は、ユーザ端末２００とデータの送受信を行う受付・応答部３０３、パス情報に所定の３文字「/./」が含まれているかを判定し、当該文字「/./」の直前までのパスを抽出し、注目フォルダをとして処理を実行するファイル管理部３０４、フォルダを蓄積するストレージ３０５を有する。
【００６１】
ネットワーク・フォルダ・サーバ３１０では、任意のユーザ端末２００からDRAG&DROPされたファイルがそのまま、もしくは、ファイル管理部３０４での処理を経た結果がセンタサーバ３００のストレージ（記憶手段）３０５に蓄積される。
【００６２】
図４は、本発明の一実施の形態におけるシステムの動作のフローチャートである。
【００６３】
ユーザ端末２００は、画面上でフォルダを選択し（ステップ１０１）ネットワーク・フォルダ・サーバ３１０に対して、ユーザ端末側のフォルダ（以下、「対象フォルダ」と記す）のDROP処理であった場合は（ステップ１０２、Ｙｅｓ）、処理対象データを指定するパス情報に対して、注目フォルダの直後のフォルダ名区切り文字（例えば、Linux（登録商標）なら"/"，Microsoft Windows（登録商標）なら"\"）を「フォルダ名区切り文字」、「基点フォルダ文字「．」（ピリオド）」、「フォルダ名区切り文字」と連なる３文字（例えば、「/./」に置換し（ステップ１０３）、http putリクエストをネットワーク・フォルダ・サーバ３１０に送信する（ステップ１０４）。また、ステップ１０２において、DROP処理でない場合は（ステップ１０２、Ｎｏ）、ステップ１０３の処理を行わずにhttp putリクエストをネットワーク・フォルダ・サーバ３１０に送信する（ステップ１０４）。
【００６４】
ネットワーク・フォルダ・サーバ３１０は、受付・応答部１００でユーザ端末２００からhttp putリクエストを受信し（ステップ２０１）、ファイル管理部３０４において、当該http putリクエストに含まれる処理対象データを指定するパス情報に対して、そのパス情報内に「フォルダ名区切り文字」、「基点フォルダ文字「．」（ピリオド）」、「フォルダ名区切り文字」と連なる３文字（例えば、「/./」が存在するかを走査し（ステップ２０２）、存在する場合は（ステップ２０２、Ｙｅｓ）、その直前までに記載されているフォルダを、ユーザ端末２００側の注目フォルダと解釈して抽出し（ステップ２０３）、その注目フォルダを使う処理を実行する（ステップ２０４）。また、ステップ２０２でパス情報内に「フォルダ名区切り文字」、「基点フォルダ文字「．」（ピリオド）」、「フォルダ名区切り文字」と連なる３文字（例えば、「/./」が存在しない場合は（ステップ２０２、Ｎｏ）、通常の処理を実行する（ステップ２０５）。受付・応答部１００は、実行したhttp putリクエストの応答をユーザ端末２００に送信する（ステップ２０６）。
【００６５】
ユーザ端末２００は、ネットワーク・フォルダ・サーバ３１０からの応答を受信し、表示装置（図示せず）に表示する（ステップ１０５）。
【００６６】
また、上記において、注目フォルダを「/./」の直後であるとして処理したが、直前として処理してもよい。
【００６７】
また、「フォルダ名区切り文字」、「基点フォルダ文字「．」（ピリオド）」、「フォルダ名区切り文字」と連なる３文字（例えば、「/./」）の代わりに、「フォルダ名区切り文字」、「上位フォルダ文字列「‥」」、「フォルダ名区切り文字」、「注目フォルダ名（例えば、「faceImage」）、「フォルダ名区切り文字」と連なる文字列（例えば、「/../faceImage/」）に変えてもよい。
【００６８】
また、本発明のシステム構成は、図３の構成に限定されることなく、ネットワーク・フォルダ・サーバのプロセスがローカル端末内に存在してもかまわない。
【００６９】
＜基本処理＞
以下に、上記の動作を図４のフローチャートに沿って具体的に説明する。
【００７０】
以下では、前述の第４の従来技術で示した課題に対して本発明で解決する流れを示す。
【００７１】
ユーザ端末２００上で注目フォルダ「mergeImage2」に対してフォルダ名が「faceImage」を送る操作ケースを考える。
【００７２】
その場合、
put  /update/users/akama/mergeImage2/faceImage/lena.jpg
put  /update/users/akama/mergeImage2/faceImage/baby.jpg
という２つのhttpリクエストは、ユーザ端末２００内で、
put   /uploads/users/akama/mergeImage2/./faceImage/lena.jpg
put   /uploads/users/akama/mergeImage2/./faceImage/baby.pg
と変換され（ステップ１０３）、ユーザ端末２００からネットワーク・フォルダ・サーバ３１０に送られる（ステップ１０４）。
【００７３】
このリクエストを受け取ったサーバ３１０は、
put   /uploads/users/akama/mergeImage2/./faceImage/lena.jpg
を受け取り、そのパス内に「/./」が含まれることを検出し（ステップ２０２）、その結果、POLDERエンジンは、注目フォルダを「mergeImage2」と把握して、注目フォルダ「mergeImage2」に割り当てられた処理を処理対象「faceImage/lena.jpg」に対して起動を試みる（ステップ２０３）。但し、この場合、ストレージ３０５の処理対象の「faceImage」フォルダ内にはまだファイルが１つしか存在しないため、特に「mergeImage2」固有の処理は実施されず、単にファイル「faceImage/lena.jpg」が生成され終了する。
【００７４】
次のリクエスト、
put   /uploads/users/akama/mergeImage2/./faceImage/lena.jpg
を受け取ると、同様に、そのパス内に「/./」が含まれることを検出し（ステップ２０２）、その結果、POLDERエンジンは、注目フォルダを「mergeImage2」と把握して（ステップ２０３）、注目フォルダ「mergeImage2」に割り当てられた処理を処理対象「faceImage/baby.jpg」に対して起動を試みる。
【００７５】
今度は、「faceImage」フォルダ内には２つのファイルが存在するため、「mergeImage2」の写真合成処理が「lena.jpg」と「baby.jpg」に対して行われ、結果として写真画像ファイル「faceImage.jpg」が「mergeImage2」フォルダ内に生成され、フォルダ「faceImage」は削除される（ステップ２０４）。
【００７６】
別の操作ケースとして、もし、ユーザ端末２００上で注目フォルダ「faceImage」に対してファイル名が「lena.jpg」をサーバ３１０に送った場合は、リクエスト中には「/./」が存在しないので、「faceImage」に割り当てられた処理を「lena.jpg」を対象に実行する。
【００７７】
put  /uploads/users/akama/mergeImage2/faceImage/lena.jpg
このように従来では解釈が曖昧だった処理を、本発明を利用することで端末側利用者の意図を明確に反映して処理を実行することが可能になる。
【００７８】
また、このPOLDERをWebDAVとは異なるネットワーク・フォルダ・サーバ、例えば、Samba上で利用する際にもパスを、
\\uploads\users\akama\mergeImage2\faceImage\lena.jpg
と
\\uploads\users\akama\mergeImage2\.\faceImage\lena.jpg
と、区別して利用することが可能になる。
【００７９】
また、SambaとWebDAVの両方に対応した端末ソフトウェア（例えば、Microsoft Windows Explorer（登録商標））では、統一的な対応が可能になる。
【００８０】
また、本方式が従来方式との互換性が高い方式であるため、サーバ側が請求項２，７に対応していないものであっても、ユーザ端末側はそれを意識することなく、リクエストのパス中に注目フォルダ情報を指定して送信して構わない。
【００８１】
受け取ったサーバ側は注目フォルダの指定「/./」の有無に関わらず、従来のパス表現として解釈し、当初予定の処理を実行することが可能である。
【００８２】
＜応用例＞
本発明のより高度な応用例として、
put  /uploads/users/akama/mergeImage2/faceImage/baby.jpg
に対して、
put  /uploads/users/akama/mergeImage2/./faceImage/baby.jpg
以外にも、
put  /uploads/users/akama/mergeImage2/././faceImage/baby.jpg
put  /uploads/users/akama/mergeImage2/./././faceImage/baby.jpg
などの変換を用いることで、注目フォルダに対して、更にその強弱やモードの状況を付与することも可能である。
【００８３】
更に高度な応用としては、「/./」と「/../mergeImage2/」の２種類を２進法のそれぞれ「０」と「１」に対応させて、例えば、
put  /uploads/users/akama/mergeImage2/././../mergeImage2/./faceImage/baby.jpg
を「００１０」と変換する処理を、図４のステップ１０３とステップ２０３に用意することで、注目フォルダに関して多様な情報を従来との互換性を維持したまま利用することが可能になる。
【００８４】
また、他の実施の形態として、ユーザ端末２００の機能をネットワーク・フォルダ・サーバ３１０側に設けることも可能である。
【００８５】
また、ネットワーク・フォルダ・サーバ３１０の機能をローカルな端末に設けることも可能である。
【００８６】
なお、上記の実施の形態では、POLDERでの利用例を中心に説明したが、注目フォルダを活用する他のサーバ側の処理にも利用することが可能であり、この情報を活用した多様なサービスが今後創出されることが期待できる。
【００８７】
なお、上記の実施の形態におけるユーザ端末２００及びネットワーク・フォルダ・サーバ３１０の動作をプログラムとして構築し、ユーザ端末、ネットワーク・フォルダ・サーバとして利用されるコンピュータにインストールして実行させる、または、ネットワークを介して流通させることが可能である。
【００８８】
また、構築されたプログラムをハードディスクや、フレキシブルディスク・ＣＤ−ＲＯＭ等の可搬記憶媒体に格納し、コンピュータにインストールする、または、配布することが可能である。
【００８９】
なお、本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において種々変更・応用が可能である。
【符号の説明】
【００９０】
１００  ネットワーク
２００  ユーザ端末
２１０  DROP判定部
２２０  置換処理部、置換手段
２３０  送受信部
３００  センタ・システム
３１０  ネットワーク・フォルダ・サーバ
３０３  受付・応答部
３０４  ファイル管理部
３０５  ストレージ
【図１】
0005552292.tif 000002
【図２】
0005552292.tif 000003
【図３】
0005552292.tif 000004
【図４】
0005552292.tif 000005
【図５】
0005552292.tif 000006
【図６】
0005552292.tif 000007
【図７】
0005552292.tif 000008