JP5420087B2 - ユニバーサルリソースロケータを含むメッセージを提供するための方法およびシステム - Google Patents

Description

本発明は、インターネット技術に関し、詳細には、短縮ユニフォームリソースロケータ(short Uniform Resource Locator)を使用してメッセージを提供するためのシステムおよび方法に関する。

ユニフォームリソースロケータ(URL)は、ウェブページアドレスとしてもまた知られており、インターネットにおけるウェブページのアドレスおよび他のリソースを完全に記述するために使用される識別方法である。

インターネット通信プロトコルRFC2616「Hypertext Transfer Protocol -HTTP/1.1」では、URLの長さについていかなる要件も設けていない。実際、URL長の制限は、クライアントブラウザの要件およびサーバサイドの設定という、2つの側面によって決定される。たとえば、Microsoft Internet Explorerは、URL長を2083バイト内に制限しているが、実際に使用することができる最大長は、2048バイトである。

現在、インターネットにおいては、メッセージ提示を提供するために使用される多くのサービスおよびアプリケーションが、メッセージ長を制限している。たとえば、受動的なメッセージのブロードキャスト機構としてのマイクロブログは、一般に、各メッセージ(すなわち、マイクロブログの記事)の長さを140文字に制限し、インスタントメッセージング(IM)システムは、一般に、各IMユーザの規定されたシグネチャの長さを50文字程度に制限し、いくつかのシステムのブロードキャストメッセージもまた、メッセージウィンドウサイズの制限として、メッセージコンテンツの長さについての要件を有する。長さについての制限を有するこれらのメッセージは、しばしばURLを含むことを必要とし、たとえば、ユーザは、最近目にしたオンライン記事を、自分のシグネチャ内、またはマイクロブログの記事内で紹介することがあり、その時、ユーザは、このオンライン記事のウェブページアドレス(以下ではURLと称する)を、自分のシグネチャまたはマイクロブログの記事に加える必要がある。URL長についていかなる制限もないために、最も一般的に使用されるURLの長さは、37文字から87文字の間であり、より長いURLを、制限された長さを有するメッセージ中に挿入するときには、URLが、制限されたメッセージ長のスペースを占めることになり、それにより、ユーザがテキストを入力するために使用する残りのスペースが不十分となり、メッセージ長が制限を超えてしまうことさえある。

以上を考慮して、本発明の態様は、制限された長さを有するメッセージに所望のURLを含ませ、同時に、メッセージにおいて所望のURLが占める長さを可能な限り短くする、URLを含むメッセージを提供するための方法を提供する。

本発明の態様はまた、制限された長さを有するメッセージに所望のURLを含ませ、同時に、メッセージにおいて所望のURLが占める長さを可能な限り短くする、URLを含むメッセージを提供するためのシステムを提供する。

本発明の態様は、ユニフォームリソースロケータ(URL)を含むメッセージを提供するための方法を提供し、方法は、
第1のURLが、ユーザによって入力されたメッセージ内のメッセージコンテンツに含まれているかどうかを検出するステップと、
第1のURLがメッセージコンテンツに含まれる場合に、第1のURLの長さとして第1の長さ値を取ることによって、メッセージの長さを計算するステップと、
メッセージの計算された長さが所定のメッセージ長を下回る場合に、ユーザがメッセージにメッセージコンテンツを追加し続けることを許可するステップと、
メッセージに含まれる第1のURLを、第1の長さ値を下回る、または第1の長さ値と同じ長さである第2のURLに置き換えるステップ、および第1のURLと第2のURLとの対応関係を保存するステップと、
第2のURLを含むメッセージを提供するステップと
を含む。

本発明の別の態様は、ユニフォームリソースロケータ(URL)を含むメッセージを提供するための方法を提供し、方法は、
メッセージに含まれる第1のURLを、第1のURLの長さを下回る長さである第2のURLに置き換えるステップ、および第1のURLと第2のURLとの対応関係を保存するステップと、
第2のURLを含むメッセージを提供するステップと、
要求元により送信された、第2のURLを含む要求を受信するステップ、および第1のURLと第2のURLとの保存された対応関係に従って、第1のURLを要求元に返すステップと
を含む。

本発明の別の態様は、ユニフォームリソースロケータ(URL)を含むメッセージを提供するためのシステムを提供し、システムは、
第1のURLが、ユーザによって入力されたメッセージ内のメッセージコンテンツに含まれているかどうかを検出し、第1のURLがメッセージコンテンツに含まれる場合に、第1のURLの長さとして第1の長さ値を用いることによって、メッセージの長さを計算し、メッセージの計算された長さが所定のメッセージ長を下回る場合に、ユーザがメッセージにメッセージコンテンツを追加し続けることを許可し、メッセージをサブミットするためにユーザによって送信された要求を受信するときに、第1のURLに対応した第2のURLをクエリモジュールから取得し、メッセージに含まれる第1のURLを第2のURLに置き換え、第2のURLを含むメッセージを提供するためのサービス処理モジュールであって、ここで、第2のURLの長さは、第1の長さ値を下回る、または第1の長さ値と同じ長さである、サービス処理モジュールと、
第1のURLに従って第2のURLを生成し、第1のURLと第2のURLとの対応関係を保存するための、クエリモジュールと
を含む。

