ES2402977B1 - Método y sistema para generar y gestionar aplicaciones nativas - Google Patents

Método y sistema para generar y gestionar aplicaciones nativas Download PDF

Info

Publication number
ES2402977B1
ES2402977B1 ES201130603A ES201130603A ES2402977B1 ES 2402977 B1 ES2402977 B1 ES 2402977B1 ES 201130603 A ES201130603 A ES 201130603A ES 201130603 A ES201130603 A ES 201130603A ES 2402977 B1 ES2402977 B1 ES 2402977B1
Authority
ES
Spain
Prior art keywords
application
developer
api
native
network
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn - After Issue
Application number
ES201130603A
Other languages
English (en)
Other versions
ES2402977R1 (es
ES2402977A2 (es
Inventor
Michael Schneider
Daniel Jesús COLOMA
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonica SA
Original Assignee
Telefonica SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to ES201130603A priority Critical patent/ES2402977B1/es
Application filed by Telefonica SA filed Critical Telefonica SA
Priority to PCT/EP2012/055792 priority patent/WO2012139903A2/en
Priority to EP12728413.1A priority patent/EP2697731A2/en
Priority to US14/111,871 priority patent/US20140109197A1/en
Priority to BR112013026486A priority patent/BR112013026486A2/pt
Priority to ARP120101228A priority patent/AR085967A1/es
Publication of ES2402977A2 publication Critical patent/ES2402977A2/es
Publication of ES2402977R1 publication Critical patent/ES2402977R1/es
Application granted granted Critical
Publication of ES2402977B1 publication Critical patent/ES2402977B1/es
Withdrawn - After Issue legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/61—Installation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6281—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database at program execution time, where the protection is within the operating system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint

Abstract

Método y sistema para generar y gestionar aplicaciones nativas.#El método comprende:#a) crear, un desarrollador de aplicaciones, una aplicación genérica basada en un tiempo de ejecución;#b) generar una pluralidad de aplicaciones nativas para diferentes sistemas operativos correspondientes agrupando dicha aplicación genérica con un tiempo de ejecución para cada sistema operativo soportado, u OS, manejando dichos tiempos de ejecución API de OS/dispositivo y API de red; y#c) gestionar dichas aplicaciones nativas mediante al menos su almacenamiento en una base de datos y/o su distribución a dispositivos informáticos,#comprendiendo el sistema medios para realizar dichas etapas b) y c) del método de la invención.

Description

Método y sistema para generar y gestionar aplicaciones nativas
Campo de la técnica
La presente invención se refiere, en general, en un primer aspecto, a un método para generar y gestionar aplicaciones nativas, basado en el agrupamiento de una aplicación genérica con tiempos de ejecución adecuados, y más particularmente a un método que comprende usar tiempos de ejecución que manejan API de red.
Un segundo aspecto de la invención se refiere a un sistema para generar y gestionar aplicaciones nativas adaptado para implementar el método del primer aspecto.
Estado de la técnica anterior
El desarrollo de aplicaciones para dispositivos móviles era una tarea que requería mucho tiempo porque los desarrolladores necesitaban crear múltiples versiones de la misma aplicación para diferentes dispositivos y/o sistemas operativos (figura 1).
Debido a esta situación, se creó el concepto de tiempo de ejecución de dispositivo cruzado u OS cruzado. Un tiempo de ejecución permite desarrollar la misma aplicación una vez y desplegarla en múltiples OS/dispositivos siempre que esté disponible el tiempo de ejecución apropiado en los dispositivos objetivo (figura 2).
Sin embargo, el paradigma que fue promocionado por JavaME [1] en primer lugar y ahora por WAC [2] ha experimentado algunos problemas prácticos:
-
No todos los dispositivos disponen del tiempo de ejecución apropiado.
-
Los tiempos de ejecución suministrados por diferentes ISV u OEM se implementan de diferentes maneras.
Debido a estos factores, cuando un desarrollador creaba una aplicación para un tiempo de ejecución, no estaba seguro de si la aplicación iba a ejecutarse en el dispositivo objetivo debido a la ausencia del tiempo de ejecución o a diferencias con el tiempo de ejecución con el que sometió a prueba y verificó la aplicación.
Con el fin de evitar estos problemas, se han creado algunas iniciativas con el fin de agrupar la aplicación con el tiempo de ejecución requerido (por ejemplo Phonegap [3]) y crear (basándose en una única aplicación de desarrollador) múltiples aplicaciones nativas (una por plataforma). Al suministrar un paquete que incluye los dos componentes, el desarrollador garantiza que la aplicación se ejecutará en el dispositivo independientemente del OS, el modelo y la disponibilidad del WRT (Web Runtime, tiempo de ejecución web) (figura 3).
Aunque la solución ilustrada en la figura 3 podría parecer un buen enfoque, vuelve a llevar de nuevo al desarrollador al problema de la heterogeneidad de OS y dispositivos: los desarrolladores necesitan usar diferentes versiones del tiempo de ejecución para cada OS y dispositivo.
Con el fin de paliar ese problema, PhoneGap ha creado otra iteración denominada “Phonegap Build” [4] (figura 4). Los desarrolladores pueden presentar simplemente su aplicación creada para el tiempo de ejecución, y esa aplicación se convertirá y empaquetará para los diferentes sistemas operativos.
Problemas con las soluciones existentes:
Aunque los desarrolladores pueden obtener ahora apps nativas basándose en una única aplicación de tiempo de ejecución, las soluciones actuales sólo están considerando la inclusión de tiempos de ejecución que abstraen la heterogeneidad de las API de dispositivo. Sin embargo, los desarrolladores no sólo están interesados en una capa de abstracción en esa área, sino en algunas otras tales como:
-
API de red: la utilización de recursos disponibles en la red es una de las características en las que también están interesados los desarrolladores (por ejemplo facturación dentro de la aplicación (in-app billing), identidad de usuario…). En este caso, el manejo de la seguridad (autenticación y autorización) es especialmente crítico, ya que los flujos pueden ser sensibles a la seguridad, complejos y extremadamente difíciles de gestionar por los desarrolladores.
-
Seguridad: Los diferentes OS tienen diferentes modelos de seguridad, y algunos de ellos no son suficientemente seguros para satisfacer las necesidades de los usuarios. Ninguna de las soluciones actuales proporciona una experiencia de seguridad común en diferentes OS.
Descripción de la invención
Es necesario ofrecer una alternativa al estado de la técnica que cubra las lagunas encontradas en el
ES 2 402 977 A2
mismo, particularmente las que existen en los tiempos de ejecución usados para generar aplicaciones nativas con respecto a las capas de abstracción que no se incluyeron en las propuestas mencionadas anteriormente.
Con ese propósito, la presente invención se refiere, en un primer aspecto, a un método para generar y gestionar aplicaciones nativas, que comprende:
a) crear, un desarrollador de aplicaciones, una aplicación genérica basada en un tiempo de ejecución;
b) generar una pluralidad de aplicaciones nativas para diferentes sistemas operativos correspondientes agrupando dicha aplicación genérica con un tiempo de ejecución para cada sistema operativo soportado, u OS, manejando dichos tiempos de ejecución API de OS/dispositivo; y
c) gestionar dichas aplicaciones nativas mediante al menos su almacenamiento en una base de datos y/o su distribución a dispositivos informáticos.
En el método del primer aspecto de la invención, a diferencia de las propuestas conocidas, dicha etapa b) comprende además agrupar dicha aplicación genérica con un tiempo de ejecución que maneja API de red y generar cada una de dichas aplicaciones nativas con manejo de seguridad realizando para ello al menos una de las siguientes acciones:
-
añadir una estructura de seguridad para restringir el acceso a dichas API de OS/dispositivo;
-
añadir una estructura de seguridad para controlar la autenticación y autorización de la utilización de dicha API de red; y
-
aplicar al menos una de un conjunto de reglas de transformación que incluyen: firmado de aplicaciones e incrustación de las credenciales del desarrollador para la utilización de API de red.
Otras realizaciones del método del primer aspecto de la invención se describen con referencia a las reivindicaciones 3 a 9 adjuntas, y en una sección posterior relativa a la descripción detallada de varias realizaciones.
Un segundo aspecto de la invención se refiere a un sistema para generar y gestionar aplicaciones nativas, que comprende medios para realizar al menos las etapas b) y c) del método del primer aspecto
Algunas realizaciones del sistema del segundo aspecto de la invención se describen con referencia a las reivindicaciones 11 y 12 adjuntas, y en una sección posterior relativa a la descripción detallada de varias realizaciones.
Breve descripción de los dibujos
Las anteriores y otras ventajas y características se entenderán más completamente a partir de la siguiente descripción detallada de realizaciones, con referencia a los dibujos adjuntos, que deben considerarse de manera ilustrativa y no limitativa, en los que:
la figura 1 muestra un mecanismo de la técnica anterior con respecto al desarrollo de apps nativas en el que se crean originariamente múltiples versiones de la misma aplicación;
la figura 2 muestra otra propuesta de la técnica anterior relativa al desarrollo de apps de tiempo de ejecución en la que se proporcionan tiempos de ejecución en los dispositivos objetivo;
la figura 3 ilustra otro escenario de la técnica anterior en el que los tiempos de ejecución se incrustan con la aplicación por parte del desarrollador;
la figura 4 muestra esquemáticamente un sistema de la técnica anterior que difiere del de la figura 3 en que la incrustación de tiempos de ejecución se realiza por medio de un generador de aplicaciones que recibe la aplicación del desarrollador;
la figura 5 muestra, a nivel esquemático, la arquitectura del sistema del segundo aspecto de la invención usado para implementar el método del primer aspecto, en una realización;
la figura 6 muestra a flujo de trabajo de alto nivel representativo de una realización del método del primer aspecto de la invención;
las figuras 7 a 11 muestran secuencialmente las etapas 1 a 5 de un proceso de generación de aplicaciones según el método del primer aspecto de la invención, en una realización, que termina, en la etapa 5 de la figura 11, con la creación de una aplicación nativa;
la figura 12 muestra esquemáticamente la aplicación nativa creada una vez instalada en el dispositivo/OS tras haber seguido un proceso de descarga de aplicaciones según una realización del método de la invención;
ES 2 402 977 A2
la figura 13 muestra la configuración de seguridad mostrada al usuario del dispositivo cuando se ejecuta la aplicación por primera vez, según una realización del método del primer aspecto de la invención;
la figura 14 muestra esquemáticamente la utilización de las API de dispositivo por la aplicación según una realización del método del primer aspecto de la invención;
la figura 15 muestra la utilización de API de red por la aplicación descargada según una realización del método del primer aspecto de la invención; y
la figura 16 muestra un ejemplo de un flujo de trabajo de autenticación/autorización de API de red según una realización del método del primer aspecto de la invención, con el fin de acceder a las API de red tal como se muestra en la figura 15.
Descripción detallada de varias realizaciones
Esta propuesta va más allá de las soluciones existentes al definir un procesador y distribuidor de aplicaciones que, basándose en un formato de aplicación universal, crea diferentes paquetes que comprenden la aplicación y el tiempo de ejecución para cada OS objetivo.
El desarrollador puede crear la aplicación basándose en las especificaciones de tiempo de ejecución (aplicación de desarrollador) y usando sólo la tecnología que proporciona el tiempo de ejecución. Cuando la aplicación está lista, el desarrollador puede presentar la aplicación al sistema que, en una realización elaborada:
-
Comprueba la validez de la aplicación.
-
Agrupa la aplicación de desarrollador con el tiempo de ejecución para cada OS soportado. El tiempo de ejecución maneja:
•
La vinculación con las API de OS/dispositivo.
•
Un modelo de seguridad consistente para acceder a las API de dispositivo.
•
La vinculación con las API de red.
•
La autenticación y autorización para acceder a las API de red.
-
Aplica un conjunto de reglas de transformación que preparan los paquetes creados tal como se definió anteriormente de modo que estén listos para su instalación en cada OS/dispositivo soportado. Por ejemplo, el firmado de aplicaciones y la incrustación de las credenciales del desarrollador para la utilización de API de red.
-
Devuelve las aplicaciones nativas generadas a los desarrolladores de modo que puedan cargarlas en las tiendas en las que estén interesados. Adicionalmente, el sistema puede exponer la aplicación a los usuarios finales: cuando un usuario desea descargar una app, el sistema, basándose en el dispositivo que esté usándose, proporciona la versión de la aplicación correcta.
La figura 5 representa gráficamente el sistema del segundo aspecto de la invención, usado para implementar el método del primer aspecto.
Los componentes que constituyen el sistema, en la realización ilustrada, son:
•
Bases de datos (DB, databases): Gestionan diferente información necesaria para el comportamiento correcto del sistema.
o DB de tiempos de ejecución: Base de datos en la que están disponibles los diferentes tiempos de ejecución que van a incrustarse en las aplicaciones nativas.
o DB de reglas: Base de datos en la que están disponibles las reglas que va a aplicarse para la generación de aplicaciones nativas. Por ejemplo, las reglas para un OS particular pueden indicar si es necesario o no el firmado de aplicaciones o qué API se soportan.
o DB de dispositivos: Base de datos en la que está almacenada la información acerca de los OS y dispositivos soportados.
o DB de desarrolladores: Base de datos en la que están disponibles la información y las credenciales de los desarrolladores (por ejemplo claves de desarrollador).
o DB de aplicaciones: Base de datos en la que están disponibles todas las aplicaciones (ya sean creadas por desarrolladores o generadas por el sistema).
•
Traductor de apps: Responsable de convertir la aplicación de desarrollador (creada en el tiempo de ejecución) a múltiples versiones nativas (una por OS soportado).
o RT de API de dispositivo: Incluye el componente que vincula las llamadas de API de dispositivo de RT con el OS nativo.
o Seguridad de RT de API de dispositivo: Incluye la capa que restringe el acceso a las API de dispositivo dependiendo de las elecciones por parte del administrador y el nivel de confianza del desarrollador.
o Sumador de RT de API de red: Incluye el componente que vincula las llamadas de API de red de RT con las API expuestas en la red (por ejemplo de JavaScript a HTTP REST).
o Seguridad de RT de API de red: Incluye la capa de control responsable de manejar la autorización y autenticación para una utilización de API de red.
o Firmado: Firma la aplicación con las credenciales del desarrollador y/o la firma del distribuidor.
•
Distribuidor de apps: Responsable de manejar peticiones de descarga de aplicaciones. Basándose en las cabeceras de la petición identifica la aplicación que debe desplegarse en el dispositivo del cliente.
ES 2 402 977 A2
La figura 6 ilustra un diagrama de alto nivel del flujo que se realiza cuando se presenta una aplicación por parte del desarrollador al distribuidor, según una realización del método de la invención, en el que las leyendas indicadas en el mismo deben interpretarse literalmente como acciones realizadas entre el usuario del dispositivo, un distribuidor generador (parte del sistema de la invención), el desarrollador de aplicaciones, y otros distribuidores, según una secuencia que va de arriba abajo en el diagrama, y que sigue los sentidos de las flechas ilustradas. Su secuencia es tal como sigue:
1.
El desarrollador crea una aplicación basándose en el tiempo de ejecución que se le ha proporcionado. Posteriormente (1.1) el desarrollador de la aplicación presenta la aplicación (app) al distribuidor.
2.
El distribuidor genera versiones nativas para cada aplicación incrustando el tiempo de ejecución necesario para cada modelo/versión de dispositivo y OS. Una vez generada las versiones nativas, el distribuidor las devuelve al desarrollador de la aplicación (2.1) y este, las carga a otro posible distribuidor (2.2).
3.
En el caso de que el usuario hubiese descargado la aplicación del distribuidor que la generó, dicho usuario se encarga de pedir la aplicación al distribuidor (3.1), entonces, el distribuidor comprueba las cabeceras de petición y proporciona (3.2) la versión correcta de la aplicación a dicho usuario (incluyendo la aplicación original y el RT requerido).
4.
Finalmente, el dispositivo desempaqueta la aplicación como si se tratase de cualquier otra aplicación nativa. El dispositivo en este caso tiene el mismo aspecto que cualquier otra aplicación pero en verdad incluye el RT y se produce la descarga de la aplicación.
Flujo de trabajo detallado:
A continuación, se proporciona una descripción más detallada de los flujos de trabajo clave que se realizan según el método del primer aspecto de la invención y por el sistema del segundo aspecto, o por las aplicaciones generadas por el mismo.
Generación de aplicaciones:
Etapa 0: El sistema lee el perfil del desarrollador, el OS soportado, los RT y los parámetros de seguridad y, basándose en esto, determina cuál es el flujo de trabajo por el que debe pasar la aplicación.
Etapa 1: Para cada OS soportado (según el flujo de trabajo determinado en la etapa 0), se aplica el tiempo de ejecución correcto que “traduce” las llamadas de API de aplicación de RT para las API de OS. Tras esta etapa, la aplicación original ha conducido a N versiones de la aplicación, una para cada plataforma/OS soportado.
Etapa 2: El sistema añade, para cada versión de la aplicación, la estructura de seguridad determinada durante la ETAPA 0 y que tiene una UX consistente para cada OS. La estructura que va a aplicarse depende del nivel de confianza del desarrollador (por ejemplo las apps desarrolladas por el propio distribuidor pueden tener menos interacciones (prompts)). Esta estructura todavía puede adaptarse/personalizarse dependiendo del las elecciones por parte del usuario final.
ES 2 402 977 A2
Etapa 3: El sistema añade, para cada versión de la aplicación, las bibliotecas apropiadas para vincular las llamadas que hace la app de tiempo de ejecución a recursos de red para la implementación de los recursos de red que tiene el distribuidor. Por ejemplo, una llamada JavaScript en el tiempo de ejecución puede necesitar una traducción para el OS nativo y después un enlace a los recursos de red (por ejemplo llamadas HTTP).
Etapa 4: El sistema añade, para cada versión de la aplicación, la estructura de seguridad apropiada para realizar la autenticación y autorización de aplicaciones y API de red. Esta estructura puede manejar aspectos tales como la validez de los testigos, el régimen de interacción, la autenticación de usuario necesaria. Durante esta etapa se añaden las credenciales del desarrollador así como las credenciales/certificados del distribuidor.
Etapa 5: Si cualquier OS destino requiere el firmado de aplicaciones (según el flujo de trabajo definido en la etapa 0), se firma la app para ese OS.
Etapa 6: Todas las apps generadas se almacenarán en el sistema en la base de datos de aplicaciones. Las aplicaciones también se devuelven al desarrollador en caso de que esté interesado en cargarlas directamente a otros distribuidores de aplicaciones.
Descarga de aplicaciones:
Etapa 0: Un usuario pide una aplicación a la tienda; un ID único identifica la aplicación. El dispositivo proporciona en la petición la información acerca de la plataforma /OS usado por el dispositivo.
Etapa 1: El módulo de distribuidor de apps busca la versión de la aplicación correcta para la plataforma/dispositivo objetivo.
Etapa 2: La app se suministra al dispositivo, que instala la aplicación en el OS objetivo.
Ejecución de aplicaciones:
Etapa 0: Cuando la aplicación se ejecuta por primera vez, notifica al usuario acerca de las API de dispositivo y red que va a usar la app y puede permitirle (dependiendo de los parámetros del sistema de generación) personalizar el régimen de interacción asociado a las mismas (figura 13).
Etapa 1: Cuando la aplicación intenta usar una API de dispositivo, comprueba si es necesaria una interacción. En caso afirmativo, la estructura de seguridad de RT de API de dispositivo pide al usuario una autorización. En caso de que lo permita o no sea necesaria una interacción, se autorizará la utilización de la API y se concederá y usará la capacidad nativa (figura 14).
Etapa 2: Cuando la aplicación intenta usar una API de red, la estructura de seguridad comprueba si la utilización de esa API se ha autorizado antes por el usuario final (figura 15).
o Etapa 2A: Si la utilización se ha autorizado antes, la estructura ya conoce el testigo de desarrollador así como el testigo de autorización. Ambos se incluyen en la petición de red que se crea basándose en la llamada de desarrollador original.
o Etapa 2B: Si la utilización no se ha autorizado o la autorización ha expirado, la estructura tiene que comprobar la autorización de utilización de las API, para ello, por ejemplo, la estructura puede interaccionar con el usuario y pedirle sus credenciales para acceder a ese recurso de red. Si se autentican las credenciales, se devuelve un código de autorización a la estructura de seguridad de red de tiempo de ejecución. Si la autorización no es satisfactoria, se rechaza la petición, si es satisfactoria, la petición del desarrollador se procesa adicionalmente tal como se especifica en la etapa 2A.
La figura 16 describe un ejemplo de este flujo de autenticación de seguridad, según una realización del método de la invención, en el que las leyendas indicadas en el mismo deben interpretarse literalmente como las acciones realizadas entre el usuario del dispositivo, la aplicación, la estructura de seguridad de red, el tiempo de ejecución de API de red y las API de red, según una secuencia que va de arriba abajo en el diagrama, y siguiendo los sentidos de las flechas ilustradas. Obsérvese que la solución definida en esta invención es suficientemente flexible para dar cabida al flujo de seguridad deseado, según se introduzca en la etapa de generación de aplicaciones de acuerdo con las necesidades del distribuidor de aplicaciones.
Un experto en la técnica puede introducir cambios y modificaciones en las realizaciones descritas sin apartarse del alcance de la invención tal como se define en las reivindicaciones adjuntas.
Ventajas de la invención:
Las aplicaciones que pueden desarrollarse mediante este sistema son más ricas que las que permiten hoy en día otras soluciones similares: las apps pueden usar no sólo API de dispositivo sino también API de red con una
ES 2 402 977 A2
experiencia de usuario muy simple.
La solución es extremadamente simple para los desarrolladores, éstos crean una aplicación usando una única tecnología y se crean múltiples variantes de esa aplicación. Adicionalmente el tiempo de ejecución maneja toda la seguridad, que habitualmente es una de las áreas más complicadas de las que tienen que encargarse los desarrolladores (especialmente en las API de red).
También aumenta el rendimiento de la inversión del desarrollo de aplicaciones. Los desarrolladores pueden cargar las apps generadas a múltiples distribuidores y también usarlas en el distribuidor que incluye el generador.
También se refuerza la seguridad: no es necesario que el desarrollador de aplicaciones se encargue del firmado de aplicaciones, la autenticación o la autorización. El generador y el distribuidor gestionan todos esos aspectos, lo que minimiza la posibilidad de desarrollo y proliferación de malware.
Definiciones técnicas:
Aplicación de desarrollador: Son las aplicaciones que se crean directamente por parte del desarrollador. En el caso de esta invención, las aplicaciones de desarrollador se generan usando una tecnología de tiempo de ejecución.
Aplicación nativa: Aplicación que se genera usando las capacidades nativas de un dispositivo (por ejemplo Dalvik en dispositivos Android o iOS en iPhones).
Tiempo de ejecución: Elemento que permite la ejecución de aplicaciones. Un tiempo de ejecución se genera normalmente a modo de plataforma cruzada, de modo que la misma app puede desplegarse en cualquier dispositivo equipado con el tiempo de ejecución adecuado.
API de red: Las API que permiten la utilización de recursos de red, recursos que se exponen normalmente a través de interfaces HTTP. Sin embargo, pueden generarse diferentes capas de ajuste en las mismas para facilitar el acceso a las mismas (por ejemplo API de JavaScript o bibliotecas nativas).
Autenticación: Es un proceso mediante el que se verifica que alguien es quien dice ser. Por ejemplo, en el caso de las API de red, se requiere que el usuario de la aplicación se autentique con el fin de permitir a la aplicación usar la cuenta de usuario final (por ejemplo cobrarle el envío de mensajes).
Autorización: Es un proceso mediante el que se comprueba si alguien tiene derecho a acceder a un recurso. Por ejemplo, en el caso de las API de red puede conseguirse con el uso de un testigo de autorización que está asociado al desarrollador. Es decir si el testigo es válido, eso significa que el desarrollador tiene derecho a acceder a ese recurso.
ES 2 402 977 A2
SIGLAS Y ABREVIATURAS
API Interfaz de programación de aplicaciones App Aplicación
5 HTTP Protocolo de transferencia de hipertexto iOS Sistema operativo de iPhone ISV Vendedor de software independiente JS JavaScript OEM Fabricante de equipos originales
10 OS Sistema operativo RT Tiempo de ejecución UX Experiencia del usuario WAC Comunidad de venta al por mayor de aplicaciones
15 BIBLIOGRAFÍA
[1] Java ME: http://www.oracle.com/technetwork/java/ javame/overview/index.html
[2] WAC: http://wacapps.net 20 [3] Phonegap: http://www.phonegap.com/
[4] Phonegap Build: https://build.phonegap.com/
ES 2 402 977 A2

