Managing application relationships in machine-to-machine systems

Application relationships may be categorized and managed at a service layer, such as creating application relationship, updating application relationship, retrieving application relationship, deleting application relationship, or discovering application relationship. Services may be based on application relationship awareness.

BACKGROUND

OneM2M Functional Architecture Baseline (oneM2M-TS-0001-V-2014-08 which is incorporated by reference in its entirety) specifies a common service layer (CSL) that can be readily embedded within various hardware and software to support different machine-to-machine (M2M) applications such as connected cars or smart health, among other things. oneM2M as a CSL defines a set of common service functions (CSFs) (e.g., registration CSF). An instantiation of a set of one or more particular types of CSFs is referred to as a common services entity (CSE) which can be hosted on different types of network nodes (e.g., infrastructure node, middle node, or application-specific node).

FIG. 1illustrates the oneM2M functional architecture. Application entity (AE)101or AE103, refers to different M2M applications, which may reside in infrastructure domain107or field domain105, respectively. The field domain107“consists of M2M Devices, M2M Gateways, Sensing and Actuation (S&A) Equipment and M2M Area Networks”, while the infrastructure domain105“consists of Application Infrastructure and M2M Service Infrastructure” according to oneM2M-TS-0011-Definitions and Acronyms-V0.7.0. AE101can access and leverage CSFs in CSE109via Mca interface108. In addition, CSE109provides a suite of CSFs and CSE109can communicate with another CSE111via Mcc interface110. CSE109can also leverage network service entity (NSE)113from underlying networks via Mcn interface112.

According to oneM2M Functional Architecture Baseline, oneM2M reference points include Mca108, Mcc110, Mcc′114, and Mcn112. Mca reference point108(also known as Mca interface) designates communication flows between an AE (e.g., AE101) and a CSE (e.g., CSE109). Mca reference point108allows AE101to use the services provided by CSE109, and for CSE109to communicate with AE101. Mcc reference point110designates communication flows between two CSEs (e.g., CSE109and CSE111). Mcc reference point110allows CSE109to use the services of CSE111in order to provide needed functionality. The services offered via Mcc reference point110are dependent on the functionality supported by CSE109and CSE111.

Mcc′ reference point114designates communication flows between two CSEs in infrastructure nodes that are oneM2M compliant and that resides in different M2M SP domains. Hence, it allows CSE111of infrastructure node105residing in the Network Domain of an M2M Service Provider to communicate with a CSE of another infrastructure node (not shown) residing in the Network Domain of another M2M Service Provider115to use its services, and vice versa. Mcn reference point112designates communication flows between CSE109and underlying NSE113. Mcn reference point112allows CSE109to use the services (other than transport and connectivity services) provided by the underlying NSE113in order to provide the needed functionality.

A few common service functions (CSFs) have been defined within CSE109or CSE111in oneM2M Functional Architecture Baseline that include the Registration (REG) CSF, Application and Service Layer Management (ASM) CSF, Device Management (DM) CSF, Data Management and Repository (DMR) CSF, Communications and Message Delivery Handling (CMDH) CSF, Service Charging and Accounting (SCA) CSF, etc. For example, a CSE (e.g., an M2M service layer entity) provides REG CSF so that an AE can first register itself to the CSE, in order to leverage other CSFs provided by the CSE. This architecture allows multiple AEs to independently register with the same CSE. After the registration is successful, the CSE creates a separate resource (e.g., <application> resource) for each AE. Conventional oneM2M Functional Architecture Baseline lack functions to support the relationship among different applications.

SUMMARY

The conventional oneM2M architecture supports resource access and message exchanges between different M2M applications (e.g., AEs). This architecture allows multiple AEs to register with the same CSE, but each AE performs application registration independently to the CSE. Conventional M2M/IoT service layers (e.g., oneM2M Functional Architecture Baseline, oneM2M-TS-0001-V-2014-08) lack functions to efficiently support and leverage the relationship among different applications. Disclosed herein is how to utilize application relationships (e.g., parent/child) in M2M or IoT service layers.

Discussed herein is application relationship categorization and application relationship management as a common service at a service layer, such as creating application relationship, updating application relationship, retrieving application relationship, deleting application relationship, or discovering application relationship. Services may be based on application relationship awareness.

DETAILED DESCRIPTION

The conventional oneM2M architecture focuses on defining various CSFs including their essential functionalities and how they should be implemented and leveraged by other CSEs or AEs. The conventional oneM2M architecture also supports resource access and message exchanges between different M2M applications (e.g., AEs). This architecture allows multiple AEs to register with the same CSE, but each AE performs application registration independently to the CSE. Conventional M2M/IoT service layers (e.g., oneM2M Functional Architecture Baseline, oneM2M-TS-0001-V-2014-08) lack functions to efficiently support and leverage the relationship among different applications. Disclosed herein is how to utilize application relationships (e.g., parent/child) in M2M or IoT service layers (hereinafter “M2M service layers”).

M2M use cases may include smart transportation, smart home, smart health, smart grid, smart cities, etc. Each use case may generate multiple relevant applications at both an infrastructure domain (e.g., in an M2M application server) and a field domain (e.g., in an M2M Device). Those M2M applications are not completely independent of each other, even for applications from different vertical domains. A gym use case and environment monitoring use case described below demonstrate that relationships may exist among different M2M applications.

FIG. 2illustrates a gym use case where there are three applications on a customer's mobile device, in which there may be parent/child relationships. AE134is a training application between mobile device132and tablet137(e.g., the coach). AE133is a treadmill application between mobile device132and the treadmill136. AE135is a bike application between mobile device132and bike138. AE133, AE134, and AE135register themselves to gym gateway131(e.g., an oneM2M CSE). AE134is used to access a training regimen from tablet137. Then the customer uses AE133or AE135for interactions with the equipment (e.g., treadmill136and bike138) which is designated in the training program as provided by AE134. For example, the customer can send commands to dynamically slow down or speed up treadmill136via AE133. In this example, AE134may be considered a parent application, which provides information (e.g., training program) to AE133and AE135. AE133and AE135may be regarded as child applications and both may provide training results as feedback to AE134. In addition, AE134may have access rights to control and even override the operations of AE133or AE135.

FIG. 3illustrates a use case for environment monitoring that includes an example of a composition/input relationship. InFIG. 3, a few types of sensors (e.g., humidity sensor145, smoke sensor142, temperature sensor144, and wind sensor143) are deployed in a physical area141. The sensors may be placed in different locations with different density. Each sensor registers itself to M2M gateway149as a sensor application. Sensors may be accessed from the Internet through M2M gateway149.

With continued reference toFIG. 3, in one deployment, M2M gateway149may install two gateway applications (e.g., AE147and AE148) for different purposes, but both may be dependent on sensor applications. For example, AE147may utilize a combination of a humidity sensor application of humidity sensor145and a temperature sensor application of temperature sensor144for weather prediction. While AE148may utilize a combination of a temperature sensor application of temperature sensor144, a smoke sensor application of smoke sensor142, and a wind sensor application of wind sensor143for fire prediction. The sensor applications are inputs on which the gateway applications (composite applications) depend on for generating output. Individual sensor applications may be utilized by other network applications from the Internet.

