FORM 2
THE PATENTS ACT, 1970 (39 of 1970)
&
THE PATENTS RULES, 2003
COMPLETE SPECIFICATION
(See section 10, rule 13)
J. Title of the in vention:
INTEROPERABILITY OF DEVICES
2. Applicant(s)
NAME NATIONALITY ADDRESS
TATA CONSULTANCY SERVICES Indian Nirmal Building, 9th Floor, Nariman Point,
LIMITED Mumbai-400021, Maharashtra, India
3. Preamble to the description
COMPLETE SPECIFICATION
Following specification particularly describes the invention and the manner in which it
is to be performed.

TECHNICAL FIELD
[0001] The present subject matter, in general, relates to interoperability of diverse devices, and in particular to generic systems and methods for implementing interoperability of devices in a smart space.
BACKGROUND
[0002] Though the concept of interoperability of devices in a smart environment is
gaining recognition, implementing an easy-to-implement, cost-effective, and generic
interoperation framework is still a difficult task to achieve. Interoperability can be understood
as the ability of two or more devices in a networked space, to exchange information and to
use the exchanged information.
[0003] A smart space can any networked space that aims to facilitate communication
between diverse systems and/or devices—similar or heterogeneous, existing or future—with
context awareness, and without any restricted access. This type of networking model is also
referred to as ubiquitous computing. A few examples of a typical smart space may include a
smart home, a smart healthcare system, and a smart vehicle. Examples of conventional devices that may interoperate in a given smart space are computers, mobile phones, lightings, climate control devices, biometric sensors, energy meter etc.
SUMMARY
[0004] This summary is provided to introduce concepts related to system and a method for providing interoperability between heterogeneous devices in a smart space, which are further described below in the detailed description. This summary is not intended to identify essential features of the claimed subject matter nor is it intended for use in determining or limiting the scope of the claimed subject matter.
[0005] In one implementation, service requests from one or more interoperating devices are received by the interface module. Based on the service requests, the services that are to be provided are identified by a control module. Once the services are identified, the service module provides the services in response to the service requests.

BRIEF DESCRIPTION OF DRAWINGS
[0006] The detailed description is provided with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the drawings to reference like features and components.
[0007] Fig. 1 illustrates an exemplary network environment implementing
interoperation of devices in a smart space, in accordance with an embodiment of the present
subject matter.
[0008] Fig. 2 illustrates an interoperation system implementing interoperation of devices, in accordance with an embodiment of the present subject matter.
[0009] Fig. 3 illustrates an exemplary method for achieving interoperation in a smart space, according to an embodiment of the present subject matter.
DETAILED DESCRIPTION
[0010] The present subject matter describes concepts related to interoperability within
a smart space. As indicated previously, a smart space is an environment or physical space having a plurality of computing-based devices, serving different domain of application and communicating with each other. Interoperation in a smart space generally requires identifying the devices in the smart space and then addressing each such device while maintaining its particular type of connectivity required for interoperation, as well as exchanging information across the diverse domain of application or services. Different devices may have different physical communication mechanisms like universal plug-and-play (UPnP), Bluetooth, Zigbee, Wi-Fi, and Ethernet, to name a few.
[0011] The devices indentified in the smart space may request for services from a central device that are already present within the smart space. The devices may communicate either through a wireless connection or through a wired connection. In case of a wireless system, the smart space can be provided by employing sensors/Zigbee, Bluetooth, Wi-Fi based devices, which can be utilized for detecting the presence of the devices seeking interoperation. Examples of devices that include such interoperating device include, but are not limited to, video file source, power meters, alarms, room temperature thermometers, cameras, etc. As would be evident, the platform and the communication standards that are

