Sign In to Follow Application
View All Documents & Correspondence

A Method Of Implementing The Location Based Ott Ring Back Tone Service And A System Thereof

Abstract: A method and system for providing context specific location based dynamic information to a user of a telecommunication network. The method comprises sending an activation request to an OTT call node server by a OTT user, sending a synchronization request to a RBT system by OTT login server subscribing RBT service, updating user information and sending back (21) synchronize success in response (20) to said synchronization request. Thereafter sending (23) a location activation request to an ORS system by an OTT user GUI; enabling ORS GUI user to activate the Location for the RBT services updating the location of a registered RBT user and wherein OTT user GUI is enabled via RBT request to perform plurality of RBT operations based on RBT play settings.

Get Free WhatsApp Updates!
Notices, Deadlines & Correspondence

Patent Information

Application #
Filing Date
31 December 2015
Publication Number
34/2017
Publication Type
INA
Invention Field
COMMUNICATION
Status
Email
Parent Application
Patent Number
Legal Status
Grant Date
2022-10-07
Renewal Date

Applicants

Huawei Technologies India Pvt. Ltd.
SYNO 37, 46, 45/3, 45/4 ETC., KNO 1540, Kundalahalli Village, Bengaluru, Karnataka – 560037, India

Inventors

1. VAID Raman
SYNO 37, 46, 45/3, 45/4 ETC., KNO 1540, Kundalahalli Village, Bengaluru,, Karnataka – 560037, India

Specification

Technical Field
Embodiments of the present disclosure relates to devices and associated methods for providing a Ring back tone service, and more specifically, but not limited to, such a system and method for Ring for back tone service based on user location.
Background
Telecommunication has experienced enormous growth in the past years. The use of electronic devices such as mobile phones, smart phones, and personal digital assistants (PDAs) has increased tremendously. The growth in the usage of electronic devices is also revolutionizing telecommunication services offered to subscribing customers.
One of such telecommunication service is a well known ringback tone (RBT). Thus, a ringback tone (RBT) or a ringing tone is an audible indication that is heard by the originator of a telephone call while the destination being called is ringing.
Such an audible indication is normally a repeated tone e.g. in a loop, designed to assure the calling party that the called party's line is ringing.
Currently, various ringback tone (RBT) services are deployed for OTT (Over the top) Networks, in which various OTT nodes are participating to provide RBT service.
The over-the-top content (OTT) refers to delivery of audio, video, and other media over the Internet without the involvement of a multiple-system operator in the control or distribution of the content. Thus, the Internet provider may be aware of the contents of the Internet Protocol packets but is not responsible for, nor able to control, the viewing abilities, copyrights, and/or other redistribution of the content.
Now, the existing OTT RBT is implemented with a Called RBT service trigger and involves registering RBT subscriber’s in OTT login server as follows:
1. A party “A” calls “B”, a OTT call node checks the RBT service trigger for Called party i.e. “B”.

2. If called party (“B”) is having RBT trigger then an RBT announcement is played for the OTT calling party (“A”)
However, one of the problem associated with said existing technique is that it is not suitable to locate the OTT user. Thus, the location of such an OTT user is not verifiable.
In a typical scenario, the OTT users are free to roam anywhere across the globe so services based on OTT user location shall able of better usage to such a user. For example if OTT user is in a particular geographical location then corresponding services provided to such a user should preferably be context sensitive to such geographical location i.e. as per calling or called user location.
However, existing schemes results in loss of context specific services to users.
Thus, there is a long felt need for a method and network infrastructure that provides a method to locate an OTT user for RBT services in OTT networks.
Further, such a solution should not require usage of Legacy (i.e. existing) telecom nodes and thus providing a flexibility to extend RBT service in OTT networks without Telecom networks.
Summary
For purposes of summarizing, certain aspects, advantages, and novel features of the disclosure have been described herein. It is to be understood that not necessarily all such advantages may be achieved in accordance with any one particular embodiment of the disclosure. Thus, the present disclosure may be embodied or carried out in a manner that achieves or optimizes one advantage or group of advantages as taught herein without necessarily achieving other advantages as may be taught suggested herein.
It is an object of the present disclosure to provide a method and system for implementing the Location based Ring back tone (CRBT or RBT announcement) for Over the Top (OTT-Voice or OTT) applications.