Conventional M2M service layers (e.g., OneM2M Functional Architecture Baseline, oneM2M-TS-0001-V-2014-08) lack functions to efficiently support and utilize the relationship among different applications. In conventional oneM2M, M2M applications (e.g., AEs) simply register to the service platform (e.g., CSE) independently via Mca interface and communicate with other M2M applications via Mca or the combination of Mca/Mcc/Mca interfaces. The dependency or relationship among M2M applications is not supported in application registration or other application-related procedures (e.g., application subscription) in oneM2M architecture.

Application relationship unawareness at a conventional M2M service layer may have multiple shortcomings. First, to support use cases with application relationship inherited or required (e.g., gym use case ofFIG. 2), a conventional M2M service layer provides no corresponding service, but relies on applications themselves to handle it at the application level, which may increase the burden for the application, for example increased application development complexity and decreased software reusability. Second, for a conventional M2M service layer dynamic change in application relationship may not be efficiently supported by applications themselves.

As disclosed herein, common services at the M2M service layer (e.g., registration services at oneM2M) may be enhanced (e.g., a reduction of message overhead) when the relationships of different applications are managed. Application relationship management may entail a common service layer function creating application relationships, updating application relationships, retrieving application relationships, deleting application relationships, or discovering application relationships, among other things.

FIG. 4Aillustrates an exemplary parent/child relationship. AE152and AE153, as child applications, are part of the parent application, AE151. AE151may have substantial access to and control of AE152and AE153. Registration of child applications, AE152and AE153, may rely on the successful registration of the parent application, AE151. AE151may be registered or activated before AE152and AE153. Alternatively, the parent/child relationship may be established after AE151, AE152, and AE153register independently. For example, AE152and AE153may be allowed to register even though the parent application, AE151, is not yet registered, however certain functionality of AE152and AE153(e.g., access rights) may not be applicable or enabled. Once AE151registers, AE152and AE153may discover AE151and establish a relationship with AE152and AE153. Accordingly, the disabled functionality may then be enabled. On the other hand, child applications, AE152and AE153, may be removed automatically when the parent application, AE151, is deleted or de-registered. Both the parent application, AE151, and child applications, AE152and AE153, may register to the same local service layer instance, but may or may not reside on the same physical M2M device, gateway, or server. In summary, parent application, AE151, may substantially control child applications, AE152and AE153, and AE152and AE153may rely on and serve AE151. It is contemplated herein that the parent application may have any number of child applications.

FIG. 4Billustrates an exemplary composition/input relationship. AE156is built up on AE154and AE155, which are referred to as input applications. AE156relies on AE154and AE155for inputs or resources, but it does not have substantial control over them. AE156may be referred to as the composite application. For example, the composite application, AE156, may access resources of input applications, AE154and AE155, but the removal or de-registration of AE156may not lead to the automatic deletion of AE154or AE155. However, the removal or de-registration of AE154or AE155has impact on the composite application, AE156. Generally, a composite application may have multiple input applications and a composite application may be an input application to another composite application.

FIG. 5AandFIG. 5Billustrate approaches for describing and linking application resource and corresponding relationship.FIG. 5Aillustrates an approach with a special application relationship record resource for linking. As shown inFIG. 5A, each application relationship may be created and captured as an application relationship record by an application relationship management (ARM) function. As disclosed in more detail herein, ARM maintains a special database for storing application relationship records. Then new attributes (e.g., linking) is introduced for an application to link to corresponding relationship records, which describe its relationship with other applications. The application relationship record database is maintained at the service layer by the ARM. The database is a generic function, which can be accessed or leveraged by different applications. The ARM may have control of the records that may be accessed or shared with an application. For example, an application, after registering itself with the service layer can search the database for a particular application relationship record about other applications. In another example, the application may update the database by adding a new application relationship record to show its relationship with another application.

FIG. 5Billustrates an approach without a special application relationship record resource. Each application relationship is created as extra information or attributes which are attached to corresponding application resource. For example, application relationship can be described by adding new attributes to <application> resource in the context of oneM2M architecture. In this approach, the ARM does not need to maintain any relationship record as in Approach1ofFIG. 5A.

With continued reference to the approach ofFIG. 5B, optionally, an existing application resource (e.g., an <application> in oneM2M) can be added as a sub-resource of another application resource (e.g., another <application> in oneM2M) to form a hierarchical structure of application resources, which implies application relationship and may not need new attributes to explicitly show application relationship. Note that an application may be restricted from adding its parent application as its sub-resource (e.g., child application). To achieve this restriction the application can check the whole hierarchical structure to guarantee that the new sub-resource (e.g., child application) to be added does not appear on the hierarchical structure. Note that the depth of the hierarchical structure could be limited in order to avoid potential loop relationship.

With regard to the application relationship record, the service layer (e.g., ARM service) may be responsible for maintaining application relationship records. The application relationship record may optionally be added as sub-resource or attributes of an application resource. As shown in Table 1, each application relationship record may include fields, such as the application relationship record identifier (ARRI) field, application relationship type field, list of applications field, primary applications field, relationship lifetime field, or list of allowed entities field, among other things. ARRI is the identifier of each application relationship record. It may be a universal resource identifier (URI) that indicates where the record is stored and can be accessed. An application involved in an application relationship can add one or more ARRIs as its attributes, so that all application relationships about an application can be retrieved based on ARRIs.

Table 1 shows different fields that may be used for application relationship records. An application relationship type field indicates the type of application relationship (e.g., parent/child relationship or composition/input relationship). This parameter may be extended to cover other relationship types. The list of applications field includes the names, labels, or identifiers of all applications directly in a relationship. The identifier may be in the form of a URI. The primary application field indicates the name, label, or identifier of the parent application for parent/child relationship or composite application for composition/input relationship. Relationship lifetime field indicates the lifetime of the application relationship. The list of allowed entities field (not explicitly shown in Table 1) is the list of applications or other M2M entities (e.g., M2M/IoT servers, gateways, devices, etc.) that are allowed to access the application relationship record. The ARM service may use one “list of allowed entities” for the entire application relationship record database.

Table 1 shows two example application relationship records in accordance withFIG. 4AandFIG. 4B. The first record of Table 1, which corresponds withFIG. 4A, may be accessed via <URI1>. In this application relationship, AE151is the parent application while AE152and AE153are child applications. The second record of Table 1, which corresponds toFIG. 4B, may be accessed via <URI2>. In this application relationship, AE156is the composite application, while AE154and AE155are input applications.