employed by such devices differ from device to device, making interoperability problematic in these circumstances.
[0012] Conventional protocols for interoperation may include discovering or detecting
one or more devices within a range or a smart space, within which such devices can
communicate. Subsequently, information can be exchanged, for example, in response to a
service request received from the device. The interoperability between the one or more
devices within a smart space can be conventionally implemented by installing one or more
components. Many a times, the components need to be installed in order to communicate
effectively with the smart environment. Such components fail to provide interoperability as
expected even when adequate conventional interface standards are used.
[0013] Furthermore, different components may be required for communicating with
different smart environments. The problem may further get compounded as the different platforms of the interoperating devices may not support the components. In such cases, additional components may be required thereby making the task of implementing interoperation between the devices complex.
[0014] For example, a user of device such as a smart phone wishes to access video
files stored in a data store. It is quite likely to be the case that the platform and the application domain which are supported by the data store differs from the platform, and the application domain that are supported by the mobile phone. Due to the differences in platform, application domain, or such the devices may not be able to communicate with each other. There may be a case, where some additional components, such as application patches that run on the devices, are installed which can enable the devices to communicate with each other. Finding the desired application patches and installing the same may prove to be a complex exercise. Furthermore, the patches may not be compatible or available, thereby preventing interoperability of the devices.
[0015] To this end, systems and methods for implementing interoperability within multiple diverse within a smart environment are described. In one implementation, a central interoperability system may be provided. The central interoperability system includes a variety of modules for providing a plurality of services. The plurality of services can be requested by interoperating devices that are present within the smart environment. The

interoperating devices within the smart environments can be detected by the central interoperability system. In one implementation, the interoperating devices can be associated with a unique identifier.
[0016] Once devices within the smart environment are detected, one or more service
requests are received from the devices. The service requests can be generated using previously existing components that are present within the devices. The previously existing components can be considered to include those components that are essential for the normal functioning of the devices. It would be appreciated that no other component would be required for generating service requests. Examples of modules that can be used for generating service requests include, but are not limited to, interfaces such as web-browsers, SMS based interfaces, and such. As will be appreciated by a person skilled in the art, such components are typically configured within all such interoperating devices.
[0017] In one implementation, the generated service requests are received by an interface module having one or more programmable module interfaces, such as Application Programmable Interfaces (i.e., APIs). Based on the service requests, the programmable module interfaces can be invoked and the relevant services can be provided to the requesting interoperating devices. In one implementation, the services can be associated with one or more events. The events can be detected, and on detection, the associated programmable module, such as an API, can be invoked for providing the service. It would be appreciated that the functionality of the interface module can be implemented using modules, as will be illustrated later in this detailed description.
[0018] A plurality of services can be provided within the central interoperability system. The types of services within the central interoperability system are extendable, as the services can be easily added within the central interoperability system into its service module. Furthermore, additional programmable module interfaces can also be provided within the central interoperability system thereby enabling provisioning of service based on service requests received from the interoperating devices. The service requested can be provided by central interoperability system. In this manner, no additional components need to be installed on the interoperating devices for requesting different or additional services. Additional modules can be implemented to provide interoperability between different interoperating

devices supporting different platforms. In this manner, different services within different smart environments can be provided efficiently, and without installing any additional components within the interoperating devices. Examples of services include, bit are not limited to, User Datagram Protocol (i.e., UDP) based data forwarding, video streaming across a network, data sharing, SMS, email, context analyzing and so on.
[0019] These and other aspects will be further explained in detail in conjunction with
Figs. 1-3. While such aspects can be implemented in any number of different computing systems, environments, and/or configurations, the embodiments are described in the context of the following exemplary system architecture(S).
[0020] Fig. 1 illustrates an exemplary network environment 100 implementing interoperability of one or more devices, according to an embodiment of the present subject matter. The network environment 100 includes a plurality of interoperating devices 102-1, 102-2, 102-3..., 102-N, hereinafter collectively referred to as interoperating devices 102. The interoperating devices 102 are heterogeneous, that is, they may have different communication or data transfer mechanisms and can communicate with each other either through a wired or a wireless medium. The user devices 102 may include desktop computers, laptops, PDAs, mobile phones, smart phones, etc.
[0021] The interoperating devices 102 within the network environment 100 may communicate with each other or with a network 104, including an external network, such as the Internet, through the central device. The network 104 may be a wireless or a wired network, or a combination thereof. The network 104 can also be a collection of individual networks, interconnected with each other and functioning as a single large network (e.g., the internet or an intranet). Examples of such individual networks include, but are not limited to, Local Area Networks (LANs), Wide Area Networks (WANs), and Metropolitan Area Networks (MANs).
[0022] In one implementation, the interoperating devices 102 may also communicate
with a central interoperability system 106 or with the network 104 through the central interoperability system 106. The central interoperability system 106 further includes the control module 108, a service module 110, and an interface module 112. The central interoperability system 106 enables the interoperation between one or more of the

