Sign In to Follow Application
View All Documents & Correspondence

Discovery Of Hybrid Network And ‘Byod’ Devices In The Enterprise Network

Abstract: ABSTRACT The embodiments herein relate to device detection in an enterprise network and, more particularly, to detecting IPv4, IPv6, and dual stack devices in the enterprise network. The system initially identifies the IP addresses of all routers present in the enterprise network being monitored. The technique that involves finding IPv6 routers or dual stack routers with IPv6 addresses is sending ICMPv6 echo request for multicast address and fetching routers reply from corresponding IPv6 networks. SNMP or DCHP techniques are used to build the IP list of IPv4 routers or dual stack routers with IPv4 networks. Further, the enterprise network is scanned continuously at given intervals of time to get the list of latest communicating nodes. Finally a router database with active device IP list is prepared in memory. Further various device parameters of the identified devices are fetched. FIG. 1

Get Free WhatsApp Updates!
Notices, Deadlines & Correspondence

Patent Information

Application #
Filing Date
06 June 2013
Publication Number
26/2013
Publication Type
INA
Invention Field
COMMUNICATION
Status
Email
patent@bananaip.com
Parent Application

Applicants

HCL Technologies Limited
50-53 Greams Road, Chennai- 600006, Tamil Nadu, India

Inventors

1. Shashidhar K
A 8&9, Sector 60, Noida, 201301, India
2. Mukta Agarwal
A 8&9, Sector 60, Noida, 201301, India
3. Navneet Kaur
A 8&9, Sector 60, Noida, 201301, India
4. Shailender Govil
A 8&9, Sector 60, Noida, 201301, India

Specification

CLIAMS:CLAIMS

