Patent Description:
Hyper Text Markup Language (HTML), including JavaScript and Cascading Style Sheets (CSS) has been one of most popular programming languages used not only to develop web sites but also to develop applications (so called Apps) for smart phones, tablets and other similar communication devices. While HTML as a language has many advantages, HTML also has some major weaknesses which prevent many software vendors from writing massive proprietary code in HTML.

Use of HTML Apps in mobile device computing (i.e. computing on mobile devices including e.g. smart phones and tablets) has been rapidly increasing in mobile web sites and packaged Apps and has become very popular. A HTML App is a software application that is constructed by HTML/JavaScript/CSS code and runs upon a Web Engine. A Web Runtime is software that manages and launches the HTML App.

However, it is very easy to get or extract the source code of a HTML App including HTML, JavaScript and CSS source code. It is easy to view, modify and debug a web site's source code with a web browser's built-in debug tool, and it is also possible to download publicly available tools for extracting the source code of a HTML App from its Android application package, i.e. a ".

This is an obstacle for software vendors to implement their private valuable algorithms in HTML Apps, because proprietary software vendors needs a solution to protect their source code from being reverse-engineered and/or protect their HTML Apps from being illegally copied.

One solution is to use code obfuscation tools to obfuscate the source code of HTML Apps before packaging the HTML Apps. Code obfuscation can significantly increase the difficulty of JavaScript code reverse-engineering and tampering. However, code obfuscation does not protect HTML programs from being copied since obfuscation does not affect the ability or difficulty of copying the source code and reusing the source code on a different computing device. Hence, it is easy for experienced hackers to reverse-engineer and re-engineer obfuscated source code. Furthermore, program developers must do the obfuscation when releasing the program and therefore debugging a release version of the software becomes very difficult because of the code obfuscation.

<CIT> describes a secondary device as key for authorizing access to resources. <CIT> describes a secure licensing of software to a computing platform using a hardware based security engine.

An objective of embodiments of the present invention is to provide a solution which mitigates or solves the drawbacks and problems of conventional solutions.

An "or" in this description and the corresponding claims is to be understood as a mathematical OR which covers "and" and "or", and is not to be understand as an XOR (exclusive OR).

The above objectives are solved by the subject matter of any of the independent claims and dependent claims.

The present invention also relates to a computer program, characterized in code means, which when run by processing means causes said processing means to execute any method according to the present invention. Further, the invention also relates to a computer program product comprising a computer readable medium and said mentioned computer program, wherein said computer program is included in the computer readable medium, and comprises of one or more from the group: ROM (Read-Only Memory), PROM (Programmable ROM), EPROM (Erasable PROM), Flash memory, EEPROM (Electrically EPROM) and hard disk drive.

Further applications and advantages of the present invention will be apparent from the following detailed description.

The appended drawings are intended to clarify and explain different embodiments of the present invention, in which:.

<FIG> shows a software handling device <NUM> according to different aspects and embodiments of the present invention. The software device <NUM> in <FIG> comprises a processor <NUM> and a transceiver <NUM> which are communicably coupled to each other. This is illustrated with the two dashed arrows between the processor <NUM> and the transceiver <NUM>. The software handling device <NUM> further comprises in this example an antenna <NUM> for wireless communications and/or a wired connection for wired communications.

When the software handling device <NUM> installs (or downloads) a software application, the software handling device <NUM> is configured as follows. The transceiver <NUM> is configured to transmit an authentication request signal to an authentication server. The authentication request signal comprises a user authentication request. The transceiver <NUM> is further configured to receive an authentication verification signal from the authentication server. The authentication verification signal comprises a user authentication verification in response to the user authentication request. The transceiver <NUM> is further configured to transmit a license request signal to a license server. The license request signal comprises the user authentication verification. The transceiver <NUM> is further configured to receive a license verification signal from the license server. The license verification signal comprises a license verification associated with the user authentication verification. The transceiver <NUM> is further configured to transmit a download request signal to a software application server. The download request signal comprises the license verification. The transceiver <NUM> is further configured to download an encrypted source code of a software application from the software application server. The software application is associated with the license verification. Finally, the processor <NUM> is configured to store the encrypted source code of the software application in a memory <NUM>, e.g. a persistent memory of the software handling device <NUM>.