Application relationship attributes (ARAs) may be defined to describe relationships that an application may have with other applications. The ARAs may be added as attributes for each application resource (e.g., <application> in oneM2M as shown inFIG. 24andFIG. 25) and in turn each attribute may have an address (e.g., URI) through which it may be accessed. For example, an ARA may include parentApp, childApp, siblingApp, inputApp, compositeApp, or relationshipLifetime. A parentApp may be the list of parent application names or identifiers, a childApp may be a list of child application names or identifiers, siblingApp may be a list of sibling application names or identifiers, inputApp may be a list of input application names or identifiers, compositeApp may be a list of composite application names or identifiers, and relationshipLifetime may be a list of lifetime information, wherein each lifetime is for an individual application relationship.

Since M2M applications register themselves with the service layer (e.g., oneM2M CSE), the service layer may be used to manage application relationship. The application relationship management (ARM) service may be considered a new common service at an M2M service layer to facilitate performing generic operations in order to manage relationships among existing or newly registered applications. The operations may include creating a new application relationship, retrieving an existing application relationship, updating an existing application relationship, deleting an existing application relationship, and discovery of an existing application relationship. Even though the ARM service is related to application relationship, it may provide generic functions that may support and may be used by various applications because 1) the herein disclosed types of application relationships are generic enough (not specific to different applications), and 2) the aforementioned generic ARM operations do not depend on particular applications and are generic as well.

A generic operation my involve creating a new application relationship. For example, an M2M/IoT Server (hereinafter M2M server) may help to create a parent/child or composition/input relationship for two or more applications that were registered to the M2M server. Accordingly, a new application relationship record is added into the application relationship record database maintained by the M2M server according to the approach ofFIG. 5A, or new attributes/links will be created for other involved applications according to the approach ofFIG. 5B. These processes may be used for retrieving, updating, deleting, and discovering existing application relationships.

It is contemplated herein that the entities performing the steps illustrated inFIG. 6-FIG. 21and throughout may be logical entities that may be implemented in the form of software (i.e., computer-executable instructions) stored in a memory of, and executing on a processor of, a device, gateway, server, or computer system such as those illustrated inFIG. 27CorFIG. 27D. In other words, the method(s) illustrated inFIG. 6-FIG. 21and throughout may be implemented in the form of software (i.e., computer-executable instructions) stored in a memory of a computing device, such as the device or computer system illustrated inFIG. 27CorFIG. 27D, which computer executable instructions, when executed by a processor of the computing device, perform any steps illustrated inFIG. 6-FIG. 21and the like.

FIG. 6illustrates an exemplary method for creating application relationships among a set of existing registered applications. At step174, requestor171(e.g., an oneM2M AE or oneM2M CSE) sends a request to create an application relationship (e.g., create an application relationship request) to service layer172(e.g., oneM2M CSE with ARM service). The request of step174may comprise ARAs with regard to application relationship type, list of applications registered with service layer172, primary application, or relationship lifetime. At step175, based on the information received in step174, the service layer172may create a corresponding application relationship resource. The application relationship resource may be an application relationship record as illustrated in Table 1. Alternatively, corresponding ARAs, such as those listed with regard to step174, may be added to each involved application. At step176, service layer172sends response back to requestor171. This message may contain the identifier (e.g., its URI) of the created application resource (e.g., application relationship record or ARA). At step177, service layer172sends notifications to the other applications on the list of applications of step174.

FIG. 7illustrates an exemplary method for creating parent/child application relationship. AE151is the parent application, while AE152and AE153are child applications, as similarly illustrated inFIG. 4A. At step184, AE151registers with service layer172(e.g. oneM2M CSE-ARM service). At step185, service layer172creates a resource for AE151. At step186, AE152registers with service layer172. At step187, service layer172creates a resource for AE152. At step188, AE153registers with service layer172. At step189, service layer172creates a resource for AE153. Conventional application registration procedures for oneM2M may be leveraged for step184through step189.

At step190, requestor171sends a create application relationship request message to service layer172to create or update parent/child relationship of AE151, AE152, and AE153. Requestor171could be AE151, AE152, AE153, another application, or another service layer172entity (e.g., another CSE). The same service layer172may also trigger to establish parent/child relationship among AE151, AE152, and AE153; in this case, step190may be skipped. A create application relationship request message may contain the following information: the relationship between AE151, AE152, and AE153; the link to resources for AE151, AE152, and AE153which are created in Step185, Step187, and Step189respectively; and the names, labels, or identifiers of AE151, AE152, and AE153. At step191, service layer172may update resources for AE151, AE152, and AE153to establish parent/child relationship among AE151, AE152, and AE153applications. AE151's resource may be added with a child pointer or link that connects to the resources for AE152and AE153. AE152's (or AE153's) resource may be added with a parent pointer or link that connects to the resource for AE151. The child pointer or link will be a new attribute or sub-resource of AE151's resource and its value is the URI of the resources for AE152and AE153. Likewise, the added parent pointer or link will be a new attribute or sub-resources of AE152's (or AE153's) resource and its value is the URI of the resource for AE151. AE152's (or AE153's) resource may be added with a sibling pointer or link that connects to the resource for AE153(or AE152). This sibling pointer or link may be used to indicate that AE152and AE153are involved in an application relationship and have the same parent application. The sibling pointer or link added to AE152's resource as a new attribute or sub-resource has the value of URI of AE153's resource. The sibling pointer or link added to AE153's resource as a new attribute or sub-resource has the value of URI of AE152's resource.

At step192, service layer172may send a response back to requester171to notify the successful creation of parent/child relationship among AE151, AE152, and AE153. At step193, service layer172sends an application relationship notification to AE151. The application relationship notification of step193may have the following information: the relationship between AE151, AE152, and AE153; the link to resources for AE152and AE153which are created in step187and step189, respectively; or the names, labels, or identifiers of AE152and AE153. At step194, service layer172may send an application relationship notification to AE152. The application relationship notification of step194may contain the following information: the relationship between AE151, AE152, and AE153; the link to resources for AE151and AE153which are created in step185and step189respectively; or the names, labels, or identifiers of AE151and AE153. At step195, service layer172may send application relationship notification to AE153. This message may contain the following information: the relationship between AE151, AE152, and AE153; the link to resources for AE151and AE152which are created in step185and step187, respectively; or the names, labels, or identifiers of AE151and AE152.

A similar procedure to what is shown inFIG. 7may be applied to create a composition/input application relationship among AE156, AE154, and AE155, where AE156is the composite application and AE154and AE155are input applications.

Another generic operation may involve retrieving an existing application relationship. For example, an M2M application may access the application relationship record database maintained at a M2M server to retrieve a particular application relationship according to the Approach1inFIG. 5A, or access the new attributes/links created for involved applications according to the Approach2inFIG. 5B.FIG. 8illustrates an exemplary method for retrieving application relationships among existing registered applications. At step197, requestor171(e.g., oneM2M AE, oneM2M CSE) may send a request to retrieve on or more relationships of an application (e.g., retrieve application relationship request) to service layer172(e.g., oneM2M CSE with ARM service). The retrieve application relationship request may include the address of application relationship resource, such as ARRI (e.g., the identifier of the application relationship record to be retrieved), or include the address of ARA, as defined herein. At step198, based on the information received in step197, the service layer172locates the corresponding application relationship record, such as the information shown in Table 1. At step199, service layer172may send a response back to requestor171. The response of step199may include the representation of the desired application relationship record or ARA.

