WO2018209195A1

WO2018209195A1 - Methods for information object lifecycle management to support interworking between systems

Info

Publication number: WO2018209195A1
Application number: PCT/US2018/032258
Authority: WO
Inventors: Xu Li; Chonggang Wang; Quang Ly
Original assignee: Convida Wireless, Llc
Priority date: 2017-05-11
Filing date: 2018-05-11
Publication date: 2018-11-15

Abstract

The present application is at least directed to an apparatus including a non-transitory memory having instructions stored thereon for supporting interworking between systems and including rules to perform information model alignment between the systems. The apparatus also includes a processor operably coupled to the non-transitory memory configured to execute the instructions of receiving a request from a physical entity in a first system to create an interworking-oriented information object in a second system. The processor is also configured to execute the instructions of determining a type of the interworking-oriented information object to create in the second system for the physical entity. The processor is also configured to execute the instructions of creating the interworking-oriented information object for the physical entity based upon the determining instruction. The processor is further configured to execute the instructions of sending a reply to the physical entity that the interworking-oriented information object is available in the second system.

Description

METHODS FOR INFORMATION OBJECT LIFECYCLE MANAGEMENT TO

SUPPORT INTERWORKING BETWEEN SYSTEMS

RELATED APPLICATION

[0001] This application claims the benefit of priority of U.S. Provisional application no.

62/504,741 filed May 11, 2017, entitled "Methods for Information Object Lifecycle Management to Support Interworking Between Systems" the contents of which is incorporated by reference in its entirety herein.

FIELD

[0002] The present application is directed to methods and apparatuses to support interworking between different systems. In particular, the application is directed to methods and apparatuses to support interworking between web of things systems and server layer systems.

BACKGROUND

[0003] Different parties or organizations may employ different Internet of Things (IoT) devices architecture, such as for example outdoor cameras, for various purposes in the same area. As shown in Figure 1, two cameras - Cameras 1 and 2 - are deployed on two adjacent roads - Road 1 and 2 - by different parties. The cameras are deployed at relative heights to give a real-time overview of the road's surface. As a result, the cameras can be used to identity unoccupied street parking spots along the road. Real-time images allow users to determine the best likelihood of obtaining an available parking spot. However, due to lack of coordination between the parties/organization, the cameras may be compliant to different industry standards, i.e., Web of things (WoT) compliant vs. Service Layer (SL) compliant.

[0004] Users in the locations may also only have limited capability to interact with IoT devices that are compliant to a specific standard. For example, User-2 in Figure 1 which may be SL- compliant may not be able to directly access Camera- 1 which is WoT-compliant. Conversely, User-1 which is WOT-compliant may not be able to directly access Camera-2 which is SL- compliant. As a result, no user can directly interact with both Camera- 1 and Camera-2 to gain an accurate assessment of the parking situation on the road.

[0005] Supporting interworking between a SL-compliant system and a WoT-compliant system is deficient. During their lifecycles, WoT-compliant and SL-compliant devices may become available, updated, or deleted. What is needed is a technique to manage the WOT-compliant' s interworking-oriented Information Objects (IO) created in a SL-compliant system to correctly reflect the status of the WoT-compliant device in a timely manner. What is also needed is a technique to manage the SL-compliant's interworking-oriented IO(s) created in a WoT- compliant system to correctly reflect the status of the SL-compliant device in a timely manner. SUMMARY

[0006] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to limit the scope of the claimed subject matter. The foregoing needs are met, to a great extent, by the present application directed an apparatus and method for supporting interworking between systems.

[0007] In one aspect of the application, a computer-implemented apparatus is disclosed including a non-transitory memory having instructions stored thereon for supporting

interworking between systems and including rules to perform information model alignment between the systems. The apparatus also includes a processor operably coupled to the non- transitory memory configured to execute the instructions of receiving a request from a physical entity in a first system to create an interworking-oriented information object in a second system. The processor is also configured to execute the instructions of determining a type of the interworking-oriented information object to create in the second system for the physical entity. The processor is also configured to execute the instructions of creating the interworking-oriented information object for the physical entity based upon the determining instruction. The processor is further configured to execute the instructions of sending a reply to the physical entity that the interworking-oriented information object is available in the second system.

[0008] In a further aspect of the application, a computer-implemented apparatus is disclosed including a non-transitory memory having instructions stored thereon for supporting

interworking between systems and including rules to perform information model alignment between the systems. The apparatus also includes a processor operably coupled to the non- transitory memory configured to execute the instructions of receiving a request from a service layer resource host in a first system to make a resource representation of a service layer compliant device in the first system available on a second system. The processor is also configured to execute the instructions of determining whether to allow the service layer compliant device to be available in the second system. The processor is also configured to execute the instructions of determining information to collect to create a things description for representing the service layer compliant device. The processor is further configured to execute the instructions of accessing the resource representation in the first system to create a things description for the service layer compliant device. The processor is even further configured to execute the instructions of creating the things description. The processor is yet even further configured to execute the instructions of publishing the created things description in a repository located in the second system.

[0009] In yet a further aspect of the application, a computer-implemented apparatus is disclosed including a non-transitory memory having instructions stored thereon for supporting

interworking between systems and including rules to perform information model alignment between the systems. The apparatus also includes a processor operably coupled to the non- transitory memory configured to execute the instructions of sending a resource discovery request to a service layer resource host in a first system for an available resource representation associated with a service layer compliant device. The processor is also configured to execute the instructions of receiving a URI of the service layer compliant device from the service layer resource host. The processor is also configured to execute the instructions of accessing the resource representation in the first system to create a things description for the service layer compliant device. The processor is further configured to execute the instructions of creating the things description. The processor is even further configured to execute the instructions publishing the created things description in a repository located in the second system.

[0010] There has thus been outlined, rather broadly, certain embodiments of the invention in order that the detailed description thereof may be better understood, and in order that the present contribution to the art may be better appreciated.

BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order to facilitate a more robust understanding of the application, reference is now made to the accompanying drawings, in which like elements are referenced with like numerals. These drawings should not be construed to limit the application and are intended only to be illustrative.

[0012] Figure 1 illustrates a use case according relating to road-side camera access for finding street parking spots. [0013] Figure 2A is a system diagram of an example machine-to-machine (M2M), Internet of Things (IoT), or Web of Things (WoT) communication system in which one or more disclosed embodiments may be implemented.

[0014] Figure 2B is a system diagram of an example architecture that may be used within the M2M/IoT/WoT communications system illustrated in Figure 2a.

[0015] Figure 2C is a system diagram of an example communication network node, such as an M2M/IoT/WoT device, gateway, or server that may be used within the communications system illustrated in Figures 2 A and 2B.

[0016] Figure 2D is a block diagram of an example computing system in which a node of the communication system of Figures 2a and 2b may be embodied.

[0017] Figure 3 illustrates a functional architecture of a web of things (WOT) servient.

[0018] Figure 4 illustrates concepts of the thing description (TD).

[0019] Figure 5 illustrates a oneM2M architecture.

[0020] Figure 6 illustrates oneM2M common service functions (CSF).

[0021] Figure 7 illustrates an interworking proxy entity.

[0022] Figure 8 illustrates a structure of a <semanticDescriptor> Resource in a Resource Tree.

[0023] Figure 9 illustrates a design structure of the home appliance information model using SDT 3.0.

[0024] Figure 10 illustrates a structure of a <flexContainer> resource.

[0025] Figure 11 illustrates a resource structure of [deviceAirConditioner] Resource

Representing a device Air Conditioner device model in HAEVI.

[0026] Figure 12 illustrates a first WOT/Service Layer (SL) interworking architecture according to an aspect of the application.

[0027] Figure 13 illustrates a second WOT/Service Layer (SL) interworking architecture according to an aspect of the application.

[0028] Figure 14 illustrates a third WOT/Service Layer (SL) interworking architecture according to an aspect of the application.

[0029] Figure 15 illustrates a procedure for creating interworking-oriented information objects (IOs) in the SL-compliant system for a WOT-compliant thing and its TD according to an aspect of the application [0030] Figure 16 illustrates an example of interworking-oriented IOs created in the SL- compliant system for separately representing an LED-Light-123 and its TD through transparent interworking according to an aspect of the application.

[0031] Figure 17 illustrates an example of interworking-oriented IOs created in the SL- compliant system for separately representing the LED-Light-123 and its TD through resource mapping according to an aspect of the application.

[0032] Figure 18 illustrates an example of an integrated interworking-oriented IO created in the SL-compliant system for representing both the LED-Light-123 and its TD jointly through IM alignment between TD and HAEVI according to an aspect of the application.

[0033] Figure 19 illustrates an example of an integrated interworking-oriented IO created in the SL-compliant system for representing both the LED-Light-123 and its TD jointly through IM alignment between TD and <SemanticDescriptor> according to an aspect of the application.

[0034] Figure 20 illustrates a procedure for creating interworking-oriented IOs in the SL- compliant system for a WOT-compliant thing and it's TD according to an aspect of the application.

[0035] Figure 21 illustrates a procedure for creating interworking-oriented IOs in the SL- compliant system for a WOT-compliant thing and it's TD according to another aspect of the application.

[0036] Figure 22 illustrates a procedure for creating an interworking-oriented IO in the WOT- compliant system for a SL-compliant thing according to another aspect of the application.

[0037] Figure 23 illustrates a procedure for creating an interworking-oriented IO in the WOT- compliant system for a SL-compliant thing according to even an aspect of the application.

[0038] Figure 24 illustrates a procedure for updating interworking-oriented IOs in the SL- compliant system for a WOT-compliant thing according to an aspect of the application.

[0039] Figure 25 illustrates a procedure for updating interworking-oriented IOs in the SL- compliant system for a WOT-compliant thing according to an aspect of the application.

[0040] Figure 26 illustrates a procedure for updating an interworking-oriented IO in the WOT- compliant system for a SL-compliant native resource provider ( RP) according to an aspect of the application. [0041] Figure 27 illustrates a procedure for deleting interworking-oriented IOs in the SL- compliant system for a WOT-compliant thing and it's TD according to an aspect of the application.

[0042] Figure 28 illustrates an embedded procedure for creating interworking-oriented IOs in the SL-compliant system for a WOT-compliant thing and it's TD according to an aspect of the application.

[0043] Figure 29 illustrates and embedded procedure for updating interworking-oriented IOs in the SL-compliant system for A WoT-compliant thing and it's TD according to an aspect of the application.

[0044] Figure 30 illustrates an embedded procedure for creating interworking-oriented IOs according to an aspect of the application.

[0045] Figure 31 illustrates an embedded procedure for updating/deleting an interworking- oriented IO according to an aspect of the application.

[0046] Figure 32 illustrates an embedded procedure for creating an interworking-oriented IO according to an aspect of the application.

[0047] Figure 33 illustrates an embedded procedure for updating/deleting an interworking- oriented IO according to another aspect of the application.

[0048] Figure 34 illustrates an interworking CSF for oneM2M service layer according to an aspect of the application.

[0049] Figure 35 illustrates a oneM2M embodiment for the proposed interworking architecture according to an aspect of the application.

[0050] Figure 36 illustrates a oneM2M resource <WSIE> according to an aspect of the application.

[0051] Figure 37 illustrates a oneM2M resource <WSIM> according to an aspect of the application.

[0052] Figure 38 illustrates a oneM2M embodiment of the procedure for IO creation under the third WOT/Service Layer (SL) interworking architecture.

[0053] Figure 39 illustrates a oneM2M embodiment of a procedure for IO creation under the third WOT/Service Layer (SL) interworking architecture.

[0054] Figure 40 illustrates a graphical user interface for monitoring physical nodes. DETAILED DESCRIPTION OF THE ILLUSTRATIVE EMBODIMENTS

[0055] A detailed description of the illustrative embodiment will be discussed in reference to various figures, embodiments and aspects herein. Although this description provides detailed examples of possible implementations, it should be understood that the details are intended to be examples and thus do not limit the scope of the application.

[0056] Reference in this specification to "one embodiment," "an embodiment," "one or more embodiments," "an aspect" or the like means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the application. Moreover, the term "embodiment" in various places in the specification is not necessarily referring to the same embodiment. That is, various features are described which may be exhibited by some embodiments and not by the other.

[0057] Generally, this application pursues the solutions to IO lifecycle management for supporting interworking. Interworking requires new logic functionality which translates the content into different information models and can access the interfaces that are compliant to different standards. Taking oneM2M as an example, Interworking Proxy Entity (IPE) is the major entity that handles interworking between an oneM2M system and an external system. The major working methodology of IPE is that for a given external device that is X-compliant, IPE will create a corresponding oneM2M resource representation (since oneM2M is resource oriented) in the oneM2M system and those resources will then have oneM2M-compliant access interfaces. Accordingly, all the CRUD operations on those resources conducted by oneM2M users will be captured by the IPE, which will further interact with corresponding X-compliant devices by translating those CRUD operations into the native operations over the X-compliant interfaces.

[0058] Some of the issues resolved in this application are when given a SL-compliant device, how to make it also available/accessible in a WoT-compliant System, and vice versa. For example, it is necessary to enable a WoT-compliant device to also have SL resource

representation(s) exposing SL-compliant interface in the SL-compliant system such that SL- compliant users can also discover and interact with this WoT-compliant device through its corresponding SL resource representation (which is called "an Information Object for supporting interworking" in the sense that it makes a WoT-compliant device also available in the SL- compliant System). Similarly, a SL-compliant device also needs to have a TD in the WoT- compliant system such that WoT-compliant users can discover this TD and then interact with this SL-compliant device through a WoT-compliant interface as specified in this TD (this TD is also an Information Object for supporting interworking since it makes a SL-compliant device also available in the WoT-compliant System). In order to support interworking, a thing/device compliant to a specific standard (either WoT or SL) may have a corresponding representation in another system that is compliant to a different standard, and such representations are referred as "Interworking-oriented Information Objects" (10) in this application

[0059] Three WoT/SL interworking architectures (Architecture- 1 to Architecture-3) are envisaged as separate embodiments. The WoT/SL Interworking Entity (WSIE) is a proposed entity that handles/realizes the interworking between a WoT-compliant system and a SL- compliant System. WSIE has the capabilities to work with both WoT-compliant and SL- compliant access interfaces. For all the interworking-oriented IOs created for supporting interworking (bidirectional), WSIE will monitor all the interaction operations on those IOs by the users in different systems and it is the WSIE that conducts related processing (which is transparent to those users) to finally translate those operations into specific access interfaces and realize the real interworking process. In another embodiment, it is envisaged that there may be multiple WSIEs that can support interworking. Accordingly, a WoT/SL Interworking Manager (WSIM) may be introduced, which is a manager for coordinating and scheduling all the interworking-related tasks among different WSIEs. Interworking in two directions and a suite of procedures are proposed to support the following scenarios:

[0060] Direction: WoT-compliant system -> SL-compliant System. When a new WoT-compliant device publishes it's TD and makes itself available in the WoT-compliant system, and if it also wants to make itself available in the SL-compliant system to support interworking, a mechanism is envisaged for creating corresponding interworking-oriented IO(s) in the SL-compliant System realized through a "IO Creation process". At some point in the future, the WoT-compliant device may make changes on its TD due to e.g., device re-configurations. A mechanism is envisaged such that those updates can also be reflected in its corresponding interworking- oriented IO(s) created in the SL-compliant System realized through a "IO Update process". Last, if the WoT-compliant device is going to be offline and wants to delete its TD in the WoT- compliant system, a mechanism is needed such that its corresponding interworking-oriented IO created in the SL-compliant system also needs to be deleted, is envisaged through a "10 Deletion process".

[0061] Direction: SL-compliant system -> WoT-compliant System. In this case, a new SL- compliant device/thing registers itself to a SL node and has a SL resource representation. In order to support interworking, a mechanism is needed for creating a TD for this SL-compliant device or its SL representation, and publishing this interworking-oriented IO (i.e., the created TD) to the WoT-compliant system such that this SL-compliant device can also become available in the WoT-compliant system (This is realized through the "10 Creation process").

[0062] Sometime later, the SL resource representation of this SL-compliant device may have undergone some changes due to CRUD operations on this representation. Therefore, a mechanism is envisaged such that these updates can also be reflected in its corresponding TD published to the WoT-compliant system (and also realized through the "10 Update process"). Lastly, if the SL-compliant device is going to be offline and wants to delete its SL resource representation in the SL-compliant system, a mechanism is envisaged such that it's

corresponding TD published to the WoT-compliant system will also be deleted (also realized through the "10 Deletion process").

Definitions and Acronyms

[0063] Provided below are acronyms for commonly used terms and phrases in this application in Table 1 followed by definitions in Table 2.

HGI Home Gateway Initiative

HTTP Hypertext Transfer Protocol

IG Information Group

IN Infrastructure Node

IN-CSE CSE which resides in the Infrastructure Node

IM Information Model

10 Information Objects

IoT Internet of Things

IPE Interworking Proxy Entity

M2M Machine to Machine

MN Middle Node

MN-CSE CSE which resides in the Middle Node

NSE Network Service Entity

OWL Web Ontology Language

RDF Resource Description Framework

RDFS Resource Description Framework Schema

RESTful Representational State Transfer

SDT Smart Device Template

SL Service Layer

SNU System Native User

SPARQL SPARQL Protocol and RDF Query Language

TD Thing Description

TDR TD Repository

URI Uniform Resource Identifier

W3C World Wide Web Consortium

WoT Web of Things

WoT-T WoT-Thing

WoT-S WoT- Servient

WSIE WoT/SL Interworking Entity

WSIM WoT/SL Interworking Manager XML extensible Markup Language

Table 1

External IM-aware For a given user in the X-compliant system, it not User (EIMU) only understands the native FMs adopted/defined by X-compliant system but also understands IMs defined by other systems.

Information Model "Information Model" is the model used to (FM) describe/represent physical devices/entities/things and their functions/operations/properties/events. The FM is an abstract model. Each system may have its own IMs, however, an FM defined by System A may also have a representation in another System B in order to support

interworking. However, the representations of the same IMs in different systems may provide different access interfaces that are compliant to different standards.

Interworking-oriented In order to support interworking, a thing in Information Object System A that is compliant to a specific standard (10) (either WoT or SL) may have a corresponding representation in another System B, in which the access interface is compliant to a different standard. Such corresponding representations for supporting interworking are referred as

"Interworking-oriented Information Objects" (10).

For a given thing in System A, its interworking- oriented 10 in another System B may be still based on the native FM defined by System A (but provides access interfaces supported in System B). Alternatively, its interworking-oriented 10 in another System B may be directly based on the IM defined by System B (if IM alignment can be done between those two systems).

Interworking can refer to bi-directional interworking, and therefore a Thing- 1 in System A can have corresponding Interworking-oriented IO(s) in another System B (so that native users in System B can also discover and interact with Thing- 1) while in turn a Thing-2 in System B can have corresponding Interworking-oriented IO(s) in System A (so that native users in System A can also discover and interact with Thing-2).

Interworking-oriented In order to support interworking, a

10 Lifecycle thing/device/entity in System A may have a Management corresponding representation (i.e., an

interworking-oriented 10) in another System B. Interworking-oriented 10 Lifecycle Management refers to necessary

processes/procedures/operations to manage interworking-oriented 10 for a thing/device/entity such as creating/updating/deleting an

Interworking-oriented 10.

For example, when the thing/device/entity becomes available in System A, its corresponding interworking-oriented IO(s) in another System B also need to be created (which is realized through a "10 Creation" process). After sometime, if the thing/device/entity undergoes some

reconfigurations, its corresponding interworking- oriented IO(s) in another System B may also need to be updated to reflect the latest status of the thing/device/entity (which is realized through a "10 Update" process). When the

thing/device/entity is going to be unavailable anymore, its corresponding interworking-oriented IO(s) in another System B may also need to be deleted (which is realized through a "10 Deletion" process).

SL Native Resource This is a "logical" role. If a SL node hosts Host (SL-NRH) resources that are created by SL-NRPs, then this

SL node has a role of SL-NRH. For example, if a SL-compliant thing/device (acting as a SL-NRP) creates its own SL resource representation on a SL node, this SL node will be a SL-NRH.

SL Native Resource Typically, if an entity is a SL-compliant

