To prove anything relating to P, Bob would need to know P to begin with, so in that sense you cannot prove within the calculation of a single hash that any particular data is hidden in that hash, without knowing P. You cannot prove a segment of a sha256 hash belongs to anything, you can only prove that you are the signer of a transaction.
One approach though, which may or may not be sufficient for what you want to do is to just prove that the UTXO's in a transaction are members of a series, meaning that you can prove that they are associated with the same sender, and you can also obfuscate this so that only one person is provided that evidence.
To do this you could take the previous transaction ID from some input, like input #1 in your transaction bundle, and then take the previous transaction ID from another transaction, lets say input #2 in your transaction bundle, and XOR those two values together to get a third hash that is the result of an XOR of the two transaction IDs that you want to associate with eachother. Now take that result of the XOR operation and place it in the scriptsig or even the coinbase transaction field in one of the outputs so that it is saved and visible on the chain once sent.
Now Alice can tell Bob to look at the scriptsig (or memo field where people often store OP_RETURN data) of the output that holds the XOR'd value, and with that just perform another XOR operation using the stored hash XOR'd again with the output's previous transaction ID, and the result of that XOR operation will be the previous transaction ID of the first input.
It sounds like that may not be exactly what you would like to do, but if associating the transactions together is all that is needed, as opposed to a full cryptographic proof or revealing any keys, you can take advantage of the commutative property of XOR to store some info.
And so taking this XOR operation:
transaction_id_A ^ transaction_id_B = transaction_id_X
Also means that
transaction_id_X ^ transaction_id_B = transaction_id_A
As well as:
transaction_id_A ^ transaction_id_X = transaction_id_B
And so with that method you can prove that the outputs are related or associated with the same person making the transaction, or prove that they were done at the same time, but there is no possible way to prove a substring of a hash digest belongs to any particular input given to sha256.
Any time that any data is fed in to SHA256 it will return a totally random new hash that is not in any order or predictable pattern, but you can use the scriptsig/OP_RETURN fields to save references to other outputs or transactions, as those do not require any key to view on the block explorer, so interlocking those fields may be the closest we can get for that type of proof.