ES2425303B1 - Procedimiento para gestionar datos en sistemas m2m - Google Patents

Abstract

Procedimiento para gestionar datos en sistemas m2m.#Un procedimiento que permite gestionar datos de dispositivos de sensor agregándolos en entidades virtuales: objetos conectados (CO). Terceros acceden a esos datos expuestos si y solo si el propietario de esos datos concede los derechos de acceso correspondientes. Puesto que la comunicación es bidireccional, también puede concederse a terceros la gestión del conjunto de dispositivos que pertenece a esos CO para los que se concedió acceso a datos. El procedimiento permite gestionar múltiples dispositivos remotos, permitiendo que esquemas de denominación y direccionamiento sistemáticos alcancen esos dispositivos. Finalmente, el procedimiento permite procedimientos de cobro a través de una entidad de función de datos de cobro de objeto, que halla el objeto correcto que deben cobrarse y envía la factura a tanto el propietario como los terceros por los servicios prestados. Los objetos de cobro (CHO) son esos CO expuestos para la aplicación específica de cobro. Se propone una jerarquía (CHO organizacional, fundamental, derivado y temporal) que permite reglas de herencia (inversa y directa) para derechos de acceso y/o política de cobro.

Description

imagen1

imagen2

DESCRIPCIÓN

Procedimiento para gestionar datos en sistemas M2M

5 Campo técnico de la invención

La presente invención tiene su aplicación dentro del sector de las telecomunicaciones y, especialmente, en el área industrial dedicada a las comunicaciones de máquina a máquina (M2M), que involucran a dispositivos de sensor remotos que tanto notifican como aceptan instrucciones a través de redes de telecomunicación, incluyendo línea fija, celular y otras redes de telecomunicación inalámbricas.

Más particularmente, la invención descrita en el presente documento se refiere a un procedimiento para controlar el acceso a flujos de datos procedentes de dispositivos de sensor.

15 Antecedentes de la invención

Máquina a máquina (M2M) se refiere a tecnologías que permiten a sistemas tanto inalámbricos como por cable comunicarse con otros dispositivos de la misma capacidad. Un sistema M2M comprende al menos un dispositivo de sensor (tal como una sonda o medidor) para capturar un evento (por ejemplo, temperatura, nivel de inventario, etc.), que se transmite a través de una red (inalámbrica, por cable o híbrida) a una aplicación (implementada como programa de software). La aplicación traduce el evento capturado en información significativa (por ejemplo, artículos que necesitan reabastecerse). Tal comunicación se logró originalmente haciendo que una red remota de máquinas transmitiera información de vuelta a un concentrador de central para su análisis, que entonces se encaminaría de nuevo a un sistema como un ordenador personal. Sin embargo, la comunicación M2M moderna

25 se ha expandido más allá de una conexión de uno a uno y ha cambiado a un sistema de redes que transmite datos a aparatos personales. La expansión de redes inalámbricas por todo el mundo ha hecho que sea mucho más fácil que la comunicación M2M tenga lugar y ha reducido la cantidad de energía y tiempo necesarios para que la información se comunique entre máquinas. Estas redes también permiten una serie de nuevas oportunidades comerciales y conexiones entre consumidores y productores en cuanto a los productos que se venden. Un campo técnico y comercial en el que está aplicándose actualmente M2M es el cobro.

El término “M2M” se usa para describir aplicaciones en campos tan diversos como: localización y seguimiento; pago; mantenimiento remoto; peaje de automóviles y electrónico; medición; y dispositivos de consumidor. El aumento de M2M para permitir comunicaciones inalámbricas entre dispositivos (a menudo denominado M2M 35 móvil) hace que los nuevos servicios sean posibles en algunos casos (dentro de la industria de la automoción, por ejemplo) y que en otros se extiendan servicios M2M existentes (dentro del campo de la medición inteligente).

El término “dispositivo de sensor” en el siguiente documento se refiere a cualquier dispositivo que es operable para generar una señal que corresponde a un parámetro medido o detectado. En muchos casos, el término se usa de manera sinónima con dispositivo de comunicación de tipo máquina (MTC) o simplemente “máquina” (especialmente en el contexto de las comunicaciones M2M). Aunque tales dispositivos pueden acoplarse a una red de telecomunicaciones que está totalmente fija, está dotándose a un número cada vez mayor de dispositivos (“máquinas”) de aparatos de telecomunicaciones inalámbricas (M2M móvil) para facilitar servicios de información adicionales.

45 Con M2M móvil, las máquinas que ascienden a del orden de millones y están ubicadas en cualquier lugar dentro de una cobertura de red móvil, pueden monitorizarse simultáneamente para proporcionar información en tiempo real que puede analizar y sobre la que puede actuar un individuo o empresa. Se prevé que grandes números de “máquinas” requerirán acceso a redes móviles de área amplia (tal como las redes celulares GSM, GPRS y/o 3G). Cada una de estas máquinas pueden tener todo el equipo básico para permitir una conexión a al menos una red de acceso cuando se requiera pero puede requerir autenticación sólo muy ocasionalmente.

La tendencia de M2M actual es evolucionar hacia la visión de “Internet de las cosas”, en la que mil millones de dispositivos siempre estarán conectados, y la mayoría serían dispositivos de bajo coste, de consumo de baja

55 potencia y por tanto de baja demanda de ancho de banda (como dispositivos de nodo de sensor sencillos). Por tanto, desde el punto de vista de los proveedores, el volumen de dispositivos conectados se vuelve más importante que el volumen de datos transmitidos por los mismos o la duración de tiempo de su conexión inalámbrica en aplicaciones tales como cobro. Por tanto, es preferible compartir una funcionalidad común para gestionar cada dispositivo conectado al acceder a sus datos entre diferentes categorías de aplicación, con el objetivo de facilitar una sociedad más eficiente; por ejemplo, en los campos de la automoción, la cadena de suministro y logística, la asistencia médica y salud, la automatización de edificios, la gestión de energía, etc.

Por otro lado, con el fin de poder acceder a los datos procedentes del gran número de dispositivos conectados, se requieren nuevos esquemas para la denominación y direccionamiento de los dispositivos. Las soluciones 65 existentes para denominación y direccionamiento de M2M de los dispositivos son muy sencillas, basándose en el hecho de que mucha de la interacción es sólo unidireccional, ya que el sensor es la fuente de información que la

imagen3

imagen4

envía hacia un localizador uniforme de recursos (URL) ampliamente conocido o dirección de protocolo de Internet (IP), que reside en el dispositivo (o bien preprogramado manualmente o bien mediante una carga de firmware remota). Sin embargo, cuando se plantea un requisito para comunicación bidireccional, los enfoques actuales ya no funcionan e incluso tienen que tratar con algunos problemas adicionales como los derivados de la

5 naturaleza dinámica de la mayoría de las direcciones, la privacidad de las mismas, etc. Además, los esquemas actuales no son lo suficientemente flexibles para afrontar diferentes tipos de direcciones, por ejemplo, direcciones IP o MSISDN.

Entonces, el problema técnico es proporcionar sistemas M2M con una funcionalidad de gestión de datos común y compartible para todos los diferentes dispositivos y redes del sistema M2M que permita el acceso a y el control de los datos intercambiados por estos dispositivos y los propios dispositivos, incluyendo la denominación y el direccionamiento de los dispositivos para comunicaciones M2M bidireccionales.

Sumario de la invención

15 La presente invención sirve para resolver el problema mencionado anteriormente proporcionando un marco y plataforma en capas horizontales para un ecosistema M2M completo para fomentar el desarrollo de nuevas aplicaciones y nuevos modelos comerciales en diferentes áreas (por ejemplo, industria de la automoción, la cadena de suministro y logística, la asistencia médica y el bienestar, la automatización de edificios, la gestión de energía, etc.) basándose en una arquitectura de servicio de objetos conectados. Para cada implantación de M2M, esta invención propone una plataforma de habilitación de servicio M2M (basándose en una infraestructura de middleware) que proporciona funciones horizontales comunes para muchos y diversos tipos de aplicaciones y dispositivos remotos M2M.

25 Un valor añadido clave de la invención es un procedimiento de gestión de suscripción de cliente tercero, que es uno de los muchos posibles conjuntos de funciones comunes ofrecidas por la plataforma de habilitación de servicio M2M propuesta. Este procedimiento es una funcionalidad común, en particular, una funcionalidad de intermediación de datos, que permite que las aplicaciones del cliente tercero se suscriban a los datos publicados por dispositivos conectados que se exponen por un cliente propietario con fines comerciales. Para facilitar tal capacidad de gestión de suscripción, se introduce el término “objeto conectado”, como una disposición lógica de dispositivos realizada por el propietario, que oscila desde dispositivos de uno a uno hasta de muchos a uno por objeto. La plataforma de middleware descrita a continuación facilita un servicio de suscripción, gestionado por el cliente propietario por medio de reglas de acceso a datos, o reglas de permiso. Esta funcionalidad común permite a los clientes terceros desarrollar o integrar aplicaciones M2M que se alimentan con datos que proceden de

35 dispositivos de sensor remotos situados en redes de sensor o módulos individuales que gestionan su conexión fija o móvil a la plataforma M2M, ni implantada ni propiedad de esos clientes terceros. Por tanto, una ventaja de la invención es que a los clientes terceros les interesa aceptar que se les cobre por el uso y consumo de los datos expuestos y sólo por los datos que pueden ser de su interés.

Otra ventaja de la invención es que proporciona un procedimiento de denominación y direccionamiento para alcanzar y gestionar de manera remota cualquier sensor o accionador situado en un dispositivo remoto conectado a la plataforma de habilitación de servicio M2M. El dispositivo puede ser un único nodo o cualquier nodo de extremo que pertenece a una red de sensores. En el último caso, la accesibilidad del dispositivo remoto se logra al interactuar con un nodo de pasarela de una red de sensores, que traduce la acción de gestión de

45 dispositivo al nodo de extremo por medio de sus propios procedimientos de denominación y direccionamiento implementados por el protocolo de comunicación de red de sensores. La invención permite la transmisión y la recepción de cualquier tipo de mensaje de petición/respuesta de gestión de dispositivo relacionado con la monitorización, configuración, información o control de dispositivo. Ejemplos son:

-Monitorización de: topología de red de sensor inalámbrico; identificación de dispositivo remoto; capacidades de dispositivo; estado de dispositivo, estado de batería, etc.

-Configuración: ajustes de parámetros de dispositivo (por ejemplo umbrales para lecturas y acciones de accionamiento); configuración de pasarela, actualizaciones de software remoto, etc. 55 -Notificación de: fallo de dispositivo o últimos datos recopilados, etc.

-Control de: dispositivo encendido/apagado; despertador de nodo de sensor, iniciar/detener mediciones, hibernar; pruebas de conectividad, etc.

Con el fin de lograr las metas mencionadas anteriormente, se propone un esquema de denominación de múltiples capas, que puede identificar finalmente el objeto conectado requerido por usuario más bajo. Es decir, es el mismo propietario del objeto conectado a la plataforma M2M el que define el nivel de granularidad de su red de sensores. A veces esa granularidad puede basarse en la preferencia del propietario, pero, siendo más 65 realista, la amplia mayoría de las veces son las limitaciones de direccionamiento inherentes de los protocolos de la red de sensores inalámbricos (WSN) M2M implantados los que imponen esa granularidad. A pesar de eso, el

imagen5

imagen6

esquema definido en este caso puede direccionar sea cual sea el nivel más bajo accesible del nodo de sensores en una red.

La invención define procedimiento y reglas mediante los que se considera único un nombre dado vinculado a una

5 dirección accesible (por ejemplo, dirección IP, número MSISDN,…) y garantiza esta exclusividad. Además, se definen reglas para exponer ese nombre al mundo exterior, concediendo suficiente confianza para garantizar la referencia al dispositivo conectado correcto. Y todo lo anterior usando un procedimiento que evita tareas complejas de reconfiguraciones en las redes de sensores conectadas, quizás ya implantadas. Además, se define un procedimiento lógico y sin interrupción de registro y vinculación con el fin de asociar de manera transparente las identidades implantadas a los nuevos nombres e identidades aprovisionados.

En el contexto de la invención, son aplicables los siguientes términos y definiciones:

Plataforma de habilitación de servicio M2M genérica: Es una plataforma de servicio que ofrece un marco abierto

15 y en capas horizontales que atrae empresas y desarrolladores a un ecosistema en el que pueden crearse y comercializarse múltiples aplicaciones M2M basándose en los datos recopilados a partir de multitud diversa de dispositivos remotos. Los servicios ofrecidos pueden ajustarse a escala y adaptarse a un amplio conjunto de aplicaciones de cliente de plataforma.