Provider (SL-NRP) thing/device, it will create its own SL resource representation when registering itself to a SL node (which is a SL resource host) and such an entity is called a SL-NRP.

SL Resource Host for A SL resource host that can host interworking- A WoT Thing (SL-RH- oriented IO(s) representing WoT Things is called T) a SL-RH-T.

SL Resource Host for The SL resource host that can host interworking- A TD (SL-RH-TD) oriented IO(s) representing TDs is called a SL- RH-TD.

System Native User For a given user in the X-compliant system, it (SNU) only understands the native IMs defined by X- compliant system, and does not know any other IMs defined by other systems. Such a user is a "SNU" for the X-compliant system.

Thing Description The WoT TD provides the semantic metadata of a (TD) Thing as well as a functional description of its WoT access interface.

TD Host A TD not only can be published into a TD

Repository, it can also be hosted by a WoT Servient in order to support local/near-by discovery. Such a node that can host TD(s) is called a TD Host.

TD Repository (TDR) A register for storing TDs that provides an

interface for WoT Servients and WoT Clients to register TDs and look them up.

WoT Client (WoT-C) A logical entity that can access and interact with a

WoT Server/Servient.

WoT Thing (WoT-T) The abstract concept of a physical entity that can either be a real-world artifact, such as a device, or a virtual entity that represents physicality, such as a room or group of devices.

WoT Servient (WoT-S) The addressable application endpoint of a Thing that makes it interactive by providing a WoT Interface and means to execute application logic. An entity consists of Web client, Web server, and device control capabilities. Typically, for a given WoT Thing, it has an associated WoT-S, which is the "representation" of this WoT Thing in the system that can be interacted by other WoT servients and/or WoT client.

WoT/SL Interworking This is the key logical entity that handles/realizes Entity (WSIE) the interworking between WoT-compliant system and SL-compliant system. WSIE has the capabilities to work with both WoT-compliant and SL-compliant access interfaces. For all the interworking-oriented IOs created for supporting interworking, WSIE will monitor all the

interaction operations on those IOs by the users in different systems and it is the WSIE working

behind to finally translate those operations into

specific access interfaces and realize the real

interworking process.

WoT/SL Interworking It is possible that there may be multiple WSIEs

Manager (WSFM) that can support interworking. Accordingly, a

WSIM is introduced as a manager for

coordinating and scheduling all the interworking- related tasks among different WSIEs.

X-compliant System A System A is X-compliant, which means the

access interfaces adopted by the system is

compliant to X standard (X could refer to any

standard, such as WoT, SL e.g. oneM2M, etc.).

Accordingly, a native thing/device/entity in a X- compliant system will be called a "a X-compliant

Thing/Device/Entity", who provides X-compliant access interfaces.

Table 2

General Architecture

[0064] Figure 2a is a diagram of an example machine-to machine (M2M), Internet of Things (IoT), or Web of Things (WoT) communication system 10 in which one or more disclosed embodiments may be implemented. Generally, M2M technologies provide building blocks for the IoT/WoT, and any M2M device, M2M gateway, M2M server, or M2M service platform may be a component or node of the IoT/WoT as well as an IoT/WoT Service Layer, etc. Any of the client, proxy, or server devices illustrated in any of Figures 2C, 12, 13 and 14 and 35 may comprise a node of a communication system, such as the ones illustrated in Figures 2C, 12-14, 35.

[0065] The service layer may be a functional layer within a network service architecture. Service layers are typically situated above the application protocol layer such as HTTP, CoAP or MQTT and provide value added services to client applications. The service layer also provides an interface to core networks at a lower resource layer, such as for example, a control layer and transport/access layer. The service layer supports multiple categories of (service) capabilities or functionalities including a service definition, service runtime enablement, policy management, access control, and service clustering. Recently, several industry standards bodies, e.g., oneM2M, have been developing M2M service layers to address the challenges associated with the integration of M2M types of devices and applications into deployments such as the

Internet/Web, cellular, enterprise, and home networks. A M2M service layer can provide applications and/or various devices with access to a collection of or a set of the above mentioned capabilities or functionalities, supported by the service layer, which can be referred to as a CSE or SCL. A few examples include but are not limited to security, charging, data management, device management, discovery, provisioning, and connectivity management which can be commonly used by various applications. These capabilities or functionalities are made available to such various applications via APIs which make use of message formats, resource structures and resource representations defined by the M2M service layer. The CSE or SCL is a functional entity that may be implemented by hardware and/or software and that provides (service) capabilities or functionalities exposed to various applications and/or devices (i.e., functional interfaces between such functional entities) in order for them to use such capabilities or functionalities.

[0066] As shown in Figure 2 A, the M2M/ IoT/WoT communication system 10 includes a communication network 12. The communication network 12 may 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 network 12 may be comprised of multiple access networks that provide content such as voice, data, video, messaging, broadcast, or the like to multiple users. For example, the communication network 12 may 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 network 12 may 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. [0067] As shown in Figure 2 A, the M2M/ IoT/WoT communication system 10 may 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 and Infrastructure Domain may both comprise a variety of different nodes (e.g., servers, gateways, device, and the like) of the network. For example, the Field Domain may include M2M gateways 14 and devices 18. It will be appreciated that any number of M2M gateway devices 14 and M2M devices 18 may be included in the M2M/ IoT/WoT communication system 10 as desired. Each of the M2M gateway devices 14 and M2M devices 18 are configured to transmit and receive signals, using communications circuitry, via the communication network 12 or direct radio link. A M2M gateway 14 allows 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 network 12 or direct radio link. For example, the M2M devices 18 may collect data and send the data, via the communication network 12 or direct radio link, to an M2M application 20 or other M2M devices 18. The M2M devices 18 may also receive data from the M2M application 20 or an M2M device 18. Further, data and signals may be sent to and received from the M2M application 20 via an M2M Service Layer 22, as described below. M2M devices 18 and gateways 14 may communicate via various networks including, cellular, WLAN, WPAN (e.g., Zigbee, 6L0WPAN, Bluetooth), direct radio link, and wireline for example.

Exemplary M2M devices include, but are not limited to, tablets, smart phones, medical devices, temperature and weather monitors, connected cars, smart meters, game consoles, personal digital assistants, health and fitness monitors, lights, thermostats, appliances, garage doors and other actuator-based devices, security devices, and smart outlets.

[0068] Referring to Figure 2B, the illustrated M2M Service Layer 22 in the field domain provides services for the M2M application 20, M2M gateways 14, and M2M devices 18 and the communication network 12. It will be understood that the M2M Service Layer 22 may communicate with any number of M2M applications, M2M gateways 14, M2M devices 18, and communication networks 12 as desired. The M2M Service Layer 22 may be implemented by one or more nodes of the network, which may comprise servers, computers, devices, or the like. The M2M Service Layer 22 provides service capabilities that apply to M2M devices 18, M2M gateways 14, and M2M applications 20. The functions of the M2M Service Layer 22 may be implemented in a variety of ways, for example as a web server, in the cellular core network, in the cloud, etc.

[0069] Similar to the illustrated M2M Service Layer 22, there is the M2M Service Layer 22' in the Infrastructure Domain. M2M Service Layer 22' provides services for the M2M application 20' and the underlying communication network 12 in the infrastructure domain. M2M Service Layer 22' also provides services for the M2M gateways 14 and M2M devices 18 in the field domain. It will be understood that the M2M Service Layer 22' may communicate with any number of M2M applications, M2M gateways and M2M devices. The M2M Service Layer 22' may interact with a Service Layer by a different service provider. The M2M Service Layer 22' may be implemented by one or more nodes of the network, which may comprise servers, computers, devices, virtual machines (e.g., cloud computing/storage farms, etc.) or the like.

[0070] Referring also to Figure 2B, the M2M Service Layers 22 and 22' provide a core set of service delivery capabilities that diverse applications and verticals may leverage. These service capabilities enable M2M applications 20 and 20' 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 Layers 22 and 22' also enable M2M applications 20 and 20' to communicate through various networks such as network 12 in connection with the services that the Service Layers 22 and 22' provide.

[0071] The M2M applications 20 and 20' 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, servers and other nodes 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 applications 20 and 20' .

[0072] Generally, a Service Layer, such as the Service Layers 22 and 22' illustrated in Figure 2B, defines a software middleware layer that supports value-added service capabilities through a set of Application Programming Interfaces (APIs) and underlying networking interfaces. Both the ETSI M2M and oneM2M architectures define a Service Layer. ETSI M2M's Service Layer is referred to as the Service Capability Layer (SCL). The SCL may be implemented in a variety of different nodes of the ETSI M2M architecture. For example, an instance of the Service Layer 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)) and/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 may be hosted on different types of network nodes (e.g., infrastructure node, middle node, application-specific node). The Third Generation Partnership Project (3GPP) has also defined architecture for machine-type communications (MTC). In that architecture, the Service Layer, and the service capabilities it provides, are implemented as part of a Service Capability Server (SCS). Whether embodied in a DSCL, GSCL, or NSCL of the ETSI M2M architecture, in a Service Capability Server (SCS) of the 3 GPP MTC architecture, in a CSF or CSE of the oneM2M architecture, or in some other node of a network, an instance of the Service Layer may be implemented as a logical entity (e.g., software, computer-executable instructions, and the like) executing either on one or more standalone nodes in the network, including servers, computers, and other computing devices or nodes, or as part of one or more existing nodes. As an example, an instance of a Service Layer or component thereof may be implemented in the form of software running on a network node (e.g., server, computer, gateway, device or the like) having the general architecture illustrated in Figure 2C or Figure 2D described below.

[0073] Further, the methods and functionalities described herein may be implemented as part of an M2M network that uses a Service Oriented Architecture (SOA) and/or a Resource-Oriented Architecture (ROA) to access services.

[0074] Figure 2C is a block diagram of exemplary hardware/software architecture of a node of a network, such as one of the clients, servers, or proxies illustrated in Figures 2C, 12-14 and 35, which may operate as an M2M server, gateway, device, or other node in an M2M network such as that illustrated in Figures 2C, 12-14 and 35. As shown in Figure 2C, the node 30 may include a processor 32, non-removable memory 44, removable memory 46, a speaker/microphone 38, a keypad 40, a display, touchpad, and/or indicators 42, a power source 48, a global positioning system (GPS) chipset 50, and other peripherals 52. The display includes a graphical user interface (GUI), as exemplarily shown in Figure 40. The node 30 may also include communication circuitry, such as a transceiver 34 and a transmit/receive element 36. It will be appreciated that the node 30 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment. This node may be a node that implements

interworking between systems, e.g., in relation to the methods described in reference to Figures 20-33 and 38-39 or the data structures of Figures 20-33 and 38-39, or in a claim.

[0075] The processor 32 may 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. In general, the processor 32 may execute computer-executable instructions stored in the memory (e.g., memory 44 and/or memory 46) of the node in order to perform the various required functions of the node. For example, the processor 32 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the node 30 to operate in a wireless or wired environment. The processor 32 may run application-layer programs (e.g., browsers) and/or radio access-layer (RAN) programs and/or other communications programs. The processor 32 may also perform security operations such as authentication, security key agreement, and/or cryptographic operations, such as at the access-layer and/or application layer for example.

[0076] As shown in Figure 3, the processor 32 is coupled to its communication circuitry (e.g., transceiver 34 and transmit/receive element 36). The processor 32, through the execution of computer executable instructions, may control the communication circuitry in order to cause the node 30 to communicate with other nodes via the network to which it is connected. In particular, the processor 32 may control the communication circuitry in order to perform the interworking between systems herein, e.g., in relation to Figures 20-33 and 38-39, or in a claim. While Figure 3 depicts the processor 32 and the transceiver 34 as separate components, it will be appreciated that the processor 32 and the transceiver 34 may be integrated together in an electronic package or chip.

[0077] The transmit/receive element 36 may be configured to transmit signals to, or receive signals from, other nodes, including M2M servers, gateways, device, and the like. For example, in an embodiment, the transmit/receive element 36 may be an antenna configured to transmit and/or receive RF signals. The transmit/receive element 36 may support various networks and air interfaces, such as WLAN, WPAN, cellular, and the like. In an embodiment, the

transmit/receive element 36 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 36 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 36 may be configured to transmit and/or receive any combination of wireless or wired signals.

[0078] In addition, although the transmit/receive element 36 is depicted in Figure 2C as a single element, the node 30 may include any number of transmit/receive elements 36. More specifically, the node 30 may employ MTMO technology. Thus, in an embodiment, the node 30 may include two or more transmit/receive elements 36 (e.g., multiple antennas) for transmitting and receiving wireless signals.

[0079] The transceiver 34 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 36 and to demodulate the signals that are received by the transmit/receive element 36. As noted above, the node 30 may have multi-mode capabilities. Thus, the transceiver 34 may include multiple transceivers for enabling the node 30 to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.

[0080] The processor 32 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 44 and/or the removable memory 46. For example, the processor 32 may store session context in its memory, as described above. The nonremovable memory 44 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 46 may include a subscriber identity module (SFM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 32 may access information from, and store data in, memory that is not physically located on the node 30, such as on a server or a home computer. The processor 32 may be configured to control lighting patterns, images, or colors on the display or indicators 42 to reflect the status of an M2M Service Layer session migration or sharing or to obtain input from a user or display information to a user about the node's session migration or sharing capabilities or settings. In another example, the display may show information with regard to a session state. [0081] The processor 32 may receive power from the power source 48, and may be configured to distribute and/or control the power to the other components in the node 30. The power source 48 may be any suitable device for powering the node 30. For example, the power source 48 may 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.

[0082] The processor 32 may also be coupled to the GPS chipset 50, which is configured to provide location information (e.g., longitude and latitude) regarding the current location of the node 30. It will be appreciated that the node 30 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0083] The processor 32 may further be coupled to other peripherals 52, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 52 may include various sensors such as an accelerometer, biometrics (e.g., finger print) sensors, an e-compass, a satellite transceiver, a sensor, a digital camera (for photographs or video), a universal serial bus (USB) port or other interconnect interfaces, 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.

[0084] The node 30 may be embodied in other apparatuses or devices, such as a sensor, consumer electronics, a wearable device such as a smart watch or smart clothing, a medical or eHealth device, a robot, industrial equipment, a drone, a vehicle such as a car, truck, train, or airplane. The node 30 may connect to other components, modules, or systems of such apparatuses or devices via one or more interconnect interfaces, such as an interconnect interface that may comprise one of the peripherals 52.

[0085] Figure 2D is a block diagram of an exemplary computing system 90 which may also be used to implement one or more nodes of a network, such as the clients, servers, or proxies illustrated in Figures 20-33 and 38-39, which may operate as an M2M server, gateway, device, or other node in an M2M network such as that illustrated in Figures 2C, 12-14 and 35.

[0086] Computing system 90 may 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 a processor, such as central processing unit (CPU) 91, to cause computing system 90 to do work. In many known workstations, servers, and personal computers, central processing unit 91 is implemented by a single-chip CPU called a

microprocessor. In other machines, the central processing unit 91 may comprise multiple processors. Coprocessor 81 is an optional processor, distinct from main CPU 91, which performs additional functions or assists CPU 91. CPU 91 and/or coprocessor 81 may receive, generate, and process data related to the disclosed systems and methods for E2E M2M Service Layer sessions, such as receiving session credentials or authenticating based on session credentials.

[0087] In operation, CPU 91 fetches, decodes, and executes instructions, and transfers information to and from other resources via the computer's main data-transfer path, system bus 80. Such a system bus connects the components in computing system 90 and defines the medium for data exchange. System bus 80 typically includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for operating the system bus. An example of such a system bus 80 is the PCI (Peripheral Component Interconnect) bus.

[0088] Memories coupled to system bus 80 include random access memory (RAM) 82 and read only memory (ROM) 93. Such memories include circuitry that allows information to be stored and retrieved. ROMs 93 generally contain stored data that cannot easily be modified. Data stored in RAM 82 may be read or changed by CPU 91 or other hardware devices. Access to RAM 82 and/or ROM 93 may be controlled by memory controller 92. Memory controller 92 may provide an address translation function that translates virtual addresses into physical addresses as instructions are executed. Memory controller 92 may also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Thus, a program running in a first mode may access only memory mapped by its own process virtual address space; it cannot access memory within another process's virtual address space unless memory sharing between the processes has been set up.

[0089] In addition, computing system 90 may contain peripherals controller 83 responsible for communicating instructions from CPU 91 to peripherals, such as printer 94, keyboard 84, mouse 95, and disk drive 85.

[0090] Display 86, which is controlled by display controller 96, is used to display visual output generated by computing system 90. Such visual output may include text, graphics, animated graphics, and video. Display 86 may 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 controller 96 includes electronic components required to generate a video signal that is sent to display 86.

[0091] Further, computing system 90 may contain communication circuitry, such as for example a network adaptor 97, that may be used to connect computing system 90 to an external communications network, such as network 12 of Figures 2A-D, to enable the computing system 90 to communicate with other nodes of the network.

W3C Web-of-Things (WoT) Overview

[0092] In Web of Things (WoT), a functional virtual entity is named a "WoT Servient" which provides the access to, control and retrieval of the status and values from physical things/devices (called "WoT Things"). The general WoT Servient functional architecture is shown in Figure 3. In general, things in the WoT architecture are represented by so-called "Servients", which are usually hosted directly on the physical thing. Servients can also provide access to virtual things, for instance, a collection of things (e.g., all lights in a room) or a WoT gateway for legacy devices (e.g., a Bluetooth device connected to a smartphone). In the latter case, servients can be hosted anywhere, such as inside a smartphone, a local gateway, or the cloud. Servients communicate with each other through the so-called "WoT Interface", a Web API that follows the recommendations of the WoT Information Group (IG). Servients can be in a client role (i.e., they only consume other Things), server role (i.e., they only expose things and provide capabilities), or both. In general, a WoT Thing (e.g., a legacy device only providing proprietary interface), has an associated WoT servient, which is the "representation" of this WoT Thing in the system, and with which other WoT servients can interact with.

[0093] Each WoT Thing is described by a WoT Thing Description (TD). The TD must be acquired in order to use and interact with the Thing, since the TD describes the semantics of a Thing as well as its WoT Interface. Usually, Things directly provide their own TDs, but the TD can also be hosted externally if there is not enough space on the thing/device. To ease discovery, TDs can be registered with a well-known TD Repository (TDR), where the TD for Things of interest can be queried.

[0094] The application logic of a WoT Thing (or technically a servient) can be implemented natively, for instance in the device firmware, which is expected to be common for very resource- constrained Things. Following the patterns in the Web, however, application logic should also be provided by scripts. This is supported through a scripting runtime environment— similar to the Web browser— that may be provided by a servient. App scripts implement application logic in a modular and portable way. It can access local hardware, locally connected legacy devices, and remote things through the WoT Interface. Portability of such scripts is ensured through a common Scripting API (Client, Server, Discovery and Propriety) that allows an application to discover things, to use the client and server functionality of the servient, and to access/control the hardware physically attached to the servient. Scripting API is more like an internal API used by application scripts, while the WoT Interface is an external interaction interface between different WoT Servients.

WoT Thing Description (TP)

[0095] The WoT Thing Description (TD) provides the semantic metadata of a Thing as well as a functional description of its WoT Interface. For this, it relies on the Resource Description Framework (RDF) as an underlying data model. For now, JSON-LD is used as the default TD serialization format. The WoT IG defines a minimal vocabulary to express the capabilities of a WoT Thing in terms of different interaction patterns: Properties, Actions, and Events. Property provides readable and/or writeable data that can be static (e.g., supported mode, rated output voltage, etc.) or dynamic (e.g., current fill level of water, minimum recorded temperature, etc.). The action interaction pattern targets changes or processes on a Thing that "take a certain time to complete" (i.e., actions cannot be applied instantaneously like property writes). Examples include an LED fade in, moving a robot, brewing a cup of coffee, etc. Usually, ongoing actions are modelled as task resources, which are created when an action invocation is received by the Thing. The event interaction pattern enables a mechanism to be notified by a Thing on a certain condition. While some protocols such as CoAP can provide such a mechanism natively, others do not. Furthermore, events might need a specific configuration that requires data sent and stored on the Thing in a standard way. In addition, the TD provides metadata for the different communication bindings (e.g., HTTP, CoAP, etc.), mediaTypes (e.g., "application/json", "application/exi", etc.), and security policies (authentication, authorization, etc.). Figure 2 shows an overview of the relevant content defined in a TD.

