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.
I afraid there are some flaws in this paragraph:
One should note that CHECKSEQUENCEVERIFY is a
relative lock time operator. For Alice to "refresh" his script there may exist two different reasons:
1)She needs to spend part of her balance and leave the remaining for Bob to inherit just in case.
2) she just wants to make it possible for another period.
In either case the "90d" parameter doesn't need to be changed (unless Alice might want to reconsider her policy), timer is reset and starts ticking from the moment the new script is confirmed. Bob should supply this constant number, 90d, in his redeem transaction in nsequence field (in spite of the fact that he needs to supply the raw script which again carries this parameter) as a result, bitcoin doesn't let Bob transaction in the blockchain, unless its input (hopefully Alice latest tx output) is aged at least 90 days (no script processing involved yet). When the time comes and Bob transaction is basically ready to be confirmed, bitcoin runs the script he has provided (as its hash is used in Alice P2SH transaction) and the script checks the nsequence field (second access into this field) for being matched with "90d" parameter of op_CSV, ... it is how it works.
Still Alice needs to refresh Bob in both cases!
It is because Alice has to expose her public address every time she spends her latest tx and as a best practice she needs to avoid reusing it in the new transaction. It implies new script pattern and new hash hence Bob should be informed about this new hash (remember? Alice is using P2SH address in her transaction) and its raw script.