本発明の別の態様は、ユニフォームリソースロケータ(URL)を含むメッセージを提供するためのシステムを提供し、システムは、
メッセージに含まれる第1のURLに対応した第2のURLをクエリモジュールから取得し、メッセージに含まれる第1のURLを、第1のURLの長さを下回る長さである第2のURLに置き換え、第2のURLを含むメッセージを提供するための、サービス処理モジュールと、
第1のURLに従って第2のURLを生成し、第1のURLと第2のURLとの対応関係を保存し、要求元により送信された、第2のURLを含む要求を受信し、第1のURLと第2のURLとの保存された対応関係に従って、第1のURLを要求元に返すための、クエリモジュールと
を含む。

URLを含むメッセージを提供するための本発明の態様の方法およびシステムは、メッセージ中のURLをより短縮URLに変換し、それにより、必要に応じてユーザまたはシステムによってメッセージ中に長いURLが挿入されるときに、メッセージ本文においてURLが占める長さを可能な限り短くすること、およびメッセージ長が長すぎないようにすることを、上記の技術的ソリューションから見ることができる。

本発明の実施形態に従った、URLを含むメッセージを提供するためのシステムの構造を示す概略図である。 本発明の実施形態に従った、URLを含むメッセージを提供するための方法を示す流れ図である。 本発明の実施形態に従った、クライアントの表示効果を示す概略図である。 本発明の実施形態に従った、URLを含むメッセージを提供するための方法を示す流れ図である。 本発明の実施形態に従った、URLを含むメッセージを提供するためのシステムの構造を示す概略図である。

本発明の実施形態技術的ソリューション、および利点をより明らかにするために、添付の図面および実施形態を参照して、本発明の実施形態を以下で詳細に説明する。

本発明の実施形態において、メッセージ中の第1のURLが、より短い第2のURLに置き換えられ、第1のURLと第2のURLとの対応関係が保存され、第2のURLが要求されたときに、第1のURLが、対応関係に従って取得され、要求元に返される。

本発明は、複数の実装を有することができるが、スペースに限りがあるため、本発明のソリューションは、以下に挙げるようないくつかの典型的な実施形態を参照して、この後詳細に説明される。当業者は、実際のニーズに応じてこれらの実施形態を変形させることができ、変形により取得された技術的ソリューションも、やはり本発明の保護範囲内にある。

実施形態１
図1は、本発明の実施形態に従った、URLを含むメッセージを提供するためのシステムの構造を示す概略図である。システムは、主に、サービス処理モジュール101と、クエリモジュール102と、クライアント103とを含む。サービス処理モジュール101は、主に、サービス論理を実施する、クライアント103に情報を提供する、クライアント103によって送信されたさまざまな要求に対処する、およびクエリモジュール102からURL情報を得るために使用される。クエリモジュール102は、主に、URLを変換する、記憶する、クエリするために使用される。上記のモジュールは、システムの機能に基づいた論理分割によって取得される。実際の実装において、各モジュールは、同じ物理デバイスによって達成されてもよく、または2つ以上の物理的エンティティに分散されてもよい。

図2に示すように、図2は、本発明の実施形態に従った、URLを含むメッセージを提供するための方法を示す流れ図である。本実施形態は、マイクロブログおよびユーザシグネチャのような応用シナリオなどの、制限された長さを有するメッセージにおいて、短縮URLが使用される状況に適用可能である。実施形態のあらゆるステップは、説明目的のみのために使用され、当業者は、実際のニーズに応じてこれらのステップの実行順序を調整する、あるステップを修正する、もしくは省略する、または特定の状況を狙いにしたいくつかのステップを追加することができる。以下の説明における単語「第1の」および「第2の」は、同じ名前を有する2つのオブジェクトを区別するためだけに使用され、それらの単語が実質的な重要性を有するわけではない。

URLを含むメッセージを提供するためのこの実施形態の方法は、主に、以下のステップを含む。

ステップ201、メッセージのためにユーザによって入力されたメッセージコンテンツが受信される。

ステップ202、第1のURLがメッセージコンテンツに含まれているかどうかが検出される。第1のURLがメッセージコンテンツに含まれる場合は、ステップ203が実施され、そうでない場合は、ステップ204が実施される。

ステップ203、第1のURLの長さとして第1の長さ値が取られる。ここで、第1の長さ値は、あらかじめ決められていてもよく、または第1のURLに従って実時間で計算されてもよい。

ステップ204、メッセージの現在の長さが計算される。