[0096] In practice, a WoT Thing provides many details about what kind of Thing it is and what the interactions mean. This additional information is the semantic context of the Thing. JSON- LD provides a means to enable a TD to have an external "semantic" context, which allows reusing existing models, thereby enhancing semantic interoperability. Through a context, the meaningless strings turn into semantically-defined terms that are part of a common vocabulary (i.e., ontology).

[0097] The example shown in Table 3 below is a TD defining an LED Light that supports multiple protocols (CoAP and HTTP), mediaTypes (JSON and EXI), and security policies. It also shows the integration of the actuator namespace (i.e., a concept of "actuator" defined in an ontology) and the resulting semantic enrichment on several Properties (such as

"actuator:onOffStatus",''actuator:fadeIn", "actuatonfadeOut") and on Event (such as

"actuatonalert").

{

"@context": [

"http://w3c.github.io/wot/w3c-wot-td-context.jsonld", { "actuator": "http://example.0rg/actuator#" }

],

"@type": "Thing",

"name" : "MyLEDThing",

"base": "coap://myled. example. com:5683/",

"security": {

"cat": "token :jwt", "alg": "HS256",

"as": "https://authority-issuing.example.org" "interactions": [

{

"@type": ["Property", "actuator: onOffiStatus"],

"name": "status",

"outputData": {"valueType": { "type": "boolean" } }, "writable": true,

"links": [{

"href : "pwr",

"mediaType" : "application/exi"

},

{

"href : "http://myled.example.com:8080/status", "mediaType" : "application/json"

}]

},

{

"@type": ["Action", "actuator adeln"], "name": "fadeln",

"inputData": {

"valueType": { "type" : "integer" }, "actuatonunit" : "actuatonms"

},

"links": [{

"href : "in",

"mediaType" : "application/exi"

{

"href : "http://myled.example.com:8080/in" "mediaType" : "application/json"

}]

"@type": ["Action","actuator:fadeOut"],

"name": "fadeOut",

"inputData": {

"valueType": { "type" : "integer" },

"actuatonunit" : "actuatonms"

},

"links": [{

"href : "out", "mediaType" : "application/exi'

},

"href : "http://myled.example.com:8080/out", "mediaType" : "application/json"

}]

'@type": ["Event", "actuator: alert"],

'name": "criticalCondition",

"outputData": {"valueType": { "type": "string"

"links": [{

"href : "ev",

"mediaType" : "application/exi'

}]

}

]

Table 3 [0098] Based on the TD shown in Table 3, one is able to know that the status of the Thing can be requested using a CoAP GET on coap://myled. example. com:5683/pwr ("base URI" from the global scope endpoint definition plus the "href) or an HTTP GET on

http://myled. example. com:8080/status. It can also be modified using a PUT on the respective URIs, since Property is writable. The Actions can be invoked through a POST to fadeln (e.g., /in for CoAP) and fadeOut (e.g., /out for CoAP) with an integer value in milliseconds (how long the action will last). MyLEDThing also provides an Event called criticalCondition through CoAP protocol, which enables clients to be informed about problems (enabled by the CoAP GET with the Observe option to coap://myled. example. com:5683/ev).

oneM2M Overview

[0099] The oneM2M standard under development defines a service layer called "Common Service Entity (CSE)". The purpose of the service layer is to provide "horizontal" services that can be utilized by different "vertical" M2M systems and applications. The CSE supports four reference points as shown in Figure 5. The Mca reference point interfaces with the Application Entity (AE). The Mcc reference point interfaces with another CSE within the same service provider domain and the Mcc' reference point interfaces with another CSE in a different service provider domain. The Men reference point interfaces with the underlying network service entity (NSE). An NSE provides underlying network services to the CSEs, such as device management, location services and device triggering.

[0100] CSE contains multiple logical functions called "Common Service Functions (CSFs)", such as "Discovery" and "Data Management & Repository." Figure 6 illustrates some of the CSFs defined by oneM2M.

[0101] The oneM2M architecture enables the following types of Nodes:

[0102] Application Service Node (ASN): An ASN is a Node that contains one CSE and contains at least one Application Entity (AE). Example of physical mapping: an ASN could reside in an M2M Device.

[0103] Application Dedicated Node (ADN): An ADN is a Node that contains at least one AE and does not contain a CSE. There may be zero or more ADNs in the Field Domain of the oneM2M System. Example of physical mapping: an Application Dedicated Node could reside in a constrained M2M Device. [0104] Middle Node (MN): A MN is a Node that contains one CSE and contains zero or more AEs. There may be zero or more MNs in the Field Domain of the oneM2M System. Example of physical mapping: a MN could reside in an M2M Gateway.

[0105] Infrastructure Node (IN): An IN is a Node that contains one CSE and contains zero or more AEs. There is exactly one IN in the Infrastructure Domain per oneM2M Service Provider. A CSE in an IN may contain CSE functions not applicable to other node types. Example of physical mapping: an IN could reside in an M2M Service Infrastructure.

[0106] Non-oneM2M Node (NoDN): A non-oneM2M Node is a Node that does not contain oneM2M Entities (neither AEs nor CSEs). Such Nodes represent devices attached to the oneM2M system for interworking purposes, including management.

Interworking with Non-oneM2M Solutions

[0107] In oneM2M, the interworking solution is based on the use of specialized Interworking Application Entities (IPE) (shown in Figure 7) that are interfaced to the CSE via standard Mca reference points.

[0108] The IPE is characterized by the support of a non-oneM2M reference point, and by the capability of remapping the related data model to the oneM2M resources exposed via the Mca reference point.

Semantic Enablement in oneM2M

[0109] The <semanticDescriptor> resource as shown in Figure 8 is used to store a semantic description pertaining to a resource and potentially sub-resources. Such a description may be provided according to ontologies. The semantic information is used by the semantic

functionalities of the oneM2M system and is also available to applications or CSEs.

[0110] In oneM2M TS-0023 provides unified means in the oneM2M system by defining a Home Appliance Information Model (HAIM) for the home domain devices such as TV, refrigerator, air conditioner, clothes washer, oven, and robot cleaner. For the reasons of interworking with external technologies and efficiency, the principle of the home appliance information model is designed based on Home Gateway Initiative (HGI) Smart Device Template (SDT) 3.0. Figure 9 depicts the basic structure of SDT 3.0.

[0111] The design principle of the oneM2M abstract information model of home appliance, is to use SDT 3.0, which includes the following essential components: [0112] ModuleClasses" specifies a single service (e.g., audioVolume, powerOn/Off) with one or more Actions, Properties, DataPoints and Events. Each service which is described as a "ModuleClass" that can be re-used in many Devices.

[0113] "Device model" is a physical, addressable, identifiable appliance, sensor and actuator with one or more Modules, Properties and SubDevices.

[0114] "SubDevice" is a device which may be embedded in a Device and/or is addressed via another Device.

[0115] "Module" is an instantiation of a ModuleClass for a specific Device or SubDevice.

[0116] Air Conditioner Example: Device Model 'deviceAirConditioner' Defined by HAIM

[0117] An air conditioner is a home appliance used to alter the properties of air (primarily temperature and humidity) to more comfortable conditions. This air conditioner information model provides capabilities to control and monitor air conditioner specific functions and resources. Table 4 shows that the air conditioner device model defined by HAIM is composed of a number of modules (such as binarySwitch, runMode, etc), and each of those modules is an instantiation of a corresponding ModuleClass. For example, the module binarySwitch is an instantiation of ModuleClass "binarySwitch"

Table 4

[0118] With a defined device model in HAIM, it also needs a resource representation in the oneM2M system. In other words, given a "deviceAirConditioiner" device model in HAIM, it also needs to define how to represent this device model in terms of oneM2M resources, which currently leverages the <flexContainer> resource type. The <flexContainer> resource type is a customizable container for data instances (see Figure 10 for its details). It is a template for the definition of flexible specializations of data containers. In particular, a specialization of the <flexContainer> resource includes associated content directly inside the <flexContainer> by means of one or more "customAttribute" attribute(s) and those customAttribute attributes can be used for representing the "deviceAirConditioiner" device model. For example, as shown in Figure 11, the 'deviceAirConditioner' model is mapped to a [deviceAirConditioner] resource which is a specialization of <flexContainer> resource. In the meantime, all the essential information defined in the 'deviceAirConditioner' device model are represented by the

[deviceAirConditioner] resource and its child resources.

Interworking-oriented 10 Lifecycle Management

[0119] According to the aspects discussed below, the letter "X" or "Y" is used in the terms such as "X-compliant" or "Y-compliant" as a wildcard and can refer to either SL or WoT, or any other standard. Although this application mainly considers the interworking between a WoT- compliant system and a SL-compliant system, the ideas proposed in this application can also be applied to interworking between any two systems as long as their IOs have similarities or similar purposes and need interworking-oriented 10 lifecycle management.

[0120] Even within the WoT-compliant system or SL-compliant system, the 10 can refer to any other newly-defined IOs that may appear in a future release of the WoT standard or the SL standard (such as oneM2M). For example, although this application mainly considers TD as the major 10 defined in WoT-compliant system, the ideas in this application can also be applied to any other new IO(s) defined in a future release of WoT standard. Similarly, in the context of a SL system such as oneM2M, an existing type of resource (such as <AE> or <flexContainer> resources) could be used for representing WoT Things and their TDs. The ideas in this application can also be applied to any other newly-defined resource types defined in a future release of SL standard (such as oneM2M). In addition, device and thing are used interchangeably in this section unless they are clarified explicitly. Moreover, while the ideas are described in the context of WoT Servicent, the ideas are also applicable to a WoT Server.

[0121] Interworking-oriented 10 lifecycle management mainly focuses on how to manage the lifecycles of the interworking-oriented IOs that are to be used for realizing the real interworking process. In particular, for the two systems (e.g., a WoT-compliant system and a SL-compliant system to be interworked), this task will take care of interworking on "two directions" and address the following issues:

[0122] 1. ' nterworking from WoT-compliant system to SL-compliant System. " There is an assumption it is known how to represent a TD of a WoT-compliant device in the SL-compliant system through resource mapping and IM alignment. A new WoT-compliant device just publishes its TD and makes itself available in the WoT-compliant system. Now it wants to make itself available in the SL-compliant system in order to support interworking. Accordingly, a mechanism is proposed for creating a corresponding interworking-oriented 10 in the SL- compliant system realized through a "10 Creation process."

[0123] Sometime later, the WoT-compliant device may make some changes on its TD due to device re-configurations. A mechanism is proposed such that updates can also be reflected in its corresponding interworking-oriented 10 created in the SL-compliant system. This is realized through a "10 Update process" as proposed in this application.

[0124] Last, if the WoT-compliant device is going to be offline and/or its TD is deleted from the WoT-compliant system, a mechanism is proposed such that its corresponding interworking- oriented 10 created in the SL-compliant system also needs to be deleted and realized through a "10 Deletion process" as proposed in this application.

[0125] 2. "Interw or king from SL-compliant system to WoT-compliant System. " Consider that a new SL-compliant device just registers itself to a SL node and has a SL resource representation. In order to support interworking, a mechanism is proposed for creating a TD for this SL- compliant device or its SL representation, and publishing this interworking-oriented 10 (i.e., the created TD) to the WoT-compliant system such that this SL-compliant device can become available in the WoT-compliant system. This is also realized through the "10 Creation process" as proposed in this application.

[0126] Sometime later, the SL resource representation of this SL-compliant device may have undergone some changes due to CRUD operations on this representation. Therefore, a mechanism is proposed such that those updates can also be reflected in its corresponding TD published to the WoT-compliant system. This is also realized through the "10 Update process" as proposed in this application.

[0127] Last, if the SL-compliant device is going to be offline and delete its SL resource representation in the SL-compliant system, a mechanism is needed such that its corresponding TD published to the WoT-compliant system also needs to be deleted. This is also realized through the "10 Deletion process" as proposed in this application.

The WoT/SL Interworking Architecture- 1

[0128] According to an embodiment, Architecture- 1 is shown in Figure 12 where some entities are involved and each of them will have certain responsibilities and roles. They are listed as follows: [0129] WoT Thing (WoT-T): The abstract concept of a physical entity that can either be a real- world artifact, such as a physical device, or a virtual entity that represents physicality, such as a room or group of devices.

[0130] WoT Servient (WoT-S): The addressable application endpoint of a Thing that makes it interactive by providing a WoT Interface and means to execute application logic. Typically, for a given WoT Thing (e.g., a legacy device only providing proprietary interface), it has an associated WoT-S, which is the "representation" of this WoT Thing in the WoT-compliant system that can be interacted by other WoT Servients.

[0131] WoT TD Repository (TDR) : A registry for TDs that provides a Web interface to register TDs and look them up.

[0132] SL Native Resource Provider (SL-NRP): Typically, if an entity is a SL-compliant thing/device, it (acting as a SL-NRP) will create its own SL resource representation when registering itself to a SL node (which is a SL resource host).

[0133] SL Native Resource Host (SL-NRH) : This is a "logical" role. If a SL node hosts resources that are created by SL-NRPs, then this SL node has a role of SL-NRH. For example, if a SL- compliant thing/device (as a SL-NRP) creates its own SL resource representation on a SL node, this node will be a SL-NRH.

[0134] WoT/SL Interw or king Entity (WSIE): This is the key entity that handles/realizes the interworking between WoT-compliant system and SL-compliant System. WSIE has the capabilities to work with both WoT-compliant and SL-compliant access interfaces. For all the interworking-oriented IOs created for supporting interworking, WSIE will monitor all the interaction operations on those IOs by the users in different systems and it is the WSIE that translates those operations into specific interface actions and realizes the real interworking process.

[0135] Interworking-oriented IOs will have different forms in different systems. For example, a WoT TD can be created for a SL resource representing a SL-compliant device. Such a TD will be an interworking-oriented IO and be published in the WoT-compliant system. In Architecture- 1, it is considered that the TD for representing a SL-compliant device/resource will mainly be published in the TD Repository in the WoT-compliant system. In another example, a WoT- compliant device and its TD can also have SL resource representation(s) such that this device and its TD can also become available in the SL-compliant system. Such SL resource representations representing this WoT-compliant device and its TD are also the interworking- oriented IOs created in the SL-compliant system. In Architecture- 1, it is assumed that all the interworking-oriented IOs stored in the SL-compliant system (such as SL resources representing WoT-compliant things/devices and TDs) will be co-located with WSIE (as shown in Figure 12).

[0136] There will be many interactions between different entities shown in Architecture- 1. For example, WoT servients or SL- RPs can directly contact WSIE in order to indicate they intend to be available in other systems for supporting interworking. In the meantime, WSIE can proactively explore the TD Repository to see if any TDs published by WoT Servients should also be available in the SL-compliant system. Similarly, WSIE can also explore SL- RHs to see any SL resources should also be available in the WoT-compliant system through WoT TDs. In the last two cases, WSIE does not have to deal with the native WoT servient or native SL-NRPs. The WoT/SL Interworking Architecture-2

[0137] According to another embodiment Architecture-2 is shown in Figure 13. Many concepts from Architecture- 1 are also available in Architecture-2. Architecture-2 involves some new entities as follows:

[0138] TD Host: A TD not only can be published into the TD Repository, it can also be hosted by a WoT Servient or a node in order to support local/near-by discovery. Such a node that can host TD(s) is called a TD Host.

[0139] SL Resource Host for A WoT Thing (SL-RH-T): For a given WoT-compliant thing in a WoT-compliant system, if it has resource representation(s) in the SL-compliant system (which is/are its corresponding interworking-oriented IO(s)), such IO(s) can be hosted on different places instead of being co-located within WSIE. A SL resource host that can host IO(s) representing WoT Things is called a SL-RH-T.

[0140] SL Resource Host for A TD (SL-RH-TD): For a given WoT-compliant thing in WoT- compliant system, if its TD also has a resource representation in the SL-compliant system (which is the corresponding interworking-oriented IO for this TD), such an IO can be hosted in a different place instead of 1) being co-located with WSIE or 2) being co-located with the corresponding interworking-oriented IO(s) of the WoT-compliant Thing itself. The SL resource host that can host IO(s) representing TDs is called a SL-RH-TD. It is envisaged the SL-RH-T and SL-RH-TD are "logical" entities in the sense that a physical SL node can take multiple roles as a SL-NRH, a SL-RH-T and a SL-RH-TD at the same time. [0141] The WSIE interacts with TD Host as well as SL-RH-T and SL-RH-TD. For example, once a TD for a SL resource needs to be made available in the WoT-compliant system, WSIE needs to decide which WoT Servient (as a TD host) should host this TD if this TD is not just to be stored in the TD Repository. Similarly, for a given WoT thing and its TD, the WSIE also needs to decide where to store its corresponding interworking-oriented IOs (in terms of SL resources) and to select an appropriate SL-RH-T and/or SL-RH-TD to host those resources. The WoT/SL Interworking Architecture-3

[0142] In yet another embodiment, Architecture-3 is shown in Figure 14. Architecture-3 involves new entities in addition to the entities already mentioned in Architecture-2, which are listed as follows:

[0143] WSIM: It is possible that there may be multiple WSIEs that can support interworking. Accordingly, the WSFM is a manager for coordinating and scheduling all the interworking- related tasks among different WSIEs. Typically, there could be two major working schemes for WSIM:

[0144] Scheme-1: In this scheme, WSIM will be the only entity that is exposed to the external entities and all the WSIEs are the internal working entities. In other words, all the external entities from WoT-compliant system and/or SL-compliant system will only communicate with WSIM. For example, when a WoT-compliant device contacts WSIM for publishing its TD to the SL-compliant system, the WSFM will accept the request but internally the WSFM will select a specific WSIE to process this request. This may be fully transparent to the WoT-compliant devices and SL-compliant devices.

[0145] Scheme-2: In this scheme, all the WSIEs can still directly interact with all the external entities from WoT-compliant system and/or SL-compliant System. However, if a given WSIE-1 cannot process or work on interworking related requests due to e.g., overloading, the WSIE-1 may ask WSFM for help. In this case, WSIM becomes an internal working entity and all the external entities do not know the existence of WSIM. Accordingly, the WSIM may help WSIE-1 to find a backup WSIE and inform WSIE-1 that another WSIE (e.g., WSIE-2) can help it and is ready to accept task transfer.

Interworking-oriented IO Lifecycle Management under Architecture -1

[0146] In order to create interworking-oriented IOs, it is necessary to first identify and categorize different types of users who will utilize these interworking-oriented IOs. On the one hand, "a device is X-compliant" when the access interfaces of a device follows the X standard. Similarly, "a user is X-compliant" basically means that the user only has the capability to access X- compliant interface.

[0147] On the other hand, the "Information Model (IM)" is used to describe/model physical devices/entities and their functions/operations/properties. The FM is an abstract model. Each system may have its own IMs in the sense that for a given native IM defined by an X-compliant system for modeling its native things/devices, the representations of those X-compliant things/devices are normally created based upon the native IMs. Therefore they provide X- compliant access interfaces. However, an IM defined by System A may also have a

representation in another System B in order to support interworking. In particular, the representations of the same FMs in different systems may provide different access interfaces that are compliant to different standards.

[0148] Typically, a native user in a X-compliant system can understand the native IM defined by the X-compliant system and because of that, the user can freely interact with the representations of the native X-compliant things/devices since they provide the X-compliant access interface. However, it is also possible that a user in the X-compliant system can not only understand the native IM defined in X-compliant system but also understand the IMs defined by other systems (e.g., Y-compliant system). Therefore, in order to realize interworking between two systems, different solutions need to be designed by considering the different types of users, which can be categorized into two types:

[0149] For the first type, for a given user in the X-compliant system, it only understands the native IMs defined by X-compliant system, and does not know any other IMs defined by other systems. This type of user is called a System Native User (SNU). Meanwhile, for the second type, for a given user in the X-compliant system, it not only understands the native IMs defined by this system but also understands other IMs defined by other systems. This type of user is called an External IM-aware User (EIMU).

[0150] For EFMU, given the two systems to be interworked such as a WoT-compliant system and a SL-compliant System, the same IM can be represented in two different systems.

Accordingly, for a given X-compliant thing/device, it may have respective representations created in the two systems, which are both based on the same IM but provide two different access interfaces respectively. The following example considers a SL-compliant EIMU in the SL-compliant system that can understand TD (i.e., one of the IMs defined by a WoT-compliant System) but just does not have capability to use WoT-compliant access interfaces to explore TDs published in the WoT-compliant system and similarly does not have the capability to directly interact with a WoT-compliant device. To support interworking in this case (e.g., to enable this SL-compliant EEVIU to be able to discover and interact with WoT-compliant devices), a WoT- compliant device and its TD can be re-represented as SL resources in the SL-compliant system and the original IM is kept. Once a WoT device and its TD are re-represented as SL resources, this device and its TD can be discovered/accessed through a SL-compliant interface in the sense that the SL-compliant EIMU can now operate on those SL resource representations to read this TD and then interact with this WoT-compliant device through SL resources. The work regarding how to create SL resource representation(s) that mirror a WoT-compliant device and its TD is called "IM/Resource mapping" since the IM is unchanged. It just has a different representation in a different system for supporting interworking. In general, some specialized SL resources will be defined for this purpose which will be discussed below in more detail.

[0151] For a SNU, FM/Resource Mapping does not work since a X-compliant SNU only understands the native IMs defined by X-compliant system itself. For example, a SL-compliant SNU in the SL-compliant system does not know anything about a WoT-compliant device as well as the TD. In this case, it is necessary to find a way to align the IMs defined by a WoT-compliant system (i.e., TD) with the IMs defined by SL-compliant system (e.g., a HAIM model defined by oneM2M SL system). Therefore, the work regarding how to align the IMs defined by different systems is called "IM Alignment". Assuming the IM alignment is done between the TD defined by WoT-compliant system and a HAIM defined by SL-compliant system, then for a given WoT- compliant device and its TD, this device will have a SL resource representation that is created fully based on the native IM defined by a SL-compliant system (e.g., a HAIM device model). Because of that, the SL-compliant SNUs will be able to understand this resource representation and also can access this resource since the SNUs regard this resource as the one representing a native X-compliant HAIM device although it is really representing a WoT-compliant device. In general, some IM alignment rules and polices will be defined for this purpose, which will be discussed later in more details.

I. Procedures for Interworking-oriented 10 Creation under Architecture- 1

A. 10 Creation (from WoT-compliant system to SL-Compliant System) 1. 10 Creation Initiated by WOT Servient

[0152] In a first aspect, when a WoT Thing (WoT-T-1) becomes available in the WoT-compliant system, it is normally associated with a specific WoT servient (WoT-S-1) as its representation in the system and WoT-T-1 may also have a corresponding TD. In order to make WoT-T-1 available in the SL-compliant system for interworking purposes, WoT-S-1 may contact WSIE in order to create a corresponding interworking-oriented 10 in the SL-compliant system for WoT- T-l .

[0153] Figure 15 illustrates the proposed procedure for creating interworking-oriented IO(s) in the SL-compliant system for a WoT-compliant Thing and its TD initiated by a WoT Servient. As a pre-condition, the entities in both WoT-compliant system knows the existence of WSIE. The WSIE already has the detailed rules/policies regarding to how to conduct information model alignment or resource mapping between those two systems. All steps will be denoted by Arabic numerals as described below.

[0154] Step 1 : A WoT Servient (WoT-S-1) associated with a WoT Thing (WoT-T-1) intends to make WoT-T-1 also available in the SL-compliant System.

[0155] Step 2: WoT-S-1 sends the TD of WoT-T-1 to WSIE. The message may include the following new parameters:

[0156] WoT Servient ID (servient id) : This information indicates which WoT servient is initiating this request.

[0157] IO Action (action): This information indicates what action is being required. For example, in this case, the action will be "IO creation."

[0158] TD ID (td id) : This information indicates the ID of a specific TD that needs to be made available in the SL-compliant system. This option is only needed if in the step, the WoT servient does not directly include the whole TD in the payload. If this parameter is not null, it means WSIE will use TD ID to further retrieve the TD from WoT-S-1.

[0159] IM ID (im id) : It is possible that WoT-S-1 may directly suggest WSIE which specific IM should be adopted when creating the corresponding interworking-oriented IOs for the WoT- T-l and its TD in the SL-compliant system.

[0160] In the case where WoT-S-1 does not directly hold the TD of WoT-T-1 locally, it could have the following two cases: (i) WoT-S-1 can send a simple request to WSIE to require WSIE to discover WoT-T-l 's TD in a TD repository; and (ii) If WoT-S-1 knows where the WoT-T-l 's TD is hosted, it can send a request to WSIE and tell where its TD can be retrieved. Then WSIE can retrieve the TD accordingly.

[0161] Step 3 : WSIE analyzes the TD sent from WoT-S-1 and it will involve with two major tasks. The first task involves deciding what type of interworking-oriented 10 needs to be created in the SL-compliant System, which is normally based on certain pre-configurations. The pre- configurations on WSIE can be set by an admin and accordingly WSIE will follow those pre- configurations when receiving any 10 creation requests. For a SL-compliant system, it may have different types of IMs (which will be illustrated later). Accordingly, a TD can be represented as SL resources that are based on a certain selected type of IM. WSIE will follow the rules and policies as defined in the pre-configurations to select the type of IM to be used, which could cover the following aspects (but not limited to):

[0162] The IMtype priority. For example, the WSIE will first try to adopt a type PI as the referenced IM, and if the interworking-oriented IOs cannot be created based on PI, another IM type, e.g., P2, will be adopted.

[0163] The multi-type 10 creation support. It is possible that for a given TD, it may have multiple representations in the SL-compliant system based on different types of IMs. Therefore, if multi-type 10 creation support is enabled, WSIE will try to create multiple interworking- oriented IOs that are based on different FMs.

[0164] The second task, for a given selected type, involves how to represent WoT-T-1 and its TD by using the interworking-oriented IOs of that selected type. For example, for the

interworking-oriented 10 to be created, it could have the following types/options:

[0165] Option 1. Transparent Interw or king: In general, transparent interworking is the most basic approach for supporting interworking. In particular, it is designed for the EFMU, which not only understands the native IMs defined by SL-compliant systems but also understands other IMs such as TD defined by WoT-compliant System. Using transparent Interworking approach, the whole TD is fully encapsulated and stored in a SL container resource. In the context of a oneM2M system for example, WSIE stores the serialized TD of WoT-T-1 into a

<contentInstance> as opaque data.

[0166] In the meantime, another resource (e.g., a <AE> resource or any other resource such as <container> or <flexContainer>) needs to be created as well in order to represent WoT-T-1 itself. In this case, WoT-T-1 and its TD will have separated interworking-oriented IOs for representing them respectively. The interworking-oriented IOs for representing WoT-T-1 and its TD can have no child-parent relationship. Alternatively, the interworking-oriented IOs for representing WoT- T-l 's TD can be the child resource of the interworking-oriented 10 that represents WoT-T-1. But in either case, the resource representing WoT-T-1 should first be created before creating the resources representing the TD of WoT-T-1. This alternative also applies to other similar situations in the later sections.

[0167] As an example in the oneM2M context, a TD of a WoT-compliant LED-Light-123 is shown in the left part of Figure 16. It can be seen that the whole serialized TD is stored in the <TD-of-LED-Light-123> resource, which is a <contentInstance> resource while another <LED- Light-123> resource is also created, which is a <AE> and represents LED-Light-123 itself. Accordingly, it is also preferred that the base URI or address of LED-Light-123 as specified in the serialized TD to be replaced by the URI of SL resource <LED-Light-123> so that SL- compliant users may directly access this resource. This resource provides SL-compliant access interface in order to interact with the real LED-Light-123 in the WoT-compliant system.

Similarly, a new attribute can be added in the <AE> resource representing LED-Light-123, which indicates the address of where the serialized TD is stored. Accordingly, when SL- compliant users discover this <AE> resource, it can further retrieve the corresponding TD in order to understand how to use this <AE> resource to interact with WoT-T-1. In addition, since the <AE> resource represents WoT-T-1, it also needs to expose interaction interfaces such as different properties/actions/events. Therefore, multiple child resources will also be created under this <AE> resource, or customized attributes if using <flexContainer> resource, which will be used as the accessing interfaces for each of specific properties/actions/events as defined in the TD of LED-Light-123.

[0168] Option 2. Resource Mapping: A resource mapping approach is also designed for the EIMU. The EIMU not only understands the native IMs defined by the SL-compliant system but also understands other IMs such as a TD defined by the WoT-compliant system. Using a resource mapping approach, the information stored in the TD will be extracted out and represented through SL resource attributes. In this approach, some new SL resources need to be defined which fully mirror the TD and are exemplarily the specializations of <flexContainer> resources. For example, the information stored in the TD of WoT-T-1 will be extracted and exposed as SL specialized resources using <flexContainer> and/or the customized resource attributes. In the meantime, another resource (e.g., a <AE> resource) needs to be created to represent WoT-T-1 itself. Similarly as before, this resource should be created before creating the resource(s) representing the TD of WoT-T-1. In this case, WoT-T-1 and its TD will have separated interworking-oriented IOs for representing them respectively. Alternatively, these IOs can have a parent-child relationship.

[0169] As an example in the oneM2M context, a TD of a WoT-compliant LED-Light-123 is shown in the left part of Figure 17. It can be seen that the information stored in the TD is now stored in the resource attributes of some specialized SL resources. For example, <TD-Property> is a specialized resource of <flexContainer> that is to represent a Property defined in the TD of LED-Light-123. Similarly, <TD-Action> is a specialized resource of <flexContainer> that is to represent an action defined in the TD, etc. In addition, another <LED-Light-123> resource is also created, which is an <AE> resource and is to represent LED-Light-123 itself. Similarly, it is also necessary that the access URI or address of WoT-compliant LED-Light-123 as specified in the original TD may need to be replaced by the URI of <LED-Light-123> when the address information is represented through the attributes of SL specialized resources.

[0170] Option 3. HAIM Representation. The HAIM Representation approach is designed for the SNU which only understands the native IMs defined by a SL-compliant system. Accordingly, by leveraging on the IM alignment between a WoT TD and SL HAFM device model, a HAIM device resource will be the interworking-oriented IO. In particular, the information in TD will be extracted and a new resource representing a HAIM device will be created in the SL-compliant system in order to represent both WoT-T-1 itself and also its TD. In other words, in this case, WoT-T-1 and its TD will have an integrated interworking-oriented IO for representing them jointly.

[0171] As an example in the oneM2M context, a TD of a WoT-compliant LED-Light-123 is shown in the left part of Figure 18. It can be seen that information stored in the TD is now stored in the resource attributes of SL resources representing a HAIM device. For example, according to the current specification for resource mapping rules of oneM2M HAFM model, the

[deviceLight] resource is a specialized <flexContainer> resource representing a HAIM device module "light", and based on the IM alignment, this resource will be used for representing WoT- compliant LED-Light-123. Similarly, [binary Switch] resource is a specialized <flexContainer> resource representing an instance of a HAFM module class "binarySwitch," and using the FM alignment, this resource will be used for representing the "onOffStatus" Property in the TD of LED-Light-123. In addition, since now the LED-Light-123 and its TD have the integrated interworking-oriented 10 in the SL-compliant system (i.e., the [deviceLight] resource and its child resources), the SL-compliant SNU can access the [deviceLight] resource and its child resources in order to interact with LED-Light-123.

[0172] Although this option focuses on a HAIM representation, the idea proposed in this option can also be applied to any other new IM defined in a future release of the SL standard such as oneM2M.

[0173] Option 4. Semantic Descriptor Representation. The semantic descriptor approach is also designed for the SNU, which only understands the native IMs defined by the SL-compliant system. A normal SL resource, such as an <AE> resource (or a <flexContainer>) will be created in order to represent WoT-T-1. In particular, by leveraging on the IM alignment between a WoT TD and SL <semanticDescriptor> resource, the information stored in its TD will be translated into RDF triples and stored in the <semanticDescriptor> child resource(s) under this <AE> representing WoT-T-1. Overall, in this case, WoT-T-1 and its TD will have an integrated interworking-oriented IO for representing them jointly.

[0174] As an example in the oneM2M context, a TD of a WoT-compliant LED-Light-123 is shown in the left part of Figure 19. It can be seen that LED-Light-123 is represented as a <AE> or <flexContainer> resource and the information stored in its TD is now stored in the

<semanticDescriptor> child resources. In addition, child resources will also be created under this <AE>, which will be used for accessing a specific property, conducting a specific action or creating a specific event as defined in the TD of LED-Light-123. For each of those sub- resources, it may also have a <semanticDescriptor> child resource, which stores the RDF triples that describe the corresponding information as specified in the TD.

[0175] Option 5. Base Ontology Representation. The Base Ontology Representation approach is also designed for the SNU. In particular, SL resource representing an abstracted device will be used as the interworking-oriented IO to represent WoT-T-1. This approach is similar with the Option 4, however, the IM alignment is done between TD and Base Ontology. For a given type of device, its abstract device model (e.g., a HAFM device model) only exposes high-level or the most common functionalities of devices across all the manufacturers or standards, which can be defined by an industry alliance for example. In the meantime, since the abstract device model derives from SL Base Ontology, SL-compliant users are able to understand the abstract device model. When using an abstract device model as the interworking-oriented 10 to represent WoT- T-l, it only describes the high-level information in the TD of WoT-T-1 (e.g., this is a light, which has fadein and fadeOut functionalities) and any WoT system-specific information will not be exposed by this abstract device (e.g., WoT Servient related information).

[0176] Step 4: Once interworking-oriented IO(s) is/are created for representing WoT-T-1 through Step 3, the WSIE will also subscribe to the interworking-oriented IO(s) in order to monitor any CRUD operation on it/them since it will trigger WSIE to contact WoT-S-1 to conduct the real interworking process. In the meantime, WSIE will also keep a local copy of the original TD of WoT-T-1 which needs to be referred to during the real interworking process. For example, once WSIE is informed by a notification that a SL-compliant user has accessed the SL resource representing a property of WoT-T-1, the WSIE will refer to the original TD of WoT-T- 1 and contact WoT-S-1 to access this property of WoT-T-1 in the WoT-compliant system on behalf of this SL-compliant user and finally get back the result which realizes a real interworking process. In addition, WSIE will also record all the necessary information as logs in order to support future actions. In general, this step also applies to the similar scenarios as introduced in the later sections.

[0177] Step 5: The WSIE acknowledges to WoT-S-1 that WoT-T-1 is already available in the SL-compliant System. The message may include the following new parameters:

[0178] IO Action Result (action): This information indicates whether the action being required has been processed successfully.

[0179] Charging-related information (chr): It is possible that WSIE may charge certain costs for a IO creation operation or WSIE may charge any future interworking requests related to IOs created by this IO creation operation, therefore, this parameter can be used to include any charging related information. This parameter may also be carried in any other response message similar to this one discussed in more detail below.

[0180] In addition, the original TD can be updated by WoT-S-1 (which will record the address of SL interworking oriented IO(s) for representing this TD as well for the WoT-T-1). Then in future, WoT-S-1 can use those addresses to contact WSIE directly when it is needed to update or delete those interworking-oriented IOs (this alternative will also apply to all other similar cases in the later sections). 2. 10 Creation Initiated by WSIE through Proactive TD Discovery

[0181] According to another aspect, when a WoT Thing becomes available in the WoT- compliant system, it is associated with a specific WoT Servient as its representation, and its TD may be published to a TDR. In this case, the WoT Servient is not involved in any 10 creation- related activities and just acts as a normal WoT Servient. Instead, WSIE can proactively conduct TD discovery in the TDR in order to decide which WoT Things it would like to also make available in the SL-compliant system. Figure 20 illustrates the proposed procedure for creating interworking-oriented IO(s) in the SL-compliant system for a WoT-compliant thing and it's TD, which is initiated by the WSIE through proactive TD discovery. As a pre-condition, the entities in both the WoT-compliant and SL-compliant system know the existence of WSIE. The WSIE already has the detailed rules/policies regarding how to conduct information model or resource mapping between those two systems. The following steps in Figure 20 are denoted by Arabic numerals.

[0182] Step 1 : WSIE intends to proactively discover available TDs in a TD Repository (TDR-1) in WoT-compliant System.

[0183] Step 2: WSIE sends a TD discovery request to TDR-1 in the WoT-compliant system. The message may include the following new parameter:

[0184] Interested TD Type (itt): This information indicates what types of TDs are interested by WSIE.

[0185] Step 3 : TDR-1 conducts normal TD discovery processing and yields the discovered TDs based on the discovery criteria sent from WSIE (A new attribute can also be defined in TD in order to indicate whether this TD should be made available in another system, accordingly the TD discovery will only return the TDs that indicate that they can be made available in another system).

[0186] Step 4: TDR-1 sends back the discovered TDs to WSIE. The message may include the following new parameter:

[0187] Interested TD List (itl): This information includes a list of discovered TDs.

[0188] Step 5 : For each of discovered TDs, WSIE analyzes it and decides which interworking- oriented IO(s) will be created in the SL-compliant system for representing each of interested WoT Thing and its TD. This step is the same as Step 3 of Figure 15. For the interworking- oriented IO to be created, it could have the following options: [0189] Option 1. Transparent Interworking

[0190] Option 2. Resource Mapping

[0191] Option 3. HAEVI Representation

[0192] Option 4. Semantic Descriptor Representation

[0193] Option 5. Base Ontology Representation

[0194] Step 6: This step is the same as Step 4 of Figure 15. Once interworking-oriented IO(s) is/are created for an interested WoT Thing, the WSIE will also subscribe to the interworking- oriented IO(s) in order to monitor any CRUD operation on them (since it will trigger WSIE to conduct the real interworking process). In the meantime, WSIE will also keep a local copy of the original TD of this WoT Thing which needs to be referred to, during the real interworking process.

3. IO Creation Initiated by WSIE through TD Subscription

[0195] According to yet another embodiment, when a WoT Thing becomes available in the WoT-compliant system, it is associated with a specific WoT servient as its representation and its TD may be published to a TDR. In this case, the WoT Servient is not involved in any IO creation-related activities and just acts as a normal WoT Servient. Instead, WSIE can proactively conduct TD discovery in the TDR in order to decide which WoT Things it would like to also make available in the SL-compliant system. However, sometimes it is possible that WSIE does not discover any interested TDs that are available in the TDR. Accordingly, instead of conducting frequent TD discovery in TDR, WSIE may send a TD subscription request to TDR with a list of its interested types of TDs. Accordingly, WSIE will be notified once new TDs become available in TDR and fall into the TD interest list of WSIE.

[0196] Figure 21 illustrates the proposed procedure for creating interworking-oriented IO(s) in the SL-compliant system for a WoT-compliant Thing and its TD initiated by WSIE through TD subscription. The steps are denoted by Arabic numerals. As a pre-condition, the entities in both WoT-compliant and SL-compliant systems know the existence of WSIE. The WSIE already has the detailed rules/policies regarding to how to conduct information model or resource mapping between those two systems.

[0197] Step 1 : WSIE is interested in a list of desired types of WoT Things and WSIE intends to make them also available in the SL System once those things becomes discoverable in TD Repository (TDR-1) in the WoT-compliant System. [0198] Step 2: WSIE sends a TD subscription request to TDR-1 in the WoT-compliant system with a TD interest list. The message may include the following new parameter:

[0199] Interested TD Type (itt): This information indicates what types of TDs are interested by

WSIE.

[0200] Step 3 : TDR-1 accepts the TD subscription request sent from WSIE. At time t, a new TD of a WoT Thing (WoT-T-1) becomes available in TDR-1. In particular, TDR-1 finds that this TD is interested by WSIE.

[0201] Step 4: TDR-1 sends a notification to WSIE, along with the ID of this newly-available TD. Alternatively, TDR-1 may directly send the whole TD to WSIE. The message may include the following new parameter:

[0202] Interested TD List (itl): This information includes a list of TDs that just became available in TDR. This option is used in this step if there are multiple TDs that just became available in TDR and needs to inform WSIE. If there is an attribute defined in a TD which indicates whether this TD wants to be made available in another system, then once this TD is published to the TDR-1, TDR-1 will directly send a notification to WSIE as Step 4 even if WSIE did not make a subscription to the TDR-1.

[0203] Step 5: WSIE sends a TD retrieval request to TDR-1 in order to retrieve the interested TD. The message may include the following new parameter:

[0204] Required TD List (rtl): This information includes a list of TDs that need to be retrieved by WSIE.

[0205] Step 6: TDR-1 sends back the required TD to WSIE.

[0206] Step 7: For a retrieved TD (e.g., the TD of WoT-T-1), WSIE analyzes it and decides which interworking-oriented IO(s) will be created in the SL-compliant system for representing

WoT-T-1 and its TD. This step is the same as Step 3 of Figure 15. For the interworking-oriented

IO to be created, it could have the following options:

[0207] Option 1. Transparent Interworking

[0208] Option 2. Resource Mapping

[0209] Option 3. HAEVI Representation

[0210] Option 4. Semantic Descriptor Representation

[0211] Option 5. Base Ontology Representation [0212] Step 8: This step is the same as Step 4 of Figure 15. Once interworking-oriented IO(s) is/are created for WoT-T-1 and its TD, the WSIE will also subscribe to the interworking-oriented IO(s) in order to monitor any CRUD operation since it will trigger WSIE to conduct the real interworking process. In the meantime, WSIE will also keep a local copy of the original TD of WoT-T-1 which is needed during the real interworking process. Figure 21 provides a procedure for creating Interworking-oriented IO(s) in The SL-compliant system for A WoT-compliant Thing and its TD (10 Creation Is Initiated by WSIE Through TD Subscription).

B. 10 Creation (from SL-compliant system to WoT-compliant system)

1. 10 Creation Initiated by SL- RP or SL- RH

[0213] According to an embodiment, when a SL native resource provider e.g., a SL-compliant Native Resource Provider (SL-NRP-1), is deployed in the SL-compliant System, it may first register to a SL node. Accordingly a resource representing SL-NRP-1 will be created. During this registration process, the SL-NRP may proactively indicate whether it also wants to be available in other systems such as WoT-compliant system. Accordingly, once the resource is created for representing SL-NRP-1 after registration, WSIE can be contacted in order to create a TD for describing <SL-NRP-1> and this TD can be published to the WoT-compliant system in order to support interworking. Figure 22 illustrates the proposed procedure for creating an interworking-oriented 10 in the WoT-compliant system for a SL-compliant NRP and its SL resource representation (which is proactively initiated by SL-NRP or SL-NRH). Each of the steps in denoted by an Arabic numeral. As a pre-condition, the entities in both the WoT- compliant system and SL-compliant system know the existence of WSIE. The WSIE already has the detailed rules/policies regarding to how to conduct IM alignment or resource mapping between those two systems.

[0214] Step 1 : SL-NRP-1 (e.g., a SL-compliant Thing) intends to register to SL-NRH-1 and also wants to make itself available in the WoT-compliant System. The message may include the following new parameter:

[0215] Participate Interworking (pi): This information indicates whether SL-NRP-1 is willing to be available in another system, e.g. in WoT-compliant System, in order to support

interworking.

[0216] Step 2: SL-NRP-1 sends registration request to SL-NRH-1. [0217] Step 3 : SL-NRH-1 processes the request from SL-NRP-1, and if the registration request is allowed, SL-NRH-1 will create a resource representation for SL-NRP-1, e.g. called <SL-NRP-

1>. Alternatively, a quick registration response could be sent to SL-NRP-1 immediately after

Step 3. In particular, the types of <SL-NRP-1> may have the following options:

[0218] Option 1. If SL-NRP-1 is a HAEVI device, <SL-NRP-1> will have a HAEVI resource representation;

[0219] Option 2. If SL-NRP-1 is just a normal SL-compliant device, it will have a normal SL resource representation, the resource type of <SL-NRP-1> could be a <AE>. In the meantime, <semanticDescriptor> child resource(s) can also be created under <SL-NRP-1> as well, which includes the semantic descriptions of SL-NRP-1.

[0220] Step 4: If SL-NRP-1 also indicated that it wants to be available in other systems, such as a WoT-compliant system, SL-NRH-1 will need to contact WSIE. In particular, since SL is resource-oriented, making SL-NRP-1 itself available in the WoT-compliant system is equal to making its resource representation (i.e., <SL-NRP-1>) available in the WoT-compliant system. Alternatively, if SL-NRP-1 did not indicate that it wants to be available in other system, the SL- NRH-1 itself can also make such a decision. In this case, SL-NRP-1 is not involved in any IO creation related activities.

[0221] Step 5: SL-NRH-1 sends a request message to WSIE, which indicates that a SL resource <SL-NRP-1> representing a SL-compliant device needs to be available in the WoT-compliant System. In the meantime, the URI of <SL-NRP-1> will be included in the request message. Alternatively, SL-NRP-1 can send such a request message to WSIE as well. The message may include the following new parameters:

[0222] IO Action (action): This information indicates what action is being required. For example, in this case, the action will be "IO creation".

[0223] Target Resource (tr): This information indicates what resource is going to be available in the WoT-compliant System. For example, the URI of <SL-NRP-1> will be included in this parameter.

[0224] Step 6: WSIE analyzes the request sent from SL-NRH-1 as well as the information included in the request message. If it allows <SL-NRP-1> to be available in the WoT-compliant system, it will determine which information needs to be collected in order to create a valid TD for representing <SL-NRP-1>. [0225] Step 7: Using the resource URI of <SL- RP-1> and/or other target resource URIs contained in Step 5, WSIE will access the corresponding resource representation hosted by SL- RH-1 in order to collect all the related information needed for creating a TD (e.g., by assessing the attributes or child resources of <SL- RP-1>). This step may be repeated multiple times.

[0226] Step 8: Based on the collected information, WSIE will create a TD for describing <SL- RP-1> and/or its child resources, according to the detailed rules/policies of IM alignment and resource mapping between the two systems. In general, two specific interworking

implementation scenarios are discussed below, which will affect the details of the created TD:

[0227] Interworking Implementation Scenario 1 : In this scenario, WSIE is responsible for the IO creation/update/deletion processes (i.e., only the process that are related to interworking-oriented IO lifecycle management). Other than that, WSIE and/or other entity (such as IPE as defined in oneM2M) will not be involved in any process related to how a WoT client will interact with or access a SL resource representing a SL-compliant thing. For example, assuming that a created TD (which is as an interworking-oriented IO representing <SL-NRP-1>) was already made available in the WoT-compliant system. For a given WoT client, if it discovers this TD, it can directly interact with <SL- RP-1> (e.g., access this resource) without relying on WSIE (or any other entity such as IPE as defined in oneM2M). In order to show how this can be done, an example is given in the oneM2M context: In this solution, oneM2M nodes are directly exposed as WoT Servients (i.e., in the server role) based on the metadata description of WoT TD. Then, a native WoT Servient in the WoT-compliant system (i.e. in the client role) can directly interact with the oneM2M nodes and consume the services and data provided by the oneM2M service layer via Mca/Mcc reference point. Under this approach, a WoT Servient in the WoT-compliant system in fact becomes oneM2M compliant and consumes oneM2M interfaces according to the WoT TD, which describes the access details of the oneM2M interfaces. Here, the key is that as long as the oneM2M resource model and protocol bindings can be well expressed in WoT TD, a CSE then can be modelled as a WoT Servient (as Server) and interact with a native WoT Servient (as Client) based on the WoT specifications. From oneM2M perspective, the WoT Servient (Client) in the WoT-compliant system in this case will act as either an AE or CSE depending on whether Mca or Mcc is used (although this WoT client itself may not even know that its access behaviors make it act as a oneM2M AE or CSE). Similarly, an oneM2M AE/CSE also may not know that it has been modeled as a WoT servient (as server) in a TD (which is an interworking-oriented 10). In addition, it is possible that many AEs may register to the same CSE, and each of those AEs is a SL-compliant thing (e.g., one is a SL-compliant temperature sensor and another is a SL-compliant humidity sensor). Accordingly, a simple/preferred way is that an individual TD will be created for each of those AEs and they will be exposed to the WoT- compliant system. Another solution is that a single giant TD will be created for this CSE, which describes all the resources hosted by this CSE (or all the AEs registered to this CSE). In this scenario, the created TD (as interworking-oriented 10) can either be directly hosted by the CSE (since CSE can be modeled as a WoT servient in this scenario, and accordingly this CSE can be a TD Host) or can be published to a TDR in the WoT compliant system as introduced in a later step.

[0228] Interworking Implementation Scenario 2: In this scenario, WSIE is still responsible for the 10 creation/update/deletion processes. Beyond that, WSIE or other entity (such as oneM2M IPE) will be involved in the process related to how a WoT client will interact with or access a SL resource representing a SL-compliant thing in a later time. In this case, for a given WoT client, if it discovers a TD representing a SL resource <SL- RP-1>, it will not interact with <SL- RP-1> directly (e.g., access this resource) but need to rely on WSIE (or any other entity such as IPE as defined in oneM2M) acting as an intermediate entity (there are following alternative cases: 1. WSIE is responsible for not only 10 lifecycle management, but also for the real interworking access; 2. WSIE and IPE are implemented as two entities. WSIE is responsible for 10 lifecycle management, and IPE is responsible for the real interworking access; 3. IPE is the major interworking physical entity and WSIE is implemented as a feature of IPE. In this case, IPE then is responsible for not only 10 lifecycle management, but also for the real interworking access.). In other words, when this WoT client in the WoT-compliant system wants to access <SL- RP- 1> resource in the SL-compliant system, it will send its access request towards WSIE (or IPE), and then WSIE will further act as an intermediate proxy to conduct the real resource access action on <SL- RP-1> in the SL-compliant system and finally return the resource access result to the WoT client in the WoT-compliant system. When compared to Step 3 of Figure 15 in which IOs are created in the SL-compliant system for representing a WoT Thing and TD, this step is the reverse process. For example, since <SL- RP-1> will be represented as a WoT-Thing in the WoT-compliant system, it is also necessary that the base URI or address in the TD of the <SL- RP-1> needs to be set with an address of a WoT-Servient, instead of directly using the URI of <SL- RP-1> since the URI of <SL- RP-1> is the access address for the SL-compliant users in the SL-compliant system. One simple solution is that since WSIE can also act as a WoT Servient in the WoT-compliant System, WSIE can directly provide a base URI to be specified in the created TD for <SL- RP-1>. For example, the base URI can be constituted of the WSIE's address as prefix plus the URL of <SL- RP-1> like "<WSIE-Address>/<SL-NRP-1>".

[0229] Alternatively, WSIE can also help in finding another WoT-Servient (e.g., WoT Servient 2) if it can provide a base URI to be specified in the created TD for <SL- RP-1>. In the latter case, if some access requests are sent to the base URI as specified in the created TD for <SL- RP-1>, once WoT Servient-2 captures those requests over the WoT interface, the App script on Servient-2 may further forward the requests to WSIE since it will be the WSIE to conduct any CRUD operations on the resource <SL- RP-1> in the SL-compliant system to finally realize the interworking process.

[0230] Step 9: WSIE publishes the created TD representing <SL- RP-1> to the TD Repository TDR-1.

[0231] Step 10: TDR-1 acknowledges that the TD is available in the WoT-compliant system.

[0232] Step 11 : WSIE will create a <subscription> child resource under <SL- RP-1> so that WSIE will be notified if any change/update is conducted on this resource and its child resources. Then it can make update to its corresponding TD being created in WoT-compliant system and stored in TDR-1.

[0233] Step 12: WSIE acknowledges that <SL- RP-1> is now also available in the WoT- compliant System.

[0234] Step 13 : SL- RH-1 acknowledges the successful registration of SL- RP-1 and that it is now also available in the WoT-compliant system (if the IO creation process is initiated by SL- NRP-1). The message may include the following new parameter:

[0235] IO Action Result (action): This information indicates whether the action being required has been processed successfully. Even if the IO creation fails, it is also possible that the <SL- NRP-1> was created successfully. For different cases, various codes can be defined for this parameter, which is up to the implementation.

2. IO Creation Initiated by WSIE Through Proactive Resource Discovery

[0236] According to yet another embodiment, when a SL native resource provider (SL-NRP-1) is deployed in the SL-compliant system, it will register to a SL node. Accordingly a resource representing SL- RP-1 will be created, called <SL-NRP-1>. In this case, SL- RP-1 is not involved in any 10 creation-related activities. Instead, WSIE can proactively conduct SL resource discovery in the SL-compliant system to identify interested SL resources that it would like to make available in the WoT-compliant system. Figure 23 illustrates the proposed procedure for creating an interworking-oriented 10 in the WoT-compliant system for a SL- compliant thing and its SL resource representation which is proactively initiated by WSIE through SL resource discovery. Each step is denoted by an Arabic numeral. A pre-condition for this procedure is that entities in both WoT-compliant system and SL-compliant system know the existence of WSIE. The WSIE already has the detailed rules/policies regarding how to conduct IM alignment or resource mapping between those two systems. Here, SL-NRP-1 is already registered with SL-NRH-1 and the name of its resource representation is <SL-NRP-1>.

[0237] Step 1 : WSIE sends a normal resource discovery request to SL-NRH-1. It is also possible a new attribute can be defined for <SL-NRP-1> which indicates whether it would like to be made available in another system. Accordingly, if such an attribute is available, new filtering criteria can also be defined for resource discovery so that discovery will only focus on those particular resources. In general, WSIE can do periodical resource discovery as did in Step 1 or WSIE can make some subscriptions so that every new resource registration will trigger a notification sent to WSIE.

[0238] Step 2: SL-NRH-1 processes the request from WSIE, and identifies a list of discovered resource URIs based on the filterCriteria sent from WSIE.

[0239] Step 3 : SL-NRH-1 sends back the discovered URIs to WSIE, in which the URI of <SL- NRP-1> is included for example.

[0240] Step 4: WSIE is interested in <SL-NRP-1> and decides to access this resource to get more information.

[0241] Step 5: WSIE accesses resource <SL-NRP-1> and collects related information from the resource attributes of <SL-NRP-1> as well as its child resources if they exist. This step may be repeated for multiple times.

[0242] Step 6: Based on the collected information, WSIE creates a WoT TD for describing <SL- NRP-1> and/or its child resources. This step is similar to the Step 8 of Figure 22, which covers the solutions to two interworking implementation scenarios. [0243] Step 7: WSIE publishes the created TD for representing <SL- RP-1> to the WoT TD Repository TDR-1.

[0244] Step 8: TDR-1 acknowledges that the TD is already available in the WoT system.

[0245] Step 9: WSIE will create a <subscription> child resource under <SL- RP-1> so that WSIE will be notified if any change/update is conducted on this resource and its child resources if exist.

[0246] It is envisaged in this embodiment that SL- RP-1 can also initiate the procedure after registration.

II. Procedures for Interworking-oriented IO Update under Architecture- 1

A. IO Update (from WoT-compliant system to SL-Compliant System)

[0247] According to an embodiment, an IO update process on the direction from the WoT- compliant system to the SL-Compliant system is described.

1. IO Update Initiated by WoT Servient

[0248] After a WoT Thing (WoT-T-1) is already available in the SL-compliant system, there may be some reconfigurations or setting on it (e.g., adding a new action), which also leads to update in its TD. Accordingly, its corresponding interworking-oriented IO in the SL-compliant system also needs to be modified in order to reflect this update. Figure 24 illustrates the proposed procedure for updating interworking-oriented IO(s) in the SL-compliant system for a WoT- compliant thing and its TD which is initiated by a WoT Servient. Each step is denoted by an Arabic numeral. As a pre-condition, A WoT Thing (WoT-T-1) is associated with a WoT Servient (WoT-S-1). Previously, WoT-S-1 contacted WSIE to make WoT-T-1 available in the SL- compliant system. With the help of WSIE, WoT-T-1 and its TD were made available in the SL- compliant system.

[0249] Step 1 : WoT-T-1 has just undergone some re-configurations or setting, and accordingly, its TD also got updated due to the reconfigurations.

[0250] Step 2: WoT-S-1 needs to inform WSIE that the TD of WoT-T-1 has been updated.

[0251] Step 3 : WoT-S-1 sends the updated TD of WoT-T-1 to WSIE. Alternatively, it could just only send an update summary to WSIE (e.g., the list of existing TD metadata with their new values or a list of new TD metadata with values). The message may include the following new parameters:

[0252] TD ID (td id): This information indicates which TD has undergone an update. [0253] 10 Action (action): This information indicates what action is being required. For example, in this case, the action will be "10 update".

[0254] TD Update Summary (td us) : This information includes the update summary of this TD.

[0255] Step 4: WSIE receives the TD update from WoT-S-1. It first checks which interworking- oriented IO(s) is/are representing WoT-T-1 and its TD. Depending on how the corresponding interworking-oriented IO(s) was/were created, the WSIE will have different actions.

[0256] According to a first option (Transparent Interworking), if WoT-S-1 sent a whole updated TD, then WSIE will create a new <contentInstance> resource in order to store the updated TD. Alternatively, if WoT-S-1 only sent an update summary, then WSIE will first retrieve the old TD of WoT-T-1 stored in an <contentInstance> resource. It will then interpret this TD and make corresponding modifications on this copy based on the update summary. Subsequently, WSIE will create a new <contentInstance> resource to store the updated TD. In regards to the interworking-oriented IO representing WoT-T-1 itself, if a new addition (e.g., a new "property") was added to the TD of WoT-T-1, a new child resource will be created in the existing

interworking-oriented IO representing WoT-T-1 in order to reflect this new addition.

[0257] According to a second option (Resource Mapping), based on the update sent from WoT- S-l, the WSIE will perform the following steps: (1) decide whether the resource structure of the existing interworking-oriented IO(s) for representing WoT-T-1 and its TD need to be modified. For example, if a new "property" was added to the TD of WoT-T-1, a new <TD-property> resource will be created in the existing interworking-oriented IO representing the TD of WoT-T- 1. A new <AE> or <flexContainer> resource will be created in the existing interworking- oriented IO representing WoT-T-1 itself; and (2) if the resource structure is the same as before, and the update is mainly related to parameter value changes, then WSIE just needs to update the values of the corresponding attributes of those SL specialized resources representing WoT-T-1 and its TD.

[0258] According to a third option (HAIM Representation), the following two cases are possible when an integrated interworking-oriented IO for representing WoT-T-1 and its TD was created based on HAIM (i.e., both WoT-T-1 and its TD are represented by a SL HAIM device in the SL- compliant system). In Case, 1, if the update is mainly related to parameter value changes, then WSIE just needs to update the values of the corresponding attributes of the SL HAFM resources representing WoT-T-1. In Case 2, if the update on TD requires changing the resource structure, WSIE will create new interworking-oriented IO(s) to represent WoT-T-1 and its TD by using a different IM other than HAIM. Namely, the resource structure of HAIM device is normally standardized and should not be modified.

[0259] According to a fourth option (Semantic Descriptor Representation), the WoT-T-1 is represented as a normal SL resource (such as <AE> or <flexContainer>) and the information stored in its TD is stored in the <semanticDescriptor> child resource(s). Similar to Option 2, based on the update sent from WoT-S-1, the WSIE will perform the step of deciding whether the resource structure of the existing interworking-oriented IO(s) for representing WoT-T-1 and its TD need to be modified (Step 1). For example, if a new property was added to the TD of WoT- T-l, a new child <AE> or <flexContainer> resource will be created and added to the existing interworking-oriented 10 for representing WoT-T-1 to reflect this newly-added property. The RDF triples stored in the <semanticDescriptor> child resources will also be modified in order to reflect the update in the TD. In Step 2, if resource structure is the same as before, and the update is mainly related to parameter value changes, then WSIE will perform a partial update on the RDF triples stored in the child <semanticDescriptor> resources in order to reflect the TD update.

[0260] According to a fifth option (Base Ontology Representation), there is no need to modify existing interworking-oriented IO(s) for representing WoT-T-1 if the changes are WoT-specific. In this case, the abstracted device resource representation is used for representing WoT-T-1, which does not expose system-specific details. In addition, for the local/internal TD copy used for realizing the real interworking process, the WSIE will also keep an updated TD and replace the old one.

[0261] Step 5: The WSIE acknowledges to WoT-S-1 that the update regarding to the TD of WoT-T-1 was already reflected in the SL-compliant system. The message may include the following new parameters:

[0262] IO Action Result (action): This information indicates whether the action being required has been processed successfully.

B. IO Update Initiated by WSIE Through Periodical TD Discovery /Freshness Check

[0263] According to another embodiment, after a WoT Thing (WoT-T-1) is already available in the SL-compliant system which was initialized by WSIE through TD discovery, there may be some reconfigurations or settings on WoT-T-1 (e.g., adding a new action) which also leads to updates in its TD. In this case, WoT-T-1 may publish its updated TD to the TD repository. Previously WoT-T-1 was not involved in the 10 creation. WSIE still needs to periodically conduct TD discovery in order to see if any TD gets updated. If so, their corresponding interworking-oriented IOs in the SL-compliant system also need to be modified in order to reflect the update. Figure 25 illustrates the proposed procedure for updating interworking- oriented IO(s) in the SL-compliant system for a WoT-compliant thing and its TD which is initiated by WSIE through TD discovery. The steps are denoted by Arabic numerals. As a precondition, the entities in both the WoT-compliant system and SL-compliant system know the existence of WSIE. The WSIE already has the detailed rules/policies regarding to how to conduct IM alignment or resource mapping between those two systems. Previously the WSIE already discovered a list of TDs from TDR-1 and made them available in the SL-compliant system. For example, a WoT Thing (WoT-T-1) is available now in the SL-compliant system initiated by WSIE through TD discovery. At some time t, WoT-T-1 gets reconfigurations and accordingly updated its TD published to TDR-1.

[0264] Step 1 : WSIE intends to conduct a freshness check to see whether any TD that was made available in the SL-compliant system gets any update since last check.

[0265] Step 2: WSIE sends a list of IDs of TDs, as well as their current versions held by WSIE, to TDR-1 in order to check their freshness. The message may include the following new parameter:

[0266] Freshness Check TD List (fctdl): This information indicates which TDs need to be checked in TDR in order to see whether there is fresher version.

[0267] Step 3 : TDR-1 checks each of TDs as required by WSIE, and if a fresher version is available, it will be sent back to WSIE. For example, TDR-1 finds that the TD of WoT-T-1 has a newer version since last check.

[0268] Step 4: TDR-1 sends back a list of TDs that are fresher than that currently hold by WSIE, including the TD of WoT-T-1 for example. The message may include the following new parameter:

[0269] Fresher TD List (fctdl): This information indicates which TDs have fresher version in TDR.

[0270] Step 5 : This step is the same as Step 4 of Figure 24. For each received TD (e.g., the TD of WoT-T-1), the WSIE checks which interworking-oriented IO(s) is/are representing WoT-T-1 and its TD. Depending on how the corresponding interworking-oriented IO(s) was/were created, the WSIE will have the different actions. In addition, WSIE will also keep a local/internal copy of the updated TD of WoT-T-1 in order to replace the old one.

10 Update (from SL-compliant system to WoT-compliant system)

[0271] According to yet a further embodiment, an 10 update process on the direction from the SL-compliant system to the WoT-compliant system is described. After a SL native resource provider (SL- RP-1) registers with the SL-compliant System, its resource representation may undergo certain updates due to any CRUD resource operations. Accordingly, if the resource representation of SL-NRP-1 (<SL-NRP-1>) was also made available in the WoT-compliant system for supporting interworking, the corresponding interworking-oriented 10 in terms of a TD describing <SL-NRP-1> also needs to be updated in order to reflect any updates. In particular, no matter how the 10 creation was initiated, either via a SL-NRP or a SL-NRH, a <subscription> was made by WSIE itself to the <SL-NRP-1> during the 10 creation to monitor any updates on this resource. Accordingly, WSIE will take care of all 10 updates related to processing.

[0272] Figure 26 is an exemplary embodiment that illustrates the proposed procedure for updating an interworking-oriented 10 in the WoT-compliant system for a SL-compliant NRP and its SL resource representation. Each step is denoted by an Arabic numeral. As a pre-condition, the entities in both the WoT-Compliant system and the SL-Compliant system know the existence of WSIE. The WSIE already has the detailed rules/policies regarding how to conduct IM alignment or resource mapping between those two systems. A SL native resource provider SL- NRP-1 has already registered itself with SL-NRH-1 by creating its resource representation <SL- NRP-1> on SL-NRH-1. <SL-NRP-1> has already been made available in the WoT-compliant system. In addition, WSIE has also created a <subscription> child resource under <SL-NRP-1> in order to monitor any change/update on this resource. The trigger includes <SL-NRP-1> being updated by some entities causing a notification trigger being sent to WSIE. Another alternative is that the SL-NRP-1 may proactively contact WSIE for its updates instead of creating a

<subscription> child resource under <SL-NRP-1>.

[0273] Step 1 : SL-NRH-1 sends a notification about the change on <SL-NRP-1> to WSIE.

[0274] Step 2: WSIE receives the notification and needs to collect the latest resource representation of <SL-NRP-1>. [0275] Step 3 : WSIE accesses the resource <SL- RP-1> hosted on SL- RH-1 in order to collect latest representation of this resource. This step may be conducted multiple times.

[0276] Step 4: WSIE analyzes the collected information, and evaluates whether it needs to further make updates to the interworking-oriented 10 in the WoT-compliant System, i.e., the TD representing <SL- RP-1> in the WoT-compliant system. For example, if a new child resource was created under <SL-NRP-1> which is representing a new function/operation of SL-NRP-1, the TD representing <SL- RP-1> in the WoT-compliant system will also need to be updated to reflect this newly-added function. As a result, an updated TD will be created by WSIE for representing the latest status of <SL- RP-1>.

[0277] Step 5 : WSIE publishes the updated TD to the TDR-1 and replace the old one.

[0278] Step 6: TDR-1 acknowledges that the updated TD is now available in the repository and it also replaced the old one.

III. Procedures for Interworking-oriented IO Deletion under Architecture- 1

[0279] According to a further embodiment, IO deletion processes under Architecture- 1 are described.

A. IO Deletion (from WoT-compliant system to SL-Compliant System)

1. IO Deletion Initiated by WoT Servient

[0280] A WoT Thing (WoT-T-1) is already available in the SL-compliant system and was initiated by a WoT Servient (WoT-S-1). After sometime, WoT-S-1 may decide that WoT-T-1 will not be available soon, and accordingly the created interworking-oriented IO(s) that represent WoT-T-1 and its TD in the SL-compliant system may also need to be deleted. Figure 27 illustrates an exemplary embodiment for deleting interworking-oriented IO(s) in the SL- compliant system for a WoT-compliant thing and its TD initiated by a WoT Servient. Each of the steps is denoted by an Arabic numeral.

[0281] Step 1 : WoT-S-1 decides that WoT-T-1 will not be available soon. Accordingly, WoT-S- 1 informs WSIE about this change.

[0282] Step 2: WoT-S-1 sends a message to WSIE and requires deleting the interworking- oriented IO(s) representing WoT-T-1 and its TD in the SL-compliant system. The message may include the following new parameters: [0283] WoT Thing ID (wot id): This information indicates which WoT Things' corresponding interworking-oriented IOs (representing them and their TDs) in the SL-compliant system are to be deleted.

[0284] 10 Action (action): This information indicates what action is being required. For example, in this case, the action will be "10 deletion".

[0285] Step 3 : WSIE receives the notification from WoT-S-1, and accordingly, it will delete the corresponding interworking-oriented IO(s) representing WoT-T-1 and its TD.

[0286] Step 4: WSIE acknowledges to WoT-S-1 that WoT-T-1 is not available anymore in the

SL-compliant System. The message may include the following new parameters:

[0287] IO Action Result (action): This information indicates whether the action being required has been processed successfully.

B. IO Deletion Initiated by WSIE Through Periodical TD Discovery/Freshness Check

[0288] In another embodiment, it is assumed a WoT Thing (WoT-T-1) is already available in the SL-compliant system initialized by WSIE through TD discovery. After some time, WoT-T-1 may decide not to be available anymore by deleting its TD from the TD repository. Previously WoT-T-1 was not involved in IO creation. WSIE needs to periodically conduct TD discovery in order to see if any TD gets deleted. If so, their corresponding interworking-oriented IOs in the SL-compliant system also need to be deleted. The procedure proposed above for IO updates may be employed here.

1. IO Deletion (from SL-compliant system to WoT-compliant system)

[0289] According to a further embodiment, assuming a SL native resource provider e.g., a SL- compliant Thing (SL-NRP-1) registered in the SL-compliant System, after some time may delete its SL resource representation (<SL-NRP-1>). If <SL-NRP-1> was available in the WoT- compliant system, the corresponding interworking-oriented IO in terms of the TD describing <SL-NPvP-l> in the WoT-compliant system also needs to be deleted. The procedure proposed above for IO updates may be employed here.

[0290] Alternatively, the following mechanisms are proposed for IO deletion. For example, a time period (timer) can be set up when WSIE is creating IOs in the SL-compliant system to represent a WoT thing and TDs. Accordingly, these IOs will only be valid during that time period as specified by the timer. After the timer expires, the IOs in the SL-compliant system becomes invalid and can be automatically deleted. [0291] In yet another alternative, a time period (timer) can be set up when WSIE is creating IOs (e.g. TDs) in the WoT-compliant system to represent SL-compliant things. These TDs will only be valid during that time period as specified by the timer. After timer expires, the TDs in the WoT-compliant system becomes invalid and can be automatically deleted.

Interworking-oriented 10 Lifecycle Management under Architecture-2

[0292] Architecture-2 as exemplarily shown in Figure 13 involves some new entities in addition to the entities already mentioned in Architecture- 1. These include, for example, a TD Host, SL Resource Host for A WoT Thing (SL-RH-T) and SL Resource Host for A TD (SL-RH-TD). I. Procedures for Interworking-oriented IO Creation under Architecture-2

A. 10 Creation (from WoT-compliant system to SL-Compliant System)

[0293] In Architecture-2, for a given WoT-compliant Thing, if it has a corresponding resource representation in the SL-compliant system (i.e., which is its corresponding interworking-oriented 10), such 10 can be hosted in a different place instead of being co-located with WSIE, i.e., on a SL-RH-T. Similarly, for a given WoT-compliant thing, if its TD has a separate resource representation in the SL-compliant system, such an 10 can be hosted in a different place instead of being co-located with WSIE, or being co-located with the resource representing the WoT Thing itself. The SL resource host that can host an 10 representing a TD is a SL-RH-TD. When WSIE is conducting a specific 10 creation operation, in the case where it is initiated by a WoT servient or by WSIE itself through TD repository, it first decides which interworking-oriented IO(s) is/are to represent a WoT thing and/or its TD. Next, it decides "where" to host those interworking-oriented IO(s) involving additional processing or steps not required in

Architecture- 1. As a result, an embedded procedure is introduced for WSIE to create/deploy interworking-oriented IO(s) on other SL nodes including SL-RH-T or SL-RH-TD. Each of the steps is denoted by an Arabic numeral in Figure 28. As a pre-condition, the WSIE is aware of the candidate SL resource hosts that can host interworking-oriented IO(s) representing a WoT Thing (e.g., SL-RH-T- 1) or can host interworking-oriented IO(s) representing a TD of a Thing (e.g., SL-RH-TD-1).

[0294] WSIE is working on a task to make a WoT Thing (WoT-T-1) and its TD also available in the SL-compliant system. As discussed above, this can be triggered by different cases, e.g., it is either required by a WoT Servient (e.g., WoT-S-1) or the WSIE proactively conducts TD discovery in a TD Repository (TDR-1) in the WoT-compliant system. WSIE decides which interworking-oriented IO(s) to create in the SL-compliant system for representing WoT-T-1 and its TD.

[0295] Step 1 : There are two cases for interworking-oriented IO(s) to be created in the SL- compliant system for representing WoT-T-1 and its TD. In Case 1, the interworking-oriented IO(s) for representing the TD of WoT-T-1 and WoT-T-1 itself are separated and therefore they can be created on different resource hosts. The following options fall under Case 1 :

[0296] Option 1. Transparent Interw or king: WSIE just stores the serialized TD of WoT-T-1 into a <contentInstance> as opaque data. In the meantime, another resource (e.g., a <AE> resource) needs to be created as well in order to represent WoT-T-1 itself. In this case, WoT-T-1 and its TD will have separated interworking-oriented IOs for representing them respectively. In this example, SL-RH-T- 1 may be selected by WSIE to store the 10 representing WoT-T-1 while SL- RH-TD-l may be selected by WSIE to store the IO representing the TD of WoT-T-1.

[0297] Option 2. Resource Mapping: Similar to Option 1, in this case, WoT-T-1 and its TD will have separated interworking-oriented IOs for representing them respectively.

[0298] In Case 2, the interworking-oriented IOs for representing the TD of WoT-T-1 and WoT- T-l itself are integrated together as a whole. As a result, the integrated IO can be created on a selected resource host, e.g., a SL-RH-T. Case 2 includes 5 options.

[0299] Option 1. Transparent Interw or king: WSIE just stores the serialized TD of WoT-T-1 into a <contentInstance> as opaque data. In the meantime, another resource (e.g., a <AE> resource) needs to be created as well in order to represent WoT-T-1 itself. Although in this case, WoT-T-1 and its TD will have separated interworking-oriented IOs for representing them respectively, but they still can be associated together and hosted the same SL node, e.g., a SL- RH-T. For example, the <contentInstance> resource storing the serialized TD can be a child resource of the <AE> resource representing WoT-T-1. Accordingly, in this example, SL-RH-T- 1 may be selected by WSIE to store the IOs representing both WoT-T-1 and its TD.

[0300] Option 2. Resource Mapping: For example, a <WoT-T-l> resource can be created on a SL-RH-T, which is a specialized resource of <flexContainer> to representing a WoT-T-1. In the meantime, the <TD> resource (which is a specialized resource of <flexContainer> to represent the TD of WoT-T-1) can be the child resource of <WoT-T-l>.

[0301] Option 3. HAIM Representation: The information in TD will be extracted and a new resource representing a HAIM device will be created in order to represent both WoT-T-1 itself and also its TD. In this case, WoT-T-1 and its TD will have an integrated interworking-oriented 10 for representing them jointly and then WSIE may choose to create the integrated

interworking-oriented 10 on SL-RH-T-1 for example.

[0302] Option 4. Semantic Descriptor Representation: This option is similar to Option 3.

[0303] Option 5. Base Ontology Representation: This option is similar to Option 3.

[0304] Step 2: Based on the decision made in Step 1 (Case 1 or Case 2), the WSIE will decide where to create corresponding interworking-oriented IOs among all the candidate resource hosts (e.g., WSIE selects SL-RH-T-1 and SL-RH-TD-l in this example), based on a certain host selection algorithm.

[0305] Step 3 : In Case, 1, WSIE sends a request to SL-RH-T-1 in order to create an

interworking-oriented IO representing WoT-T-1 itself. The message may include the following new parameter:

[0306] Flag (flag) : This information indicates the resource to be created is an interworking- oriented IO.

[0307] Step 4: In Case 1, SL-RH-T-1 acknowledges that an interworking-oriented IO for representing WoT-T-1 was already created.

[0308] Step 5: In Case 1, WSIE sends a request to SL-RH-TD-l in order to create an interworking-oriented IO representing the TD of WoT-T-1. The message may include the following new parameter:

[0309] Flag (flag) : This information indicates the resource to be created is an interworking- oriented IO.

[0310] Step 6: In Case 1, SL-RH-TD-l acknowledges that the interworking-oriented IO for representing the TD of WoT-T-1 was already created.

[0311] Step 7: In Case 2, WSIE sends a request to SL-RH-T-1 in order to create an integrated interworking-oriented IO representing WoT-T-1 as well as its TD. The message may include the following new parameter:

[0312] Flag (flag) : This information indicates the resource to be created is an interworking- oriented IO.

[0313] Step 8: In Case 2, SL-RH-T-1 acknowledges that the integrated interworking-oriented IO for representing WoT-T-1 and its TD was already created. [0314] Step 9: In Case 2, WSIE will continue the remaining work once those interworking- oriented IOs were created (for example, WSIE will make a subscription on each of those IOs to monitor any operations on those IOs).

B. 10 Creation (from SL-compliant system to WoT-Compliant System)

[0315] According to yet even a further embodiment, when a SL native resource provider e.g., a SL-compliant Thing (SL- RP-1) is deployed in the SL-compliant system, it may first perform registration to a SL node. A resource representing SL-NRP-1 will be created. Once the resource is created for representing SL-NRP-1 after registration, a TD for describing <SL-NRP-1> can be created and published to the WoT-compliant System. In Architecture-2, the TD can also be published and hosted by a selected TD Host, and also published to a TDR. Similar steps proposed above, for example in relation to Figures 22 and 23, may be performed here.

II. Procedures for Interworking-oriented IO Update under Architecture-2

A. IO Update (from WoT-compliant system to SL-Compliant System)

[0316] According to yet even another embodiment, after a WoT Thing (WoT-T-1) is already available in the SL-compliant system, there may be some reconfigurations or settings on it (e.g., adding a new action), which may lead to update its TD. Accordingly, its corresponding interworking-oriented IO in the SL-compliant system also needs to be modified in order to reflect this update. In Architecture-2, the interworking-oriented IOs can be hosted on a SL-RH-T or on a SL-RH-TD. Accordingly, when WSIE is conducting a specific IO update operation, WSIE first needs to find out which SL resource host(s) is/are hosting the interworking-oriented IOs to be updated. Accordingly, WSIE will need to send update requests to those resource hosts in order to conduct update operations supported by an embedded procedure as exemplarily shown in Figure 29. Each step is denoted by an Arabic numeral. As a pre-condition, WSIE already created interworking-oriented IOs in the SL compliant system for representing a WoT Thing (WoT-T-1) and its TD. The created IOs can be hosted by different SL resource hosts. For example, SL-RH-T- 1 can host the IO representing WoT-T-1 while SL-RH-TD- 1 can host the IO representing the TD of WoT-T-1. WSIE already knows the details of TD update of WoT-T-1 through a freshness check in a TD Repository (TDR-1), or is informed by a WoT Servient (e.g., WoT-S-1). Depending on how the interworking-oriented IOs were created, the WSIE will know what specific actions are to be done on those created interworking IOs. [0317] Step 1 : There are two cases for creating the interworking-oriented IOs. In Case 1, the interworking-oriented IOs for representing the TD of WoT-T-1 and WoT-T-1 itself are separated and not associated with each other. Therefore, their respective IOs are created on different resource hosts. For example, WSIE identifies that the 10 representing WoT-T-1 is hosted by SL- RH-T-1 while the 10 representing the TD of WoT-T-1 is hosted by SL-RH-TD-1. In Case 2, the interworking-oriented IOs for representing the TD of WoT-T-1 and WoT-T-1 itself are integrated together as a whole and therefore the integrated 10 was created on a single resource host. For example, WSIE identifies that the integrated 10 representing WoT-T-1 and its TD is hosted by SL-RH-T-1.

[0318] Step 2: Based on the different cases as mentioned above, the WSIE will send

corresponding resource update requests to the involved resource hosts.

[0319] Step 3 : In Case 1, WSIE sends a request to SL-RH-T-1 in order to update the 10 representing WoT-T-1 itself, in order to reflect update.

[0320] Step 4: In Case 1, SL-RH-T-1 acknowledges that the 10 for representing WoT-T-1 was already updated.

[0321] Step 5: In Case 1, WSIE sends a request to SL-RH-TD-1 in order to update the 10 representing the TD of WoT-T-1.

[0322] Step 6: In Case 1, SL-RH-TD-1 acknowledges that the 10 for representing the TD of WoT-T-1 was already updated.

[0323] Step 7: In Case 2, WSIE sends a request to SL-RH-T-1 in order to update the integrated 10 representing WoT-T-1 and its TD.

[0324] Step 8: In Case 2, SL-RH-T-1 acknowledges that the IOs for representing WoT-T-1 and its TD were already updated.

[0325] Step 9: WSIE will continue the remaining work once those interworking-oriented IOs gets updated.

2. 10 Update (From SL-compliant system to WoT-Compliant System)

[0326] According to another embodiment, an updating from the SL-compliant system to the

WOT-compliant System is described. The procedure is similar to the procedures described above in Figure 26. However, when WSIE needs to update a specific TD, if this TD is hosted by a TD

Host, the WSIE first needs to find which TD Host is hosting the TD to be updated.

III. Procedures for Interworking-oriented 10 Deletion under Architecture-2 A. 10 Deletion (from WoT-compliant system to SL-Compliant System)

[0327] Similar to the 10 Update case, The 10 Deletion procedures are similar to those described above in Figure 29. When WSIE is conducting a specific 10 deletion operation, WSIE needs to find out which SL resource host(s) is/are hosting the interworking-oriented IOs to be deleted. WSIE will need to send deletion requests to those resource hosts in order to conduct deletion operations.

B. 10 Deletion (from SL-compliant system to WoT-Compliant System)

[0328] The 10 Deletion procedures are similar to those described above in Figure 26. The only thing is that when WSIE needs to delete a specific TD, if this TD is hosted by a TD Host, the WSIE first needs to find which TD Host is hosting the TD to be deleted.

Interworking-oriented 10 Lifecycle Management under Architecture-3

[0329] In yet a further embodiment, Architecture-3 describes interworking-oriented 10 lifecycle management. Architecture-3 includes a new entity - WSIM - in addition to the entities already mentioned in Architecture-2. In Architecture-3, there may be multiple WSIEs in the system that can support interworking. Accordingly, WSFM is a manager for coordinating and scheduling all the interworking tasks among multiple WSIEs.

[0330] For all the procedures to be proposed for the 10 Lifecycle management under

Architecture-3, the major methodologies have been described above for Architecture- 1 and Architecture-2. The new embedded procedures introduced in this embodiment govern interactions between the WSIM and WSIEs. As discussed above, WSFM has two major working schemes.

[0331] Scheme-1: WSIM will be the only entity that is exposed to the external entities and all the WSIEs will be internal working entities and all the external entities from WoT-compliant system or SL-compliant system will only communicate with WSFM.

[0332] Scheme-2: All the WSIEs can still directly interact with all the external entities from

WoT-compliant system or SL-compliant System. However, WSIM becomes an internal working entity and all the external entities do not know about the existence of WSIM.

I. Procedures for Interworking-oriented 10 Creation/Update/Deletion (WSIM Working Scheme- i)

A. 10 Creation (Both Directions) [0333] Figure 30 illustrates an exemplary embodiment for performing an 10 Creation by a WSIM for working scheme-1. Each of the steps is denoted by an Arabic numeral. As a precondition, the entities in both the WoT-compliant system and SL-compliant system know the existence of WSIM (WSIEs are internal working entities). The WSIM manages a batch of WSIEs. In particular, for all the interworking-oriented IO lifecycle management related tasks, the entities in both systems will mainly interact with WSIM, which will internally distribute tasks to WSIEs for processing. For a given IO creation request received by WSFM, it could refer to either of the following two directions: 1) to create interworking-oriented IO(s) in the WoT-compliant system for a SL-compliant NRP, or 2) to create interworking-oriented IO(s) in the SL-compliant system for a WoT-compliant Thing and its TD.