1. A method of detecting types of devices in an enterprise hybrid network, said method comprises:
fetching IPV4 subnet of said enterprise network;
preparing a router database of said enterprise network;
identifying devices connected to each router in said enterprise network; and
identifying device parameters corresponding to each of said identified devices.
2. The method as in claim 1, wherein said identifying devices in said enterprise network further comprises:
identifying whether said enterprise network is a managed or unmanaged network;
fetching device information from a DNS server on said network being a managed network;
identifying type of network on said network being an unmanaged network; and preparing router database from said unmanaged network based on said identified type of network.
3. The method as in claim 2, wherein said fetching device information from said DNS server for said managed network further comprises:
fetching IP address of said DNS server;
fetching all registered IP address details by sending a zone transfer request to said DNS server; and
classifying said fetched IP addresses as IPV4 and IPV6.
4. The method as in claim 2, wherein said preparing the router database based on identified type of network for said unmanaged network further comprises:
identifying whether said unmanaged network is an IPV4 network or an IPV6 network;
fetching IPv6 router information on said unmanaged network being an IPV6 network; and
fetching IPv4 router information on said unmanaged network being an IPV4 network.
5. The method as in claim 4, wherein said fetching router information for said IPV6 network further comprises:
sending an ICMPV6 request to a multicast address;
receiving at least one ICMPV6 echo reply in response to said ICMPV6 request; and
fetching said device information from said received ICMPV6 echo reply.
6. The method as in claim 4, wherein said fetching router information for said IPV4 network further comprises:
fetching IP address of a local host;
fetching a router list associated with said local host;
identifying recursively the routers from said router list based on a IP forward value; and
confirming that each of said identified routers belong to said enterprise network.
7. The method as in claim 6, wherein said confirming each of said identified routers belong to said enterprise network further comprises comparing a subnet of IP address of said router with a subnet value of said enterprise network.
8. The method as in claim 1 wherein said identifying devices connected to each router in said hybrid network further comprises fetching device IP address of latest communicating devices from a router cache of each of said routers.
9. The method as in claim 1 wherein said identified device parameters further comprises at least one of an operating system and type of each of said identified device.
10. A system for detecting types of devices in an enterprise hybrid network, said system is configured for :
fetching IPV4 subnet of said enterprise network using a hybrid network identifier system;
preparing a router database of said enterprise network using said hybrid network identifier system;
identifying devices connected to each router in said enterprise network using said hybrid network identifier system; and
identifying device parameters corresponding to each of said identified devices using said hybrid network identifier system.
11. The system as in claim 10, wherein said hybrid network identifier system is configured to identify devices in said enterprise network by:
identifying whether said enterprise network is a managed or unmanaged network using a discovery module;
fetching device information from a DNS server on said network being a managed network using said discovery module using said discovery module;
identifying type of network on said network being an unmanaged network using said discovery module; and
preparing router database from said unmanaged network based on said identified type of network using said discovery module.
12. The system as in claim 11, wherein said hybrid network device identifier system is further configured to fetch said device information from said DNS server for said managed network by:
fetching IP address of said DNS server using said discovery module;
fetching all registered IP address details by sending a zone transfer request to said DNS server using said discovery module; and
classifying said fetched IP addresses as IPV4 and IPV6 using said discovery module.
13. The system as in claim 11, wherein said hybrid network device identifier system is further configured to prepare said router database based on identified type of network for said unmanaged network by:
identifying whether said unmanaged network is an IPV4 network or an IPV6 network using said discovery module;
fetching IPv6 router information on said unmanaged network being an IPV6 network using said discovery module; and
fetching IPv4 router information on said unmanaged network being an IPV4 network using said discovery module.
14. The system as in claim 13, wherein said hybrid network identifier system is further configured to fetch said router information for said IPV6 network by:
sending an ICMPV6 request to a multicast address using said discovery module;
receiving at least one ICMPV6 echo reply in response to said ICMPV6 request using said discovery module; and
fetching said device information from said received ICMPV6 echo reply using said discovery module.
15. The system as in claim 13, wherein said hybrid network device identifier system is further configured to fetch said router information for said IPV4 network by:
fetching IP address of a local host using said discovery module;
fetching a router list associated with said local host using said discovery module;
identifying recursively the routers from said router list based on a IP forward value using said discovery module; and
confirming that each of said identified routers belong to said enterprise network using said discovery module.
16. The system as in claim 15, wherein said hybrid network device identifier system is further configured to confirm whether each of said identified routers belong to said enterprise network by comparing a subnet of IP address of said router with a subnet value of said enterprise network using said discovery module.
17. The system as in claim 10 wherein said hybrid network device identifier system is further configured to identify devices connected to each router in said hybrid network by fetching device IP address of latest communicating devices from a router cache of each of said routers using said discovery module.
18. The method as in claim 10, wherein said hybrid network device identifier system is further configured to identify said device parameters by fetching information on at least one of an operating system and type of each of said identified device using an OS detection module.
Dated: 06-06-2013
Signature: Vikram Pratap SinghThakur
(Patent Agent)
,TagSPECI:FORM 2
The Patent Act 1970
(39 of 1970)
&
The Patent Rules, 2005

COMPLETE SPECIFICATION
(SEE SECTION 10 AND RULE 13)

TITLE OF THE INVENTION

DISCOVERY OF HYBRID NETWORK AND ‘BYOD’ DEVICES IN THE ENTERPRISE NETWORK
APPLICANTS:
Name : HCL Technologies Limited
Nationality : Indian
Address : HCL Technologies Ltd., 50-53 Greams
Road,Chennai – 600006, Tamil Nadu, India
The following Specification particularly describes and ascertains the nature of this invention and the manner in which it is to be performed:

FIELD OF INVENTION
[001] The embodiments herein relate to device detection in an enterprise network and, more particularly, to detecting IPv4, IPv6, and dual stack devices in the enterprise network.

