Method for server-assisted data processing for a plurality of clients

[0001] This application claims priority to Application No. 10208432.7 which was filed in the German language on Feb. 22, 2002.

[0002] The invention relates to a method for server-assisted data processing for a plurality of clients which are connected at least temporarily to a server.

[0003] Conventionally, methods of this type are applied both in computer systems having distributed resources for solving complex processing tasks and, by way of example, in communication networks having a large number of subscribers and also a central electronic billing system. Put in perspective, they have great economic significance in the development and operation of IN services with charge debiting from a prepaid credit.

[0004] In the evolution of an IN service (prepaid service), it is possible to reserve partial sums or portions of a service user's and account holder's (subscriber's) credit. The money used up for a telephone call is normally deducted at the end of the call. Only then are the reservations for the call reclaimed.

[0005] When calls have been terminated, it is necessary to ensure that the reservations made for them are released again even without this final action. If not, it would no longer be possible to use up the entire credit for telephoning.

[0006] This is currently achieved by checking, when any call accesses the account, how long it has been since this account was last accessed. If a prescribable (recovery) time has been exceeded, all reservations are deleted. Upon resetting, it is necessary to ensure that no “live” call is holding a reservation.

[0007] With mobile radio links based on the GPRS standard, the account is accessed for always-on scenarios continuously, however, i.e. at least the (charge) portion of the GPRS call is reserved up to the next ACR at all times. It is therefore never possible to reset the reservations on the basis of the current method. The reservations for parallel calls terminated under some circumstances are no longer available to the subscriber.

[0008] The main problem is concealed in the recovery mechanism: the recovery time transferred for the RESERVE does not relate to the individual reservation, but rather all reservations are reset to zero if the transferred time since the last reserving access has expired. This results in “hanging” reservations being cancelled only when there is at least one break of the length of the recovery time between two calls. In the case of “normal” calls, this behavior is not so critical, since

• • [0009] the recovery time can generally be kept relatively short in this case (billing on the basis of time), and
  • [0010] the calls do not last forever, which means that there is a very high chance of a break coming soon.

[0011] With GPRS, there is the problem that the calls can last for any length of time (volume-based billing). “Hanging” reservations hardly have any chance, or sometimes have no chance, of being cancelled.

[0012] In the case of lengthy calls (GPRS calls or else other calls) or calls in brief succession, reservations for parallel or previous calls which have been terminated may, for the same reason, be released again too late from the subscriber's point of view.

[0013] The invention discloses an improved method of the generic type which allows, in particular, correct handling of resource or credit reservation in modern communication systems, specifically for mobile radio traffic based on the GPRS standard.

[0014] In one embodiment of the invention, there is a solution which uses a second reservation sum in which the currently “live” calls continually confirm their overall reservations. At the recovery times, the sum of the reservations is then no longer set to zero, as previously, but rather is replaced by the value of the second reservation sum. Every call entity needs to report back to the account at least once within a certain time (recovery time) and hence to confirm its reservation. Calls which are no longer active will no longer be able to report in order to confirm their reservation. The reservations for these calls are then released again when the account is first accessed after expiry of the recovery time.

[0015] In one aspect of the invention, the account manager manages, for each account, not only the normal reservation counter (which, as before, is used for the RESERVE/CHARGE functionality) but also a further one, in which the reservations confirmed within the currently running recovery interval are summed again. If, after expiry of the recovery time, this sum does not match that on the actual reservation counter, then there is/are call entities which have obviously not reported back again and whose reservations have been invalidated. It is therefore possible to deduct the difference between the counter readings on the two reservation counters from that on the actual reservation counter.

[0016] In one preferred embodiment, a maximum reservation period is determined and it is stipulated that the length of a reservation period which the clients can obtain is at most equal to the maximum reservation period.

[0017] In addition, preferably prior to the start of the method, a general request for reservation confirmations is transmitted to the clients which applies to reservation periods while the method is being carried out.

[0018] For stipulating the length of the maximum reservation period and of the confirmation period on the basis thereof, there are a number of alternative options: in a first variation, prior to the start of the method, the maximum reservation period and on the basis thereof the confirmation period are firmly defined. In a second variation, while the method is being carried out, the reservation periods are detected and are taken as a basis for determining the maximum reservation period, with the confirmation period being defined as a fixed value, based on the maximum reservation period. Finally, in a third variation, the confirmation period is defined dynamically as a ratio value, based on the maximum reservation period, depending on the method being carried out.

[0019] At the end of the confirmation period, the quantity of available reservations is compared with the quantity of confirmed reservations, and unconfirmed subsets of the processing resource are released by equating the sum of the reservations to the sum of the confirmed reservations.

[0020] The aforementioned application of providing network resources in a mobile radio network for GPRS calls on the basis of a prepaid credit involves not only reserving processing resources in the form of computer and transmission capacities, but in particular also handling virtual sums of money, specifically debiting from virtual credits.

[0026] The system outlined in FIGS. 1 to 4 relates to online-charged IN calls, the resource to be managed being a prepaid credit account, the server being an “account manager” and the clients being parallel IN calls Call 1 to Call n for which charges are routed via the same account.

[0027] For space/performance reasons, no call-specific information can be held in the account manager for an account. It is therefore preferable for the requesting entity to deliver the respectively necessary context information (see below) at the same time.

[0028] Account data

[0029] The following content fields are required:

[0030]

Field	Size in bytes	Remarks
Account	4	Money available
timestamp	4	Time at which the
		two reservation
		counters next need
		to be aligned.
		Stipulates the
		“recovery interval”
reservation_account_1	4	Actual reservation
		counter
Reservation_account_2	4	Counter for the
		reservations
		confirmed in the
		current recovery
		interval
RTmax	2	Optional
		Maximum recovery
		time which has been
		requested in the
		current recovery
		interval
		Is used to determine
		the next recovery
		interval
RTlastmax	2	Optional
		Recovery time which
		has been used to
		determine the
		current recovery
		interval

Alignment

[0031] If reservation_account_1 is greater than reservation_account_2, then

• • [0032] reservation_account_1=reservation_account_—2
  • [0033] reservation_account_2=0
    Recovery Time

[0034] Using the timestamp (next alignment) and the recovery time, the start of alignment of the two reservation counters is controlled (the condition below is checked for every RESERVE/CHARGE request):

[0035] If current time is greater than timestamp (next alignment), then

• • [0036] increase timestamp (next alignment) by RTstat (static recovery time)
  • [0037] start alignment

[0038] A prerequisite is that the recovery time is stipulated once statically for an account. Should it be necessary to set the recovery time dynamically, then this is also conceivable under the following conditions:

• [0039] a) extra data field in the account for holding the current recovery time (RTmax). For space reasons, the value of the recovery time should not exceed MAXSHORT.
• [0040] b) it is possible to increase the length of the recovery time.
• [0041] c) the maximum recovery time applies to requesting entities.
  Action for the RESERVE request:

[0042] If currently transferred recovery time (RTnew) is greater than RTmax, then

• • [0043] increase timestamp (next alignment) by delta (RTnew, RTmax)
  • [0044] RTmax=RTnew
    Action for alignment:

[0045] If current time is greater than timestamp (next alignment), then

• • [0046] increase timestamp (next alignment) by RTmax
  • [0047] start alignment

[0048] Restriction b) can remain limited to the recovery interval currently in progress at the cost of a further account field (RTlastmax). To this end, this additional field would need to include a note of the last recovery time which was used to form the new timestamp (next alignment) during alignment: the action for the RESERVE request would then need to be as follows:

[0049] If RTnew is greater than RTlastmax, then

• • [0050] increase timestamp (next alignment) by delta (RTnew, RTlastmax)

[0051] If RTnew is greater than RTmax, then

• • [0052] RTmax=RTnew
    Action for alignment:

[0053] If current time is greater than timestamp (next alignment), then

• • [0054] increase timestamp by RTmax
  • [0055] RTlastmax=RTmax
  • [0056] RTmax=0

[0057] Handling the context information for RESERVE

[0058]

	Context element	Remarks
	new_portion	Level of the portion currently
		to be reserved
	sum_reserved_portions	Sum of all portions reserved to
		date in the entire call
		(without new_portion)
	last_reservation_time	Time at which the last
		reservation was made