[0334] Step 1 : WSIM receives an IO creation request (e.g., Request-1). WSIM will select an appropriate WSIE based on certain WSIE selection or scheduling algorithm. For example, WSIM may select WSIE-1 to process Request-1.

[0335] Step 2: WSIM assign this IO creation request to WSIE-1. The parameters included in this step are the same as those ones defined in the previous sections related to IO creation.

[0336] Step 3 : WSIE-1 receives the task from WSIM to process Request-1, and it starts the processing of this request.

[0337] Step 4: WSIE-1 acknowledges that Request-1 is already processed and WSIE-1 will take care of all the future interworking activities involved with the IOs created for Request-1 (in other words, WSIE-1 will be the "responsible WSIE" for those created IOs). The parameters included in this step are as same as those ones defined in the previous sections related to IO creation.

[0338] Step 5: WSIM will also send an acknowledgement to the sender of Request-1.

[0339] For this procedure, all the external entities in the SL-compliant system and WoT- compliant system will only send their IO creation requests to WSIM. After that, Steps 1-2 and Steps 4-5 of the procedure shown in Figure 30 will be used for interactions between WSFM and WSIE. The processing of Step 3 shown in Figure 30 will be the same as the work performed by WSIE in IO creation-related procedures described above for Architecture- 1 and Architecture-2. The external entities will also get a response from WSFM after Step 5 of the procedure shown in Figure 30.