BACKGROUND OF INVENTION
[002] An enterprise network consists of a group of local area networks (LANs) which are interconnected using wide area networks (WANs) along with number of internetworking devices like switches, routers, gateways etc. Further, the enterprises manage their networks using typical hierarchical ways like core tier of routers and switches or distribution tier of routers and switches or using an access layer that connects users via lower-end switches and wireless access points. The Internet Protocol (IP) allows data communication over geographically diverse sites of an enterprise. When a router in the network receives a packet, based on packets forwarding table, router forwards the received packet to a destined network. Internet Protocol version 4 (IPv4) technology was initially deployed but the exhaustion of IPv4 addresses is generating unavoidable need for all the enterprises and products to migrate to Internet Protocol version 6 (IPv6). The movement to IPv6 is happening in phases by implementing tunnels or by installing dual stack hosts. With phase-wise migration to IPv6, today’s enterprise network became a hybrid network which is having pure IPv4/IPv6, partial and/or dual IPv4/IPv6 islands. Management of network resources in this hybrid environment is quite complex. Further, it raises a need to have methods for planning, tracking and managing the networks. These methods should help the network administrators to discover whole network and to determine IPv6 or IPv4 nodes or dual stack nodes present in the network. Further, network administrator need some tools to do powerful auto-discovery or to maintain up-to-date inventory for all the subnets, IP addresses and network devices present in the network.
[003] The current prevailing method to discover the IPv4 networks involves the process of sending Internet Control Message Protocol (ICMP) echo request to all potential IPv4 addresses and wait for the response. But in IPv6 network, due to large addressing space (2^128 addresses), it is not feasible to send ICMPv6 request to all potential IPv6 addresses as it takes more time to get the response. Further, with the advent of Bring Your Own Device (BYOD) concept, network administrator’s task is further challenged and generates requirement for a tool to determine the BYOD’s in the network. With this BYOD concept, employees in the enterprise are allowed to bring their own devices to work and can use them to share files and data inside and outside the office. Therefore, the issues with managing the BYOD is tracking and controlling the access of the networks. It is imperative to determine which devices will be allowed to access the network and what data employees will be allowed to view, store or transfer through the newly established connections.
[004] What is needed therefore is a system and method that aims at detecting the assigned or currently used IP addresses across IPv4 and IPv6 present in the hybrid network and detecting different BYOD devices present in the hybrid network with details of their location, operating system, applications etc. irrespective of the underlying network connectivity.

SUMMARY
[005] In view of the foregoing, an embodiment herein provides a method of detecting types of devices in an enterprise hybrid network, the method comprises fetching IPV4 subnet of the enterprise network; preparing a router database of the enterprise network; identifying devices connected to each router in the enterprise network; and identifying device parameters corresponding to each of the identified devices.
[006] Embodiments further disclose a system for detecting types of devices in an enterprise hybrid network, the system is configured for fetching IPV4 subnet of the enterprise network using a hybrid network identifier system; preparing a router database of the enterprise network using the hybrid network identifier system; identifying devices connected to each router in the enterprise network using the hybrid network identifier system; and identifying device parameters corresponding to each of the identified devices using the hybrid network identifier system.
[007] These and other aspects of the embodiments herein will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings.

BRIEF DESCRIPTION OF THE FIGURES
[008] The embodiments herein will be better understood from the following detailed description with reference to the drawings, in which:
[009] FIG. 1 illustrates a block diagram of Hybrid network device identifier system, as disclosed in the embodiments herein;
[0010] FIG. 2 illustrates various components of the Discovery module, as disclosed in the embodiments herein;
[0011] FIG. 3 illustrates various components of the Router detection module, as disclosed in the embodiments herein;
[0012] FIG. 4 illustrates various components of the DNS detection module, as disclosed in the embodiments herein;
[0013] FIG. 5 illustrates various components of the memory module , as disclosed in the embodiments herein;
[0014] FIG. 6 illustrates a various components of the OS detection module, as disclosed in the embodiments herein;
[0015] FIG. 7 is a flow diagram which shows various steps involved in the process of identifying different devices present in the hybrid network, as disclosed in the embodiments herein; and
[0016] FIG. 8 is a flow diagram which shows various steps involved in the process of preparing a router database, as disclosed in the embodiments herein.