Claims (11)

  1. REIVINDICACIONES
    1. Método para generar y gestionar aplicaciones nativas, que comprende:
    a) crear, un desarrollador de aplicaciones, una aplicación genérica basada en un tiempo de ejecución;
    b) generar una pluralidad de aplicaciones nativas para diferentes sistemas operativos correspondientes agrupando dicha aplicación genérica con un tiempo de ejecución para cada sistema operativo soportado, u OS, manejando dichos tiempos de ejecución API de OS/dispositivo; y
    c) gestionar dichas aplicaciones nativas mediante al menos su almacenamiento en una base de datos y/o su distribución a dispositivos informáticos;
    estando el método caracterizado porque dicha etapa b) comprende además:
    -
    agrupar dicha aplicación genérica con un tiempo de ejecución que maneja API de red; y
    -
    generar cada una de dichas aplicaciones nativas con manejo de seguridad realizando para ello al menos una de las siguientes acciones:
    o añadir una estructura de seguridad para restringir el acceso a dichas API de OS/dispositivo;
    o añadir una estructura de seguridad para controlar la autenticación y autorización de la utilización de dichas API de red; y/o
    o aplicar al menos una de un conjunto de reglas de transformación que incluyen: firmado de aplicaciones e incrustación de las credenciales del desarrollador para utilización de API de red.
  2. 2.
    Método según la reivindicación 1, que comprende además comprobar la validez de dicha aplicación genérica antes y como condición o inicio de dicha etapa b).
  3. 3.
    Método según cualquiera de las reivindicaciones anteriores, que comprende, para la generación de cada una de dichas aplicaciones nativas, realizar dicha etapa b) para llevar a cabo dicho agrupamiento de tiempos de ejecución o dicho agrupamiento de tiempos de ejecución y acciones adicionales, según un flujo de trabajo.
  4. 4.
    Método según la reivindicación 3, que comprende iniciar dicho flujo de trabajo leyendo un perfil de desarrollador suministrado, los OS soportados, los tiempos de ejecución y los parámetros de seguridad, y basándose en eso, determinar cuál es el flujo de trabajo por el que debe pasar la aplicación genérica, incluyendo dicha determinación la selección de los tiempos de ejecución, las estructuras de seguridad y las reglas de transformación que van a aplicarse, a partir de una pluralidad de tiempos de ejecución, estructuras de seguridad y reglas de transformación, y el orden en el que se realizan.
  5. 5.
    Método según la reivindicación 4, que comprende adaptar/personalizar dichas estructuras de seguridad dependiendo de las elecciones de dispositivos informáticos por parte del usuario final.
  6. 6.
    Método según la reivindicación 1, que comprende, una vez almacenada dicha aplicación nativa en dicha memoria de dispositivo informático, ejecutar por primera vez la aplicación nativa, proporcionando dicha ejecución la notificación que notifica al usuario del dispositivo informático acerca de las API de dispositivo y red que va a usar la aplicación.
  7. 7.
    Método según la reivindicación 6, en el que dicha primera ejecución también proporciona al usuario del dispositivo informático medios para permitirle personalizar el régimen de interacción asociado a las API de dispositivo y red.
  8. 8.
    Método según la reivindicación 7, que comprende cuando la aplicación nativa intenta usar una API de dispositivo, comprobar si es necesaria una interacción, y en caso afirmativo, la estructura de seguridad de RT de API de dispositivo pide al usuario una autorización, y en caso de que lo permita o no sea necesaria una interacción, se autorizará la utilización de la API y se concederá y usará la capacidad nativa.
  9. 9.
    Método según la reivindicación 8, que comprende cuando la aplicación nativa intenta usar una API de red, comprobar, la estructura de seguridad, si la utilización de esa API se ha autorizado antes por el usuario final, y:
    i) si la utilización se ha autorizado antes, conociendo ya la estructura de seguridad un testigo de desarrollador así como un testigo de autorización, incluir ambos en una petición de red que se crea basándose en la llamada de desarrollador original;
    ii) si la utilización no se ha autorizado o la autorización ha expirado, comprobar, la estructura de seguridad,
    ES 2 402 977 A2
    la autorización de utilización de las API para dicho usuario, y si la autorización no es satisfactoria rechazar la petición para acceder a las API de red, y si es satisfactoria, la petición del desarrollador se procesa adicionalmente tal como se especifica en i).
  10. 10. Sistema para generar y gestionar aplicaciones nativas, que comprende medios para realizar al menos 5 dichas etapas b) y c) del método según cualquiera de las reivindicaciones anteriores.
  11. 11. Sistema según la reivindicación 10, que comprende al menos una de las siguientes bases de datos para gestionar diferente información necesaria para implementar el método:
    o Base de datos de tiempos de ejecución, en la que están disponibles dichos tiempos de ejecución;
    o Base de datos de reglas, en la que están disponibles las reglas de transformación;
    10 o Base de datos de dispositivos, en la que está almacenada información acerca de los OS y dispositivos soportados;
    o Base de datos de desarrolladores, en la que están disponibles la información y las credenciales de los desarrolladores; y
    o Base de datos de aplicaciones, en la que están disponibles las aplicaciones genéricas y nativas.
    15 12. Sistema según la reivindicación 11, que comprende además una unidad de traductor de aplicaciones para realizar dicho flujo de trabajo del método según la reivindicación 4.
