特許6033440 | 知財ポータル「IP Force」

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

▶ アリババ・グループ・ホールディング・リミテッドの特許一覧

特許6033440インスタントメッセージング通信先に対応する取引状況情報の決定

書誌要約請求の範囲詳細な説明課題実施例実施するための形態図面の説明

目に優しい文字サイズ小中大 PDF Top

< >

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6033440

(24)【登録日】2016年11月4日

(45)【発行日】2016年11月30日

(54)【発明の名称】インスタントメッセージング通信先に対応する取引状況情報の決定

(51)【国際特許分類】

G06Q 30/06 20120101AFI20161121BHJP

G06Q 50/10 20120101ALI20161121BHJP

【ＦＩ】

G06Q30/06 300

G06Q50/10

【請求項の数】20

【全頁数】35

(21)【出願番号】特願2015-526756(P2015-526756)

(86)(22)【出願日】2013年8月12日

(65)【公表番号】特表2015-528602(P2015-528602A)

(43)【公表日】2015年9月28日

(86)【国際出願番号】US2013054550

(87)【国際公開番号】WO2014028391

(87)【国際公開日】20140220

【審査請求日】2015年3月11日

(31)【優先権主張番号】13/963,823

(32)【優先日】2013年8月9日

(33)【優先権主張国】US

(31)【優先権主張番号】201210287697.6

(32)【優先日】2012年8月13日

(33)【優先権主張国】CN

(73)【特許権者】

【識別番号】510330264

【氏名又は名称】アリババ・グループ・ホールディング・リミテッド

【氏名又は名称原語表記】ＡＬＩＢＡＢＡＧＲＯＵＰＨＯＬＤＩＮＧＬＩＭＩＴＥＤ

(74)【代理人】

【識別番号】110000028

【氏名又は名称】特許業務法人明成国際特許事務所

(72)【発明者】

【氏名】ホゥ・コーァ

【審査官】梅岡信幸

(56)【参考文献】

【文献】特開２００２−０８３２４７（ＪＰ，Ａ）

【文献】登録実用新案第３１７３４５１（ＪＰ，Ｕ）

【文献】特開２００３−０４４７００（ＪＰ，Ａ）

【文献】特開２００９−２１１５８３（ＪＰ，Ａ）

【文献】特開２００５−１３５３９４（ＪＰ，Ａ）

【文献】特開２００８−３０５３９６（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｑ１０／００−９９／００

(57)【特許請求の範囲】

【請求項1】

システムであって、
１または複数のプロセッサであって、
インスタントメッセージングクライアントに関連付けられている通信先と前記インスタントメッセージングクライアントに関連付けられているユーザとの間にインスタントメッセージングセッションが確立されたことの表示を受信し、
前記表示の受信に応じて、前記インスタントメッセージングクライアントに関連付けられているユーザに関し、前記通信先に対応する取引状況情報クエリ要求を自動的に送信し、前記取引状況情報クエリ要求は、前記通信先および前記インスタントメッセージングクライアントに関連付けられている前記ユーザに関連付けられている識別情報を含み、
前記通信先に対応する前記取引状況情報クエリ要求に少なくとも部分的に基づいて決定された、注文の履行過程における現在の段階を記述する取引状況情報を受信するよう構成されている、１または複数のプロセッサと、
前記１または複数のプロセッサに接続され、前記１または複数のプロセッサに命令を提供するよう構成されている１または複数のメモリと、
を備える、システム。

【請求項2】

請求項１に記載のシステムであって、前記インスタントメッセージングクライアントに関連付けられている前記ユーザは、販売者ユーザを含む、システム。

【請求項3】

請求項１に記載のシステムであって、前記通信先は、購入者ユーザを含む、システム。

【請求項4】

請求項１に記載のシステムであって、前記受信された取引状況情報は、前記インスタントメッセージングクライアントに関連付けられている前記ユーザによって販売されている商品について前記通信先によってなされた前記注文に関連付けられている前記履行過程に関する前記現在の段階を記述する、システム。

【請求項5】

請求項１に記載のシステムであって、前記受信された取引状況情報は、注文済、支払済、発送済、配達確認済、購入者ユーザによる評価済、および、両関係者による評価済の内の１つを示す、システム。

【請求項6】

請求項１に記載のシステムであって、前記取引状況情報クエリ要求は、取引サーバに送信され、前記受信された取引状況情報は、前記取引サーバに関連付けられている取引状況データベースにクエリするよう構成されている前記取引サーバによって決定される、システム。

【請求項7】

請求項１に記載のシステムであって、前記取引状況情報クエリ要求は、インスタントメッセージングサーバに送信され、前記受信された取引状況情報は、前記インスタントメッセージングサーバに関連付けられている取引状況データベースにクエリするよう構成されている前記インスタントメッセージングサーバによって決定される、システム。

【請求項8】

請求項１に記載のシステムであって、前記取引状況情報クエリ要求は、インスタントメッセージングサーバに送信され、前記受信された取引状況情報は、取引サーバに関連付けられている取引状況データベースにクエリするよう構成されている前記取引サーバに前記取引状況情報クエリ要求を転送するよう構成されている前記インスタントメッセージングサーバによって決定される、システム。

【請求項9】

請求項１に記載のシステムであって、前記１または複数のプロセッサは、さらに、前記通信先に対応する前記受信された取引状況情報を前記インスタントメッセージングクライアントに関連付けられているインスタントメッセージングウィンドウに表示するよう構成されている、システム。

【請求項10】

請求項９に記載のシステムであって、前記通信先に対応する前記受信された取引状況情報の表示は、前記受信された取引状況情報に関連付けられている優先順位に少なくとも部分的に基づく、システム。

【請求項11】

請求項９に記載のシステムであって、前記１または複数のプロセッサは、さらに、前記受信された取引状況情報に少なくとも部分的に基づいて、複数の通信先の表示内での前記通信先に関連付けられている順位を決定するよう構成されている、システム。

【請求項12】

請求項１に記載のシステムであって、前記１または複数のプロセッサは、さらに、
複数の通信先のそれぞれに対応する複数の取引状況情報クエリ要求をクエリキュー内に格納し、
前記クエリキュー内での前記複数の取引状況情報クエリ要求に関連付けられている順序に少なくとも部分的に基づいて、前記複数の取引状況情報クエリ要求から、前記複数の取引状況情報クエリ要求の内の１または複数を送信し、
前記１または複数の取引状況情報クエリ要求に少なくとも部分的に基づいて決定された取引状況情報を受信するよう構成されている、システム。

【請求項13】

請求項１に記載のシステムであって、前記取引状況情報クエリ要求は、第１の取引状況情報クエリ要求を含み、前記１または複数のプロセッサは、さらに、
前記インスタントメッセージングクライアントをインスタントメッセージングサーバに再接続するための指示を受信し、
選択された通信先に対応する第２の取引状況情報クエリ要求を再送信するための選択を受信し、
前記選択された通信先に対応する前記第２の取引状況情報クエリ要求を再送信するよう構成されている、システム。

【請求項14】

方法であって、
インスタントメッセージングクライアントに関連付けられている通信先と前記インスタントメッセージングクライアントに関連付けられているユーザとの間にインスタントメッセージングセッションが確立されたことの表示を受信し、
前記表示の受信に応じて、前記インスタントメッセージングクライアントに関連付けられているユーザに関し、前記通信先に対応する取引状況情報クエリ要求を自動的に送信し、前記取引状況情報クエリ要求は、前記通信先および前記インスタントメッセージングクライアントに関連付けられている前記ユーザに関連付けられている識別情報を含み、
前記通信先に対応する前記取引状況情報クエリ要求に少なくとも部分的に基づいて決定された、注文の履行過程における現在の段階を記述する取引状況情報を受信すること、
を備える、方法。

【請求項15】

請求項１４に記載の方法であって、さらに、
複数の通信先のそれぞれに対応する複数の取引状況情報クエリ要求をクエリキュー内に格納し、
前記クエリキュー内での前記複数の取引状況情報クエリ要求に関連付けられている順序に少なくとも部分的に基づいて、前記複数の取引状況情報クエリ要求から、前記複数の取引状況情報クエリ要求の内の１または複数を送信し、
前記１または複数の取引状況情報クエリ要求に少なくとも部分的に基づいて決定された取引状況情報を受信すること、
を備える、方法。

【請求項16】

請求項１４に記載の方法であって、前記取引状況情報クエリ要求は、第１の取引状況情報クエリ要求を含み、前記方法は、さらに、
前記インスタントメッセージングクライアントをインスタントメッセージングサーバに再接続するための指示を受信し、
選択された通信先に対応する第２の取引状況情報クエリ要求を再送信するための選択を受信し、
前記選択された通信先に対応する前記第２の取引状況情報クエリ要求を再送信すること、
を備える、方法。

【請求項17】

システムであって、
１または複数のプロセッサであって、
インスタントメッセージングクライアントによって送信された通信先に対応する取引状況情報クエリ要求を受信し、前記取引状況情報クエリ要求は、前記通信先に関係するユーザに関連付けられ、前記ユーザは、前記インスタントメッセージングクライアントに関連付けられ、前記取引状況情報クエリ要求は、前記通信先と前記インスタントメッセージングクライアントに関連付けられている前記ユーザとの間にインスタントメッセージングセッションが確立されたことの表示の受信に応じて自動的に送信され、
取引状況データベースにクエリすることに少なくとも部分的に基づいて、前記通信先に対応する取引状況情報を決定し、前記取引状況情報は、注文の履行過程における現在の段階を記述し、
前記通信先に対応する前記取引状況情報を前記インスタントメッセージングクライアントに送信するよう構成されている、１または複数のプロセッサと、
前記１または複数のプロセッサに接続され、前記１または複数のプロセッサに命令を提供するよう構成されている１または複数のメモリと、
を備える、システム。

【請求項18】

請求項１７に記載のシステムであって、前記取引状況情報クエリ要求は、インスタントメッセージングサーバで受信される、システム。

【請求項19】

請求項１８に記載のシステムであって、前記インスタントメッセージングサーバは、前記取引状況データベースにクエリするよう構成されている、システム。

【請求項20】

請求項１７に記載のシステムであって、前記通信先に対応する前記取引状況情報を決定することは、前記取引状況データベースにクエリするよう構成された取引サーバに前記取引状況情報クエリ要求を転送することを含む、システム。

【発明の詳細な説明】

【技術分野】

【0001】

