diff --git a/docs/01_library.dox b/docs/01_library.dox
index 5cd33b6..6f4b717 100644
--- a/docs/01_library.dox
+++ b/docs/01_library.dox
@@ -38,10 +38,10 @@
 The Runtime library is a very basic wrapper around the Core library which can be used for quick prototyping, it is basic in the sense that:
 
 - It allocates images and tensors by using standard malloc().
-- It multi-threads Neon code in a very basic way using a very simple pool of threads.
+- It multi-threads Arm® Neon™ code in a very basic way using a very simple pool of threads.
 - For OpenCL it uses the default CLScheduler command queue for all mapping operations and kernels.
 
-For maximum performance, it is expected that the users would re-implement an equivalent to the runtime library which suits better their needs (With a more clever multi-threading strategy, load-balancing between Neon and OpenCL, etc.)
+For maximum performance, it is expected that the users would re-implement an equivalent to the runtime library which suits better their needs (With a more clever multi-threading strategy, load-balancing between Arm® Neon™ and OpenCL, etc.)
 
 @section S4_1_2 Data-type and Data-layout support
 
@@ -62,7 +62,7 @@
 @section S4_1_3 Fast-math support
 
 Compute Library supports different types of convolution methods, fast-math flag is only used for the Winograd algorithm.
-When the fast-math flag is enabled, both Neon and CL convolution layers will try to dispatch the fastest implementation available, which may introduce a drop in accuracy as well. The different scenarios involving the fast-math flag are presented below:
+When the fast-math flag is enabled, both Arm® Neon™ and CL convolution layers will try to dispatch the fastest implementation available, which may introduce a drop in accuracy as well. The different scenarios involving the fast-math flag are presented below:
 - For FP32:
     - no-fast-math: Only supports Winograd 3x3,3x1,1x3,5x1,1x5,7x1,1x7
     - fast-math: Supports Winograd 3x3,3x1,1x3,5x1,1x5,7x1,1x7,5x5,7x7
@@ -131,7 +131,7 @@
 
 @subsection S4_2_3 Multi-threading
 
-The previous section shows how to run a Neon / CPP kernel in the current thread, however if your system has several CPU cores, you will probably want the kernel to use several cores. Here is how this can be done:
+The previous section shows how to run a Arm® Neon™ / CPP kernel in the current thread, however if your system has several CPU cores, you will probably want the kernel to use several cores. Here is how this can be done:
 
 @code{.cpp}
     ThreadInfo info;
@@ -181,7 +181,7 @@
     }
 @endcode
 
-This is a very basic implementation which was originally used in the Neon runtime library by all the Neon functions.
+This is a very basic implementation which was originally used in the Arm® Neon™ runtime library by all the Arm® Neon™ functions.
 
 @sa CPPScheduler
 
@@ -202,7 +202,7 @@
 function.run();
 @endcode
 
-@warning The Compute Library requires Mali OpenCL DDK r8p0 or higher (OpenCL kernels are compiled using the -cl-arm-non-uniform-work-group-size flag)
+@warning The Compute Library requires Arm® Mali™ OpenCL DDK r8p0 or higher (OpenCL kernels are compiled using the -cl-arm-non-uniform-work-group-size flag)
 
 @note All OpenCL functions and objects in the runtime library use the command queue associated with CLScheduler for all operations, a real implementation would be expected to use different queues for mapping operations and kernels in order to reach a better GPU utilization.
 
@@ -225,9 +225,9 @@
 
 In order to block until all the jobs in the CLScheduler's command queue are done executing the user can call @ref CLScheduler::sync() or create a sync event using @ref CLScheduler::enqueue_sync_event()
 
-@subsection S4_4_2_cl_neon OpenCL / Neon interoperability
+@subsection S4_4_2_cl_neon OpenCL / Arm® Neon™ interoperability
 
-You can mix OpenCL and Neon kernels and functions. However it is the user's responsibility to handle the mapping/unmapping of OpenCL objects.
+You can mix OpenCL and Arm® Neon™ kernels and functions. However it is the user's responsibility to handle the mapping/unmapping of OpenCL objects.
 
 @section S4_5_algorithms Algorithms
 
@@ -249,7 +249,7 @@
 - @ref BorderMode::REPLICATE : Neighbor pixels outside of the image are treated as having the same value as the closest valid pixel.
 - @ref BorderMode::CONSTANT : Neighbor pixels outside of the image are treated as having the same constant value. (The user can choose what this value should be).
 
-Moreover both OpenCL and Neon use vector loads and stores instructions to access the data in buffers, so in order to avoid having special cases to handle for the borders all the images and tensors used in this library must be padded.
+Moreover both OpenCL and Arm® Neon™ use vector loads and stores instructions to access the data in buffers, so in order to avoid having special cases to handle for the borders all the images and tensors used in this library must be padded.
 
 @subsubsection padding Padding
 
@@ -474,7 +474,7 @@
 
 The implemented @ref TensorAllocator and @ref CLTensorAllocator objects provide an interface capable of importing existing memory to a tensor as backing memory.
 
-A simple Neon example can be the following:
+A simple Arm® Neon™ example can be the following:
 @code{.cpp}
 // External backing memory
 void* external_ptr = ...;