Another generic operation may involve updating an existing application relationship. For example, an M2M application may update the application relationship record database maintained at the M2M server to update an existing application relationship (e.g., to change the child application or input application) according to the approach ofFIG. 5A, or update the new attributes/links created for involved applications according to the approach ofFIG. 5B.FIG. 9illustrates an exemplary method for updating application relationships among existing registered applications. At step201, requestor171may send a request to update application relationship (e.g., update application relationship request) to service layer172. The update application relationship request may include the following information: ARRI (e.g., the identifier of the application relationship record to be updated), other attributes to be updated for the desired application relationship record such as the list of applications, or address or values of ARA as discussed herein. At step202, based on the information received in step201, the service layer172may locate and update the corresponding Application Relationship Record or ARA as requested in step201. At step203, service layer172may send a response back to requestor171. The response of step203may include the representation of the updated application relationship record or ARA. At step204, service layer172may send a notification to involved applications205on the updated list of applications about the change of application relationship record or ARA.

A generic operation may involve deleting an existing application relationship. For example, an M2M application can delete its existing application relationship from the application relationship record database as maintained at the M2M server according to the approach ofFIG. 5A, or delete the new attributes/links created for involved applications according to the approach ofFIG. 5B.FIG. 10illustrates an exemplary method for deleting application relationships among existing registered applications. At step206, requestor171sends a request to delete an application relationship (e.g., delete application relationship request) to service layer172. This delete application relationship request may include an ARRI (e.g., the identifier of the application relationship record to be deleted) or the address of application relationship attributes. At step206, requestor171may choose not to explicitly indicate the ARRI, but give certain criteria on application relationship records to be deleted. For example, to delete application relationship records where one or more specific applications (e.g., AE151) are involved. At step207, based on the information received in step206, service layer172locates and deletes the corresponding application relationship record or ARA. At step208, the service layer172sends response back to Requestor171. This response of step208may contain the deletion result (e.g., success or failure). At step209, service layer172may send a notification to all involved applications (e.g., applications173) on the list of applications (e.g., parent/child or composition/input applications).

A generic operation may involve discovering existing application relationships. For example, an M2M application can access the application relationship record database maintained at the M2M server to discover application relationships it has with other applications according to the approach ofFIG. 5A, or access the new attributes/links created for involved applications according to the approach ofFIG. 5Bto discover corresponding application relationships.FIG. 11illustrates an exemplary method for discovering application relationships among existing registered applications. At step211, requestor171sends a request to discover application relationships (e.g., discover application relationship request) to service layer172. This discover application relationship request may include certain search criteria, such as discover application relationships associated with a particular application name/identifier, discover application relationships among a set of particular applications, discover a particular type of application relationships, or discover application relationships, which have a particular number of applications involved. At step212, based on the information received in step211, service layer172locates the corresponding application relationship record or application relationship attribute. At step213, service layer172sends response back to requestor171. The response of step213may contain the list of discovered application relationship records or ARAs (e.g., their identifiers or addresses).

Discussed below are a few new value-added (enhanced) services that may use application relationships (e.g., parent/child relationship and composition/input relationship), such as enhanced application registration service, enhanced application announcement service, enhanced application software management service, relationship-aware application discovery, or subscription and notification of application relationships. Enhanced application registration may include enhanced registration procedures and de-registration procedures, which may apply to parent/child applications, composition/input applications, and other relationships. During the enhanced registration process, application relationship record or ARA may be automatically created. During the enhanced de-registration process, application relationship record or ARA may be automatically updated or removed. In an example, the parent application and child applications may be co-located in the same M2M device, gateway, or server, such as those in the gym use case. Before performing registration, applications may first bootstrap and establish individual secure connections between themselves and a service layer. In this bootstrap process, the parent application may help child applications to establish their secure connections with the service layer during its own security bootstrap process.

FIG. 12illustrates an exemplary method for parent/child application registration process. AE151is the parent application, while AE152and AE153are child applications. At step215, AE151sends a request to register an application (e.g., an application registration request) to service layer172. This application registration request may include information such as: the relationship between AE151, AE152, and AE153; the description of AE151, AE152, or AE153; or the names, labels, or identifiers of AE151, AE152, or AE153. At step216, service layer172creates corresponding resource for AE151, AE152, or AE153. At step217, service layer172may create a corresponding application relationship record or ARA. The created ARA may be used to create attributes for each created application resource. For example, a created resource for AE151may have a child pointer or link that connects to the resources for AE152and AE153. In another example, a created resource for AE151(or AE153) may have a parent pointer or link that connects to the resource for AE152. In another example, a created resource for AE152(or AE153) may have a sibling pointer or link which connects to the resource for AE153(or AE152). At step218, service layer172sends response back to AE151that may include the link of resources created for AE151, AE152, or AE153.

FIG. 13illustrates another exemplary method for parent/child application registration. AE151may be the parent application, while AE152and AE153are child applications. At step220, AE151may send an application registration request to service layer172to register AE151only. At step221, service layer172may create a corresponding resource for AE151. At step222, service layer172sends a response back to AE151. The response at step22may include a result of creating the resource for AE151, e.g. success or fail, as well as the content of the created resource. At step223, AE151, may send another application registration request to service layer172to register AE151. The application registration request of step223may include information such as the link to the resource for AE151created in step221, the relationship between AE151and AE152, the description of AE152, or the names, labels, or identifiers of AE151and AE152. At step224, service layer172creates corresponding resource for AE152. At step225, service layer172creates a corresponding application relationship record or ARA. The created ARA may be used to create new attributes for each created application resources. The created resource for AE152may have a parent pointer or link that connects to the resource for AE151. Service layer172may update the resource of AE151to add a child pointer or link that connects to the resources for AE152.

At step226, service layer172may send a response to AE151. This response of step226may include the link of resources created for AE152. At step227, AE151may send another application registration request to service layer172to register AE153. This application registration request of step227may include information, such as: the link to the resource for AE151created in step221; the relationship between AE151and AE153; the description of AE153; or the names, labels, or identifiers of AE151and AE153. At step228, service layer172creates corresponding resources for AE153. At step229, service layer172updates application relationship record or ARAs as created in step191. The ARA may be used to attributes for each created application resources. The created resource for AE153may have a parent pointer or link which connects to the resource for AE151. Service layer172may update resource for AE151to add a child pointer or link which connects to the resources for AE153. At step230, service layer172may send a response back to AE151. The response of step230may include a link of resources created for AE153.