ES201130603A 2011-04-15 2011-04-15 Método y sistema para generar y gestionar aplicaciones nativas Withdrawn - After Issue ES2402977B1 (es)

Priority Applications (6)

Application Number Priority Date Filing Date Title
ES201130603A ES2402977B1 (es) 2011-04-15 2011-04-15 Método y sistema para generar y gestionar aplicaciones nativas
EP12728413.1A EP2697731A2 (en) 2011-04-15 2012-03-30 Method and system to generate and manage native applications
US14/111,871 US20140109197A1 (en) 2011-04-15 2012-03-30 Method and a system to generate and manage native applications
BR112013026486A BR112013026486A2 (pt) 2011-04-15 2012-03-30 método e sistema para gerar e manusear aplicativos nativos
PCT/EP2012/055792 WO2012139903A2 (en) 2011-04-15 2012-03-30 A method and a system to generate and manage native applications
ARP120101228A AR085967A1 (es) 2011-04-15 2012-04-10 Metodo y sistema para generar y gestionar aplicaciones nativas

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
ES201130603A ES2402977B1 (es) 2011-04-15 2011-04-15 Método y sistema para generar y gestionar aplicaciones nativas

Publications (3)

Publication Number Publication Date
ES2402977A2 ES2402977A2 (es) 2013-05-10
ES2402977R1 ES2402977R1 (es) 2013-07-05
ES2402977B1 true ES2402977B1 (es) 2014-02-11

