Well, in TLS 1.0 and a CBC mode ciphersuite, the IV for the next record would always be the last ciphertext block for the previous record. That is, the first encrypted block of each record would be:
$$C_0 = Encrypt_k( P_0 \oplus C_{prev} )$$
What the BEAST attack did was exploit this to generate an encryption Oracle. If they had a guess that a plaintext block (xored with its previous ciphertext block) generated a specific ciphertext block, what they would do is take the current last ciphertext block $C_{prev}$, and have the device generate a plaintext block $P_0$ such that, the two xor'ed together would be the plaintext block (xor'ed with its previous ciphertext block) under test - if the resulting first ciphertext block of the record was what they expect, their guess was correct (and the rest of the exploit was using this Oracle to extract useful information).
Now, if you read through the above text, we see that this attack needs the previous ciphertext block immediately before we encrypt the plaintext, and the attacker needs to see that before he picks his $P_0$ plaintext block. In TLS 1.1, the IV is generated unpredictably by the sender, thus preventing this attack.
If we live with TLS 1.0, we can't change the protocol, but we can emulate it. What this defense does is generate an empty block; the resulting ciphertext is an encryption of data that the attacker cannot control (hence he cannot use that to perform the BEAST attack). And, that ciphertext has a last block that the attacker cannot predict, hence preventing him knowledge of the $C_{prev}$ that will be used when he generates $P_0$, hence effectively emulating the 'use an unpredictable IV' defense in TLS 1.1.
Historic note: TLS 1.1 predated the BEAST attack, but was specifically designed to foil this 'encryption oracle' facet of BEAST. The real innovation of BEAST was the part that used this oracle to perform real world attack.