The software handling device <NUM> is according to an embodiment a standalone device configured to install and run applications. However, the software handling device <NUM> may according to another embodiment be integrated in another device, e.g. a communication device with computing capabilities. In this case the processor <NUM> and the transceiver <NUM> of the software handling device <NUM> may be the processor and the transceiver of the communication device.

Further, the memory <NUM> may be comprised in the software handling device <NUM> as shown in the example in <FIG>. According to another embodiment the memory may <NUM> be part of another device and therefore not part of the software handling device <NUM>. The memory <NUM> can e.g. be part of the above mentioned communication device.

When the software handling device <NUM> runs or executes the software application the configurations to receive the user authentication verification above are the same. Thereafter, after receiving the user authentication verification the transceiver <NUM> is further configured to transmit a license request signal to a license server. The license request signal comprises the user authentication verification. The transceiver <NUM> is further configured receive a license encryption signal from the license server. The license encryption signal comprises a license encryption key associated with the user authentication verification. The processor <NUM> is further configured to load the encrypted source code in the memory <NUM>. The processor <NUM> is further configured to decrypt the encrypted source code based on the license encryption key. The processor <NUM> is finally configured to run the software application by executing the decrypted source code.

<FIG> shows a corresponding method 200a which in this example is executed in a software device <NUM> shown in <FIG>. The method 200a in <FIG> relates to the aspect of installing or downloading the software application. The method comprises the step <NUM> of transmitting an authentication request signal S1 to an authentication server 300a. The authentication request signal S1 comprising a user authentication request R1 (which may include a pair of user name and password). The method 200a further comprises the step <NUM> of receiving an authentication verification signal S11 from the authentication server 300a. The authentication verification signal S11 comprising a user authentication verification T1 in response to the user authentication request R1. The method 200a further comprises the step <NUM> of transmitting a license request signal S2 to a license server 300b. The license request signal S2 comprising the user authentication verification T1. The method 200a further comprises the step <NUM> of receiving a license verification signal S22 from the license server 300b. The license verification signal S22 comprising a license verification T2 associated with the user authentication verification T1. The method 200a further comprises the step <NUM> of transmitting a download request signal S3 to a software application server 300c. The download request signal S3 comprising the license verification T2. The method 200a further comprises the step <NUM> of downloading an encrypted source code of a software application from the software application server 300c. The software application is associated with the license verification T2. The method 200a further comprises the step <NUM> of storing the encrypted source code of the software application in a memory <NUM>. The user authentication verification T1 and the license verification T2 may be numbers that the server system <NUM> will trust during a certain time period which means that T1 and T2 are valid during the time period.

<FIG> shows another corresponding method 200b which in this example is executed in a software device <NUM> shown in <FIG>. The method 200b in <FIG> relates to the aspect of running or executing the software application. The method 200b comprises the step <NUM> of transmitting an authentication request signal S1 to an authentication server 300a. The authentication request signal S1 comprising a user authentication request R1. The method 200b further comprises the step <NUM> of receiving an authentication verification signal S11 from the authentication server 300a. The authentication verification signal S11 comprising a user authentication verification T1 in response to the user authentication request R1. The method 200b further comprises the step <NUM> of transmitting a license request signal S2 to a license server 300b. The license request signal S2 comprising the user authentication verification T1. The method 200b further comprises the step <NUM> of receiving a license encryption signal S44 from the license server 300b. The license encryption signal S44 comprising a license encryption key associated with the user authentication verification T1. The method 200b further comprises the step <NUM> of loading an encrypted source code of a software application stored in a memory <NUM>. The method 200b further comprises the step <NUM> of decrypting the encrypted source code of the software application based on the license encryption key. The method 200b further comprises the step <NUM> of running the software application by executing the decrypted source code. The encrypted source code can be decrypted with the license encryption key in the form of a cryptography key using a cryptography algorithm. A cryptography key is usually a number or a series of numbers, e.g.: "A1 0C E3 5D F9 <NUM>7B 6D.