ステップ205、計算されたメッセージ長が所定のメッセージ長を満たすかどうかが判定され、計算されたメッセージ長が所定のメッセージ長よりも小さい場合、それはステップ201に戻され、それにより、ユーザはメッセージ中にメッセージコンテンツを追加し続けることができる。計算されたメッセージ長が所定のメッセージ長に達する場合、ステップ206が実施される。所定のメッセージ長は、最大メッセージ長についてシステムによって設定された制限値である。

ステップ206、ユーザからのサブミッション命令が受信され、メッセージに含まれる第1のURLが第2のURLに置き換えられ、第1のURLと第2のURLとの対応関係が保存され、第2のURLを含むメッセージが提供される。ここで、第2のURLの長さは、第1の長さ値よりも小さい、または第1の長さ値と同じである。

したがって、要求元によって送信された、第2のURLを含む要求が受信されるとき、第1のURLは、第1のURLと第2のURLとの保存された対応関係に従って、要求元に返される。

上記のステップは、図1に示すサービス処理モジュール101によって実行されてよい。ここで、ステップ206において、サービス処理モジュール101は、クエリモジュール102から、第1のURLに対応した第2のURLを取得する必要があり、一方、クエリモジュール102は、第1のURLと第2のURLとの対応関係を保存する必要がある。

ステップ206において、第2のURLを含むメッセージが提供されるということは、メッセージがシステムにおいてユーザに公開されること、またはメッセージが保存され、そのメッセージを要求したユーザに提供されることであってよい。このようにして、システムにおけるユーザのクライアントは、メッセージをユーザのために表示することができる。

他のユーザが、クライアントを通してこのメッセージをブラウズするとき、他のユーザは、メッセージ中の第2のURLに興味を持つことがある。したがって、システムはまた、第2のURLから、対応する第1のURLを正しく見つける必要があり、ユーザが第2のURLを通して、クエリし、第1のURLにアクセスすることを可能にする。クエリ機能およびアクセス機能を提供するシステムのプロセスは、それぞれ以下の通り説明される。

第2のユーザ(任意のユーザであってよい)が、クライアントに表示された第2のURLにマウスを動かすとき、クライアントは、第1のURLをクエリするための第2のURLを含むクエリ要求を送信することになる。クエリ要求を受信すると、サービス処理モジュール101は、第2のURLに対応した第1のURLをクエリモジュール102から取得し、第1のURLを表示するためにクライアントに提供する。第1のURLは、クライアントによってフローティングウィンドウに表示される、または他の形態において表示されてもよい。特定の表示方法は、本発明によって限定されない。

第2のユーザが、クライアントに表示された第2のURLをクリックする、または第2のURLを直接クライアントに入力して、第2のURLによって指し示されたウェブページにアクセスするよう要求するとき、クライアントは、第2のURLによって指し示されたネットワークデバイスに、第2のURLを含むアクセス要求を送信することになる。本発明の実施形態に従って、このネットワークデバイスは、システムにおけるウェブサーバであってよい。

アクセス要求を受信すると、ウェブサーバは、第2のURLを含むクエリ要求を、クエリモジュール102に送信することになる。クエリモジュール102は、第1のURLと第2のURLとの保存された対応関係に従って、第1のURLを取得し、第1のURLをウェブサーバに提供する。クエリモジュール102から第1のURLを取得した後、ウェブサーバは、第2のユーザのクライアントを、第1のURLによって指し示されたウェブページへとジャンプさせる、またはリダイレクトさせる。ジャンプする、またはリダイレクトする方法は、先行技術に属しており、ここでは繰り返さない。

このようにして、第2のURLを通して、第1のURLをクエリしてそれにアクセスする機能が、システムによって達成される。

本発明の実施形態に従って、ホスト名および接尾辞を含む一定のフォーマットが、第2のURLのために設定されてよい。ここで、ホスト名は、上記のウェブサーバなどの、システムにおけるデバイスを指してよく、すなわち、このデバイスのドメイン名がホスト名として設定される。異なる第2のURLが、これらの接尾辞によって互いに区別される。

上記の第2のURLは、特定のサービス要件に従って構成されていてよく、または第1のURLを処理するための適切なアルゴリズムを選択することによって取得されてもよい。以下の特定の実施形態は、第2のURLを生成するための方法を示すために挙げられ、当業者は、この実施形態に基づいた改良または簡略化を行って、実際のニーズに適応することができる。

本発明の実施形態において、クエリモジュール102は、第1のURLに一意のシリアル番号を割り当てることができ、接尾辞を生成するためにシリアル番号を符号化し、最後に、ホスト名および接尾辞に従って、第2のURLを生成する。

クエリモジュール102は、第1のURLと第2のURLとの対応関係を保存することができる、または、第1のURLと、第2のURLの接尾辞との対応関係のみを保存することができる。