In an embodiment the present invention provides OTT Login servers /OTT registrars with database storage for OTT users.
In another embodiment the present invention provides OTT call serving nodes or OTT call processing nodes for switching switch outgoing OTT call to incoming OTT call & RBT system.
In another embodiment of the present invention, the present invention provides a method and system of playing the RBT for OTT users based on the OTT user location.
In yet another embodiment the present invention provides a method and system for activation of RBT triggers of OTT users in the RBT system, OTT call node server redirect the calls towards RBT system for playing CRBT.
In an embodiment of the present invention a method is provided for providing context specific location based dynamic information to a user of a telecommunication network by activating an OTT service, sending (19) a synchronization request to a RBT system by OTT login server, subscribing RBT service, updating user information( MSISDN, Userid etc..) and sending back (21) synchronize success in response (20) to said synchronization request, voluntary sending (23) a RBT activation request to a ORS system by an OTT user GUI, enabling user to activate the RBT services via ORS GUI, updating the location of a registered RBT user and wherein OTT user GUI is enabled via RBT request to perform plurality of RBT operations based on RBT play settings.
In an embodiment the present invention a system is provided to provide context specific location based dynamic information to a user of a telecommunication network and the system comprises of at least one OTT user to send a registration request, at least one OTT call node server to receive registration request and activate an OTT service , an OTT login server to send a synchronization request to a RBT system wherein the RBT system subscribes to a RBT service , updates user information( MSISDN, Userid etc.) and sends back synchronize success in response to a synchronization request and updates the location of a registered RBT user, an OTT user GUI to voluntary send a RBT activation request to a ORS system, enable user to activate the RBT services via ORS GUI wherein OTT user GUI is enabled via RBT request to perform plurality of RBT operations based on RBT play settings.

These and other embodiments of the present disclosure will also become readily apparent to those skilled in the art from the following detailed description of the embodiments having reference to the attached figures, the disclosure not being limited to any particular embodiments disclosed.
Brief Description of the Drawings
For a better understanding of the embodiments of the systems and methods described herein, and to show more clearly how they may be carried into effect, reference will now be made, by way of example, to the accompanying drawings, wherein:
FIGURE 1 illustrates an existing OTT registration flow diagram of the prior art
(without RBT system).
FIGURE 2 illustrates an exemplary flowchart depicting a basic OTT Voice call flow
diagram with an existing RBT system of the prior art.
FIGURE 3 illustrates a flowchart depicting an exemplary embodiment of present
invention for subscription of RBT service for an OTT user & synchronization of the user information with such RBT.
FIGURE 4 depicts an exemplary enablement by an ORS system allowing an OTT
user to voluntarily activate the RBT service after OTT registration.
FIGURE 5 illustrates an exemplary ORS system implementation wherein OTT call
node server redirects OTT user calls towards RBT system & RBT system Play the RBT/announcement based on location of the OTT user. FIGURE 5 illustrates an exemplary alternative ORS system implementation.
FIGURE 6 illustrates another embodiment of ORS system implementation, wherein OTT call node server checks the OTT login server for user status & location, sends updated RBT location to RBT service after OTT registration success, of a user who voluntarily subscribed.
FIGURE 7 An exemplary architecture of the present invention
FIGURE 8 An exemplary architecture of the hardware elements of the present invention

Detailed Description
Exemplary embodiments now will be described with reference to the accompanying drawings. The disclosure may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey its scope to those skilled in the art. The terminology used in the detailed description of the particular exemplary embodiments illustrated in the accompanying drawings is not intended to be limiting. In the drawings, like numbers refer to like elements.
The specification may refer to “an”, “one” or “some” embodiment(s) in several locations. This does not necessarily imply that each such reference is to the same embodiment(s), or that the feature only applies to a single embodiment. Single features of different embodiments may also be combined to provide other embodiments.
As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless expressly stated otherwise. It will be further understood that the terms “includes”, “comprises”, “including” and/or “comprising” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. It will be understood that when an element is referred to as being “connected” or “coupled” to another element, it can be directly connected or coupled to the other element or intervening elements may be present. Furthermore, “connected” or “coupled” as used herein may include operatively connected or coupled. As used herein, the term “and/or” includes any and all combinations and arrangements of one or more of the associated listed items.
Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and will

