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 "B239­261" 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 "B239­261", 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 fixed­term 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 top­up, 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 top­up amount added by any recharge mechanism. There is no split between monthly recharges and additional top­up, 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 top­up 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 1­3, 9­12, 14­19 and 24­28 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­