diff --git a/images/solution_architecture/figure_1.svg b/images/solution_architecture/figure_1.svg
index c53eed4..1908c3d 100644
--- a/images/solution_architecture/figure_1.svg
+++ b/images/solution_architecture/figure_1.svg
@@ -1,3 +1,3 @@
-
+
diff --git a/images/solution_architecture/figure_2.svg b/images/solution_architecture/figure_2.svg
index 7657442..a907f33 100644
--- a/images/solution_architecture/figure_2.svg
+++ b/images/solution_architecture/figure_2.svg
@@ -1,3 +1,3 @@
-
+
diff --git a/images/solution_architecture/figure_3.svg b/images/solution_architecture/figure_3.svg
index a568a23..3a39bb2 100644
--- a/images/solution_architecture/figure_3.svg
+++ b/images/solution_architecture/figure_3.svg
@@ -1,3 +1,3 @@
-
+
diff --git a/images/solution_architecture/figure_4.svg b/images/solution_architecture/figure_4.svg
index dbf10b7..71dfc0b 100644
--- a/images/solution_architecture/figure_4.svg
+++ b/images/solution_architecture/figure_4.svg
@@ -1,3 +1,3 @@
-
+
diff --git a/images/solution_architecture/figure_6.svg b/images/solution_architecture/figure_6.svg
index 34a8db7..fee43e5 100644
--- a/images/solution_architecture/figure_6.svg
+++ b/images/solution_architecture/figure_6.svg
@@ -1,3 +1,3 @@
-
+
diff --git a/images/solution_architecture/figure_7.svg b/images/solution_architecture/figure_7.svg
index 6feab1d..ff8b7b3 100644
--- a/images/solution_architecture/figure_7.svg
+++ b/images/solution_architecture/figure_7.svg
@@ -1,3 +1,3 @@
-
+
diff --git a/solution_architecture.md b/solution_architecture.md
index d05bf68..dbde8e0 100644
--- a/solution_architecture.md
+++ b/solution_architecture.md
@@ -65,7 +65,7 @@ The flow for using the app is as follows, referencing the steps from *Figure 2*:
- (2) Optionally, they can scan the QR code with the Corona-Warn-App (*Figure 3*, step 1) – if users decide against using the test retrieval functionality of the Corona-Warn-App, they still receive their test results through the regular channels explained before.
- (3) When the code is scanned, a web service call (REST) is placed against the Verification Server (*Figure 3*, step 2), linking the phone with the data from the QR code through a registration token, which is generated on the server (*Figure 3*, step 3) and stored on the phone (*Figure 3*, step 4).
- **Step 2:** The samples are transported to the lab (together with a “Probenbegleitschein”, which has a machine-readable QR code on it, as well as multiple other barcodes (lab ID, sample IDs).
-- **Step 3:** As soon as the test result is available (i.e. the samples have been processed), the software running locally in the lab (lab client) transmits the test result to the Laboratory Information System, together with the GUID from the QR code. The Laboratory Information System hashes the GUID and the test result. It is made available to the Verification Server through a REST interface.
+- **Step 3:** As soon as the test result is available (i.e. the samples have been processed), the software running locally in the lab (lab client) transmits the test result to the Laboratory Information System, together with the GUID from the QR code. The Laboratory Information System hashes the GUID and posts it together with the test result to the Test Result Server through a REST interface (*Figure 3*, step A), which in turn makes it available to the verification server.
- **Step 4a:** After signing up for notifications in step 1, the user’s phone regularly checks the Verification Server for available test results (polling, figure 3, steps 5-8). This way, no external push servers need to be used. If results are available, the user is informed about the availability of information and only after opening the app, the result is displayed, together with recommendations for further actions (see scoping document for more details).
- In case the test returned a positive result, users are asked to upload their keys to allow others to find out that they were exposed. If the users agree, the app retrieves a short-lived token (TAN) from the Verification Server (see also *Figure 3*, steps 9-11). The TAN is uploaded together with the diagnosis keys of up to the last 14 days to the Corona-Warn-App Server (*Figure 3*, step 12).
- The Corona-Warn-App Server uses the TAN to verify the authenticity (*Figure 3*, steps 13-15) of the submission with the Verification Server.
@@ -161,7 +161,7 @@ Further details of the API are explained in the documentation of the Corona-Warn
### Data retention
-The data on the all involved servers will only be retained as long as required. Diagnosis Keys will be removed from Corona-Warn-App Server once they refer to a period more than 14 days ago. TANs on the Verification Server will be removed as soon as they have been used. The hashed GUID on the Verification Server needs to be retained as long as the GUID can be used to retrieve test results from the Laboratory Information System, as otherwise a second upload privilege (i.e. a registration token) could be fetched with the same GUID.
+The data on the all involved servers will only be retained as long as required. Diagnosis Keys will be removed from Corona-Warn-App Server once they refer to a period more than 14 days ago. TANs on the Verification Server will be removed as soon as they have been used. The hashed GUID on the Verification Server needs to be retained as long as the GUID can be used to retrieve test results from the test result server, as otherwise a second upload privilege (i.e. a registration token) could be fetched with the same GUID.
## MOBILE APPLICATIONS