B. IO Update/Deletion (Both Direction) [0340] An exemplary embodiment as shown Figure 31 illustrates the proposed embedded procedure and the detailed descriptions for performing an 10 Update/Deletion by a WSFM for Working Scheme-1. Each step is denoted by an Arabic numeral. As a pre-condition, the entities in both the WoT-compliant system and the SL-compliant system know the existence of WSIM (WSIEs are internal working entities) and WSFM manages a batch of WSIEs. In particular, for all the interworking-oriented IO lifecycle management related tasks, the entities in both systems will mainly interact with WSIM, which will internally distribute tasks to WSIEs for processing. For a given IO Update/Deletion request received by WSIM, one of the following two directions are employs: 1) to update/delete interworking-oriented IO(s) in the WoT-compliant system for a SL-compliant RP; or 2) to update/delete an interworking-oriented IO(s) in the SL-compliant system for a WoT-compliant Thing and its TD.

[0341] Step 1 : WSIM receives a request (Request-2), and it is related to an Update/Deletion operation on some interworking-oriented IO(s). Then, WSIM will check which WSIE is the responsible WSIE for those IO(s) to be updated/deleted. For example, based on records, WSIM finds that WSIE-2 is the responsible WSIE for the IO(s) to be updated/deleted.

[0342] Step 2: WSIM sends Request-2 to WSIE-2 for processing. The parameters included in this step are as same as those ones defined in the previous sections related to IO update/deletion.