他の出願の相互参照
本願は、すべての目的のために参照により本明細書に組み込まれる、発明の名称を「ＩＮＳＴＡＮＴＭＥＳＳＡＧＩＮＧＣＬＩＥＮＴ，ＩＮＳＴＡＮＴＭＥＳＳＡＧＩＮＧＳＥＲＶＥＲＡＮＤＩＮＳＴＡＮＴＭＥＳＳＡＧＩＮＧＭＥＴＨＯＤ」とする、２０１２年８月１３日出願の中国特許出願第２０１２１０２８７６９７．６号に基づく優先権を主張する。

【0002】

本願は、インスタントメッセージング技術の分野に関し、特に、インスタントメッセージングクライアントを用いて取引状況情報を表示する技術に関する。

【背景技術】

【0003】

インスタントメッセージング（「ＩＭ」とも呼ばれる）技術は、しばしば、電子商取引（ｅコマース）の用途で用いられる。インスタントメッセージング技術は、チャットおよびファイル転送ツールとしての以前の役割から電子商取引に必須の通信ツールへと次第に拡張されてきた。例えば、電子商取引ウェブサイトで、販売者ユーザは、自身が販売している商品の商品情報をウェブサイトに提出し、購入者ユーザは、かかる商品を購入する選択をしうる。販売者ユーザおよび購入者ユーザは、電子商取引ウェブサイトに関連付けられているインスタントメッセージングクライアントアプリケーションを介して互いに通信できるように、かかるクライアントアプリケーションをそれぞれダウンロードしてインストールしうる。例えば、購入者ユーザは、販売者ユーザが販売している商品に関して質問するために、購入者ユーザのデバイスにインストールされたインスタントメッセージングクライアントアプリケーションを介して販売者ユーザとチャットすることができる。

【0004】

オンライン取引の数が増えるにつれて、取引を行っている各購入者ユーザの取引状況情報を手動で追跡することが、販売者ユーザにとってますます困難になっている。購入者ユーザとよりよいコミュニケーションを取るために、販売者ユーザが現在インスタントメッセージングサービスでチャットしている購入者ユーザの取引状況情報を知っていることが、一般に販売者ユーザによって利点がある。取引（または、注文）についてのこの取引状況情報は、注文の履行が進むにつれて絶えず変化する。例えば、取引注文は、以下の内の１または複数に基づいて特定されうる。販売者ユーザＩＤ、購入者ユーザＩＤ、商品情報、および、注文コード。取引状況情報は、以下の段階の例を通して進みうる。注文済→支払済→発送済→配達確認済→評価済、など。注文が処理されていくにつれて、注文に関連付けられている取引状況情報は、電子商取引ウェブサイトの取引サーバで経時的に更新される。

【0005】

通例、販売者ユーザが特定の注文に関する取引状況情報を知りたい場合、販売者ユーザは、電子商取引ウェブサイトに対応する取引サーバのウェブサイト（または、他のウェブベースのポータル）にログオンして、注文の現在の取引状況情報のためのクエリを送信しなければならない。したがって、販売者ユーザは、インスタントメッセージングアプリケーション上で関係のある（例えば、通信している）購入者ユーザに関連付けられている注文について現在の取引状況情報を決定するために、インスタントメッセージングアプリケーションと取引サーバのウェブサイトとを同時に利用するか、または、それらを頻繁に切り替える必要がある。販売者ユーザが販売促進活動を行っているために、同時または短い時間内に多数の購入者ユーザと通信している場合、特に当てはまる。インスタントメッセージングアプリケーションと取引サーバに関連付けられているウェブサイトとの間で利用を切り替えることは、取引サーバおよびインスタントメッセージングサーバの両方への訪問負荷を増やすだけでなく、販売者ユーザの作業効率も大きく低下させる。特に、取引サーバが過剰な訪問負荷により迅速に応答できない時、販売者ユーザは、取引状況情報を迅速に取得することも、その後にかかる取引状況情報を購入者ユーザに返すこともできない。これは、ユーザにとってインスタントメッセージングの効率を下げるだけでなく、ユーザ体験も低下させる。

【図面の簡単な説明】

【0006】

以下の詳細な説明と添付の図面において、本発明の様々な実施形態を開示する。

【0007】

【図1】取引状況情報を決定するためのシステムの図。

【0008】

【図2】取引状況情報を決定するための処理の一実施形態を示すフローチャート。

【0009】

【図3】取引状況情報を決定するための処理の一実施形態を示すフローチャート。

【0010】

【図4】取引状況情報を決定するための処理の一実施形態を示すフローチャート。

【0011】

【図5】取引状況情報を決定するための処理の一実施形態を示すフローチャート。

【0012】

【図6】インスタントメッセージングクライアントによって様々な通信先に対応する取引状況情報を表示する第１の実施形態を示す図。

【0013】

【図7】インスタントメッセージングクライアントによって様々な通信先に対応する取引状況情報を表示する第２の実施形態を示す図。

【0014】

【図8】インスタントメッセージングクライアントによって様々な通信先に対応する取引状況情報を表示する第３の実施形態を示す図。

【0015】

【図9】注文履行過程の様々な段階に対して表示されるアイコンの図。

【0016】

【図10】取引状況情報を決定するための処理の一実施形態を示すフローチャート。

【0017】

【図11】取引状況情報を決定するための処理の一実施形態を示すフローチャート。

【0018】

【図12】取引状況情報を決定するための処理の一実施形態を示すフローチャート。

【0019】

【図13】取引状況情報を決定するための処理の一実施形態を示すフローチャート。

【0020】

【図14】インスタントメッセージングクライアントのためのシステムを示す図。

【0021】

【図15】インスタントメッセージングクライアントのためのシステムを示す図。

【発明を実施するための形態】

【0022】

本発明は、処理、装置、システム、物質の組成、コンピュータ読み取り可能な格納媒体上に具現化されたコンピュータプログラム製品、および／または、プロセッサ（プロセッサに接続されたメモリに格納および／またはそのメモリによって提供される命令を実行するよう構成されたプロセッサ）を含め、様々な形態で実装されうる。本明細書では、これらの実装または本発明が取りうる任意の他の形態を、技術と呼ぶ。一般に、開示された処理の工程の順序は、本発明の範囲内で変更されてもよい。特に言及しない限り、タスクを実行するよう構成されるものとして記載されたプロセッサまたはメモリなどの構成要素は、ある時間にタスクを実行するよう一時的に構成された一般的な構成要素として、または、タスクを実行するよう製造された特定の構成要素として実装されてよい。本明細書では、「プロセッサ」という用語は、１または複数のデバイス、回路、および／または、コンピュータプログラム命令などのデータを処理するよう構成された処理コアを指すものとする。

【0023】

以下では、本発明の原理を示す図面を参照しつつ、本発明の１または複数の実施形態の詳細な説明を行う。本発明は、かかる実施形態に関連して説明されているが、どの実施形態にも限定されない。本発明の範囲は、特許請求の範囲によってのみ限定されるものであり、多くの代替物、変形物、および、等価物を含む。以下の説明では、本発明の完全な理解を提供するために、多くの具体的な詳細事項が記載されている。これらの詳細事項は、例示を目的としたものであり、本発明は、これらの具体的な詳細事項の一部または全てがなくとも特許請求の範囲に従って実施可能である。簡単のために、本発明に関連する技術分野で周知の技術要素については、本発明が必要以上にわかりにくくならないように、詳細には説明していない。

【0024】

販売者ユーザおよび購入者ユーザの間の通信ならびに取引状況情報の生成は共に、オンライン取引の重要な要素である。通例、販売者ユーザが、購入者ユーザとの通信および購入者ユーザによる様々な注文の取引状況情報に関連付けられているクエリに利用できるポータルは２つある。第１のポータルは、インスタントメッセージングサーバを介するものであり、第２のポータルは取引サーバを介するものである。インスタントメッセージングサーバは、主に、インスタントメッセージングサービスの提供に関係しており、取引サーバは、主に、１または複数の電子商取引ウェブサイトで実行された取引（または、なされた注文）の状況情報の追跡に関係している。したがって、典型的なオンライン取引処理では、しばしば、販売者ユーザが、インスタントメッセージングクライアントの利用を、インスタントメッセージングサーバにアクセスする利用と１または複数の購入者ユーザに対応する現在の取引状況情報を取引サーバにクエリする利用との間で頻繁に切り替える必要がある。販売者ユーザにインスタントメッセージングサーバおよび取引サーバの間で頻繁に切り替えさせることは、インスタントメッセージングサーバおよび取引サーバの両方への訪問負荷を増大させるだけでなく、インスタントメッセージングの効率を低下させる。

【0025】

インスタントメッセージング通信先（ｃｏｎｔａｃｔｐｅｒｓｏｎ）に対応する取引状況情報の決定の実施形態を本明細書に記載する。様々な実施形態において、取引状況情報は、電子商取引ウェブサイトで購入者ユーザによってなされた販売者ユーザへの注文履行過程における現在の段階を記述する。販売者ユーザは、販売者ユーザが用いるクライアントデバイスで実行されるインスタントメッセージングクライアントを用いて、１または複数の販売者ユーザと通信しうる。いくつかの実施形態において、インスタントメッセージングクライアントは、インスタントメッセージングアプリケーションを備える。販売者ユーザとのインスタントメッセージングセッションを確立した１または複数の購入者ユーザ（例えば、販売者ユーザと接続されている購入者ユーザ）が、インスタントメッセージングクライアントの通信先リストに通信先として現れる。様々な実施形態において、インスタントメッセージングクライアントは、接続中の各通信先（例えば、購入者ユーザ）に対応する取引状況情報クエリ要求を自動的に送信するよう構成される。いくつかの実施形態において、インスタントメッセージングクライアントは、取引状況情報クエリ要求を取引サーバに送信する。いくつかの実施形態において、インスタントメッセージングクライアントは、取引状況情報クエリ要求をインスタントメッセージングサーバに送信する。様々な実施形態において、インスタントメッセージングクライアントは、各通信先に対応する現在の取引状況情報を取引サーバまたはインスタントメッセージングサーバのいずれかから受信する。様々な実施形態において、インスタントメッセージングクライアントは、販売者ユーザが、接続中の通信先に関連付けられている取引状況を容易に知ることができるように、インスタントメッセージングクライアントに関連付けられているインスタントメッセージングウィンドウ内に、通信先に対応する受信済みの取引状況情報を表示するよう構成される。

【0026】

図１は、取引状況情報を決定するためのシステムの図である。この例において、システム１００は、クライアントデバイス１０２、クライアントデバイス１０４、クライアントデバイス１０６、ネットワーク１０８、インスタントメッセージングサーバ１１０、取引状況データベース１１４、取引サーバ１１２、および、取引状況データベース１１６を備える。ネットワーク１０８は、高速データネットワークおよび／または遠隔通信ネットワークを含む。

