JP3774293B2

JP3774293B2 - Billing method

Info

Publication number: JP3774293B2
Application number: JP10291497A
Authority: JP
Inventors: 誠司高野
Original assignee: Nomura Research Institute Ltd
Current assignee: Nomura Research Institute Ltd
Priority date: 1997-04-21
Filing date: 1997-04-21
Publication date: 2006-05-10
Anticipated expiration: 2017-04-21
Also published as: JPH10293621A

Description

【０００１】
【発明の属する技術分野】
本発明は、インターネットによるデータ提供有料サービスであって、いわゆる従量制で課金を行う手段に関する。
【０００２】
【先行技術】
先行技術について、図２および図３を用いて説明する。
近年の販売システムではオンデマンドシステムにより、「情報」という無形物を販売するようになってきた。デジタル化が可能な「情報」という無形物は、オンラインによるネットワークを介して、送受が可能だからである。
【０００３】
まずクライアントがサーバにログインし、サーバはクライアントのＩＤを確認する。ＩＤが確認できた場合には確認できた旨をクライアントへ発信する。すると、クライアントは、サーバから引き出したいデータを特定するコマンド命令を発信し、サーバはこれを受信して、クライアントへデータを発信する。クライアントはデータの受け取り確認をサーバへ発信し、サーバは、その受け取り確認を受信したときに、クライアントへ対価の要求、いわゆる「課金」を行う。
【０００４】
なお、クライアントからサーバへ発信される受け取り確認は、通信用のソフトウェアが自動的に行うことも多い。ところで、インターネットによってクライアント側が欲するデータをサーバ側が販売するサービスにあっては、図３に示すように、通信プロトコル上ではサーバ側にて受け取り確認ができない。そのため、クライアントへの課金は、コネクション型とは異なり、以下のような手段によって行われてきた。
【０００５】
まず第一の手段としては、通信制御プログラムを、インターネット通信用のソフトウェアの上位に組み込み、セッション管理を可能とするものである。
第二の手段としては、クライアント側へ販売のためのデータを発信したときに課金を行ってしまうものである。
第三の手段としては、いわゆる固定制料金を設定することによって、サービス提供ごとの「課金」は行わない、という手段である。
【０００６】
【発明が解決しようとする課題】
しかしながら、上記の手段はいずれも以下のような欠点を抱えていた。
第一の手段にあっては、サーバ側が通信制御プログラムを提供するものの、クライアント側がその通信制御用プログラムを自分のコンピュータに組み込まなければならないという手間が掛かる。
【０００７】
第二の手段にあっては、データを発信しても通信トラブルによってクライアントがデータを受け取ることができない場合にも、課金されてしまうことになる。通信トラブルに関してはサーバ側が責任を負わないという業務スタイルであり、通信トラブルの頻度が極めて低いとは言えない現状にあっては、クライアント側にかかる経済的、心理的負担があるのでクライアントのデメリットは小さくない。
【０００８】
第三の手段は、通信トラブルに関してはサーバ側が責任を負うという業務スタイルであり、クライアント側には責任がない。しかし、固定制料金に見合うニーズまでを必要としないユーザには合理的な料金ではなく、固定制料金に見合わないほどの大容量のデータを要求するクライアントがいた場合には、サーバの負担が大きいこととなってしまう。
【０００９】
以上説明したように、インターネットを利用したデータ提供有料サービスにおいては、クライアント側、サーバ側のいずれに対する負担も小さく、経済的負担も合理的な課金の手段が存在しなかった。
本発明が解決すべき課題は、インターネットを利用したデータ提供有料サービスにおいて、クライアント側、サーバ側のいずれに対する負担も小さく、経済的負担も合理的な課金手段に関する技術を提供することにある。
【００１０】
ここで、請求項１および請求項２記載の発明の目的は、インターネットを利用したデータ提供有料サービスにおいて、クライアント側、サーバ側のいずれに対する負担も小さく、経済的負担も合理的な課金方法であって、データを再送信するか否かの選択をクライアント側に委ねて合理的に運用するための課金方法を提供することである。
【００１１】
【課題を解決するための手段】
上記した課題を解決するため、本出願人は、前記した請求項１および請求項２に記載した発明を提供する。
（請求項１）
請求項１記載の発明は、インターネットを用いてクライアントへデータ供給サービスを行うサーバにおいて、クライアントからのデータ供給の要求を受けつける要求受付手順と、過去に当該要求と同じ要求があったか否かを判断し、履歴があると判断した場合には課金しないと判断するとともに、履歴がないと判断した場合には課金すると判断する課金判断手順と、課金すると判断する場合には要求の履歴を記録する履歴記録手順とを含む課金方法である。
そして、その履歴記録手順において記録する履歴は、ユーザＩＤおよびコマンドとし、前記要求受付手順においてはクライアントが履歴記録手順の必要不要を選択可能とし、履歴記録手順が不要である旨の選択をした場合には、履歴記録手順を踏まないこととしたことを特徴とする。
【００１２】
（作用）
要求受付手順においては、クライアントからのコマンドをサーバが受信する。
履歴記録手順には、クライアントを特定するためのクライアント情報（たとえばクライアントのＩＤ）と、当該クライアントから受信したコマンドとを対応させて記録する。
【００１３】
履歴記録手順において、要求受付手順におけるクライアントからのコマンドとクライアント情報とを対応させて記録しているので、データ送信にエラーが生じてクライアントがデータを受け取れなくても、同じデータを再度要求した場合には課金されない。したがって、通信制御用プログラムを自分のコンピュータに組み込む必要はなく、データ送信のエラーに基づくクライアントへの経済的負担もなく、固定制料金よりも合理的な従量制料金となる。サーバ側にとってもデータ送信にエラーが生じた場合にのみ経済的な負担をすればよいので、固定料金制の場合に比べて合理的な料金となる。
履歴記録手順における記録回数を有限とすることによって、過去に同一コマンドがあるが、送信エラーなどが原因ではなくて本来課金すべき新たな要求として位置づけられるコマンドに対しては課金することができ、サーバ側にとっての経済的な不合理を回避することができる。
【００１４】
クライアントが履歴記録手順を不要であると選択した場合には、履歴記録手順を行わない。その場合、クライアントが要求したデータが送信エラーによって届かず、再度送信を要求したとしても、再送信の際に課金される。
【００１５】
（請求項２）
請求項２記載の発明は、請求項１に記載の課金方法を限定したものであり、
履歴記録手順が不要である旨の選択をした場合には、必要である旨の選択をした場合に比べて課金額を小さくすることとしたことを特徴とする。
【００１６】
（作用）
クライアントが履歴記録手順を不要であると選択した場合には、履歴記録手順を行わないので、クライアントが要求したデータが送信エラーによって届かず、再度送信を要求したとしても、再送信の際に課金される。しかし、本請求項の発明では課金される額が小さくなるので、送信エラーがない場合には割安の料金で利用できる。
【００１７】
なお、履歴記録手順によって記録された履歴は、クライアント側から確認することができるように形成してもよい。その場合、クライアントは、履歴記録手順によって記録された履歴を確認することができるので、送信エラーによってデータが届かなかった場合などに、その履歴を確認し、再度送信を要求すればよいので、安心して使用することができる。
【００１８】
【発明の実施の形態】
以下、本発明を実施の形態および図面に基づいて更に詳しく説明する。ここで使用する図面は図１であり、本発明の第一の実施の形態を示す概念図である。
【００１９】
（第一の実施の形態）
図１に基づいて、第一の実施の形態について説明する。
この実施の形態は、インターネットを用いてクライアントへデータ供給サービスを行うサーバにおいて用いる課金方法である。
図示は省略するが、まずクライアントがサーバにログインし、サーバはクライアントのＩＤを確認する。ＩＤが確認できた場合には、データ供給の要求が可能である旨をクライアントへ発信する。
【００２０】
続いて、クライアントは、データ供給を要求するためのコマンドを送信し、サーバはこれを受信する。次に、サーバは、クライアントのＩＤと当該コマンドとを対応させ、履歴記録がなされているか否かを判断する。履歴記録には存在しない場合には、履歴記録のデータベースに記録し、課金を行う旨の手続をとってから、当該コマンドに対応するデータをクライアントへ送信する。
履歴記録に存在する場合には、課金を行わない旨の手続をとってから、当該コマンドに対応するデータをクライアントへ送信する。
【００２１】
履歴記録手順において、要求受付手順におけるクライアントからのコマンドとクライアント情報とを対応させて記録しているので、データ送信にエラーが生じてクライアントがデータを受け取れなくても、同じデータを再度要求した場合には課金されない。したがって、通信制御用プログラムを自分のコンピュータに組み込む必要はなく、データ送信のエラーに基づくクライアントへの経済的負担もなく、固定制料金よりも合理的な従量制料金となる。サーバ側にとってもデータ送信にエラーが生じた場合にのみ経済的な負担をすればよいので、固定料金制の場合に比べて合理的な料金となる。
【００２２】
（第二の実施の形態）
第二の実施の形態においては、第一の実施の形態と異なり、履歴記録手順においては、記録回数を有限としている。この記録回数の制限数については、通信エラーの頻度、サーバ側やクライアント側のハードウエアの条件などによって定めるが、例えば１回から１００回くらいである。
履歴記録手順における記録回数を有限とすることによって、課金されないデータを繰り返して送信しなくてもよく、サーバ側にとっての設備の軽減、経済的な不合理を回避することができる。
なお、クライアント側からのリクエストにより、履歴記録をクライアントが確認できるようにしてある。このため、課金されないデータが何であるかが判るので、クライアントにとって利用しやすいシステムとなっている。
【００２３】
（第三の実施の形態）
第三の実施の形態は、第二の実施の形態を更に改良したものである。すなわち、課金判断手順によって課金すると判断した場合にその課金の対象となるデータを記憶装置に保存するデータ保存手順と、課金判断手順によって課金しないと判断した場合に当該記憶装置に保存されたデータのうちのデータ供給の要求に対応するデータを取り出して送信する無課金送信手順とを含んでいる。
ここにいう「記憶装置」は、サービス用のデータが通常保存されているデータ記憶装置とは別に設けられたＲＡＭなどであり、クライアントから再送信の依頼があった場合に、データ記憶装置に再度アクセスして所望するデータを取り出す手間を軽減できる。したがって、再送信に要する時間が短くて済む。
なお、この記憶装置に記憶するデータの数もまた、履歴記録手順の記録回数と同じく制限しており、両者の制限数は同じとしている。従って、記憶装置の容量を小さくすることができ、サーバ側にとっての設備の軽減、経済的な不合理を回避することができる。
【００２４】
（第四の実施の形態）
第四の実施の形態は、上記してきた実施の形態よりも、更に安い料金でクライアントが利用できる可能性を追及したものである。
すなわち、要求受付手順においてはクライアントが履歴記録手順の必要不要を選択可能とし、履歴記録手順が不要である旨の選択をした場合には履歴記録手順を踏まないこととする。そして、履歴記録手順が不要である旨の選択をした場合には、必要である旨の選択をした場合に比べて課金額を小さくするのである。
クライアントが履歴記録手順を必要であると選択した場合には、上記してきた実施の形態と変わらない。
【００２５】
クライアントが履歴記録手順を不要であると選択した場合には、履歴記録手順を行わない。その場合、クライアントが要求したデータが送信エラーによって届かず、再度送信を要求したとしても、再送信の際に課金される。一方、サーバ側は履歴記録手順が不要になるので、記録、保存の手間が軽減される。
サーバ側の手間が軽減されるので、送信エラーがない場合には割安の料金で利用できる。換言すれば、クライアントとしては、履歴記録手順を必要であると選択した場合には、送信エラーが起きた場合の保険料として通常料金を払うか、保険料を抜きにした割安料金を払うかを選択することができる。
【００２６】
【発明の効果】
請求項１および請求項２記載の発明によれば、インターネットを利用したデータ提供有料サービスにおいて、クライアント側、サーバ側のいずれに対する負担も小さく、経済的負担も合理的な課金方法であって、データを再送信するか否かの選択をクライアント側に委ねて合理的に運用するための課金方法を提供することができた。
【図面の簡単な説明】
【図１】本発明の第一の実施の形態を示すフローチャートである。
【図２】従来のセッション管理型の課金システムを示す概念図である。
【図３】従来のインターネット利用型の課金システムを示す概念図である。[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a fee-based service for providing data via the Internet, and relates to a means for charging on a so-called metered basis.
[0002]
[Prior art]
The prior art will be described with reference to FIGS.
In recent years, on-demand systems have been selling intangibles called “information” in sales systems. This is because the intangible “information” that can be digitized can be sent and received via an online network.
[0003]
First, the client logs in to the server, and the server confirms the client ID. When the ID can be confirmed, the fact that it has been confirmed is transmitted to the client. Then, the client sends a command command specifying data to be extracted from the server, and the server receives this and sends the data to the client. The client sends a data receipt confirmation to the server, and when the server receives the receipt confirmation, the server makes a request for compensation, so-called “billing”.
[0004]
Note that the confirmation of receipt transmitted from the client to the server is often automatically performed by communication software. By the way, in the service where the server side sells data that the client side desires via the Internet, as shown in FIG. Therefore, charging to the client has been performed by the following means unlike the connection type.
[0005]
As a first means, a communication control program is incorporated in the upper layer of software for Internet communication to enable session management.
As a second means, charging is performed when data for sale is transmitted to the client side.
As a third means, by setting a so-called fixed fee, “charging” for each service provision is not performed.
[0006]
[Problems to be solved by the invention]
However, each of the above-mentioned means has the following drawbacks.
In the first means, although the server side provides the communication control program, it takes time and effort for the client side to incorporate the communication control program into its own computer.
[0007]
In the second means, even if the client cannot receive the data due to a communication trouble even if the data is transmitted, the user is charged. It is a business style that the server side is not responsible for communication troubles, and in the current situation where the frequency of communication troubles is not very low, there is an economic and psychological burden on the client side, so the disadvantage of the client is Not small.
[0008]
The third means is a business style in which the server side is responsible for communication troubles, and the client side is not responsible. However, it is not a reasonable fee for users who do not need to meet the fixed fee, and if there is a client requesting a large amount of data that does not meet the fixed fee, the burden on the server will be reduced. It will be big.
[0009]
As described above, in the data providing pay service using the Internet, the burden on both the client side and the server side is small, and there is no reasonable charging means for the economic burden.
The problem to be solved by the present invention is to provide a technique relating to a charging means that has a small burden on both the client side and the server side in a data providing pay service using the Internet and has a reasonable economic burden.
[0010]
The object of the present invention described in claims 1 and 2 is a charging method in which the burden on the client side and the server side is small and the economic burden is reasonable in the data providing pay service using the Internet. Thus, it is to provide a charging method for rational operation by entrusting selection of whether or not to retransmit data to the client side .
[0011]
[Means for Solving the Problems]
In order to solve the above-described problems, the present applicant provides the inventions described in claims 1 and 2 .
(Claim 1)
According to the first aspect of the present invention, in a server that provides a data supply service to a client using the Internet, a request reception procedure for receiving a data supply request from the client, and whether or not there has been the same request as the request in the past. If it is determined that there is a history, it is determined that no charging will be performed, and if it is determined that there is no history, a charging determination procedure for determining charging, and a history recording for recording a request history if it is determined that charging will be performed A billing method including a procedure.
The history to be recorded in the history recording procedure is a user ID and a command. In the request receiving procedure, the client can select whether or not the history recording procedure is necessary, and selects that the history recording procedure is unnecessary. Is characterized in that the history recording procedure is not followed .
[0012]
(Function)
In the request reception procedure, the server receives a command from the client.
In the history recording procedure, client information (for example, client ID) for specifying a client and a command received from the client are recorded in association with each other.
[0013]
In the history recording procedure, the command from the client in the request acceptance procedure is recorded in correspondence with the client information, so the same data is requested again even if an error occurs in the data transmission and the client cannot receive the data Will not be charged. Therefore, there is no need to incorporate the communication control program into the computer, there is no economic burden on the client based on the data transmission error, and the usage fee is more reasonable than the fixed fee. Since the server side only has to pay an economic burden only when an error occurs in data transmission, it becomes a reasonable charge compared to the case of the fixed charge system.
By making the number of recordings in the history recording procedure finite, there is the same command in the past, but it can be charged for a command that is positioned as a new request that should not be charged due to a transmission error or the like, Economic unreasonableness for the server side can be avoided.
[0014]
When the client selects that the history recording procedure is unnecessary, the history recording procedure is not performed. In that case, even if the data requested by the client does not arrive due to a transmission error and the transmission is requested again, the client is charged for the retransmission.
[0015]
(Claim 2)
The invention according to claim 2 limits the billing method according to claim 1,
When the selection that the history recording procedure is unnecessary is made, the billing amount is made smaller than when the selection that the history recording procedure is required is made.
[0016]
(Function)
If the client selects that the history recording procedure is unnecessary, the history recording procedure is not performed. Therefore, even if the data requested by the client does not arrive due to a transmission error and a request for transmission is made again, a charge is made at the time of retransmission. Is done. However, in the invention of this claim, the amount to be charged is small, so that if there is no transmission error, it can be used at a low price.
[0017]
The history recorded by the history recording procedure may be formed so that it can be confirmed from the client side. In that case, since the client can check the history recorded by the history recording procedure, if the data does not arrive due to a transmission error, etc., it is only necessary to check the history and request transmission again. Can be used with heart.
[0018]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, the present invention will be described in more detail based on embodiments and drawings. Drawing used here is FIG. 1, and is a conceptual diagram which shows 1st Embodiment of this invention.
[0019]
(First embodiment)
The first embodiment will be described with reference to FIG.
This embodiment is a charging method used in a server that provides a data supply service to a client using the Internet.
Although illustration is omitted, first, the client logs in to the server, and the server confirms the ID of the client. If the ID can be confirmed, a message is sent to the client that data supply can be requested.
[0020]
Subsequently, the client transmits a command for requesting data supply , and the server receives the command. Next, the server associates the client ID with the command and determines whether or not history recording has been performed. If it does not exist in the history record, it is recorded in the history record database, and after taking a procedure for charging, data corresponding to the command is transmitted to the client.
If it exists in the history record, a procedure for not charging is taken, and then data corresponding to the command is transmitted to the client.
[0021]
In the history recording procedure, the command from the client in the request acceptance procedure is recorded in correspondence with the client information, so the same data is requested again even if an error occurs in the data transmission and the client cannot receive the data Will not be charged. Therefore, there is no need to incorporate the communication control program into the computer, there is no economic burden on the client based on the data transmission error, and the usage fee is more reasonable than the fixed fee. Since the server side only has to pay an economic burden only when an error occurs in data transmission, it becomes a reasonable charge compared to the case of the fixed charge system.
[0022]
(Second embodiment)
In the second embodiment, unlike the first embodiment, the number of times of recording is limited in the history recording procedure. The limit on the number of times of recording is determined by the frequency of communication errors, hardware conditions on the server side or client side, and is, for example, about 1 to 100 times.
By limiting the number of times of recording in the history recording procedure, it is not necessary to repeatedly transmit uncharged data, and it is possible to reduce the equipment on the server side and avoid economic unreasonableness.
The client can confirm the history record by a request from the client side. For this reason, since it is possible to know what data is not charged, the system is easy to use for the client.
[0023]
(Third embodiment)
The third embodiment is a further improvement of the second embodiment. That is, when it is determined that charging is performed according to the charging determination procedure, the data storage procedure for storing the data to be charged in the storage device, and when the charging determination procedure determines that charging is not performed, the data stored in the storage device A charge-free transmission procedure for extracting and transmitting data corresponding to the data supply request.
The “storage device” referred to here is a RAM or the like provided separately from the data storage device in which service data is normally stored. When a re-transmission request is received from the client, the data storage device is reconnected to the data storage device. The trouble of accessing and retrieving desired data can be reduced. Therefore, the time required for retransmission is short.
Note that the number of data stored in the storage device is also limited in the same way as the number of times recorded in the history recording procedure, and the number of both is the same. Therefore, it is possible to reduce the capacity of the storage device, and it is possible to reduce facilities on the server side and avoid economic unreasonableness.
[0024]
(Fourth embodiment)
The fourth embodiment pursues the possibility that the client can use it at a lower price than the above-described embodiments.
That is, in the request reception procedure, the client can select whether or not the history recording procedure is necessary, and if the history recording procedure is selected, the client does not follow the history recording procedure. If the history recording procedure is selected to be unnecessary, the billing amount is reduced as compared with the case where the history recording procedure is selected.
When the client selects that the history recording procedure is necessary, the embodiment is the same as the above-described embodiment.
[0025]
When the client selects that the history recording procedure is unnecessary, the history recording procedure is not performed. In that case, even if the data requested by the client does not arrive due to a transmission error and the transmission is requested again, the client is charged for the retransmission. On the other hand, since the history recording procedure is unnecessary on the server side, the trouble of recording and saving is reduced.
Since the effort on the server side is reduced, if there is no transmission error, it can be used at a lower price. In other words, if the client chooses to require a history recording procedure, he or she will decide whether to pay a normal fee as a premium when a transmission error occurs or to pay a discount fee without the insurance fee. You can choose.
[0026]
【The invention's effect】
According to the invention of claims 1 and 2 wherein, in the data providing paid services using the Internet, the client-side, smaller burden on either the server side, a financial burden rational charging method, data It was possible to provide a charging method for rational operation by entrusting the client side the choice of whether or not to retransmit the message .
[Brief description of the drawings]
FIG. 1 is a flowchart showing a first embodiment of the present invention.
FIG. 2 is a conceptual diagram showing a conventional session management charging system.
FIG. 3 is a conceptual diagram showing a conventional internet-based charging system.

Claims

インターネットを用いてクライアントへデータ供給サービスを行うサーバにおいて、
クライアントからのデータ供給の要求を受けつける要求受付手順と、
過去に当該要求と同じ要求があったか否かを判断し、履歴があると判断した場合には課金しないと判断するとともに、履歴がないと判断した場合には課金すると判断する課金判断手順と、
課金すると判断する場合には要求の履歴を記録する履歴記録手順とを含み、
その履歴記録手順において記録する履歴は、ユーザＩＤおよびコマンドとし、
前記要求受付手順においてはクライアントが履歴記録手順の必要不要を選択可能とし、
履歴記録手順が不要である旨の選択をした場合には、履歴記録手順を踏まないこととしたことを特徴とする課金方法。In a server that provides data supply services to clients using the Internet,
A request acceptance procedure for accepting a data supply request from a client;
A determination procedure for determining whether or not there has been the same request as the request in the past, determining that no charge is made when it is determined that there is a history, and determining charging if there is no history;
Including a history recording procedure for recording the request history when it is determined to charge,
The history to be recorded in the history recording procedure is a user ID and a command,
In the request acceptance procedure, the client can select whether or not the history recording procedure is necessary,
A billing method characterized in that a history recording procedure is not followed when a history recording procedure is selected to be unnecessary .

履歴記録手順が不要である旨の選択をした場合には、
必要である旨の選択をした場合に比べて課金額を小さくすることとしたことを特徴とする請求項 1に記載の課金方法。If you choose not to require a history recording procedure,
2. The billing method according to claim 1 , wherein the billing amount is reduced as compared with a case where selection is made as necessary.