[0343] Step 3 : WSIE-2 receives the task from WSIM and it will update/delete IOs as requested by Request-2. In particular, what WSIE will do during the processing of this step is the same as the work that need to be done by WSIE under Architecture- 1 and Architecture-2.

[0344] Step 4: WSIE-2 acknowledges that Request-2 is already processed and completed.

[0345] Step 5 : WSIM will also send back an acknowledgement to the sender of Request-2.

[0346] For this procedure, all the external entities in the SL-compliant system and WoT- compliant system will perform the following: 1) all the external entities in the SL-compliant system and WoT-compliant system will only send their IO update/deletion requests to WSFM. After that, the Steps 1-2 and Step 4-5 of the procedure shown in Figure 31 will be used for interactions between WSIM and WSIE. In the meantime, the processing of Step 3 of this procedure will be the same as the work that needs to be done by WSIE in all the IO

update/deletion-related procedures proposed for Architecture- 1 and Architecture-2 in the previous sections. The external entities will also get a response from WSIM after the Step 5 of the procedure shown in Figure 31. II. Procedures for Interworking-oriented 10 Creation/Update/Deletion (WSIM Working Scheme- 2}

A. 10 Creation (Both Directions)

[0347] Figure 32 illustrates an exemplary embodiment for performing IO creation by a WSIM for working scheme-2. Each step is denoted by an Arabic numeral. As a pre-condition, the entities in both the WoT-compliant system and the SL-compliant system know the existence of WSIEs (i.e., WSIM is an internal working entity which manages a batch of WSIEs). In particular, for all the interworking-oriented 10 lifecycle management related tasks, the entities in both systems will continue to interact with the WSIE, and the WSIM will act as an internal manager or coordinator. For a given 10 creation request received by WSIE, it could refer to either of the following two directions: 1) to create interworking-oriented IO(s) in the WoT- compliant system for a SL-compliant RP, or 2) to create interworking-oriented IO(s) in the SL- compliant system for a WoT-compliant Thing and its TD.