接尾辞は、任意の数字、大文字、小文字、およびシンボルを含むことができる。接尾辞の長さは、固定でもあっても可変であってもよく、たとえば、1から10個のシンボルなどの長さ範囲を設定することができる。接尾辞の長さは、主に、シリアル番号の形態および符号化に使用される方法によって決まる。

固定長の接尾辞が使用されるとき、ステップ203で、第1の長さ値は、第2のURLの所定の長さであってよく、これは、ホスト名、すなわち上記のウェブサーバのドメイン名と、接尾辞の固定長とを計算することによって取得することができる。可変長の接尾辞が使用されるとき、ステップ203で、第1のURLを計算することによって第2のURLの接尾辞を取得する必要があり、次いで第2のURLの長さが、接尾辞を計算することによって取得され、次いで第1の長さ値として取られる、あるいは、接尾辞の最大長が第2のURLの接尾辞の長さとして取られ、第2のURLの長さが、この接尾辞の長さを計算することによって取得され、次いで第1の長さ値として取られる。

本発明の好ましい実施形態に従って、固定長の接尾辞が、システムの処理を簡略化し、効率性を向上させるために使用される。長整数型の32ビットデータまたは64ビットデータなどの長整数型のデータが、シリアル番号として使用されてよく、これらのシリアル番号は次に、受信されたメッセージ中の第1のURLに割り当てられる。次いで、第1のURLのシリアル番号が、ハッシュアルゴリズムまたはMD5アルゴリズムなどの一定のアルゴリズムを通して符号化されて、接尾辞を取得する。

上記は、第2のURLの接尾辞を生成するための、本発明の単なる一方法であり、第1のURLを直接符号化するなどの、他の方法がまた使用されてもよい。符号化アルゴリズムは、上記の2つのアルゴリズムのいずれにも限定されず、長いシーケンスを短くし、符号化された接尾辞にわずかしか繰り返しがないようにすることができる、他のアルゴリズムもまた使用することができる。

多くの場合、人気のあるコンテンツを含むいくつかのウェブページは、ある時間内に、ユーザのブログおよびシグネチャにおいて大勢のユーザによって参照されることになり、したがって、この実施形態は以下のように改善されてよい。第1のURLを含むURL変換要求を受信すると、クエリモジュール102は、最初に、第1のURLが保存されているか否かを判定することができ、第1のURLが既に保存されている場合、クエリモジュール102は、同じ第1のURLについて複数の異なる第2のURLを保存することを必要とすることなく、第1のURLと第2のURLとの対応関係に従って、第2のURLを取得することができる。したがって、システムリソースが節約され、効率性が向上し、システムが他のサービスを提供するために都合がよい。

たとえば、本発明の実施形態に従って、システムはまた、以下の情報のうちの少なくとも1つを記録することができる。
第2のURLが要求された回数であって、これは、第2のURLがクエリされた回数、または第2のURLがクリックされた回数などであってよい。
第2のURLが最後に要求された時間であって、これは、第2のURLが最後にクエリされた時間、または第2のURLが最後にアクセスされた時間などであってよい。
受信されたメッセージ内で第1のURLを含むメッセージの数、すなわち、第1のURLが異なるメッセージによって引用された回数。
第1のURLを含む、受信されたメッセージ内で最も新しいメッセージの入力時間、すなわち、第1のURLが最後に引用された時間。

第2のURLを含むクエリ要求がクライアントによって送信されると、システムは、クエリされた第1のURLと共に、上記の記録された情報をクライアントに提供することができ、クライアントは、任意の手段を使用して上記の情報をユーザに提供することができ、たとえば、上記の情報が、第1のURLが表示される同じ場所に同時に表示される。

上記の記録された情報に従って、システムはまた、第1のURLと第2のURLとの保存された対応関係を一掃し、更新することができる。たとえば、上記の記録された時間情報および/または回数情報に従って、第2のURLおよび/または第1のURLが古くなっているか否かが判定され、第2のURLおよび/または第1のURLが古くなっていると判定された場合、第1のURLと第2のURLとの保存された対応関係は削除され、この時、削除された第1のURLのシリアル番号は解除されて、今後において他のURLに割り当てることができる。

異なるURLにシリアル番号を割り当てることが可能なとき、その対象が元の第1のURLである要求が、間違って新しいURLに指し示されないよう保証するために、生成される接尾辞は、同一であってはならない。これは、いくつかの特殊な符号化またはアルゴリズムを使用することによって達成することができる。たとえば、それは、アウトオブオーダーアルゴリズム(out-of-order algorithm)を使用して、シリアル番号を処理し、次いで処理されたシリアル番号を符号化することができる。

