JP3966051B2 - 通信データ削減方法およびシステム - Google Patents
通信データ削減方法およびシステム Download PDFInfo
- Publication number
- JP3966051B2 JP3966051B2 JP2002112818A JP2002112818A JP3966051B2 JP 3966051 B2 JP3966051 B2 JP 3966051B2 JP 2002112818 A JP2002112818 A JP 2002112818A JP 2002112818 A JP2002112818 A JP 2002112818A JP 3966051 B2 JP3966051 B2 JP 3966051B2
- Authority
- JP
- Japan
- Prior art keywords
- business document
- document
- business
- tag
- similar transaction
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
- 238000000034 method Methods 0.000 title claims description 65
- 238000004891 communication Methods 0.000 title claims description 26
- 230000005540 biological transmission Effects 0.000 claims description 16
- 238000004364 calculation method Methods 0.000 claims description 6
- 238000007726 management method Methods 0.000 description 14
- 238000013144 data compression Methods 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 4
- 230000010365 information processing Effects 0.000 description 2
- 238000007906 compression Methods 0.000 description 1
- 230000006835 compression Effects 0.000 description 1
- 230000007423 decrease Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99933—Query processing, i.e. searching
- Y10S707/99936—Pattern matching access
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
- Y10S707/99953—Recoverability
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Marketing (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、通信ネットワークを介して接続された少なくとも１つの計算機のそれぞれの間でビジネス文書を交換する企業間電子商取引システムに関する。特に、ビジネス文書の交換における通信データ量削減方法に関する。
【０００２】
【従来の技術】
近年、インターネットの普及や、ＸＭＬ等の標準データ交換技術の確立により、オープンな通信ネットワーク環境での企業間電子商取引（ＢｔｏＢ）が行われ始めている。これに伴い、企業間電子商取引において取引企業間で電子化されたビジネス文書を転送するための、情報処理技術に関する標準仕様の策定が行われてきた。
【０００３】
こうした標準仕様では、取引企業間で交換する電子化されたビジネス文書の形式に関する取り決めや、ビジネス文書を取引先企業へ送信する際のメッセージ形式（ＢｔｏＢ標準メッセージ形式）に関する取り決め等が定められている。
【０００４】
ＢｔｏＢ標準メッセージの具体的な形式を規定している団体には、RosettaNet等がある。RosettaNetは、ビジネス文書の形式に関する取り決めを、Partner Interface Processesによって定めている。また、送信の際のメッセージ形式に関する取り決めをRosettaNet Implementation Frameworkによって定めている。
【０００５】
従来の企業間電子商取引では、取引企業間で独自に通信データの形式を規定していたため、１つの取引相手ごとに１つの電子商取引システムが必要であった。しかし、上述の標準仕様の策定によって、ある企業でＢｔｏＢ標準仕様に準拠した電子商取引システムを１つ用意すれば、システムやメッセージ形式を変更しなくても、ＢｔｏＢ標準準拠の電子商取引システムを備えた不特定多数の企業との取引を行なえる。
【０００６】
【発明が解決しようとする課題】
上述の企業間電子商取引における標準仕様では、ビジネス文書に対する形式が厳密に決められている。例えば、ビジネス文書内に含めなければならないデータ項目は、標準仕様に規定されている。しかしながら、企業間電子商取引において一旦特定の企業間で商取引を始めると、毎回の取引案件において決まった値を送ることになるデータ項目も少なくない。例えば、定期的に同じ商品を数量のみを変えて発注し、注文した商品を同じ場所へ配送する場合など、商品名、商品コードや配送先のデータ項目は、発注のたびに同じデータを送信することになる。
【０００７】
現在、企業間電子商取引市場は急速に成長しつつあり、ネットワークにおける通信トラフィックの増加が予想されている。このような状況の中で、冗長性の高いＢｔｏＢ標準フォーマットの使用は非効率である。また、企業間電子商取引におけるビジネス文書交換では、機密性等のセキュリティ要件も厳しく、電子暗号技術によるビジネス文書の暗号化や電子署名を行う必要がある場合が多い。
【０００８】
電子暗号処理は計算コストが高いので、冗長性の高いＢｔｏＢ標準フォーマットを使用することは、情報処理システムへの処理負荷へ直接影響し、システムの高コスト化を招く原因となりうる。
【０００９】
通信データ量を削除する技術としてはデータ圧縮技術等がある。例えば、特開２００１−２１７７２０では、ＸＭＬ文書のデータ圧縮方法について述べている。しかし、送信するビジネス文書や、ＢｔｏＢ標準メッセージに対して、これらの通信データ圧縮技術をそのまま適用すると、ＢｔｏＢ標準仕様に従ったメッセージ形式が崩れてしまい、ＢｔｏＢ標準準拠のシステムで文書の書式チェックエラーが起きてしまう。
【００１０】
また、ＢｔｏＢ標準フォーマットを使用せずに電子商取引を行う場合、取引企業間で独自にメッセージ形式を規定する必要があり、特定の取引先企業のみしか取引のできない電子商取引システムになってしまう。
【００１１】
本発明の目的は、１つのＢｔｏＢ標準準拠の電子商取引システムを用いて、不特定多数の取引相手との商取引を可能にしつつ、電子商取引の際の通信データ量を削減する方法を提供する。
【００１２】
【課題を解決するための手段】
本発明では、通信ネットワークを介して接続された少なくとも１つの計算機のそれぞれの間でビジネス文書を交換するＢｔｏＢ標準フォーマットを使用する企業間電子商取引システムにおいて、業務処理部とメッセージ交換部から構成されているそれぞれの計算機に新たに差分処理部を設ける。差分処理部は、送信時は、取引相手や取引内容に応じて、過去に送信済みのビジネス文書と、今回送信するビジネス文書との差分情報を、ＢｔｏＢ標準メッセージ形式の範囲内で生成し、取引相手へ送信する。受信時は、過去に受信済みのビジネス文書と差分情報から、今回受信したビジネス文書を復元する。
【００１３】
既存のデータ圧縮技術を、単純にビジネス文書に用いると、出力されるデータは、圧縮アルゴリズムに依存したバイト列になるので、既存の企業間電子商取引システムでは処理できない。しかし、本発明の差分生成方法を用いると、ＢｔｏＢ標準仕様に従ったビジネス文書のＸＭＬ文書構造を崩さずに、冗長なデータを削減できる。
【００１４】
【発明の実施の形態】
まず、取引履歴情報を用いて通信データ量を削除する場合の一実施例を図を用いて説明する。
図１は、本発明における企業間電子商取引システムの全体図である。送信側及び受信側それぞれのＢｔｏＢサーバ１０１は、業務処理部１０３、差分処理部１０４、メッセージ交換部１０５から構成されて、互いにインターネット１０２を介して接続されている。
【００１５】
差分処理部１０４は、取引相手管理ＤＢ１０６と履歴ＤＢ１０７にアクセスできる。業務処理部１０３は、送信時は、業務処理に応じて取引相手に送るビジネス文書１１１を生成する。受信時は、受け取ったビジネス文書１１１の内容に応じて適切な業務処理を行う。
【００１６】
差分処理部１０４は、送信時は、業務処理部１０３からビジネス文書１１１を受け取り、ビジネス文書１１１の内容及び取引相手、履歴ＤＢ１０７の情報を元に、差分ビジネス文書１１２を生成する。受信時は、メッセージ交換部１０５から差分ビジネス文書１１２を受け取り、差分ビジネス文書１１２及び取引相手、履歴ＤＢ１０７の情報を元に、ビジネス文書１１１を復元する。
【００１７】
メッセージ交換部１０５は、送信時は、差分ビジネス文書１１２を受け取り、差分ビジネス文書１１２を含むＢｔｏＢ標準メッセージ１１３を生成して取引相手に送信する。受信時は、ＢｔｏＢ標準メッセージ１１３を受け取り、ＢｔｏＢ標準メッセージ１１３の書式チェックを行い、その中に含まれる差分ビジネス文書１１２を取り出す。
【００１８】
図２は、本発明を、メッセージングハブ２０１を用いたネットワークに応用した例である。
【００１９】
本発明システムを実装したＢｔｏＢサーバ１０１と、メッセージングハブ２０１との間は、差分形式のＢｔｏＢ標準メッセージ１１３を用いて通信する。メッセージングハブ２０１と、本発明システムを実装していないＢｔｏＢサーバ２０２との間は、通常のＢｔｏＢ標準メッセージ２１１を用いて通信する。メッセージングハブ２０１を用いることにより、本発明システムを実装したＢｔｏＢサーバ１０１と、本発明システムを実装していないＢｔｏＢサーバ２０２との間でも、部分的に通信データ量を削減できる。図２に示す形態のネットワークの例として、ｅマーケットプレイスなどが挙げられる。
【００２０】
図３は、差分処理部１０４の内部のモジュール構成とデータの流れを示す。差分処理部１０４は、履歴検索部３０１と差分生成・復元部３０２から構成される。
【００２１】
送信時に、差分処理部１０４は、業務処理部１０３から配信情報３１１とビジネス文書１１１を渡される。配信情報３１１には、取引相手識別子１５０２が含まれる。これらの情報は、まず履歴検索部３０１に渡される。履歴検索部３０１は、配信情報３１１とビジネス文書１１１を受け取ると、まず、配信情報３１１から取引相手識別子１５０２を取得し、取引相手管理ＤＢ１０６を検索して、取引相手の電子商取引システムが本発明システムを実装しているか否かを調べる。次に、履歴検索部３０１は、履歴ＤＢ１０７を検索し、ビジネス文書１１１と内容が類似する類似取引３１２を取得する。ビジネス文書１１１と類似取引３１２は、差分生成・復元部３０２に渡される。
【００２２】
差分生成・復元部３０２は、ビジネス文書１１１と類似取引３１２から差分ビジネス文書１１２を生成し、類似取引３１２から、類似取引３１２の識別子である類似取引ＩＤ３１３を取得する。
【００２３】
配信情報３１１、差分ビジネス文書１１２及び類似取引ＩＤ３１３は、メッセージ交換部１０５に渡されてＢｔｏＢ標準メッセージ１１３の中に組み込まれる。
受信時に、差分処理部１０４は、メッセージ処理部１０５がＢｔｏＢ標準メッセージ１１３から取得した配信情報３１１、差分ビジネス文書１１２及び類似取引ＩＤ３１３を渡される。これらの情報は、まず履歴検索部３０１に渡される。
【００２４】
履歴検索部３０１は、配信情報３１１から取引相手識別子１５０２を取得し、取引相手管理ＤＢ１０６を検索して、取引相手の電子商取引システムが本発明システムを実装しているか否かを調べる。次に、履歴検索部３０１は、受信したＢｔｏＢ標準メッセージ１１３が差分ビジネス文書１１２を含むかを確認し、類似取引ＩＤ３１３をキーにして履歴ＤＢ１０７を検索し、類似取引３１２を取得する。類似取引３１２と差分ビジネス文書１１２は差分生成・復元部３０２に渡される。
【００２５】
差分生成・復元部３０２は、類似取引３１２と差分ビジネス文書１１２からビジネス文書１１１を復元する。復元されたビジネス文書１１１と配信情報３１１は、業務処理部１０３に渡される。
【００２６】
図１４は、取引相手管理ＤＢ１０６の詳細である。取引相手識別子１４０１は、取引相手をシステム内で一意に識別する識別子である。システム対応フラグ１４０２は、取引相手識別子１４０１が示す相手の電子商取引システムが、本発明システムを実装しているか否かを示すフラグである。
【００２７】
図１５は、履歴ＤＢ１０７の詳細である。取引ＩＤ１５０１は、取引の識別子である。取引相手識別子１５０２は、取引相手の識別子である。文書構造定義１５０３は、その取引が従う文書の形式である。文書構造定義１５０３の例には、ＤＴＤファイル名などがある。取引履歴１５０４は、過去に行われた取引のビジネス文書の実データである。
【００２８】
図４は、ＢｔｏＢサーバ１０１における送信時の処理のフローチャートである。
【００２９】
ビジネス文書１１１と配信情報３１１を生成する（ステップ４０１）。配信情報３１１に含まれる取引相手識別子１５０２を元に、取引相手管理ＤＢ１０６を検索し、取引相手の電子商取引システムが本発明システムを実装しているか否かを調べる（ステップ４０２）。本発明システムを実装している場合はステップ４０３へ進み、実装していなければステップ４０６へ進む。ビジネス文書１１１と内容が類似した過去の類似取引３１２を履歴ＤＢ１０７から検索する（ステップ４０３）。検索方法の詳細は後述する。類似取引が存在する場合はステップ４０４へ進み、存在しない場合はステップ４０６へ進む。今回送信するビジネス文書１１１と過去の類似取引３１２から差分ビジネス文書１１２を生成する（ステップ４０４）。差分ビジネス文書１１２の生成方法の詳細は後述する。差分ビジネス文書１１２を含むＢｔｏＢ標準メッセージ１１３を生成して取引相手に送信する（ステップ４０５）。ビジネス文書１１１を含むＢｔｏＢ標準メッセージ２１１を生成して取引相手に送信する（ステップ４０６）。
【００３０】
ここで、図４のステップ４０３における、類似取引３１２の検索方法の詳細を説明する。
【００３１】
まず、今回送信するビジネス文書１１１、取引相手識別子１５０２及び文書構造定義１５０３が同じである過去の取引を履歴ＤＢ１０７から検索する。次に、検索の結果取得される取引１件ごとに、今回送信するビジネス文書１１１との類似度を計算する。類似度の計算方法は後述する。類似度の計算が終了したら、類似度が最大の過去の取引を探す。その類似度が予め設定された値を超えていたら、その過去の取引を類似取引３１２とする。類似度が上記の値を超えていなければ、類似取引３１２は存在しないと判断する。
【００３２】
次に、図６によって、過去の取引と今回送信するビジネス文書１１１との類似度計算方法を説明する。ここで、元文書は、過去の取引または今回送信するビジネス文書１１１である。対象文書は、元文書が過去の取引の場合は、今回送信するビジネス文書１１１であり、元文書が今回送信するビジネス文書１１１の場合は、過去の取引である。
【００３３】
文書の重みに０を代入する（ステップ６０１）。元文書のタグを展開したツリー構造上のノードを辿る（ステップ６０２）。辿るタグがまだ存在する場合は、ステップ６０４へ進む（ステップ６０３）。辿るタグがもう存在しない場合は、現在の文書の重みを類似度として終了する。現在位置のタグが、子タグを持たない末端のタグである場合はステップ６０５へ進む（ステップ６０４）。そうでない場合はステップ６０２へ進む。現在位置のタグと同じパス情報を持つタグを、対象文書上のタグの中から探す（ステップ６０５）。パス情報の詳細は後述する。現在位置のタグの値と、ステップ６０５で探したタグの値が一致する場合は、ステップ６０７に進む（ステップ６０６）。タグの値が一致しない場合、もしくは、ステップ６０５で探したタグが存在しない場合、ステップ６０２に進む。文書の重みに、現在位置のタグの値の長さを加算する（ステップ６０７）。
【００３４】
以上で、過去の取引と今回送信するビジネス文書１１１との類似度計算方法を説明した。この類似度計算方法では、タグが文書定義上必須である場合も省略可能である場合も同様に扱っている。ここで、省略可能タグの値が一致する場合は、そのタグを省略するようにすれば、より多くの余剰データを削減できる。この場合は、受信側で、値が一致したためにタグを省略したのか、今回の取引文書では予めタグが省略してあったのかを区別するために、予めタグが省略してあった場合には、その旨を示す特定記号をタグの値として差分ビジネス文書１１２に書き込む。
【００３５】
図７は、図６のステップ６０５における、パス情報の対応付けの方法を示す。パス情報は、ツリー構造の頂点からタグを辿る順番に、タグ名を区切り記号で区切って並べたものである。同じタグの子タグの中に同名のタグが複数ある場合は、タグ名の後に出現順序を付ける。区切り記号を「／」としたとき、タグ７０３とタグ７０６のパス情報は「／注文／取引相手」である。また、タグ７０４とタグ７０７のパス情報は「／注文／商品情報［１］／値段」であり、タグ７０５とタグ７０８のパス情報は「／注文／商品情報［２］／個数」である。出現順序が付いていないタグ名は、出現順序が１であるタグ名と同じであると見なす。従って、「／注文／商品情報」と「／注文／商品情報［１］」は同じパス情報である。
【００３６】
次に、図８に、図４のステップ４０４における、差分ビジネス文書１１２の生成方法の詳細を示す。ここで、元文書は、類似取引３１２またはビジネス文書１１１である。元文書が類似取引３１２である場合、対象文書はビジネス文書１１１である。元文書がビジネス文書１１１である場合、対象文書は類似取引３１２である。元文書がビジネス文書１１１である場合、ステップ８０４とステップ８０７は処理を行わずにスキップし、このときステップ８０３からは常にステップ８０５へ進む。
【００３７】
元文書のタグを展開したツリー構造上のノードを辿る（ステップ８０１）。辿るタグがまだ存在する場合はステップ８０３へ進み、辿るタグがもう存在しない場合はステップ８０７へ進む（ステップ８０２）。現在位置のタグと同じパス情報を持つタグを、対象文書上のタグの中から探す（ステップ８０３）。現在位置のタグと同じパス情報を持つタグが、対象文書上に存在する場合はステップ８０５へ進み、存在しない場合はステップ８０１へ進む（ステップ８０４）。現在位置のタグが子タグを持たない末端タグである場合はステップ８０６へ進み、そうでない場合はステップ８０９へ進む（ステップ８０５）。現在位置のタグの値と、ステップ８０３で探したタグの値が一致する場合は、ステップ８０８へ進み、そうでない場合はステップ８０９へ進む（ステップ８０６）。対象文書中のタグで未参照であるもののタグ名とタグ値を全て差分ビジネス文書０１１２へ書き込む（ステップ８０７）。現在位置のタグの値を特定記号に置き換えたものを差分ビジネス文書１１２に書き込む（ステップ８０８）。差分ビジネス文書１１２のタグ値は特定記号に置き換わる。ここで、特定記号とは、文字数が長いタグ値の情報量を削減するために置き換える文字数が短い値である。現在位置のタグ名とタグ値を差分ビジネス文書１１２に書き込む（ステップ８０９）。
【００３８】
図５は、ＢｔｏＢサーバ１０１における受信時の処理のフローチャートである。
受信したＢｔｏＢ標準メッセージ１１３の形式がＢｔｏＢ標準仕様に従うかの書式チェックを行う（ステップ５０１）。受信したＢｔｏＢ標準メッセージ１１３が差分ビジネス文書１１２を含むか否かを、類似取引ＩＤ３１３の有無によって調べる（ステップ５０２）。差分ビジネス文書１１２を含む場合はステップ５０３へ進み、含まない場合は終了する。類似取引ＩＤ３１３をキーに履歴ＤＢ１０７を検索して類似取引３１２を取得する（ステップ５０３）。差分ビジネス文書１１２と過去の類似取引３１２から元のビジネス文書１１１を復元する（ステップ５０４）。ビジネス文書１１１の復元方法の詳細は後述する。ビジネス文書１１１の内容に応じた業務処理を行う（ステップ５０５）。
【００３９】
次に、図９は、図５のステップ５０４における、ビジネス文書１１１の復元方法の詳細を示す。ここで、元文書は類似取引３１２または差分ビジネス文書１１２である。元文書が類似取引３１２である場合、対象文書は差分ビジネス文書１１２である。元文書が差分ビジネス文書１１２である場合、対象文書は類似取引３１２である。元文書が差分ビジネス文書１１２である場合、ステップ９０４とステップ９０７は処理を行わずにスキップする。このときステップ９０３からは常にステップ９０５へ進む。
【００４０】
元文書のタグを展開したツリー構造上のノードを辿る（ステップ９０１）。辿るタグがまだ存在する場合はステップ９０３へ進み、辿るタグがもう存在しない場合はステップ９０７へ進む（ステップ９０２）。現在位置のタグと同じパス情報を持つタグを対象文書上のタグの中から探す（ステップ９０３）。現在位置のタグと同じパス情報を持つタグが対象文書上に存在する場合はステップ９０５へ進み、存在しない場合はステップ９０１へ進む（ステップ９０４）。現在位置のタグが子タグを持たない末端タグである場合はステップ９０６へ進み、そうでない場合はステップ９０９へ進む（ステップ９０５）。現在位置のタグの値が特定記号である場合はステップ９０８へ進み、そうでない場合はステップ９０９へ進む（ステップ９０６）。対象文書中のタグで、未参照であるもののタグ名とタグ値を全て復元するビジネス文書１１１へ書き込む（ステップ９０７）。ステップ９０３で探した対象文書上のタグ名とタグ値を、復元するビジネス文書１１１に書き込む（ステップ９０８）。現在位置のタグ名とタグ値を、復元するビジネス文書１１１に書き込む（ステップ９０９）。
【００４１】
図１０に、送信時の差分生成（図４のステップ４０４、図８）における、元文書が今回送信するビジネス文書１１１である場合のデータの流れを示す。
【００４２】
元文書のタグが末端タグではないので、そのまま差分ビジネス文書１１２に書き込む（矢印１００１）。元文書のタグが末端タグであり、値が対象文書のタグ値と一致するので、差分ビジネス文書１１２に、値を特定記号に置き換えたタグを書き込む（矢印１００２）。ここでは特定記号を「Ｘ」とする。元文書のタグが末端タグであり、値が対象文書のタグ値と一致しないので、元文書のタグ名とタグ値をそのまま差分ビジネス文書１１２に書き込む（矢印１００３）。元文書のタグが末端タグであり、値が対象文書のタグ値と一致しない（対象文書には値がない）ので、元文書のタグ名とタグ値をそのまま差分ビジネス文書１１２に書き込む（矢印１００４）。対象文書にタグがあっても元文書にタグがない場合は、無視されるので自動的に省略される（矢印１００５）。
【００４３】
図１１に、送信時の差分生成（図４のステップ４０４、図８）における、元文書が類似取引３１２である場合のデータの流れを示す。
【００４４】
元文書のタグが末端タグではないので、そのまま差分ビジネス文書１１２に書き込む（矢印１１０１）。元文書のタグが末端タグであり値が対象文書のタグ値と一致するので、差分ビジネス文書１１２に、値を特定記号に置き換えたタグを書き込む（矢印１１０２）。ここでは特定記号を「Ｘ」とする。元文書のタグが末端タグであり値が対象文書のタグ値と一致しないので、元文書のタグ名とタグ値をそのまま差分ビジネス文書１１２に書き込む（矢印１１０３）。元文書にはタグがないが対象文書にはタグがあるので、対象文書のタグ名とタグ値を差分ビジネス文書１１２に書き込む（矢印１１０４）。（ステップ８０７で、未参照タグとして書き込まれる。）元文書にはタグがあるが対象文書にはタグがないので、無視される（矢印１１０５）。（ステップ８０４からステップ８０１に進むので何も処理されない。）
図１２に、受信時の差分復元（図５のステップ５０４、図９）における、元文書が差分ビジネス文書１１２である場合のデータの流れを示す。
【００４５】
元文書のタグが末端タグではないので、そのまま復元するビジネス文書１１１に書き込む（矢印１２０１）。元文書のタグが末端タグであり、値が特定記号なので、対象文書からパス情報が同じタグの値を取得し、その値を復元するビジネス文書１１１に書き込む（矢印１２０２）。元文書の値が特定記号ではないので、その値を復元するビジネス文書１１１に書き込む（矢印１２０３）。対象文書には値があるが元文書には値がないので、無視される（矢印１２０４）。
【００４６】
図１３に、受信時の差分復元（図５のステップ５０４、図９）における、元文書が類似取引３１２である場合のデータの流れを示す。
【００４７】
元文書のタグが末端タグではなく、対象文書に同じパス情報のタグが存在するので、そのまま復元するビジネス文書１１１に書き込む（矢印１３０１）。元文書のタグが末端タグであり、対象文書の同じパス情報のタグの値が特定記号なので、元文書のタグ名とタグ値を復元するビジネス文書１１１に書き込む（矢印１３０２）。元文書のタグが末端タグであり、対象文書の同じパス情報のタグの値が通常値なので、対象文書のタグ名とタグ値を復元するビジネス文書１１１に書き込む（矢印１３０３）。元文書にはタグがないが対象文書にタグがあるので、対象文書のタグ名とタグ値を復元するビジネス文書１１１に書き込む（矢印１３０４）。（ステップ９０７で、未参照タグとして書き込まれる。）元文書にタグがあるが対象文書にはタグがないので、無視される（矢印１３０５）。（ステップ９０４からステップ９０１に進むので何も処理されない。）
以上で、取引履歴情報を用いた本発明の一実施例を示した。
【００４８】
次に、取引相手と事前に交換したテンプレートを用いて通信データ量を削除する場合の一実施例を図を用いて説明する。この実施例は、上述した履歴ＤＢ使用時の実施例で用いた類似取引３１２の代わりにテンプレート１７０１を使用するものである。図１７にテンプレートの例を示す。テンプレート１７０１は、ビジネス文書１１１であって、かつ、取引のたびに同じ値を使用するタグに予め値が設定されているものである。
【００４９】
以下では、履歴ＤＢ使用時との相違点のみを説明する。まず、本実施形態のシステムの構成に関し、図１の履歴ＤＢ１０７はテンプレート管理ＤＢ１６０５に置き換わる。
【００５０】
次に、本実施形態におけるデータの流れに関し、図３の類似取引３１２はテンプレート１７０１に置き換わり、類似取引ＩＤ３１３はテンプレートＩＤ１６０３に置き換わる。
【００５１】
次に、送受信時のフローチャートに関し、送信時における図４のステップ４０３は「取引相手識別子１６０１と文書構造定義１６０２の組がビジネス文書１１１と一致するテンプレート１７０１が存在するか？」に置き換わる。ここでは、取引相手識別子１６０１と文書構造定義１６０２が一致するテンプレート１７０１を、テンプレート管理ＤＢ１６０５から取得する。
【００５２】
また、ステップ４０４は「今回のビジネス文書１１１とテンプレート１７０１から、差分ビジネス文書１１２を生成する」に置き換わる。差分生成方法は、履歴ＤＢと同様の方法を用いる。ただし、類似取引３１２をテンプレート１７０１に置き換える。また、テンプレート１７０１内のタグで値が設定されていないものは、タグが存在しないと見なす。
【００５３】
受信時については、図５におけるステップ５０３は「テンプレート１７０１を、テンプレート管理ＤＢ１６０５から取得する」に置き換わる。テンプレート１７０１は、受信したＢｔｏＢ標準メッセージ１１３に含まれるテンプレートＩＤ１６０３、または、取引相手識別子１６０１とビジネス文書の文書構造定義１６０２を用いて取得する。
【００５４】
また、ステップ５０４は「差分ビジネス文書１１２とテンプレート１７０１から、今回のビジネス文書１１１を復元する」に置き換わる。差分復元方法は、履歴ＤＢ使用時と同様の方法を用いる。ただし、類似取引３１２をテンプレート１７０１に置き換える。また、テンプレート１７０１内のタグで値が設定されていないものは、タグが存在しないと見なす。
【００５５】
図１６は、テンプレートを使用する本実施例におけるテンプレート管理ＤＢ１６０５の詳細である。
【００５６】
取引相手識別子１６０１は取引相手の識別子である。文書構造定義１６０２は、その取引が従う文書の形式である。文書構造定義１６０２は例えばＤＴＤファイル名などである。テンプレート識別子１６０３はテンプレートの識別子である。テンプレート識別子１６０３は例えばファイル名などである。交換フラグ１６０４は、テンプレートを最初の取引時に交換する場合の後述する実施例で使用され、取引相手とテンプレート１７０１を既に交換したか否かを示すフラグである。
【００５７】
以上で、テンプレートを使う場合で、テンプレートを取引相手と事前に交換する場合の実施形態を説明した。
【００５８】
次に、テンプレートを使う場合で、最初の取引時にテンプレートを交換する場合の実施形態を示す。ここでは、テンプレートを取引相手と事前に交換する場合との相違点のみを説明する。
【００５９】
この実施形態のシステムの構成は、テンプレート１７０１を事前に交換する場合と同じである。ただし、テンプレート管理ＤＢ１６０５のカラムの交換フラグ１６０４を使用して、テンプレート１７０１を既に交換したか否かを調べることができる。送信時は、テンプレート１７０１を既に交換した取引相手には、前述したテンプレート事前交換時の実施例と同様に動作する。テンプレート１７０１をまだ交換していない取引相手には、内部にテンプレート１７０１が含まれた差分ビジネス文書０１１２を生成して交換フラグ１６０４を設定する。ここで、テンプレート１７０１とは、特定項目のデフォルト値が記述されているＸＭＬスキーマファイルであり、このＸＭＬスキーマファイル名はテンプレート識別子１６０３によって示される。
【００６０】
受信時は、差分ビジネス文書１１２にはＸＭＬスキーマが指定されており、各項目値はＸＭＬスキーマのデフォルト値に自動的に置き換わるので、差分を復元する必要はない。ただし、ある相手との最初の取引時には、差分ビジネス文書１１２の中に含まれるＸＭＬスキーマファイルを抽出して、特定の格納位置に保存し、その位置情報をテンプレート管理ＤＢ１６０５のテンプレート識別子１６０３に保存し、交換フラグ１６０４を設定する。
以上で、テンプレートを使う場合で、最初の取引時にテンプレートを交換する場合の実施形態を示した。
【００６１】
【発明の効果】
以上に述べたように、既存のメッセージ交換部と業務処理部との間に差分処理部を設けることで、１つの電子商取引システムによる不特定多数の相手との取引を可能にし、かつ、本発明システムを実施している相手との取引時には取引データ量を削減できる。
【００６２】
その結果、暗号化や復号化の処理量が減るので、その分トランザクション量を増やすことができる。また、インターネットの利便性が高まり、インターネット取引の利用者が増える。さらに、頻繁に取引をする相手とは無駄のない差分ビジネス文書、そうでない相手とは通常のビジネス文書と、相手に応じてビジネス文書の交換方法を使い分けることができる。
【図面の簡単な説明】
【図１】本発明のソフトウェア構成と、そのモジュール間を流れるデータを示す。
【図２】本発明を、メッセージングハブを用いたネットワークに利用した例である。
【図３】差分処理部の中のモジュールと、送信時及び受信時のデータの流れを示す。
【図４】送信時の差分制御部の中で行う処理のフローチャートである。
【図５】受信時の差分制御部の中で行う処理のフローチャートである。
【図６】送信するビジネス文書と過去の取引との類似度計算アルゴリズムである。
【図７】２つのビジネス文書間におけるタグのパス情報の対応付けを示す。
【図８】送信するビジネス文書と類似取引との差分ビジネス文書を生成するアルゴリズムである。
【図９】受信した差分ビジネス文書と類似取引から元のビジネス文書を復元するアルゴリズムである。
【図１０】送信するビジネス文書を基準にして、類似取引との差分ビジネス文書を生成する方法を示す。
【図１１】類似取引を基準にして、送信するビジネス文書との差分ビジネス文書を生成する方法を示す。
【図１２】受信した差分ビジネス文書を基準にして、類似取引から元のビジネス文書を復元する方法を示す。
【図１３】類似取引を基準にして、受信した差分ビジネス文書から元のビジネス文書を生成する方法を示す。
【図１４】取引相手管理ＤＢの詳細を示す。
【図１５】履歴ＤＢの詳細を示す。
【図１６】テンプレート管理ＤＢの詳細を示す。
【図１７】テンプレートの構成例である。
【符号の説明】
１０１：ＢｔｏＢサーバ、１０２：インターネット、１０３：業務処理部、
１０４：差分処理部、１０５：メッセージ交換部、１０６：取引相手管理ＤＢ、
１０７：履歴ＤＢ、１１１…ビジネス文書、１１２：差分ビジネス文書、
１１３：ＢｔｏＢ標準メッセージ、２０１：メッセージングハブ、
３０１：履歴検索部、３０２：差分生成・復元部、３１１：配信情報、
３１２：類似取引、３１３：類似取引ＩＤ、１７０１：テンプレート
【発明の属する技術分野】
本発明は、通信ネットワークを介して接続された少なくとも１つの計算機のそれぞれの間でビジネス文書を交換する企業間電子商取引システムに関する。特に、ビジネス文書の交換における通信データ量削減方法に関する。
【０００２】
【従来の技術】
近年、インターネットの普及や、ＸＭＬ等の標準データ交換技術の確立により、オープンな通信ネットワーク環境での企業間電子商取引（ＢｔｏＢ）が行われ始めている。これに伴い、企業間電子商取引において取引企業間で電子化されたビジネス文書を転送するための、情報処理技術に関する標準仕様の策定が行われてきた。
【０００３】
こうした標準仕様では、取引企業間で交換する電子化されたビジネス文書の形式に関する取り決めや、ビジネス文書を取引先企業へ送信する際のメッセージ形式（ＢｔｏＢ標準メッセージ形式）に関する取り決め等が定められている。
【０００４】
ＢｔｏＢ標準メッセージの具体的な形式を規定している団体には、RosettaNet等がある。RosettaNetは、ビジネス文書の形式に関する取り決めを、Partner Interface Processesによって定めている。また、送信の際のメッセージ形式に関する取り決めをRosettaNet Implementation Frameworkによって定めている。
【０００５】
従来の企業間電子商取引では、取引企業間で独自に通信データの形式を規定していたため、１つの取引相手ごとに１つの電子商取引システムが必要であった。しかし、上述の標準仕様の策定によって、ある企業でＢｔｏＢ標準仕様に準拠した電子商取引システムを１つ用意すれば、システムやメッセージ形式を変更しなくても、ＢｔｏＢ標準準拠の電子商取引システムを備えた不特定多数の企業との取引を行なえる。
【０００６】
【発明が解決しようとする課題】
上述の企業間電子商取引における標準仕様では、ビジネス文書に対する形式が厳密に決められている。例えば、ビジネス文書内に含めなければならないデータ項目は、標準仕様に規定されている。しかしながら、企業間電子商取引において一旦特定の企業間で商取引を始めると、毎回の取引案件において決まった値を送ることになるデータ項目も少なくない。例えば、定期的に同じ商品を数量のみを変えて発注し、注文した商品を同じ場所へ配送する場合など、商品名、商品コードや配送先のデータ項目は、発注のたびに同じデータを送信することになる。
【０００７】
現在、企業間電子商取引市場は急速に成長しつつあり、ネットワークにおける通信トラフィックの増加が予想されている。このような状況の中で、冗長性の高いＢｔｏＢ標準フォーマットの使用は非効率である。また、企業間電子商取引におけるビジネス文書交換では、機密性等のセキュリティ要件も厳しく、電子暗号技術によるビジネス文書の暗号化や電子署名を行う必要がある場合が多い。
【０００８】
電子暗号処理は計算コストが高いので、冗長性の高いＢｔｏＢ標準フォーマットを使用することは、情報処理システムへの処理負荷へ直接影響し、システムの高コスト化を招く原因となりうる。
【０００９】
通信データ量を削除する技術としてはデータ圧縮技術等がある。例えば、特開２００１−２１７７２０では、ＸＭＬ文書のデータ圧縮方法について述べている。しかし、送信するビジネス文書や、ＢｔｏＢ標準メッセージに対して、これらの通信データ圧縮技術をそのまま適用すると、ＢｔｏＢ標準仕様に従ったメッセージ形式が崩れてしまい、ＢｔｏＢ標準準拠のシステムで文書の書式チェックエラーが起きてしまう。
【００１０】
また、ＢｔｏＢ標準フォーマットを使用せずに電子商取引を行う場合、取引企業間で独自にメッセージ形式を規定する必要があり、特定の取引先企業のみしか取引のできない電子商取引システムになってしまう。
【００１１】
本発明の目的は、１つのＢｔｏＢ標準準拠の電子商取引システムを用いて、不特定多数の取引相手との商取引を可能にしつつ、電子商取引の際の通信データ量を削減する方法を提供する。
【００１２】
【課題を解決するための手段】
本発明では、通信ネットワークを介して接続された少なくとも１つの計算機のそれぞれの間でビジネス文書を交換するＢｔｏＢ標準フォーマットを使用する企業間電子商取引システムにおいて、業務処理部とメッセージ交換部から構成されているそれぞれの計算機に新たに差分処理部を設ける。差分処理部は、送信時は、取引相手や取引内容に応じて、過去に送信済みのビジネス文書と、今回送信するビジネス文書との差分情報を、ＢｔｏＢ標準メッセージ形式の範囲内で生成し、取引相手へ送信する。受信時は、過去に受信済みのビジネス文書と差分情報から、今回受信したビジネス文書を復元する。
【００１３】
既存のデータ圧縮技術を、単純にビジネス文書に用いると、出力されるデータは、圧縮アルゴリズムに依存したバイト列になるので、既存の企業間電子商取引システムでは処理できない。しかし、本発明の差分生成方法を用いると、ＢｔｏＢ標準仕様に従ったビジネス文書のＸＭＬ文書構造を崩さずに、冗長なデータを削減できる。
【００１４】
【発明の実施の形態】
まず、取引履歴情報を用いて通信データ量を削除する場合の一実施例を図を用いて説明する。
図１は、本発明における企業間電子商取引システムの全体図である。送信側及び受信側それぞれのＢｔｏＢサーバ１０１は、業務処理部１０３、差分処理部１０４、メッセージ交換部１０５から構成されて、互いにインターネット１０２を介して接続されている。
【００１５】
差分処理部１０４は、取引相手管理ＤＢ１０６と履歴ＤＢ１０７にアクセスできる。業務処理部１０３は、送信時は、業務処理に応じて取引相手に送るビジネス文書１１１を生成する。受信時は、受け取ったビジネス文書１１１の内容に応じて適切な業務処理を行う。
【００１６】
差分処理部１０４は、送信時は、業務処理部１０３からビジネス文書１１１を受け取り、ビジネス文書１１１の内容及び取引相手、履歴ＤＢ１０７の情報を元に、差分ビジネス文書１１２を生成する。受信時は、メッセージ交換部１０５から差分ビジネス文書１１２を受け取り、差分ビジネス文書１１２及び取引相手、履歴ＤＢ１０７の情報を元に、ビジネス文書１１１を復元する。
【００１７】
メッセージ交換部１０５は、送信時は、差分ビジネス文書１１２を受け取り、差分ビジネス文書１１２を含むＢｔｏＢ標準メッセージ１１３を生成して取引相手に送信する。受信時は、ＢｔｏＢ標準メッセージ１１３を受け取り、ＢｔｏＢ標準メッセージ１１３の書式チェックを行い、その中に含まれる差分ビジネス文書１１２を取り出す。
【００１８】
図２は、本発明を、メッセージングハブ２０１を用いたネットワークに応用した例である。
【００１９】
本発明システムを実装したＢｔｏＢサーバ１０１と、メッセージングハブ２０１との間は、差分形式のＢｔｏＢ標準メッセージ１１３を用いて通信する。メッセージングハブ２０１と、本発明システムを実装していないＢｔｏＢサーバ２０２との間は、通常のＢｔｏＢ標準メッセージ２１１を用いて通信する。メッセージングハブ２０１を用いることにより、本発明システムを実装したＢｔｏＢサーバ１０１と、本発明システムを実装していないＢｔｏＢサーバ２０２との間でも、部分的に通信データ量を削減できる。図２に示す形態のネットワークの例として、ｅマーケットプレイスなどが挙げられる。
【００２０】
図３は、差分処理部１０４の内部のモジュール構成とデータの流れを示す。差分処理部１０４は、履歴検索部３０１と差分生成・復元部３０２から構成される。
【００２１】
送信時に、差分処理部１０４は、業務処理部１０３から配信情報３１１とビジネス文書１１１を渡される。配信情報３１１には、取引相手識別子１５０２が含まれる。これらの情報は、まず履歴検索部３０１に渡される。履歴検索部３０１は、配信情報３１１とビジネス文書１１１を受け取ると、まず、配信情報３１１から取引相手識別子１５０２を取得し、取引相手管理ＤＢ１０６を検索して、取引相手の電子商取引システムが本発明システムを実装しているか否かを調べる。次に、履歴検索部３０１は、履歴ＤＢ１０７を検索し、ビジネス文書１１１と内容が類似する類似取引３１２を取得する。ビジネス文書１１１と類似取引３１２は、差分生成・復元部３０２に渡される。
【００２２】
差分生成・復元部３０２は、ビジネス文書１１１と類似取引３１２から差分ビジネス文書１１２を生成し、類似取引３１２から、類似取引３１２の識別子である類似取引ＩＤ３１３を取得する。
【００２３】
配信情報３１１、差分ビジネス文書１１２及び類似取引ＩＤ３１３は、メッセージ交換部１０５に渡されてＢｔｏＢ標準メッセージ１１３の中に組み込まれる。
受信時に、差分処理部１０４は、メッセージ処理部１０５がＢｔｏＢ標準メッセージ１１３から取得した配信情報３１１、差分ビジネス文書１１２及び類似取引ＩＤ３１３を渡される。これらの情報は、まず履歴検索部３０１に渡される。
【００２４】
履歴検索部３０１は、配信情報３１１から取引相手識別子１５０２を取得し、取引相手管理ＤＢ１０６を検索して、取引相手の電子商取引システムが本発明システムを実装しているか否かを調べる。次に、履歴検索部３０１は、受信したＢｔｏＢ標準メッセージ１１３が差分ビジネス文書１１２を含むかを確認し、類似取引ＩＤ３１３をキーにして履歴ＤＢ１０７を検索し、類似取引３１２を取得する。類似取引３１２と差分ビジネス文書１１２は差分生成・復元部３０２に渡される。
【００２５】
差分生成・復元部３０２は、類似取引３１２と差分ビジネス文書１１２からビジネス文書１１１を復元する。復元されたビジネス文書１１１と配信情報３１１は、業務処理部１０３に渡される。
【００２６】
図１４は、取引相手管理ＤＢ１０６の詳細である。取引相手識別子１４０１は、取引相手をシステム内で一意に識別する識別子である。システム対応フラグ１４０２は、取引相手識別子１４０１が示す相手の電子商取引システムが、本発明システムを実装しているか否かを示すフラグである。
【００２７】
図１５は、履歴ＤＢ１０７の詳細である。取引ＩＤ１５０１は、取引の識別子である。取引相手識別子１５０２は、取引相手の識別子である。文書構造定義１５０３は、その取引が従う文書の形式である。文書構造定義１５０３の例には、ＤＴＤファイル名などがある。取引履歴１５０４は、過去に行われた取引のビジネス文書の実データである。
【００２８】
図４は、ＢｔｏＢサーバ１０１における送信時の処理のフローチャートである。
【００２９】
ビジネス文書１１１と配信情報３１１を生成する（ステップ４０１）。配信情報３１１に含まれる取引相手識別子１５０２を元に、取引相手管理ＤＢ１０６を検索し、取引相手の電子商取引システムが本発明システムを実装しているか否かを調べる（ステップ４０２）。本発明システムを実装している場合はステップ４０３へ進み、実装していなければステップ４０６へ進む。ビジネス文書１１１と内容が類似した過去の類似取引３１２を履歴ＤＢ１０７から検索する（ステップ４０３）。検索方法の詳細は後述する。類似取引が存在する場合はステップ４０４へ進み、存在しない場合はステップ４０６へ進む。今回送信するビジネス文書１１１と過去の類似取引３１２から差分ビジネス文書１１２を生成する（ステップ４０４）。差分ビジネス文書１１２の生成方法の詳細は後述する。差分ビジネス文書１１２を含むＢｔｏＢ標準メッセージ１１３を生成して取引相手に送信する（ステップ４０５）。ビジネス文書１１１を含むＢｔｏＢ標準メッセージ２１１を生成して取引相手に送信する（ステップ４０６）。
【００３０】
ここで、図４のステップ４０３における、類似取引３１２の検索方法の詳細を説明する。
【００３１】
まず、今回送信するビジネス文書１１１、取引相手識別子１５０２及び文書構造定義１５０３が同じである過去の取引を履歴ＤＢ１０７から検索する。次に、検索の結果取得される取引１件ごとに、今回送信するビジネス文書１１１との類似度を計算する。類似度の計算方法は後述する。類似度の計算が終了したら、類似度が最大の過去の取引を探す。その類似度が予め設定された値を超えていたら、その過去の取引を類似取引３１２とする。類似度が上記の値を超えていなければ、類似取引３１２は存在しないと判断する。
【００３２】
次に、図６によって、過去の取引と今回送信するビジネス文書１１１との類似度計算方法を説明する。ここで、元文書は、過去の取引または今回送信するビジネス文書１１１である。対象文書は、元文書が過去の取引の場合は、今回送信するビジネス文書１１１であり、元文書が今回送信するビジネス文書１１１の場合は、過去の取引である。
【００３３】
文書の重みに０を代入する（ステップ６０１）。元文書のタグを展開したツリー構造上のノードを辿る（ステップ６０２）。辿るタグがまだ存在する場合は、ステップ６０４へ進む（ステップ６０３）。辿るタグがもう存在しない場合は、現在の文書の重みを類似度として終了する。現在位置のタグが、子タグを持たない末端のタグである場合はステップ６０５へ進む（ステップ６０４）。そうでない場合はステップ６０２へ進む。現在位置のタグと同じパス情報を持つタグを、対象文書上のタグの中から探す（ステップ６０５）。パス情報の詳細は後述する。現在位置のタグの値と、ステップ６０５で探したタグの値が一致する場合は、ステップ６０７に進む（ステップ６０６）。タグの値が一致しない場合、もしくは、ステップ６０５で探したタグが存在しない場合、ステップ６０２に進む。文書の重みに、現在位置のタグの値の長さを加算する（ステップ６０７）。
【００３４】
以上で、過去の取引と今回送信するビジネス文書１１１との類似度計算方法を説明した。この類似度計算方法では、タグが文書定義上必須である場合も省略可能である場合も同様に扱っている。ここで、省略可能タグの値が一致する場合は、そのタグを省略するようにすれば、より多くの余剰データを削減できる。この場合は、受信側で、値が一致したためにタグを省略したのか、今回の取引文書では予めタグが省略してあったのかを区別するために、予めタグが省略してあった場合には、その旨を示す特定記号をタグの値として差分ビジネス文書１１２に書き込む。
【００３５】
図７は、図６のステップ６０５における、パス情報の対応付けの方法を示す。パス情報は、ツリー構造の頂点からタグを辿る順番に、タグ名を区切り記号で区切って並べたものである。同じタグの子タグの中に同名のタグが複数ある場合は、タグ名の後に出現順序を付ける。区切り記号を「／」としたとき、タグ７０３とタグ７０６のパス情報は「／注文／取引相手」である。また、タグ７０４とタグ７０７のパス情報は「／注文／商品情報［１］／値段」であり、タグ７０５とタグ７０８のパス情報は「／注文／商品情報［２］／個数」である。出現順序が付いていないタグ名は、出現順序が１であるタグ名と同じであると見なす。従って、「／注文／商品情報」と「／注文／商品情報［１］」は同じパス情報である。
【００３６】
次に、図８に、図４のステップ４０４における、差分ビジネス文書１１２の生成方法の詳細を示す。ここで、元文書は、類似取引３１２またはビジネス文書１１１である。元文書が類似取引３１２である場合、対象文書はビジネス文書１１１である。元文書がビジネス文書１１１である場合、対象文書は類似取引３１２である。元文書がビジネス文書１１１である場合、ステップ８０４とステップ８０７は処理を行わずにスキップし、このときステップ８０３からは常にステップ８０５へ進む。
【００３７】
元文書のタグを展開したツリー構造上のノードを辿る（ステップ８０１）。辿るタグがまだ存在する場合はステップ８０３へ進み、辿るタグがもう存在しない場合はステップ８０７へ進む（ステップ８０２）。現在位置のタグと同じパス情報を持つタグを、対象文書上のタグの中から探す（ステップ８０３）。現在位置のタグと同じパス情報を持つタグが、対象文書上に存在する場合はステップ８０５へ進み、存在しない場合はステップ８０１へ進む（ステップ８０４）。現在位置のタグが子タグを持たない末端タグである場合はステップ８０６へ進み、そうでない場合はステップ８０９へ進む（ステップ８０５）。現在位置のタグの値と、ステップ８０３で探したタグの値が一致する場合は、ステップ８０８へ進み、そうでない場合はステップ８０９へ進む（ステップ８０６）。対象文書中のタグで未参照であるもののタグ名とタグ値を全て差分ビジネス文書０１１２へ書き込む（ステップ８０７）。現在位置のタグの値を特定記号に置き換えたものを差分ビジネス文書１１２に書き込む（ステップ８０８）。差分ビジネス文書１１２のタグ値は特定記号に置き換わる。ここで、特定記号とは、文字数が長いタグ値の情報量を削減するために置き換える文字数が短い値である。現在位置のタグ名とタグ値を差分ビジネス文書１１２に書き込む（ステップ８０９）。
【００３８】
図５は、ＢｔｏＢサーバ１０１における受信時の処理のフローチャートである。
受信したＢｔｏＢ標準メッセージ１１３の形式がＢｔｏＢ標準仕様に従うかの書式チェックを行う（ステップ５０１）。受信したＢｔｏＢ標準メッセージ１１３が差分ビジネス文書１１２を含むか否かを、類似取引ＩＤ３１３の有無によって調べる（ステップ５０２）。差分ビジネス文書１１２を含む場合はステップ５０３へ進み、含まない場合は終了する。類似取引ＩＤ３１３をキーに履歴ＤＢ１０７を検索して類似取引３１２を取得する（ステップ５０３）。差分ビジネス文書１１２と過去の類似取引３１２から元のビジネス文書１１１を復元する（ステップ５０４）。ビジネス文書１１１の復元方法の詳細は後述する。ビジネス文書１１１の内容に応じた業務処理を行う（ステップ５０５）。
【００３９】
次に、図９は、図５のステップ５０４における、ビジネス文書１１１の復元方法の詳細を示す。ここで、元文書は類似取引３１２または差分ビジネス文書１１２である。元文書が類似取引３１２である場合、対象文書は差分ビジネス文書１１２である。元文書が差分ビジネス文書１１２である場合、対象文書は類似取引３１２である。元文書が差分ビジネス文書１１２である場合、ステップ９０４とステップ９０７は処理を行わずにスキップする。このときステップ９０３からは常にステップ９０５へ進む。
【００４０】
元文書のタグを展開したツリー構造上のノードを辿る（ステップ９０１）。辿るタグがまだ存在する場合はステップ９０３へ進み、辿るタグがもう存在しない場合はステップ９０７へ進む（ステップ９０２）。現在位置のタグと同じパス情報を持つタグを対象文書上のタグの中から探す（ステップ９０３）。現在位置のタグと同じパス情報を持つタグが対象文書上に存在する場合はステップ９０５へ進み、存在しない場合はステップ９０１へ進む（ステップ９０４）。現在位置のタグが子タグを持たない末端タグである場合はステップ９０６へ進み、そうでない場合はステップ９０９へ進む（ステップ９０５）。現在位置のタグの値が特定記号である場合はステップ９０８へ進み、そうでない場合はステップ９０９へ進む（ステップ９０６）。対象文書中のタグで、未参照であるもののタグ名とタグ値を全て復元するビジネス文書１１１へ書き込む（ステップ９０７）。ステップ９０３で探した対象文書上のタグ名とタグ値を、復元するビジネス文書１１１に書き込む（ステップ９０８）。現在位置のタグ名とタグ値を、復元するビジネス文書１１１に書き込む（ステップ９０９）。
【００４１】
図１０に、送信時の差分生成（図４のステップ４０４、図８）における、元文書が今回送信するビジネス文書１１１である場合のデータの流れを示す。
【００４２】
元文書のタグが末端タグではないので、そのまま差分ビジネス文書１１２に書き込む（矢印１００１）。元文書のタグが末端タグであり、値が対象文書のタグ値と一致するので、差分ビジネス文書１１２に、値を特定記号に置き換えたタグを書き込む（矢印１００２）。ここでは特定記号を「Ｘ」とする。元文書のタグが末端タグであり、値が対象文書のタグ値と一致しないので、元文書のタグ名とタグ値をそのまま差分ビジネス文書１１２に書き込む（矢印１００３）。元文書のタグが末端タグであり、値が対象文書のタグ値と一致しない（対象文書には値がない）ので、元文書のタグ名とタグ値をそのまま差分ビジネス文書１１２に書き込む（矢印１００４）。対象文書にタグがあっても元文書にタグがない場合は、無視されるので自動的に省略される（矢印１００５）。
【００４３】
図１１に、送信時の差分生成（図４のステップ４０４、図８）における、元文書が類似取引３１２である場合のデータの流れを示す。
【００４４】
元文書のタグが末端タグではないので、そのまま差分ビジネス文書１１２に書き込む（矢印１１０１）。元文書のタグが末端タグであり値が対象文書のタグ値と一致するので、差分ビジネス文書１１２に、値を特定記号に置き換えたタグを書き込む（矢印１１０２）。ここでは特定記号を「Ｘ」とする。元文書のタグが末端タグであり値が対象文書のタグ値と一致しないので、元文書のタグ名とタグ値をそのまま差分ビジネス文書１１２に書き込む（矢印１１０３）。元文書にはタグがないが対象文書にはタグがあるので、対象文書のタグ名とタグ値を差分ビジネス文書１１２に書き込む（矢印１１０４）。（ステップ８０７で、未参照タグとして書き込まれる。）元文書にはタグがあるが対象文書にはタグがないので、無視される（矢印１１０５）。（ステップ８０４からステップ８０１に進むので何も処理されない。）
図１２に、受信時の差分復元（図５のステップ５０４、図９）における、元文書が差分ビジネス文書１１２である場合のデータの流れを示す。
【００４５】
元文書のタグが末端タグではないので、そのまま復元するビジネス文書１１１に書き込む（矢印１２０１）。元文書のタグが末端タグであり、値が特定記号なので、対象文書からパス情報が同じタグの値を取得し、その値を復元するビジネス文書１１１に書き込む（矢印１２０２）。元文書の値が特定記号ではないので、その値を復元するビジネス文書１１１に書き込む（矢印１２０３）。対象文書には値があるが元文書には値がないので、無視される（矢印１２０４）。
【００４６】
図１３に、受信時の差分復元（図５のステップ５０４、図９）における、元文書が類似取引３１２である場合のデータの流れを示す。
【００４７】
元文書のタグが末端タグではなく、対象文書に同じパス情報のタグが存在するので、そのまま復元するビジネス文書１１１に書き込む（矢印１３０１）。元文書のタグが末端タグであり、対象文書の同じパス情報のタグの値が特定記号なので、元文書のタグ名とタグ値を復元するビジネス文書１１１に書き込む（矢印１３０２）。元文書のタグが末端タグであり、対象文書の同じパス情報のタグの値が通常値なので、対象文書のタグ名とタグ値を復元するビジネス文書１１１に書き込む（矢印１３０３）。元文書にはタグがないが対象文書にタグがあるので、対象文書のタグ名とタグ値を復元するビジネス文書１１１に書き込む（矢印１３０４）。（ステップ９０７で、未参照タグとして書き込まれる。）元文書にタグがあるが対象文書にはタグがないので、無視される（矢印１３０５）。（ステップ９０４からステップ９０１に進むので何も処理されない。）
以上で、取引履歴情報を用いた本発明の一実施例を示した。
【００４８】
次に、取引相手と事前に交換したテンプレートを用いて通信データ量を削除する場合の一実施例を図を用いて説明する。この実施例は、上述した履歴ＤＢ使用時の実施例で用いた類似取引３１２の代わりにテンプレート１７０１を使用するものである。図１７にテンプレートの例を示す。テンプレート１７０１は、ビジネス文書１１１であって、かつ、取引のたびに同じ値を使用するタグに予め値が設定されているものである。
【００４９】
以下では、履歴ＤＢ使用時との相違点のみを説明する。まず、本実施形態のシステムの構成に関し、図１の履歴ＤＢ１０７はテンプレート管理ＤＢ１６０５に置き換わる。
【００５０】
次に、本実施形態におけるデータの流れに関し、図３の類似取引３１２はテンプレート１７０１に置き換わり、類似取引ＩＤ３１３はテンプレートＩＤ１６０３に置き換わる。
【００５１】
次に、送受信時のフローチャートに関し、送信時における図４のステップ４０３は「取引相手識別子１６０１と文書構造定義１６０２の組がビジネス文書１１１と一致するテンプレート１７０１が存在するか？」に置き換わる。ここでは、取引相手識別子１６０１と文書構造定義１６０２が一致するテンプレート１７０１を、テンプレート管理ＤＢ１６０５から取得する。
【００５２】
また、ステップ４０４は「今回のビジネス文書１１１とテンプレート１７０１から、差分ビジネス文書１１２を生成する」に置き換わる。差分生成方法は、履歴ＤＢと同様の方法を用いる。ただし、類似取引３１２をテンプレート１７０１に置き換える。また、テンプレート１７０１内のタグで値が設定されていないものは、タグが存在しないと見なす。
【００５３】
受信時については、図５におけるステップ５０３は「テンプレート１７０１を、テンプレート管理ＤＢ１６０５から取得する」に置き換わる。テンプレート１７０１は、受信したＢｔｏＢ標準メッセージ１１３に含まれるテンプレートＩＤ１６０３、または、取引相手識別子１６０１とビジネス文書の文書構造定義１６０２を用いて取得する。
【００５４】
また、ステップ５０４は「差分ビジネス文書１１２とテンプレート１７０１から、今回のビジネス文書１１１を復元する」に置き換わる。差分復元方法は、履歴ＤＢ使用時と同様の方法を用いる。ただし、類似取引３１２をテンプレート１７０１に置き換える。また、テンプレート１７０１内のタグで値が設定されていないものは、タグが存在しないと見なす。
【００５５】
図１６は、テンプレートを使用する本実施例におけるテンプレート管理ＤＢ１６０５の詳細である。
【００５６】
取引相手識別子１６０１は取引相手の識別子である。文書構造定義１６０２は、その取引が従う文書の形式である。文書構造定義１６０２は例えばＤＴＤファイル名などである。テンプレート識別子１６０３はテンプレートの識別子である。テンプレート識別子１６０３は例えばファイル名などである。交換フラグ１６０４は、テンプレートを最初の取引時に交換する場合の後述する実施例で使用され、取引相手とテンプレート１７０１を既に交換したか否かを示すフラグである。
【００５７】
以上で、テンプレートを使う場合で、テンプレートを取引相手と事前に交換する場合の実施形態を説明した。
【００５８】
次に、テンプレートを使う場合で、最初の取引時にテンプレートを交換する場合の実施形態を示す。ここでは、テンプレートを取引相手と事前に交換する場合との相違点のみを説明する。
【００５９】
この実施形態のシステムの構成は、テンプレート１７０１を事前に交換する場合と同じである。ただし、テンプレート管理ＤＢ１６０５のカラムの交換フラグ１６０４を使用して、テンプレート１７０１を既に交換したか否かを調べることができる。送信時は、テンプレート１７０１を既に交換した取引相手には、前述したテンプレート事前交換時の実施例と同様に動作する。テンプレート１７０１をまだ交換していない取引相手には、内部にテンプレート１７０１が含まれた差分ビジネス文書０１１２を生成して交換フラグ１６０４を設定する。ここで、テンプレート１７０１とは、特定項目のデフォルト値が記述されているＸＭＬスキーマファイルであり、このＸＭＬスキーマファイル名はテンプレート識別子１６０３によって示される。
【００６０】
受信時は、差分ビジネス文書１１２にはＸＭＬスキーマが指定されており、各項目値はＸＭＬスキーマのデフォルト値に自動的に置き換わるので、差分を復元する必要はない。ただし、ある相手との最初の取引時には、差分ビジネス文書１１２の中に含まれるＸＭＬスキーマファイルを抽出して、特定の格納位置に保存し、その位置情報をテンプレート管理ＤＢ１６０５のテンプレート識別子１６０３に保存し、交換フラグ１６０４を設定する。
以上で、テンプレートを使う場合で、最初の取引時にテンプレートを交換する場合の実施形態を示した。
【００６１】
【発明の効果】
以上に述べたように、既存のメッセージ交換部と業務処理部との間に差分処理部を設けることで、１つの電子商取引システムによる不特定多数の相手との取引を可能にし、かつ、本発明システムを実施している相手との取引時には取引データ量を削減できる。
【００６２】
その結果、暗号化や復号化の処理量が減るので、その分トランザクション量を増やすことができる。また、インターネットの利便性が高まり、インターネット取引の利用者が増える。さらに、頻繁に取引をする相手とは無駄のない差分ビジネス文書、そうでない相手とは通常のビジネス文書と、相手に応じてビジネス文書の交換方法を使い分けることができる。
【図面の簡単な説明】
【図１】本発明のソフトウェア構成と、そのモジュール間を流れるデータを示す。
【図２】本発明を、メッセージングハブを用いたネットワークに利用した例である。
【図３】差分処理部の中のモジュールと、送信時及び受信時のデータの流れを示す。
【図４】送信時の差分制御部の中で行う処理のフローチャートである。
【図５】受信時の差分制御部の中で行う処理のフローチャートである。
【図６】送信するビジネス文書と過去の取引との類似度計算アルゴリズムである。
【図７】２つのビジネス文書間におけるタグのパス情報の対応付けを示す。
【図８】送信するビジネス文書と類似取引との差分ビジネス文書を生成するアルゴリズムである。
【図９】受信した差分ビジネス文書と類似取引から元のビジネス文書を復元するアルゴリズムである。
【図１０】送信するビジネス文書を基準にして、類似取引との差分ビジネス文書を生成する方法を示す。
【図１１】類似取引を基準にして、送信するビジネス文書との差分ビジネス文書を生成する方法を示す。
【図１２】受信した差分ビジネス文書を基準にして、類似取引から元のビジネス文書を復元する方法を示す。
【図１３】類似取引を基準にして、受信した差分ビジネス文書から元のビジネス文書を生成する方法を示す。
【図１４】取引相手管理ＤＢの詳細を示す。
【図１５】履歴ＤＢの詳細を示す。
【図１６】テンプレート管理ＤＢの詳細を示す。
【図１７】テンプレートの構成例である。
【符号の説明】
１０１：ＢｔｏＢサーバ、１０２：インターネット、１０３：業務処理部、
１０４：差分処理部、１０５：メッセージ交換部、１０６：取引相手管理ＤＢ、
１０７：履歴ＤＢ、１１１…ビジネス文書、１１２：差分ビジネス文書、
１１３：ＢｔｏＢ標準メッセージ、２０１：メッセージングハブ、
３０１：履歴検索部、３０２：差分生成・復元部、３１１：配信情報、
３１２：類似取引、３１３：類似取引ＩＤ、１７０１：テンプレート
Claims (10)
- ネットワークを介して接続された計算機間でビジネス文書を交換する電子商取引システムにおける通信データ量削減方法であって、
送信側計算機は、
履歴検索部が、取引相手識別情報及び文書構造定義が送信対象のビジネス文書と対応する類似取引のビジネス文書を履歴データベースから検索し、前記類似取引のビジネス文書と前記送信対象のビジネス文書との類似度を計算し、前記類似度が所定の条件を満たす前記類似取引のビジネス文書を取得し、
差分生成部が、取得した前記類似取引のビジネス文書を元データとして前記送信対象のビジネス文書との差分から差分ビジネス文書を生成し、
メッセージ交換部が、生成された前記差分ビジネス文書と前記類似取引を示す情報とを前記受信側計算機に送信し、
前記受信側計算機は、
履歴検索部が、受信した前記差分ビジネス文書の差分生成の元データとなった前記類似取引のビジネス文書を、前記類似取引を示す情報に基づいて履歴データベースに記憶された受信履歴情報から検索し、
復元部が、前記類似取引のビジネス文書と前記差分ビジネス文書とから前記送信対象のビジネス文書を復元することを特徴とする通信データ量削減方法。 - 前記類似度の計算は、前記送信対象のビジネス文書の文書構造を親タグから子タグへ向けてたどり、前記類似取引のビジネス文書の文書構造を親タグから子タグへ向けてたどり、同一のタグ構造があった場合に、前記類似度を増加させることを特徴とする請求項１記載の通信データ量削減方法。
- 前記同一のタグ構造があった場合に、タグの値に基づいて前記類似度を増加させることを特徴とする請求項２記載の通信データ量削減方法。
- 前記類似度が所定の条件を満たす場合は、前記類似度が所定の値を超える場合であることを特徴とする請求項１から３のいずれかの項に記載の通信データ量削減方法。
- 前記送信側計算機は、
前記履歴検索部が、前記取引相手識別情報に基づいて前記ビジネス文書の受信側計算機が差分ビジネス文書を処理できるか否かを示す情報を記憶した取引相手管理データベースを検索し、検索結果に応じて差分ビジネス文書と送信対象のビジネス文書の何れを送るかを切り替えることを特徴とする請求項１から４のいずれかの項に記載の通信データ量削減方法。 - 前記送信側計算機は、
前記差分生成部が、データ項目の値が前記送信対象のビジネス文書と前記差分生成の元データの双方で一致する場合に、前記データ項目の値を、データ量が小さくなるように予め定められた値に置き換えて前記差分ビジネス文書に設定し、
前記受信側計算機は、
前記復元部が、前記予め定められた値を設定したデータ項目が前記差分ビジネス文書に存在する場合、前記値を前記元データから取得して置き換えることで、前記送信対象のビジネス文書を復元することを特徴とする請求項１から５のいずれかの項に記載の通信データ量削減方法。 - ネットワークを介して接続された計算機間でビジネス文書を交換する電子商取引における通信データ量削減システムであって、
ビジネス文書の送信履歴情報を記憶する履歴データベースと、
取引相手識別情報及び文書構造定義が送信対象のビジネス文書と対応する類似取引のビジネス文書を前記履歴データベースから検索し、前記類似取引のビジネス文書と前記送信対象のビジネス文書との類似度を計算し、前記類似度が所定の条件を満たす前記類似取引のビジネス文書を取得する履歴検索部と、
取得した前記類似取引のビジネス文書を元データとして前記送信対象のビジネス文書との差分から差分ビジネス文書を生成する差分生成部と、
生成された前記差分ビジネス文書と前記類似取引を示す情報とを送信するメッセージ交換部と
を含む送信側計算機と、
ビジネス文書の受信履歴情報を記憶する履歴データベースと、
受信した前記差分ビジネス文書の差分生成の元データとなった前記類似取引のビジネス文書を、前記類似取引を示す情報に基づいて前記履歴データベースに記憶された受信履歴情報から検索する履歴検索部と、
前記類似取引のビジネス文書と前記差分ビジネス文書とから前記送信対象のビジネス文書を復元する差分復元部と
を含む受信側計算機と
を備えることを特徴とする通信データ量削減システム。 - 前記類似度の計算は、前記送信対象のビジネス文書の文書構造を親タグから子タグへ向けてたどり、前記類似取引のビジネス文書の文書構造を親タグから子タグへ向けてたどり、同一のタグ構造があった場合に、前記類似度を増加させることを特徴とする請求項７記載の通信データ量削減システム。
- 前記同一のタグ構造があった場合に、タグの値に基づいて前記類似度を増加させることを特徴とする請求項８記載の通信データ量削減システム。
- 前記類似度が所定の条件を満たす場合は、前記類似度が所定の値を超える場合であることを特徴とする請求項７から９のいずれかの項に記載の通信データ量削減システム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002112818A JP3966051B2 (ja) | 2002-04-16 | 2002-04-16 | 通信データ削減方法およびシステム |
| US10/348,708 US7275057B2 (en) | 2002-04-16 | 2003-01-22 | Method for reducing communication data amount in business to business electronic commerce |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002112818A JP3966051B2 (ja) | 2002-04-16 | 2002-04-16 | 通信データ削減方法およびシステム |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2003308444A JP2003308444A (ja) | 2003-10-31 |
| JP2003308444A5 JP2003308444A5 (ja) | 2005-06-16 |
| JP3966051B2 true JP3966051B2 (ja) | 2007-08-29 |
Family
ID=29267328
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002112818A Expired - Fee Related JP3966051B2 (ja) | 2002-04-16 | 2002-04-16 | 通信データ削減方法およびシステム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US7275057B2 (ja) |
| JP (1) | JP3966051B2 (ja) |
Families Citing this family (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2002012997A1 (en) * | 2000-08-08 | 2002-02-14 | Fineground Networks | Method and system for parameterized web documents |
| US7562041B2 (en) | 2001-01-09 | 2009-07-14 | International Business Machines Corporation | Method and apparatus for facilitating business processes |
| US8660880B2 (en) | 2004-03-04 | 2014-02-25 | International Business Machines Corporation | System and method for workflow enabled link activation |
| JP4756144B2 (ja) * | 2005-09-21 | 2011-08-24 | 和秀 有川 | 商取引システムおよび方法並びにプログラム |
| US8645248B2 (en) * | 2010-10-27 | 2014-02-04 | Hsbc Technology & Services (Usa) Inc. | Integrated customer communications computer system and process for implementing same |
| US9275360B2 (en) | 2010-05-21 | 2016-03-01 | Hsbc Technology & Services (Usa) Inc. | Account opening flow configuration computer system and process for implementing same |
| EP2628091A4 (en) | 2010-10-11 | 2016-04-27 | Hsbc Technology & Services Usa Inc | Computer Architecture and Method for an Application Processing Machine |
| WO2012054572A2 (en) | 2010-10-21 | 2012-04-26 | Hsbc Technologies Inc. | Computer metrics system and process for implementing same |
| JP6330277B2 (ja) | 2013-09-10 | 2018-05-30 | 日本電気株式会社 | 送信装置、送信方法、送信プログラム、及び、中継システム |
| US10489748B2 (en) * | 2015-02-18 | 2019-11-26 | Upwire Pty Ltd. | Managing the generation of text messages |
| US10223362B2 (en) * | 2016-03-31 | 2019-03-05 | International Electronic Business Iii, Inc. | Methods and systems for converting business to business data to a canonical format |
| JP6768182B1 (ja) * | 2020-02-17 | 2020-10-14 | 三菱電機株式会社 | 端末、集約装置、制御回路、記憶媒体、および、データ収集方法 |
Family Cites Families (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH04352538A (ja) | 1991-05-30 | 1992-12-07 | Mitsubishi Electric Corp | 通信装置 |
| US5826017A (en) * | 1992-02-10 | 1998-10-20 | Lucent Technologies | Apparatus and method for communicating data between elements of a distributed system using a general protocol |
| JP2947713B2 (ja) * | 1994-09-21 | 1999-09-13 | 株式会社日立製作所 | 電子化書類回覧システム |
| JPH08161395A (ja) | 1994-12-09 | 1996-06-21 | Toshiba Corp | 電子承認装置 |
| US5915252A (en) * | 1996-09-30 | 1999-06-22 | International Business Machines Corporation | Object oriented framework mechanism for data transfer between a data source and a data target |
| US6496504B1 (en) * | 1998-08-06 | 2002-12-17 | Ricoh Company, Ltd. | Smart allocation of bandwidth for multiple independent calls on a digital network |
| EP1001574A1 (en) * | 1998-11-10 | 2000-05-17 | International Business Machines Corporation | Method and system in a packet switching network for dynamically adjusting the bandwidth of a continuous bit rate virtual path connection according to the network load |
| US6711624B1 (en) * | 1999-01-13 | 2004-03-23 | Prodex Technologies | Process of dynamically loading driver interface modules for exchanging data between disparate data hosts |
| US6321283B1 (en) * | 1999-03-22 | 2001-11-20 | International Business Machines Corporation | Method and apparatus for determining a data transmission capacity between communicatively connected source and target devices |
| US6442569B1 (en) * | 1999-04-26 | 2002-08-27 | General Electric Company | Apparatus and method for data transfer between databases |
| US6625622B1 (en) * | 1999-05-14 | 2003-09-23 | Eisenworld, Inc. | Apparatus and method for transfering information between platforms |
| JP2001014194A (ja) | 1999-07-01 | 2001-01-19 | Fujitsu Ltd | ファイル管理装置 |
| US6694336B1 (en) * | 2000-01-25 | 2004-02-17 | Fusionone, Inc. | Data transfer and synchronization system |
| CA2436517C (en) * | 2000-10-09 | 2011-09-20 | Maximum Availability Limited | Method and apparatus for data processing |
| WO2002097664A1 (en) * | 2001-05-30 | 2002-12-05 | Sap Aktiengesellschaft | Method, system, and computer program for migrating content from source database to target database |
| AU2002340403A1 (en) * | 2001-11-16 | 2003-06-10 | Paralleldb, Incorporated | Data replication system and method |
-
2002
- 2002-04-16 JP JP2002112818A patent/JP3966051B2/ja not_active Expired - Fee Related
-
2003
- 2003-01-22 US US10/348,708 patent/US7275057B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US7275057B2 (en) | 2007-09-25 |
| US20030208526A1 (en) | 2003-11-06 |
| JP2003308444A (ja) | 2003-10-31 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10304133B2 (en) | Distribution of market data | |
| US20190197257A1 (en) | Method and system for electronic delivery of sensitive information | |
| TW495680B (en) | A method and apparatus for electronically integrating data captured in heterogeneous information systems | |
| JP3966051B2 (ja) | 通信データ削減方法およびシステム | |
| US8726015B2 (en) | Methods and apparatus for secure content routing | |
| US7730139B2 (en) | Asynchronous tamper-proof tag for routing e-mails and e-mail attachments | |
| US20020035583A1 (en) | Real-time single entry multiple carrier interface (SEMCI) | |
| US11722583B2 (en) | System and method for asset management and integration | |
| US20080154656A1 (en) | Data Collection System with Document Production Capability | |
| WO2022137834A1 (ja) | 情報管理方法、及び情報管理プログラム | |
| JP2008197788A (ja) | 電子文書送信システム | |
| JP2003308444A5 (ja) | ||
| US6609156B1 (en) | Method and apparatus for reducing redundant multiple recipient message handling in a message handling system | |
| WO2001026004A2 (en) | Method and apparatus for interprocess messaging and its use for automatically generating transactional email | |
| US8230224B2 (en) | Transmitting security data in multipart communications over a network | |
| CN113656466B (zh) | 保单数据查询方法、装置、设备及存储介质 | |
| WO2024084692A1 (ja) | 情報処理装置、情報処理方法及びプログラム | |
| US7711768B1 (en) | System and method for reliably exchanging information across a computer network | |
| JP2002245264A (ja) | Ｘｍｌのｄｔｄ管理システムと方法およびｘｍｌのｄｔｄ流通システムと方法ならびにプログラム | |
| Allen et al. | MIME object definitions for the common indexing protocol (CIP) | |
| JP2002073463A (ja) | データ通信システム、データ通信方法、及び記録媒体 | |
| JP2020108178A (ja) | 電子データ保管サーバ、及び、電子データ保管プログラム | |
| CN116720968A (zh) | 保单的生成方法及装置、存储介质、电子设备 | |
| Allen et al. | RFC2652: MIME Object Definitions for the Common Indexing Protocol (CIP) | |
| JP2010123095A (ja) | 企業間電子商取引の接続方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040914 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040914 |
|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20060419 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20061004 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20061010 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20061211 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070220 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070312 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070508 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070521 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100608 Year of fee payment: 3 |
|
| LAPS | Cancellation because of no payment of annual fees |