Family

ID=46320890

Family Applications (1)

Application Number Title Priority Date Filing Date
ES201130603A Withdrawn - After Issue ES2402977B1 (es) 2011-04-15 2011-04-15 Método y sistema para generar y gestionar aplicaciones nativas

Country Status (6)

Country Link
US (1) US20140109197A1 (es)
EP (1) EP2697731A2 (es)
AR (1) AR085967A1 (es)
BR (1) BR112013026486A2 (es)
ES (1) ES2402977B1 (es)
WO (1) WO2012139903A2 (es)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8955067B2 (en) * 2012-09-12 2015-02-10 Capital One, Na System and method for providing controlled application programming interface security
KR20140095903A (ko) * 2013-01-25 2014-08-04 한국전자통신연구원 사용자 디바이스 기반 매쉬업 서비스 제공 방법 및 장치
US10331765B2 (en) 2013-05-24 2019-06-25 Sourcecode Technology Holdings, Inc. Methods and apparatus for translating forms to native mobile applications
US10423992B2 (en) 2013-06-13 2019-09-24 Microsoft Technology Licensing, Llc Method, system, and medium for event based versioning and visibility for content releases
US9787665B2 (en) * 2013-07-02 2017-10-10 Verizon Patent And Licensing Inc. System and method for providing single sign on interface for applications on mobile devices
AU2014353151B2 (en) * 2013-11-19 2018-03-08 Visa International Service Association Automated account provisioning
US20150205581A1 (en) * 2014-01-22 2015-07-23 Bejoynath L. Narayanapillai Method for creating a centrally located enterprise service application framework
KR102208631B1 (ko) * 2014-02-19 2021-01-28 삼성전자 주식회사 전자 장치의 보안 정보 입출력 방법 및 이를 사용하는 전자 장치
US9692879B1 (en) 2014-05-20 2017-06-27 Invincea, Inc. Methods and devices for secure authentication to a compute device
US9208284B1 (en) * 2014-06-27 2015-12-08 Practice Fusion, Inc. Medical professional application integration into electronic health record system
US10459600B2 (en) 2015-06-24 2019-10-29 Microsoft Technology Licensing, Llc Conversion of platform-independent accessibility logic into platform-specific accessibility functionality

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6460074B1 (en) * 2000-02-10 2002-10-01 Martin E. Fishkin Electronic mail system
US20060069605A1 (en) * 2004-09-29 2006-03-30 Microsoft Corporation Workflow association in a collaborative application
US20070180509A1 (en) * 2005-12-07 2007-08-02 Swartz Alon R Practical platform for high risk applications
US7735116B1 (en) * 2006-03-24 2010-06-08 Symantec Corporation System and method for unified threat management with a relational rules methodology
CA2698066A1 (en) * 2009-07-31 2011-01-31 Nitobi Software Inc. System and method for remotely compiling multi-platform native applications for mobile devices
US8566956B2 (en) * 2010-06-23 2013-10-22 Salesforce.Com, Inc. Monitoring and reporting of data access behavior of authorized database users
US20120042016A1 (en) * 2010-08-10 2012-02-16 Google Inc. Exposing resource capabilities to web applications