本発明の別の実施形態に従って、セキュリティに基づいた制御ドメイン管理を実現するために、クライアントが第2のURLを含むクエリ要求を送信するとき、システムは、セキュリティセンターに第1のURLのセキュリティ情報をクエリして、次いでこのセキュリティ情報をクライアントに提供することができ、その後、セキュリティ情報は、クライアントによってユーザに表示される。セキュリティ情報は、テキストとして表示されても、またはアイコンとして表示されてもよい。セキュリティ情報は、第1のURLが、セキュアなリンクであること、危険性のある、または危険なリンクであることをプロンプトすることができる。セキュアなリンクでは、システムは、ユーザが第2のURLをクリックした後に自動的にジャンプすることができ、危険性のあるリンクでは、システムは、ユーザに手動でジャンプするようにプロンプトする、または構成を変更した後で自動的にジャンプすることができ、危険なリンクでは、システムは、ユーザが手動でジャンプしなければならないことをプロンプトすることができる。セキュリティドメイン制御機能は、先行技術に属し、その特定の実装はここでは繰り返さない。

図3は、本発明の実施形態に従った、クライアントの表示効果を示す概略図である。図3において、301は、メッセージ本文であり、302は、第2のURLであり、304は、メッセージの公開時間であり、308は、ユーザが302によって示される部分にマウスを動かすときに表示されるフローティングウィンドウであり、ここで303は、第1のURLであり、305は、第1のURLが異なるメッセージによって引用された回数であり、306は、第2のURLがクエリされた回数であり、307は、第1のURLのセキュリティ情報を反映するためのアイコンである。ここで、302によって示されるURLにおいて、「url.cn」は、ウェブサーバのホスト名であり、「Hr5N1」は、接尾辞である。

加えて、いくつかの引用されたURLがそれほど長くはないことを考慮に入れて、それにより、上記の実施形態を最適化することができる。たとえば、ステップ203または206において、最初に、第1のURLの長さが第1の長さ値を上回るかどうかを判定することができ、第1のURLの長さが、第1の長さ値または別の所定の閾値を下回る、またはそれと同じである場合、URLの置き換え動作は実施されないことになる。このようにして、システムは、その長さが一定の値を上回るURLのみ、または変換された後にその長さが著しく短くなるURLのみが置き換えられることを実現することができ、それにより、システムリソースが節約され、システム効率が向上する。

実施形態２
図4に示すように、図4は、本発明の実施形態に従った、URLを含むメッセージを提供するための方法を示す流れ図である。この実施形態は、マイクロブログおよびユーザシグネチャなどの応用シナリオに適用可能であり、とりわけ、システムが、制限された長さのブロードキャストメッセージまたはマルチキャストメッセージを公開する応用シナリオに適用可能である。

本実施形態のURLを含むメッセージを提供するための方法は、主に、以下のステップを含む。

ステップ401、メッセージに含まれる第1のURLが、第2のURLに置き換えられ、第1のURLと第2のURLとの対応関係が保存される。ここで、メッセージは、ユーザによって入力されたメッセージであっても、またはシステムによって生成された、公開されることになるメッセージであってもよい。第2のURLの長さは、第1のURLの長さを下回る。

ステップ402、第2のURLを含むメッセージが提供される。

ステップ403、要求元によって送信された、第2のURLを含む要求が受信される。要求元は、クライアントであっても、ウェブサーバであってもよい。

ステップ404、第1のURLと第2のURLとの保存された対応関係に従って、第1のURLが要求元に返される。

第1の実施形態では、メッセージがユーザによって編集された後でメッセージがサブミットされているときに、メッセージに含まれる第1のURLが、第2のURLに置き換えられる。第2の実施形態では、メッセージに含まれる第1のURLは、第1のURLが入力された後に第2のURLに置き換えられる。メッセージ長が制限されているときに、置き換えられたメッセージコンテンツに従ってメッセージ長を直接計算することができ、それにより、第1のURLの長さを、第1の実施形態で示された所定の長さ値に置き換えることを通して、メッセージ長を計算する必要がない。先行技術を使用することができる、システムのメッセージ長モニタリング機能を変更する必要がない。したがって、第2の実施形態は、第1の実施形態よりも単純である。

第2の実施形態の他のシステム機能およびプロセス、たとえば、第2のURLをクエリしてそれにアクセスすること、第2のURLの構造および生成方法、置き換えの前に第1のURLが保存されているか否かを判定すること、第1のURLを置き換える必要であるかどうかを判定すること、ならびに、第1のURLと第2のURLとの対応関係を更新し、維持することは、第1の実施形態のシステム機能およびプロセスと同様である。

この実施形態によって提供されるシステムは、図1に示す構造を使用することができる。

メッセージに含まれる第1のURLに対応した第2のURLをクエリモジュール102から取得し、メッセージに含まれる第1のURLを第2のURLに置き換え、第2のURLを含むメッセージを提供するように構成された、サービス処理モジュール101。ここで、第2のURLの長さは、第1のURLの長さを下回る。