[0348] Step 1 : WSIE-1 receives an 10 creation request (Request-1). The parameters included in this step are similar to those discussed above related to 10 creation. Step 1 has the following two cases. In case 1, if WSIE-1 has the capacity to process this request, it will start to process Request-1. In case 2, if WSIE-1 is not able to process this request, it will first contact WSFM to find another WSIE to process this request.

[0349] Step 2: In case 1, WSIE-1 starts the processing of Request-1. In particular, what WSIE will do during the processing of this step is the same as the work that needs to be done by WSIE under Architecture- 1 and Architecture-2 described above.

[0350] Step 3 : In case 1, WSIE informs WSIM that it is processing a new Request-1 for supporting interworking.

[0351] Step 4: In case 1, WSFM records the task reporting as working logs sent from WSIE-1, in order to maintain a global workload distribution on different WSIEs.

[0352] Step 5: In case 1, WSFM acknowledges that it already recorded the task reporting from WSIE-1.

[0353] Step 6: In case 2, WSIE-1 sends a request message to WSIM and indicates that there is a new request Request-1 but it cannot process it. Therefore, it needs another WSIE to help. [0354] Step 7: In case 2, WSIM will select an appropriate WSIE based on certain WSIE selection or scheduling algorithm. For example, WSFM may select WSIE-2 to process the Request- 1.

[0355] Step 8: In case 2, WSIM informs WSIE-1 that WSIE-2 can process Request-1.

[0356] Step 9: In case 2, WSIE forwards Request-1 to WSIE-2.

[0357] Step 10: In case 2, WSIE-2 starts the processing of Request-1 (As same as Step 2), and in the meantime, WSIE-2 will also report its workload to WSIM for processing Request-1.

[0358] Step 1 1 : In case 2, WSIE-2 acknowledges that Request-1 is already processed and WSIE- 2 will take care all the future interworking activities involved with the IOs created for Request-1.

[0359] Step 12: WSIE-1 will also send back an acknowledgement to the sender of Request-1.

[0360] As a result, for all IO creation-related procedures in this Architecture-3, the procedures will be embedded such that: 1) all the external entities in the SL-compliant system and WoT- compliant system will send their IO creation requests to a WSIE and the above embedded procedure will be hidden from the external entities used for interactions between WSIM and WSIE. In the meantime, the processing of Step 2 and Step 10 of this procedure shown in Figure 32 will be similar to the work done by WSIE in the IO creation-related procedures proposed for Architecture- 1 and Architecture-2 discussed above.

B. IO Update/Deletion (Both Direction)

[0361] Figure 33 illustrates an exemplary embodiment for performing an IO Update/Deletion by a WSIM for working scheme-2. Each step is denoted by an Arabic numeral. As a pre-condition, the entities in both the WoT-compliant system and SL-compliant system know the existence of WSIEs (WSFM is an internal working entity which manages a batch of WSIEs). In particular, for all the interworking-oriented IO lifecycle management related tasks, the entities in both systems will interact mainly with WSIE, and WSIM is an internal manager or coordinator. For a given IO update/deletion request received by WSIE, it could employ either of the following two cases: 1) to update/delete interworking-oriented IO(s) in the WoT-compliant system for a SL-compliant RP, or 2) to update/delete an interworking-oriented IO(s) in the SL-compliant system for a WoT-compliant Thing and its TD.

[0362] Step 1 : WSIE-1 receives an IO update/deletion request (Request-2) and the parameters included in this step are the same as those defined in the previous sections related to IO update/deletion. Step 1 may be one of two cases. In case 1, if WSIE-1 is the responsible WSIE for the IOs to be updated/deleted, it will start to process Request-2. In case 2, if WSIE- 1 is not the responsible WSIE for the IOs to be updated/deleted, it will first contact WSEVI to find the corresponding responsible WSIE.

[0363] Step 2: In case 1, WSIE-1 starts the processing of Request-2. In particular, what WSIE will do during the processing of this step is the same as the work that needs to be done by WSIE under Architecture- 1 and Architecture-2.

[0364] Step 3 : In case 1, WSIE informs WSIM that it is processing a new Request-2.

[0365] Step 4: In case 1, WSEVI records the task reporting as working logs sent from WSIE-1 in order to maintain a global workload distribution on different WSIEs.

[0366] Step 5: In case 1, WSEVI acknowledges that it already recorded the task reporting from WSIE-1.

[0367] Step 6: In case 2, WSIE-1 sends a request message to WSIM and queries the responsible WSIE of IOs to be updated/deleted for Request-2.

[0368] Step 7: In case 2, WSIM finds out that WSIE-2 is the responsible WSIE of IOs to be updated/deleted for Request-2.

[0369] Step 8: In case 2, WSEVI informs WSIE-1 that WSIE-2 should process Request-2.

[0370] Step 9: In case 2, WSIE forwards Request-2 to WSIE-2.

[0371] Step 10: In case 2, WSIE-2 starts the processing of Request-2 (As same as Step 2) and also reports its workload to WSEVI for processing Request-2.

[0372] Step 1 1 : In case 2, WSIE-2 acknowledges that Request-2 is already processed.

[0373] Step 12: WSIE-1 will also send back an acknowledge to the sender of Request-2 (and also may suggest the sender to contact WSIE-2 for the future requests). Alternatively, WSIE-2 can directly send a response to the sender of Request-2.

[0374] As a result, for all IO update/deletion procedures in this Architecture-3, the following procedures will be employed: 1) all the external entities in the SL-compliant system and WoT- compliant system will send their IO update/deletion requests to a WSIE and the above embedded procedure will be hidden from the external entities used for interactions between WSIM and WSIE. In the meantime, the processing of Step 2 and Step 10 of this procedure shown in Figure 33 will be similar to the work that needs to be done by WSIE in all the IO update/deletion-related procedures proposed for Architecture- 1 and Architecture-2 as discussed above. [0375] According to another embodiment, the proposed Working Scheme- 1 and Working Scheme-2 can be combined together as a hybrid working scheme. The working methodology could be as follows: a WoT-compliant device (or a SL-compliant device) could first talk to WSIM which will select and assign an appropriate WSIE to the WoT-compliant device (or a SL- compliant device). Then, the WoT-compliant device (or a SL-compliant device) will go through the assigned WSIE to perform interworking procedures which will then work the same as the Work Scheme- 1.

[0376] According to the present application, 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, e.g., 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, transit device or the like, perform and/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 includes 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.

[0377] According to yet another aspect of the application, a non-transitory computer-readable or executable storage medium for storing computer-readable or executable instructions is disclosed. The medium may include one or more computer-executable instructions such as disclosed above in the plural call flows according to Figures 20-33 and 38-39. The computer executable instructions may be stored in a memory and executed by a processor disclosed above in Figures 2C and 2D, and employed in devices including servers. In one embodiment, a computer- implemented UE having a non-transitory memory and processor operably coupled thereto, as described above in Figures 2C and 2D, is disclosed. The processor is configured to execute the instructions of (i) receiving a request from a physical entity in a first system to create an interworking-oriented information object in a second system, (ii) determining a type of the interworking-oriented information object to create in the second system for the physical entity, (iii) creating the interworking-oriented information object for the physical entity based upon the determining instruction; and (iii) sending a reply to the physical entity that the interworking- oriented information object is available in the second system.

[0378] According to another embodiment, the processor is configured to execute the instructions of (i) determining an interest in obtaining a list of physical entities in a first system to make them available in the second system; (ii) sending a request to a things description repository in a first system for available things descriptions of the physical entities; (iii) receiving a things description of one physical entity from the repository; (iv) determining a type of the

interworking-oriented information object to create in the second system for the physical entity; and (v) creating the interworking-oriented information object for the physical entity based upon the determining instruction.

[0379] According to yet another embodiment, the processor is configured to execute the instructions of (i) receiving a request from a service layer resource host in a first system to make a resource representation of a service layer compliant device in the first system available on a second system, (ii) determining whether to allow the service layer compliant device to be available in the second system, (iii) determining information to collect to create a things description for representing the service layer compliant device, (iv) accessing the resource representation in the first system to create a things description for the service layer compliant device, (v) creating the things description, and (vi) publishing the created things description in a repository located in the second system.

[0380] According to yet a further embodiment the processor is configured to perform the instructions of (i) sending a resource discovery request to a service layer resource host in a first system for an available resource representation associated with a service layer compliant device;

(ii) receiving a URI of the service layer compliant device from the service layer resource host;

(iii) accessing the resource representation in the first system to create a things description for the service layer compliant device; (iv) creating the things description; and (v) publishing the created things description in a repository located in the second system.

OneM2M Functional Architecture Embodiment

[0381] In another aspect of this application, oneM2M is currently in the process of defining capabilities supported by the oneM2M service layer. These capabilities are referred to as Capability Service Functions (CSFs). The oneM2M service layer is referred to as a Capability Services Entity (CSE). Accordingly, the proposed WoT/SL interworking solution could be regarded as a new CSF in service layer, as shown in Figure 34. Alternatively, it could be part of the existing interworking-related CSF defined in oneM2M TS-0001. Different types of M2M nodes can implement interworking services, such as M2M Gateway, M2M Server, M2M

Devices, etc. In particular, depending on the various/different hardware/software capacities for those nodes, the capacities of interworking services implemented by those nodes may also vary.

[0382] A number of entities have been defined with regard to the three architectures proposed this application. Figure 35 shows an exemplary embodiment of how those entities can be embodied in the oneM2M context under Architecture-3. For example, SL Resource Host can be a CSE in the oneM2M system and AE/CSE can be a SL Native Resource Provider. In the meantime, AE or a CSE can take the role of a WSIE or a WSIM and accordingly the entity taking the role of WSIE or WSEVI can also act as a WoT servient in the WoT system. For example, an implementation solution could be a physical node that has both WoT capability and the oneM2M capability. In the meantime, the WSIE capability is also implemented in this node. In addition, for the interworking-oriented IOs in the WoT-compliant system, it refers to TD. Meanwhile in the oneM2M system, the interworking-oriented IOs refer to oneM2M resources. In the oneM2M system, there could be two types of entities to handle interworking. These include the IPE-based interworking entity and the CSE-based interworking entity. The proposed WSIE or WSIM could refer to either a CSE or an IPE (i.e., specialized AE) for supporting these two types of interworkings:

[0383] The CSE-based interworking (in which IPE is not involved) is mainly adopted in the Interworking Implementation Scenario 1 as introduced during Step 8 of Figure 22: In this scenario, WSIE is responsible for or involved in the 10 creation/update/deletion processes (i.e., only the process that are related to interworking-oriented IO lifecycle management). However, WSIE and/or other entity (such as IPE as defined in oneM2M) will not be involved in any process related to how a WoT client will interact with or access a SL resource representing a SL- compliant thing. For example, for a given WoT client, it can directly interact with a SL resource (e.g., access this resource) without relying on WSIE or relying on IPE. In CSE-based

interworking, oneM2M nodes are directly exposed as WoT Servients (i.e., in the server role) based on the metadata description of WoT TD. Then, a native WoT Servient in the WoT- compliant system (i.e. in the client role) can directly interact with AEs/CSEs and consume the services and data provided by oneM2M CSEs. Under this approach, a WoT Servient in the WoT- compliant system in fact becomes oneM2M compliant and consumes oneM2M interfaces according to the WoT TD since the oneM2M resource model and protocol bindings have been well expressed in WoT TD and then a CSE then can be modelled as a WoT Servient (as Server) and directly interact with a native WoT Servient (as Client) based on the WoT specifications (which is so called CSE-based interworking). In this scenario, the created TD (as interworking- oriented 10) can either be directly hosted by the CSE (since CSE can be modeled as a WoT servient in this scenario, and accordingly this CSE can be a TD Host) or can be published to a TDR in the WoT compliant system as introduced in a later step.

