The transaction looks like this:
1) user chooses which kind of credit card he/she has
2) user gets a screen where he/she can specify the cc nr and de-scramble the code
3) user's browser sends the cc nr and de-scrambled code back to the server
4) server replies: all is well, congratulations
If the fraudster is able to intercept just 1 of these transactions then he can already narrow the number of possible "PassWindow" combinations down to lets say a few hundred. But if he can intercept for example 3 or more of the transactions made with the same card then he can easily narrow the possibilities down to fewer than ten combinations. There exists no mechanism that would prevent the fraudster from trying out all of these 10 or fewer combinations.
The most secure way to handle cc transactions would be to confirm every transaction with the cc holder. It could work with e-mail, sms, telephone, im or any other means of communication that the cc holder has chosen and believes is secure enough for him/her. That of course would create significant delays that many current cc systems would be unable to handle since atm they expect instant replies from the cc issuer. Which means that this system would only work with credit cards meant for online payments. In physical stores the 'pin code' is still the best solution at least until the confirmation delays come down to a few seconds.