Objeto conectado (CO): Un único dispositivo remoto M2M o un conjunto lógico de dispositivos remotos M2M. Pueden pertenecer a una o varias redes de sensores (por cable o inalámbricas) conectadas a una plataforma de habilitación de servicio M2M genérica por medio de nodos de pasarela dotados de portadoras de comunicación activas que permiten que cualquier dispositivo conectado envíe/reciba información a/desde cualquier fuente de información específica o general. Ejemplos de redes de sensores son redes de sensores inalámbricas de

25 propósito genérico basadas en diferentes tecnologías inalámbricas de corto alcance como ZigBee, 6lowPAN, Bluetooth / Bluetooth Low Energy, WiFi, Z-Wave, etc.

Cliente propietario: Es el propietario de los dispositivos M2M conectados a una plataforma de habilitación de servicio M2M genérica y, en consecuencia, el propietario de los datos recopilados y gestionados. El cliente propietario debe tener una relación contractual con un operador de red (fijo o móvil) para proporcionar conectividad de servicio a sus dispositivos. El cliente propietario puede definir sus CO relevantes, asociándose cada CO con o bien un único dispositivo M2M o bien un conjunto de dispositivos M2M conectados a la plataforma. El propietario tiene los derechos para las funciones que pueden realizar esos dispositivos. Un cliente propietario está suscrito por defecto a sus CO. En consecuencia, sus aplicaciones conectadas a la plataforma

35 pueden consumirlos. El cliente propietario puede crear tantos CO como sean necesarios (que oscilan de “1 a n”) que satisfacen sus propios criterios y también definir niveles de umbral de advertencia o alerta específicos, que pueden activar una notificación específica. El cliente propietario tiene los derechos para recuperar datos desde sus CO; por ejemplo, un CO puede definirse simplemente para los datos detectados por un sensor único en un lugar determinado, o puede definirse para la recopilación de datos detectados desde un conjunto de sensores remotos (del mismo tipo o de diferente tipo de sensores) distribuidos en un área determinada de relevancia para el cliente.

Flujo de datos (DS): Un flujo de datos es la entidad de datos individual gestionada por una plataforma de habilitación de servicio M2M genérica y asociada de manera inequívoca a un objeto conectado (CO), que

45 pertenece a un único cliente propietario.

Cliente tercero: Es otro cliente de una plataforma de habilitación de servicio M2M genérica con permisos concedidos proporcionados por un cliente propietario de la misma plataforma para consumir los datos del cliente propietario publicados en esta plataforma M2M genérica. Este servicio se habilita por medio de un servicio de suscripción para una funcionalidad de intermediación de datos. Un cliente tercero ha concedido permisos de suscripción a una entidad dada denominada “objeto de aplicación específica (SAO)”, que puede ser sólo un objeto conectado, una agregación de objetos conectados o un subconjunto de un objeto conectado expuesto por un cliente propietario con fines comerciales. En consecuencia, un cliente tercero también puede definir alertas y recibir notificaciones originadas por la circunstancia de eventos definidos.

55 Funcionalidad de intermediación de datos: Es una función común proporcionada por una plataforma de habilitación de servicio M2M genérica que permite que un cliente tercero se suscriba a un objeto de aplicación específica. Cada SAO puede contener información valiosa para la aplicabilidad en sectores verticales M2M específicos; por ejemplo: cobro de servicio, medición de parámetros de energía para control de consumo, recopilación de parámetros relacionados con asistencia médica, información crítica en entornos industriales para monitorización y control de máquinas, automatización en el hogar y de edificios, gestión logística, servicios de coches conectados tales como conducción asistida o notificaciones de emergencia, etc.). Este servicio de suscripción se gestiona por el cliente propietario por medio de reglas de acceso a datos, o reglas de permiso.

65 Reglas de acceso a datos: Las reglas de permisos establecidas por los clientes propietarios que proporcionan la capacidad de acceder y consumir un contenido asociado a un objeto de aplicación específica, cada vez que se actualiza (suscripción concedida).

imagen7

imagen8

Objeto de aplicación específica: Una entidad virtual compuesta por o bien un objeto conectado, o bien una agregación de objetos conectados o bien un subconjunto de un objeto conectado; que debe tratarse como una

5 entidad individual para los propósitos específicos definidos por la aplicación de la plataforma de habilitación de servicio M2M; (por ejemplo, cobro, control médico, supervisión de consumo de energía, monitorización y control de maquinaria industrial, automatización en el hogar y de edificios, control eficaz de alumbrado público, recogida selectiva de basura, gestión de logística, operaciones de estacionamiento en la calle, control de riego de zonas verdes, control de uso de carreteras, asistencia a la conducción, asistencia de seguridad pública y recuperación de desastres, juegos, robótica, etc.…)

Generación de objeto de aplicación específica: Procedimiento por el que un cliente de una plataforma de habilitación de servicio M2M genérica (o el administrador de una plataforma de este tipo) decide qué conjunto de datos procedentes de sus objetos conectados aprovisionados pueden vincularse a un SAO, para propósitos de

15 aplicación específica. El resultado de este procedimiento es la creación de un catálogo SAO.

Entidad funcional de aprovisionamiento: Por naturaleza, es una base de datos de una plataforma de habilitación de servicio M2M genérica con capacidades de comunicaciones en las que todos los actores (clientes, aplicaciones, etc.) tienen que registrarse con el fin de almacenar toda la información necesaria para ejecutar los servicios. También se almacenan aquí los permisos de acceso para la función de intermediación de datos.

Entidad funcional de gestión de suscripción: Es la entidad funcional de una plataforma de habilitación de servicio M2M genérica que hace un seguimiento de las suscripciones de cliente a los datos que se publican o se entregan por los dispositivos M2M y que están expuestos en el catálogo SAO.

25 Entidad funcional de seguridad, autenticación y privacidad: Se implementa en un módulo de seguridad. Ésta es la entidad para comprobar las credenciales de cliente, que se requieren para conceder acceso a la parte principal de los procedimientos de plataforma de habilitación de servicio M2M genérica.

Entidad funcional de gestión de flujo de datos (DS): Es el núcleo de una plataforma de habilitación de servicio M2M genérica para procesamiento de datos, almacenamiento de datos y envío de datos.

Identidad de objeto de aplicación específica: Una identidad válida asignada a un SAO. Esta identidad (ID) se usa para correlacionar diferentes fuentes de información relacionadas con la aplicación.

35 Objeto fundamental (F-SAO): Es un SAO que actúa como punto de inicio para una jerarquía de estructura de objetos de aplicación específica. Un F-SAO tiene una SAO_ID asociada.

Objeto derivado (D-SAO): Un nuevo SAO que puede crearse a partir de uno o varios F-SAO. Un D-SAO también puede crearse o bien mediante agregación de más de un objeto derivado, o bien a partir de un objeto derivado específico; definiendo, entonces, una jerarquía de objetos de aplicación específica. Un D-SAO tiene una SAO_ID asociada.

Objeto de organización (O-SAO): Una abstracción de SAO compuesta por una agregación de objetos 45 fundamentales. Es posible añadir más de un nivel de objetos de organización.

Objeto temporal: Un SAO solicitado por un cliente tercero. Es una disposición diferente del objeto expuesto con respecto a lo que ha decidido el propietario. Debe acordarse por el propietario y sólo se crea temporalmente.

La presente invención proporciona funciones, por ejemplo, gestión de suscripción, comunes para muchos o diversos tipos de aplicaciones y dispositivos. Esto tiene dos implicaciones: por un lado, la habilitación de los medios correctos para el cliente propietario para acceder a y consumir un flujo específico de datos originados en sus propios dispositivos; y por otro lado, la habilitación de una función de intermediación de datos de sensores, permitiendo al cliente propietario gestionar permisos de acceso a datos de terceros (por ejemplo,

55 desarrolladores, integradores de sistemas, proveedores de servicios de aplicación, etc.).

La presente invención proporciona una plataforma de habilitación de servicio M2M genérica con una funcionalidad de suscripción de terceros por medio de interfaces transparentes para los servicios de los terceros y que permiten al cliente propietario gestionar y publicar datos para otros clientes (e incluso cobrar, por ejemplo, por el uso de estos datos por otros clientes).

La presente invención dota al cliente propietario de herramientas (reglas de autorización de entrega de datos) para garantizar un acceso controlado a los datos, de modo que el cliente propietario puede conceder o denegar intentos individuales de acceso a datos, para cada fuente de datos y también para cada intento de acceso a

65 datos, minimizando al mismo tiempo la tasa de petición “molesta” para conceder accesos. Las reglas de autorización de entrega de datos se basan en mezclar dos tipos de modos de autorización:

imagen9

imagen10

-Autorización indirecta, por la que el cliente propietario autoriza el acceso a los datos antes de solicitarse por cualquiera. El cliente propietario puede considerar autorizaciones individuales, autorizaciones de listas de contactos (lista blanca). También es posible una autorización de listas por defecto y una lista excluida (lista negra) de usuarios no autorizados.

5

o Para la autorización de listas de contactos, el cliente propietario especifica el conjunto de datos que va a asociarse con una lista de contactos. Puede haber más de un conjunto de datos por lista de contactos. Los datos asignados a la lista de contactos son accesibles por todos los clientes terceros en esa lista de contactos excepto esos clientes que tienen una autorización individual. La autorización individual tiene la prioridad más alta.

o Para la autorización individual, el cliente propietario especifica un conjunto que va a asociarse con un cliente tercero. Es necesaria una notificación adicional si el cliente autorizado solicita otro conjunto de datos distintos de los autorizados.

15

o El cliente propietario puede especificar una lista de conjunto de datos expuestos por defecto (autorización de lista por defecto); un conjunto de datos disponible para todos los clientes que no pertenecen a la lista excluida (de usuarios no autorizados).

o Puede haber más de un conjunto de datos por cliente tercero. Cuando se autoriza a un cliente tercero tanto individualmente como a través de una lista de contactos, entonces la autorización individual tiene prioridad sobre la autorización de lista, es decir el conjunto de datos del individuo anula el conjunto de datos de la lista de contactos.

25 o Si el cliente tercero solicita otro conjunto de datos distintos de los autorizados por el cliente propietario, se aplica una autorización directa. Si el cliente propietario autoriza indirectamente a un cliente tercero dado a través de una autorización individual, pero con indicación de que se le notifique cuándo este abonado autorizado solicita otro conjunto de datos distintos de los que ya se autorizaron, la entidad de gestión de suscripción lo notifica al cliente propietario. Esta notificación contiene la ID del cliente tercero y la lista de conjunto de datos solicitado adicional, actualmente no autorizada.

-Autorización directa, por la que el cliente propietario autoriza el acceso a datos basándose en una

35 petición específica. Si el cliente propietario no autoriza al cliente tercero de ninguna manera (ni autorización individual ni de lista de contactos, y la lista de datos solicitados no se cubre en la lista de datos por defecto), el cliente propietario notifica acerca de peticiones de conjunto de datos adicionales distintos de los autorizados a través de la lista por defecto. Por tanto, la entidad de gestión de suscripción lo notifica al cliente, pidiendo autorización explícita. La notificación contiene la ID del cliente tercero y la lista de conjunto de datos solicitados adicionales que actualmente no están autorizados.

Las reglas de autorización de entrega de datos están almacenadas en la entidad de base de datos de aprovisionamiento, vinculadas a los datos para los que se autoriza su entrega que están almacenados en una

45 entidad de almacenamiento de datos. Necesitan cierta interacción con una base de datos de aprovisionamiento con el fin de completar la información requerida (ID de listas de contacto de terceros, ID de cliente tercero, etc.). Los procedimientos relacionados con las interacciones de autorización garantizan que el número de interacciones con el cliente propietario se mantenga al nivel más bajo posible. La autorización (directa o indirecta) puede dirigirse o bien a clientes individuales o bien a un grupo de clientes a través de una lista de contactos, o bien al público general a través de una lista por defecto. Los datos reales que se autorizan para su entrega deben definirse en un conjunto de datos específicos.

Un aspecto de la invención se refiere a un procedimiento para gestionar datos (recopilación, procesamiento y exposición de datos) en sistemas M2M (es decir, en cualquier plataforma de habilitación de servicio M2M

55 genérica), que comprende las etapas de:

-registrar un cliente propietario y un cliente tercero (adicionalmente, sus aplicaciones, etc. están registradas; normalmente, toda la información requerida para ejecutar servicios en un sistema M2M) en una base de datos de aprovisionamiento que pertenece al sistema M2M;

-definir por parte del cliente propietario al menos un objeto conectado (CO), que se asocia, en la base de datos de aprovisionamiento, con datos procedentes de o bien un único dispositivo M2M o bien un conjunto de dispositivos M2M del cliente propietario;

