Encrypt hash using hash of hash?
So your idea is that the client does the work in calculating the slow hash $B(P)$, and proves that to the server by using a hash as an encryption key. It is definitely not a standard way to do things, and has some problems.

In particular, any eavesdropped can trivially launch an offline dictionary attack on the password, so it is like your normal password database was constantly compromised (which should normally lead to "change your password" emails being sent). That means any passwords that are simple enough to be attacked are completely unprotected.

Instead, I would second the suggestion of using TLS. Even if you can come up with a strong password authentication system that works in the clear, you need authenticated encryption to prevent eavesdroppers from reading the authenticated content etc.

If TLS is simply out of the question, you could use SRP. It, too lets you offload all the hard work of using e.g. bcrypt to the client, by using as B(P) as the SRP password: the server only uses the verifier, meaning it does not need to do the calculation. Unlike your protocol, it prevents both passive attacks on the authentication (as well as MITM). However, you should use the agreed key to authenticate and encrypt the rest of the session, or an attacker can just jump in at that point, so complexity is not that much less than TLS.

(You mention patent concerns. IANAL, but Stanford has a royalty free patent grant for implementing RFC 2945, and anyway the patent may already have expired.)