【0027】

クライアントデバイス１０２、クライアントデバイス１０４、および、クライアントデバイス１０６の各々は、インスタントメッセージングサーバ１１０および／または取引サーバ１１２と通信するよう構成されている。インスタントメッセージングクライアントが、クライアントデバイス１０２、クライアントデバイス１０４、および、クライアントデバイス１０６の各々で実行されている。インスタントメッセージングクライアントは、クライアントデバイス１０２、クライアントデバイス１０４、および、クライアントデバイス１０６の各々が、インスタントメッセージングサーバによって提供されるインスタントメッセージングサービスを用いることを可能にする。クライアントデバイス１０２、クライアントデバイス１０４、および、クライアントデバイス１０６は各々、ラップトップコンピュータとして図示されているが、クライアントデバイス１０２、クライアントデバイス１０４、および、クライアントデバイス１０６のその他の例としては、デスクトップコンピュータ、携帯デバイス、タブレットデバイス、スマートフォン、および／または、任意のその他のコンピュータデバイスが挙げられる。クライアントデバイス１０２、クライアントデバイス１０４、および、クライアントデバイス１０６の各々は、ユーザが文字を入力しうる入力インターフェース（例えば、物理キーボードまたはタッチスクリーン）と、情報をユーザに表示しうるディスプレイインターフェースとを備える。

【0028】

この例において、販売者ユーザがクライアントデバイス１０２のインスタントメッセージングクライアントを利用しており、異なる購入者ユーザがクライアントデバイス１０４およびクライアントデバイス１０６の各々のインスタントメッセージングクライアントを利用していると仮定する。クライアントデバイス１０４およびクライアントデバイス１０６のインスタントメッセージングクライアントを利用する購入者ユーザは、販売者ユーザによって販売されている商品に関心を持つようになり、したがって、クライアントデバイス１０２の販売者ユーザとのインスタントメッセージングセッションを開始する。したがって、２人の購入者ユーザは各々、クライアントデバイス１０２で実行される販売者ユーザのインスタントメッセージングクライアントで販売者ユーザと接続されている通信先になる。クライアントデバイス１０２で実行されるインスタントメッセージングクライアントは、クライアントデバイス１０４に関連付けられている購入者ユーザに対応する第１の取引状況情報クエリ要求およびクライアントデバイス１０６に関連付けられている購入者ユーザに対応する第２の取引状況情報クエリ要求を送信するよう構成されている。

【0029】

いくつかの実施形態において、クライアントデバイス１０２で実行されるインスタントメッセージングクライアントは、取引状況情報クエリ要求を取引サーバ１１２に送信するよう構成されている。取引サーバ１１２は、取引サーバ１１２によって維持される取引状況データベース１１６内の電子商取引ウェブサイトの様々な購入者ユーザに関すると共に様々な販売者ユーザに対応する現在の取引状況情報を追跡するよう構成されている。取引状況情報クエリ要求が取引サーバ１１２に送信されると、取引サーバ１１２は、クライアントデバイス１０４の購入者ユーザおよびクライアントデバイス１０６の購入者ユーザの各々に関すると共にクライアントデバイス１０２の販売者ユーザの現在の取引状況情報を取引状況データベース１１６にクエリするよう構成されている。取引サーバ１１２は、クライアントデバイス１０４の購入者ユーザおよびクライアントデバイス１０６の購入者ユーザの各々に関すると共にクライアントデバイス１０２の販売者ユーザに関連付けられている決定済みの現在の取引状況情報をクライアントデバイス１０２のインスタントメッセージングクライアントに送信するよう構成されている。

【0030】

いくつかの実施形態において、クライアントデバイス１０２で実行されるインスタントメッセージングクライアントは、取引状況情報クエリ要求をインスタントメッセージングサーバ１１０に送信するよう構成されている。インスタントメッセージングサーバ１１０は、インスタントメッセージングサービスを提供するよう構成されており、インスタントメッセージングサービスは、インスタントメッセージングサーバ１１０によって維持される特定の電子商取引ウェブサイトに関連しうる。取引状況情報クエリ要求がインスタントメッセージングサーバ１１０に送信されると、いくつかの実施形態において、インスタントメッセージングサーバ１１０は、取引サーバ１１２がクライアントデバイス１０４の購入者ユーザおよびクライアントデバイス１０６の購入者ユーザの各々に関すると共にクライアントデバイス１０２の販売者ユーザに関連付けられている現在の取引状況情報を取引状況データベース１１６にクエリするために、クエリ要求を取引サーバ１１２に転送するよう構成されている。いくつかの実施形態において、インスタントメッセージングサーバ１１０は、クライアントデバイス１０４の購入者ユーザおよびクライアントデバイス１０６の購入者ユーザの各々に関すると共にクライアントデバイス１０２の販売者ユーザに関連付けられている現在の取引状況情報を自身のローカルデータベースすなわち取引状況データベース１１４にクエリするよう構成されている。インスタントメッセージングサーバ１１０は、クライアントデバイス１０４の購入者ユーザおよびクライアントデバイス１０６の購入者ユーザの各々に関すると共にクライアントデバイス１０２の販売者ユーザに関連付けられている決定済みの現在の取引状況情報をクライアントデバイス１０２のインスタントメッセージングクライアントに送信するよう構成されている。

【0031】

クライアントデバイス１０２のインスタントメッセージングクライアントが、クライアントデバイス１０４の購入者ユーザおよびクライアントデバイス１０６の購入者ユーザの各々に関すると共にクライアントデバイス１０２の販売者ユーザに関連付けられている決定済みの現在の取引状況情報を受信した後、かかる取引状況情報は、クライアントデバイス１０２のインスタントメッセージングクライアントに関連付けられているインスタントメッセージングウィンドウで販売者ユーザに向けて表示される。このように、販売者ユーザは、インスタントメッセージングクライアントを用いて自分とチャットしている各購入者ユーザに対応する現在の取引状況情報を容易に決定することができる。

【0032】

図２は、取引状況情報を決定するための処理の一実施形態を示すフローチャートである。いくつかの実施形態において、処理２００は、図１のシステム１００で実施される。

【0033】

様々な実施形態において、処理２００は、電子商取引ウェブサイトの販売者ユーザが用いるクライアントデバイスで実行されるインスタントメッセージングクライアントによって実施される。

【0034】

工程２０２では、インスタントメッセージクライアントに関連付けられている通信先に対応する取引状況情報クエリ要求が送信される。ここで、取引状況情報クエリ要求は、通信先に関するインスタントメッセージングクライアントのユーザに関連している。例えば、電子商取引ウェブサイトで商品を販売している販売者ユーザが、インスタントメッセージングアカウントを確立し、電子商取引ウェブサイトに関連付けられているインスタントメッセージングクライアントをクライアントデバイスにダウンロードしうる。インスタントメッセージングクライアントは、クライアントユーザにインスタントメッセージングサービスを提供するよう構成されたアプリケーションを備えうる。インスタントメッセージングサービスは、他のユーザの通信先リストを維持することを含みうる。例えば、インスタントメッセージクライアントは、電子商取引ウェブサイトからダウンロードされてもよいし、その他の適切な手段を用いて取得されてもよい。様々な実施形態において、販売者ユーザは、インスタントメッセージクライアントに関連したユーザであり、「クライアントユーザ」とも呼ばれる。

【0035】

様々な実施形態において、インスタントメッセージングクライアントに関連付けられている通信先は、販売者ユーザとのオンライン取引を潜在的に行った購入者ユーザである。通信先は、販売者ユーザがインスタントメッセージングサービスに関連付けられている識別情報を維持している購入者ユーザでありうる。いくつかの実施形態において、各通信先に対応する取引状況情報クエリ要求は、通信先（購入者ユーザ）がインスタントメッセージングサービスで販売者ユーザと現在接続中である場合にのみ、販売者ユーザのインスタントメッセージングクライアントによって送信される。接続中の通信先は、インスタントメッセージングサービスで販売者ユーザとのインスタントメッセージングセッションを確立した購入者ユーザである。例えば、購入者ユーザは、購入者ユーザのクライアントデバイスで実行されるインスタントメッセージングクライアントで１または複数の選択を行って販売者ユーザとのチャットセッションを始めることにより、販売者ユーザとのインスタントメッセージングセッションを確立しうる。例えば、購入者ユーザは、販売者ユーザによって販売されている商品について質問するため、および／または、購入者ユーザが販売者ユーザに出した特定の注文について問い合わせするために、販売者ユーザとのインスタントメッセージングセッションを開始しうる。例えば、販売者ユーザは、購入者ユーザに商品情報を伝えるため、および／または、広告を送信するために、購入者ユーザとのインスタントメッセージングセッションを開始しうる。

【0036】

一般に、インスタントメッセージングセッションが、２つの主な実施形態に基づいてクライアントユーザ（販売者ユーザ）および購入者ユーザの間で確立されうる。第１の実施形態では、通信先に関連付けられた識別情報が、クライアントユーザのインスタントメッセージングクライアントのクライアントユーザの格納された通信先リスト内で見つけられる。通信先リストは、インスタントメッセージングクライアントを介してクライアントユーザ（販売者ユーザ）と現在接続されている各通信先を記録するために利用されうる。例えば、クライアントユーザは、通信先リスト内の通信先に関連付けられた識別情報を選択することによって、通信先とのインスタントメッセージングセッションを開始できる。第２の実施形態では、通信先に関連付けられた識別情報は、クライアントユーザの通信先リスト内で見つけられないが、クライアントユーザは、通信先のインスタントメッセージングアカウントにメッセージを直接送信し、それにより、通信先に関連付けられた識別情報が通信先リストに追加される。クライアントユーザが、接続中の通信先とのインスタントメッセージングセッションに関連付けられているウィンドウを閉じた場合、または、通信先リストから通信先を削除した場合、該当する通信先が通信先リストから除去される。あるいは、クライアントユーザが通信先と通信するためにインスタントメッセージングウィンドウを開いた場合、または、通信先リストに通信先を追加した場合、該当する通信先が通信先リストに追加されたと見なされる。

【0037】