65 -suscripción del cliente propietario a cada objeto conectado definido (por el propio cliente propietario) al validar una identidad inequívoca única (CO_ID) de cada CO en la base de datos de aprovisionamiento;

imagen11

imagen12

-publicación al cliente tercero por parte del cliente propietario, en la base de datos de aprovisionamiento, de al menos un objeto de aplicación específica (SAO), que consiste en un único CO, una cierta parte de un único CO o una agregación de múltiples CO, comprendiendo la publicación una asociación del SAO con datos procedentes de los objetos conectados que están definiendo dicho objeto de aplicación

5 específica;

-definición por parte del cliente propietario, en la base de datos de aprovisionamiento, de reglas de acceso a datos para permitir que el cliente tercero (es decir, sus aplicaciones registradas) solicite suscripción a un SAO que se publica a dicho cliente tercero.

El mapeo o la vinculación de objetos de aplicación específica a objetos conectados definidos por el cliente propietario (y asociados con datos de sus dispositivos M2M) en la base de datos de aprovisionamiento puede seguir una jerarquía de niveles tal como se definió anteriormente: con SAO fundamentales en un nivel de inicio de la jerarquía, SAO derivados en un nivel siguiente y añadiendo niveles al definir uno o más niveles de SAO

15 organizacionales, por ejemplo. También es posible que los SAO temporales permitan que el cliente tercero modifique (con el permiso del cliente propietario) este mapeo inicial entre SAO y CO definido originalmente por el cliente propietario dependiendo de la aplicación específica a la que está registrado el cliente tercero.

El procedimiento permite que el cliente propietario conceda a clientes terceros la transmisión y recepción de cualquier tipo de mensaje de petición/respuesta de gestión de dispositivo relacionado con la monitorización, configuración, notificación o control de dispositivos.

Un aspecto adicional de la invención se refiere a un producto de programa informático que comprende medios de código de programa que van a cargarse en medios de procesamiento de uno o más dispositivos electrónicos

25 programables, que pueden ser una unidad de procesamiento central o procesador de un ordenador, un procesador de propósito general, un procesador de señal digital, una disposición de puertas programables en campo (FGPA), un circuito integrado de aplicación específica (ASCI), un microprocesador , un microcontrolador o cualquier otra forma de hardware programable, integrado en un sistema M2M, con el fin de ejecutar el procedimiento descrito.

Descripción de los dibujos

Para completar la descripción que está realizándose y con el objeto de ayudar a un mejor entendimiento de las características de la invención, según un ejemplo preferido de la realización práctica de la misma, a dicha

35 descripción le acompañan como parte integral de la misma un conjunto de dibujos en los que, a modo de ilustración y de manera no restrictiva, se ha representado lo siguiente:

La figura 1 muestra un diagrama de bloques de la arquitectura de servicio de objeto conectados para una aplicación de servicio de cobro según una posible realización de la invención.

La figura 2 muestra un diagrama de bloques de entidades y dominios funcionales, así como su relación a través de interfaces de comunicación, involucradas en el cobro basándose en la arquitectura de servicio de objeto conectado según una posible realización de la invención.

45 La figura 3 muestra una representación esquemática de una asociación lógica de dispositivos M2M con objetos conectados y el mapeo entre objetos conectados y objetos de aplicación específica para cobro, por parte del cliente propietario de los dispositivos, según una posible realización de la invención.

La figura 4 muestra un árbol de aprovisionamiento de identidades de objeto conectado clasificadas en niveles por el cliente propietario, según una posible realización de la invención.

La figura 5 muestra una estructura jerárquica de objetos de aplicación específica para cobro que puede mapearse con el árbol de aprovisionamiento, según una posible realización de la invención.

55 La figura 6 muestra un diagrama de bloques de herencia directa de reglas de acceso en objetos de aplicación específica para cobro, según una posible realización de la invención.

La figura 7 muestra un diagrama de flujo de mensajes para un proceso de suscripción a un objeto de aplicación específica para cobro en el que se aplica una herencia directa de reglas de acceso, según una posible realización de la invención.

La figura 8 muestra un diagrama de bloques de herencia inversa de reglas de acceso en objetos de aplicación específica para cobro, según una posible realización de la invención.

65 La figura 9 muestra un diagrama de flujo de mensajes para un proceso de creación de un objeto de cobro temporal, según una posible realización de la invención.

imagen13

imagen14

La figura 10 muestra un diagrama de flujo de mensajes para el proceso de aprovisionamiento de un objeto de cobro fundamental, según una posible realización de la invención.

La figura 11 muestra un diagrama de flujo de mensajes para el proceso de aprovisionamiento de un objeto de 5 cobro derivado, según una posible realización de la invención.

La figura 12 muestra un diagrama de flujo de mensajes para el proceso de aprovisionamiento de un objeto de cobro de organización, según una posible realización de la invención.

La figura 13 muestra un diagrama de flujo de mensajes para un proceso de suscripción a un objeto de aplicación específica para cobro seleccionado de fundamental, derivado y de organización, según una posible realización de la invención.

La figura 14 muestra un diagrama de flujo de mensajes para un proceso de cobro en línea implementado por una

15 función de datos de cobro de objeto usando los objetos de aplicación específica para cobro, según una posible realización de la invención.

Descripción detallada de la invención

Una realización preferida de la invención se centra en un procedimiento de control de los flujos de datos originados a partir de diferentes dispositivos conectados a una red de sensores con el fin de controlar eventos de cobro asociados con estos dispositivos de sensor. Este procedimiento permite procedimientos de cobro entre el propietario y terceros con acceso concedido. Un cobro basado en objeto conectado se describe como un metaenfoque de cobro que presta más atención al elemento que está cargándose en lugar de en la especificidad de la

25 información de cobro recopilada de ese elemento. Es decir, en cualquiera de los enfoques de cobro actuales, la información de cobro siempre se comprueba con la factura asignada a una cuenta de usuario individual; mientras tanto, en el cobro basado en objeto conectado, la información de cobro se comprueba con o se carga en cuentas de objetos individuales. El cobro basado en objeto conectado aprovecha el volumen de dispositivos conectados en lugar de modelos de cobro legados basándose en el volumen de datos transmitidos, intervalo de tiempo del cobro de evento o conexión.

En el ecosistema M2M, el concepto de abonado móvil o de telefonía se vuelve menos preciso para describir el desempeño de los elementos que van a interactuar con la red móvil. Y por tanto, los enfoques de cobro clásicos no son lo suficientemente flexibles para afrontar todos los requisitos entrantes de servicios móviles.

35 En el negocio de las telecomunicaciones, sólo hay dos modos principales de cobro: denominados fuera de línea y en línea. La diferencia principal se reduce a la capacidad de prestar el servicio requerido después de comprobar la cuenta de cliente en tiempo real o no. Estos dos modos principales están relacionados con algunas estrategias de cobro, que pueden ser aplicables a uno o ambos modos. En este sentido, puede definirse, por ejemplo, un cobro basado en flujo en línea, un cobro basado en volumen fuera de línea o un cobro basado en sesión/evento en línea.

Se requiere introducir algún elemento en las soluciones de arquitectura de cobro actuales con el fin de dar lugar a la inteligencia necesaria para implementar el cobro basado en objeto conectado. El elemento funcional principal

45 requerido para eso se denomina función de datos de cobro de objeto (OCDF), que es responsable de encontrar el objeto correcto que va a cobrarse y enviar la petición de facturación con esta información hasta la fecha. A continuación se describe la relación de arquitectura de la OCDF con el resto de funciones en las arquitecturas de cobro legadas de un operador de red móvil.

El cobro basado en objeto conectado propone una estructura jerárquica que tiene que definirse antes del proceso de cobro. Esta estructura es necesaria con el fin de asignar correctamente el artículo que puede cobrarse a la factura correcta y facilitar nuevas reglas de cobro para el elemento intermediador de arquitectura de servicio de objetos conectados, que es una plataforma de habilitación de servicio de valor añadido M2M. El cliente propietario es quien posee los objetos conectados/dispositivos/máquinas en esta plataforma de intermediador.

55 Adicionalmente, esta jerarquía define alguna relación entre diferentes facturas de objetos basándose en conceptos como herencia inversa: es posible que un objeto fundamental pueda heredar la factura asignada a su objeto derivado. Esta jerarquía facilita nuevas reglas de cobro para un cliente propietario a un cliente tercero.

Para la realización particular de la invención descrita en este caso, aplican los siguientes términos y definiciones:

Registro de datos de cobro (CDR): registro generado por un elemento de red con el propósito de facturar a un abonado por el servicio proporcionado. Incluye campos que identifican el usuario, la sesión y los elementos de red así como información sobre los servicios y recursos de red usados para soportar una sesión de

65 abonado. En el dominio de circuito tradicional, CDR se ha usado para indicar “registro de detalle de llamada”, que se incluye en “registro de datos de cobro” a continuación en el presente documento.

imagen15

imagen16

CDR parcial: CDR que proporciona información sobre parte de una sesión de abonado. Una sesión larga puede cubrirse por varios CDR parciales. Se consideran dos formatos para CDR parciales: uno que contiene todos los campos necesarios y un formato reducido.

5 Facturación: Es el mecanismo de procesamiento y presentación de una factura. Por tanto, esos registros de datos de cobro (CDR) generados por la función de cobro se transforman en facturas que requieren pago.

Dominio de facturación: Parte de la red de operador, que está fuera de la red principal, que recibe y procesa la información de cobro desde las funciones de cobro de red principal. Incluye funciones que pueden proporcionar aplicaciones finales de facturación y de mediación de facturación.

Cobro: Proceso de recopilar datos para monitorizar el uso de recursos, contabilidad y (o) facturación. Por tanto, proporciona una función por la que se da formato a la información relacionada con un evento que puede cobrarse y se transfiere con el fin de hacer posible determinar el uso por el que puede facturarse a la parte cobrada.

15 Objeto de cobro (CHO): Es una implementación particular del objeto de aplicación específica previamente definido para cobro, siendo una entidad virtual compuesta por un objeto conectado, una agregación de objetos conectados o un subconjunto de un objeto conectado; que debe tratarse como una entidad individual con fines de cobro.

Generación de objeto de cobro: Procedimiento por el que un cliente de una plataforma de habilitación de servicio M2M genérica (o el administrador de una plataforma de este tipo) decide qué conjunto de datos procedentes de sus objetos conectados aprovisionados están vinculados a un objeto de cobro, con fines de cobro.

25 Identidad de objeto de cobro (CHO_ID): Una entidad válida asignada a un objeto de cobro específico. La CHO_ID se usa para correlacionar diferentes fuentes de información relacionada con el cobro.

Evento que puede cobrarse: cualquier actividad que puede cobrarse que utiliza la infraestructura de red de plataforma de habilitación de servicio M2M genérica y servicios relacionados.

Parte cobrada: usuario involucrado en un evento que puede cobrarse que tiene que pagar parte de o todos los costes del evento que puede cobrarse, o un tercero que paga los cargos provocados por uno o todos los usuarios involucrados en el evento que puede cobrarse, o un operador de red.

35 Cobro basado en objeto: Política de cobro en la que eventos que pueden cobrarse se refieren a la entidad definida como objeto de cobro. El cobro basado en objeto puede ser fuera de línea o en línea y basarse en la sesión, el evento o el flujo.

Cobro fuera de línea: Mecanismo de cobro en el que el cobre de la información no afecta, en tiempo real, el servicio prestado.

Cobro en línea: Mecanismo de cobro en el que el cobro de la información puede afectar, en tiempo real, el servicio prestado y por tanto se requiere una interacción directa del mecanismo de cobro con control de sesión/servicio.

45 Objeto de cobro fundamental (F_CHO): Un objeto de cobro asociado con un objeto conectado aprovisionado en una base de datos de aprovisionamiento, que es el punto de inicio para una jerarquía de estructura de objetos de cobro. Un objeto de cobro fundamental tiene una ID de objeto de cobro asociada.

Objeto de cobro derivado (D_CHO): Un nuevo objeto de cobro que puede crearse a partir de un objeto de cobro fundamental o varios F-CHO. Un objeto de cobro derivado también puede crearse o bien mediante agregación de más de un objeto de cobro derivado, o bien a partir de un objeto de cobro derivado específico; definiendo entonces, una jerarquía de objetos de cobro. Un objeto de cobro derivado siempre es un objeto de cobro y por tanto tiene una ID de objeto de cobro asociada.

55 Objeto de cobro de organización (O_CHO): Una abstracción de objeto de cobro en el sentido de que no está vinculado en absoluto a un objeto conectado. Está compuesto por una agregación de CHO fundamentales y es posible añadir más de un nivel de objetos de cobro de organización.

