Using IV buffer after altered inside a Rijndael CBC Encryption/Decryption process as IV for next message?
I assume you mean that the CBC-mode encryption and decryption process would 'update' the "output IV" will be identical to the most recent ciphertext block.  This isn't obvious from your question; for example, the diagrams you show don't show any "output IV" being generated at all.

Now, for your specific questions:


  Does this "Output IV" holds information that can have private key or plain data value inferred from?


Well, obviously not; this "output IV" is just a part of the ciphertext that (we assume) that the attacker sees already.


  Is using the IV in such a way, which can keep both sides of a Rijndael secured communication link sync data (IV) up to date without the need of sending the IV over communication (Although it is not secret), is a known and used approach?


Well, techinically yes, this approach is known and in use; for example, TLS 1.0 uses it (except they maintain separate IVs and keys in the different directions; one reason for that is so that if the two sides send messages at the same time, both encryptors don't try to update their internal states to reflect the most recent message they've seen (which would differ) at the same time - you may want to consider that).

However, there's an issue that you don't ask (but should have)


  Is there any known weaknesses that can occur because of this?


The answer to this is "Yes; if an attacker can convince one of the two sides to send a message of his choosing, he can use that ability to test the decryption of another message block".  With TLS, this is known as the BEAST attack; it would be considered wise to design your encryption system to avoid it.

In addition, I have some questions for you:


What sort of integrity protection are you designing in your protocol?  That is, if the attacker can modify an encrypted message, what advantage can he gain?  What provisions do you have in your protocol that would limit it?
More fundamentally, why are you designing your own encryption protocol?  Encryption protocols have subtle problems (for example, this BEAST attack, which is not at all obvious); is there a specific reason you have decided not to use a known good design which avoids the obvious problems?
How does the two sides get their shared secret key?  Now, this may appear to be off-topic for 'how to encrypt', however it's fraught with even more landmines than designing your own encryption protocol.