not be interpreted in an idealized or overly formal sense unless expressly so defined herein.
The figures depict a simplified structure only showing some elements and functional entities, all being logical units whose implementation may differ from what is shown. The connections shown are logical connections; the actual physical connections may be different. It is apparent to a person skilled in the art that the structure may also comprise other functions and structures. It should be appreciated that the functions, structures, elements and the protocols used in communication are irrelevant to the present disclosure. Therefore, they need not be discussed in more detail here.
Also, all logical units described and depicted in the figures include the software and/or hardware components required for the unit to function. Further, each unit may comprise within itself one or more components which are implicitly understood. These components may be operatively coupled to each other and be configured to communicate with each other to perform the function of the said unit.
The features provided by the disclosed system in the present disclosure, may be wirelessly accessed remotely, in one or more embodiments, and/or through a wireless network. Such types of wireless network service providers operate and maintain the computing systems and environment, such as server system and architectures. Typically, server architecture includes the infrastructure (e.g. hardware, software, and communication lines) that offers wireless network services. The operations in embodiment of the present invention are performed wirelessly during on-air or air interface.
For the most part, the operations described herein are operations performed by a handset, device, computer or a machine in conjunction with a human operator or user that interacts with the computer or the machine. The programs, modules, processes, methods, data, and the like, described herein are but an exemplary implementation and are not related, or limited, to any particular computer, apparatus, or computer language. Rather, various types of general purpose computing machines or devices may be used with programs constructed in accordance with the teachings described herein.
The present invention provides a method and system to locate an OTT user for RBT services in OTT networks without the need for any Legacy telecom nodes, thus

providing a flexibility to extend RBT service in OTT networks without Telecom
networks.
Figure 1, Figure 2 and Figure 3 illustrate existing OTT implementation(s) including
OTT registration flow and OTT call flow.
Figure 1 depicts an exemplary OTT registration flow diagram.
Here an OTT user (“1”) sends an activation request to an OTT call node server. The
OTT call node forwards (“2”) this activation request to an OTT Login server. The Login
server checks the credential for the OTT user. Thereafter, OTT Login server sends either
(“3”) a verification mobile call or verification code to OTT call node (“4”) for OTT user.
The OTT reverts back with the response (“5”) to OTT call node server, and the response
is forwarded to login server (“6”). Thereafter, OTT login server verifies the response
(“7”), sends back the registration success (“8”) to OTT call node server, and the
registration success is again forwarded to end user (“9”).
Figure 2 illustrates an exemplary OTT Voice call flow diagram, wherein an OTT user1
and OTT user 2 have logged in (“10”) to an OTT login server. Thereafter, OTT user1
calls (“11”) to OTT user2, which is processed (“12”) by OTT call node server. The OTT
call node server processes incoming call (“13”) to OTT user2, which returns with ring
(“14”) to OTT call node server. OTT call node server plays the normal ring (“15”) to
OTT user1. OTT user2 answers the call (“16”). Thereafter, OTT call node server
switches (“17”) with incoming OTT user1. OTT user1 connects (“18”) voice with OTT
user2.
Figure 3 depicts a default mode of OTT RBT subscription where in OTT user
automatically subscribes to RBT service as & when register to OTT service. This
method is useful for RBT features like Add-RBT features.
The OTT user1 is depicted as a user interested to register to OTT service. The OTT user
sends registration request to corresponding OTT call node. The registration request (1)
comprises of at least a mobile number and a user name of the OTT user. Thus, OTT
service registration requires (mobile) phone number and user name for RBT service. A
typical OTT vendor may use any other credential or mechanism to get the Mobile
number of the OTT user.
Thereafter, OTT call node forwards (2) OTT user1 registration request to OTT login
server. The OTT login server is a permanent database/repository for all OTT users.
The OTT Login server sends (3) verification code (or a verification call) to a OTT user1
based on underlying OTT network implementation and either can authenticate the OTT
user credentials.

The present invention does not require a change to existing authorization and
authentication flows for OTT service.
Thus, the OTT user1 gets the verification call (4) from OTT network. Thus, OTT user
must be authentic before registration, and for this OTT network may use any
implementation. ORS systems need not change the existing implementation for
verification of OTT user.
OTT user1 responds (5) to the verification call. OTT call node forwards (6) the
verification response to OTT login server. OTT call node authenticates (7) the OTT user
or forwards (8) authentication request to login server.
OTT login server verifies the login credentials. OTT login server sends registration result to (“8”) OTT user via OTT Call server node (“9”).
Thereafter, the OTT login server sends (19) a synchronization request to RBT system.
The RBT system in response (20) subscribes RBT service and updates user information
and sends back (21) synchronize success.
Figure 4 depicts an exemplary enablement by an ORS system allowing an OTT user to
voluntarily activate the RBT service after OTT registration.
Thus, Figure 4 depicts a voluntarily mode of OTT RBT location update wherein the
OTT user sends activation request to ORS. ORS provides a Graphical user interface
(GUI) on OTT application to access the RBT system. OTT user sends RBT activation
request, RBT download request, RBT Present request, RBT share to Social media,
Location update etc. via ORS GUI.
Referring to Figure 4 “Steps 1 to Step 9” depicts the OTT user registration flow,
which remains same as described with reference to Figure 3 description. Thus, the
steps are in consistent with Call Flow sequence for simpler and efficient
implementation.
Thus, the OTT user voluntarily sends (23) location activation request to ORS system in
GUI. OTT user shows interest to activate the Location update by sending a RBT service
activation or a download request. These are considered as an expression of interest to
activate the RBT service.
The ORS system enables GUI to perform different RBT operations with different RBT
play settings via RBT request.
ORS GUI enables user to activate the Location for the RBT services. If user is an
already registered RBT user then ORS only updates the location, otherwise ORS allows
subscription and updation of the location.