DETAILED DESCRIPTION OF THE INVENTION
[0017] The embodiments herein and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein may be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.
[0018] The embodiments herein disclose a process of detecting types of devices in an enterprise network by preparing a router database. Referring now to the drawings, and more particularly to FIGS. 1 through 8, where similar reference characters denote corresponding features consistently throughout the figures, there are shown embodiments.
[0019] FIG. 1 illustrates a block diagram of hybrid network device identifier system, as disclosed in the embodiments herein. The system comprises a plurality of user devices 101 and a hybrid network device identifier system 102. The hybrid network device identifier system 102 further comprises an Input Output (I/O) module 102.a, a Discovery module 102.b, a memory module 102.c and an OS detection module 102.d
[0020] The user device 101 refers to the devices present in the network such as personal computer, laptop, tablet PC and so on. In various embodiments, the user devices 101 may be IPv4 or IPv6 or hybrid devices. The hybrid network device identifier 102 maybe set up within the enterprise network 100.
[0021] The I/O module 102.a provides a suitable interface such as keyboard, mouse and touch screen and so on for an authorized person to input data required by the hybrid network device identifier 102.The authorized person such as network administrator shall enter the subnets of IPv4 network. The I/O module 102.a may also be used to provide outputs of the system to the user.
[0022] The discovery module 102.b fetches the configuration information provided by the user and autonomously detects all the IP addresses of routers present in the enterprise network 100. Further, this information is stored in memory module 102.c. Later, the discovery module 102.b fetches the router’s IP addresses from the memory module 102.c and using SNMP engine gets the router cache information to build the database of the active devices (IPv4 or IPv6) on the network. This device database is stored in the memory module 102.c. After identifying network devices 101, the discovery module 102.b may even verify active status of the devices by sending an echo request. The identified information regarding the devices and corresponding node may be stored in the memory module 102.c.
[0023] The OS detection module 102.d fetches the IP addresses from memory module 102.c and identifies the device parameters such as operating system of the device, type of device and so on using a suitable technique such as finger printing technology or SNMP scan technique. The identified devices could also be routers so the device parameters will also be sent to router detection module 201 for further processing.
[0024] The information regarding routers and devices IP’s and device parameters may be stored in a database associated with the memory module 102.c. Further, the data in the memory module 102.c may be fetched by users at any point of time using a suitable interface.
[0025] FIG. 2 illustrates various components of the Discovery module, as disclosed in the embodiments herein. The discovery module 102.b further comprises of a Router detection module 201 and a DNS detection module 202. When information regarding devices in the enterprise network has to be detected, the router detection module 201 in the discovery module 102.b autonomously detects all IPv6 and IPv4 routers present in the enterprise and prepares a list of router’s IP database. This database is stored in the memory module 102.c.
[0026] FIG. 3 illustrates various components of the Router detection module, as disclosed in the embodiments herein. The router detection module 201 comprises a router cache engine 301 and a router 302. The router cache engine 301 further comprises an ICMPv6 echo module 301.a, a SNMP engine 301.b, and a subnet comparator 303.c.
[0027] The router cache engine 301 is responsible for preparing the database of unmanaged networks. The ICMPv6 echo module 301.a finds the routers in IPv6 networks or dual stack routers with IPv6 addresses by sending an echo request to multi cast address of IPv6. Further, ICMPv6 echo module 301.a receives an echo reply from all IPv6 routers that are present in the network. The SNMP engine 301.b which is present in router cache engine 301 identifies the IP address of routers in IPv4 networks by sending a SNMP query to IP route table of respective router 302.
[0028] A router database is build by considering the routers which are in enterprise boundary only. The subnet comparator 303.c in case of IPv4 compares the subnet of the IPv4 router’s IP with enterprise subnet. Further, subnet comparator 303.c may add a router’s IP to router database after confirming the router is in enterprise boundary.
[0029] After router database is build, the SNMP engine 301.b which is present in router cache engine 301 identifies the IP address of devices on the network by sending an SNMP query to get the router’s cache. IP’s in the router cache are the IP’s of the active devices on the network. This identifies all the IPv4, IPv6 or dual stack devices that are actively communicating on the network Later the list of these devices is stored in device database 502 using memory module 102.c.
[0030] FIG. 4 illustrates various components of the DNS detection module, as disclosed in the embodiments herein. The DNS detection module 202 further comprises of a DNS engine 401 and a DNS server 402. The DNS engine 401 enables network discovery of user devices 101 that are present in the enterprise’s managed network. DNS engine 401, sends a request to DNS server 402 in order to get the list of domain registered IP addresses. Further, the DNS engine 401 fetches the list of domain registered IP addresses from DNS server 402 which are later stored in a device database 502 associated with memory module 102.c.
[0031] FIG. 5 illustrates various components of the memory module, as disclosed in the embodiments herein. The memory module 102.c further comprises a router database 501 and a device database 502. The router database 501 stores information on the IP addresses of all routers that are present in the enterprise network. The device database 502 maintains the list of detected device IP addresses. Further, it also maintains the list of all active devices information along with device details like IP address, operating system, location and so on present in the enterprise network 100.
[0032] FIG. 6 illustrates various components of the Operating System (OS) detection module, as disclosed in the embodiments herein. The OS detection module 102.d further comprises a finger printing engine 601 and a SNMP engine 602. The OS detection module 102.d fetches the device database information from memory module 102.c and identifies the device parameters by using different engines (finger printing engine 601 or SNMP engine 602) present in the OS detection module 102.d.
[0033] FIG. 7 is a flow diagram which shows various steps involved in the process of identifying different devices present in the enterprise’s unmanaged network, as disclosed in the embodiments herein. The I/O module 102.a fetches (702) input from user regarding the subnet range for enterprises IPv4 network, through a suitable user interface. Further, the router detection module 201 prepares (704) a router’s IP list by using router cache engine 301 which in turn stored in a router database 501 of memory module 102.c. Each router of the router database is queried to get the list of latest communication nodes or devices that are connected to the routers. These devices are either domain registered or not domain registered. Further the IP information of these devices is stored in device database 502. Since router 302 is also a user device 101 so IP’s of all the routers detected from the router’s cache are omitted and not stored in device database.
[0034] The OS detection module 102.d fetches the IP list of each user device that present in the enterprise network from the device database 502 of memory module 102.c. Further, SNMP engine 602 of the OS detection module 102.d may identify the device parameters such as operating system, device type, device name and so on corresponding to each device 101 by using SNMP scan technique. For example, device OS may be detected from MIB “sysDescr” and device name may be detected from MIB “sysName”. Further from the OS identified, the type of device (smart phone, IPAD, tablet and so on) can be detected. In another embodiment, the finger printing engine 601 of the OS detection module 102.d may identify the device parameters (706) by using finger printing technology.
[0035] Once the device parameters are detected by the OS detection module 102.d, the system may confirm the identified devices 101 in active state or not. In a preferred embodiment, the active devices in the network may be detected by sending an ICMPv6 or ICMPv4 echo requests from router cache engine 301 and DNS engine 401 to the identified devices 101. A device is said to be in active state if the device responds to the echo it received. Finally, the fetched results regarding the type of devices and their status are provided (708) to the user. In a preferred embodiment the results that comprise detected network devices with details like IP address, OS, system descriptor and system name and so on may be provided in a graphical view or in any such suitable format. The various actions in method 700 may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some actions listed in FIG. 7 may be omitted.
[0036] FIG. 8 is a flow diagram which shows various steps involved in the process of preparing a router database, as disclosed in the embodiments herein. Initially, the hybrid network device identifier system 102 fetches (802) information regarding the enterprise network 100 to be monitored so as to identify the subnet of IPv4 network. The hybrid network device identifier system 102, works simultaneously for both managed network and unmanaged network. Managed network may refer to a network which has a definite structure or which is organized properly; whereas the unmanaged network refers to a network that doesn't possess a definite structure. If the enterprise network 100 is a managed network, the DNS engine 401 of the DNS detection module 202 fetches IP address of a DNS server 402 in the enterprise network 100 by using a suitable protocol such as Dynamic Host Configuration Protocol (DHCP). In another embodiment, the DNS server’s or an authoritative name server’s IP address may be provided by the user/network administrator of the enterprise, manually. After fetching IP address of the DNS server 402, the DNS engine 401 sends (804) a zone transfer request to the DNS server 402 to get all the IP address records registered for that particular domain. Further, DNS engine 201 fetches and prepares (806) a list of domain registered IP addresses by parsing the address records of type A (for IPv4 devices) and AAAA (for IPv6 devices) present in DNS server 402.
[0037] In unmanaged case, for IPv6 router discovery the ICMPv6 echo module 301.a of router cache engine 301 sends (810) an ICMPv6 echo request to multicast address of IPv6 (for example; FF05::2). As per Ipv6 Specification, all the routers in the boundary of enterprise network 100 by default join the multicast group FF05::2. It’s responsibility of the network administrator to allow the ICMPv6 for ff05::2 over VPN to cover the geographically dispersed site. Further, the routers with IPv6 or dual stack type may reply with ICMPv6 echo reply. Finally a list is prepared with details of IP addresses of detected IPv6 routers and added to the router database 501 of memory module 102.
[0038] For IPv4 type, the SNMP engine 301.b of the router cache engine 301 fetches IP address (example; 127.0.0.1) of the local host. Further, the SNMP engine 301.b sends (808) a SNMP query to the fetched IP. Later, SNMP engine 301.b reads ‘IPRouteTable’ which is maintained by the local host and fetches information regarding IP addresses of the associated router’s 302. An ‘IPRouteNextHop’ field in the IP address gives the IP address of next routers. In another embodiment, default router field or local host IP can be fetched by using DCHP. Further, an “IP forward value” field may indicate whether the device corresponding to the fetched IP is a router 302 or not. The ‘IP forward value’ of fetched IP’s (IPv4) is checked (812) and IP with IP forward value equal to 1 is added to router database 501 of memory module 102.c., as it indicates a router 302. The IP addresses with a different "IP forward value" may be discarded (814). Further, for IPv4 addresses, a subnet comparison may be performed (816) before adding the IP to the router database 501, so as to confirm the router belongs to the enterprise boundary by comparing subnet of IPv4 with enterprise’s subnet. This is because when router searching is done, the IPv6 routers of enterprise only will responds to the ICMPv6 echo request. But when IPv4 routers are searched using SNMP, the IPv4 routers outside the enterprise boundary may also get detected. Subnet comparator method makes sure that only the IPv4 routers of enterprise are added to router database. This process is recursively done to build the list of IPv4 router’s in the enterprise and finally the list is added to router database 501.
[0039] The SNMP engine 301.b of the router cache engine 301 further sends an SNMP query to all detected routers and fetches the latest communication nodes (818) of routers from SNMP MIB “ipNetToMedia” and “ipv6NetToMedia” tables of router’s cache. These tables may provide information regarding IP’s of identified network devices 101. For example, the fields “ipNetToMediaPhysAddress” and “ipv6netToMediaPhysAddress” may provide the required IP addresses. In an embodiment, router’s cache may be refreshed periodically during which old entries may be flushed so as to provide space for new entries. The hybrid network device identifier system 102 gives due consideration to this property and hence a timer is set. The router cache is read every time whenever the timer goes “Off”. Further, the device parameters like OS, type of device and so on are fetched (820) for the identified device IP addresses by using finger printing engine 601 and SNMP engine 602 of OS detection module 102.d.Finally, a device database is prepared (822) with identified IP addresses in device database 502 of memory module 102.c. The various actions in method 800 may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some actions listed in FIG. 8 may be omitted.
[0040] The embodiments disclosed herein can be implemented through at least one software program running on at least one hardware device and performing network management functions to control the network elements. The network elements shown in Fig. 1 to Fig. 6 include blocks which can be at least one of a hardware device, or a combination of hardware device and software module.
[0041] The embodiment disclosed herein specifies a system for identifying assigned or currently using IP addresses across IPv4 and IPv6 present in a hybrid network. The mechanism allows preparing a router database of IPv6 and IPv4 networks providing a system thereof. Therefore, it is understood that the scope of the protection is extended to such a program and in addition to a computer readable means having a message therein, such computer readable storage means contain program code means for implementation of one or more steps of the method, when the program runs on a server or mobile device or any suitable programmable device. The method is implemented in a preferred embodiment through or together with a software program written in e.g. Very high speed integrated circuit Hardware Description Language (VHDL) another programming language, or implemented by one or more VHDL or several software modules being executed on at least one hardware device. The hardware device can be any kind of device which can be programmed including e.g. any kind of computer like a server or a personal computer, or the like, or any combination thereof, e.g. one processor and two FPGAs. The device may also include means which could be e.g. hardware means like e.g. an ASIC, or a combination of hardware and software means, e.g. an ASIC and an FPGA, or at least one microprocessor and at least one memory with software modules located therein. Thus, the means are at least one hardware means and/or at least one software means. The method embodiments described herein could be implemented in pure hardware or partly in hardware and partly in software. The device may also include only software means. Alternatively, the invention may be implemented on different hardware devices, e.g. using a plurality of CPUs.
[0042] The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the spirit and scope of the claims as described herein.