第1のURLに従って第2のURLを生成し、第1のURLと第2のURLとの対応関係を保存し、要求元によって送信された、第2のURLを含む要求を受信し、第1のURLと第2のURLとの保存された対応関係に従って、第1のURLを要求元に返すように構成された、クエリモジュール102。

本発明の別の実施形態に従って、クエリモジュール102は、最初に、第1のURLが保存されているか否かを判定することができ、第1のURLが既に保存されている場合に、クエリモジュール102は、第1のURLと第2のURLとの対応関係に従って、第2のURLを取得することができる。

本発明の別の実施形態に従って、クエリモジュール102はまた、クライアント103によって送信された、第2のURLを含むクエリ要求を受信し、第1のURLと第2のURLとの対応関係に従って、第1のURLをクライアント103に返すことができる。

第1のURLに従って第2のURLが生成されるとき、クエリモジュール102は、第1のURLに一意のシリアル番号を割り当て、接尾辞を生成するためにシリアル番号を符号化し、次いでウェブサーバのホスト名および接尾辞を使用することによって、ウェブサーバを指し示す第2のURLを生成する。

システムはさらにウェブサーバを含むことができ、ウェブサーバは、第2のURLによって指し示されたウェブページにアクセスするために第2のユーザのクライアントによって送信されたアクセス要求を受信するとき、クエリモジュール102にクエリ要求を送信し、第2のURLに対応した第1のURLをクエリモジュール102から取得するように構成されており、それにより、第2のユーザのクライアントは、第1のURLによって指し示されたウェブページへとジャンプする、またはリダイレクトすることができる。

実施形態３
図5は、本発明のこの実施形態に従った、URLを含むメッセージを提供するためのシステムの構造を示す概略図である。システムは、以下のデバイスを含むことができる。

ユーザによって入力され、クライアント503によって送信されたメッセージコンテンツおよび要求(要求は、メッセージサブミッション要求、URLクエリ要求、およびURLアクセス要求などであってよい)を受信し、メッセージコンテンツおよびURLクエリ要求をURL変換サーバ502に提供し、URLアクセス要求をHTTPサーバ504に提供し、クライアント503とURL変換サーバ502との間、クライアント503とHTTPサーバ504との間で情報を転送し、ならびに、URL変換サーバ502とHTTPサーバ504との間で情報を転送するように構成された、インターフェースサーバ501。

クライアント503によって送信されたメッセージに含まれる第1のURLを第2のURLに置き換えるように構成されたURL変換サーバ502であって、ここで、URL変換サーバ502は、最初に、第1のURLが記憶サーバ506に保存されているかどうかを判定するようにクエリされてよく、第1のURLが既に存在する場合、URL変換サーバ502は、第1のURLに対応した第2のURLを記憶サーバ506から取得し、第1のURLがまだ存在しない場合、URL変換サーバ502は、第1のURLに従って第2のURLを生成し、第1のURLと第2のURLとの対応関係を記憶サーバ506に保存するように構成される。クエリモジュール102の記憶機能が記憶サーバ506を通して達成されることを除けば、URL変換サーバ502の機能は、図1に示したクエリモジュール102の機能と同様である。

インターフェースサーバ501を介してクライアント503によって送信された、第2のURLを含むアクセス要求を受信し、第2のURLに対応した第1のURLを、インターフェースサーバ501を介してURL変換サーバ502から取得して、クライアント503を、第1のURLへとジャンプさせる、またはリダイレクトさせるように構成された、HTTPサーバ504。

第1のURLと第2のURLとの対応関係を保存するように構成された、記憶サーバ506。本発明の別の実施形態に従って、記憶サーバ506はさらに、第1のURLおよび第2のURLの関連情報を記録するように構成されていてもよく、たとえば、関連情報は、第2のURLが要求された回数、第2のURLが最後に要求された時間、受信されたメッセージ内で第1のURLを含むメッセージの数、第1のURLを含む、受信されたメッセージ内で最も新しいメッセージの入力時間などである。

URL変換サーバ502およびHTTPサーバ504によって送信された、第1のURLのセキュリティ情報をクエリするための要求を受信し、第1のURLのセキュリティ情報をURL変換サーバ502およびHTTPサーバ504に提供するように構成された、セキュリティセンター505。

ユーザによって入力されたメッセージコンテンツおよびメッセージサブミッション要求を受信し、メッセージコンテンツおよびメッセージサブミッション要求をインターフェースサーバ501に送信し、URLクエリ要求およびURLアクセス要求をインターフェースサーバ501に送信し、インターフェースサーバ501によって送信された、第1のURL、第1のURLおよび第2のURLの関連情報、ならびに第1のURLのセキュリティ情報を受信し、表示するように構成された、クライアント503。

本発明のクライアント103および503は、ブラウザ、IMクライアント、またはマイクロブログクライアントなどであってよい。