FIG. 14illustrates an exemplary method for composite application registration. AE156is the composite application, while AE154and AE155are input applications. Also this registration process may not be the first-time registration for AE155and in turn AE156may have knowledge about AE154and AE155. In steps233thru step236, AE154and AE155independently register themselves to service layer172. At step233, service layer172(e.g., ARM) may exchange registration messages for AE154. At step234, service layer172may create a resource for AE154. At step235, service layer172may exchange registration messages for AE155. At step236, service layer172may create a resource for AE155. At step237, AE156may send an application registration request to the service layer172to register itself (AE156) and in the meantime to inform service layer172that AE156is a composite application with AE154and AE155as two input applications. The application registration request of step237may include information, such as the relationship between AE156, AE154, and AE155, the description of AE156, AE154, and AE155, the names, labels, or identifiers of AE156, AE154, and AE155; or the link to resources of AE154or AE155, which are created in step234and step236, respectively. One way for AE156to obtain this information is to use discovery function (e.g., Discovery CSF in oneM2M).

At step238, service layer172may create a resource for AE151and update resources for AE154and AE155. At step239, service layer172may create corresponding application relationship record or ARA. The created ARA may have attributes for each created application resource, such as: a resource for AE156which includes input pointers or links that connect to resources for AE154and AE155; a resource for AE154which includes a composite link that connects to resources for AE156; or a resource for AE155which includes a composite link that connects to resources for AE156. At step240, service layer172may send an application registration response to AE156. At step241, service layer172may send an application relationship notification to AE154. This application relationship notification may include information, such as the relationship between AE156and AE154, the link to resources for AE156, or the names, labels, or identifiers of AE156. At step242, service layer172may send an application relationship notification to AE155. This application relationship notification may include information, such as the relationship between AE156and AE155, the link to resources for AE156, the names, labels, or identifiers of AE156.

FIG. 15shows exemplary procedures for parent/child application de-registration. Here, AE151is the parent application, while AE152and AE153are child applications. Block243involves de-registering a child application, while block251involves de-registering a parent application. At step245, AE151sends a request to de-register an application from the service layer (e.g., an application de-registration request) to service layer172to de-register one of the child applications (e.g., AE152). This application de-registration request of step245may include information, such as: the name, label, or identifier of the child application to be de-registered; or the link to the resource of the child application to be de-registered. At step246, service layer172removes the resource of the child application to be de-registered (e.g., the resource of AE152). Service layer172may also remove from the resource of AE151, the child pointer or link which connects to AE152. Service layer172may also remove from the resource of AE153, the sibling pointer or link which connects to AE152. In addition, service layer172may also update a corresponding application relationship record. At step247, service layer172may send a response back to AE151.

With regard to de-registering a parent application in block251ofFIG. 15, at step252, AE151sends an application de-registration request to service layer172to de-register itself (AE151). At step253, since AE153is the child application of AE151, service layer172may remove the resources for AE151and AE153. Service layer172may also remove the corresponding application relationship record. At step254, service layer172may send a response to AE151. An alternative to the steps shown in block243or block251, a child application may de-register itself and then notify its parent application.

FIG. 16illustrates an exemplary method for composite application de-registration. Here, AE156is the composite application, while AE154and AE155are input applications. Block261involves de-registering an input application, while block266involves de-registering a composite application. At step262, AE155may send an application de-registration request to service layer172to de-register itself. This application de-registration request may include information, such as: the name, label, or identifier of the input application to be de-registered; or the link to the resource of the input application to be de-registered. At step263, service layer172may remove the resource of the input application to be de-registered (e.g., the resource of AE155). Service layer172may also remove from the resource of AE156the input pointer or link which connects to AE155. Service layer172may also update the corresponding application relationship record. At step264, service layer172may send a response back to AE155. At step265, service layer172may send application relationship notification to AE156. This application relationship notification may contain information such as the name, label, or identifier of the de-registered input application (e.g., AE155); or the link to the resource of the de-registered input application (e.g., the resource of AE155).

With regard to block266ofFIG. 16, at step267, AE156may send request for an application to de-register (e.g., an application de-registration request) to service layer172de-register itself (AE156). At step268, service layer172may remove the resource of AE156. Service layer172may also remove from the resource of AE154the composite pointer or link that connects to AE156. In addition, service layer172may remove a corresponding application relationship record. At step269, service layer172sends a response to AE156. At step270, service layer172may send an application relationship notification to AE154. This application relationship notification may contain information such as: the name, label, or identifier of the de-registered composite application (e.g., AE156); the link to the resource of the de-registered composite application (e.g., the resource of AE156). In another example with regard toFIG. 16, service layer172may automatically de-register the composite application AE156after step264(e.g., after an input application is de-registered, or after a certain number of input applications are de-registered.)

An enhanced application announcement may refer to the procedure for announcing parent/child applications or composition/input applications.FIG. 17illustrates an exemplary procedure for parent/child application announcement. It is assumed here that applications block272represents applications with a parent/child relationship (e.g.,FIG. 4A), a composition/input relationship (e.g.,FIG. 4B), or the like. At step274, the applications of applications block272may register themselves to service layer172, which may be completed with the procedures discussed herein. At step275, service layer172may send an application announcement request to service layer273. This application announcement request of step275may include information such as the relationship of the applications of application block272, the names, labels, or identifiers of the applications of application block272, or the link to the resources of the applications of application block272. At step276, service layer273may create an announced resource for the applications of block272. The created announced resource may be one hierarchical resource with the relationship of the applications of block272embedded. In another example, the created announced resource may be separate, but cross-referred resources, respectively, for each application for the applications of block272. At step277, service layer273sends response to the service layer172.

A service layer may manage application software (e.g., upgrade) based on device management (DM) technologies, such as open mobile alliance (OMA) Software Component Management Objects (SCOMO). The following may leverage application relationships to enhance application software management.FIG. 18illustrates an exemplary method for software management that is relationship aware, such as for a parent/child application. At step284, service layer172retrieves software for child application283located on M2M device281. The software may be located on the same apparatus as service layer172or on another apparatus (e.g., server), not shown. Here child application283downloads the software with the assistance of service layer172. At step285, service layer172may analyze the application relationship record or the ARA to discover the corresponding parent application (e.g., parent application282). At step286, after service layer172assists in the retrieval of software for child applications (the software is not installed yet for child application283), service layer172may send a notification to parent application282of M2M device281. The notification may include the following information: 1) the name, label, or identifier of the child application with downloaded new software; or 2) the new software version. At step287, parent application282may trigger child application283to install the new software. This trigger of step287may contain the software version to be installed. In this example, parent application282may decide to give permission to allow installation of the downloaded software to child application283. The decision to give permission may be based on determining whether there may be negative effects or other issues if the downloaded software is installed. The effect of the install may be directly to parent application282, child application283, or to other associated child applications (not shown) of parent application282. At step288, child application283may install the corresponding application. At step289, parent application282may send a confirmation message to service layer172. The message at step289may contain an indication of the latest software version of child application283or indication that the software of step284was installed.

FIG. 19illustrates an exemplary method for relationship-aware composition/input application software management. At step293, service layer172may update software of input application292. At step294, service layer172may analyze application relationship record or ARA to discover the corresponding composite application. At step295, service layer172may send a notification to composite application291to inform with the name, label, or identifier of input application292with updated new software; or the new software version. Composite application291may make changes to how it receives input or adjust other operations based on the notification of the new version and any other details received at step295. Changes may include updating the software of the composite application291. At step296, composite application291may send a confirmation message to service layer172acknowledging notification and may contain other details with regard to composite application291. The details may include a notification to end the relationship with input application292, which may be due to incompatibility of the software.

