I was trying to think of solution for the same problem and came across this old thread during my research. So would like to share the following ideas, which can be seen as improvements to this process.
Aside from process where Bob give his public key to Alice for first time, Alice could write a script which :
1. Make exactly same script, expect timestamp/block height modified for next 90 days
2. Spend Bitcoin from older P2SH transaction and send it to same address with new script
3. Send newer script to Bob (through email perhaps)
Additionally, Alice could send the script only one time to Bob and said she always add value for OP_CSV time with +12960 (block) or +7776000 (timestamp) every transaction "refresh", so continues communication or 3rd party dependency can be removed as Bob simply need to know how many "refresh" happens.
The steps are as follows:
Similarly, Bob gives his public key to Alice.
1. Alice creates special spend bitcoin transaction(s) from all Bitcoin UTXOs under his control to P2SH address. The unlock script of the address allows Alice to spend anytime, but Bob to spend in N days (with OP_CSV).
2. Alice DOES NOT broadcast the transaction but just sends it to Bob and have an agreement with Bob that he broadcasts ONLY in case of some accident. Bob is motivated now to store the transaction(s) on his side.
3. Alice is motivated to check if transaction was NOT broadcasted (which results in decrease of his walled amount) at least every N days.
4. If Bob breaks the agreement and broadcasts or the transaction(s) accidentally hits the chain then Alice will just withdraw bitcoins from the P2SH locked output of the transaction(s).
5. If there is an accident with Alice then Bob broadcasts the transaction(s), waits N days and withdraws bitcoins.
The advantages comparing to the previous methods are:
1. Alice can use any type of addresses to store her bitcoins but not just specific P2SH scripts so complexity reduce and network fee reduce when spending coins.
2. Alice should not move her bitcoins from one P2SH locking script to other every N months. Complexity and network fee reduce again.
The disadvantages which are still there:
1. Alice still needs to create transaction(s) to cover new UTXO set which appears under her control and communicate it to Bob. This might happen every time when she receives BTC or spends and gets a change.
Please, let me know if this approach makes sense, has any mistakes or it was already discussed somewhere.