本発明の実施形態によって提供される技術的ソリューションは、メッセージ中のURLをより短縮URLに変換し、それにより、必要に応じてユーザまたはシステムによってメッセージ中に長いURLが挿入されるときに、メッセージ本文においてURLが占める長さを可能な限り短くし、メッセージ長が長すぎないようにする。

以上は、本発明の単にいくつかの実施形態にすぎず、本発明の保護範囲を限定するために使用されるものではない。本発明の趣旨および原理のもとで作成された任意の変更例、均等例、改良例などは、すべて本発明の保護範囲に含まれる。

101 サービス処理モジュール
102 クエリモジュール
103 クライアント
301 メッセージ本文
302 第2のURL
303 第1のURL
304 メッセージの公開時間
305 第1のURLが異なるメッセージによって引用された回数
306 第2のURLがクエリされた回数
307 アイコン
308 フローティングウィンドウ
501 インターフェースサーバ
502 URL変換サーバ
503 クライアント
504 HTTPサーバ
505 セキュリティセンター
506 記憶サーバ

Claims (18)

1. ユニフォームリソースロケータ(URL)を含むメッセージを提供するための方法であって、
   第1のURLが、第1のユーザによって入力されたメッセージ内のメッセージコンテンツに含まれているかどうかを検出するステップと、
   前記第1のURLが前記メッセージコンテンツに含まれる場合に、前記第1のURLの長さとして第1の長さ値を用いることによって、前記メッセージの長さを計算するステップと、
   前記メッセージの計算された長さが所定のメッセージ長を下回る場合に、前記第1のユーザが前記メッセージにメッセージコンテンツを追加し続けることを許可するステップと、
   前記メッセージに含まれる前記第1のURLを、前記第1の長さ値を下回る、または前記第1の長さ値と同じ長さである第2のURLに置き換えるステップ、および前記第1のURLと前記第2のURLとの対応関係を保存するステップと、
   前記第2のURLを含む前記メッセージを提供するステップと
   を含む方法。
2. 要求元によって送信された、前記第2のURLを含む要求を受信するステップ、および前記第1のURLと前記第2のURLとの前記対応関係に従って、前記第1のURLを前記要求元に返すステップ
   をさらに含む請求項１に記載の方法。
3. 前記要求は、第2のユーザがクライアントに表示された前記第2のURLにマウスを動かすときに前記クライアントによって送信されたクエリ要求であり、前記要求元は、前記クライアントであり、
   前記方法は、
   前記クライアントが前記第1のURLを表示するステップ
   をさらに含む請求項２に記載の方法。
4. 前記第1のURLのセキュリティ情報をクエリするステップ、および前記セキュリティ情報を前記クライアントに提供するステップと、
   前記クライアントが前記セキュリティ情報を表示するステップと
   をさらに含む請求項３に記載の方法。
5. 前記第2のURLがウェブサーバを指し示し、前記要求は、前記ウェブサーバが、前記第2のURLによって指し示されたウェブページにアクセスするために第2のユーザのクライアントによって送信されたアクセス要求を受信するときに、前記ウェブサーバによって送信されたクエリ要求であり、前記要求元は、前記ウェブサーバであり、
   前記方法は、
   前記ウェブサーバが、前記第2のユーザの前記クライアントを、前記第1のURLによって指し示されたウェブページへとジャンプさせる、またはリダイレクトさせるステップ
   をさらに含む請求項２に記載の方法。
6. 前記第1のURLの長さが前記第1の長さ値を上回るかどうかを判定するステップをさらに含み、
   前記メッセージコンテンツに含まれる前記第1のURLを前記第2のURLに置き換える前記ステップ、および前記第1のURLと前記第2のURLとの前記対応関係を保存するステップが、
   前記第1のURLの長さが前記第1の長さ値を上回る場合に、前記メッセージコンテンツに含まれる前記第1のURLを前記第2のURLに置き換えるステップ、および前記第1のURLと前記第2のURLとの前記対応関係を保存するステップ
   を含む、
   請求項１に記載の方法。
7. 前記第2のURLが、ホスト名および接尾辞を含み、前記第1のURLと前記第2のURLとの前記対応関係が、前記第1のURLと前記接尾辞との対応関係である、請求項１、２、および６のいずれか一項に記載の方法。
8. 前記第1のURLに一意のシリアル番号を割り当てるステップと、
   前記接尾辞を生成するために前記シリアル番号を符号化するステップと、
   前記ホスト名および前記接尾辞に従って、前記第2のURLを生成するステップと
   をさらに含む請求項７に記載の方法。
9. 前記第1のURLが保存されているか否かを判定するステップと、
   前記第1のURLが既に保存されている場合に、前記第1のURLと前記第2のURLとの保存された対応関係に従って、前記第2のURLを取得するステップと
   をさらに含む請求項１に記載の方法。