FIG. 20illustrates an exemplary procedure for application discovery in the context of being relationship-aware. At step301, requestor171may send a request to discover an application (e.g., discover application request) to service layer172. The discover application request of step301may include search criteria such as: discovering parent applications of a particular application; discovering child applications of a particular application; discovering input applications of a particular application; discovering composite applications of a particular application; discovering applications within a particular application relationship; or discover common applications within a set of application relationships. At step302, based on the information received in step301, service layer172locates the corresponding applications. At step303, service layer172sends a response to requestor171. The response of step303may contain the list of discovered applications (e.g., their identifiers or names).

FIG. 21illustrates the procedure for subscription and notification on application relationship, through which an application may receive automatic notification about any new relationship it has with other applications or any changes to its existing relationship with other applications. At step305, requestor171may send a request to subscribe based on application relationship (e.g., subscribe application relationship request) to service layer172. The request of step305may contain a list of target applications (e.g., their identifiers or names). At step306, service layer172may send a subscribe application relationship response message to requestor307to indicate if the subscription request is approved or not. At step307, after a certain amount of time, a relationship about or related to the target applications is changed. For example, a new relationship may be created with one of the target applications in the list of step305. At step308, service layer172may send an application relationship notification to requestor171. The notification of step308may contain the relationship changes that may occur with regard to step307.

Disclosed below are additional details with regard to applying or implementing the methods discussed herein in an oneM2M architecture. The methods may be implemented as an oneM2M CSF (e.g., Application Relationship Management (ARM) CSF inFIG. 22).FIG. 22structure is further detailed below. The “service layer” actor (e.g., service layer172) in procedures mentioned previously may be replaced with ARM CSF. In other words, the ARM CSF performs the functionalities that were described herein with regard to the service layer. The “requestor” (e.g., requester171) in procedures mentioned previously may be an oneM2M AE, ARM CSF, or an oneM2M CSE. The methods disclosed herein may affect existing oneM2M reference points (e.g., Mca and Mcc). In other words, the message exchanges may be implemented as a part of oneM2M reference points. For example messages between an application and a service layer (e.g., CSE) may travel over and otherwise involve the Mca reference point. In another example, messages between service layers (e.g., CSEs) may involve the Mcc reference point.

Enhanced application registration services discussed herein may be implemented in a REG CSF to enhance functionality. Software management methods discussed herein may be implemented in a DM CSF or an ASM CSF, for example.

FIG. 23andFIG. 24illustrate exemplary resource trees of enhanced or new resources. An application relationship record (e.g., <appRelationRecord>321) may enable the proposed application relationship management. The <appRelationRecord>321may be added as a sub-resource of <application>331resource to record application relationships that <application>331is involved with. As shown inFIG. 23, <appRelationRecord>321may have attributes, such as description322, lifetime323, type324, lifeOfApp325, and primaryApp326. A description322is an indication of the text description of <appRelationRecord>321. A lifetime323may be an indication of the lifetime of <appRelationRecord>321. A type324may be an indication of the application relationship type of <appRelationRecord>321(e.g., parent/child application or composition/input application). A listOfApp325may be an indication of the list of applications involved in <appRelationRecord>. The value of this attribute may be the name, label, or identifier of the applications on the list. The primaryApp326is an indication the primary application of <appRelationRecord>321(e.g., parent application or composite application).

FIG. 24illustrates an exemplary structure of new <application>331resource. The <application>331may include a sub-resources or attributes to support the disclosed application management (e.g., application registration, application update, application de-registration, application announcement, and application software management). The <application>331may have the attributes arri333, parentApp334, childApp335, siblingApp336, compositeApp337, and inputApp338. The arri333may be an indication of the ARRIs that <application>331may be involved with. Each arri333points to an <appRelationRecord>321resource. The parentApp334may be an indication of the parent application of this <application>331resource, if any. The childApp335may be an indication of the child applications of <application>331resource, if any. The siblingApp336may be an indication of sibling applications of <application>331resource, if any. The compositeApp337may be an indication of the composite applications of <application>331resource, if any. The inputApp338may be an indication of the input applications of the <application>331resource, if any.

FIG. 25illustrates another exemplary structure of the disclosed hierarchical <application> structure. The <application>342stands for an application. The lifetime343may be an indication the lifetime of the application relationship type between <application>341and <sub-application>345. The type344may be an indication of the application relationship type between <application>341(a first application) and <sub-application>344. A<sub-application>345indicates child applications (if type=“parent/child relationship”) or input applications (if type=“composition/input Relationship”) of <application>341. The <application>341may have multiple <sub-application> as its sub-resource.

With continued reference toFIG. 25, a <sub-application> resource may have another <sub-application> resource (e.g., <sub-application>346) as its sub-resource. In this case, the <sub-application> may have “type” attribute as explained above. The value of a <sub-application> may be a pointer or URI that links to the real <sub-application> resource. The <sub-application> may have the same structure of <application>331as shown inFIG. 24, which includes arri, parentApp, childApp, siblingApp, compositeApp, and inputApp. While the oneM2M architecture with CoAP is described by way of background herein and may be used to illustrate various examples described hereinafter, it is understood that implementations of the examples described hereinafter may vary while remaining within the scope of the present disclosure. One skilled in the art will also recognize that the disclosed examples are not limited to implementations using the oneM2M architecture discussed above, but rather may be implemented in other architectures and systems, such as ETSI M2M, MQTT, and other M2M systems and architectures.

FIG. 26illustrates an exemplary display (e.g., graphical user interface) that may be generated based on the methods and systems discussed herein. Display interface350(e.g., touch screen display) may provide text in block352associated with application relationships, such as the parameters of Table 1, a list of composite or parent applications, or the like. There may be additional information (not shown) with regard to whether a device is a constrained device or simplified interfaces based on whether the device is a constrained device. In another example, progress of any of the steps (e.g., sent messages or success of steps) discussed herein may be displayed in block352. In addition, graphical output354may be displayed on display interface350. Graphical output354may be the topology of devices or applications with regard to the application relationships, a graphical output of the progress of any method or systems discussed herein, or the like.

FIG. 27Ais a diagram of an example machine-to-machine (M2M), Internet of Things (IoT), or Web of Things (WoT) communication system10in which one or more disclosed examples may be implemented. Generally, M2M technologies provide building blocks for the IoT/WoT, and any M2M device, gateway or service platform may be a component of the IoT/WoT as well as an IoT/WoT service layer, etc.

