[ja_JP] Key Concepts / Private data

[shimos]

Original HTML: https://hyperledger-fabric.readthedocs.io/en/release-2.5/private-data/private-data.html Original Source: https://github.com/hyperledger/fabric/blob/e1e8e2e52aa4fc543360d245fe6554a0eaf81183/docs/source/private-data/private-data.md

diff --git a/docs/source/private-data/private-data.md b/docs/source/private-data/private-data.md
index 1a8efcdd9..d14945b96 100644
--- a/docs/source/private-data/private-data.md
+++ b/docs/source/private-data/private-data.md
@@ -118,23 +118,30 @@ For details on transaction flows that don't use private data refer to our
 documentation on [transaction flow](../txflow.html).
 
 1. The client application submits a proposal request to invoke a chaincode
-   function (reading or writing private data) to endorsing peers which are
-   part of authorized organizations of the collection. The private data, or
-   data used to generate private data in chaincode, is sent in a `transient`
-   field of the proposal.
+   function (reading or writing private data) to a target peer, which will manage
+   the transaction submission on behalf of the client. The client application can
+   [specify which organizations](../gateway.html#targeting-specific-endorsement-peers)
+   should endorse the proposal request, or it can delegate the
+   [endorser selection logic](../gateway.html#how-the-gateway-endorses-your-transaction-proposal)
+   to the gateway service in the target peer.  In the latter case, the gateway will
+   attempt to select a set of endorsing peers which are part of authorized organizations
+   of the collection(s) affected by the chaincode. The private data, or data used to
+   generate private data in chaincode, is sent in a `transient` field in the proposal.
 
 2. The endorsing peers simulate the transaction and store the private data in
    a `transient data store` (a temporary storage local to the peer). They
    distribute the private data, based on the collection policy, to authorized peers
    via [gossip](../gossip.html).
 
-3. The endorsing peer sends the proposal response back to the client. The proposal
+3. The endorsing peers send the proposal response back to the target peer. The proposal
    response includes the endorsed read/write set, which includes public
    data, as well as a hash of any private data keys and values. *No private data is
-   sent back to the client*. For more information on how endorsement works with
+   sent back to the target peer or client*. For more information on how endorsement works with
    private data, click [here](../private-data-arch.html#endorsement).
 
-4. The client application submits the transaction (which includes the proposal
+4. The target peer verifies the proposal responses are the same before assembling the
+   endorsements into a transaction, which is sent back to the client for signing.
+   The target peer "broadcasts" the transaction (which includes the proposal
    response with the private data hashes) to the ordering service. The transactions
    with the private data hashes get included in blocks as normal.
    The block with the private data hashes is distributed to all the peers. In this way,
@@ -151,6 +158,9 @@ documentation on [transaction flow](../txflow.html).
    their copy of the private state database and private writeset storage. The
    private data is then deleted from the `transient data store`.
 
+Note: The client application can collect the endorsements instead of delegating that step to the target peer.
+Refer to the [v2.3 Peers and Applications](https://hyperledger-fabric.readthedocs.io/en/release-2.3/peers/peers.html#applications-and-peers) topic for details.
+
 ## Sharing private data
 
 In many scenarios private data keys/values in one collection may need to be shared with
@@ -362,14 +372,22 @@ For very sensitive data, even the parties sharing the private data might want
 on their peers, leaving behind a hash of the data on the blockchain
 to serve as immutable evidence of the private data.
 
-In some of these cases, the private data only needs to exist on the peer's private
+In some of these cases, the private data only needs to exist in the peer's private
 database until it can be replicated into a database external to the peer's
 blockchain. The data might also only need to exist on the peers until a chaincode business
 process is done with it (trade settled, contract fulfilled, etc).
 
-To support these use cases, private data can be purged if it has not been modified
-for a configurable number of blocks. Purged private data cannot be queried from chaincode,
-and is not available to other requesting peers.
+To support these use cases, private data can be purged so that it is not available for chaincode queries, not available in block events, and not available for other peers requesting the private data.
+
+### Purging private data in chaincode
+
+Private data can be deleted from state just like regular state data so that it is not available for query in chaincode for future transactions.
+However, when private data is simply deleted from state, the history of the private data remains in the peer's private database so that it can be returned in block events and returned to other peers that are catching up to the current block height.
+If you need to completely remove the private data from all peers that have access to it, use the chaincode API `PurgePrivateData` instead of the `DelPrivateData` API.
+
+### Purging private data automatically
+
+Private data collections can be configured to purge private data automatically if it has not been modified for a configurable number of blocks.
 
 ## How a private data collection is defined