I agree with Steffen Ullrich's answer that this is snake oil and that a random IV would solve this problem. Just to add on to to his answer, the paper makes a number of misleading or outright false claims.
They say on page 2 that
However, with the rapid advances in computing horsepower continuing,
it was clear that the era of DES (and 3DES) encryption was coming to a
close and a new way to secure data was needed.
This is only partially correct. DES was vulnerable to brute force attacks, but not 3DES. 3DES is still secure when properly implemented, but has fallen out of favor for its high complexity and extremely poor performance.
However, with the passage of time, even AES has become susceptible to
the massive amounts of computing horsepower available in today’s world
and the increasing sophistication of cyber criminals
Complete nonsense. AES is perfectly fine when properly implemented with a mode of operation appropriate for the use case. No currently known attacks on AES are feasible.
About the 3 different key sizes, they say the following:
Interestingly, the fact that the standard supports increasingly large
key sizes was perhaps an early indication that the security may not be
entirely scalable – i.e. if AES security was stable, then no change in
key size should in fact be required.
The key size requirements were made by NIST before the AES competition concluded. They have nothing to do with concern over Rijndael; any cipher that won would have those 3 key sizes. Furthermore, this has more to do with the fact that it was a government competition, and the government thinks in terms of "security levels". The thought was you would have a fast, lower security version (AES-128); a medium performance, medium security version (AES-192); and a lower performance, high security version (AES-256). In reality, they're all fast, they're all secure, and there's no reason to split hairs unless you're worried about quantum computing, in which case you'd pick AES-192 or AES-256. See this answer by Thomas Pornin.
After totally ignoring the role of the IV as mentioned above, they go on to suggest something a bit absurd:
As a further protection, it is also possible to use different
encryption algorithms for each segment of data to be secured. For
example, segment A could use AES-256, segment B could use Blowfish,
segment C could use 3DES, etc. In fact, each segment of data could
then be further re-encrypted dozens, hundreds, or even thousands of
times. This is one of the characteristics that makes CipherLoc’s
technology very scalable. As hackers get more sophisticated and
continue to have access to ever-increasing amounts of computing
horsepower, our technology can be easily and quickly scaled to even
greater levels of security through a variety of techniques including,
but not limited to, massive amounts of re-encryption.
This solves nothing that properly applied AES does not already solve, while introducing an absolutely unfathomable amount of complexity. If you're using AES, the weaknesses in your system will not be your cipher. They will be side channel attacks, nonce reuse (if applicable), poor random number generators, fixed IVs, lousy KDFs, wrong modes of operation, lack of authentication, and plenty of other common vulnerabilities, all of which would apply anyway in this scheme. Furthermore, I shudder to think of the performance of a system that re-encrypts thousands upon thousands of times with multiple ciphers.
In summary, this scheme is unnecessary and the paper misleading (and that's being charitable).