As shown inFIG. 27A, the M2M/IoT/WoT communication system10includes a communication network12. The communication network12may be a fixed network (e.g., Ethernet, Fiber, ISDN, PLC, or the like) or a wireless network (e.g., WLAN, cellular, or the like) or a network of heterogeneous networks. For example, the communication network12may comprise of multiple access networks that provides content such as voice, data, video, messaging, broadcast, or the like to multiple users. For example, the communication network12may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), and the like. Further, the communication network12may comprise other networks such as a core network, the Internet, a sensor network, an industrial control network, a personal area network, a fused personal network, a satellite network, a home network, or an enterprise network for example.

As shown inFIG. 27A, the M2M/IoT/WoT communication system10may include the Infrastructure Domain and the Field Domain. The Infrastructure Domain refers to the network side of the end-to-end M2M deployment, and the Field Domain refers to the area networks, usually behind an M2M gateway. The Field Domain includes M2M gateways14and terminal devices18. It will be appreciated that any number of M2M gateway devices14and M2M terminal devices18may be included in the M2M/IoT/WoT communication system10as desired. Each of the M2M gateway devices14and M2M terminal devices18are configured to transmit and receive signals via the communication network12or direct radio link. The M2M gateway device14allows wireless M2M devices (e.g. cellular and non-cellular) as well as fixed network M2M devices (e.g., PLC) to communicate either through operator networks, such as the communication network12or direct radio link. For example, the M2M devices18may collect data and send the data, via the communication network12or direct radio link, to an M2M application20or M2M devices18. The M2M devices18may also receive data from the M2M application20or an M2M device18. Further, data and signals may be sent to and received from the M2M application20via an M2M service layer22, as described below. M2M devices18and gateways14may communicate via various networks including, cellular, WLAN, WPAN (e.g., Zigbee, 6LoWPAN, Bluetooth), direct radio link, and wireline for example.

Referring toFIG. 27B, the illustrated M2M service layer22(e.g., CSE109ofFIG. 1as described herein) in the field domain provides services for the M2M application20, M2M gateway devices14, and M2M terminal devices18and the communication network12. It will be understood that the M2M service layer22may communicate with any number of M2M applications, M2M gateway devices14, M2M terminal devices18, and communication networks12as desired. The M2M service layer22may be implemented by one or more servers, computers, or the like. The M2M service layer22provides service capabilities that apply to M2M terminal devices18, M2M gateway devices14and M2M applications20. The functions of the M2M service layer22may be implemented in a variety of ways, for example as a web server, in the cellular core network, in the cloud, etc.

Similar to the illustrated M2M service layer22, there is the M2M service layer22′ in the Infrastructure Domain. M2M service layer22′ provides services for the M2M application20′ and the underlying communication network12′ in the infrastructure domain. M2M service layer22′ also provides services for the M2M gateway devices14and M2M terminal devices18in the field domain. It will be understood that the M2M service layer22′ may communicate with any number of M2M applications, M2M gateway devices and M2M terminal devices. The M2M service layer22′ may interact with a service layer by a different service provider. The M2M service layer22′ may be implemented by one or more servers, computers, virtual machines (e.g., cloud/compute/storage farms, etc.) or the like.

Referring also toFIG. 27B, the M2M service layer22and22′ provide a core set of service delivery capabilities that diverse applications and verticals can leverage. These service capabilities enable M2M applications20and20′ to interact with devices and perform functions such as data collection, data analysis, device management, security, billing, service/device discovery etc. Essentially, these service capabilities free the applications of the burden of implementing these functionalities, thus simplifying application development and reducing cost and time to market. The service layer22and22′ also enables M2M applications20and20′ to communicate through various networks12and12′ in connection with the services that the service layer22and22′ provide.

In some examples, M2M applications20and20′ may include parent and child respectively that communicate to a CSE with regard to their application relationship, as discussed herein. The M2M applications20and20′ may include applications in various industries such as, without limitation, transportation, health and wellness, connected home, energy management, asset tracking, and security and surveillance. As mentioned above, the M2M service layer, running across the devices, gateways, and other servers of the system, supports functions such as, for example, data collection, device management, security, billing, location tracking/geofencing, device/service discovery, and legacy systems integration, and provides these functions as services to the M2M applications20and20′.

The managing of application relationships of the present application may be implemented as part of a service layer. The service layer (e.g., service layer172) is a software middleware layer that supports value-added service capabilities through a set of application programming interfaces (APIs) and underlying networking interfaces. An M2M entity (e.g., an M2M functional entity such as a device, gateway, or service/platform that may be implemented by a combination of hardware and software) may provide an application or service. Both ETSI M2M and oneM2M use a service layer that may contain the managing of application relationships of the present application. ETSI M2M's service layer is referred to as the Service Capability Layer (SCL). The SCL may be implemented within an M2M device (where it is referred to as a device SCL (DSCL)), a gateway (where it is referred to as a gateway SCL (GSCL)) or a network node (where it is referred to as a network SCL (NSCL)). The oneM2M service layer supports a set of common Service Functions (CSFs) (i.e., service capabilities). An instantiation of a set of one or more particular types of CSFs is referred to as a Common Services Entity (CSE), which can be hosted on different types of network nodes (e.g., infrastructure node, middle node, application-specific node). Further, the managing of application relationships of the present application can implemented as part of an M2M network that uses a Service Oriented Architecture (SOA) or a resource-oriented architecture (ROA) to access services such as managing of application relationships of the present application.

FIG. 27Cis a system diagram of an example M2M device30, such as an M2M terminal device18or an M2M gateway device14for example. As shown inFIG. 27C, the M2M device30may include a processor32, a transceiver34, a transmit/receive element36, a speaker/microphone38, a keypad40, a display/touchpad42, non-removable memory44, removable memory46, a power source48, a global positioning system (GPS) chipset50, and other peripherals52. It will be appreciated that the M2M device30may include any sub-combination of the foregoing elements while remaining consistent with the disclosed subject matter. M2M device30(e.g., service layer172, AE151, M2M device281, and others) may be an exemplary implementation that performs the disclosed systems and methods for managing application relationships.

The processor32may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, application specific integrated circuits (ASICs), field programmable gate array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor32may perform signal coding, data processing, power control, input/output processing, or any other functionality that enables the M2M device30to operate in a wireless environment. The processor32may be coupled to the transceiver34, which may be coupled to the transmit/receive element36. WhileFIG. 27Cdepicts the processor32and the transceiver34as separate components, it will be appreciated that the processor32and the transceiver34may be integrated together in an electronic package or chip. The processor32may perform application-layer programs (e.g., browsers) or radio access-layer (RAN) programs or communications. The processor32may perform security operations such as authentication, security key agreement, or cryptographic operations, such as at the access-layer or application layer for example.

The transmit/receive element36may be configured to transmit signals to, or receive signals from, an M2M service platform22. For example, the transmit/receive element36may be an antenna configured to transmit or receive RF signals. The transmit/receive element36may support various networks and air interfaces, such as WLAN, WPAN, cellular, and the like. In an example, the transmit/receive element36may be an emitter/detector configured to transmit or receive IR, UV, or visible light signals, for example. In yet another example, the transmit/receive element36may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element36may be configured to transmit or receive any combination of wireless or wired signals.