This exemplary method includes a voluntarily updation of the location with GUI, but is
not limited to GUI. Thus, ORS system can provide any means of communication to OTT
user for updating the location & register the service like IVR call, Web portal, Missed
call to some specific number, or by any other way of communication to ORS network.
The OTT call node server forwards OTT user RBT Location activation request (24) to
OTT call login server. This procedure is ORS implementation specific, and such a RBT
location activation request may be forwarded (25) directly to RBT system or via OTT
login Server.
In an embodiment the present invention implements said procedure via OTT login
server. OTT Login server receives the User location information with help of Mobile
GPS.
The location information gets stored in an OTT login server which shares it to RBT
system. In another embodiment the ORS may implement another procedure to update
the location for OTT user like City, country, region, any specific place.
The OTT Login server forwards the RBT location information to RBT system. The ORS
implementation for a voluntarily RBT Location activation differs from a “Default mode”.
The OTT login server develops an interface with a RBT system. OTT login server, in an
embodiment, uses web service interface which passes the user credentials to RBT
system. OTT login server sends Mobile number, User name/ID, Location information or
optionally any other parameters to RBT system in RBT Location request.
The RBT system in ORS, activates a location in RBT system for the OTT user. The RBT
system updates the RBT user information in the RBT database. This updated
information is used to play the RBT.
The RBT system plays the selected download RBT to either all OTT calling users or to a
group of OTT users for either specific time or for a default (users) for all the times.
The configuration used in different embodiments is specific to RBT system. OTT user
may also send RBT activation request for calling RBT service or Called RBT service with
the help of OTT RBT GUI .RBT system returns back the RBT service activation
response to OTT login server.
The ORS system, OTT login server, the RBT service status for OTT users is stored in
OTT login server database. The OTT user RBT status is used to share with OTT call
node server, whenever so requested/required by OTT call node server. The OTT call
node server returns the RBT user Location activation result to the OTT call node server.
The OTT call node server forwards the status to OTT RBT user which now becomes OTT
RBT user.

The OTT RBT user is able to download more than one RBT after OTT RBT service
activation. In one embodiment the ORS OTT RBT user directly accesses RBT system
and in another embodiment ORS OTT RBT user accesses RBT system via OTT network.
This step is optional in ORS but may be used for the OTT RBT user.
Figure 5 illustrates an exemplary ORS system implementation wherein OTT call node
server redirects OTT user calls towards RBT system & RBT system and plays the
RBT/announcement based on location of the OTT user.
Here, OTT user 1 and OTT user 2 are logged on (10) to OTT Login Server. OTT user 1
calls (11) to OTT user 2 via OTT call node server. The call is processed (12) at OTT call
node server. The OTT user 2 receives (13) the incoming call and sends (14) a ring
(alert) to OTT call node server. The call is redirected (29) from OTT call node server to
RBT system which plays (30) the RBT announcement. The OTT call node server
switches (31) the outgoing call and plays (32) RBT announcement to OTT user 1. The
OTT user 2
The OTT user may call back to OTT call node server which sends (33) ‘Release message’
to RBT system. The RBT system reverts with a ‘Release Ack’ message (34) to OTT call
node server which switches (17) incoming and outgoing OTT call and re directs (18) the
answer to OTT user 1.
This procedure is useful for implementing Add-RBT and like features.
FIGURE 6 illustrates another embodiment of ORS system implementation, wherein
OTT call node server checks the OTT login server for user status & location, sends
updated RBT location to RBT service after OTT registration success, of a user who
voluntarily subscribed.
In this embodiment, the OTT call node server asks for the RBT status from OTT Login server before redirecting the call to RBT system.
The OTT Login server checks the OTT user RBT status in database. In case the called or calling OTT user is a subscriber with RBT service, then a “Play trigger” is sent to RBT system. Otherwise OTT Login server directly connects outgoing OTT user to incoming OTT user.
Thus, both OTT user 1 and OTT user 2 are logged in (10) to OTT login server. The OTT user 1 makes a call (11) to OTT user 2. The OTT call node server processes (12) the call and sends the incoming call (13) to OTT user 2. A ring (alert) is sent (14) from OTT user 2 to OTT call node server. The OTT call node server redirects (29) call to RBT

