writing of the existing interact code. This functional specification defines Vodacom's Tecnomer design of the voucher
and credit card recharge product where users are afforded the ability to recharge their accounts by using a voucher
or if registered for the credit card recharge service a user can recharge using their credit card. This functionality is
provided via an IVR session by dialing a unique access code, where the user will be prompted to choose a specific
recharge function according to current profile on the PPFE."
The plaintiff 's reliance on this statement for the point he sought to make was misplaced, as borne out by his
ultimate concession regarding the credit card recharge Autocharge system and the rebutting evidence of
Gathercole. The specification did not involve any functional change; it was aimed rather at an improvement in
capacity and throughput. Prior to this improvement the system could only manage 90 simultaneous
connections (subscriber's seeking a recharge); the new system allows for 1 800 simultaneous connections.
The case for infringement based on the hybrid prepaid contract
[64] The above summation is the evidence relevant to the alleged infringement by the Autocharge system. The
aspects of it related to the enabling code have relevance to the hybrid contract. I accordingly turn now to deal
with the evidence related to the case for infringement based on the hybrid prepaid contract. Here the plaintiff
relied on the Product Concept Document exhibit "B239261" dated August 2003. The document is stated to be
Version 3 and makes reference to two prior versions, the dates of which are unknown to me because they
were not discovered for the purposes of the trial.
[65] From the evidence, and particularly exhibit "B239261", it can be accepted that the hybrid prepaid contract
operates in the manner outlined earlier. However, it is necessary for present purposes to expand on certain
of its technical aspects. The innovation hoped for with the introduction of the product was that it would
combine the flexibility of a prepaid option and the convenience of a fixedterm contract for the supply of
airtime (as opposed to "a pay as you go"). As already explained, subscribers choose a contract where they
get a fixed monthly amount of airtime (the most popular selection being R135), and then have the option of
purchasing additional airtime using prepaid vouchers or electronic recharge mechanisms to topup, most
usually when the fixed amount supplied automatically at the beginning of each month becomes depleted in
the course of the month. The product concept document explains that the monthly airtime value will be a
monetary value (not a specific number of minutes). The reason for this is that both the monthly airtime value
and the prepaid balance are stored in the same account. Telephone calls first use the fixed monthly airtime
value until depleted and then the topup amount added by any recharge mechanism. There is no split
between monthly recharges and additional topup, as the same IN account is used.
Page 401 of [2009] 1 All SA 381 (T)
The call rates applicable will be the same for the monthly portion and the topup portion; call rates will be
charged at the same value.
[66] As explained above, after the various amendments, the plaintiff's case in relation to the hybrid system is that
it infringes claims 13, 912, 1419 and 2428 of his patent.
[67] Gathercole clarified how the tandem computer runs a "batch job" monthly. An instruction is given and the
programme looks through the registration table on the tandem for the hybrid subscribers (1 million). The
operational function on the tandem will extract the subscribers, the airtime value for each (R135 for example),
and will generate a transaction ID. The function will then extract this; call up the recharge programmes, which
put the money into the subscriber account on the IN network, the only data involved being the MSISDN
(cellphone number), the transaction ID and the airtime value. This, in his opinion, is not an enabling code. As
he sees it, the plaintiff misunderstands the operation. The programme does not interrogate the bank to
determine whether the subscriber has R135 in his account. The crediting of the network account occurs just
after midnight of the last day of the month, while the stop order transactions with the bank occur the next
day by means of a different programme. Should a stop order fail, a soft lock is placed on the subscriber
account and the subscriber will be unable to use the phone. The batch job runs automatically every month.
The subscriber does not have to take any action to effect the monthly recharge. It is done as a matter of
course from the inception of the contract.
[68] While the hybrid contract certainly does involve some element of remote identification and verification, in the
use of the network and the fact of the MSISDN being within the database, the recharge on a monthly basis,
according to Gathercole, does not require the identification and verification of a subscriber's personal details
(contained on the billing platform), seeing as the recharge occurs monthly as an automatic process that will
carry on running as long as the subscriber's contract is valid. The subscriber has no further interaction once he
has established his prepaid contract and set up the debit order.
[69] There was some debate between Mr Puckrin, counsel for the plaintiff, and Gathercole about whether the data
transmitted to the IN network for the purposes of a recharge (the transaction ID, the MSIDN and the amount)
constituted "a code". Gathercole defined the transaction ID as "a unique number that actually identifies the
specific transaction". When asked why such did not constitute a code, he replied: "Because it does not do
anything." By that I understood him to mean that it did not functionally enable anything. As he put it:
"A code, to my understanding, can either be numerical, it can be alpha, but the code takes on a certain functionality
depending on what it is actually designed to do."
The purpose of a transaction ID is limited to identifying a transaction by means of a number, such being of
value to mapping or following the progress of a transaction as it travels through the network.
[70] However, Gathercole conceded that the transaction ID, the MSISDN and the value on being transmitted to the
IN network enabled the net