interoperating devices 102 through at least the control module 108. During interoperation, the interoperating devices 102 may request for a variety of services which can then be provided by the service module 110.
[0023] In operation, the central interoperability system 106 implements
interoperability between one or more of the interoperating devices 102 by initially detecting
which one or more of the interoperating devices 102 which are associated with the central
interoperability system 106. For example, the interoperating devices 102 can be associated
with the central interoperability system 106, either through a wired or a wireless medium. In
case of a wireless medium, such as a Wi-Fi enabled network, the central interoperability
system 106 attempts to detect the interoperating devices 102 which may be present within the
operating range of the wireless network. In one implementation, the interoperating devices
102 can be detected the moment they fall within the range of the wireless network.
[0024] Once one or more of the interoperating devices 102, such as devices 102-1 and
2, are detected, the central interoperability system 106 registers the detected device 102-1. Subsequently the registered device, such as device 102-1, is enabled to request for one or more services from the central interoperability system 106. In one implementation, each of the registered interoperating devices 102 is assigned a unique identifier. During the interoperation, the interoperating devices 102 would be associated with the same unique identifier that was assigned at the time of registration.
[0025] As mentioned previously, the registered interoperating devices 102 can request
for services from the central interoperability system 106. The central interoperability system 106 includes a variety of modules for providing the requested services. The modules can be added or removed from the central interoperability system 106. In this manner, the number of services that can be offered can be changed easily. In one implementation, the service module 110 provides services to the interoperating devices 102 based on the service requests. In another implementation, the services that can be requested by the interoperating devices 102 can be first provided by the central interoperability system 106 as listed options. Of the listed options, the users of the interoperating devices 102 can select the relevant service. It would be appreciated that the relevant services can be provided by either the central interoperability system 106 directly or through any one or more of other interoperating devices 102, such as

device 102-2. For example, device 102-1 being a smart phone, can request video streaming of video files stored in device 102-2.
[0026] In one implementation, the central interoperability system 106 also includes a
plurality of programmable module interfaces, such as APIs. The APIs allow for interfacing
the various services with the interoperating devices 102 that may be present within the
interoperability environment 100. The APIs can be considered to be part of the interface
module 112of central interoperability system 106. It would be appreciated that the interface
module 112 of the central interoperability system provides an interface for interaction with the
outer world. . The same can be implemented using one or more modules within the central
interoperability system 106. In one implementation, the APIs invokes the service module 110,
by triggering events/service requests which eventually are handled by the control module 108
and providing the services to one or more of the interoperating devices 102, say device 102-1.
[0027] Once the service request is received, the control module 108 identifies the
service associated with the service request. In one implementation, the identification of the service to be provided can be based on a service registry. Once the service to be provided is identified, the service module 110 is invoked by the control module for providing the requested service to the any of the interoperating devices 102. Few examples of the types of services that can be requested or provided include, but not limited to, video streaming, IP data access, SMS, UDP-based data forwarding, context processing, etc. In one implementation, the services can be invoked by APIs.
[0028] As is indicated above, the number of services that can be provided is not dependent on the modules that are installed or implemented within the interoperating devices 102. The number of services that can be provided by the central interoperability system 106 can be increased or decreased by adding or removing the relevant service components to or from the service module 110 within central interoperability system 106. In this way, the number of services that can be offered can be altered without making any modifications or installing any additional components onto the interoperating devices 102. According to an embodiment of the present subject matter, central interoperability system 106 may support an Open Source Gateway Initiative (OSGi) based platform.