[0384] The IPE-based interworking (in which IPE is not involved) is mainly adopted in the Interworking Implementation Scenario 2 as introduced during Step 8 of Figure 22: In this scenario, WSIE is not only responsible for the 10 creation/update/deletion processes, but also may be involved in the process related to how a WoT client will interact with or access a SL resource representing a SL-compliant thing in a later time. In this case, for a given WoT client, if it discovers a TD representing a SL resource, it will not interact with this resource directly (e.g., access this resource) but need to rely on WSIE (or the IPE as defined in oneM2M) acting as an intermediate entity. In other words, when this WoT client in the WoT-compliant system wants to access a SL resource in the SL-compliant system, it will send its access request towards WSIE (or IPE), and then WSIE or IPE will further act as an intermediate proxy to conduct the real resource access action on the SL resource in the SL-compliant system and finally return the resource access result to the WoT client in the WoT-compliant system. Overall, the above description has the following alternative cases: 1. WSIE is responsible for not only 10 lifecycle management, but also for the real interworking access (i.e., WSIE handle all the details of interworking). 2. WSIE and IPE are implemented as two entities. WSIE is specifically responsible for 10 lifecycle management, and existing IPE is responsible for the real

interworking access. 3. IPE is the major interworking entity and WSIE is implemented as a feature of IPE. In this case, IPE then is responsible for not only 10 lifecycle management, but also for the real interworking access.

[0385] In particular, for Architecture- 1 where SL resources represent TD and WoT Things are co-located with WSIE, it could be one of the following cases: 1) For the IPE-based interworking, the WSIE is a IPE (i.e., WSIE is a feature of IPE), and the SL resources representing TD and WoT Things will be hosted by the CSE hosting the IPE; 2) the SL resources representing TD and WoT Things can also be hosted by the IPE itself, if, in a future release of oneM2M, the IPE or an AE can also host resources; or 3) For the CSE-based interworking, the WSIE is implemented a feature of CSE and the SL resources representing TD and WoT Things will be hosted by this CSE implemented WSIE. In the meantime, in CSE-based interworking, the CSEs can be directly exposed as WoT Servients (i.e., in the server role) based on the metadata description of WoT TD and then can be directly interacted with WoT clients in the WoT- compliant system.

[0386] In the context of oneM2M and WoT, the interworking-oriented 10 life management will have the following descriptions:

[0387] In order to fully realize the above-mentioned interworking between a WoT and oneM2M system, a couple of major technical topics need to be studied: Each system has defined its own Information Object (IO) to represent things/devices/entities. For example, in WoT-compliant system, "Thing Description (TD)" is a type of 10 defined by WoT standard to describe a WoT Thing. Similarly, in oneM2M-compliant system, "Resource" is the type of 10 for

describing/representing oneM2M devices/things. However, in order to support interworking between WoT and oneM2M, a thing/device in one system needs to have corresponding avatar(s) in another system. Such corresponding representations/avatars created for supporting

interworking are referred as "Interworking-oriented IOs". Accordingly, for WoT things and their TDs in the WoT-compliant system, their corresponding Interworking-oriented IOs created in oneM2M system are normal oneM2M resources and can then be accessed by oneM2M- compliant users. For those oneM2M-compliant users, they are able to understand those resources, and to them, those resources are just the representations of oneM2M things/devices although they are really representing WoT-compliant devices in another system.

[0388] One major technical issue in the above process is that given a type of 10 defined in a WoT-compliant system (e.g., the TD defined by WoT), how to create its corresponding interworking-oriented IOs (i.e., its avatar) in terms of resources in oneM2M system, and vice versa. This is mainly done through resource mapping and IM alignment, whose objective is to define standard rules and policies about mapping/translating/transforming IOs between different systems. [0389] However, resource mapping and IM alignment only defines the guideline and rules/policies, it does not involve any concrete procedures/operations implementing the real interworking process. In particular, interworking needs to not only achieves system

interoperability but also needs to be automatic. In other words, based on resource mapping and IM alignment rules/policies, if the interworking-oriented IOs still need to be manually managed (e.g., created/updated/deleted), such level of interworking is not desired especially considering the dynamical changes in M2M/IoT systems (e.g., IoT devices/things are consistently joining/leaving the system). In fact, an interworking-oriented 10 has a certain lifecycle, which is affected by the lifecycle of the corresponding original thing/device. In order to enable the truly automatic interworking, the interworking-oriented 10 lifecycle management needs to support the following operations on two directions:

[0390] When a new WoT device publishes its TD and makes itself available in the WoT system, it may also make itself available in the oneM2M system in order to support interworking.

Similarly, on other direction, consider the scenario where a new oneM2M device/thing registers itself to a CSE and has an oneM2M resource representation (such as a <AE> resource). In order to support interworking, a TD can be created as its interworking-oriented IO of this oneM2M device, and the created TD can be published to the WoT system such that this oneM2M device can become also available in the WoT system. The above operation can be realized through an "Interworking-oriented 10 Creation Process" on both directions.

[0391] Sometime later, if this WoT device may make some changes on its TD due to e.g., device re-configurations, those updates should also be reflected in its corresponding interworking- oriented IO(s) created in the oneM2M system. Similarly, on the other direction, the AE resource of the oneM2M device may have undergone some changes due to CRUD operations. Therefore, those updates can also be reflected in its corresponding TD published to the WoT system. This can be realized through an "Interworking-oriented 10 Update Process".

[0392] Last, if the WoT device is going to be offline and delete its TD in the WoT system, its corresponding interworking-oriented 10 created in the oneM2M system also needs to be deleted. Similarly, on the other direction, if the oneM2M device is going to be offline and delete its <AE> resource from the registered CSE, its corresponding TD published to the WoT system also needs to be deleted. This can be realized through an "Interworking-oriented 10 Delete Process". New OneM2M Resources [0393] In yet another embodiment, a new resource called <WSIE> is exemplarily shown in Figure 36. The resource receives requests related to interworking-oriented 10 lifecycle management. <WSIE> also includes common attributes for service layer resources not shown in Figure 36. During the 10 creation process, when a WSIE receives a 10 creation request, it needs to decide two tasks: Task-1): What type of interworking-oriented 10 needs to be created in the SL-compliant System; and Task-2): For a given selected type, how to represent a WoT Thing and its TD by using the interworking-oriented IOs of that selected type. Normally, WSIE will conduct Task-1 and Task-2 by following respective policies/rules, which can be configured through a configuration process. Accordingly, a new attribute called "rulesForTask-1" can be defined for WSIE to store the policies or rules for Task-1 while another new attribute called "rulesForTask-2" can be defined for WSIE to store the policies or rules for Task-2.

[0394] Another new resource called <WSIM> is exemplarily shown in Figure 37. This resource supports interactions between a WSIE and a WSIM. <WSEVI> includes common attributes for service layer resources and is not shown in Figure 37.

New OneM2M Resources Attribute

[0395] According to yet a further embodiment, a SL resource (such as oneM2M resource) made be made available in another system. Here, a new resource attribute called "externally Available" can be defined for any resource that represents a SL-compliant thing/device/entity. It indicates whether this resource and a corresponding thing is willing to be made available in another system such as a WoT-compliant system or any other external systems.

[0396] Alternatively, another new resource attribute called "externally AvailableList" can be defined for any resource that represents a SL-compliant thing/device/entity to indicate whether this resource and a corresponding thing is willing to be made available in specific external systems.

[0397] If a TD is made available in the SL system, and if WoT-compliant device/thing and its TD are also made available in the oneM2M system (or any other SL-compliant systems), it will have corresponding oneM2M resource(s) as its interworking-oriented IO(s) in the oneM2M system. Accordingly, a new attribute called "originalTD-ID" is defined. It stores the ID or address of the original TD in the WoT-compliant system.

[0398] For a given WoT-compliant Thing and its TD in the oneM2M system, consider the case in which <Resource-l> is created as the corresponding interworking-oriented 10 that represents this WoT Thing, and <Resource-2> is created as the corresponding interworking-oriented 10 that represents the TD of this WoT Thing. When <Resource-l> and <Resource-2> are separated and do not have a parent-child relationship, a new attribute called "resourceAddressOfTD" can be defined for <Resource-l> to store the URI of <Resource-2>, (i.e., the resource representing a corresponding TD). Another new attribute called "resourceAddressOfThing" can be defined for <Resource-2> to store the URI of <Resource-l>, (i.e., the resource representing the WoT Thing). New OneM2M Filter Criteria

[0399] According to even a further embodiment, when the new attribute "externally Available" or "externally AvailableList" is used, they can support more efficient resource discovery if the resource discovery is used to identify which resources should be published to another external system, (i.e., a WoT-compliant system). Accordingly, a new filter criteria called

"externalAvailableCriteria" is proposed. When externalAvailableCriteria is used as a Boolean flag, it will be evaluated against the externally Available attribute of a specific resource, e.g., <Resource-l>. For example, when externalAvailableCriteria is included in a resource discovery request, if the externally Available attribute of <Resource-l> is "true", then, Resource-1 satisfies the externalAvailableCriteria.

[0400] Alternatively, externalAvailableCriteria can also include a list of external system names. It will evaluate the names against the externally AvailableList attribute of a specific resource, e.g., <Resource-l>. For example, when externally AvailbleList is included in a resource discovery request, then if any of system names listed in the externally AvailableList attribute of <Resource-l> is also in the list of names specified in the externalAvailableCriteria, Resource-1 satisfies the externalAvailableCriteria.

Extend Usage for Existing OneM2M Resource Attributes

[0401] In yet even a further embodiment, for a given WoT-Thing and its TD, in the oneM2M system, <Resource-l> is created as the corresponding interworking-oriented IO that represents this WoT Thing. Thus, when putting <Resource-l> and the TD together, the existing

"description" or the "label" attribute of <Resource-l> can be used to store all the information as specified in the TD of this thing.

OneM2M Embodiment for Procedures

[0402] Figure 38 is an exemplary embodiment that illustrates a oneM2M embodiment having procedures for IO creation. In particular, since Architecture-3 is the most sophisticated architecture including all the entities, this embodiment procedure employs Architecture-3. It shows how a oneM2M device and its resource representation can be made available as a TD in the WoT-compliant system. In addition, the corresponding 10 Update/Deletion will have the similar oneM2M embodiments as this one. The steps of this figure 38 are similar to those steps described above. In this figure, the existing resource announcement mechanism can be used for realizing Step 2. For example, a new value can be defined for the 'announceTo' attribute in the request message of Step 2. For example, if 'announceTo' is sent to "WSIE" or set to an URI of a <WSIE> or a <WSIM>, it indicates this request is related to a 10 creation for interworking.

[0403] Similarly, Figure 39 illustrates a oneM2M embodiment of the procedure for 10 creation under Architecture-3. In particular, it shows how a WoT Thing and its TD can be made available in the oneM2M System. The detailed descriptions of all the procedure steps are the same as the ones as defined previously in the corresponding figures detailing the procedures in this. The corresponding 10 Update/Deletion will have a similar oneM2M embodiment.

WoT TD Embodiment

[0404] According to yet even a further embodiment, for a TD to be made available in another system, a new metadata called "externally Available" can be defined in a TD. It indicates whether this thing is willing to be made available in another external system, i.e., a SL-compliant system such as oneM2M or any other external systems.

[0405] Alternatively, another new metadata called "externally AvailableList" can be defined in a TD. It indicates whether this TD and corresponding thing is willing to be made available in which specific external systems. After a TD is published to another system and has

corresponding interworking-oriented IOs in another system, a new metadata can be defined in the TD called "InterworkingOrientedlOs." This indicates the address of the corresponding interworking-oriented IOs in an external interworked system. It is possible that a given TD can be made available in multiple external systems. If so, this metadata could store key-value pairs in which the key is the name of a specific interworked system and the value is the address of the corresponding interworking-oriented IOs in that system that represents this TD). For example, in the case where the TD is published to the oneM2M system, the addresses of the corresponding resources representing a WoT-Thing and its TD will be stored in this metadata.

[0406] For an SL resource e.g., such as oneM2M resource, made available in the WoT system through a TD, if a oneM2M resource representing a oneM2M-compliant device/thing is made available in the WoT system, it will have a corresponding TD as its interworking-oriented 10 in the WoT-compliant system. Accordingly, a new metadata called "originalResource" is defined. It stores the URI of the original oneM2M resource. This attribute can also be used when a WoT- compliant device/thing is interworked with other systems in addition to a oneM2M system.

User Interface

[0407] A GUI interface is exemplarily shown in Figure 40. It can be used for monitoring which physical nodes are taking the roles as defined in the interworking architecture described above in detail. For example, WSIE, WSIM are all logical entities, and different physical nodes can take these roles. In particular, as long as a physical node can work both in the WoT-compliant system and SL-compliant System, it may potentially be a WSIE or a WSEVI. However, it is possible that a physical node may only have limited capacity. Thus, the interworking-related workload of a physical node should be monitored by a GUI such that the global workload can be balanced in real-time based on an administrator's decision. By using the GUI as illustrated in Figure 40, it allows an admin, preferably a human to check which physical nodes are currently taking the different roles. Accordingly, it may further conduct necessary re-configurations as necessary.

[0408] While the systems and methods have been described in terms of what are presently considered to be specific aspects, the application need not be limited to the disclosed aspects. It is intended to cover various modifications and similar arrangements included within the spirit and scope of the claims, the scope of which should be accorded the broadest interpretation so as to encompass all such modifications and similar structures. The present application includes any and all aspects of the following claims.

Claims

WHAT IS CLAIMED IS:

1. A computer-implemented apparatus comprising:

a non-transitory memory having instructions stored thereon for supporting interworking between systems and including rules to perform information model alignment between the systems; and

a processor operably coupled to the non-transitory memory configured to execute the instructions of:

receiving a request from a physical entity in a first system to create an interworking-oriented information object in a second system;

determining a type of the interworking-oriented information object to create in the second system for the physical entity;

creating the interworking-oriented information object for the physical entity based upon the determining instruction; and

sending a reply to the physical entity that the interworking-oriented information object is available in the second system.

2. The apparatus of claim 1, wherein the processor is further configured to execute the instructions of:

subscribing to the interworking-oriented information object for the physical entity; and monitoring the interworking-oriented information object for a change.

3. The apparatus of claim 1, wherein the request includes information selected from a servient ID, required action, ID of a things description, information model suggestion, and combinations thereof.

4. The apparatus of claim 1, wherein the processor is further configured to execute the instructions of preserving a copy of the things description in the non-transitory memory.

5. The apparatus of claim 1, wherein the type is based on transparent interworking, resource mapping, a HAEVI representation, a semantic descriptor representation or a base ontology representation.

6. The apparatus of claim 1, wherein the first and second systems are selected from a web of things system and a service layer system.

7. The apparatus of claim 1, wherein the processor is further configured to execute the instructions of: receiving an update from the physical entity regarding the things description; performing an action to update the interworking-oriented information object based upon the type; and

confirming the update has been made in the second system.

8. The apparatus of claim 7, wherein the processor is further configured to execute the instructions of checking which interworking-oriented information object represents the physical entity and its associated things description.

9. The apparatus of claim 1, wherein the processor is further configured to execute the instructions of:

receiving notification from the physical entity to delete the interworking-oriented information object; and

deleting the interworking-oriented information object for the physical entity.

10. The apparatus of claim 1, wherein the interworking-oriented information object for the physical entity and the physical entity are hosted on the second system.

11. The apparatus of clam 1, wherein the receiving and sending instructions are performed by an interworking manager and the determining and creating instructions are performed by an interworking entity.

12. The apparatus of claim 11, wherein the interworking manager is configured to assign the interworking entity from a group of interworking entities.

13. The apparatus of claim 12, wherein the interworking manager selects one or more of the interworking entities to handle updating and deletion of the interworking-oriented information object.

14. The apparatus of claim 1, wherein

the apparatus is an interworking entity, and

the processor is configured to execute the instructions of sending completed tasks to an interworking manager that records workload distributions of plural interworking entities.

15. A computer-implemented apparatus comprising:

a non-transitory memory having instructions stored thereon for supporting interworking between systems and including rules perform information model alignment between the systems; and a processor operably coupled to the non-transitory memory configured to execute the instructions of:

determining an interest in obtaining a list of physical entities in a first system to make them available in the second system;

sending a request to a things description repository in a first system for available things descriptions of the physical entities;

receiving a things description of one physical entity from the repository;

determining a type of the interworking-oriented information object to create in the second system for the physical entity; and

creating the interworking-oriented information object for the physical entity based upon the determining instruction.

16. The apparatus of claim 15, wherein the sending instruction includes a subscription to certain kinds of physical entities.

17. The apparatus of claim 15, wherein the type is based on transparent interworking, resource mapping, a HAIM representation, a semantic descriptor representation or a base ontology representation.

18. The apparatus of claim 15, wherein the processor is further configured to execute the instructions of:

19. The apparatus of claim 15, wherein the processor is further configured to execute the instructions of:

sending a list of identifications of things descriptions to the things description repository to check for updates; and

receiving the list of things descriptions with updates.

20. The apparatus of claim 15, wherein the processor is further configured to execute the instructions of receiving an id of the physical entity and sending a things description retrieval request to the first system.

21. The apparatus of claim 15, wherein the processor is further configured to execute the instructions of:

receiving an update from the physical entity regarding the things description; performing an action to update the interworking-oriented information object based upon the type; and

confirming the update has been made in the second system.

22. The apparatus of claim 21, wherein the processor is further configured to execute the instructions of checking which interworking-oriented information object represents the physical entity and its associated things description.

23. The apparatus of claim 21, wherein the processor is further configured to execute the instructions of:

deleting the interworking-oriented information object for the physical entity.

24. The apparatus of claim 15, wherein the interworking-oriented information object for the physical entity and the physical entity are hosted on the second system.

25. A computer-implemented apparatus comprising:

receiving a request from a service layer resource host in a first system to make a resource representation of a service layer compliant device in the first system available on a second system;

determining whether to allow the service layer compliant device to be available in the second system;

determining information to collect to create a things description for representing the service layer compliant device;

accessing the resource representation in the first system to create a things description for the service layer compliant device;

creating the things description; and

publishing the created things description in a repository located in the second system.

26. The apparatus of claim 25, wherein the processor is further configured to execute the instructions of:

creating a subscription for CRUD activities associated with the resource representation; and

sending a reply to the service layer resource host confirming the things description is available in the second system.

27. The apparatus of claim 25, wherein

the request includes a URI of the service layer compliant device, and

the things description includes child resources of the service layer compliant device.

28. The apparatus of claim 25, wherein the processor is further configured to execute the instructions of:

determining the service layer compliant device has been updated;

assessing a latest representation of the resource representation;

updating to the things description associated with the service layer compliant device; and publishing the updated things description in the repository in the second system.

29. The apparatus of claim 28, wherein the processor is further configured to execute the instructions of:

receiving an update notification from the service layer resource host; and

receiving an acknowledgment from the second system of the update.

30. The apparatus of claim 25, wherein the processor is further configured to execute the instructions of:

receiving notification from the service layer resource host to delete the things description; and

deleting the things description.

31. The apparatus of claim 25, wherein the things description and service layer compliant device are hosted on the second system.

32. A computer-implemented apparatus comprising:

a non-transitory memory having instructions stored thereon for supporting interworking between systems including rules how to perform information model alignment between the systems; and a processor operably coupled to the non-transitory memory configured to execute the instructions of:

sending a resource discovery request to a service layer resource host in a first system for an available resource representation associated with a service layer compliant device;

receiving a URI of the service layer compliant device from the service layer resource host;

creating the things description; and

33. The apparatus of claim 32, wherein

the sending instruction includes a subscription request to certain types of physical entities, and

the accessing instruction includes child resources of resource representation.

34. The apparatus of claim 32, wherein the processor is further configured to execute the instructions of determining an interest exists in the service layer compliant device;

35. The apparatus of claim 32, wherein the processor is further configured to execute the instructions of:

36. The apparatus of claim 32, wherein the processor is further configured to execute the instructions of:

determining the service layer compliant device has been updated;

receiving an update notification from the service layer resource host;

assessing a latest representation of the resource representation;

37. The apparatus of claim 36, wherein the processor is further configured to execute the instructions of receiving an acknowledgment from the second system of the update.

38. The apparatus of claim 32, wherein the processor is further configured to execute the instructions of:

deleting the things description.

39. The apparatus of claim 32, wherein the things description and service layer compliant device are hosted on the second system.

40. The apparatus of claim 32, wherein

the sending instruction is performed by an interworking manager,

the creating instruction is performed by an interworking entity, and

the interworking manager is configured to assign the interworking entity from a group of interworking entities.