La figura 1 muestra un diagrama de los actores y sus interacciones en el modelo de cobro basado en objeto conectado, que pueden implementar las siguientes trayectorias de flujo de dinero:

-Entre el cliente propietario 2 y el intermediador 6 que posee la plataforma de cobro basado en objeto conectado: El intermediador 6 define reglas de cobro dependiendo del uso de recursos de 65 plataforma asociado al objeto conectado definido por el cliente propietario 2.

imagen17

imagen18

-Entre el cliente propietario 2 y el cliente tercero 3: El intermediador 6 dota al cliente propietario 2 de medios para cobrar al cliente tercero 3 por el uso de los objetos conectados del propietario o partes de estos objetos.

5 Obsérvese que tanto el cliente propietario 2 como el cliente tercero 3 pueden adoptar el papel de proveedor de servicios 4, dando servicio a peticiones entrantes procedentes de un usuario final 1, o desempeñar el papel de desarrollador 5 dirigiendo peticiones al intermediador 6 desde usuarios finales y clientes que son partes cobradas. A su vez, el intermediador 6 desempeña la funcionalidad de intermediación de datos común al suministrador de plataforma de servicios M2M 7 así como el suministrador de los dispositivos de sensor 8 asociados con los objetos conectados y al operador de red móvil 9 de la red a la que se conectan los dispositivos. El integrador de sistema 10 puede desempeñar los papeles de suministrador de dispositivo de sensor 8, proveedor de servicios 4 y/o desarrollador 5 conjuntamente porque integra soluciones de llave en mano para los usuario finales 1.

15 El cobro basado en objeto conectado es un metaenfoque de cobro que presta más atención al elemento que está cobrándose en lugar de a la especificidad de la información de cobro recopilada de ese elemento. Es decir, en cualquiera de las estrategias de cobro existentes (en cualquiera de los dos posibles modos de cobro (en línea o fuera de línea), por ejemplo, cobro basado en flujo en línea, cobro basado en volumen fuera de línea o cobro basado en sesión/evento en línea) la información de cobro siempre se comprueba con la factura asignada a una cuenta de usuario individual; mientras tanto, en el cobro basado en objeto conectado, la información de cobro se comprueba con o se carga en las cuentas de objeto individual (cuentas de objetos de cobro).

Adicionalmente, el objeto de cobro (CHO) desempeña un papel importante en cómo los permisos de acceso se asignan y se derivan a los diferentes datos que están comercializándose. Los CHO tienen una estructura

25 jerárquica definida antes del evento que puede cobrarse. Esta estructura es necesaria con el fin de asignar correctamente el evento que puede cobrarse a la factura correcta, permitiendo al intermediador 6 definir nuevas reglas de cobro para el cliente propietario 2. Adicionalmente, esta jerarquía define alguna relación entre diferentes cuentas de objetos de cobro individuales. Se definen dos clases de jerarquía: herencia inversa, en la que un objeto de cobro de organización (O_CHO) puede heredar el esquema de cobro asignado a los objetos de cobro fundamentales de los que está compuesto este O_CHO; y viceversa con herencia directa. Por tanto, un objeto de cobro fundamental (F_CHO) puede heredar la factura asignada a su objeto de cobro derivado (D_CHO), que también facilita la definición de nuevas reglas de cobro para el cliente propietario 2 por el cliente tercero 3.

35 Según la definición descrita de forma general anteriormente, la figura 2 muestra el elemento funcional principal introducido en las soluciones de arquitectura de cobro actuales con el fin de producir la inteligencia requerida para implementar el concepto de cobro basado en objeto conectado. Este elemento de función común se denomina función de datos de cobro de objeto, OCDF, que es responsable de descubrir el objeto correcto que debe cobrarse, al que debe darse formato y debe transferirse a la petición de facturación con esta información actualizada del dominio de cobro basado en objeto conectado 23. El dominio de cobro basado en objeto conectado 23 hace posible determinar el uso para el que puede facturarse la parte cobrada. Con ese propósito, la arquitectura de plataforma de habilitación de servicio M2M permite un registro completo de eventuales eventos que pueden cobrarse a medida que se procesan. Por tanto, los registros de datos de evento (EDR) pueden registrarse en una base de datos de evento que es el elemento central del dominio de cobro basado en objeto

45 conectado. A partir de los EDR, el cliente propietario 2 decide su política de evento que puede cobrarse.

La figura 2 también ilustra la relación de arquitectura de la OCDF con el resto de funciones en las arquitecturas de cobro legadas de un operador de red móvil que interactúa dentro de un dominio de facturación 20. El dominio de facturación 20 es responsable del procesamiento y presentación de una factura a los clientes de la plataforma de habilitación de servicio M2M.

-el sistema de cobro en línea, OCS, que permite a un proveedor de servicios de comunicaciones cobrar a sus clientes, en tiempo real, basándose en uso de servicio en el dominio de conmutación por paquetes (PS) 21,

55 -la función de pasarela de cobro de 3GPP, CGF, usada en el dominio de GSM/GPRS/UMTS/IMS 22.

Según este concepto de cobro basado en objeto conectado, se requieren tres nuevas interfaces, tal como se muestra en la figura 2: las interfaces Oc, Og y la Of entre la OCDF y respectivamente el dominio de cobro basado en objeto conectado 23, dominio PS 21 y dominio IMS 22. Si la OCDF se implementa como parte de tanto la CGF como el OCS, estas interfaces Oc, Og y Of pueden definirse internamente (por tanto, propietarias).

El OCS puede realizar la correlación de cobro según la 3GPP TS 32.296 “Telecommunication management; Charging management; Online Charging System (OCS): Application and interfaces (Release 10)” (sección 4: 65 “Required functionality of the OCS”). La CFG puede obtener registros de cobro correlacionados de los múltiples flujos de datos mediante una función de datos de cobro centralizada (CDF) según la 3GPP TS 32.240

imagen19

imagen20

“Telecommunication management; Charging management; Charging Architecture and Principles (Release 9)” (figura 4.2 “Logical ubiquitous charging architecture and information flows” y figura 4.3.1 “Logical ubiquitous offline charging architecture”). Se necesita otra nueva interfaz, entre la OCDF y el dominio de facturación 20: la interfaz Bo, que está definida para cargar las interacciones externas en nombre del cliente propietario 2.

5 La información de correlación de cobro basada en objeto puede codificarse en una cabecera específica de todos los mensajes gestionados por una plataforma de habilitación de servicio M2M genérica. Cualquier entidad funcional de la plataforma de habilitación de servicio M2M genérica es responsable de rellenar esa cabecera antes de emitir cualquier mensaje. La única información requerida en esa cabecera es la identidad de objeto de cobro (CHO_ID). La manera en que cualquier entidad funcional específica descubre la CHO_ID en una plataforma de habilitación de servicio M2M genérica depende en gran medida de los mensajes (peticiónrespuesta) implicados en la interacción. En algunas de esas interacciones, la CHO_ID es una parte inherente del mensaje (por ejemplo, una suscripción a un CHO, que se implementa usando la CHO_ID como el puntero), pero en otras pueden requerirse interacciones dedicadas con la base de datos de aprovisionamiento de la plataforma

15 de habilitación de servicio M2M genérica, que es la entidad en la que se almacena principalmente la CHO_ID, con el fin de lograr el conocimiento de ese parámetro.

La CHO_ID se usa como el puntero frente a la entidad OCDF con el fin de pedir autorización para implementar la interacción solicitada y las condiciones específicas en las que la interacción puede entregarse al cliente de la plataforma. Por eso, en algunos casos la OCDF puede necesitar interactuar con las entidades funcionales CGF y OCS con el fin de lograr no sólo cualquier información relacionada con el cobro requerida sino también imponer a esas entidades esas reglas aplicables de cobro basadas en objeto. Es responsabilidad de la OCDF correlacionar la información de cobro basada en objeto con la información usada en las entidades a las que se hace referencia con el fin de obtener acceso a la información relacionada con el cobro correcta (por ejemplo, la regla de cobro

25 correcta almacenada en la entidad OCS) o imponer las reglas de cobro basadas en objeto a las interacciones de cliente correctas.

Los objetos de cobro se mapean con objetos conectados implementados en una base de datos de aprovisionamiento de una plataforma de habilitación de servicio M2M genérica. Este mapeo se lleva a cabo exclusivamente por parte del cliente propietario 2 tras una estricta comprobación de sus credenciales. El cliente propietario 2 tiene algunas primitivas de API disponibles y primitivas proporcionadas por una interfaz web con el fin de llevar a cabo dicho mapeo.

El cliente propietario 2 de una plataforma de habilitación de servicio M2M genérica puede definir 31, tal como se

35 muestra en la figura 3, diferentes grupos de sus bienes (por ejemplo, dispositivos M2M remotos D y pasarelas G), basándose en qué es relevante para su negocio. Esto implica la provisión de un conjunto de objetos conectados a esta plataforma. Los grupos de bienes, g1, g2, g3, g4, g5, se mapean 32 en la plataforma en, por ejemplo, dos objetos conectados CO1 y CO2. Cada CO se procesa mediante la plataforma de habilitación de servicio M2M como un flujo de datos, DS1 y DS2 respectivamente en la figura 3, que es la única entidad de datos gestionada por esta plataforma y asociada inequívocamente a un objeto conectado. Con el fin de exponer los datos recopilados para el consumo de clientes terceros (habilitando una nueva funcionalidad de intermediación de datos en la plataforma), el cliente propietario 2 puede configurar un conjunto de objetos de cobro, CHO#1, CHO#10, CHO#101, CHO#11, CHO#111, que pueden asociarse 33 a un objeto conectado completo, a una agregación de objetos conectados o a una parte de un objeto conectado individual.

45 En una plataforma de habilitación de servicio M2M genérica, el cliente propietario 2 define objetos conectados mapeados con las fuentes de datos que se incluyen en un flujo de datos específico, y este mapeo se tiene en cuenta por las entidades funcionales de gestión de datos correspondientes en la plataforma de habilitación de servicio M2M, con el fin de componer los mensajes según esta disposición. Adicionalmente, una versión reducida

o completa de la información contenida en un objeto conectado es el elemento expuesto por el cliente propietario 2 a esos clientes terceros 3 para una eventual suscripción y otras operaciones de la plataforma. Es decir, el objeto conectado es el elemento clave de la entidad de gestión de datos definida en una plataforma de habilitación de servicio M2M genérica.

55 Por tanto, el enfoque de objeto de cobro añade una organización virtual encima de la organización física y real descrita a través de las identidades de objeto conectado. Este enfoque virtual ofrece mucho valor y simplicidad sobre cómo cobrar a los clientes de una plataforma de habilitación de servicio M2M genérica (o bien un cliente propietario 2 o bien un cliente tercero 3), que puede acceder a los datos recopilados de dispositivos remotos M2M, exactamente por aquello a lo que desean acceder. En resumen, las principales ventajas del presente enfoque son:

•

Posible descuento por volumen agregado.

•

Cobro más claro: es fácil para cualquier cliente propietario 2 o cliente tercero 3 entender qué se le

está cobrando. 65 • Cobro flexible: es posible cambiar fácilmente la tarifa que está aplicándose a un objeto específico.

• Gestión de accesos a los datos fácilmente: la misma claridad aplicable al cobro es aplicable a qué datos está accediendo el cliente.

imagen21

imagen22

Una arquitectura de denominación y direccionamiento que permite un procedimiento inequívoco para accesibilidad de dispositivo remoto y las definiciones de objeto conectado guía al cliente propietario 2 a la hora 5 de aprovisionar objetos conectados con configuración personalizada. Esta arquitectura de denominación y direccionamiento determina finalmente el nivel de exposición de los datos recopilados respecto al consumo de aplicaciones del cliente tercero (si el servicio de suscripción los permite). La figura 4 ejemplifica cómo un cliente propietario 2 puede configurar una identidad de objeto conectado (CO_ID) específica en un árbol de aprovisionamiento 40, independientemente del rango (capa) de esa identidad. Adicionalmente, esa decisión es importante, porque la CO_ID podría relacionarse con el objeto de cobro expuesto al mundo exterior por la suscripción de terceros a los datos de cliente propietario y, aún más importante, cualquier regla o restricción de acceso está vinculada a las CO_ID definidas. En el ejemplo de la figura 4, hay cuatro objetos conectados CO_ID#1, CO_ID#2, CO_ID#3, CO_ID#4. CO_ID#1 está constituido por la contribución de dos dispositivos, Dev_ID#1-1 y Dev_ID#1-2; CO_ID#4 está constituido por la contribución de otros dos dispositivos, Dev_ID#41 y