According to an embodiment of the present invention, the license encryption key is unique for a software application and an associated software handling device <NUM>. This means that the license encryption key is unique for the software application and the software handling device <NUM> pair. The license encryption key is created based on the software application and the software handling device, so that a copy of the application package cannot be decrypted on other devices, nor can the key can be used to decrypt other application packages on the same device.

According to a further embodiment of the present invention the license request signal S2 further comprises an indication of an identity of the software application, e.g. an identification number.

According to a further embodiment of the present invention the license request signal S2 further comprises an indication of an identity of a communication device <NUM> comprising the software handling device <NUM>. The identity of a communication device <NUM> can be a Medium Access Control (MAC) address or any other suitable hardware identification means.

<FIG> shows a server system <NUM> according to embodiments of the present invention. The present server system <NUM> may be a system with independent physical servers for an authentication server 300a, a licensing server 300b and a software application server 300c or a system with virtual servers corresponding to the mentioned servers. The embodiment in <FIG> comprises an authentication server 300a, a licensing server 300b and a software application server 300c each comprising independent transceivers 302a, 302b, 302c or sharing a common transceiver in which case the 302a, 302b, 302c are configured in the same transceiver unit. The server system <NUM> in <FIG> also comprises in this particular example a processor <NUM> communicably coupled to the transceivers 302a, 302b and 302c.

Depending on whether the software handling device <NUM> is installing or running the software, the transceivers 302a, 302b, 302c of the server system are configured to receive above mentioned signals S1, S2 and S3 from the software handling device <NUM>. Further, the transceivers 302a, 302b, 302c are configured to transmit above mentioned signals S11, S22 and S44 to the software handling device <NUM>.

<FIG> shows a corresponding method 400a which in this example is executed in a server system <NUM> shown in <FIG>. The method 400a in <FIG> relates to the aspect of installing (or downloading) software but as seen from the server system <NUM> side. The method 400a comprises the step <NUM> of receiving an authentication request signal S1 from a software handling device <NUM>. The authentication request signal S1 comprising a user authentication request R1. The method 400a further comprises the step <NUM> of transmitting an authentication verification signal S11 to the software handling device <NUM> if the user authentication request R1 is valid, e.g. the user name and password in R1 correct. The authentication verification signal S11 comprising a user authentication verification T1. The method 400a further comprises the step <NUM> of receiving a license request signal S2 from the software handling device <NUM>. The license request signal S2 comprising the user authentication verification T1. The method 400a further comprises the step <NUM> of transmitting a license verification signal S22 to the software handling device <NUM> if the user authentication verification T1 is valid. The validity of the user authentication verification T1 can be communicated by a notification from the authentication server 300a to the licensing server 300b. The license verification signal S22 comprises a license verification T2. The method 400a further comprises the step <NUM> of receiving a download request signal S3 from the software handling device <NUM>, the download request signal S3 comprising the license verification T2. The method 400a further comprises the step <NUM> of transmitting an encrypted source code of a software application to the software device <NUM> if the license verification T2 is valid. The software application is associated with the license verification T2. The validity of the license verification T2 can be communicated by a notification from the licensing server 300b to the software application (or resource) server 300c.