[0029] Though the systems and methods described above have been explained in relation to a particular system that provides a platform for interoperation of a plurality of heterogeneous devices, such as interoperating devices 102, in a smart space, it would be appreciated that the same systems and methods may be applicable to any other similar system that facilitates communication between such devices.
[0030] The systems and devices as introduced in Fig. 1 are further described in detail
in conjunction with Fig. 2. Fig. 2 illustrates a central interoperability system 106 for implementing an interoperation between one or more devices, according to an embodiment of the present subject matter. The central interoperability system 106 may include processor(s) 202, I/O interface(s) 204, and a memory 206 coupled to the processor(s) 202. The processors) 202 may include microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries and/or any devices that manipulate signals and data based on operational instructions. Among other capabilities, the processors) 202 is configured to fetch and execute computer-readable instructions stored in the memory 206.
[0031] The I/O interfaces) 204 may include a variety of software and hardware interfaces, for example, interfaces for peripheral device(s) such as data input/output devices, storage devices, network devices, etc. The I/O interface(S) may include Universal Serial Bus (USB) ports, Ethernet ports, Host Bus Adaptors, Wi-Fi, power lines, Bluetooth, etc and their corresponding device drivers. The I/O interface(s) 204, amongst other things, facilitate receipt of services from the interoperating devices 102 in the network 104.
[0032] The memory 206 may include any computer-readable medium known in the art
including, for example, volatile memory (e.g., RAM) and/or non-volatile memory (e.g., flash, etc.). The memory 206 further includes modules 208 and/or data 210 for implementing the interoperation between the devices. The modules 208 may include, for example, the control module 108, the service module 110, an interface module 112, operating system 212 and other modules 214. The interface module 112 further includes API 216. The other module(s) 214 may include modules that supplement the functioning of the central interoperability system 106, for example, modules enabling communication between the interoperating devices 102, or the central interoperability system 106.

[0033] On the other hand, data 210 serve as repositories for storing information associated with the modules 208, or any other information that is used by the modules 208 or
generated as result of the execution of one or more of the modules 208. The data 210 includes
service registry 218, event data 220, user information 222, and other data 224. The user
information 222 includes information associated with the one or more of the interoperating
devices 102. The service registry 218 can specify information and the settings associated with
the services that have to be provided in response to the service requested by the interoperating
devices 102. In addition, the service registry 220 provides mechanism to share service specific
information. In an implementation, new services to be provided can be notified in the service
registry 218. It would be appreciated by a person skilled in the art that the modules 208 and/or
data 210 can be implemented within the operating system 212 of the central interoperability
system 106. The operating system 212 can be present within the memory 206.
[0034] During operation, the control module 108 detects all the interoperating devices
102 that are present within the network environment 100. The interoperating devices 102 that
are present within the network environment 100 can be connected either through a wired or a
wireless medium. The control module 108 can detect the interoperating devices 102 within
the network environment 100 by mechanisms that are conventionally known to a person
skilled in the art. For example, the control module 108 can broadcast or initiate a device
search through its device search service across the existing physical interfaces having
different communication protocol (like Wi-Fi, Zigbee, Bluetooth, Ethernet, etc.)
[0035] Once the control module 108 detects one or more interoperating devices 102, it
evaluates a unique identifier. The unique identifier would eventually be utilized, amongst other things, for providing the services requested by the interoperating devices 102. Once evaluated, the unique identifier is associated with the relevant interoperating devices 102, say device 102-1. In one implementation, the unique identifier can be associated with the device, say device 102-1, for as long as the device 102-1 communicates with the central interoperability system 106 or for a definite time interval. In one implementation, the control module 108 utilizes the service module 110 to determine the unique identifier based on the requested service, and for associating the unique identifier with the relevant interoperating