Documents

Application Documents

# Name Date
1 2494-CHE-2013 FORM-9 07-06-2013.pdf 2013-06-07
1 2494-CHE-2013-US(14)-HearingNotice-(HearingDate-21-01-2021).pdf 2021-10-17
2 2494-CHE-2013 FORM-18. 07-06-2013.pdf 2013-06-07
2 2494-CHE-2013-Correspondence to notify the Controller [15-01-2021(online)].pdf 2021-01-15
3 Form 5.pdf 2013-06-12
3 2494-CHE-2013-Proof of Right (MANDATORY) [23-01-2020(online)].pdf 2020-01-23
4 FORM 3.pdf 2013-06-12
4 2494-CHE-2013-ABSTRACT [19-09-2019(online)].pdf 2019-09-19
5 FORM 2.pdf 2013-06-12
5 2494-CHE-2013-CLAIMS [19-09-2019(online)].pdf 2019-09-19
6 drawings.pdf 2013-06-12
6 2494-CHE-2013-CORRESPONDENCE [19-09-2019(online)].pdf 2019-09-19
7 abstract2494-CHE-2013.jpg 2013-06-20
7 2494-CHE-2013-FER_SER_REPLY [19-09-2019(online)].pdf 2019-09-19
8 2494-CHE-2013-FORM 13 [19-09-2019(online)].pdf 2019-09-19
8 2494-CHE-2013 POWER OF ATTORNEY 17-10-2013.pdf 2013-10-17
9 2494-CHE-2013 FORM-1 17-10-2013.pdf 2013-10-17
9 2494-CHE-2013-OTHERS [19-09-2019(online)].pdf 2019-09-19
10 2494-CHE-2013 CORRESPONDENCE OTHERS 17-10-2013.pdf 2013-10-17
10 2494-CHE-2013-RELEVANT DOCUMENTS [19-09-2019(online)].pdf 2019-09-19
11 2494-CHE-2013-FER.pdf 2019-03-20
12 2494-CHE-2013 CORRESPONDENCE OTHERS 17-10-2013.pdf 2013-10-17
12 2494-CHE-2013-RELEVANT DOCUMENTS [19-09-2019(online)].pdf 2019-09-19
13 2494-CHE-2013 FORM-1 17-10-2013.pdf 2013-10-17
13 2494-CHE-2013-OTHERS [19-09-2019(online)].pdf 2019-09-19
14 2494-CHE-2013 POWER OF ATTORNEY 17-10-2013.pdf 2013-10-17
14 2494-CHE-2013-FORM 13 [19-09-2019(online)].pdf 2019-09-19
15 2494-CHE-2013-FER_SER_REPLY [19-09-2019(online)].pdf 2019-09-19
15 abstract2494-CHE-2013.jpg 2013-06-20
16 2494-CHE-2013-CORRESPONDENCE [19-09-2019(online)].pdf 2019-09-19
16 drawings.pdf 2013-06-12
17 2494-CHE-2013-CLAIMS [19-09-2019(online)].pdf 2019-09-19
17 FORM 2.pdf 2013-06-12
18 2494-CHE-2013-ABSTRACT [19-09-2019(online)].pdf 2019-09-19
18 FORM 3.pdf 2013-06-12
19 Form 5.pdf 2013-06-12
19 2494-CHE-2013-Proof of Right (MANDATORY) [23-01-2020(online)].pdf 2020-01-23
20 2494-CHE-2013-Correspondence to notify the Controller [15-01-2021(online)].pdf 2021-01-15
20 2494-CHE-2013 FORM-18. 07-06-2013.pdf 2013-06-07
21 2494-CHE-2013-US(14)-HearingNotice-(HearingDate-21-01-2021).pdf 2021-10-17
21 2494-CHE-2013 FORM-9 07-06-2013.pdf 2013-06-07

Search Strategy

1 searchstrategy_07-03-2019.pdf