10. 以下の情報、
    前記第2のURLが要求された回数、
    前記第2のURLが最後に要求された時間、
    受信されたメッセージ内で前記第1のURLを含むメッセージの数、および
    前記第1のURLを含む、前記受信されたメッセージ内で最も新しいメッセージの入力時間
    のうちの少なくとも1つを記録するステップ
    をさらに含む請求項１、２、および９のいずれか一項に記載の方法。
11. 以下の情報、
    前記第2のURLが要求された回数、
    前記第2のURLが最後に要求された時間、
    受信されたメッセージ内で前記第1のURLを含むメッセージの数、
    前記第1のURLを含む、前記受信されたメッセージ内で最も新しいメッセージの入力時間
    のうちの少なくとも1つを記録するステップと、
    前記クライアントが、クエリされた第2のURL、および前記第2のURLに対応した前記第1のURLに関連した記録された情報を表示するステップと
    をさらに含む請求項３に記載の方法。
12. 記録された情報に従って、前記第2のURLおよび/または前記第1のURLが古くなっているかどうかを判定するステップと、古くなっている場合に、前記第1のURLと前記第2のURLとの前記保存された対応関係を削除するステップと
    をさらに含む請求項１０に記載の方法。
13. 以下の情報、
    前記第2のURLが要求された回数、
    前記第2のURLが最後に要求された時間、
    受信されたメッセージ内で前記第1のURLを含むメッセージの数、
    前記第1のURLを含む、前記受信されたメッセージ内で最も新しいメッセージの入力時間
    のうちの少なくとも1つを記録するステップと、
    記録された情報に従って、前記第2のURLおよび/または前記第1のURLが古くなっているかどうかを判定するステップと、古くなっている場合に、前記第1のURLと前記第2のURLとの保存された対応関係を削除するステップ、および前記第1のURLの前記シリアル番号を第3のURLに割り当てるステップと
    をさらに含み、
    前記接尾辞を生成するために前記シリアル番号を符号化する前記ステップが、
    前記シリアル番号をアウトオブオーダーアルゴリズムにより処理するステップ、および処理されたシリアル番号を符号化するステップ
    を含む、
    請求項８に記載の方法。
14. 前記シリアル番号のデータ型が、長整数型であり、
    符号化する前記ステップが、ハッシュアルゴリズムまたはMD5アルゴリズムを採用する、
    請求項８または１３に記載の方法。
15. ユニフォームリソースロケータ(URL)を含むメッセージを提供するためのシステムであって、
    サービス処理モジュールは、第1のURLが、第1のユーザによって入力されたメッセージ内のメッセージコンテンツに含まれているかどうかを検出し、前記第1のURLが前記メッセージコンテンツに含まれる場合に、前記第1のURLの長さとして第1の長さ値を用いることによって、前記メッセージの長さを計算し、前記メッセージの計算された長さが所定のメッセージ長を下回る場合に、前記第1のユーザが前記メッセージにメッセージコンテンツを追加し続けることを許可し、前記メッセージをサブミットするために前記第1のユーザによって送信された要求を受信するときに、前記第1のURLに対応した第2のURLをクエリモジュールから取得し、前記メッセージに含まれる前記第1のURLを前記第2のURLに置き換え、前記第2のURLを含む前記メッセージを提供するためのものであり、ここで、前記第2のURLの長さは、前記第1の長さ値を下回る、または前記第1の長さ値と同じであり、
    前記クエリモジュールは、前記第1のURLに従って前記第2のURLを生成し、前記第1のURLと前記第2のURLとの対応関係を保存するためのものである、
    システム。
16. 前記クエリモジュールはさらに、前記第1のURLが前記クエリモジュールに保存されているかどうかを判定し、前記クエリモジュールが前記第1のURLを既に保存している場合に、前記第1のURLと前記第2のURLとの保存された対応関係に従って、前記第2のURLを取得するためのものである、請求項１５に記載のシステム。
17. 前記サービス処理モジュールはさらに、クライアントによって送信された、前記第2のURLを含むクエリ要求を受信し、前記第2のURLに対応した前記第1のURLを前記クエリモジュールから取得し、前記第1のURLを前記クライアントに返すためのものである、請求項１５に記載のシステム。
18. 前記クエリモジュールは、前記第1のURLに一意のシリアル番号を割り当て、接尾辞を生成するために前記シリアル番号を符号化し、ウェブサーバのホスト名および前記接尾辞を使用することによって、前記ウェブサーバを指し示す前記第2のURLを生成するためのものであり、
    前記ウェブサーバは、前記第2のURLによって指し示されたウェブページにアクセスするために第2のユーザのクライアントによって送信されたアクセス要求を受信するとき、前記第2のURLに対応した前記第1のURLを前記クエリモジュールから取得し、前記第2のユーザの前記クライアントを、前記第1のURLによって指し示されたウェブページへとジャンプさせる、またはリダイレクトさせるためのものである、
    請求項１５に記載のシステム。

Images