diff --git a/Latex/Manuscript.tex b/Latex/Manuscript.tex
index b9fb97c..6bb46ee 100644
--- a/Latex/Manuscript.tex
+++ b/Latex/Manuscript.tex
@@ -101,7 +101,7 @@ \section{Introduction}\label{introduction}
 
 By design, the direct approach requires that the cloud has to be compliant with the interoperability standard the CPS is built upon - it becomes a consistent part of the CPS. Data models, roles, and responsibility differences of both solutions make this approach impractical or even imposable to be applied in typical cases. A more detailed description is covered by the Sect.~\ref*{cloud-to-sensors-field-level-connectivity}.
 
-This article addresses further research on the integration of the CPS in the context of new emerging disciplines, i.e.~Industry 4.0 (I4.0) and the Internet of Things (IoT). The new architecture is proposed for integration of the multi-vendor \textbf{machine-centric} CPS designed atop of M2M reactive communication and emerging cloud computing as a \textbf{human-centric} front-end. To support the multi-vendor environment OPC Unified Architecture \cite{LiteratureSurveyOnOpenPlatformCommunications} interoperability standard has been selected. The proposals are backed by proof of concept reference implementations. Prototyping addresses Microsoft Azure Cloud as an example. The prototyping outcome has been just published on GitHub as the open-source (MIT licensed) [TODO: Add reference?]. The proposed solutions have been harmonized with the more general concept called the Object-Oriented Internet.
+This article addresses further research on the integration of the CPS in the context of new emerging disciplines, i.e.~Industry 4.0 (I4.0) and the Internet of Things (IoT). The new architecture is proposed for integration of the multi-vendor \textbf{machine-centric} CPS designed atop of M2M reactive communication and emerging cloud computing as a \textbf{human-centric} front-end. To support the multi-vendor environment OPC Unified Architecture \cite{LiteratureSurveyOnOpenPlatformCommunications} interoperability standard has been selected. The proposals are backed by proof of concept reference implementations. Prototyping addresses Microsoft Azure Cloud as an example. The prototyping outcome has been just published on GitHub as the open-source (MIT licensed) \todo{Add reference}. The proposed solutions have been harmonized with the more general concept called the Object-Oriented Internet.
 
 The main goal of this article is to provide proof that:
 
@@ -205,7 +205,7 @@ \subsubsection{Services}\label{services}
 user interface. To make this interface meaningful metadata called device
 template is used to describe devices.
 
-Following the assumption that interconnection between the CPS and cloud services is designed based on the gateway concept, a middleware must be considered as a coupler. It must be interconnected with the CPS using an in-band protocol adhering to communications requirements (i.e.~protocol profile, data encoding, time relationships, etc.) governing communication of the parts making it up. At the same time, it must support back-and-forth data transfer to the cloud using out-of-band native for the cloud services. The transfer process requires data conversion from source to destination encoding. The \textit{IoT\ Hub} is a service hosted in the cloud that supports \textit{IoT\ Central} providing a robust messaging solution - it acts as a central message hub for bi-directional communication [TODO: Reference]. This communication is transparent, i.e.~it is not data types aware allowing
+Following the assumption that interconnection between the CPS and cloud services is designed based on the gateway concept, a middleware must be considered as a coupler. It must be interconnected with the CPS using an in-band protocol adhering to communications requirements (i.e.~protocol profile, data encoding, time relationships, etc.) governing communication of the parts making it up. At the same time, it must support back-and-forth data transfer to the cloud using out-of-band native for the cloud services. The transfer process requires data conversion from source to destination encoding. The \textit{IoT\ Hub} is a service hosted in the cloud that supports \textit{IoT\ Central} providing a robust messaging solution - it acts as a central message hub for bi-directional communication \todo{Reference}. This communication is transparent, i.e.~it is not data types aware allowing
 any devices to exchange any kind of data. This service is responsible to manage the devices' identity and it offers the following protocol stacks: AMQP, MQTT and HTTPS.
 
 Before process data can be exposed using a web user interface the data source must be associated with an appropriate solution and validated to make sure that the security rules are not violated. It is hard to assume that the security rules governing the CPS may also apply to the cloud-based services. In the gateway scenario, they can be mapped on each other or be entirely independent. The \textit{IoT\ Hub\ Device\ Provisioning\ Service} (DPS) is a helper service for \textit{IoT\ Hub} that enables devices' connection process management, upon device providing valid identity attestation it assigns the device to an appropriate \textit{IoT\ Hub} instance and returns to the device connection parameters, which allow direct connection with given \textit{IoT\ Hub} service. The device proceeds to use the same attestation in \textit{IoT\ Hub} connection and based on it, is granted authorization to selected operations including but not limited to data transfer and updating the user interface.