In addition, although the transmit/receive element36is depicted inFIG. 27Cas a single element, the M2M device30may include any number of transmit/receive elements36. More specifically, the M2M device30may employ MIMO technology. Thus, in an example, the M2M device30may include two or more transmit/receive elements36(e.g., multiple antennas) for transmitting and receiving wireless signals.

The transceiver34may be configured to modulate the signals that are to be transmitted by the transmit/receive element36and to demodulate the signals that are received by the transmit/receive element36. As noted above, the M2M device30may have multi-mode capabilities. Thus, the transceiver34may include multiple transceivers for enabling the M2M device30to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.

The processor32may access information from, and store data in, any type of suitable memory, such as the non-removable memory44or the removable memory46. The non-removable memory44may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory46may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other examples, the processor32may access information from, and store data in, memory that is not physically located on the M2M device30, such as on a server or a home computer. The processor32may be configured to control lighting patterns, images, or colors on the display or indicators42in response to application relationships (e.g., parent/child relationships or composition/input relationships). For example, some of the lighting patterns, images, or colors on the display may be indicators of managing application relationships such as applicability of an application relationship, successful registration of an application relationship, linking to applicable relationship records, as well as other things with regard to retrieving, updating, deleting, and discovering existing application relationships.

The processor32may be configured to control lighting patterns, images, or colors on the display or indicators42in response to whether the LMS in some of the examples described herein are successful or unsuccessful (e.g., subscribing to an application relationship, registering an application based on relationship, discovering relationships, etc.), or otherwise indicate a status of application relationships and associated components. The control lighting patterns, images, or colors on the display or indicators42may be reflective of the status of any of the method flows or components in the FIG.'s illustrated or discussed herein (e.g.,FIG. 6-FIG. 21, etc.). Disclosed herein are messages and procedures of application relationships in M2M. The messages and procedures can be extended to provide interface/API for users to request application relationships and management components via an input source (e.g., speaker/microphone38, keypad40, or display/touchpad42) and request, configure, or query application relationships, among other things that may be displayed on display42.

The processor32may receive power from the power source48, and may be configured to distribute or control the power to the other components in the M2M device30. The power source48may be any suitable device for powering the M2M device30. For example, the power source48may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

The processor32may also be coupled to the GPS chipset50, which is configured to provide location information (e.g., longitude and latitude) regarding the current location of the M2M device30. It will be appreciated that the M2M device30may acquire location information by way of any suitable location-determination method while remaining consistent with an example.

The processor32may further be coupled to other peripherals52, which may include one or more software or hardware modules that provide additional features, functionality or wired or wireless connectivity. For example, the peripherals52may include an accelerometer, an e-compass, a satellite transceiver, a sensor, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

FIG. 27Dis a block diagram of an exemplary computing system90on which, for example, the M2M service platform22ofFIG. 27AandFIG. 27Bmay be implemented. Computing system90may comprise a computer or server and may be controlled primarily by computer readable instructions, which may be in the form of software, wherever, or by whatever means such software is stored or accessed. Such computer readable instructions may be executed within central processing unit (CPU)91to cause computing system90to do work. In many known workstations, servers, and personal computers, central processing unit91is implemented by a single-chip CPU called a microprocessor. In other machines, the central processing unit91may comprise multiple processors. Coprocessor81is an optional processor, distinct from main CPU91, that performs additional functions or assists CPU91. CPU91or coprocessor81may receive, generate, and process data related to the disclosed systems and methods for management of application relationships, such as receiving enhanced application registration (e.g., registration of multiple applications at once).

In addition, computing system90may contain peripherals controller83responsible for communicating instructions from CPU91to peripherals, such as printer94, keyboard84, mouse95, and disk drive85.

Display86, which is controlled by display controller96, is used to display visual output generated by computing system90. Such visual output may include text, graphics, animated graphics, and video. Display86may be implemented with a CRT-based video display, an LCD-based flat-panel display, gas plasma-based flat-panel display, or a touch-panel. Display controller96includes electronic components required to generate a video signal that is sent to display86.

Further, computing system90may contain network adaptor97that may be used to connect computing system90to an external communications network, such as network12ofFIG. 27AandFIG. 27B.

It is understood that any or all of the systems, methods and processes described herein may be embodied in the form of computer executable instructions (i.e., program code) stored on a computer-readable storage medium which instructions, when executed by a machine, such as a computer, server, M2M terminal device, M2M gateway device, or the like, perform or implement the systems, methods and processes described herein. Specifically, any of the steps, operations or functions described above may be implemented in the form of such computer executable instructions. Computer readable storage media include both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, but such computer readable storage media do not includes signals. Computer readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other physical medium which can be used to store the desired information and which can be accessed by a computer.

Methods, systems, and apparatuses, among other things, as described herein may provide for means for requesting, configuring, or determining, among other things, application relationships. A method, system, computer readable storage medium, or apparatus has means for assisting in the retrieval of software for a first application; means for determining the relationship of the first application to a second application, the second application is a parent application; and means for sending a first message to the second application based on the relationship of the first application to the second application, the message comprising an alert of the retrieval of software for the first application. The second application may be a parent application to the first application. The message may include the relationship of the first application to the second application. The message may include an identifier of the first application or a version of the software. The method, system, computer readable storage medium, or apparatus has means for further operations that may include receiving a notification of most recently installed version of software of the first application. The first application may be an input application to the second application. The message may notify the second application that the first application has installed the retrieved software. The second application may alter a process for handling data from the first application based on a notification that the first application has installed the retrieved software.

A method, system, computer readable storage medium, or apparatus has means for sending a request to create a resource for an application relationship, the request comprising a type of application relationship; and means for receiving a response that confirms creation of the resource for the application relationship, wherein the response comprises an identifier for the resource for the application relationship. The request may further include a list of applications registered with a service layer or a period for the application relationship existed.

A method, system, computer readable storage medium, or apparatus has means for creating a first resource for a first application based on a first registration request; means for creating a second resource for a second application based on a second registration request; means for receiving a first request, the first request comprising a request to create a relationship between the first application and the second application; and means for creating, based on the first request, a relationship between the first application and the second application. The creation of the relationship may include updating the first resource and the second resource. The method, system, computer readable storage medium, or apparatus has means for updating the first resource with a pointer that connects with the second resource, the pointer indicative that the first application is a parent of the second application. The method, system, computer readable storage medium, or apparatus has means for notifying the first application of creation of the relationship between the first application and the second application. The relationship may include a parent/child relationship between the first application and the second application. The relationship may include a composition/input relationship between the first application and the second application. The relationship may include updating a first application relationship attribute within the first resource. The first request may be received on an application relationship management service of a common services entity.

In describing preferred methods, systems, or apparatuses of the subject matter of the present disclosure, as illustrated in the Figures, specific terminology is employed for the sake of clarity. The claimed subject matter, however, is not intended to be limited to the specific terminology so selected, and it is to be understood that each specific element includes all technical equivalents that operate in a similar manner to accomplish a similar purpose.