15 Dev_ID#42; mientras que los otros dos CO tienen sólo una contribución de un dispositivo diferente en cada caso, Dev_ID#21 y Dev_ID#31. En el ejemplo de la figura 4, tres rangos de identidades de CO: capa1, capa2 y capa3. El árbol de aprovisionamiento 40 obtenido mediante esta denominación y direccionamiento de CO puede crecer añadiendo capa 4 y capas posteriores, en el caso de que algún dispositivo remoto puede tener capacidades de encaminamiento para conectarse a cualquier otro nodo de sensor muy remoto. Este procedimiento de denominación y direccionamiento es muy potente y flexible porque proporciona medios para definir un nombre único vinculado a una dirección accesible (por ejemplo, dirección IP, número MSISDN, direcciones usadas por protocolos tales como SIP o el protocolo de transporte de telemetría de MQ, MQTT, etc.), con el fin de personalizar qué datos el cliente propietario 2 desea exponer al resto del mundo.

25 La figura 5 muestra una estructura virtual y de solapamiento de organización de objetos con fines de cobro, basándose en el procedimiento de denominación y direccionamiento descrito anteriormente, que facilita de manera sencilla la funcionalidad de intermediación de datos. A partir del ejemplo de la figura 5, es posible describir de forma general las principales características de esta estructura de objeto de cobro de solapamiento

50:

-No existen huecos en la estructura. Cualquier elemento en la base de datos aprovisionada se asigna a un objeto de cobro (CHO).

-Cualquier objeto de cobro se identifica con una ID de objeto de cobro única (CHO_ID).

35 -Es realmente una estructura virtual. Si la unidad de mensajería de una plataforma de habilitación de servicio M2M genérica es el objeto conectado (CO), un cliente tercero 3 suscrito a un CHO formado por la agregación de, por ejemplo, dos CO, recibe dos mensajes. Esto es algo que el cliente propietario 2 debe tener en cuenta al definir sus objetos de cobro. Adicionalmente, la estructura de objeto de cobro se desacopla de la accesibilidad de CO, lo que significa que se requiere el registro del CO individual, no del CHO. Un CHO es accesible si y sólo si todos de sus CO constituyentes son accesibles.

-Es posible establecer una jerarquía de objetos de cobro. Todos los elementos de base de datos de aprovisionamiento forman parte de un CHO, pero esos CHO individuales pueden ser padre o hijo, en una

45 estructura muy similar a la definida en la teoría de programación orientada a objetos. La CHO_ID asignada refleja esta relación, con el fin de mantener el principio de denominación comprensible requerido en una plataforma de habilitación de servicio M2M genérica.

-Como consecuencia del punto anterior, puede aplicarse un concepto apropiado de herencia, con alcance en las reglas de acceso a datos definidas y el esquema de cobro aplicable a cada CHO individual. Esto también es una consecuencia de la recomendación de aplicar las reglas de acceso a datos a la estructura de objeto de cobro definida, en vez de aplicarla al CO individual.

-La estructura propuesta es más flexible porque facilita la reconfiguración de todo el sistema en caso de 55 que puedan requerirse adiciones de nuevos CO, o cambios en CO aprovisionados actuales, por los clientes propietarios 2.

La estructura de objeto de cobro 50 puede mapearse con los objetos conectados implementados en el árbol de aprovisionamiento 40 definiendo diferentes tipos de CHO configurados por el cliente propietario 3. Se proponen tres tipos de CHO y se describen de la siguiente manera:

1) Objeto de cobro fundamental (F_CHO) En el caso de configurar un objeto de cobro de primer nivel, que se define como un objeto de cobro fundamental (F_CHO), la información que debe proporcionarse por el cliente propietario comprende al menos los 65 siguientes datos:

•

Una CHO_ID provisional.

•

Una indicación de que el CHO es uno fundamental.

•

La lista del/de los objeto(s) conectado(s) constituyente(s) de ese CHO.

•

Las reglas de acceso a datos para ese CHO. No puede quedarse vacío.

•

El esquema de cobro para ese CHO. No puede quedarse vacío.

imagen23

imagen24

5 Cuando la entidad funcional de aprovisionamiento de una plataforma de habilitación de servicio M2M genérica recibe la petición de configuración de F-CHO anterior del cliente propietario 2, la exclusividad de la CHO_ID propuesta se valida obteniendo una respuesta positiva o negativa. Si la respuesta es negativa, la entidad funcional de aprovisionamiento permite al cliente propietario 2 solicitar una propuesta de CHO_ID totalmente nueva. Queda a expensas del cliente propietario 2 aceptarla o rechazarla. Si esta nueva propuesta se acepta por parte del cliente propietario 2, se asigna una nueva CHO_ID en la base de datos de aprovisionamiento (árbol de aprovisionamiento 40), y el nivel de exposición corresponde al CO, en la lista de CO constituyentes, en el nivel más alto aprovisionado en el árbol de aprovisionamiento 40. Por ejemplo, en el ejemplo descrito de forma general en la figura 5, si la lista incluye CO_ID#2, CO_ID#3 y CO_ID#4, esto significa que CHO_ID#1-2 es un

15 CHO fundamental y está vinculado al nivel marcado por estos tres CO, que es el nivel de capa 3 para ese ejemplo. Esto es una característica clave de los CHO fundamentales: siempre están vinculados a un nivel de CO_ID real definido en la base de datos.

2) Objeto de cobro derivado (D_CHO)

El cliente propietario 2 puede definir un segundo nivel de objeto de cobro, que se define como un objeto de cobro derivado (D_CHO). En ese caso, la información que debe proporcionarse por parte del cliente propietario 2 comprende al menos los siguientes datos:

• Una CHO_ID provisional. Puede ajustarse a un comodín que significa que el cliente propietario 2

requiere que el sistema proporcione esa ID. 25 • Una indicación de que el CHO es uno derivado.

•

Una indicación de los orígenes de ese CHO derivado. Puede ser:

•

Derivado meramente de uno o más CHO fundamentales.

•

Derivado meramente de otros CHO derivados.

•

Derivado de una mezcla de ambos.

•

La lista de CHO fundamentales de los que se deriva el CHO derivado.

•

La lista de los otros CHO derivados, de los que se compone el CHO derivado.

•

La lista de los objetos conectados constituyentes o partes de un objeto conectado de los/las que se compone el CHO derivado. Si el CHO derivado incluye partes de un CO, dos indicaciones adicionales se incluyen con el fin de distinguir ambos conjuntos de constituyentes, aquellos que son

35 CO completos y aquellos que son parte de un CO. Esta distinción se requiere con el fin de optimizar los procedimientos de consulta mediante los cuales la base de datos de aprovisionamiento descubre ambos conjuntos de constituyentes.

•

Las reglas de acceso a datos para ese CHO. Puede quedarse vacío

•

El esquema de cobro para ese CHO. Puede quedarse vacío.

Si las reglas de acceso y los campos de esquema de cobro se dejan vacíos, las reglas de herencia, que se describen más adelante con mayor detalle, se aplican con el fin de aportar un conjunto válido para esos parámetros.

45 Cuando la entidad funcional de aprovisionamiento de una plataforma de habilitación de servicio M2M genérica recibe la petición de configuración de D-CHO anterior del cliente propietario 2, la entidad funcional de aprovisionamiento valida la exclusividad de la CHO_ID propuesta y responde con una respuesta positiva o negativa. Existen algunas reglas para crear una CHO_ID derivada basándose en su CHO_ID fundamental. Si se siguen esas reglas por parte del cliente propietario 2, la respuesta es positiva; de lo contrario, es negativa. Si la respuesta es negativa, la entidad funcional de aprovisionamiento puede incluir una propuesta de una CHO_ID para el cliente propietario 2, pero queda a expensas del cliente propietario 2 aceptarla o rechazarla. En cualquier caso, se requiere una nueva petición por su parte con esta propuesta o una CHO_ID completamente nueva. Adicionalmente, en este caso el cliente propietario 2 rellena este campo con un comodín; cuyo significado es que el propietario deja a la entidad funcional de aprovisionamiento la responsabilidad de derivar una CHO_ID válida.

55 Por ejemplo, en el ejemplo descrito de forma general en la figura 5, si la lista incluye CO_ID#1 y el CHO fundamental es CHO_ID#1-1, se crea el CHO_ID#1-1-1 como un CHO derivado.

La definición de un CHO derivado basándose en un objeto conectado completo (o un subconjunto de un CO) es clara y nítida, e introduce una característica poderosa: el segundo nivel de CHO en la jerarquía evita reconfigurar el registro aprovisionado en su totalidad para configurar nuevos objetos conectados asignados a la nueva partición deseada del objeto conectado original. El único inconveniente puede ser que esto requiere del cliente propietario 2 un conocimiento adicional y más profundo de las identidades asignadas a cada bien (es decir, los niveles más bajos) en su organización. Ese conocimiento está garantizado por la plataforma de habilitación de servicio M2M genérica también, pero depende del cliente propietario 2 sopesar si, posiblemente, definir objetos

65 conectados adicionales, antes de la construcción de la estructura de objeto de cobro.

imagen25

imagen26

3) Objeto de cobro de organización (O_CHO)

Existe un tercer tipo de objetos de cobro que se definen como objeto de cobro de organización (O_CHO). Las principales características de este tipo de objetos de cobro son que un CHO de organización es una abstracción

5 de CHO fundamentales y puede añadirse más de un nivel de O_CHO. Por tanto, la mínima información que debe proporcionarse por parte de un cliente propietario 2 con el fin de solicitar la creación de un O_CHO comprende al menos los siguientes datos:

•

Una CHO_ID provisional.

•

Una indicación de que el CHO es uno de organización.

•

Una indicación de la composición de ese CHO de organización. Puede ser:

•

Compuestos meramente por más de un CHO fundamental.

•

Compuestos meramente por otros CHO de organización.

• Compuestos de una mezcla de ambos. 15 • La lista de CHO fundamentales de los que está compuesto el CHO de organización.

•

La lista de los otros CHO de organización de los que está compuesto el CHO de organización actual.

•

Las reglas de acceso a datos para ese CHO. Puede dejarse vacío.

•

El esquema de cobro para ese CHO. Puede dejarse vacío.

El objeto de cobro de organización añade un nivel de abstracción a la estructura de objeto de cobro que se requiere para que el cliente propietario 2 personalice la estructura de cobro.

A partir de la clasificación de CHO descrita de forma general anteriormente, obsérvese que los objetos de cobro clave son los fundamentales, porque estos CHO son los que vinculan la estructura virtual definida por el enfoque

25 de objetos de cobros y la real compuesta a partir de los objetos conectados dentro de flujos de datos gestionables. Por tanto, los F_CHO deben ser los primero definidos por el cliente propietario 2 en el caso de solicitar un servicio de suscripción. Adicionalmente, merece la pena señalar que los F_CHO son los únicos para los que proporcionar las reglas de acceso y esquemas de cobro es obligatorio.

En un procedimiento alternativo para configurar la estructura de objeto de cobro, el cliente propietario 2 empieza pidiendo a la funcionalidad de gestión de aprovisionamiento de una plataforma de habilitación de servicio M2M genérica la provisión de un CHO de organización, proporcionando al menos la siguiente información:

•

Una CHO_ID provisional.

•

Una indicación de que el CHO es uno de organización.

35 • Una indicación de que este CHO de organización no tiene ninguna estructura jerárquica definida hasta ahora. Esta indicación es una petición para que el sistema construya esta estructura por sí mismo.

•

La lista de CO de los que está compuesto el CHO de organización.

•

Las reglas de acceso a datos para ese CHO. No puede quedarse vacío.

•

El esquema de cobro para ese CHO. No puede quedarse vacío.

Con la recepción de esta petición, la función de gestión de aprovisionamiento crea el CHO fundamental requerido y comunica su provisión al cliente propietario 2 en respuesta a la petición.

45 Por ejemplo, en el ejemplo descrito de forma general en la figura 5, si el cliente propietario 2 pide aprovisionar un CHO de organización (puede denominarse CHO padre), CHO_ID 1, cuya lista de CO incluye CO_ID#1, CO_ID#2, CO_ID#3 y CO_ID#4, la función de gestión de aprovisionamiento crea ese O_CHO. Después de eso, el cliente propietario 2 puede solicitar adicionalmente la creación de dos CHO fundamentales (como los hijos de ese CHO padre); es decir, CHO_ID#1-1 y CHO_ID#1-2 vinculados a CO_ID#1 y CO_ID#2, CO_ID#2¡3 y CO_ID#4 respectivamente. La responsabilidad de la creación de CHO derivados es del cliente propietario 2.

Una vez adoptada una estructura de objeto de cobro dada, por parte del cliente propietario 2 para organizar y gestionar sus datos; es necesario definir reglas de acceso a datos y aplicabilidad de esquema de cobro para clientes terceros 3 interesados en consumir esos datos. Por tanto, la estructura de objeto de cobro finalmente