system which plays (30) the RBT. The OTT call node server switches the outgoing call and plays the RBT at OTT user 1.
Thereafter OTT call node server checks the RBT location for calling/called OTT user, triggers (36) a RBT location. A person ordinary skilled in the art will appreciate that the present invention automatically detects the OTT user location without the need of GPS technology. Hence, present invention advantageously reduces the usage of network resources which are otherwise needed to find the location of the user and therefore reduces the usage of power consumption, required to find the location of the user.
The various features of the claimed invention are implemented by various hardware
elements. These hardware elements may employ a combination of software and
hardware means, including embedded processors, to achieve the designated results and /or implement the required technical feature.
The hardware elements of the present invention include but are not limited to call node server, login server, RBT system etc.
A typical architecture of an exemplary hardware elements of the present invention is explained with reference to Figure.
A CPU bus is, essentially, an interconnection wires that all subsystems are connected to. In general, only one pair of devices can talk to each other at a time, so communication of the bus must be coordinated to prevent message collisions. This coordination is often handled by the CPU.
The central processing unit (CPU) executes instructions contained in memory. These instructions are executed at a rate specified by the computer's clock.
The CPU needs to access two different types of memory in order to execute a program. There are two types of memories used in micro-controllers. These are read-only memory (ROM) and random access memory (RAM).
In a micro-controller, read-only memory (ROM) is used to store permanent programs, operating drivers, and data. Many micro-controllers use erasable programmable read¬only memory (EPROM) or electrically erasable programmable read-only memory (EEPROM) to store programs, operating drivers, and data. EPROM and EEPROM are non-volatile memories.
Random access memory or RAM (508) is used to temporarily store data and instructions.

The relevant components of hardware elements of the present invention selectively comprise of:
- Signal control unit (not shown):
• Device: Mainly comprising of CPU + software in memory + rf section, for controlling the bandwidth usage in device.
• Service provider network: Mainly comprising of server + software in memory + rf section, for controlling the bandwidth usage in network.
- Memory unit:
• Device: Mainly comprising of memory, for storing software + data associated with one or more services/tasks/operations as transceived by the said signal control unit.
• Service provider network: Mainly comprising of memory, for storing software + data associated with one or more services/tasks/operations as transceived by the said signal control unit
- Signal processing unit:
• Device: Mainly comprising of CPU + software in memory + speaker, for processing short switching trigger data pulse signal to accomplish the operations by performing output to the speaker after recalling the corresponding service memory from device and confirm to network provider/operator.
• Service provider network: Mainly comprising of server + software in memory, for processing short switching trigger data pulse signal to accomplish the operations by transceiving to device and confirmation from device.

We Claim:
1. A method for providing context specific location based dynamic information to a user of a
telecommunication network , comprising
- activating an OTT service;
- sending (19) a synchronization request to a RBT system by OTT login server
- subscribing RBT service , updating user information( MSISDN,Userid etc..) and sending back (21) synchronize success in response (20) to said synchronization request;
- voluntary sending (23) a RBT activation request to a ORS system by an OTT user GUI;
- enabling user to activate the RBT services via ORS GUI;
- updating the location of a registered RBT user and;
Wherein OTT user GUI is enabled via RBT request to perform plurality of RBT operations based on RBT play settings.
2. The method as claimed in claim 1 , wherein the RBT location activation request is
forwarded (25) is
- directly sent to RBT system or
- via OTT login Server.
3. The method as claimed in claim 1 wherein the ORS provides a Graphical user interface (GUI) on OTT application to access the RBT system.
4. The method as claimed in claim 1, comprising voluntarily updation of the location.
5. The method as claimed in claim 1, wherein login credentials comprise Mobile number, User name/ID.
6. The method as claimed in claim 1, wherein ORS provides a Graphical user interface (GUI) on OTT application to access the RBT system.
7. The method as claimed in claim 1, wherein OTT call node server is configured to
- check OTT login server for user status and location and