いくつかの実施形態において、通信先に対応する取引状況情報クエリ要求が、販売者ユーザのインスタントメッセージングクライアントによって送信され、そのクエリ要求は、クライアントユーザ（販売者ユーザ）に関連付けられた識別情報と、通信先の識別情報とを含む。いくつかの実施形態では、クライアントユーザ（販売者ユーザ）に関連付けられた識別情報および通信先の識別情報に加えて、その他の情報がクエリ要求に含まれる。いくつかの実施形態において、販売者ユーザと接続された各通信先に対応する取引状況情報クエリ要求が、インスタントメッセージングクライアントによって送信される。

【0038】

工程２０４では、通信先に対応する取引状況情報クエリ要求に少なくとも部分的に基づいて決定された取引状況情報が受信される。通信先（例えば、購入者ユーザ）およびクライアントユーザ（例えば、販売者ユーザ）に関する現在の注文の取引状況情報を示す取引状況情報が、インスタントメッセージングクライアントで受信される。様々な実施形態において、取引状況情報は、クエリ要求に含まれるクライアントユーザ（例えば、販売者ユーザ）に関連付けられた識別情報および通信先の識別情報に基づいて、取引状況データベースにクエリすることによって決定される。様々な実施形態において、取引状況データベースは、電子商取引ウェブサイトに関連する様々な販売者ユーザおよび購入者ユーザの間の各取引（例えば、注文）の現在の進捗を追跡する。例えば、取引状況データベースのエントリは、取引の現在の状況（取引状況情報とも呼ばれる）、取引に関連する販売者ユーザ、取引に関連する購入者ユーザ、取引の現在の状況の最終更新時刻、および、注文番号を含んでよい。いくつかの実施形態では、取引（例えば、注文履行過程）の進捗が次の段階に変わった時に、取引状況データベースの対応するエントリが更新される。

【0039】

例えば、最初に発注された時から完了した注文のレビューが投稿された時までの取引状況情報の進捗は、以下の段階を含む。注文済→支払済→発送済→配達確認済→購入者ユーザによる評価済→両関係者による評価済。様々な段階に関する説明は、以下の通りである。

【0040】

「注文済」の前：購入者ユーザ（通信先）は、最初に、購入者ユーザがまだ購入していない商品について問い合わせるために、販売者ユーザによって販売されている商品を含む商品ページに関連付けられているインスタントメッセージングウィンドウを介して、販売者ユーザ（クライアントユーザ）と接続する。この時点では、取引は発生していないので、通信先に関すると共に販売者ユーザに関連付けられている取引データは、取引データベース内にない。したがって、販売者ユーザおよびこの購入者ユーザに関連付けられている対応する取引状況情報は（まだ）存在しない。

【0041】

「注文済」：購入者ユーザが販売者ユーザによって販売されている商品を注文した後、「注文済」取引メッセージが取引状況データベースに送信され、購入者ユーザに関すると共に販売者ユーザに関連付けられているエントリが取引状況データベース内に記録される。この時点で、購入者ユーザに関すると共に販売者ユーザに関連付けられている現在の取引状況情報は、「注文済」に更新される。

【0042】

「支払済」：商品が注文された後に、購入者ユーザが支払いに成功すると、「支払済」取引メッセージが取引状況データベースに送信され、そのメッセージは、購入者ユーザに関すると共に販売者ユーザに関連付けられている現在の取引状況情報を更新するために用いられる。購入者ユーザに関すると共に販売者ユーザに関連付けられている現在の取引状況情報は、「支払済」に更新される。

【0043】

「発送済」：購入者ユーザが支払いを行った後に、販売者ユーザが購入者に商品を発送すると、「発送済」取引メッセージが取引状況データベースに送信され、そのメッセージは、購入者ユーザに関すると共に販売者ユーザに関連付けられている現在の取引状況情報を更新するために用いられる。購入者ユーザに関すると共に販売者ユーザに関連付けられている現在の取引状況情報は、「発送済」に更新される。

【0044】

「配達確認済」：販売者ユーザが商品を発送した後に、購入者ユーザがそれを受け取り、電子商取引ウェブサイトで配達を確認すると、「配達確認済」メッセージが取引状況データベースに送信され、そのメッセージは、購入者ユーザに関すると共に販売者ユーザに関連付けられている現在の取引状況情報を更新するために用いられる。購入者ユーザに関すると共に販売者ユーザに関連付けられている現在の取引状況情報は、「配達確認済」に更新される。

【0045】

「購入者ユーザによる評価済」：購入者ユーザが商品の配達を確認した後に、電子商取引ウェブサイト上で（例えば商品および／または販売者ユーザのレビューを投稿することによって）それを評価すると、「購入者ユーザによる評価済」取引メッセージが取引状況データベースに送信され、そのメッセージは、購入者ユーザに関すると共に販売者ユーザに関連付けられている現在の取引状況情報を更新するために用いられる。購入者ユーザに関すると共に販売者ユーザに関連付けられている現在の取引状況情報は、「購入者ユーザによる評価済」に更新される。

【0046】

「両関係者による評価済」：購入者ユーザが評価を提供した後、販売者ユーザも評価を行うと、「両関係者による評価済」取引メッセージが取引状況データベースに送信され、そのメッセージは、購入者ユーザに関すると共に販売者ユーザに関連付けられている現在の取引状況情報を更新するために用いられる。購入者ユーザに関すると共に販売者ユーザに関連付けられている現在の取引状況情報は、「両関係者による評価済」に更新される。

【0047】

注文履行過程の異なる段階における上述の購入者ユーザによる評価および販売者ユーザによる評価の順序は、逆であってもよい。

【0048】

上述のように、本明細書に記載のインスタントメッセージングクライアントは、通信先との接続を取得した後、対応する接続中の通信先のための取引状況情報クエリ要求の送信を自動的にトリガしてよい。例えば、購入者ユーザは、注文する前に、クライアントユーザが販売する商品に関する情報を探すために、電子商取引ウェブサイト上の商品ページを通して、仮想店主（クライアントユーザ）とのインスタントメッセージングセッションを開始する。この時点で、購入者ユーザは、すでにクライアントユーザとのインスタントメッセージング接続を確立しているので、接続中の通信先と見なされてよく、適切な取引状況情報クエリ要求がインスタントメッセージングクライアントによって送信されるよう自動的にトリガされる。取引状況情報クエリ要求は、店主（販売者ユーザ）に関連付けられた識別情報および接続中の通信先に関連付けられた識別情報を用いて、店主および接続中の通信先の間の現在の取引状況情報を取引状況データベース内でルックアップできるように、かかる識別情報を含んでよい。

【0049】

特定の購入者ユーザ（通信先）のインスタントメッセージングクライアントに返された取引状況情報に基づいて、販売者ユーザは、取引状況情報を用いて、販売者ユーザと購入者ユーザとの間の取引状況情報の迅速な評価を行うことができる。これは、取引状況情報について問い合わせるために電子商取引ウェブサイトにログオンする動作を販売者ユーザまたは購入者ユーザのいずれかが行う必要性を削減できる。したがって、インスタントメッセージングクライアントを用いて取引状況情報のためのクエリ要求を自動的に送信することにより、インスタントメッセージングの効率を効果的に高めることができる。

【0050】

従来、販売者ユーザは、取引状況情報に関するクエリについて購入者ユーザに伝えるために、インスタントメッセージングソフトウエアの利用および電子商取引ウェブサイトのチェックを頻繁に切り替える必要があったが、本明細書に記載の実施形態は、クライアントユーザに関連付けられた識別情報および接続中の各通信先に関連付けられた識別情報に基づいて、販売者ユーザと様々な購入者ユーザの各々とに関連付けられている現在の取引状況情報を自動的に決定する。したがって、取引サーバおよびインスタントメッセージングサーバへの訪問の頻繁な切り替えを減らすことができ、取引サーバおよびインスタントメッセージングサーバへの訪問負荷も低減できる。本明細書に記載の実施形態は、オンラインで取引を行っている販売者ユーザが、同じポータル（例えば、インスタントメッセージングクライアント）を通して通信を行うと共に様々な購入者の取引状況情報を取得することも可能にする。したがって、販売者ユーザは、購入者ユーザに対応する取引状況情報に基づいて、様々な購入者ユーザとのインスタントメッセージングセッションに優先順位を付けることができる。これは、購入者ユーザにとってのインスタントメッセージングの待ち時間を削減する。

【0051】

様々な実施形態において、時間と共に注文が履行される時に、インスタントメッセージングクライアントが注文に関連付けられている最新の取引状況情報を受信できるように、通信先に対応する取引状況情報クエリ要求は、インスタントメッセージングクライアントによって定期的に送信される。

【0052】

図３は、取引状況情報を決定するための処理の一実施形態を示すフローチャートである。いくつかの実施形態において、処理３００は、図１のシステム１００で実施される。いくつかの実施形態において、図２の処理２００は、処理３００を用いて実施される。

【0053】

処理３００は、図２の処理２００と同様であるが、処理３００は、通信先に対応する取引状況情報クエリ要求が具体的に取引サーバに送信される一例を記載している。

【0054】

工程３０２では、インスタントメッセージクライアントに関連付けられている通信先に対応する取引状況情報クエリ要求が取引サーバに送信され、ここで、取引状況情報クエリ要求は、通信先に関するインスタントメッセージングクライアントのユーザに関連している。いくつかの実施形態において、通信先に対応する取引状況情報クエリ要求が、販売者ユーザのインスタントメッセージングクライアントによって自動的に送信され、そのクエリ要求は、クライアントユーザ（販売者ユーザ）に関連付けられた識別情報と、通信先の識別情報とを含む。処理３００において、取引状況情報クエリ要求は、取引サーバによって送信および処理されるように、自動的にトリガされる。取引サーバは、クライアントユーザ（販売者ユーザ）に関連付けられた識別情報および通信先の識別情報に基づいて、取引状況データベースにクエリすることによって、クエリ要求に関連付けられている現在の取引状況情報を取得する。

【0055】

工程３０４では、通信先に対応する取引状況情報クエリ要求に少なくとも部分的に基づいて決定された取引状況情報が、取引サーバから受信される。通信先（購入者ユーザ）およびクライアントユーザ（販売者ユーザ）に関する現在の注文の取引状況情報を示す取引状況情報が、インスタントメッセージングクライアントで受信される。処理３００において、クエリ要求に応答して送信される現在の取引状況情報は、クエリ要求に含まれるクライアントユーザ（販売者ユーザ）に関連付けられた識別情報および通信先の識別情報を用いて、取引サーバによって維持される取引状況データベースに取引サーバがクエリすることによって決定される。

【0056】

クエリ要求に対して決定された取得済みの現在の取引状況情報は、インスタントメッセージングサーバによってインスタントメッセージングクライアントに返される。

【0057】