55 definida es la expuesta por el cliente propietario 2 para las peticiones de suscripción y datos procedentes de los clientes terceros 3.

Como se ha descrito y mostrado en la figura 5, cada CHO puede ser un hijo de al menos otro CHO, y/o cada CHO puede ser el padre de al menos otro CHO. Por tanto, no existen huecos en la estructura, y un enfoque de herencia, tal como el definido en la programación orientada a objetos, puede implementarse de manera sencilla para hacer más rápidas las reconfiguraciones de todo el sistema tras cambios o actualizaciones.

Las características que los objetos de cobro pueden heredar son inicialmente dos: reglas de acceso a datos y esquemas de cobro. Esto no excluye que puedan añadirse más características.

65 I) Reglas de acceso a datos El cliente propietario 2 puede definir las reglas de acceso a datos para cada uno de los CHO creados con el fin de indicar quién puede acceder a los datos y en qué condiciones.

imagen27

imagen28

El mecanismo para reglas de autorización se basa en la mezcla de dos tipos de modos de autorización: 5 -Autorización indirecta mediante la cual el cliente propietario 2 autoriza el acceso a los datos incluidos en un objeto de cobro antes de que alguien lo solicite. -Autorización directa mediante la cual el cliente propietario 2 autoriza ese acceso basándose en una petición específica.

Las reglas de acceso a datos se gestionan basándose o bien en clientes individuales o bien en un grupo de clientes a través de una lista blanca, o al público en general a través de una lista por defecto. Aquellos clientes a los que no se les permite acceder a un CHO específico se ponen en una lista negra.

15 Las reglas de acceso a datos definidas por el cliente propietario 2 se almacenan en una entidad de base de datos de aprovisionamiento (los datos reales que están autorizados a entregarse se definen en un CHO específico), vinculada a los datos que están autorizados a entregarse, y con otra información (ID de clientes terceros en la lista blanca, ID de clientes terceros en las listas negras, etc.), que también reside en la base de datos de aprovisionamiento y se necesita para completar la información requerida.

I.1) Autorización indirecta

En el modelo de autorización indirecta, el cliente propietario 2 puede considerar (antes de cualquier petición individual) la creación de autorizaciones individuales, autorizaciones de grupo o autorización por defecto. 25 También es posible definir usuarios autorizados/no autorizados, gestionados por medio de listas blancas/negras. En términos prácticos, el cliente propietario 2 tiene usuarios agrupados en listas de contacto (clientes, compañeros, etc.). En ese caso, vale la pena permitir que el cliente propietario 2 conceda/bloquee el acceso directamente a una lista de contactos en su totalidad a un CHO específico. En ese caso, el cliente propietario 2 especifica el conjunto de CHO que va a asociarse a una lista de contactos. Puede haber más de un CHO por lista de contactos. La lista de contactos se copia a cada lista blanca del CHO solicitado, de manera transparente con respecto al cliente propietario 2. Cualquier cliente tercero 3 incluido en una lista blanca de un CHO específico obtiene acceso inmediato a los datos en el CHO sin interacción adicional con el cliente propietario 2. Otros clientes terceros 3 fuera de la lista blanca que deseen acceder a un CHO específico debe seguir una política de autorización definida por el cliente propietario 2 (por ejemplo, rechazo inmediato por los clientes terceros 3 o

35 petición explícita del cliente tercero 3 al cliente propietario 2). Cuando un cliente tercero 3 ha sido autorizado individualmente (mediante autorización indirecta), y también está autorizado a través de una lista de contactos, entonces la autorización individual tiene prioridad sobre la autorización de lista de contactos, es decir el CHO de la individual invalida el CHO de la lista de contactos.

Para la autorización individual, el cliente propietario 2 puede desear recibir notificación de si el cliente tercero 3 autorizado individual está solicitando otro conjunto de datos aparte de aquél para el que se le autorizó indirectamente. En este caso, debe aplicarse la autorización directa.

El cliente propietario 2 puede especificar una lista de CHO por defecto expuesta. Estos CHO están disponibles 45 para todos los clientes que no pertenezcan a una lista negra.

I.2) Autorización directa

Si el cliente propietario 2 no autoriza indirectamente un cliente tercero 3 en cualquiera de las formas descritas anteriormente (ni la individual, ni la autorización indirecta mediante lista de contactos, y los CHO solicitados no están incluidos en una lista por defecto); la entidad de almacenamiento de datos de la plataforma notifica al cliente propietario 2 acerca de peticiones de conjuntos de datos adicionales y pide autorización explícita. Esta notificación contiene la ID de cliente tercero y la lista de CHO solicitados adicionales que actualmente no están actualizados.

55 En cualquier caso, para autorización directa o indirecta, el cliente propietario 2 define las reglas de acceso a datos para los CHO, al menos para los CHO fundamentales, que ha expuesto en las listas blancas, negras y por defecto.

II) Esquemas de cobro

Un esquema de cobro es el tratamiento de cobro que debe aplicarse a un objeto de cobro. El cliente propietario 2 vincula cada CHO definido a un paquete de cobro específico que garantiza el aprovisionamiento de los servicios requeridos.

65 La funcionalidad de intermediación de datos permite al cliente propietario 2 tener un control total de sus datos recopilados, incluyendo qué datos se mantienen para su uso en aplicaciones propias y cuáles pueden exponerse para comerciar con aplicaciones de clientes terceros, haciendo negocio de la venta de los datos que posee. Esto es realmente una funcionalidad de diferenciación de esta plataforma, que puede vincularse a algunas otras, por ejemplo, la provisión de mecanismos de calidad de servicio para transacciones de datos en la plataforma y para

imagen29

imagen30

5 la entrega de un servicio de extremo a extremo (por ejemplo, priorización de datos; datos en tiempo real; datos urgentes con entrega garantizada; datos tolerantes al retardo; datos sin conexión; datos de mejor esfuerzo, etc.). Plataformas de habilitación de servicio M2M genéricas pueden tratar esas capacidades de diferenciación aplicando diferentes paquetes, o esquemas, de cobro a cada conjunto de datos agregado en un CHO. Por ejemplo, puede suponerse que un conjunto de capacidades de diferenciación se agrupan en un esquema de cobro premium. Para el resto de capacidades de la plataforma comunes (por ejemplo, gestión de dispositivos, conexión de dispositivos Plug & Play, almacenamiento de datos, servicios de procesamiento y encaminamiento, integración en sistemas de IT de cliente backend, procesamiento de eventos en tiempo real, etc.) puede aplicarse un esquema de cobro básico.

15 El esquema de cobro es una de las características de un CHO, así como las reglas de acceso a datos, que pueden heredarse por otros CHO, según las siguientes reglas de herencia:

Las reglas de herencia para las reglas de acceso a datos dependen del tipo de herencia, que puede ser directa o inversa.

La herencia directa de CHO se aplica a reglas de acceso a datos de la siguiente manera:

1. Las reglas de acceso indicadas para un CHO se heredan por todos los CHO derivados de ese CHO. Es decir, las reglas de acceso definidas para un CHO padre se heredan por sus CHO hijos,

25 cualquiera que sea la naturaleza de los CHO (organización, fundamental o derivado). La asignación de esas reglas de acceso de herencia es inmediata tras la definición del CHO.

2.

Cualquier regla de acceso específica indicada para un CHO, invalida las reglas de acceso heredadas de ese CHO y debe realizarse explícitamente por parte del cliente propietario 2.

3.

En el caso de que un CHO se derive de dos o más CHO (CHO padres), se aplican las siguientes reglas de herencia:

o La lista blanca heredada se implementa añadiendo todos los contenidos de las listas blancas de 35 los padres.

o La lista negra heredada se implementa añadiendo todos los contenidos de las listas negras de los padres.

o Después de un proceso de comprobación de listas blancas/negras, los clientes terceros comunes en ambas listas heredadas se retiran de la lista blanca heredada.

Estas reglas sencillas permiten una asignación muy rápida de nuevas reglas de acceso a un CHO recién definido

o una reconfiguración muy rápida del sistema en su totalidad en caso de cambios implementados por el cliente propietario 2.

45 La figura 6 implementa un ejemplo de cómo se aplica la herencia directa a las reglas de acceso a datos de objetos de cobro. El ejemplo supone que el usuario#3 es un cliente tercero particular principalmente interesado en los datos asignados en el acceso a un determinado objeto conectado CO#4. Este cliente tercero particular, usuario#3, puede no conocer de antemano si tiene permisos de acceso indirecto por parte del cliente propietario

2. Existen dos opciones de suscripción basándose en lo que ha expuesto el cliente propietario 2: puede solicitarse una suscripción a CHO#1-2 o a CHO#2. Cada CHO definido, CHO#1, CHO#1-2 y CHO#2, tiene listas de usuarios asociadas, 61, 62, 63 respectivamente, que distinguen listas blancas y negras para usuarios autorizados y no autorizados. Si el usuario#3 solicita una autorización directa para la suscripción a CHO#1-2 (porque sólo está interesado únicamente en un objeto conectado que, en última instancia, puede estar asociado a una suscripción más barata), el usuario#3 recibe un mensaje de permiso denegado, porque el usuario#3 está

55 incluido en la lista negra para este CHO específico, tal como se muestra en la figura 6. Sin embargo, este rechazo se ha heredado del “otro lado” del que está compuesto el CHO#1-2, y en ese caso, puede implementarse un algoritmo en la plataforma de habilitación de servicio M2M genérica para recomendar al usuario#3 que solicite una autorización directa para la otra opción (es decir, para CHO#2). Este algoritmo es una consecuencia de las reglas de herencia explicadas anteriormente y provoca la implementación de un mensaje de “rechazo enriquecido”, mostrado en otro ejemplo ilustrado en la siguiente figura 7.

La figura 7 resume un flujo de trabajo de posibles mensajes en el escenario de aplicabilidad de herencia directa descrito anteriormente en la figura 6. El cliente tercero usuario#3 envía una petición de suscripción 701 a la entidad de función de gestión de suscripción 71, que a su vez pide a la entidad de función de gestión de 65 aprovisionamiento 72 que compruebe 73 los permisos de dicho cliente tercero usuario#3. En este ejemplo, la suscripción se solicita para CHO#1-2, para el que el cliente tercero usuario#3 no tiene permiso, por lo que la

imagen31

imagen32

entidad de función de gestión de aprovisionamiento 72 envía un mensaje de rechazo 703 como una respuesta de comprobar permisos a una petición de comprobación permisos 702 desde la entidad de función de gestión de suscripción 71. Este mensaje de rechazo “enriquecido” 703 del ejemplo dentro de un mensaje de respuesta a la suscripción 704 informa al cliente tercero usuario#3 de que no tiene un acceso concedido a los datos agregados

5 en CHO#1-2, y también informa de que, en este ejemplo, el cliente tercero usuario#3 tiene un acceso concedido a los datos en CHO#2, que se ha descubierto por la entidad de función de gestión de aprovisionamiento 72 después de haber escalado en la estructura jerárquica de la herencia. Por tanto, el cliente tercero usuario#3 informado puede solicitar una suscripción a CHO#2.

Por otro lado, puesto que los CHO fundamentales se han definido como los únicos para los que es obligatorio asignar explícitamente un conjunto de reglas de acceso a datos, se proporcionan algunas reglas adicionales para la herencia para cubrir el caso de definición de CHO de organización, sin aprovisionar explícitamente las reglas de acceso a datos establecidas para esos nuevos CHO en la parte superior del árbol. Este tipo de herencia se denomina en este caso herencia inversa y en ese caso se aplican los siguientes principios:

15

o La lista blanca heredada se implementa añadiendo todos los contenidos de las listas blancas de los hijos.

o La lista negra heredada se completa sólo con nombres comunes en todas las Listas negras de los hijos.

o Los nombres comunes en ambas listas heredadas, si los hubiera, se retiran de la lista blanca heredada.

o Si tras haber aplicado la herencia inversa, se retira alguna regla de acceso de los hijos (por cualquier motivo), entonces puede aprovisionarse un nuevo conjunto de reglas de acceso mediante herencia directa.

25 Un ejemplo de aplicabilidad de los principios de herencia inversa se muestra en la figura 8, en la que el CHO#1 es un CHO organizacional creado como una abstracción a partir de dos CHO fundamentales, que son: CHO#1-1 y CHO#1-2. Entonces, CHO#1 hereda las reglas de acceso a datos de esos F-CHO, CHO#1-1 y CHO#1-2, conforme a los principios indicados anteriormente, y en consecuencia todos los usuarios, usuario#1, usuario#2 y usuario#3, que tienen acceso a los dos F-CHO, CHO#1-1 y CHO#1-2, tienen acceso concedido al O_CHO, CHO#1.