<FIG> shows a corresponding method 400b which in this example is executed in a server system <NUM> shown in <FIG>. The method 400b in <FIG> relates to the aspect of running or executing the software in the software handling device but as seen from the server system <NUM> side. The method 400b comprises the step <NUM> of receiving an authentication request signal S1 from a software handling device <NUM>. The authentication request signal S1 comprising a user authentication request R1. The method 400b further comprises the step <NUM> of transmitting an authentication verification signal S11 to the software handling device <NUM> if the user authentication request R1 is valid. The authentication verification signal S11 comprising a user authentication verification T1. The method 400b further comprises the step <NUM> of receiving a license request signal S2 from the software handling device <NUM>, the license request signal S2 comprising the user authentication verification T1. The method 400b further comprises the step <NUM> of transmitting a license encryption signal S44 to the software handling device <NUM> if the user authentication verification T1 is valid. The license encryption signal S44 comprising a license encryption key for an encrypted source code of a software application.

According to an embodiment of the present invention the user authentication verification T1 is a first token and the license verification T2 is a second token. The first and second tokens are valid by the server system during a limited time period and may e.g. be so called magic numbers.

The software handling device <NUM> and server system <NUM> may e.g. be implemented as a Web Runtime and a set of Cloud services, respectively, according to an embodiment of the present invention. The Web Runtime is a program that hosts HTML applications, maintains encrypted source code, after user authentication and license verification, decrypts a HTML application's source code into the memory <NUM> and runs the code in the underlying Web Engine. The Web Runtime is often run as software in computing devices which can be found in communication devices <NUM>. After the Web Runtime decrypts the source code (e.g. HTML, JavaScript, and CSS) the Web Runtime starts parsing and executing the source code.

The mentioned Cloud services are services that provide HTML application management, user authentication, license management, HTML source code encryption, and encrypted source code delivery.

<FIG> shows an example of a communication device <NUM> comprising a software handling device <NUM> according to an embodiment of the present invention in which the software application is a HTML application. The communication device <NUM> e.g. can be a smart phone, a tablet, a computer or any other communication device that can install and run software applications and therefore has the suitable communication, computing and processing capabilities. The communication device <NUM> may have wireless communication capabilities and/or wired communication capabilities. Suitable communication protocols and interfaces may be used for the transmission and reception of communication signals.

<FIG> also shows a server system <NUM> according to an embodiment of the present invention. The different servers 300a, 300b, 300c in the present server system <NUM> may be a group of software components that e.g. can be accessed through the internet and may be hosted by one or multiple physical or virtual computer server systems and/or server system units. The Web Runtime <NUM> (shown in square bracket in the software handling device <NUM>) is the software component that runs on the communication device <NUM> and is used to install and launch HTML applications.

When the Web Runtime <NUM> installs or launches a HTML application, the Web Runtime <NUM> will first get authenticated by using its authentication module to make a request to the server <NUM> by transmitting authentication request signal S1. On the server side, the authentication server 300a will handle the request and return authentication verification signal S11. Once the communication device <NUM> side gets authenticated, the Web Runtime <NUM> will use its licensing module to make a licensing request by transmitting license request signal S2 to the license server 300b. Then, the license server 300b on the server side will handle the licensing request. Once the licensing is done there are two options depending on if the application should be installed or launched.

When installing the application, the Web Runtime <NUM> will make a download request for the encrypted package by transmitting download request signal S3 to the software application server 300c. The software encryption server will be used on the server side to encrypt the source code of the HTML application, and send it to the software handing device <NUM>. The Web Runtime <NUM> will then save the encrypted package in the memory <NUM> for future use. The local storage of encrypted applications is shown as encrypted HTML application in the memory <NUM> in <FIG>.

When launching the application, the Web Runtime <NUM> will use the decryption module to decrypt the saved application, and then launch the application.

<FIG> illustrates an example of the flow inside the Web Runtime <NUM>. <FIG> shows how the Web Runtime <NUM> works when it launches a HTML application. When performing authentication, the software handing device usually needs input of the user, i.e. the person using the software handling device <NUM> or the communication device <NUM>. The Web Runtime <NUM> uses its user authentication module (UAM) to authenticate the user by signalling with the server system <NUM> using the application verification module (AVM) and the UAM. These aspects have been explained above. After decrypting the application source code, the Web Runtime <NUM> loads and runs the source code with its associated Web Engine. When launched the application may e.g. show contents, playing audio/video and handling user inputs, etc..