取引サーバの取引状況データベースに記録された取引状況情報は、取引状況情報の変化に関して受信されたメッセージに基づいて経時的に更新される。したがって、インスタントメッセージングクライアントによって受信される同じ通信先に対応する現在の取引状況情報が、次の取引状況情報クエリ要求が送信される時には、経時的に変化しうる。

【0058】

図４は、取引状況情報を決定するための処理の一実施形態を示すフローチャートである。いくつかの実施形態において、処理４００は、図１のシステム１００で実施される。いくつかの実施形態において、図２の処理２００は、処理４００を用いて実施される。

【0059】

処理４００は、図２の処理２００と同様であるが、処理４００は、通信先に対応する取引状況情報クエリ要求が具体的にインスタントメッセージングサーバに送信される一例を記載しており、インスタントメッセージングサーバは、要求された情報を取引サーバから取得する。いくつかの実施形態において、処理４００は、図３の処理３００の代わりに実施される。

【0060】

工程４０２では、インスタントメッセージクライアントに関連付けられている通信先に対応する取引状況情報クエリ要求がインスタントメッセージングサーバに送信され、ここで、取引状況情報クエリ要求は、通信先に関するインスタントメッセージングクライアントのユーザに関連している。いくつかの実施形態において、通信先に対応する取引状況情報クエリ要求が、販売者ユーザのインスタントメッセージングクライアントによって自動的に送信され、そのクエリ要求は、クライアントユーザ（販売者ユーザ）に関連付けられた識別情報と、通信先の識別情報とを含む。処理４００において、取引状況情報クエリ要求は、インスタントメッセージングサーバに送信されインスタントメッセージングサーバによって処理されるように、自動的にトリガされる。

【0061】

工程４０４では、通信先に対応する取引状況情報クエリ要求に少なくとも部分的に基づいて決定された取引状況情報が、インスタントメッセージングサーバから受信される。通信先（購入者ユーザ）およびクライアントユーザ（販売者ユーザ）に関する現在の注文の取引状況情報を示す取引状況情報が、インスタントメッセージングクライアントで受信される。処理４００において、取引状況情報は、クエリ要求に含まれるクライアントユーザ（販売者ユーザ）に関連付けられた識別情報および通信先の識別情報を用いて、インスタントメッセージングサーバおよび／または取引サーバによって維持される取引状況データベースにインスタントメッセージングサーバがクエリすることによって決定される。取引状況データベースは、インスタントメッセージングサーバおよび取引サーバの一方または両方によって維持されてよい、もしくは、少なくとも、インスタントメッセージングサーバおよび／または取引サーバによってアクセス可能である。クエリ要求に対して決定された取得済みの現在の取引状況情報は、インスタントメッセージングサーバによってインスタントメッセージングクライアントに返される。

【0062】

処理４００において、インスタントメッセージングサーバは、クエリ要求に含まれるクライアントユーザに関連付けられた識別情報および通信先に関連付けられた識別情報を用いて取引状況データベースにクエリすることによって、クエリ要求に関連付けられている現在の取引状況情報を取得する。以下は、インスタントメッセージングサーバが取引状況データベースから現在の取引状況情報を取得する２つの実施形態である。

【0063】

実施形態１：

【0064】

インスタントメッセージングサーバは、インスタントメッセージングクライアントから受信した取引状況情報クエリ要求を取引サーバに転送する。次いで、取引サーバは、クエリ要求に含まれるクライアントユーザに関連付けられた識別情報および通信先に関連付けられた識別情報を用いてクエリを行うことによって取引状況情報を取得し、その後、決定された取引状況情報をインスタントメッセージングサーバに返す。実施形態１は、取引状況データベースが、取引サーバによって維持される場合、および／または、より容易に取引サーバによってアクセス可能である場合に用いられてよい。

【0065】

実施形態２：

【0066】

実施形態１では、取引状況データベースが、取引サーバによって維持される、および／または、より容易に取引サーバによってアクセス可能であるが、実施形態２では、比較的インスタントメッセージングサーバにローカルな別の取引状況データベースが、インスタントメッセージングサーバによって維持される、および／または、より容易にインスタントメッセージングサーバによってアクセス可能である。その結果、インスタントメッセージングサーバは、ローカル取引状況データベースに格納された情報を用いて、インスタントメッセージングクライアントからの取引状況情報クエリ要求を直接処理できる。インスタントメッセージングサーバは、例えば、情報クエリ要求のバッチを取引サーバに定期的に送信し、その後、インスタントメッセージングサーバによって維持されているローカル取引状況データベース内の販売者ユーザおよび購入者ユーザに対応する識別情報を含むクエリ要求に応答して取引サーバから返された取引状況情報を格納することによって、ローカル取引状況データベースに格納すべき情報を決定する。インスタントメッセージングサーバは、例えば、毎日、毎時、または、１０分ごとの設定期間に基づいて、取引状況情報要求を送信してよい。第１の例において、インスタントメッセージングサーバから取引サーバに送信される情報クエリ要求は、様々な販売者ユーザに関連付けられた識別情報のみを含んでよい。インスタントメッセージングサーバから販売者ユーザの識別情報のみを含む情報クエリ要求を受信したことに応答して、取引サーバは、その販売者ユーザに発注した各購入者ユーザに関すると共にその販売者ユーザに関連付けられている取引状況情報を、自身の取引情報データベースにクエリしてよい。このように、インスタントメッセージングサーバに返される取引状況情報は、販売者ユーザに発注した様々な購入者ユーザの各々に関すると共に販売者ユーザに関連付けられている取引状況情報を含む。第２の例において、インスタントメッセージングサーバから取引サーバに送信される情報クエリ要求は、特定の販売者ユーザに関連付けられた識別情報および特定の購入者ユーザに関連付けられた識別情報を含んでもよい。この場合、取引サーバは、その特定の購入者ユーザに関すると共にその販売者ユーザに関連付けられている取引状況情報を、自身の取引状況データベースにクエリし、その後、決定された取引状況情報をインスタントメッセージングサーバに返してよい。

【0067】

実施形態１または実施形態２のいずれかが実施されてよい。いくつかの実施形態では、実施形態１および実施形態２の一方が実施されるが、最初の実施形態が失敗した場合に他方の実施形態が用いられる。

【0068】

図３の処理３００（取引サーバを用いる処理）または図４の処理４００（インスタントメッセージングサーバを用いる処理）のいずれかが、後述のように、インスタントメッセージングクライアントによって送信された取引状況情報クエリ要求に対する取引状況情報を決定するために用いられてよい。

【0069】

図５は、取引状況情報を決定するための処理の一実施形態を示すフローチャートである。いくつかの実施形態において、処理５００は、図１のシステム１００で実施される。

【0070】

処理５００は、図２の処理２００と同様であるが、処理５００は、インスタントメッセージングクライアントで受信された取引状況情報を表示する一例を記載している。

【0071】

工程５０２では、インスタントメッセージクライアントに関連付けられている通信先に対応する取引状況情報クエリ要求が送信され、ここで、取引状況情報クエリ要求は、通信先に関するインスタントメッセージングクライアントのユーザに関連している。

【0072】

工程５０４では、通信先に対応する取引状況情報クエリ要求に少なくとも部分的に基づいて決定された取引状況情報が受信される。

【0073】

工程５０６では、通信先に対応する取引状況情報は、インスタントメッセージングクライアントによって表示される。処理５００では、クライアントユーザが、インスタントメッセージングサービスを用いることにより、各通信先に関連付けられている現在の取引状況情報を即座に知ることができるように、各通信先について受信された受信済み取引状況情報が、インスタントメッセージングクライアントによってその通信先について表示される。このように、クライアントユーザは、自身が通信している通信先の優先順位を、それらに対応する現在の取引状況情報に基づいて付けてよい。いくつかの実施形態において、受信された取引状況情報は、販売者ユーザのクライアントデバイスで受信された後すぐに、販売者ユーザのインスタントメッセージングクライアントによって表示される。いくつかの実施形態において、クライアントユーザは、各通信先について受信された取引状況情報の表示に関連付けられている１または複数のパラメータを（例えば、ユーザインターフェースを介して）設定してよい。

【0074】

図６〜図８は、様々な通信先に対応する取引状況情報を表示するいくつかの実施形態を示す。

【0075】

図６は、インスタントメッセージングクライアントによって様々な通信先に対応する取引状況情報を表示する第１の実施形態を示す図である。いくつかの実施形態において、図５の処理５００の工程５０６は、図６に示す実施形態を用いて実施される。

【0076】

図６の例は、インスタントメッセージングクライアントによって提供されるインスタントメッセージングウィンドウを示す。この例で示すインスタントメッセージングウィンドウは、インスタントメッセージングクライアントに関連付けられているユーザインターフェースの少なくとも一部を表す。例えば、インスタントメッセージングクライアントは、クライアントユーザ（販売者ユーザ）のクライアントデバイスで実行されている。この例で示すように、インスタントメッセージングウィンドウは、チャットウィンドウ６０８および通信先リストを備える。通信先リストは、１または複数の領域を備えており、各領域は、インスタントメッセージングクライアントに関連付けられている販売者ユーザと現在接続されている特定の通信先（購入者ユーザ）に関連付けられている通信先リストの領域を含む。この例において、通信先リストは、領域６０２、領域６０４、および、領域６０６を含んでおり、領域は、それぞれ、通信先１、通信先２、および、通信先３に対応する。各領域（領域６０２、領域６０４、および、領域６０６）は、特定の接続中の購入者ユーザに関連付けられている情報を表示するために準備された通信先リストの領域を指す。販売者ユーザは、チャットウィンドウ６０８を介して通信先とインスタントメッセージをやり取りできる。言い換えると、チャットウィンドウ６０８は、販売者ユーザおよび選択された通信先の間のインスタントメッセージングセッションの内容を表示する。例えば、販売者ユーザは、チャットウィンドウ６０８内で通信先１とチャットするために通信先１に関連付けられている領域６０２を選択してもよいし、チャットウィンドウ６０８内で通信先２とチャットするために通信先２に関連付けられている領域６０４を選択してもよい。この例に示すように、通信先について受信された現在の取引状況情報が、通信先に関連付けられている領域内に表示される。このように、インスタントメッセージングウィンドウを用いる販売者ユーザは、自分がインスタントメッセージングサービスで通信している購入者ユーザの現在の取引状況情報を容易に決定することができる。インスタントメッセージングクライアントは、表示される取引状況情報が注文履行過程の最新の進捗状況になるように、通信先に対応する最新の取引状況情報のクエリ要求を定期的に送信してよい。