Las listas blancas y negras 81, 82, 83, se envían a la plataforma de habilitación de servicio M2M en el mismo momento de la creación del CHO. Si el CHO es un hijo de uno o más CHO, estas listas pueden quedarse vacías

35 porque se rellenan con los datos del/de los CHO(s) padre(s) aplicando las reglas de herencia descritas.

Con respecto al esquema de cobro, las reglas de herencia (directas o inversas) son las mismas que las indicadas para las reglas de acceso a datos, con las siguientes consideraciones:

1. Si un CHO se deriva de dos o más CHO (padres), se aplican las siguientes reglas para herencia directa:

o El esquema básico es más restrictivo que el premium.

o En este escenario, la funcionalidad de intermediación de datos da valor a que el cliente

propietario 2 proporcione privacidad de sus datos, por tanto el esquema básico está siempre 45 preeminente en la herencia; lo que significa que:

•

Una combinación de esquemas de cobro de los padres de [básico + premium] provoca una herencia directa de esquema básico.

•

Sólo la combinación de [premium + premium] provoca una herencia de premium.

o Si se definen más niveles premium en el futuro, se aplica el mismo enfoque de dar preeminencia al más restrictivo.

2. En el caso de un O_CHO que agrega dos o más otros CHO (hijos), se aplican las siguientes reglas para herencia inversa:

o El esquema básico es más restrictivo que el premium.

o En este escenario, la funcionalidad de intermediación de datos da valor a que el cliente

55 propietario 2 proporcione la capacidad comercial (el enfoque más rentable), por tanto el esquema básico debe asignarse al nivel más bajo que sea posible en la jerarquía, lo que significa que debe ser el cliente propietario 2 quien restrinja explícitamente su propio negocio. Es decir:

•

Una combinación de esquemas de cobro de los hijos de [básico + premium] provoca una herencia inversa de esquema premium.

•

Sólo la combinación de [básico + básico] provoca una herencia de esquema básico.

o Si se definen más niveles premium en el futuro, se aplica el mismo enfoque de dar preeminencia al más rentable.

65 Por tanto, el cliente propietario 2 puede decidir cambiar el perfil de tarifa en cualquier nivel de la estructura de objeto de cobro, confiando en que esta decisión se propaga a lo largo de la estructura de CHO de manera correspondiente usando las reglas de herencia descritas y sin interacción adicional o reconfiguración manual por parte del cliente.

imagen33

imagen34

La estructura de objeto de cobro aceptada por el cliente propietario 2 es la estructura expuesta al mundo exterior,

5 que tiene cada objeto de cobro definido asignado a una ID de objeto de cobro (CHO_ID), independientemente de la naturaleza del CHO (fundamental, derivado o de organización). La CHO_ID asignada mantiene el mismo tipo de requisito impuesto a los objetos conectados u otras identidades aprovisionadas de elementos en la plataforma de habilitación de servicio M2M genérica, lo que puede resumirse mediante las siguientes características:

•

Única.

•

Legible por humanos.

•

En la medida en que sea posible, que indique inequívocamente qué datos está señalando.

El cliente propietario 2 es en principio libre de asignar cualquier CHO_ID. La responsabilidad de la entidad

15 funcional de aprovisionamiento de la plataforma de habilitación de servicio M2M genérica es comprobar la exclusividad de tal ID asignada. Con el fin de minimizar el número de interacciones para esta comprobación, la CHO_ID se deriva de la ID de capa 1, capa 2 o capa “n” ya definido en el árbol de aprovisionamiento 40. Por ejemplo, volviendo al ejemplo de la figura 4, el CHO fundamental denominado CHO_ID#1-1 puede mapearse con el CO_ID#1 indicado, con el siguiente esquema de denominación, como: /vf_m2m/GWBarcelona. Además, un posible CHO derivado puede ser CHO_ID#1-1-1 mapeado con uno de los dispositivos que forman parte de ese CO#1, que por ejemplo puede indicarse como: /vf_m2m/GWBarcelona/Barcelona1.

La estructura de objeto de cobro descrita puede optimizar la capacidad de servicio de intermediación de datos de una forma realmente sencilla usando otro tipo de objeto de cobro: el objeto de cobro temporal (T_CHO). En la

25 estructura de CHO propuesta, la funcionalidad de intermediación de datos siempre da prioridad a la personalización de estructura de CHO decidida por el cliente propietario 2. El cliente tercero 3 es principalmente pasivo y sólo tiene derecho a suscribirse y obtener acceso a los datos expuestos por el cliente propietario 2 en un conjunto de CHO, de la forma y en el formato de agrupación que haya decidido este cliente propietario 2. Eso significa que un cliente tercero 3 puede tener acceso a algunos datos en los que puede no estar interesado o que el cliente tercero 3 necesita solicitar suscripciones a varios CHO porque su interés real está dividido, por ejemplo, en dos CHO diferentes por una decisión del cliente propietario. Esta estructura de CHO la ha aprovisionado el cliente propietario 2 y debe ser la única permanente en el tiempo, pero es posible tener una ventana de flexibilidad provista mediante la creación de un objeto de cobro temporal (T_CHO). El cliente propietario 2 tiene a su disposición las siguientes políticas para procesar una petición para la creación de un T_CHO:

35

1.

No aceptar: el cliente propietario 2 no va a aceptar ninguna petición de creación de T_CHO ni desea que le molesten con esta petición. El cliente tercero 3 recibe un permiso denegado para esta petición.

2.

No aceptar, excepto si el cliente tercero 3 está registrado en su lista de contactos: el cliente propietario 2 acepta la petición y la respuesta a dicho cliente tercero 3 es positiva, sólo si la petición procede de un grupo de contactos seleccionado, aceptado.

3.

La petición puede aceptarse caso por caso: El cliente propietario 2 puede aceptar la petición, tras su revisión, y la respuesta puede ser o bien positiva o bien negativa dependiendo del resultado de dicha revisión:

45 o Si es positiva, se crea un CHO temporal durante un periodo de tiempo establecido por parte del cliente propietario 2, se publica y se expone para las suscripciones. No es exclusivo para el cliente tercero 3 que solicita su creación. Tras un periodo de tiempo dado definido por el cliente propietario 2, el CHO temporal se retira automáticamente.

o Si es negativa, el cliente tercero 3 recibe un permiso denegado para esta petición.

4. Cuando se acepta, el cliente propietario 2 puede decidir qué reglas de acceso a datos y esquema de cobro son aplicables al CHO temporal. En otro caso este T_CHO recibe estas características, reglas de acceso a datos y esquema de cobro, por medio de las reglas de herencia descritas anteriormente, lo que garantiza una mínima interacción con el cliente propietario 2.

55 Volviendo al ejemplo mostrado en la figura 6, es posible explicar el concepto de CHO temporal. En este ejemplo, el usuario#3 sólo estaba interesado en CO#4, pero tuvo que suscribirse a CHO#2, que incluye CO#3, CO#4 y CO#5, con el fin de superar una primera prohibición heredada y obtener, finalmente, sus datos altamente deseados. Si el usuario#3 can pedir al cliente propietario 2 la creación de un CHO temporal y personalizado, el usuario#3 se da cuenta de que una solución óptima es solicitar sólo un T_CHO que incluye CO#4.

La figura 9 describe de forma general el procedimiento mediante el cual un cliente tercero 3 solicita, 901, 903, al cliente propietario 2 a través de los servicios ofrecidos por la entidad de función de gestión de aprovisionamiento 72 que cree un CHO temporal, TCHO, tras haber autenticado al cliente tercero 3 y comprobado el perfil de seguridad y privacidad 902 mediante la entidad funcional de seguridad, autenticación y privacidad 91, 65 implementada en un módulo de seguridad para comprobar las credenciales de cliente requeridas para conceder acceso a la parte principal de una plataforma de habilitación de servicio M2M genérica. En la respuesta 904, 905,

imagen35

imagen36

el cliente propietario 2 incluye la cuota concedida (tiempo, volumen de datos, etc.) para ese CHO temporal. Cuando esta cuota se acaba, el CHO temporal se elimina. La creación de un CHO temporal no implica aceptar implícitamente la suscripción del cliente tercero 3 a cualquiera de los CHO expuestos permanentes por un cliente propietario 2. Por tanto, este cliente tercero 3 debe emitir un procedimiento de aprovisionamiento de CHO 906 y

5 un procedimiento normal de suscripción 907 para un CHO permanente específico (CHO de organización, fundamental o derivado) tal como se describe a continuación respectivamente en las siguientes figuras 10 a 12.

La figura 10 ilustra el procedimiento de aprovisionamiento de un objeto de cobro fundamental FCHO específico y muestra el flujo de mensajes cuando un cliente propietario 2 solicita a una plataforma de habilitación de servicio M2M genérica la creación 101 del objeto de cobro FCHO, especificado por un identificador: FCHO_CHO_ID#1, considerando los dos posibles casos: A) la petición se acepta, B) la petición se rechaza. En primer lugar, la entidad de función de gestión de aprovisionamiento 72 pide a la función de seguridad y autenticación 91 la comprobación de autenticación, seguridad y privacidad 102 del cliente propietario 2. Una vez autenticado el cliente propietario 2, entonces la entidad de función de gestión de aprovisionamiento 72 comprueba la identidad 15 del CHO 103 solicitado. Si la asignación de la CHO_ID es correcta, la entidad de función de gestión de aprovisionamiento 72 configura las reglas de acceso a datos 104 aceptadas en el registro correspondiente a la CHO_ID verificada y también informa a la función de datos de cobro de objeto, OCDF, acerca del esquema de cobro 105 que se ha concedido para ese CHO. Si la función de datos de cobro de objeto, OCDF, puede aceptar la petición, notifica 106 que la petición es finalmente aceptada a la entidad de función de gestión de aprovisionamiento 72, que a su vez envía una respuesta positiva 107 al cliente propietario 2. En caso contrario, en el caso B) de que la petición de CHO_ID provisional del cliente propietario no se acepta, no se recibe acuse de recibo por la entidad de función de gestión de aprovisionamiento 72 desde la función de datos de cobro de objeto OCDF sino que se recibe una respuesta negativa 108 por parte del cliente propietario 2 desde la entidad de función de gestión de aprovisionamiento 72. En ese caso B), el cliente propietario 2 puede emitir otra petición

25 109 para un CHO fundamental usando una nueva identidad de FCHO o la CHO_ID propuesta, FCHO_CHO_ID#2, por la entidad de función de gestión de aprovisionamiento 72.

La figura 11 ilustra el procedimiento de aprovisionamiento de un objeto de cobro derivado DCHO específico y muestra el flujo de mensajes cuando un cliente propietario 2 solicita a una plataforma de habilitación de servicio M2M genérica la creación 111 del objeto de cobro DCHO, especificado por un identificador: DCHO_CHO_ID#1, considerando los dos posibles casos: A) la petición se acepta, B) la petición se rechaza. En primer lugar, la entidad de función de gestión de aprovisionamiento 72 pide a la función de seguridad y autenticación 91 la comprobación de autenticación, seguridad y privacidad 112 del cliente propietario 2. Una vez autenticado el cliente propietario 2, entonces la entidad de función de gestión de aprovisionamiento 72 comprueba la identidad

35 del CHO 113 solicitado. Si la asignación de la CHO_ID es correcta, la entidad de función de gestión de aprovisionamiento 72 configura las reglas de acceso a datos 114 aceptadas en el registro correspondiente a la CHO_ID verificada y también informa a la función de datos de cobro de objeto, OCDF, acerca del esquema de cobro 115 que se ha concedido para ese CHO. El procedimiento es muy similar al descrito para el aprovisionamiento de un CHO fundamental, pero obsérvese que para la creación de un CHO derivado, la adición de parámetros para establecer reglas de acceso a datos 114 y el esquema de cobro 115 es opcional porque se aplican las reglas de herencia para estas características a partir del FCHO del que se deriva el DCHO.

En el primer caso A) mostrado en la figura 11, la función de datos de cobro de objeto, OCDF, acepta la petición y la notifica 116 a la entidad funcional de gestión de aprovisionamiento 72, que a su vez envía una respuesta

45 positiva 117 al cliente propietario 2. En caso contrario, en el caso B) de que la petición de CHO_ID provisional del cliente propietario no se acepta, no se recibe acuse de recibo por la entidad de función de gestión de aprovisionamiento 72 desde la función de datos de cobro de objeto, OCDF, sino que se recibe una respuesta negativa 118 por parte del cliente propietario 2 desde la entidad de función de gestión de aprovisionamiento 72. En ese caso B), el cliente propietario 2 puede emitir otra petición 119 para un CHO derivado usando una nueva identidad de DCHO o la CHO_ID propuesta, DCHO_CHO_ID#2, por la entidad de función de gestión de aprovisionamiento 72.