<FIG> shows a more detailed sequence of what happens when the Web Runtime <NUM> installs an HTML application in the communication device <NUM>. As an example only, the authentication server 300a, licensing 300b server and resource server 300c are in this case full-functional physical servers (i.e. separate computers) rather than the software modules showed in the architecture of the previous Figs. Of course, the servers could be also implemented as software modules running on one and the same computer. The memory <NUM> is the physical storage means where the encrypted HTML applications is stored.

The Web Runtime will send an authentication request to the authentication server in S1, which returns token A in S11 upon success. Then, the Web Runtime <NUM> sends token A in S2 to the licensing server. The S2 also comprises a device or hardware token (i.e. a hardware identity that uniquely identifys the software handling device or its associated computing device), and the idenity (ID) of the application (e.g. a number that uniquely identifys the application).

After the licensing server 300b verifies that the software handling device <NUM> or its associated communication device <NUM> is licensed to use the application on the communication device <NUM>, the licensing server 300b will send back token B in S22. The Web Runtime <NUM> can then use token B to fetch encrypted source code of the HTML application from the resource server 300c by transmitting S3. The resource server 300c is responsible to perform the encryption with all the required information, such as software application ID, user ID, and communicaton device ID. It should be noted that relevant server side communications among the authentication server 300a, the licensing server 300b, and the resource server 300c are not shown in <FIG>.

<FIG> shows the detailed sequence of what happens when the Web Runtime <NUM> launches an HTML application. The authentication server 300a and licensing server 300b are also in this example full-functional physical servers (i.e. separate computers). Of course, the servers could also be implemented as software modules running on one and the same computer. Also, in this case the memory <NUM> is where the encrypted HTML applications is stored.

The Web Runtime <NUM> sends an authentication request in S1 to the authentication server 300a, which returns a token A upon success in S11. Then the Web Runtime <NUM> sends token A, a device or hardware token (i.e. a hardware identity that uniquely identifys the software handling device or its associated computing device), and an ID of the application (e.g. a number that uniquely identify the application) to the licensing server 300b in S2. After the licensing server 300b verifies that the software handling device <NUM> or the associated communication device <NUM> is licensed to use the application, the licensing server 300b will send back an encryption key in S44. The Web Runtime <NUM> therafter loads the encrypted source code from the memory <NUM>, and decyrpts the source code by using the encryption key along with other information, e.g. device ID, user ID, etc., and then forwards the decrypted source code to the Web Engine which will execute the HTML source code.

<FIG> shows a further embodiment which is similar to <FIG> but adds a Web Runtime verification server 300d to the server system <NUM> to make the present solution even more secure. Web Runtime <NUM> sends an authentication request in S1 to the authentication server 300a, which returns a token A upon success in S11. After the Web Runtime <NUM> gets authenticated (using signals S1 and S11), the Web Runtime <NUM> is required to use a specific token to download a verification routine from the Web Runtime verification server 300d. The Web Runtime verification server 300d is used to verify that the Web Runtime software on the software handling device <NUM> has not been tampered. Therefore, a routine request is transmitted to the The Web Runtime verification server 300d which returns a verification routine to the Web Runtime <NUM>. The verification routine will then be executed and scan the Web Runtime <NUM> software, and generate a number, e.g. a token X. The Web Runtime <NUM> may get different routines every time so that the expected verfication token X can also be different every time. If token X that is sent in S2 is the one expected by the licensing server 300b an encryption key will be sent back by the licensing server 300b in S22. Otherwise, the licensing will fail. It is assumed that the license server 300b communicates with the Web Runtime verification server 300d to verify that token X is correct. However, server system <NUM> side communications are not shownin <FIG>. The Web Runtime <NUM> therafter loads the encrypted source code from the memory <NUM>, and decyrpts the source code by using the encryption key along with other information, e.g. device ID, user ID, etc., and then forwards the decrypted source code to the Web Engine which will execute the HTML source code.