【0077】

例えば、販売者ユーザが大規模な販売促進活動（例えば、販売者ユーザが販売する全商品が２０％オフ）を行う場合、販売促進活動によって生じた関心により、販売者ユーザは、非常に短期間に何人かの通信先と同時に接続されうる。通例、インスタントメッセージングクライアントは、接続中の通信先に対応した表示を行わない（または取引情報を受信しない）ため、販売者ユーザは、接続中の各通信先の現在の取引進捗を即座に知ることができない。販売者ユーザは、接続中の各通信先の現在の取引状況情報を決定するために取引サーバにクエリを手動で送信できるが、その処理は、非常に時間が掛かり、非効率的である。接続中の各通信先の現在の取引の進捗を知らなければ、販売者ユーザは、どの通信先とチャットするかについてどのように優先順位を付けるか、および／または、各通信先と何を通信するかを知ることができない。

【0078】

したがって、各通信先に図６の例に示したようなインスタントメッセージングウィンドウ内の領域を割り当てることは、その通信先に関連付けられている領域をひと目見ただけで各通信先に関連付けられている現在の取引状況情報を販売者ユーザが即座に把握する助けになるよう設計されている。

【0079】

図７は、インスタントメッセージングクライアントによって様々な通信先に対応する取引状況情報を表示する第２の実施形態を示す図である。いくつかの実施形態において、図５の処理５００の工程５０６は、図７に示す実施形態を用いて実施される。

【0080】

図７の例は、インスタントメッセージングクライアントによって提供されるインスタントメッセージングウィンドウを示す。この例で示すインスタントメッセージングウィンドウは、インスタントメッセージングクライアントに関連付けられているユーザインターフェースの少なくとも一部を表す。例えば、インスタントメッセージングクライアントは、クライアントユーザ（販売者ユーザ）のクライアントデバイスで実行されている。この例に示すように、インスタントメッセージングウィンドウは、チャットウィンドウ７０２、通信先リスト、および、通信先記述領域７０４を備える。図７の例の通信先リストは、各通信先が通信先リストの領域に関連付けられている点で、図６の例と同様である。ただし、図７の例の通信先リストでは、現在の取引状況情報が、各通信先に関連付けられている領域内に表示されない。その代わり、通信先の現在の取引状況情報は、販売者ユーザがチャットウィンドウ７０２で通信先とチャットすることを（例えば、通信先リスト内のその通信先に関連付けられている領域を選択することによって）選択した時に、通信先記述領域７０４内に表示される。図７に示した例によれば、販売者ユーザは、どの通信先とチャットウィンドウ７０２で現在チャットしていても、その通信先の現在の取引状況情報を速やかに決定することができる。インスタントメッセージングクライアントは、表示される取引状況情報が取引の最新の進捗状況になるように、通信先に対応する最新の取引状況情報のクエリ要求を定期的に送信してよい。

【0081】

図８は、インスタントメッセージングクライアントによって様々な通信先に対応する取引状況情報を表示する第３の実施形態を示す図である。いくつかの実施形態において、図５の処理５００の工程５０６は、図８に示す実施形態を用いて実施される。図８の例は、図６および図７の例を組み合わせたインスタントメッセージングウィンドウを含む。したがって、図８のインスタントメッセージングウィンドウの例は、各通信先およびその通信先の現在の取引情報に関連付けられている領域を備えた通信先リストを備える。さらに、インスタントメッセージングウィンドウは、通信先記述領域を備えており、通信先記述領域は、販売者ユーザが現在チャットウィンドウ内で通信中の通信先の取引状況情報を含む。したがって、図８の例によれば、販売者ユーザは、通信先リスト内の各通信先の現在の取引情報を見ると共に、販売者ユーザがチャットウィンドウでチャットすることを選択した通信先の現在の取引情報を見ることができる。

【0082】

図９は、注文履行過程の様々な段階に対して表示されるアイコンの図である。通信先に対応する取引状況情報は、通信先が販売者ユーザに出した注文に関連付けられている注文履行過程の段階を記述する。上述のように、注文履行過程の様々な段階は、以下を含みうる。注文済→支払済→発送済→配達確認済→購入者ユーザによる評価済→両関係者による評価済。図９の例は、これらの段階の各々を表すための異なるアイコンを示している。例えば、アイコン９０２は、「注文済」の取引状況情報を表し、アイコン９０４は、「支払済」の取引状況情報を表す。この例に示したアイコンは、例にすぎず、注文履行過程の段階のいずれかを表すために、他の画像が用いられてもよい。例えば、アイコンは、或る種のグラフィックマーキングフォーマット（ｇｒａｐｈｉｃｍａｒｋｉｎｇｆｏｒｍａｔ）を含み、＊．ｉｃｏｎまたは＊．ｉｃｏというファイル名拡張子に関連付けられてよい。

【0083】

図９の例に示したアイコンは、図６、図７、および／または、図８の例のインスタントメッセージングウィンドウ内で通信先の現在の取引状況情報を表すために用いられてよい。アイコンを用いて注文履行過程の様々な段階を表すことにより、販売者ユーザは、通信先と共に表示されたアイコンに基づいて、その通信先に関連付けられている現在の取引状況情報を即座に認識できる。例えば、注文履行過程の特定の段階を表すアイコンの表示において、ユーザの動作がアイコンの上または周囲の表示領域内に移動した時に、その段階（例えば、注文済、支払済、発送済、配達確認済、購入者ユーザによる評価済、または、両関係者による評価済）を説明するテキストが表示されてよい。ユーザの動作がアイコンの上または周囲の領域から外れると、テキストはもはや表示されない。ユーザの動作の例は、マウス、キーボード、または、タッチスクリーンに関連付けられている動作を含みうる。

【0084】

図１０は、取引状況情報を決定するための処理の一実施形態を示すフローチャートである。いくつかの実施形態において、処理１０００は、図１のシステム１００で実施される。

【0085】

処理１０００は、図２の処理２００と同様であるが、他の通信先の中での通信先に関連付けられている順位を、それらに対応する現在の取引状況情報に関連付けられている優先順位に基づいて決定するさらなる技術を含む。

【0086】

工程１００２では、インスタントメッセージクライアントに関連付けられている通信先に対応する取引状況情報クエリ要求が送信され、ここで、取引状況情報クエリ要求は、通信先に関するインスタントメッセージングクライアントのユーザに関連している。例えば、クエリ要求は、接続中の各通信先のインスタントメッセージングクライアントによって送信されてよい。

【0087】

工程１００４では、通信先に対応する取引状況情報クエリ要求に少なくとも部分的に基づいて決定された取引状況情報が受信される。接続中の各通信先に関連付けられている取引状況情報が受信される。

【0088】

工程１００６では、複数の通信先の表示の中での通信先に関連付けられている順位が、インスタントメッセージングクライアントによって取引状況情報に少なくとも部分的に基づいて決定される。いくつかの実施形態において、優先順位が、注文履行過程の各段階に（例えば、システム管理者によって）割り当てられてよい。このように、異なる取引状況情報が異なる優先順位に関連付けられる。例えば、注文履行過程の特定の段階の優先順位は、販売者ユーザの視点から設定されてよい。具体例において、取引状況情報の降順の優先順位が、以下のように割り当てられてよい。両関係者による評価済＞購入者ユーザによる評価済＞配達確認済＞発送済＞注文済＞取引状況情報なし。ここで、「取引状況情報なし」とは、対応する接続中の通信先について取引状況情報が受信されていないことを示す。

【0089】

このように、通信先は、その通信先について受信された現在の取引状況情報の優先順位を与えられる。通信先に関連付けられている情報をインスタントメッセージングウィンドウの通信先リスト内に表示する前に、表示される通信先は、（それらの現在の取引状況情報から決定された）それぞれの優先順位に基づいて順位付けされてよい。例えば、優先順位の高い通信先は、通信先リスト内で優先順位の低い別の通信先よりも上位に順位付けられてよい。例えば、販売者ユーザが、非常に短い期間に１００の通信先と接続すると仮定する。通信先リスト内で、１００の通信先の各々は、それぞれの接続時刻に基づいて、デフォルトの順位を受けうる。後に、取引状況情報が、接続中の通信先について受信された時に、接続中の通信先が通信先リスト内で表示される順位は、受信された取引状況情報に基づく。優先順位に基づいて通信先リスト内の通信先を順位付けることは、どの購入者ユーザと最初にチャットすべきかおよび／または何を通信するかを販売者ユーザが特定するのに役立ちうる。更新された取引状況情報が通信先について受信されると、通信先リスト内のそれぞれの順位付けも更新されてよい。

【0090】

図１１は、取引状況情報を決定するための処理の一実施形態を示すフローチャートである。いくつかの実施形態において、処理１１００は、図１のシステム１００で実施される。

【0091】

処理１１００は、図２の処理２００と同様であるが、インスタントメッセージングクライアントが様々な通信先に対応する取引状況情報クエリ要求をクエリキュー内に配置し、クエリキュー内のクエリ要求の順序に基づいてクエリ要求を送信することを可能にするさらなる技術を含む。

【0092】

工程１１０２では、複数の通信先のそれぞれに対応する複数の取引状況情報クエリ要求が、クエリキュー内にインスタントメッセージングクライアントによって格納される。

【0093】

工程１１０４では、複数の取引状況情報クエリ要求の内の１または複数が、クエリキュー内での複数の取引状況情報クエリ要求に関連付けられている順序に少なくとも部分的に基づいて送信される。

【0094】

工程１１０６では、１または複数の取引状況情報クエリ要求に少なくとも部分的に基づいて決定された取引状況情報が受信される。

【0095】

処理１１００はは、販売者ユーザが多数の通信先と連絡を取る場合に特に有用でありうる。例えば、販売者ユーザが大規模な販売促進活動を行う場合、販売促進活動によって生じた関心により、販売者ユーザは、非常に短期間に何人かの通信先と同時に接続されうる。しかしながら、多数の通信先が接続されていることを仮定すると、インスタントメッセージングクライアントが、同時および／または短期間に各通信先のために取引サーバまたはインスタントメッセージングサーバに取引状況情報クエリ要求を送信するとすれば、取引サーバまたはインスタントメッセージングサーバには、非常に多くの処理すべきクエリ要求が突然殺到して、取引サーバまたはインスタントメッセージングサーバによるクエリ要求の処理が非効率的になりうる。

【0096】