devices 102. In another implementation, the unique identifier can be based on Internet Protocol version 6 (IPv6) based address.
[0036] Information indicating the each of the interoperating devices 102 along with
the unique identifier can be stored in user information 222. Once the unique identifier is
associated, each of the interoperating devices 102 can be registered with the central
interoperability system 106. At this stage, the registered interoperating devices 102 can be
considered to be authorized for requesting different services available with the central
interoperability system 106. It would be appreciated that the control module 108 can be
implemented as a thread. For example, the control module 108 may be configured to run as a
java-based executable with a threaded architecture which can interact with the service module
110 and the interface module 112. Depending on the services requested, the control module
108 can invoke the relevant services and provide the same to the interoperating devices 102.
[0037J The service request sent from the interoperating devices 102 can be received
by the interface module 112. The received service request can further include the unique
identifier of one of the interoperating devices 102, say device 102-1, which generated the
service request. Once the service request is received, the control module 108 invokes the
service module 110. The service module 110, depending on the service requested by any one
or more of the interoperating devices 102, provides the service to, say device 102-1.
[0038] In one implementation, the API 216 within the interface module 112 may
identify one or more events based on the service request. The events that are identified by the interface module 112 are then forwarded to the service module 110. In one implementation, the events are forwarded to the service module 110 via the control module 108. The control module 108 identifies the requested service to be provided to the relevant interoperating devices 102. Once the services are identified, the service module 110 provides the service to the requesting interoperating devices 102. It would be appreciated that the API 216 may itself include a plurality of APIs (not illustrated), including invoking a web interface, each of which can be chosen depending on the service that is to be provided. In such a manner, the number of services that can be provided can be changed by simply adding the relevant programmable module interfaces, such as APIs within API 216. This way, no additional components are required to be installed on any of the interoperating devices 102.

[0039] In another implementation, the control module 108 running as a thread, associating interface and service module for continuously monitoring the occurrence of, and handling, one or more events. One detecting the occurrence of an event, the control module 108 may invoke an event handler, where the events are registered by this module during initialization. Once the event handler is invoked, the control module 108 can determine the relevant services based on the registered events. In one implementation, the control module 108 may determine the relevant services to be provided based on the service registry 218. In another implementation, information in relation to services that may be associated with events can be stored in event data 220. Once the services are determined, the control module 108 associates the services with the event. The associated services can then be provided by the service module 110 to the relevant interoperating devices 102.
[0040] In an implementation, the interface module 112 includes a message producer and a topic publisher (not shown in Fig. 2), both being types of event handling mechanisms as are known in the art. These schemes are used for, for example, handing transfer of message or data between the central interoperability system 106 and one or more of the interoperating devices 102.
[0041] In yet another implementation, the API 216 may further include an interopStart API and an interopStop API. The interopStart API and interopStop API start and stop the control module 108, respectively.
[0042] As has been described in the preceding paragraphs, the service module 110 performs service-specific functionality as activated by the control module 108. The services are furnished to the concerned user device that has requested the service, by using the API 216 provided within the interface module 112. A person skilled in the art may easily understand that the services act as event handler, and the central device 106 on which the interoperation framework runs is a common point for interoperation.
[0043] Fig. 3 illustrates an exemplary method 300 for implementing interoperability between a plurality of devices within a smart environment, according to an embodiment of the present subject matter. These exemplary methods may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, functions, and

the like that perform particular functions or implement particular abstract data types. The computer executable instructions can be stored on a computer readable medium and can be loaded or embedded in an appropriate device for execution.
[0044] The order in which the method is described is not intended to be construed as a
limitation, and any number of the described method blocks can be combined in any order to implement the method, or an alternate method. Additionally, individual blocks may be deleted from the method without departing from the spirit and scope of the invention described herein. Furthermore, the method can be implemented in any suitable hardware, software, firmware, or combination thereof.
[0045] At block 302, a plurality of interoperating devices within a smart environment,
are identified and registered. For example, the control module 108 identifies the one or more
of the interoperating devices 102 within the network environment 100. In one
implementation, the control module 108 on detecting, associates a unique identifier to the
interoperating devices 102. In another implementation, the control module 108 utilizes the
interface module 112 for the registration of the interoperating devices 102.
[0046] At block 304, one or more service requests are received by the interface
module from the interoperating devices. For example, the interface module 112 receives a service request from at least one interoperating devices 102. In one implementation, the service request can also be associated with the unique identifier of one of the interoperating devices 102, say device 102-1, which generated the service request.
[0047J At block 306, one or more events associated with the service requests are identified. For example, API 216 within the interface module 112 may identify events with the service request. In one implementation, the interface module 112 identifies the events based on the service requests. In another implementation, the interface module 112 communicates the identified event to the control module 108.
[0048] At block 308, based on the identified events, the services to be provided are also identified. For example, the control module 108 invokes the service module 110, based on the identified events and its associated service, which in turn executes the requested service to be provided to the relevant interoperating devices 102. Once identified, the services to be provided are associated with the events.

[0049] At block 310, the service associated with the event is provided to the interoperating devices. For example, the service module 110 then provides the service that
was associated with the event in the previous step. In one implementation, the control module
108 can monitor the occurrence, and schedule the handling of similar events. On detection of
similar events, the associated services can be provided to the interoperating devices 102.
[0050J Although embodiments for implementing a knowledge system has been described in language specific to structural features and/or methods, it is to be understood that the subject matter is not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as examples of implementations for the virtualization of the plurality of storage locations.

I/We Claim:
1. An interoperability system, the system comprising:
a processor;
a memory coupled to the processor, the memory comprising,
an interface module configured to receive a plurality of service requests remotely from at least one interoperating device;
a control module configured to identify, from a group of available services, at least one service based at least in part on the service request; and
a service module configured for providing the service identified by the control module.
2. The system as claimed in claim 1, wherein the interface module is further configured to identify at least one event with the service request.
3. The system as claimed in claim 2, wherein the service module further provides, from the group of available services, the at least one service based on the identified event.
4. The system as claimed in claim 1, wherein the control module identifies the at least one service based on a service registry.
5. The system as claimed in claim 2, wherein the control module is executed as a thread.
6. The system as claimed in claim 1, wherein the interface module further includes a plurality of programmable module interfaces for detecting the plurality of interoperating devices prior to the receiving of the plurality of service requests.
7. The system as claimed in claim 6, wherein the interface module further coordinates with the control module to associate a unique identifier to the detected plurality of interoperating devices.
8. The system as claimed in claim 6, wherein the service module is further configured to add additional services to the group of available services, based at least in part on adding additional programmable module interfaces associated with the additional services to the interface module.

9. The system as claimed in claim 7, wherein the unique identifier is an Internet Protocol version 6 (IPv6) based address.
10. A method for implementing interoperability between interoperating devices, the method comprising:
receiving a service request from one or more of the interoperating devices;
identifying at least one event based on the received service request;
identifying services, from a group of available services, to be provided based at least in part on the identified event; and
providing identified services to the interoperating devices.
11. The method as claimed in claim 10, wherein the identifying the at least one event is based on a plurality of programmable module interfaces, wherein each of the plurality of the programmable module interfaces are for the services within the group of available services.
12. The method as claimed in claim 11, wherein the programmable module interfaces are implemented as Application Programmable Interfaces (API).
13. The method as claimed in claim 10, wherein the identifying the services further comprises:
registering an event;
associating the service, from the group of available services, with the event;
monitoring for occurrence of the event; and
on detection of the occurrence of the event, providing the associated service.
14. The method as claimed in claim 13, wherein the monitoring for occurrence of the
event is implemented as a computer-implementable threaded process.