- send updated RBT location to RBT service after OTT registration success, of a
subscribed user.
8. The method as claimed in claimed 1, wherein OTT user location is detected
automatically without GPS technology.
Reduces the usage of network resources which is used to find the location of the user Reduces the usage of power consumption, required to find the location of the user.
9. A system for providing context specific location based dynamic information to a user of a
telecommunication network , comprising
- At least one OTT user to send a registration request;
- At least one OTT call node server to receive registration request and activate an OTT service ;
- An OTT login server to send a synchronization request to a RBT system wherein the RBT system subscribes to a RBT service , updates user information( MSISDN, Userid etc.) and sends back synchronize success in response to a synchronization request and updates the location of a registered RBT user;
- An OTT user GUI to voluntary send a RBT activation request to a ORS system, enable user to activate the RBT services via ORS GUI;
wherein OTT user GUI is enabled via RBT request to perform plurality of RBT operations based on RBT play settings.
10. A system as claimed in claim 9 and configured to perform the steps as claimed in claims
1 to 8.

Documents

Application Documents

# Name Date
1 Power of Attorney [31-12-2015(online)].pdf 2015-12-31
2 Form 5 [31-12-2015(online)].pdf 2015-12-31
3 Form 3 [31-12-2015(online)].pdf 2015-12-31
4 Form 18 [31-12-2015(online)].pdf 2015-12-31
5 Drawing [31-12-2015(online)].pdf 2015-12-31
6 Description(Complete) [31-12-2015(online)].pdf 2015-12-31
7 Other Patent Document [30-06-2016(online)].pdf 2016-06-30
8 7160-CHE-2015-Correspondence-Form 1-080716.pdf 2016-07-29
9 7160-CHE-2015-PA [26-04-2018(online)].pdf 2018-04-26
10 7160-CHE-2015-ASSIGNMENT DOCUMENTS [26-04-2018(online)].pdf 2018-04-26
11 7160-CHE-2015-8(i)-Substitution-Change Of Applicant - Form 6 [26-04-2018(online)].pdf 2018-04-26
12 Correspondence by Agent_Assignment, Form6_03-05-2018.pdf 2018-05-03
13 7160-CHE-2015-FER.pdf 2019-11-26
14 7160-CHE-2015-PETITION UNDER RULE 137 [07-04-2020(online)].pdf 2020-04-07
15 7160-CHE-2015-OTHERS [07-04-2020(online)].pdf 2020-04-07
16 7160-CHE-2015-FORM-26 [07-04-2020(online)].pdf 2020-04-07
17 7160-CHE-2015-FER_SER_REPLY [07-04-2020(online)].pdf 2020-04-07
18 7160-CHE-2015-DRAWING [07-04-2020(online)].pdf 2020-04-07
19 7160-CHE-2015-COMPLETE SPECIFICATION [07-04-2020(online)].pdf 2020-04-07
20 7160-CHE-2015-CLAIMS [07-04-2020(online)].pdf 2020-04-07
21 7160-CHE-2015-ABSTRACT [07-04-2020(online)].pdf 2020-04-07
22 7160-CHE-2015-US(14)-HearingNotice-(HearingDate-27-06-2022).pdf 2022-05-31
23 7160-CHE-2015-Correspondence to notify the Controller [24-06-2022(online)].pdf 2022-06-24
24 7160-CHE-2015-Written submissions and relevant documents [11-07-2022(online)].pdf 2022-07-11
25 7160-CHE-2015-PatentCertificate07-10-2022.pdf 2022-10-07
26 7160-CHE-2015-IntimationOfGrant07-10-2022.pdf 2022-10-07
27 7160-CHE-2015-Form 1-080716.pdf 2023-06-17

Search Strategy

1 Searchstrategy_23-10-2019.pdf

ERegister / Renewals

3rd: 27 Dec 2022

From 31/12/2017 - To 31/12/2018

4th: 27 Dec 2022

From 31/12/2018 - To 31/12/2019

5th: 27 Dec 2022

From 31/12/2019 - To 31/12/2020

6th: 27 Dec 2022

From 31/12/2020 - To 31/12/2021

7th: 27 Dec 2022

From 31/12/2021 - To 31/12/2022

8th: 27 Dec 2022

From 31/12/2022 - To 31/12/2023

9th: 14 Nov 2023

From 31/12/2023 - To 31/12/2024

10th: 22 Nov 2024

From 31/12/2024 - To 31/12/2025