Also Published As

Publication number Publication date
WO2012139903A2 (en) 2012-10-18
ES2402977R1 (es) 2013-07-05
EP2697731A2 (en) 2014-02-19
ES2402977A2 (es) 2013-05-10
AR085967A1 (es) 2013-11-06
WO2012139903A3 (en) 2013-03-07
BR112013026486A2 (pt) 2016-12-27
US20140109197A1 (en) 2014-04-17

Similar Documents

Publication Publication Date Title
ES2402977B1 (es) Método y sistema para generar y gestionar aplicaciones nativas
ES2465967T3 (es) Sistema y método de firma mediante código por software
JP5497171B2 (ja) セキュア仮想マシンを提供するためのシステムおよび方法
US9258669B2 (en) Registering a mobile application with a server
US9170800B2 (en) Application wrapping for application management framework
US8661420B2 (en) System and method for runtime interface versioning
KR20190111037A (ko) 컨소시엄 블록체인에 의한 스마트 계약 업그레이드 방법 및 시스템
US20160042191A1 (en) Programmable interface for extending security of application-based operating system, such as android
US11340893B2 (en) Mobile application update preserving changes to the application made by a client
CN106295255B (zh) 应用程序的加固方法和装置
US20100325628A1 (en) Information processing device
US8533811B2 (en) Developer phone registration
KR101204726B1 (ko) 보안성 동적 로딩
CN108810894A (zh) 终端授权方法、装置、计算机设备和存储介质
US9208338B2 (en) Method and apparatus for securely executing multiple actions using less than a corresponding multiple of privilege elevation prompts
US9922181B2 (en) Security model for network information service
Liebergeld et al. Android security, pitfalls and lessons learned
ES2623702T3 (es) Procedimiento para la instalación de aplicaciones relevantes para la seguridad en un elemento de seguridad de un terminal
US9354849B2 (en) Modification of compiled applications and application management using retrievable policies
JP5797666B2 (ja) 計算リソースの安全な実行
Park et al. TGVisor: A tiny hypervisor-based trusted geolocation framework for mobile cloud clients
CN107689934B (zh) 一种保障信息安全的方法、服务器及客户端
KR20190128534A (ko) 기능확장을 위한 신뢰실행환경들의 결합 방법 및 비즈니스 프로세스 지원을 위한 fido u2f 활용 방법
Yuan et al. Towards an operating system for the campus
Singh et al. Discovering persuaded risk of permission in android applications for malicious application detection

Legal Events

Date Code Title Description
FG2A Definitive protection

Ref document number: 2402977

Country of ref document: ES

Kind code of ref document: B1

Effective date: 20140211

FA2A Application withdrawn

Effective date: 20140609