[0059] This context information needs to be transferred for every RESERVE request, and is evaluated as follows:

• • [0060] alignment function (see above)
  • [0061] currPortion=reservation function with update reservation_account_—1 (as before)
  • [0062] last_reservation_time is less than/equal to (timestamp (next alignment)−RT (RTlastmax/RTmax/RTstat (depending on variant)), then
  • [0063] the call reports back for the very first time in the current recovery interval. Reservations from the last intervals and the current reservation need to be confirmed:
• [0064] increase reservation_account_2 by currPortion and sum_reserved_portions if
• [0065] last_reservation_time is greater than (timestamp (next alignment)−RT (RTlastmax/RTmax/RTstat depending on variant)), then
  • [0066] the call had already reported back in the current recovery interval and had confirmed all reservations from the last intervals the first time. It is therefore now only necessary to confirm the current reservation:
• [0067] increase reservation_account_2 by currPortion

[0068] A simple COMMIT_RESERVATION operation can be introduced which then proceeds in a similar manner to RESERVE with currPortion=0.

[0069] Handling the context information for CHARGE

[0070]

	Context element	Remarks
	charged_money	Level of the money which is
		to be deducted
	sum_reserved_portion	Sum of all portions reserved
		to date in the entire call
	last_reservation_time	Time at which the last
		reservation was made.

[0071] This context information needs to be transferred for every CHARGE request, and is evaluated as follows:

• • [0072] alignment function (see above)
  • [0073] charge function with update account and reservation_account_1 (as before) if last_reservation_time is less than/equal to (timestamp (next alignment)—RT (RTlastmax/RTmax/RTstat depending on variant)), then
  • [0074] the call reports back in the current recovery interval for the very first time. Reservations from the last intervals need to be confirmed. Since the CHARGE function reclaims all announced charges anyway, nothing more needs to be done in this case.
  • [0075] if last_reservation_time is greater than (timestamp (next alignment)—RT (RTlastmax/RTmax/RTstat depending on variant)), then
  • [0076] the call had already reported back in the current recovery interval and had confirmed reservations from the last intervals the first time. It is therefore also necessary to deduct the sum of the reservations: reduce reservation_account_2 by charged_money
    COMMIT_RESERVATION

[0077] In the method described above, the RESERVE function has been used to confirm the reservations, for the sake of simplicity.

[0078] Alternatively, this purpose can be served by introducing a simple COMMIT_RESERVATION operation which then proceeds in a similar manner to RESERVE with currPortion=0 and needs to be requested regularly (at least once in the recovery interval).

[0079] The figures are fundamentally self-explanatory with regard to the above explanations of the terms used and procedures adopted. The situations illustrated are as follows:

[0080] In FIG. 1, three IN calls Call 1, Call 2 and Call n have accessed the prepaid credit account and have made reservations. The reservations have been confirmed for the first recovery interval. In FIG. 2, the first call Call 1 is the first to access the account again after expiry of the recovery time. The reservations are aligned with the confirmations. Since there are no differences, reservation_account_1 remains unchanged, while reservation_account_2 is reset. Call 1 confirms its original reservation and reserves a further credit sum.

[0081] In FIG. 3, a further call Call 3 confirms the original reservation and reserves a further credit share (portion). The second call Call 2 has been terminated without the account manager receiving any corresponding information. In FIG. 4, Call 3 is the first to access the credit again after expiry of the recovery time. Reservations and confirmed reservations are aligned, and this time discrepancies have arisen on account of Call 2 not having reported back. Next, reservation_account_1 assumes values from reservation_account_2, and reservation_account_2 is reset. Call 3 again confirms its previous reservations and reserves a further portion.

[0082] The embodiments of the invention is not limited to the example described and to the method aspects highlighted above, but rather is also possible in a large number of modifications which are within the scope of technical action.