<FIG> shows a flowchart of a process when the Web Runtime <NUM> installs an application. The Web Runtime <NUM> first performs user authentication. Upon success, the Web Runtime <NUM> will continue to license verification which involves communicating with the license server 300b shown in previous Figs. Upon success, the Web Runtime <NUM> will starts downloading encrypted application to the memory <NUM>. If any of the previous steps fails, the Web Runtime <NUM> will end the process.

<FIG> shows a flowchart of a process when the Web Runtime <NUM> launches an application. The Web Runtime <NUM> first performs user authentication task. Upon success, the Web Runtime <NUM> will continue to license verification which involves communicating with the license server 300b shown in previous Figs. Upon success, Web Runtime <NUM> will decrypt the source code and launch the same. If any of the previous steps fails, the Web Runtime <NUM> will end the process.

Furthermore, any method according to the present invention may be implemented in a computer program, having code means, which when run by processing means causes the processing means to execute the steps of the method. The computer readable medium may comprises of essentially any memory, such as a ROM (Read-Only Memory), a PROM (Programmable Read-Only Memory), an EPROM (Erasable PROM), a Flash memory, an EEPROM (Electrically Erasable PROM), or a hard disk drive.

Moreover, it is realized by the skilled person that the present software handling device <NUM> and server system <NUM> comprises the necessary communication capabilities in the form of e.g., functions, means, units, elements, etc., for performing the present solution. Examples of other such means, units, elements and functions are: processors, memory, buffers, control logic, encoders, decoders, rate matchers, de-rate matchers, mapping units, multipliers, decision units, selecting units, switches, interleavers, de-interleavers, modulators, demodulators, inputs, outputs, antennas, amplifiers, receiver units, transmitter units, DSPs, MSDs, TCM encoder, TCM decoder, power supply units, power feeders, communication interfaces, communication protocols, etc. which are suitably arranged together for performing the present solution.

Especially, the processors of the present devices may comprise, e.g., one or more instances of a Central Processing Unit (CPU), a processing unit, a processing circuit, a processor, an Application Specific Integrated Circuit (ASIC), a microprocessor, or other processing logic that may interpret and execute instructions. The expression "processor" may thus represent a processing circuitry comprising a plurality of processing circuits, such as, e.g., any, some or all of the ones mentioned above. The processing circuitry may further perform data processing functions for inputting, outputting, and processing of data comprising data buffering and device control functions, such as call processing control, user interface control, or the like.

Claim 1:
A software handling device (<NUM>) comprising a processor (<NUM>) and a transceiver (<NUM>); wherein the transceiver (<NUM>) is configured to:
transmit an authentication request signal (S1) to an authentication server (300a), the authentication request signal (S1) comprising a user authentication request (R1);
receive an authentication verification signal (S11) from the authentication server (300a), the authentication verification signal (S11) comprising a user authentication verification (T1) in response to the user authentication request (R1) and being received if the user authentication request (R1) is valid, wherein the user authentication request (R1) includes a pair of user name and password and is valid if the user name and password are correct;
transmit a license request signal (S2) to a license server (300b), the license request signal (S2) comprising the user authentication verification (T1) and an indication of an identity of a software application,
receive a license encryption signal (S44) from the license server (300b), the license encryption signal (S44) comprising a license encryption key associated with the user authentication verification (T1), wherein the license encryption signal (S44) is received if the user authentication verification (T1) is valid, and wherein the license encryption key is created based on the software application and the software handling device (<NUM>); and wherein the processor (<NUM>) is configured to
load an encrypted source code of the software application stored in a memory (<NUM>), wherein the encrypted source code is downloaded from a software application server (300c) and is encrypted by the software application server (300c) using a software application ID and a communication device ID;
decrypt the encrypted source code of the software application based on the license encryption key; and
run the software application by executing the decrypted source code.