La figura 12 ilustra el procedimiento de aprovisionamiento de un objeto de cobro de organización, OCHO, específico y muestra el flujo de mensajes cuando un cliente propietario 2 solicita a una plataforma de habilitación 55 de servicio M2M genérica la creación 121 del objeto de cobro, OCHO, especificado mediante un identificador: OCHO_CHO_ID#1, considerando los dos posibles casos: A) la petición se acepta, B) la petición se rechaza. En primer lugar, la entidad de función de gestión de aprovisionamiento 72 pide a la función de seguridad y autenticación 91 la comprobación de autenticación, seguridad y privacidad 122 del cliente propietario 2. Una vez autenticado el cliente propietario 2, entonces la entidad de función de gestión de aprovisionamiento 72 comprueba la identidad del CHO 123 solicitado. Si la asignación de la CHO_ID es correcta, la entidad de función de gestión de aprovisionamiento 72 configura las reglas de acceso a datos 124 aceptadas en el registro correspondiente a la CHO_ID verificada y también informa a la función de datos de cobro de objeto, OCDF, acerca del esquema de cobro 125 que se ha concedido para ese CHO. Obsérvese que, como en el caso de petición de un CHO derivado y a diferencia del caso del CHO fundamental, la adición de parámetros para

65 establecer las reglas de acceso a datos 124 y el esquema de cobro 125 es opcional porque se aplican las reglas de herencia para estas características a partir del FCHO del que se deriva el OCHO.

imagen37

imagen38

En el primer caso A) mostrado en la figura 12, la función de datos de cobro de objeto OCDF acepta la petición y la notifica 126 a la entidad funcional de gestión de aprovisionamiento 72, que a su vez envía una respuesta positiva 127 al cliente propietario 2. En caso contrario, en el caso B) de que la petición de CHO_ID provisional del cliente propietario no se acepta, no se recibe acuse de recibo por la entidad de función de gestión de

5 aprovisionamiento 72 desde la función de datos de cobro de objeto OCDF, sino que se recibe una respuesta negativa 128 por parte del cliente propietario 2 desde la entidad de función de gestión de aprovisionamiento 72. En ese caso B), el cliente propietario 2 puede emitir otra petición 129 para un CHO derivado usando una nueva identidad de DCHO o la CHO_ID propuesta, OCHO_CHO_ID#2, por la entidad de función de gestión de aprovisionamiento 72.

10 La figura 13 muestra el procedimiento de suscripción normal para un CHO específico (CHO de organización, fundamental o derivado). Un cliente tercero 3 envía una petición de suscripción 131 a la entidad de función de gestión de suscripción 71, que a su vez pide en primer lugar a la entidad de función de gestión de aprovisionamiento 72 que compruebe 132 los permisos de este cliente tercero 3, identificado por usuario#3 en el

15 ejemplo, para acceder al CHO solicitado, identificado por CHO_ID#1-2. Si el usuario#3 tiene permisos para acceder a dicho CHO_ID#1-2, caso A), las respuestas 133, 134 respectivas a la entidad de función de gestión de suscripción 71 y al cliente tercero 3 informan de que el acceso se ha concedido. De otro modo, el caso B), se recibe una respuesta 135 de rechazo por la entidad de función de gestión de suscripción 71, que envía una respuesta 136 que informa al cliente tercero 3 de que el acceso se deniega para el CHO solicitado, CHO_ID#1-2,

20 pero que pueden concederse permisos para un CHO alternativo, CHO_ID#2, propuesto por la entidad de función de gestión de aprovisionamiento 72.

La figura 14 ilustra un ejemplo del proceso para implementar la política de cobro basada en objetos conectados por medio de la entidad de función de datos de cobro de objeto, OCDF. En primer lugar, es una condición previa 25 que el cliente propietario 2 (por ejemplo, siguiendo el proceso descrito en la figura 13) haya proporcionado acceso concedido a un cliente tercero 3 dado para la suscripción a una CHO_ID específica, basándose en una política de cobro específica que ya se ha aprovisionado. En segundo lugar, es una condición previa que este cliente tercero 3 conozca esta política de cobro y la acepte antes de remitir cualquier suscripción para esa CHO_ID. En tercer lugar, se supone que este cliente tercero 3 es también un cliente de un proveedor de 30 servicios de telecomunicaciones que posee un sistema de cobro en línea, OCS. En este caso, debe haber una interacción entre las entidades OCDF y OCS del proveedor de servicios para correlacionar intentos de acceso a objeto de cobro con la información usada en el OCS para cobrar a los clientes. Por ejemplo, una petición de control de crédito 144 para la CHO_ID concedida se emite por parte de la entidad de aprovisionamiento 141 contra el OCDF. La entidad de aprovisionamiento 141 monitoriza el uso de una cuota concedida 142 según 35 instrucciones devueltas por el OCS, que controla la reserva de crédito y tarificación 148. Los servicios pueden agruparse en grupos de tarificación. La entidad de OCDF solicita un grupo de tarificación 145 correspondiente (todos los clientes pertenecientes a este grupo tienen la misma política de cobro definida) para esa CHO_ID, por medio de la interacción con la entidad OCS, que responde afirmativamente con la provisión de una cuota de uso concedida 146 previamente reservada para el grupo de tarificación. La entidad de OCDF realiza el control de 40 tarificación 143, es decir, el control de la determinación del coste del evento de servicio, basándose en la cuota reservada. Finalmente, la OCDF contesta afirmativamente 147 a la petición de control de crédito inicial procedente de la entidad de aprovisionamiento 141 informando acerca de la cuota concedida que se ha reservado. Basándose tanto en la política de cobro aprovisionada como en este flujo de trabajo, cada vez que una aplicación de terceros intenta acceder a información en una CHO_ID dada, entonces se le cobra basándose

45 en una cuota reservada que podría depender de, por ejemplo, el volumen de dispositivos conectados por objeto de cobro.

Obsérvese que en este texto, la expresión “comprende” y sus derivaciones (tales como “que comprende/comprendiendo”, etc.) no debe entenderse en un sentido excluyente, es decir, estas expresiones no

50 deben interpretarse como que excluyen la posibilidad de que lo que se describe y define pueda incluir otros elementos, etapas, etc.

Claims (13)

1. 
   
   

   imagen1

   imagen2

   REIVINDICACIONES

   1. Un procedimiento para gestionar datos en sistemas M2M, cuyos clientes son al menos un cliente propietario 2 que posee dispositivos M2M y un cliente tercero 3 que solicita acceso a datos asociados

   5 con los dispositivos M2M del cliente propietario 2, caracterizado porque comprende las etapas de: -registro del cliente propietario 2 y el cliente tercero 3 en una base de datos de aprovisionamiento que pertenece a un sistema M2M; -definición por parte del cliente propietario 2 de al menos un objeto conectado, que se asocia con datos procedentes de o bien un único dispositivo M2M o bien un conjunto de dispositivos M2M del cliente propietario 2, en la base de datos de aprovisionamiento; -suscripción del cliente propietario 2 a cada objeto conectado definido por el cliente propietario 2 al validar una identidad inequívoca única de cada objeto conectado en la base de datos de aprovisionamiento; -publicación al cliente tercero 3 por parte del cliente propietario 2, en la base de datos de

   15 aprovisionamiento, de al menos un objeto de aplicación específica, que consiste en un único objeto conectado, una cierta parte de un único objeto conectado o una agregación de múltiples objetos conectados, comprendiendo la publicación una asociación del objeto de aplicación específica con datos procedentes de los objetos conectados que definen dicho objeto de aplicación específica; -definición por parte del cliente propietario 2, en la base de datos de aprovisionamiento, de reglas de acceso a datos para permitir que el cliente tercero 3 solicite la suscripción a un objeto de aplicación específica publicado a dicho cliente tercero 3.
2. 2. El procedimiento según la reivindicación 1, en el que los objetos de aplicación específica se publican en la base de datos de aprovisionamiento según niveles jerárquicos en los que un objeto de aplicación

   25 específica fundamental inicia un primer nivel en la jerarquía, un objeto de aplicación específica derivado se crea a partir de uno o más objetos de aplicación específica fundamentales en un nivel jerárquico siguiente y se crea un objeto de aplicación específica organizacional mediante agregación de múltiples objetos de aplicación específica fundamentales que añaden niveles jerárquicos.

3. 3.

   El procedimiento según la reivindicación 2, en el que las reglas de acceso a datos se definen por parte del cliente propietario 2 obligatorio para objetos de aplicación específica fundamentales.

4. 4.

   El procedimiento según cualquiera de las reivindicaciones 2-3, en el que el objeto de aplicación

   específica fundamental está vinculado a una identidad inequívoca única de un objeto conectado. 35

5. 5.

   El procedimiento según cualquier reivindicación anterior, que comprende además crear temporalmente en la base de datos de aprovisionamiento un objeto de aplicación específica temporal que se solicita por parte del cliente tercero 3 con un mapeo entre el objeto de aplicación específica temporal y datos asociados con objetos conectados que se define por dicho cliente tercero 3 y acordado con el cliente propietario 2.

6. 6.

   El procedimiento según cualquier reivindicación anterior, que comprende además acceder por parte del cliente propietario 2 a un flujo específico de datos asociados con cualquiera de los objetos conectados definidos por dicho cliente propietario 2.

   45

7. 7.

   El procedimiento según cualquier reivindicación anterior, que comprende además conceder por parte del cliente propietario 2 el acceso a datos asociados con un objeto de aplicación específica sólo si el cliente tercero 3 cumple las reglas de acceso a datos definidas en la base de datos de aprovisionamiento para solicitar la suscripción al objeto de aplicación específica.

8. 8.

   El procedimiento según la reivindicación 7, en el que la concesión de acceso a datos por parte del cliente propietario 2 se realiza antes de que el cliente tercero 3 solicite los datos.

9. 9.

   El procedimiento según la reivindicación 8, en el que la concesión de acceso a datos por parte del

   55 cliente propietario 2 se realiza individualmente con respecto a dicho cliente tercero 3 y comprende especificar una lista de conjuntos de datos que van a asociarse con el cliente tercero 3 en la base de datos de aprovisionamiento.

10. 10.

    El procedimiento según la reivindicación 8, en el que la concesión de acceso a datos por parte del cliente propietario 2 se realiza con respecto a una lista de clientes terceros a la que pertenece dicho cliente tercero 3 y comprende especificar una lista de conjuntos de datos que van a asociarse con la lista de clientes terceros en la base de datos de aprovisionamiento.

11. 11.

    El procedimiento según la reivindicación 7, en el que la concesión de acceso a datos por parte del

    65 cliente propietario 2 se realiza por parte del cliente propietario 2 después de que el cliente tercero 3 solicite los datos sólo si el cliente tercero 3 cumple las reglas de acceso a datos definidas en la base de

    21

    imagen3

    imagen4

    datos de aprovisionamiento para solicitar la suscripción a los objetos de aplicación específica asociados con los datos solicitados.
12. 12. El procedimiento según cualquiera de las reivindicaciones 6-11, en el que asociar datos con objetos

    5 conectados, objetos de aplicación específica y clientes terceros comprende acceder mediante la base de datos de aprovisionamiento a una base de datos de almacenamiento de datos, en la que se almacenan datos y desde la que se entregan datos cuando se concede acceso, usando respectivas identidades inequívocas únicas de los objetos conectados, objetos de aplicación específica y clientes terceros.

    10
13. 13. El procedimiento según cualquier reivindicación anterior, en el que los objetos de aplicación específica son para una aplicación específica que se cobra y la identidad inequívoca única de cada objeto conectado definido se usa para correlacionar diferentes fuentes de datos relacionados con el cobro.

    15 14. El procedimiento según la reivindicación 13, que comprende además correlacionar los datos relacionados con el cobro con objetos de aplicación específica mediante una entidad de función de datos de cobro de objeto, a la que tanto el cliente propietario 2 como el cliente tercero 3 tienen acceso a través de la base de datos de aprovisionamiento.

    20 15. El procedimiento según cualquier reivindicación anterior, en el que asociar datos con dispositivos M2M comprende definir por parte del cliente propietario 2 un flujo de datos que es una única entidad de datos asociada de manera inequívoca con un objeto conectado definido por el cliente propietario 2 en la base de datos de aprovisionamiento.

    25 16. Un programa informático que comprende medios de código de programa informático adaptados para realizar las etapas del procedimiento según cualquiera de las reivindicaciones 1-15, cuando dicho programa se ejecuta en al menos un dispositivo electrónico programable seleccionado de un grupo de: un procesador de propósito general, un procesador de señal digital, una disposición de puertas programables en campo, un circuito integrado de aplicación específica, un microprocesador y un

    30 microcontrolador.

    22