インスタントメッセージングクライアントが同時または短時期間にあまりに多くの取引状況情報クエリ要求を取引サーバおよび／またはインスタントメッセージングサーバに送信することを避けるために、クエリ要求は、インスタントメッセージングクライアントによって管理されるクエリキュー内に構造化されてよい。クエリ要求をクエリキュー内に配置することにより、いつどのクエリ要求がインスタントメッセージングクライアントによって送信されるのかを、クエリ要求がクエリキュー内で配列されている順序に基づいて決定できる。例えば、クエリキューは、要求データベースに格納されてよい。いくつかの実施形態において、インスタントメッセージングクライアントは、取引サーバまたはインスタントメッセージングサーバに送信するために、設定された間隔（例えば、３０秒）ごとにクエリキューから次のクエリ要求をフェッチしてよい。

【0097】

例えば、クエリキューは、数字セット、キュー、スタック、および／または、連結リストを用いて実装されてよい。いくつかの実施形態において、クエリキューは、本明細書に記載していない技術を用いて実装されてもよい。いくつかの実施形態において、クエリキューのクエリ要求は、先入れ先出しに基づいた順序で配列されてよい。先入れ先出しスキームにおいて、新たな通信先が販売者ユーザと接続した時には、新たな取引状況情報クエリ要求が、クエリキューの後ろに追加されてよい。例えば、新たな取引状況情報クエリ要求は、「キュー・イン」動作を用いてキューの最後に追加されてよい。キューの最上位の取引状況情報クエリ要求が取引サーバまたはインスタントメッセージングサーバに送信されると、その取引状況情報クエリ要求は、「キュー・アウト」動作を用いてキューから削除されてよい。先出し先入れスキームは、クエリ要求の対応する接続時刻に基づいて実施されてよい。したがって、販売者ユーザとの接続時刻の早い通信先に対応するクエリ要求が、接続時刻の遅い別の通信先に対応する別のクエリ要求よりも、キューの先頭に近く配列されることになる。さらに、通信先に対応する取引状況情報への更新を経時的に決定できるように、新たな取引状況情報クエリ要求が、通信先について定期的に生成されて、キューの後ろに追加されてもよい。

【0098】

いくつかの実施形態において、クエリキュー内のクエリ要求の順序は、取引サーバまたはインスタントメッセージングサーバによってプッシュされたクエリ要求に対応する通信先に関連付けられている受信済みの取引状況情報に基づいて調整されてよい。様々な実施形態において、インスタントメッセージングサーバまたは取引サーバによって「プッシュ」される情報は、インスタントメッセージングクライアントから送信された取引状況情報クエリ要求のトリガなしにサーバによって送信される情報である。例えば、クエリキュー内のクエリ要求は、最初に、先入れ先出しスキームに基づいて配列されてよい。次いで、クエリ要求に対応する通信先に関連付けられている取引状況情報が取引サーバまたはインスタントメッセージングサーバによってインスタントメッセージングクライアントにプッシュされた時、インスタントメッセージングクライアントは、受信した情報に基づいてクエリキュー内のクエリ要求の順序を調整してよい。以下は、取引サーバまたはインスタントメッセージングサーバからプッシュされた情報に基づいたクエリキュー内のクエリ要求の順序調整について記載する一例である。

【0099】

この例において、販売者ユーザのインスタントメッセージングクライアントは、２００の通信先と接続しており、これら２００の通信先のための取引状況情報クエリ要求をインスタントメッセージングクライアントに接続した順序で１つずつキューに入れたと仮定する。関連付けられているクエリ要求がクエリキュー内にある通信先の現在の順番が、通信先１、通信先２、通信先３、・・・、通信先２００であるとする。この時、メッセージングクライアントは、通信先１ないし通信先２０に対応する要求を送信したところであり、通信先２１ないし通信先２００のためのクエリ要求はまだ送信されていないと仮定する。しかしながら、この時、インスタントメッセージングサーバは、取引サーバまたはインスタントメッセージングサーバから、クライアントユーザおよび通信先１００に関連付けられている取引状況情報を受信している。例えば、受信された取引状況情報は、通信先１００がクライアントユーザによって販売されている特定の商品を注文したばかりで、支払いを待っていることを示しているとする。

【0100】

いくつかの実施形態において、取引サーバまたはインスタントメッセージングサーバは、販売者ユーザに対応する最近更新された取引状況情報をその販売者ユーザに関連付けられているインスタントメッセージングクライアントに能動的にプッシュしてよい。例えば、取引サーバおよびインスタントメッセージングサーバの少なくとも一方が、販売者ユーザに対応する最近更新された取引状況情報をその販売者ユーザに関連付けられているインスタントメッセージングクライアントに能動的にプッシュよう構成される。例えば、通信先に関すると共に販売者ユーザに関連付けられている取引状況情報にどのようなタイプの更新／変更がなされたら、インスタントメッセージングクライアントへのかかる情報のプッシュをトリガするのかを、（例えば、システム管理者が）設定してよい。例えば、通信先に関すると共に販売者ユーザに関連付けられている取引状況情報への変更について、変更後の取引状況情報が販売者ユーザにとってより重要になる（例えば、優先順位が高くなる）ような変更が、かかる情報のプッシュを引き起こすように構成されてよい。例えば、変更は、取引状況情報が「注文済」から「支払済」に変更されたことでありうる。変更された取引状況情報がインスタントメッセージングクライアントにプッシュされることにより、インスタントメッセージングクライアントは、受信した取引状況情報内で特定した通信先に対応する取引クエリ要求を、クエリキューがより早く送信されるように、クエリキュー内で上位に移動させることができる。したがって、上位に移動されたクエリ要求は、販売者ユーザにとって関心のある通信先に対応する別の更新済みの取引状況情報をより早く返すことができる。

【0101】

前の例に戻ると、販売者ユーザおよび通信先１００についてインスタントメッセージングクライアントで取引サーバまたはインスタントメッセージングサーバから受信した取引状況情報が「注文済」であった場合、インスタントメッセージングクライアントは、移動されなかった場合よりも早く送信されるように、通信先１００に関連付けられているクエリ要求をキュー内で上位に移動してよい。クエリキュー内でクエリ要求を上位に移動させることにより、通信先１００に対応する取引状況情報の次の更新（「支払済」に対応する更新）をより早く受信することができる。

【0102】

クライアントユーザが、接続中の通信先のインスタントメッセージングウィンドウを閉じた時、または、接続中の通信先を通信先リストから削除した時、対応する接続中の通信先は、通信先のリストから除去されうる。通信先が通信先リストから除去されると、その通信先に対応する任意の１または複数の取引状況情報クエリ要求も、クエリキューから削除されうる。

【0103】

図１２は、取引状況情報を決定するための処理の一実施形態を示すフローチャートである。いくつかの実施形態において、処理１２００は、図１のシステム１００で実施される。

【0104】

処理１２００は、販売者ユーザと１または複数の通信先との間の接続が販売者ユーザのインスタントメッセージングクライアントとインターネット／インスタントメッセージングサーバとの切断によって中断された実施形態を記載する。

【0105】

工程１２０２では、インスタントメッセージングサーバに再接続する旨の指示が受信される。インスタントメッセージングクライアントとインスタントメッセージングサーバとの接続が予期せず切断された場合、販売者ユーザに関連付けられているアカウントは、もはやインスタントメッセージングサービスにログオンされていない。インスタントメッセージングクライアントは、以前に受信した通信先関連の取引状況情報をメモリに保存する。後に、インスタントメッセージングクライアントは、インスタントメッセージングサーバに再接続するよう販売者ユーザによって指示される。インスタントメッセージングクライアントは、再びインスタントメッセージングサーバに接続されると、様々な通信先に対応する以前に受信した取引状況情報をインスタントメッセージングウィンドウに表示する。

【0106】

しかしながら、時に、インスタントメッセージングクライアントとインスタントメッセージングサーバとの接続が中断する前に送信された様々な通信先に対応するいくつかの取引状況情報クエリ要求への応答が、インスタントメッセージングクライアントによって受信されていないことがある（例えば、インスタントメッセージングクライアントがオフラインの間に、それらの応答がインスタントメッセージングクライアントに送信されたため）。いくつかの実施形態において、取引サーバおよび／またはインスタントメッセージングサーバは、オフラインのインスタントメッセージングクライアントによって受信されなかった取引状況情報を一時的に格納し、インスタントメッセージングクライアントとインスタントメッセージングサーバとの再接続が成功したことをサーバが検出した時にかかる取引状況情報をインスタントメッセージングクライアントにプッシュするよう構成されている。しかしながら、取引サーバおよび／またはインスタントメッセージングサーバに取引状況情報を格納させると、取引サーバおよび／またはインスタントメッセージングサーバのリソースを大量に消費するため、一部の例では望ましくない場合がある。

【0107】

いくつかの実施形態において、取引サーバおよび／またはインスタントメッセージングサーバが取引状況情報を一時的に格納するように構成されていない場合、インスタントメッセージングクライアントは、インスタントメッセージングサーバとの再接続に成功した後に、まだ応答を受信していない取引状況情報クエリ要求すべてを再送信してよい。しかしながら、取引サーバまたはインスタントメッセージングサーバに多数の取引状況情報クエリ要求を再送信すると、取引サーバおよび／またはインスタントメッセージングサーバのリソースを消費しうるため、一部の例では望ましくない場合がある。

【0108】

工程１２０４では、通信先に対応する取引状況情報クエリ要求を再送信する旨の選択が受信される。いくつかの実施形態において、インスタントメッセージングクライアントは、インスタントメッセージングサーバへの再接続に成功した後、応答をまだ受信していない取引状況情報クエリ要求すべてを再送信するわけではない。その代わり、インスタントメッセージングクライアントは、クライアントユーザがインスタントメッセージングクライアントに取引状況情報クエリ要求を再送信してもらいたい通信先に関連付けられている選択を、ユーザインターフェースを通してクライアントユーザ（例えば、販売者ユーザ）から受信するよう構成される。このように、インスタントメッセージングクライアントは、潜在的に、応答をまだ受信していない取引状況情報クエリ要求の全部未満を再送信する必要がありうる。

【0109】

工程１２０６では、通信先に対応する取引状況情報クエリ要求が再送信される。

【0110】

例えば、インスタントメッセージングクライアントがインスタントメッセージングサーバとの接続を失う前に、インスタントメッセージングクライアントは、通信先１、２、３、１０、４０、および、５６に対応する取引状況情報クエリ要求を送信していたが、かかる通信先のいずれについても、対応する取引状況情報を受信していないとする。インスタントメッセージングクライアントがインスタントメッセージングサーバに再ログオンする前に、クライアントユーザが通信先３および通信先５６の取引状況情報を見たいと思った場合、クライアントユーザは、通信先３および通信先５６をインスタントメッセージングウィンドウの通信先リストに追加するよう選択できる。次いで、インスタントメッセージングクライアントがインスタントメッセージングサーバとの接続に成功した後に、通信先３および５６に対応する取引状況情報クエリ応答が、インスタントメッセージングクライアントによって再送信されてよい。したがって、インスタントメッセージングクライアントは、かかる再送信された取引状況情報クエリ要求に基づいて送り返された取引状況情報を受信する。

【0111】

いくつかの実施形態において、取引サーバまたはインスタントメッセージングサーバは、かかる情報に対して更新がなされた時に、インスタントメッセージングクライアントに取引状況情報を能動的にプッシュしてよい。上述のように、取引サーバまたはインスタントメッセージングサーバによる取引状況情報のプッシュは、トリガ（インスタントメッセージングクライアントからの取引状況情報クエリ要求など）なしに実行される。例えば、取引サーバまたはインスタントメッセージングサーバは、１または複数の通信先に関するクライアントユーザの取引状況情報を監視できる。取引サーバまたはインスタントメッセージングサーバは、変更が生じたことを検出すると、対応する通信先の変更済みの取引状況情報をクライアントユーザのインスタントメッセージングクライアントに能動的にプッシュできる。

【0112】

例えば、インスタントメッセージングクライアントが２００の通信先に接続されていると仮定する。インスタントメッセージングクライアントは、通信先１ないし２０に対応するクエリ要求を送信したが、通信先２１ないし２００についての要求はまだ送信していないと仮定する。この時点で、インスタントメッセージングサーバは、通信先１００に関するクライアントユーザの取引状況情報に変更があることを検出する。例えば、通信先１００は、クライアントユーザによって販売されている特定の商品を注文したばかりで、支払いを待っている。したがって、インスタントメッセージングサーバは、通信先１００の最近変更された取引状況情報をインスタントメッセージングクライアントに能動的にプッシュしてよい。

【0113】

いくつかの実施形態において、インスタントメッセージングクライアントは、接続中の通信先だけに対応する取引状況情報クエリ要求を表示してよい（非接続通信先については表示しない）。例えば、インスタントメッセージングクライアントが２０の接続中の通信先のみを有すると仮定する。インスタントメッセージングサーバが１００の異なる通信先の取引状況情報を能動的にプッシュしても、インスタントメッセージングクライアントは、現在クライアントユーザに接続されている２０の通信先の取引状況情報だけを表示して、現在クライアントユーザに接続されていないその他の８０の通信先の取引状況情報を表示しなくてもよい。

【0114】

いくつかの実施形態では、インスタントメッセージングクライアントが、取引サーバまたはインスタントメッセージングサーバのいずれかに取引状況情報クエリ要求を送信するよう構成されると共に、取引サーバおよびインスタントメッセージングサーバのいずれかが、インスタントメッセージングクライアントに取引状況情報をプッシュするよう構成される。例えば、インスタントメッセージングクライアントは、接続中の通信先に対応する取引状況情報クエリ要求を１回送信してよい。次いで、インスタントメッセージングクライアントから取引状況情報クエリ要求を受信した後に、取引サーバまたはインスタントメッセージングサーバのいずれかは、対応する取引状況情報の変更を検出した時にはいつでも、クライアントユーザと以前のクエリ要求に関連付けられている接続中の通信先とに関連付けられている最新の取引状況情報をプッシュし続けてよい。

【0115】

図１３は、取引状況情報を決定するための処理の一実施形態を示すフローチャートである。いくつかの実施形態において、処理１３００は、図１のシステム１００で実施される。

【0116】

処理１３００は、インスタントメッセージングサーバがクライアントユーザに関連付けられている様々な通信先に対応する取引状況情報を決定する一例を提供する。

【0117】

工程１３０２では、インスタントメッセージングクライアントによって送信された通信先に対応する取引状況情報クエリ要求がインスタントメッセージングサーバで受信され、ここで、取引状況情報クエリ要求は、通信先に関するインスタントメッセージングクライアントのユーザに関連している。取引状況情報クエリ要求は、インスタントメッセージングクライアントのクライアントユーザに関連付けられた識別情報および通信先の識別情報を含む。

【0118】

工程１３０４では、通信先に対応する取引状況情報が、取引状況データベースにクエリすることに少なくとも部分的に基づいて決定される。インスタントメッセージングサーバは、各取引状況情報クエリ要求に含まれるインスタントメッセージングクライアントのクライアントユーザに関連付けられた識別情報および通信先の識別情報を用いて取引状況データベースにクエリすることにより、取引状況情報を取得できる。

【0119】

工程１３０６では、取引状況情報クエリ要求に少なくとも部分的に基づいて決定された取引状況情報は、インスタントメッセージングサーバによってインスタントメッセージングクライアントに送信される。

【0120】

一実施形態において、インスタントメッセージングサーバは、受信した取引状況情報クエリ要求を取引サーバに転送する。次いで、インスタントメッセージングサーバは、各取引状況情報クエリ要求に含まれるインスタントメッセージングクライアントのクライアントユーザに関連付けられた識別情報および通信先の識別情報を用いて（取引サーバによって維持される）取引状況データベースで取引サーバによって取得された適切な取引状況情報を受信する。

【0121】

第２の実施形態では、別個の取引状況データベースが、インスタントメッセージングサーバによって維持される、および／または、インスタントメッセージングサーバによって容易にアクセス可能である。図４の処理４００について上述したように、インスタントメッセージングサーバによって維持されている取引状況データベースに格納される情報は、インスタントメッセージングサーバに情報クエリ要求のバッチを取引サーバへ定期的に送信させ、その後、販売者ユーザおよび購入者ユーザに対応する識別情報を含むクエリ要求に応答して取引サーバから返された取引状況情報をインスタントメッセージングサーバによって維持されるローカル取引状況データベース内に格納させることによって決定される。次いで、インスタントメッセージングサーバは、ローカル取引状況データベースを用いて、受信した取引状況情報クエリ要求を処理してよい。

【0122】

上述した２つの実施形態は、別個に、組み合わせて、または、互いに代替手段として用いられてよい。

【0123】

いくつかの実施形態において、インスタントメッセージングサーバは、通信先に対応する取引状況情報クエリ要求を受信した後、クエリ要求内で特定されたクライアントユーザおよびクエリ要求内で特定された通信先に関連付けられている取引状況情報を監視し続けてよい。取引状況について変更が決定されると、クライアントユーザの識別情報が決定され、そのクライアントユーザに関連付けられているインスタントメッセージングクライアントが決定される。次いで、更新された取引状況情報がインスタントメッセージングクライアントにプッシュされる。

【0124】

いくつかの実施形態において、インスタントメッセージングサーバは、インスタントメッセージングクライアントとの接続が失われたことを検出した後、インスタントメッセージングクライアントに取引状況情報を返送またはプッシュするのを停止する。いくつかの実施形態において、インスタントメッセージングサーバは、オフラインのインスタントメッセージングクライアントに送信された取引状況情報を一時的に格納し、インスタントメッセージングクライアントがインスタントメッセージングサーバに再接続したと判定された時に、一時的に格納した取引状況情報をインスタントメッセージングクライアントに送信する。

【0125】

図１４は、インスタントメッセージングクライアントのためのシステムを示す図である。この例において、インスタントメッセージングクライアント１４００は、送信モジュール１４０２および受信モジュール１４０４を備える。

【0126】

モジュールおよびサブモジュールは、コンピュータデバイス（パーソナルコンピュータ、サーバ、ネットワーク装置など）に本発明の実施形態に記載された方法を実行させるための複数の命令など、不揮発性記憶媒体（光学ディスク、フラッシュ記憶装置、携帯用ハードディスクなど）に格納することができるソフトウェア製品の形態で具現化されうる要素として設計された、１または複数のプロセッサ上で実行されるソフトウェアコンポーネントとして、プログラム可能論理デバイスおよび／または特定用途向け集積回路などのハードウェアとして実装されてよい。モジュールおよびサブモジュールは、単一のデバイス上に実装されてもよいし、複数のデバイスにわたって分散されてもよい。

【0127】

送信モジュール１４０２は、接続中の通信先に対応する取引状況情報クエリ要求を送信するよう構成されている。取引状況情報クエリ要求は、インスタントメッセージングクライアントに関連付けられているクライアントユーザ（販売者ユーザ）と、接続中の通信先（インスタントメッセージングサービスを介して販売者ユーザに現在接続されている購入者ユーザ）とに関連付けられている。取引状況情報クエリ要求は、クライアントユーザに関連付けられた識別情報および通信先に関連付けられた識別情報を含む。

【0128】

受信モジュール１４０４は、取引状況情報クエリ要求に基づいて決定された取引状況情報を受信するよう構成されている。取引状況情報は、各取引状況情報クエリ要求に含まれるクライアントユーザに関連付けられた識別情報および通信先に関連付けられた識別情報を用いて取引状況データベースにクエリすることによって決定される。

【0129】

いくつかの実施形態において、送信モジュール１４０２は、さらに以下を備えてもよい。

【0130】

接続中の通信先に対応する取引状況情報クエリ要求を１または複数のインスタントメッセージングサーバに送信するよう構成された第１の送信サブモジュール。

【0131】

受信モジュール１４０４は、さらに以下を備えてもよい。

【0132】

取引状況情報クエリ要求に基づいて１または複数のインスタントメッセージングサーバによって返された取引状況情報を受信するよう構成された第１の受信サブモジュール。返信される取引状況情報は、クエリ要求に含まれるクライアントユーザに関連付けられた識別情報および様々な通信先に関連付けられた識別情報を用いて１または複数のインスタントメッセージングサーバもしくは１または複数の取引サーバの取引状況データベースにクエリすることによって取得される。

【0133】

いくつかの実施形態において、送信モジュール１４０２は、さらに以下を備えてもよい。

【0134】

接続中の通信先に対応する取引状況情報クエリ要求を１または複数の取引サーバに送信するよう構成された第２の送信サブモジュール。

【0135】

受信モジュール１４０４は、さらに以下を備えてもよい。

【0136】

取引状況情報クエリ要求に基づいて１または複数の取引サーバによって返された取引状況情報を受信するよう構成された第２の受信サブモジュール。返される取引状況情報は、クエリ要求に含まれるクライアントユーザに関連付けられた識別情報および様々な通信先に関連付けられた識別情報を用いて１または複数の取引サーバの取引状況データベースにクエリすることによって取得される。

【0137】