Sign In to Follow Application
View All Documents & Correspondence

Rescheduling Download Of A Content In A Radio Access Network

Abstract: Example implementations relate to technique for rescheduling download of a content in a radio access network. For example, a method includes receiving a request to download the content from a computing system of the radio access network and identifying the content to be a re-schedulable content based on content analysis parameters, where the content analysis parameters are indicative of at least size and type of the content. The method also includes determining service timing of the radio access network to be a congestion timings based on traffic throughput of the radio access network and prompting the computing system to reschedule the download of the content. The method further includes rescheduling the download of the content to another service timing of radio access network.

Get Free WhatsApp Updates!
Notices, Deadlines & Correspondence

Patent Information

Application #
Filing Date
17 August 2015
Publication Number
08/2017
Publication Type
INA
Invention Field
COMMUNICATION
Status
Email
iprdel@lakshmisri.com
Parent Application
Patent Number
Legal Status
Grant Date
2023-01-09
Renewal Date

Applicants

BHARTI AIRTEL LIMITED
Bharti Airtel Limited, Bharti Crescent, 1 Nelson Mandela Road, Vasant Kunj, Phase II, New Delhi – 110070, India

Inventors

1. VARAPRASAD, CVN
H.No 1802 Tower-3 Nirvana county Gurgaon 122001, India
2. ROYZADA, Gaurav
2nd Floor 343 Sec -15 part -1 Gurgaon 122001, India

Specification

BACKGROUND
[0001] In past few years there has been widespread increase in internet
usage by users. Also, as the users tend to download more and more content from
the Internet there has been significant increase in data traffic over radio access
10 networks (RAN). This drastic increase in the data traffic has been more
significant in RAN due to widespread of on-the-go devices, such as smartphones,
tablets, and personal digital assistants. Possession of such devices with almost
every other user has changed user internet habits and data consumption pattern to
a great extent. Users often request the network service providers for online
15 streaming of content, such as audio files, videos and live TV, online gaming, eshopping,
real-time file sharing, live videos, VOIP calling and teleconferencing,
peer to peer (P2P) file sharing, emailing and other downloading of various
different type of contents which contribute to the data traffic. Different types of
the data traffic over the RAN have different Quality of Service (QOS)
20 requirements. QOS facilitates in measuring overall performance of the RAN.
BRIEF DESCRIPTION OF DRAWINGS
[0002] The detailed description is provided with reference to the
accompanying figures. In the figures, the left-most digit(s) of a reference number
25 identifies the figure in which the reference number first appears. The same
numbers are used throughout the drawings to reference like features and
components.
3
[0003] Fig. 1 illustrates an example computing environment,
implementing a Download Management System (DMS) for rescheduling
download of a content in a Radio Access Network (RAN), according to an
example implementation of the present subject matter;
[0004] Fig. 2 schematically illustrates various elements of the DMS 5 and a
computing system, coupled to the DMS, according to an example implementation
of the present subject matter;
[0005] Fig. 3(A) and 3(B) illustrates an example method for rescheduling
the download of the content in the RAN, according to an example
10 implementation of the present subject matter;
[0006] Fig. 4 illustrates an example method for facilitating a rescheduled
download of the content in the RAN, according to an example implementation of
the present subject matter;
[0007] Fig. 5(A) and 5(B) is an example method of rescheduling the
15 download of the content in the RAN, according to an example implementation of
the present subject matter;
[0008] Fig. 6 illustrates a an example method of determining a service
timing of the RAN to be a congestion timing, according to another example
implementation of the present subject matter;
20 [0009] Fig. 7 illustrates a call flow, indicating procedure for rescheduling
the download of the content in the RAN , according to an example
implementation of the present subject matter;
[0010] Fig. 8 illustrates a call flow diagram indicating procedure for
rescheduling the download of the content, during an interruption in the download,
25 in the RAN , according to an example implementation of the present subject
matter;
[0011] Fig. 9 illustrates a call flow diagram indicating procedure for
rescheduling the download of the content, on receiving multiple content
4
download requests simultaneously, in the RAN , according to an example
implementation of the present subject matter;
DETAILED DESCRIPTION
[0001] The present subject matter relates to techniques for rescheduling a
download of content in a radio access network (RAN). The methods and system5 s
as described herein facilitates in identifying a service timing of the RAN to be a
congestion timing and providing options to a user for rescheduling the download
of the content.
[0002] In order to provide good quality of user experience and meet
10 Quality Of Service (QOS) requisites for different variety of data traffic, network
service providers periodically upgrade network infrastructure to latest standards,
and increased backhaul bandwidth. However, an exponential growth in the
number of users and thereafter the data traffic of RAN, soon neutralizes the
effects of the upgradation. Also, with the increase in the variety of the data traffic
15 and overall data consumption, the network often experiences sudden increase and
decrease in number of requests from the users for downloading a content. Sudden
and persistent rise in number of such requests from the users for utilizing network
bandwidth simultaneously overloads the RAN. Overloading of RAN further leads
to network congestion, thereby resulting in deterioration in the QoS. The
20 congestion of RAN may also occur due to multiple other factors such as Denial
of Service (DOS) Attacks, compromised network entities, backbone network
failure, server faults, etc.
[0003] Congestion in RAN causes delay in sending responses
corresponding to incoming content downloading requests. This impacts user
25 experience which is often attributed by, slowness of browsing, stuttering of
videos, sluggish download of contents, and loss of audio and video frames in
video conferencing or live programs. Also, in other situations, an ongoing
download may get interrupted due to RAN congestion. Occurrence of such
situations leads to overall bad user experience as a high amount of user’s time
5
gets consumed in waiting for the response corresponding to content downloading
requests. Further, even after consuming significant time, while waiting for the
response, the user may not be able to receive the content of desired quality. For
example, corresponding to a request for an online video to be streamed, the user
may need to wait long for the video to get buffered. In such cases, with 5 h no
alternate left for the user, the user may need to request for a low quality of the
requested video.
[0004] Known methods of managing data traffic involves controlling of
network parameters like traffic handling profile (THP), Allocation and retention
10 priority (ARP) and QoS, or distributing data traffic over multiple radio access
type (RAT) by selection of the most suitable access network, or by
simultaneously utilizing all available radio access networks. However, such
techniques for managing data traffic do not differ in operations based on the type
and size of content to be downloaded, and thereby provide similar solution of
15 management for small and large sizes of download. Thus, as soon as there is a
significant increase in overall data traffic, existing methods becomes ineffective,
as such methods may not be able to prioritize or schedule the incoming content
download requests depending upon the size and type of the content. Such existing
methods operate in a similar manner for any size of the content varying from
20 kilobytes, megabytes, gigabytes and so on, and the type of the content which may
be a live feed, streaming of a video or an audio file download, or an executable
file for upgrading an operating system. In a way, even in the periods of
congestion, with no alternate option of offloading some of the incoming content
download requests, the RAN has to acknowledge the downloading for all of
25 incoming content irrespective of the type and size of the content, which results in
addition in the data traffic and further, poor traffic management on the RAN.
[0005] According to example implementations of the present subject
matter, techniques for rescheduling download of content in a RAN are described.
The described techniques may allow managing data traffic in the RAN by
30 providing users operating a computing system with options to reschedule the
6
download of the content. Further, the techniques may facilitate downloading of
the content at a rescheduled service timing of the RAN.
[0006] In one example implementation, the computing system may send a
content download request to a Download Management Server (DMS), for
downloading of the content. The content can be of multiple types, such as, 5 , an
audio file, a video file, a text file, an executable file for updating operating
system, etc. The content requested for the download may be of varying size
depending upon the type of the content. Upon receiving the content download
request, the content may be identified to be a re-schedulable content based on
10 content analysis parameters. The content analysis parameters may indicate the
type and size of the content. In one implementation, the DMS may identify the
content to be re-schedulable if the size of the content may be more than a predefined
size limit. The pre-defined size limit may be defined by the DMS
depending upon current traffic on the RAN. For example, a video file for a movie
15 may be of hundreds of megabytes in size and may be considered as reschedulable.
In another example, the DMS may identify a requested content to be
re-schedulable where the content includes the executable file for updating the
operating system which may be of gigabytes in size. In other example, the DMS
may identify the content to be non re-schedulable if the content includes a PDF
20 document or a word file. Further in the said example, the DMS may also identify
the content to be re-schedulable based on the type of the content. Consideration
of the type of the content for re-scheduling may be done essentially to meet the
quality of the content to be downloaded as desired by the user. For example, or a
video file to be streamed online may be identified as the re-schedulable content.
25 In the said example implementation, upon identifying the content to be the reschedulable
content, service timing of the RAN may be accessed. The service
timing of the RAN may indicate either a congestion timing or a non-congestion
timing, depending upon a traffic throughput of the RAN. For example, the service
timing of the RAN may be the congestion timing when the RAN experiences a
30 congestion i.e. a throughput expected from the RAN becomes more than an
7
available bandwidth of the RAN. The accessing of service timing of RAN may be
done to determine whether the RAN is congested. Further to the assessment of
service timings, location of the computing system may also be determined. The
user may be located in a home network or a roaming network defined by the
network provider for the user. In one example, the location of the comp5 uting
system may be determined based on cell identifier of RAN cellular structure or
computing system’s Public Land Mobile Network (PLMN) circle.
[0007] Upon assessing the RAN service timing to be congestion timing
and the computing system to be located in computing system’s home network, a
10 prompt for rescheduling the download may be sent to the computing system. The
prompt may include options of different available service timings at which the
computing system can reschedule the download. For example, in situations when
the user requested for the downloading of the content during a day time such as
afternoon, the user may be prompted to re-schedule the download of the content
15 during an available service timings such as mid-night. In an example
implementation of the present subject matter, the DMS may receive rescheduling
details which includes computing system’s choice amongst any of the available
service timings provided in the prompt, for rescheduling the download. Further,
upon receiving the rescheduling details from the computing system, a response
20 may be sent to the computing system for facilitating a re-scheduled download, at
a point of time received as the re-scheduled service timings in the rescheduling
details. The response may comprise a header including a set of tokens allocated
to the computing system for facilitating a rescheduled download.
[0012] In one of the example implementations, further to rescheduling the
25 download of the content by the computing system, a rescheduling initiation
prompt may be sent to the computing system for initiating the re-scheduled
download. In one example, the re-scheduling initiation prompt may be a reminder
or a notification sent by the DMS at the re-scheduled service timings chosen by
the computing system. Upon receiving the rescheduling initiation prompt, the
30 rescheduled download is facilitated based on the validation of the allocated
8
tokens to the computing system. Thus, using the described techniques, a network
service provider operating the DMS may effectively manage a high amount of
traffic on the RAN, by prioritizing and re-scheduling incoming requests for
facilitating download of the content. Further, the RAN may ensure consistent
delivery of the content requested from different computing systems within 5 in the
RAN, without compromising on any of the QOS requisites. Effective
management of data traffic on the RAN ensures that the services offered by the
RAN are consistently available to the end users, thereby providing a better user
experience. The above techniques are further described with reference to figures,
10 Fig. 1 to Fig. 9. It should be noted that the description and figures merely
illustrate the principles of the present subject matter along with examples
described herein and, should not be construed as a limitation to the present
subject matter. It is thus understood that various arrangements may be devised
that, although not explicitly described or shown herein, embody the principles of
15 the present subject matter. Moreover, all statements herein reciting principles,
aspects, and embodiments of the present subject matter, as well as specific
examples thereof, are intended to encompass equivalents thereof.
[0013] Fig. 1 illustrates a computing environment 100, implementing a
download management system (DMS) 102 for rescheduling download of a
20 content in a Radio Access Network (RAN) 104, according to an example
implementation of the present subject matter. The computing environment 100
may either be a public distributed environment or may be a private closed
computing environment. The computing environment 100 further comprises
multiple computing systems 106-1, 106-2, 106-3…106-N and an origin server
25 108, according to an example implementation of the present subject matter. For
the purpose of understanding the computing systems 106-1, 106-2, 106-3…106-
N are commonly referred to as computing systems 106, hereinafter. According to
an implementation of the present subject matter, the DMS 102 may be
implemented as, but is not limited to, a server, a workstation, a computer, and the
9
like. The DMS 102 may also be a machine readable instructions-based
implementation or a hardware-based implementation or a combination thereof.
[0014] According to an example implementation, the DMS 102 may
communicate with different entities of the computing environment 100, such as
the computing systems 106 and the origin server 108. The RAN 104 may 5 be an
individual network or a collection of many such individual networks,
interconnected with each other and functioning as a single large network, e.g., the
Internet or an intranet. The RAN 104 may be implemented as one of the different
types of networks, such as intranet, local area network (LAN), wide area network
10 (WAN), and such. The RAN 104 may either be a dedicated network or a shared
network, which represents an association of the different types of networks that
use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP),
Transmission Control Protocol/Internet Protocol (TCP/IP), etc., to communicate
with each other.
15 [0015] The RAN 104 may also include individual networks, such as, but
are not limited to, Global System for Communication (GSM) network, Universal
Telecommunications System (UMTS) network, Long Term Evolution (LTE)
network, Personal Communications Service (PCS) network, Time Division
Multiple Access (TDMA) network, Code Division Multiple Access (CDMA)
20 network, Next Generation Network (NGN), Public Switched Telephone Network
(PSTN), and Integrated Services Digital Network (ISDN). Depending on the
implementation, the RAN 104 may include various network entities, such as base
stations, gateways and routers; however, such details have been omitted to
maintain the brevity of the description. Further, it may be understood that the
25 communication between the DMS 102, the computing systems 106, and the
origin server 108, and other entities may take place based on the communication
protocol compatible with the RAN 104.
[0016] In one of the said example implementation, the computing systems
106 and the origin server 108 may include, but are not restricted to, servers,
30 workstations, desktop computers, laptops, smart phones, personal digital
10
assistants (PDAs), tablets, virtual hosts, applications, and the like. The origin
server 108 may include the servers located at any of the content providers. The
content providers may provide multiple types of content such as music files, on
demand videos, live TV streaming etc., to the users of the RAN.
[0017] In one example implementation, the DMS 102 may 5 perform rescheduling
the download of the content in the RAN 104. The DMS 102 may reschedule
the download of the content upon identifying the content to be a reschedulable
content and accessing a service timing of the RAN 104 to be a
congestion timing. The DMS may further, facilitate a re-scheduled download of
10 the content at re-scheduled service timings of the RAN. In said example
implementation, the DMS 102 may include a rescheduling module 110 to
reschedule the download of the content in the RAN 104
[0018] Although the DMS 102 may perform rescheduling the download
of the content based on the elements described in the example implementation,
15 the DMS 102 may also perform other functionalities and may include other
different elements. Such example functionalities and example elements have been
described in more detail in reference to Fig. 2.
[0019] Fig. 2 schematically illustrates elements of the DMS 102 and the
computing system 106, in accordance with an example implementation of the
20 present subject matter. The DMS 102 may interact with the computing system
106 for rescheduling the download of the content in the RAN 104. The DMS 102
and the computing system 106 may include processors 202-1 and 202-2 to run at
least one operating system and other application and services. The DMS 102 and
the computing system 106 may also include, interface(s) 204-1 and 204-2, and
25 memory(s) 206-1 and 206-2, coupled to the processors 202-1 and 202-2
respectively.
[0020] The processors 202-1 and 202-2 may be implemented as
microprocessor(s), microcomputer(s), microcontroller(s), digital signal
processor(s), central processing unit(s), state machine(s), logic circuit(s), and/or
30 any device(s) that manipulates signals based on operational instructions. Among
11
other capabilities, the processor may fetch and execute computer-readable
instructions stored in a memory. The functions of the various ‘processor(s)’ may
be provided through the use of dedicated hardware as well as hardware capable of
executing machine readable instructions.
[0021] The interface(s) 204-1 and 204-2 may include a variety o5 f
machine readable instructions-based interfaces and hardware interfaces that allow
the DMS 102 and the computing system 106 to interact with different entities,
such as the processors 202-1 and 202-2, the memory(s) 206-1 and 206-2, and
other entities. Further, the interface(s) 204-1 and 204-2 may enable the
10 components of the DMS 102 and the computing system 106 to communicate with
other communication and computing devices, such as the origin server 108, other
web servers and external repositories.
[0022] According to one of the example implementation, as described in
Fig. 2, the DMS 102 and the computing system 106, may further include, modules
15 208-1 and 208-2 for implementing various different functionalities of the DMS
102 related to the present subject matter. The modules 208-1 and 208-2 may
include routines, programs, objects, components, data structures, and the like,
which perform particular tasks or implement particular abstract data types. The
modules 208-1 and 208-2 may include communication modules 210-1 and 210-2,
20 respectively, for performing communication of the DMS 102 and the computing
system 106 with other entities. The modules 208-1 and 208-2 may further include
other modules 212-1 and 212-2, which may supplement additional applications of
the DMS 102 and the computing system 106 respectively.
[0023] In one example implementation of the present subject matter, the
25 DMS 102 and the computing system 106 may further include data 214-1 and 214-
2 which serves, amongst other things, as a repository for storing data that may be
fetched, processed, received, or generated by one or more of the modules 208-1
and 208-2, respectively. Further, the data 214-1 and 214-2 may include token data
216-1 and 216-2 which may serve as a repository for storing token related data.
30 The data 214-1 and 214-2 may also include other data 218-1 and 218-2 for storing
12
any other data to be utilized by the different modules of the DMS 102 and the
computing system 106. In one of the example implementation, the data 218-1
corresponding to the computing system 106 may further include reschedule details
220 which indicates data related to rescheduling of a downloadable content.
[0024] In one of the example implementation, the DMS 102 may include 5 e an
analysis module 222 for analyzing the content to be re-schedulable content for
the download. The DMS 102 may also include the rescheduling module 110 for
re-scheduling the download of the content, in accordance with one of the example
implementations of the present subject matter.
10 [0025] The following description describes the functionality of the DMS
102 in conjunction with the computing system 106 in accordance with Fig. 2, for
rescheduling the download of the content in the RAN 104. According to an
example implementation of the present subject matter, multiple end users may
operate the computing system(s) 106. Therefore, for the ease of explanations and
15 clarity, the communications initiated by the users, are referred as the
communications performed by the computing system 106, hereinafter throughout
the description.
[0026] According to one of the example implementations of the present
subject matter, the analysis module 222 of the DMS 102 may receive a request
20 for the download of the content from the computing system 106. For example, the
DMS 102 may receive a HTTP GET request for the download of the content
from the computing system 106. The HTTP GET request may include, a Uniform
Resource Indicator (URI) including content attributes indicative of details of the
content to be downloaded. In another example implementation, the DMS 102
25 may receive more than one HTTP GET requests from multiple computing
systems 106 for downloading either the same content or different contents. In the
said example implementation of the present subject matter, the requests received
by the DMS 102 may not be restricted to HTTP GET requests, and in other
example implementations, the requests received by the DMS 102 may be a HTTP
30 Post. The HTTP based communication between the DMS 102 and the computing
13
system 106 may utilize any of other well known HTTP methods other than GET
and POST.
[0027] In the said example implementation, upon the receipt of the request,
the analysis module 222 may further identify the content to be the re-schedulable
content based on content analysis parameters. In one example, the conten5 t
analysis parameters may be derived by processing the URI and extracting the
content attributes of the HTTP GET request. The content analysis parameters
may indicate a size and type of the content, according to an example
implementation of the present subject matter. For example, the type of the
10 content may be an audio file, a video file, a word document, a PowerPoint
presentation, a PDF document or a file executable for upgrading an operating
system. Further, the content may of different sizes depending upon the type of the
content, such as, the audio file may be of few megabytes in the size and the file
executable for upgrading the operating system may be of gigabytes in the size. In
15 one example, the DMS 102 may identify the content requested for the download
to be re-schedulable content if the size of the content becomes more than a predefined
size limit. The DMS 102 may determine the pre-defined size limit based
on data traffic on the RAN. For example, the DMS 102 may identify the file
executable for upgrading the operating system to be the re-schedulable content,
20 as the size of the file may be in gigabytes. Further, the DMS 102 may also
identify the content to be re-schedulable based on the type of the content. For
example, a live video feed requested for the download, may be identified as the
re-schedulable content as the video feed may need to be buffered and delivered
seamlessly on the computing system 106. Although, the content analysis
25 parameters may indicate the type and the size of the content based on the
description specified in the above example implementation, in other example
implementations, DMS 102 may identify the content to be the re-schedulable
content based on the other content analysis parameters such as urgency or a
user’s priority for receiving the content. For example, a user operating the
30 computing system 106 may request for downloading an important word
14
document for which the user may be in urgent need. The user may also request
for downloading the file executable for upgrading the operating system, for
which the user might not be in the urgent need. The DMS 102 may identify the
word document to be the non-reschedulable content and the file executable for
upgrading the operating system to be the re-schedulable cont5 ent.
[0028] In the said example implementation, the analysis module 222 of the DMS
102 may access a service timing of the RAN 104. In one example, the service
timing of the RAN 104 may be congestion timing or a non-congestion timing
depending upon a network traffic throughput of the RAN 104. The congestion
10 timing of the RAN 104 may indicate the service timings of the duration when the
RAN 104 experiences congestion. For example, the RAN 104 may be overloaded
due to sudden increase in data traffic. In such situations, the RAN 104 may be
expected to handle a traffic throughput more than a bandwidth available with the
RAN 104, which may lead to deterioration of quality of services provided by the
15 RAN 104. Therefore, the RAN 104 may experience congestion. Such service
timings of the RAN 104 when the RAN 104 experiences the congestion may be
referred to be congestion timings. On the other hand, the service timings may be
referred to be non-congestion timings, when the data traffic on the RAN 104
decreases and the RAN 104 may seamlessly provide services to the computing
20 systems 106 within the RAN 104. In one example, an available service timing of
the RAN 104 may be the non-congestion timings.
[0029] In one of the example implementation, the analysis module 222 may
monitor real-time network parameters indicating attributes of network utilization.
According to one example implementation, the real-time network parameters
25 may include: number of users using voice services, number of users using data
services, type of applications used by the users, information about movement of
users from within or outside of cell of the RAN 104, handover between the cells,
signaling and bandwidth utilization of cell sites within the RAN 104, round trip
time (RTT) information for request-response, voice and data call failure index at
30 an instant, and radio traffic channel utilization at an instant.
15
[0030] The network parameters described above may not be constant and may
vary from time to time, for example, week of the day, hour of the day, special
event in city, periods of festivals, etc. In another example implementation, the
analysis module 222 may also monitor other real-time network parameters other
than the ones explained in the description provided 5 d above.
[0031] Further, the analysis module 222 may compute a network parameter
indices based on the monitored network parameters. The network parameter
indices may be any value useful for determining network traffic throughput. In
one example, the network parameter indices may be geo-utilization index,
10 services usage index, motion index, video performance index, bandwidth usage
index or any other network parameter indices. The analysis module 222 may
further determine the network traffic throughput based on the computation of
network parameter indices, according to one of the example implementations of
the present subject matter. In one example, the analysis module 222 may
15 determine the service timing of the RAN 104 to be congestion timing if the
network traffic throughput is above a pre-defined limit.
[0032] In the said example implementation, the analysis module 222 may further
determine a location of the computing system 106 to be in computing system’s
home location. The determination of the location is performed to identify whether
20 the computing system 106 is located in a roaming network or within the
computing system’s home network. In one example, the computing system’s
home network or the roaming network may be defined by the network provider.
The computing system’s home network may be determined by the network
provider based on cell identifier of RAN cellular structure or computing system’s
25 Public Land Mobile Network (PLMN) circle. The network provider may propose
different billing rates for the users operating the computing system 104
depending upon the location of the computing systems 106 to be in the home
network or the roaming network.
16
[0033] Upon the assessment of the service timing and determination of the
location by the analysis module 222, the communication module 210-2, may send
a prompt to reschedule the download of the content at one of available service
timings, to the computing system 106.
[0034] In one example implementation, when the computing system 106 may 5 be
located in the roaming network, the DMS 102 may continue for facilitating the
download at current service timings. Thus, according to the said example
implementation, the prompt for re-scheduling the download of the content is sent,
in situations, when the computing system is located in the computing system’s
10 home network and when the RAN 104 is experiencing congestion. In the said
example implementation, the prompt may include multiple options of available
service timings provided to the computing system 106. Further, the available
service timings may be from amongst the non-congestion timings of the RAN
104. In one example, the prompt may look like a pop-up interface having
15 multiple selectable options implemented using selectable icons or radio buttons
or drop-down menus, which can be displayed to the screen of the computing
system 106. Thus, the computing system 106 may choose one of the available
service timings, by selecting one of the options, for rescheduling the download of
the content at a later point of time.
20 [0035] Further, in response to the prompt sent to the computing system 106, the
communication module 210-2 may receive re-scheduling details from the
computing system 106 to re-schedule the download of the content. The rescheduling
details may include a re-scheduled service timing of the RAN 104. In
one example, the re-scheduled service timing of the RAN 104 may indicate the
25 service timings at which the computing system 106 may desire to re-schedule the
download of the content. For example, upon receiving the prompt to re-schedule
the download of the content, the user may respond back to the DMS 102 with the
service timings referred here as re-scheduled service timings, at which the user
may want to re-schedule the download of the content. In one example, the re30
scheduled service timing may be one of the available service timings provided as
17
the option in the prompt sent to the computing system 106. In addition to the rescheduled
service timing the re-scheduling details may also include other
information associated with the re-scheduling of the content. For example, in one
implementation, the re-scheduling details may also include a preference order of
the re-scheduled service timing selected by the computing system 5 106.
[0036] In the said example implementation, upon receiving the re-scheduled
service timings from the computing system 106, the rescheduling module 110
may send a response to the computing system 106 to reschedule the download of
the content at the rescheduled service timing. According to one of the example
10 implementation, the response may include a set of tokens allocated to the
computing system 106 for facilitating the re-scheduled download at the
rescheduled service timings of the RAN 104. The allocated tokens may be unique
to the computing system 106 and the content requested for the download. In one
example, the set of tokens may be included in a header of the response. The set of
15 tokens may be generated by the re-scheduling module 110, using identifiers
associated with the content and the computing system 106. The identifier
associated with the computing system 106 may be a value which uniquely
identifies the computing system 106 such as, a Mobile Station International
Subscriber Directory Number (MSISDN), an International mobile subscriber
20 identity (IMSI) etc. In one example, the response may be a HTTP response
including a HTTP header which includes the set of tokens for facilitating the
rescheduled download of the content at the rescheduled service timing. In another
example, the tokens may be added to a URI, included in the HTTP request. In
another example implementation, for facilitating secure use of the tokens, the set
25 of tokens may be further encrypted using RC4 encryption mechanism. In one
example implementation, the DMS 102 may disconnect an established
connection with the computing system 106 after allocation of the tokens.
[0037] Once a content download is rescheduled and the tokens are
allocated, the download of the content may occur at a later point in time, as
30 chosen by the user, and confirmed by the DMS. In one implementation, to
18
facilitate download of the content at a later point in time, the communication
module 210-2 of the DMS 102 may send a rescheduled download initiation
prompt for initiating the re-scheduled download. In one example, the download
initiation prompt may be sent at the re-scheduled service timings received
previously from the computing system 106. In another example impleme5 ntation,
the communication module may send the download initiation prompt at any of
the available service timings determined by the analysis module 222. In one
example, the prompt may be a pop-up or a notification or a reminder to the
computing system for facilitating the re-scheduled download, which may be
10 displayed to the screen of the computing system 106.
[0038] Once the DMS 102 sends the re-scheduled download initiation prompt,
the DMS 102 waits for an acknowledgement from the computing system 106. For
example, the DMS 102 may send the prompt for initiating the re-scheduled
download to the user and may wait for a response from the user. In one example
15 implementation, the communication module 210-2 may receive the set of tokens
from the computing system 106 for the re-scheduled download of the content. For
example, the communication module 210-2 may receive a HTTP request from the
computing system 106 including the set of tokens allocated previously for the rescheduled
download. Although, the communication module 210-2 of the DMS
20 102 initiates the re-scheduled download based on the description provided in the
above example implementation, in another example implementation, the
communication module 210-1 of the computing system 106 may also initiate the
re-scheduled download by sending the set of allocated tokens to the DMS 102.
[0039] In said example implementation, upon receiving the set of tokens, the
25 analysis module 222 may further validate the set of tokens based on
corresponding content requested previously and associated computing system’s
credentials. For example, the analysis module 220 may validate that the
computing system 106 requesting the re-scheduled download is the same
computing system 106 which previously requested for the re-scheduling of the
30 content.
19
[0040] Further in the said example implementation, upon the validation of the set
of tokens, the analysis module 220 may determine an account balance in a
computing system’s user account to be sufficient for the initiation or completion
of the re-scheduled download. In one example, the communication module 210-2
may send an error message to the computing system 106 if the comp5 uting
system’s 106 user account balance is not sufficient to proceed with the rescheduled
download. For example, the error message may include “Rescheduled
download not possible. Insufficient balance.” Furthermore, in the said example
implementation, the communication module 210-2 may facilitate the re10
scheduled download upon the validation of the tokens and the determination of
account balance.
[0041] In one example, the communication module 210-2 may communicate
with the origin server 108 to provide a URL on which the content requested for
downloading is located. In one example, the origin server 108 may be any server
15 associated with a content provider. The content providers may store different
types of contents, such as, music files, movies etc. in a database of the origin
server 108. There may be multiple origin servers 108 associated with the content
providers. In one implementation, the DMS 102 may forward the content
downloading request received from the computing system 106 to the origin server
20 108. The origin server 108 may respond back to the DMS 102 with the content
requested for download, which the DMS 102 forwards to the computing system
106. The DMS 102 may act as an intermediate entity managing the download of
the content between the computing system 106 and the origin server 108. The
communication module 210-2 may facilitate the re-scheduled download of the
25 content by forwarding the URL received from the origin server 108, to the
computing system 106.
[0042] In addition to the said example implementation, the DMS 102 may
additionally perform a resource requirement check indicating sufficient resource
availability at the computing system 106, before facilitating the rescheduled
30 download. In one example, the communication module 210-2 may send a HTTP
20
request for status information at the computing system 106. In response to the
sent HTTP request, the communication module 210-2 may receive a response
including the status information from the computing system 106. The status
information may include details of free memory and remaining battery capacity
of the computing system 106. Further, upon the receipt of the status inform5 ation,
the analysis module 222 may determine a sufficient memory and battery of the
computing system 106 to initiate the rescheduled download of the content. For
example, in one situation the battery of the computing system 106 may be 80%
available which may be sufficient enough to initiate and complete the re10
scheduled download. In other example, the computing system 106 may request
for the download of the content of size 200mb, and free memory of the
computing system 106 may be 15Gb which may be sufficient enough to complete
the re-scheduled download. Thus, in such cases the DMS 102 may facilitate the
re-scheduled download of the content.
15 [0043] In another example, the analysis module 222 may also determine an insufficient
memory and battery of the computing system 106 to prompt an error
message to the computing system 106. For example, in one situation, the
available battery of the computing system may be 7% which may be in-sufficient
to complete the re-scheduled download. Upon the determination of the in20
sufficient memory and battery, the communication module 210-2 may send a
prompt to the computing system 106. . In one example, the free memory
available at the computing system 106 may be 100mb and the user may request
for downloading the content of size 1 GB. In such situations the DMS 102 may
send a prompt indicating in-sufficient resource availability at the computing
25 system 106. Further, in one example, the prompt may also notify the user to plug
in a battery-charger to continue the rescheduled download or to delete junk data
for de-allocating occupied memory, according to one example implementation
related to present subject matter.
[0044] In addition to the example implementation related to the present subject
30 matter described above, the analysis module 220 may be further configured to
21
identify a change in the location of the computing system 106 from a congested
network to a non-congested network. In one example, the location of the
computing system 106 may be determined based on a cellular identity of the
RAN’s 104 cellular structure including the computing system 106. There may be
multiple cellular identities such as cell_id1, cell_id2, cell_id3 and so on wi5 thin
the RAN’s 104 cellular structure For example, the DMS 102 may identify the
change in the computing system’s location from cell_id 1 to cell_id 2 where
cell_id1 corresponds to the congested network and cell_id2 corresponds to the
non-congested network, In one implementation, the network congestion may be
10 determined based on the assessment of the service timings of the network to be
the congestion and non-congestion timings. In one of the example
implementations, upon identification of the change in the location, the
communication module 210-2 may prompt the computing system to pre-pone the
re-scheduled download at a current service timing of the RAN 104.
15 [0045] In addition to the described example implementations related to present
subject matter, the DMS 102 may perform re-scheduling of the download of the
content in different scenarios. In one example implementation, the
communication module 210-2 may simultaneously receive multiple rescheduled
download requests for downloading of different rescheduled content. Upon the
20 receipt of multiple rescheduled download requests, the analysis module 220 may,
access a download window associated with the rescheduled download. In one
example, the analysis module 220 may define the download window as a
predefined downloading limit, which may indicate a maximum content size
permissible for the rescheduled download at the available service timing. The
25 analysis module 220 facilitate execution of the multiple received rescheduled
download requests until exhaustion of the download window. Furthermore, the
analysis module 220, may determine a set of pending requests from amongst the
received rescheduled download requests based on identification of the exhaustion
of the download window. In one of the example implementation, upon the
30 determination of the pending request, the re-scheduling module 110 may send a
22
prompt to the computing system 106 to re-schedule the download of the pending
requests. For example, the re-scheduling module 110 may send the prompt
including options of different available service timings to the computing system
106 for rescheduling the pending requests. In one example, the re-scheduling
module may prompt different starting times amongst the set of 5 available service
timings for each of the pending requests.
[0046] In addition to the functionalities of the DMS 102 described above, the
analysis module 220 of the DMS 102 may also determine a request time-out
associated with a current content download request executing at an instant. The
10 request time-out may indicate a completion of a predefined time interval within
which the one of received rescheduled download request can be executed. Further
upon determination of the request time out, the reschedule module 110 may send
a prompt to the computing system 106 to reschedule the current content
remaining download request. In another example implementation, upon the
15 receipt of the multiple rescheduled download requests simultaneously by the
communication module 210-2, the analysis module 220 may determine the
request time-out associated with one of the received rescheduled download
request executing at an instant. Further, the reschedule module 110 may send a
prompt to the computing system 106 to reschedule remaining download requests,
20 based on determination of the request time-out.
[0047] Further, in addition to the functionalities of DMS 102 described above,
the DMS 102 may further perform billing for the content requested to be
downloaded by the computing system 106, at a pre-defined rate. In one example,
the billing at the pre-defined rate may be performed in such a way that a user
25 operating the computing system 106 is rewarded for re-scheduling the download
of the content at the re-scheduled service timings. The pre-defined billing may be
performed by billing the user at a lower cost or at a subsidized rate during the rescheduled
service timings of the RAN 104. According to an example
implementation of the present subject matter, the analysis module 222 may
30 access a billing profile associated with the computing system 106. In one
23
example, the billing profile may include the computing system’s user account
related information such as prepaid plan, postpaid plan, data tariff plan, prepaid
balance, computing system’s Public Land Mobile Network (PLMN) circle etc. In
one example implementation, upon the accessing the billing profile by the
analysis module 222, the re-scheduling module 110 may send a prompt includ5 ing
different re-scheduling options available to the computing system 106. In one
implementation, the re-scheduling options may include different re-scheduling
service timings of the RAN 104. In the said example implementation, the prompt
may also include various discount offers associated with the different re10
scheduling options. In response to the prompt sent to the computing system 106,
the communication module 210-2 may receive a response indicating a selection
of the re-scheduling option and the associated discount offer by the computing
system 106. Further, upon the receipt of the response, the analysis module 222
may use the billing profile and the discount offer for performing the billing of the
15 computing system 106, at the pre-defined rate.
[0048] In addition to the described example implementation above, in another
implementation, the analysis module 222 may also allocate a coupon, including a
coupon code, to the computing system 106, for availing the discount offer. The
coupon may be unique to the content and the re-scheduling option selected by the
20 computing system 106. The analysis module 222 may further perform a coupon
validation on receiving a coupon code at the re-scheduled service timings from
the computing system 106. Further, a successful coupon validation by the
analysis module 222, may facilitate the computing system 106 to avail the
discount offer.
25 [0049] The following description describes the functionality of the
computing system 106 in conjunction with the DMS 102, in accordance with Fig.
2. In one of the example implementation, the computing system 106 may
communicate with the DMS 102 for rescheduling the download of the content in
the RAN 104. In the said example implementation, the communication module
30 210-1 of the computing system 106 may send a request to download the content,
24
to the DMS 102. In one example, the computing system 106 may send a HTTP
GET request to the DMS 102 for the download of the content. Further, in
response to the sent request, the communication module 210-1 may receive a
prompt from the DMS 102 to reschedule the download of the content. In one
example, the prompt includes options of available service timings 5 ngs to reschedule
the download of the content. Furthermore, upon the receipt of the prompt, the
communication module may send a response to the DMS 102. The response may
include re-scheduling details for re-scheduling the download of the content. In
one example, the re-scheduling details may include the re-scheduled service
10 timings of the RAN 104. The re-scheduled service timings may be one of the
available service timings.
[0050] In the said example implementation, upon sending the rescheduling
details, the computing system 106 may further receive a set of tokens
from the DMS 102. In one implementation, the set of tokens may be used for
15 performing the re-scheduled download of the content at the available service
timing. According to one example implementation of the present subject matter,
the communication module 210-1 may further send the set of tokens to the DMS
for facilitating the re-scheduled download of the content at the available service
timings of the RAN 104.
20 [0051] In addition to the said example implementation, the communication
module 210-1 may additionally receive the resource requirement check request
from the DMS 102. In response to the resource check request, the communication
module 210-1 may send a status information to the DMS 102. In one example,
the status information may include details of free memory and remaining battery
25 capacity of the computing system 102.
[0052] Fig. 3(A) and 3(B) illustrates a method 300 for rescheduling the
download of the content in the RAN 104, according to an example
implementation of the present subject matter. The order in which the method 300
is described is not intended to be construed as a limitation, and any number of the
30 described method blocks may be combined in any order to implement the method
25
300, or an alternative method. Furthermore, the method 300 may be implemented
by processor(s) or computing system(s) through any suitable hardware, nontransitory
machine readable instructions, or combination thereof.
[0053] It may be understood that steps of the method 300 may be
performed by programmed computing systems. The steps of the methods 5 ds 300
may be executed based on instructions stored in a non-transitory computer
readable medium, as will be readily understood. The non-transitory computer
readable medium may include, for example, digital memories, magnetic storage
media, such as one or more magnetic disks and magnetic tapes, hard drives, or
10 optically readable digital data storage media.
[0054] Further, although the method 300 may be implemented in a variety
of computing environments; in an embodiment described in Fig. 3A and 3B, the
method 300 is explained in context of the aforementioned computing
environment 100 having DMS 102 and computing system 106, for ease of
15 explanation.
[0055] Referring to Fig. 3(A), in an implementation of the present subject
matter, at step 302, a request to download a content is received from the
computing system 106 of the RAN 104. In one example implementation, the
request may include attributes indicating metadata associated with the content
20 such as, content title, content author, content type, content size, URL where the
content is located etc.
[0056] At step 304, the content is identified to be a re-schedulable content
based on content analysis parameters, where the content analysis parameters are
indicative of at least size and type of the content. In one example, the re25
schedulable content indicates the content which qualifies to be rescheduled for
the download at a later point of time. In one implementation, the DMS 102 may
identify the content to be the re-schedulable content if the content size is more
than a pre-defined size For example, the DMS 102 may identify a video file
related to a documentary to be the re-schedulable content, as the size of the file
30 may be hundreds of megabytes. limit. Further, the identification may include
26
parsing the content analysis parameters to extract the metadata associated with
the content.
[0057] At step 306, a service timing of the RAN 104 is accessed to be a
congestion timing based on traffic throughput on the RAN 104. The congestion
timing may indicate the service timings when the RAN 104 5 experiences
congestion. In one example implementation, the congestion timing may be
determined based on statistical examination of average congestion hours on the
RAN 104 for a defined period of time. The statistical examination may be
performed by the DMS 102. According to another example implementation, the
10 accessing of the service timing may be performed by the DMS 102 and may
include, monitoring of real-time network parameters and calculation of network
parameter indices, for determining the traffic throughput on the RAN 104.
[0058] At step 308, a location of the computing system 106 is determined
to be in the computing system’s home location. In one example implementation,
15 the location of the computing system may be determined by the DMS 102, based
on the information related to PLMN circle, or identifier associated with a cell site
within a cellular structure of the RAN 104.
[0059] Referring to Fig. 3(B), at step 310, the computing system 106 is
prompted to re-schedule the download of the content at one of available service
20 timings, based on the accessing of the service timings and determination of the
location. In one of the example implementation, the available service timings
may be a non-congestion timing of the RAN 104. The non-congestion timing of
the RAN 104 may correspond to the service timing when the RAN 104 may not
experience congestion. For example, the computing system 106 may be prompted
25 to download the content at the time, when the RAN 104 may seamlessly facilitate
the download without any interruptions.
[0060] At step 312, re-scheduling details are received from the computing
system 106 to re-schedule the download of the content, where the re-scheduling
details include a re-scheduled service timing and where, the re-schedule service
30 timings is from amongst the available service timing. For example, the re27
scheduled service timing may indicate the service timings amongst the available
service timings prompted to the computing system 106, at which the computing
system 106 may desire to re-schedule the download of the content.
[0061] At step 314, the download of the content is re-scheduled by sending
a response to the computing system 106, the response comprising 5 a header
including a set of tokens for facilitating a rescheduled download of the content,
where the set of tokens are unique to the computing system 106 and the content.
For example, the DMS 102 may send a response with a set of tokens T1 and T2
corresponding to the download of a content C’. The token T1 may include an
10 identifier associated with the computing system 106 for example, IP Address,
IMSI number and the token T2 may include another identifier associated with the
content for example content title. For secure allocation of the tokens, the DMS
102 may also encrypt the tokens T1 and T2 using RC4 encryption. In one
example, the download of the content is re-scheduled by the DMS 102 and the
15 response may include the set of tokens along with a coupon associated with a
discount offer, which may be availed by the computing system 106 at the rescheduled
service timing.
[0062] Fig. 4 illustrates a method 400 for facilitating a re-scheduled
download of the content in the RAN 104, according to an example
20 implementation of the present subject matter. The order in which the method 400
is described is not intended to be construed as a limitation, and any number of the
described method blocks may be combined in any order to implement the method
400, or an alternative method. Furthermore, the method 400 may be implemented
by processor(s) or computing system(s) through any suitable hardware, non25
transitory machine readable instructions, or combination thereof.
[0063] It may be understood that steps of the method 400 may be
performed by programmed computing systems. The steps of the methods 400
may be executed based on instructions stored in a non-transitory computer
readable medium, as will be readily understood. The non-transitory computer
30 readable medium may include, for example, digital memories, magnetic storage
28
media, such as one or more magnetic disks and magnetic tapes, hard drives, or
optically readable digital data storage media.
[0064] Further, although the method 400 may be implemented in a variety
of computing environments; in an embodiment described in Fig. 4, the method
400 is explained in context of the aforementioned computing environment 5 ent 100
having DMS 102 and computing system 106, for ease of explanation.
[0065] Referring to Fig. 4, at step 402, a re-scheduled download initiation
prompt is sent to the computing system 106 at re-scheduled service timing.
[0066] At step 404, a set of tokens is received from the computing system
10 106 for a re-scheduled download of the content. In one of the example
implementation, the computing system 106 may receive the set of tokens: Token
T1 and Token T2 from the computing system 106 for facilitating the re-scheduled
download of the content C’. The tokens may be an encoded value, using any of
the well known mechanisms such as MD5 hashing, RC4 encryption etc.
15 [0067] At step 406, the set of tokens is validated based on corresponding
content and associated computing system’s credentials. The set of tokens may be
validated based on the decryption of tokens at the DMS 102 and validation of
tokens based on the identifiers associated with the computing system 106 and the
content requested for the download.
20 [0068] At step 408, a sufficient memory and battery of the computing
system is determined to initiate the re-scheduled download of the content. For
example, the DMS 102 may determine that a 20% battery available at the
computing system 106 may be insufficient for the re-scheduled download of the
content. In other example, the DMS 102 may determine that the re-scheduled
25 download of a content of size 5Gb may not be possible for the computing system
106 with only 700 Mb free memory.
[0069] At step 410, an account balance in the computing system’s user
account is determined to be sufficient for at least one of the initiation or
completion of the download of the content.
29
[0070] At 412, the re-scheduled download of the content is facilitated. In
one of the example implementation, the DMS 102 may communicate with the
origin server 102 to facilitate the re-scheduled download of the content.
[0071] Fig. 5(A) and 5(B) illustrates a method 500 for rescheduling the
download of the content in the RAN 104, according to another exampl5 e
implementation of the present subject matter. The order in which the method 500
is described is not intended to be construed as a limitation, and any number of the
described method blocks may be combined in any order to implement the method
500, or an alternative method. Furthermore, the method 500 may be implemented
10 by processor(s) or computing system(s) through any suitable hardware, nontransitory
machine readable instructions, or combination thereof.
[0072] It may be understood that steps of the method 500 may be
performed by programmed computing systems. The steps of the methods 500
may be executed based on instructions stored in a non-transitory computer
15 readable medium, as will be readily understood. The non-transitory computer
readable medium may include, for example, digital memories, magnetic storage
media, such as one or more magnetic disks and magnetic tapes, hard drives, or
optically readable digital data storage media.
[0073] Further, although the method 500 may be implemented in a variety
20 of computing environments; in an embodiment described in Fig. 5A and 5B, the
method 500 is explained in context of the aforementioned computing
environment 100 having DMS 102 and computing system 106, for ease of
explanation.
[0074] Referring to Fig. 5(A), in an implementation of the present subject
25 matter, at step 502, a request is sent, to download a content in the RAN 104. In
one of the example implementation the request for the download of the content
may be sent from the computing system 106 to the DMS 102.
[0075] At step 504, a prompt including option of available service timings
of the RAN 104 is received to re-schedule the download of the content.
30
According to one example implementation, the computing system 106 may
receive the prompt to re-schedule the download. The prompt may be popped up
on the display of the computing system 106. In one example, the prompt may
include multiple options of available service timings of the RAN 104. The
multiple options of the available service timings are selectable by the comp5 uting
system 106, in accordance with one of the example implementation of the present
subject matter.
[0076] At step 506, rescheduling details to re-schedule the download of the
content is communicated where the re-scheduling details include a re-scheduled
10 service timing from amongst the available service timing of the RAN 104. The
re-scheduled service timing may indicate the service timings at which the
computing system 106 desires to re-schedule the download. In one example
implementation, the rescheduling details may be communicated by the computing
system 106 to the DMS 102. The re-scheduling details may include the re15
schedulable service timing selected by the computing system 106 from amongst
the multiple options of available service timings provided in the prompt.
[0077] At step 508, a set of tokens corresponding to the re-scheduled
download of the content is received, where the set of tokens are unique to the
computing system 106 and the content. In one example, the computing system
20 106 may receive an encrypted set of tokens T’ and T’’ corresponding to the rescheduled
download of the content. The set of tokens may be encrypted using
RC4 or other well known encryption mechanisms.
[0078] Referring to Fig 5(B), at step 552, a re-scheduled download
initiation prompt is received at the re-scheduled service timing of the RAN 104
25 for initiating the re-scheduled download. In one of the example implementation
the re-scheduled download initiation prompt may be sent from the DMS 102 and
may be received at the computing system 106. In one example implementation,
the re-scheduled download initiation prompt may be received at a pre-defined
time of the RAN 104. In another example implementation, the re-scheduled
30 download initiation prompt may be received at one of the available service timing
31
or re-scheduled service timing of the RAN 104. The re-scheduled download
initiation prompt may be sent as a reminder to the computing system 106 to
initiate the re-scheduled download of the content.
[0079] At step 554, the set of tokens is sent, for validating the re-scheduled
download of the content. In one implementation, the computing system 106 ma5 y
send the set of tokens to the DMS 102 for validation. For example, the computing
system 106 may send the encrypted set of tokens T’ and T’’ to the DMS 102
which may be decrypted later by the DMS 102 for validation. In another
example, the computing system 106 may also send a coupon code along with the
10 set of tokens for availing a discount offer associated with the re-scheduled
download of the content.
[0080] At step 556, a status information for available battery and memory
of the computing system 106 is sent to initiate the re-scheduled download of the
content. In one example implementation, the computing system 106 may send the
15 status information indicating the available battery and free memory of the
computing system 106. For example, computing system 106 may send to the
DMS 102 the status information stating a 70% available battery and 20 Gb of free
memory available at the computing system 106. In the said example
implementation, the status information may be sent in a response to a resource
20 requirement check request received at the computing system 106.
[0081] At step 558, the content downloaded at the re-scheduled service
timing of the RAN 104 may be received. In one of the implementation, the
computing system 106 receives the content downloaded at the re-scheduled
service timing. The content may be downloaded from the origin server 108,
25 according to one example implementation of the present subject matter.
[0082] Fig. 6 illustrates a method 600 for determining a service timing of
the radio access network to be a congestion timing, according to another example
implementation of the present subject matter. The order in which the method 600
is described is not intended to be construed as a limitation, and any number of the
30 described method blocks may be combined in any order to implement the method
32
600, or an alternative method. Furthermore, the method 600 may be implemented
by processor(s) or computing system(s) through any suitable hardware, nontransitory
machine readable instructions, or combination thereof.
[0083] It may be understood that steps of the method 600 may be
performed by programmed computing systems. The steps of the methods 5 ds 600
may be executed based on instructions stored in a non-transitory computer
readable medium, as will be readily understood. The non-transitory computer
readable medium may include, for example, digital memories, magnetic storage
media, such as one or more magnetic disks and magnetic tapes, hard drives, or
10 optically readable digital data storage media.
[0084] Further, although the method 600 may be implemented in a variety
of computing environments; in an embodiment described in Fig. 6, the method
600 is explained in context of the aforementioned computing environment 100
having DMS 102 and computing system 106, for ease of explanation.
15 [0085] Referring to Fig. 6, at step 602, service timings of the RAN 104 is
accessed at the DMS 102.
[0086] At step 604, real-time network parameters indicating network
utilization statistics are monitored for calculating network parameter indices. In
one example implementation, the DMS 102 may monitor the network parameters
20 based on periodic accessing of the service timings by the DMS 102. In another
example implementation, the DMS 102 may also monitor the network parameters
based on a request received from one of the computing system(s) 106.
[0087] At step 606, network parameter indices which includes geoutilization
index, services usage index, motion index, video performance index,
25 and bandwidth usage index, based on network parameters information, are
computed. The network parameter indices may indicate various attributes
associated with network utilization, which may be computed mathematically.
[0088] At step 608, network traffic throughput is determined based on the
network parameter indices.
33
[0089] At step 610, the service timings may be determined to be congestion
timings based on the network traffic throughput. In one example, the congestion
timing of may indicate the service timings when the RAN 104 experiences
congestion. In one example implementation, the DMS 102 may determine the
service timings to be the congestion timings if the network traffic 5 ffic throughput is
exceedingly above a pre-defined threshold.
[0090] Fig. 7 represents a call flow diagram 700 indicating procedure for
rescheduling the download of the content in the RAN 104, in accordance with an
embodiment of the present subject matter. The various arrow indicators used in
10 the call-flow diagram 700 depict the transfer of signal/information between the
computing system 106, the DMS 102, and the origin server 108.
[0091] The call flow diagram 700, as described in the Fig. 7 has been
explained in considerable details with respect to the computing system 106
initiating the procedure. It will be understood that the principles described herein
15 may be extended to various other scenarios as well, for example, where DMS 102
initiates the procedure.
[0092] In one of the example implementation, the procedure for
rescheduling the download of the content is initiated with the computing system
106 sending a content download request 702 to the DMS 102 for downloading
20 the content in the RAN 104. In one example, the content download request may
be a HTTP GET request sent to the DMS 102. The HTTP GET request may
include a URI including content attributes indicative of details related to the
content. The DMS 102 subsequently determines a service timing of the RAN 104
to be a congestion timing. In one example, the DMS 102 may determine the
25 service timing to be the congestion timing based on the network traffic
throughput. For example, the RAN 104 may be in a state of congestion when the
data traffic at the RAN 104 becomes more than a defined traffic limit, such that
the QOS of the RAN 104 starts getting compromised. The congestion timings
may be the service timings, when the RAN may be in the state of congestion
30 Further, the DMS 102 subsequently sends a re-schedule download prompt 704 to
34
the computing system 102. In one example, the reschedule download prompt 704
may include options of available service timings of the RAN 104. The available
service timings of the RAN 104 may indicate the service timings at which the
download may be facilitated seamlessly without any interruption.
[0093] Further, upon the receipt of the re-schedule download prompt, th5 e
computing system 106 subsequently sends rescheduling details to the DMS 102
for re-scheduling the download of the content. In one example implementation,
the re-scheduling details may include an option selected by the computing system
106. The selected option may be a re-scheduled service timing, indicating the
10 choice of the service timing at which the download of the content may be rescheduled.
Upon the receipt of the re-scheduling details, the DMS 102
subsequently sends a response 708, including a set of tokens to the computing
system 106. For example, the response 708 may be a HTTP Response including a
URI having token 1 and token 2, where the token 1 may be uniquely associated
15 with the content’s identity and token 2 may be uniquely associated with the
computing system’s identity.
[0094] The DMS 102 further determines the service timings to be rescheduled
service timings and subsequently sends a re-scheduled download
initiation prompt 710 to the computing system 106 for initiating a re-scheduled
20 download of the content. Further upon receiving the re-scheduled download
initiation prompt 710, the computing system 106 sends a set of tokens 712 to the
DMS 102 to proceed for the re-scheduled download of the content. For example,
the set of tokens may be sent as a HTTP GET request having a URL. The request
may include the token 1 and token 2 as attributes in the URI.
25 [0095] Upon the receipt of the set of tokens, the DMS 102 subsequently
validates the set of tokens and sends a resource requirement check request 714 to
the computing system 106. For example, the resource requirement check request
may be a HTTP request including a GET method for requesting status
information from the computing system 106. Further, the computing system 106
30 sends a response 716 including the status information indicating the resource
35
availability at the computing system 106. For example, the status information
may include details of available battery and free memory of the computing
system 106.
[0096] The DMS 102 further determines sufficient resource availability at
the computing system 106 to facilitate the re-scheduled download 5 d and
subsequently sends a request 718 to the origin server 108 for providing the
content requested for the download. The origin server may be a server associated
with multiple content providers which facilitate providing multiple types of
content such as movies, music files etc., to the users. For example, the DMS 102
10 may send a HTTP request to the origin server 108 for providing the requested
content.
[0097] Further, the origin server 108 sends the content to the DMS 102. In
one implementation, the origin server 108 may also send a URL corresponding to
the location where the content is available. The DMS subsequently forwards the
15 received content 720 or the URL to the computing system 106 for downloading
the content.
[0098] Fig. 8 represents a call flow diagram 800 indicating procedure for
rescheduling the download of the content in the RAN 104, in accordance with an
embodiment of the present subject matter. The various arrow indicators used in
20 the call-flow diagram 800 depict the transfer of signal/information between the
computing system 106, the DMS 102, and the origin server 108.
[0099] The call flow diagram 800, as described in the Fig. 8 has been
explained in considerable details with respect to the computing system 106
initiating the procedure. It will be understood that the principles described herein
25 may be extended to various other scenarios as well, for example, where DMS 102
initiates the procedure.
[00100] In one of the example implementation, the procedure rescheduling
the download of the content, during an interruption in the download, in the RAN
104 is initiated by the computing system 106 sending a content download request
36
to the DMS 102 for the download of the content. The DMS 102 subsequently
forwards the content download request 802 to the origin server 108.
[00101] Further, the origin server 108 provides the content 804 in a response
to the DMS 102. The DMS 102 subsequently forwards the response 804 to the
computing system 106 to start the download of the cont5 ent.
[00102] Furthermore, the computing system 106 sends a download interrupt
message to the DMS 102 indicating an interruption in an ongoing download. In
one of the example implementation, the download interrupt message may be an
error message indicative of a non-completion of the ongoing download. The
10 DMS 102 determines a reason for the interruption in the ongoing download. For
example, the DMS 102 may determine the reason for the interruption, such as,
loss of RAN network connectivity, loss of internet connectivity, fault in the
computing system 106 etc. Upon the determination of the reason, the DMS 102
sends a re-schedule remaining download prompt to re-schedule the download for
15 a remaining content, at another service timing of the RAN 104. For example, the
DMS 102 may send a prompt including options of available service timings of
the RAN 104 along with a set of tokens allocated for the download of the
remaining content.
[00103] Fig. 9 represents a call flow diagram 900 indicating procedure for
20 rescheduling the download of the content, on receiving multiple content
download requests simultaneously, in the RAN 104, in accordance with an
embodiment of the present subject matter. The various arrow indicators used in
the call-flow diagram 900 depict the transfer of signal/information between the
computing system 106, the DMS 102, and the origin server 108.
25 [00104] The call flow diagram 900, as described in the Fig. 8 has been
explained in considerable details with respect to the DMS 102 initiating the
procedure. It will be understood that the principles described herein may be
extended to various other scenarios as well, for example, where the computing
system 106 initiates the procedure.
37
[00105] In one of the example implementation, the procedure for
rescheduling the download of the content, on receiving multiple content
download requests simultaneously, in the RAN 104 is initiated by the DMS 102
by determining a change in location of the computing system 106 from the
congested network to the non-congested network 902. In one example, th5 e
location of the computing system may corresponds to the cellular identity of the
RAN’s 104 cellular structure within which the computing system 106 may be
located. Upon the determination, the DMS 102 subsequently sends a prompt 904
to the computing system 106 to pre-pone the re-scheduled download. It would
10 appreciated that the steps of re-scheduling of the download of the content for
facilitating a re-scheduled download may be performed by the DMS 102 and the
computing system 106 in a similar way as described in previous figures. The said
steps are skipped and not explained in this section for the clarity of explanation.
[00106] Upon the receipt of the prompt, the computing system sends a first
15 re-scheduled content download request 906 to the DMS 102 for initiating the rescheduled
download. Further, the DMS 102 forwards 907 the first re-scheduled
content download request to the origin server 108. The computing system 106
further sends a second download re-scheduled content request 908 and a third
download re-scheduled content request 909 simultaneously to the DMS 102. For
20 example, the first re-scheduled content download request may be for a video file
including trailer of an upcoming movie. The second re-scheduled content
download request may be for an audio file including a song of the upcoming
movie, and the third re-scheduled content download request may be for all music
files of the upcoming movie. In one example implementation, the computing
25 system 106 may send any number of re-scheduled content download requests
simultaneously to the DMS 102.
[00107] Upon the receipt of multiple re-scheduled content download
requests simultaneously , the DMS 102 polls for a response from the origin
server 108 corresponding to the first re-scheduled content download request and
30 determines the request time-out associated with the first re-scheduled content
38
download request. For example, the DMS 102 may wait for the response from
the origin server 108 for the download of the first re-scheduled content
download request related to the trailer of the upcoming movie. Further, the DMS
102 also identifies an exhaustion of the download window associated with the
re-scheduled 5 download 910.
[00108] Upon the determination of the request time-out and exhaustion of
the download window, the DMS 102 determines the pending re-scheduled
content download requests and subsequently sends a prompt 912 to the
computing system 106 to re-schedule the download of the pending re-scheduled
10 content download requests. For example, the DMS 102 may send the prompt to
the computing system 106 to re-schedule the download of the pending rescheduled
content download requests related to the audio files and the music
files of the upcoming movie.
[00109] Although implementations of present subject matter have been
15 described in language specific to structural features and/or methods, it is to be
understood that the present subject matter is not necessarily limited to the
specific features or methods described. Rather, the specific features and methods
are disclosed and explained in the context of a few implementations for the
present subject matter.

I/We claim:
1. A method for rescheduling download of a content in a radio access
network, the method comprising:
receiving a request to download the content from a computing
system of the radio 5 access network;
identifying the content to be a reschedulable content based on
content analysis parameters, wherein the content analysis parameters are
indicative of at least size and type of the content;
assessing service timing of the radio access network to be a
10 congestion timing based on traffic throughput on the radio access
network;
determining location of the computing system to be in computing
system’s home network;
prompting the computing system to reschedule the download of
15 the content at one of available service timings, based on the assessment of
service timing and the determination of the location;
receiving rescheduling details from the computing system to
reschedule the download of the content, wherein the rescheduling details
include a rescheduled service timing, and wherein the rescheduled service
20 timing is from amongst the available service timings;
rescheduling the download of the content at the rescheduled
service timing by sending a response to the computing system, wherein
the response comprises a header including a set of tokens for facilitating
rescheduled download of the content, and wherein the set of tokens are
25 unique to the computing system and the content.
2. The method as claimed in claim 1, wherein the accessing the service
timing further comprises monitoring real-time network parameters, and
wherein the network parameters are indicative of attributes affecting
30 network utilization.
40
3. The method as claimed in claim 2, further comprising computing network
parameter indices based on the real-time network parameters to determine
network traffic throughput.
5
4. The method as claimed in claim 1, wherein the one of available service
timing of the radio access network is a non congestion timing.
5. The method as claimed in claim 1, wherein the method further comprises
10 disconnecting a connection between the radio access network and the
computing system.
6. The method as claimed in claim 1, wherein the method further comprises:
sending a rescheduled download initiation prompt to the
15 computing system at the rescheduled service timing;
receiving, from the computing system, the set of tokens for the
rescheduled download of the content;
validating the set of tokens based on corresponding content and
associated computing system’s credentials;
20 determining an account balance in the computing system’s user
account to be sufficient for at least one of initiation or completion of the
download of the content;
facilitating download of the content upon validation of the tokens
and determination of the account balance.
25
7. The method as claimed in claim 6, wherein the method further comprises
determining a sufficient memory and battery of the computing system to
initiate the rescheduled download of the content.
41
8. The method as claimed in claim 6, wherein the method further comprises
billing a user operating the computing system at a predefined rate for the
rescheduled download of the content.
5
9. A method to reschedule download of a content in a radio access network,
the method comprising:
sending, by a computing system, a request to download the
content from the radio access network;
10 receiving a prompt to reschedule the download of the content,
wherein the prompt includes options of available service timings to
reschedule the download of the content; and
communicating reschedule details to reschedule the download of
the content, wherein the reschedule details include a rescheduled service
15 timing from amongst the available service timings.
10. The method as claimed in claim 9, wherein the method further comprises
receiving a set of tokens corresponding to a rescheduled download of the
content, wherein the set of tokens are unique to the content and the
20 computing system.
11. A download management system (DMS) comprising:
a processor;
an analysis module coupled to the processor to:
25 receive a request to download a content from a computing system
of a radio access network;
42
identify the content to be a reschedulable content based on content
analysis parameters, wherein the content analysis parameters are
indicative of at least size and type of the content; and
assess service timing of the radio access network to be a
congestion timing based on traffic throughput on the radio acces5 s
network;
determine location of the computing system to be any one of
congested network, non-congested network and computing system’s
home network;
10 a communication module coupled to the processor to:
prompt the computing system to reschedule the download of the
content at one of available service timings based on the assessment of
service timings and the determination of the location and;
receive rescheduling details including a rescheduled service timing
15 from the computing system to reschedule the download of the content,
wherein the rescheduling details include a rescheduled service timing, and
wherein the rescheduled service timing is from amongst the available
service timings;
a rescheduling module coupled to the processor to:
20 reschedule the download of the content at the rescheduled service
timing by sending a response to the computing system, wherein the
response comprises a header including a set of tokens for facilitating
rescheduled download of the content, and wherein the set of tokens are
unique to the computing system and the content.
25
43
12. The DMS as claimed in claim 11, wherein the communication module is
to further :
receive the set of tokens for the rescheduled download of the
content from the computing system, and wherein the analysis module is to
5 further:
validate the set of tokens based on corresponding content and
associated computing system’s credentials, for the rescheduled download
of the content; and
determine an account balance in the computing system’s user
10 account to be sufficient for at least one of initiation or completion of the
download of the content.
13. The DMS as claimed in claim 12, wherein communication module is to
further facilitate the download of the content, based on the validation of
15 the set of tokens and determination of account balance.
14. The DMS as claimed in claim 11, wherein the analysis module is to
identify a change in the location of the computing system from the
congested network to the non-congested network and further prompt the
20 computing system to pre-pone the rescheduled download at a current
service timing of the radio access network.
15. The DMS as claimed in claim 11 comprising,
the communication module to receive, simultaneously, a plurality
of rescheduled download requests for downloading of the different
25 rescheduled content;
the analysis module to further:
44
access a download window associated with the rescheduled
download, wherein the download window is a predefined
downloading limit indicating a maximum content size permissible
for the rescheduled download at the available service timing;
facilitate execution of the plurality of received reschedu5 led
download requests until exhaustion of the download window;
determine a set of pending requests from amongst the
received rescheduled download requests based on identification of
the exhaustion of the download window;
10 the reschedule module is to further:
send a prompt to the computing system to reschedule the
pending download requests, wherein the prompt includes different
starting time amongst a set of available service timings for
rescheduling each of the pending rescheduled download requests.
15
16. The DMS as claimed in claim 11 comprising,
the communication module to receive, simultaneously, the
plurality of rescheduled download requests for downloading of the
different rescheduled content;
20 the analysis module to further:
access one of a rescheduled download request from
amongst the plurality of received rescheduled download requests;
determine a request timeout indicating a completion of a
predefined time interval within which the one of received
25 rescheduled download request can be executed;
45
the reschedule module is to further send a prompt to the
computing system to reschedule remaining download requests
based on determination of the request timeout.
17. A computing system comprising5 :
a processor;
a communication module coupled to the processor to:
send a request to download a content from a radio access network;
receive a prompt to reschedule the download of the content,
10 wherein the prompt includes options of available service timings to
reschedule the download of the content; and
communicate reschedule details to reschedule the download of the
content, wherein the reschedule details include a rescheduled service
timing from amongst the available service timings of the radio access
15 network.
18. The computing system as claimed in claim 17, wherein the
communication module is to further send a set of tokens for a rescheduled
download of the content.
20
19. The computing system as claimed in claim 17, wherein the
communication module is to further send a status information including
details of free memory and remaining battery capacity of the computing
device for determining an initiation of the rescheduled download of the
25 content.
20. A non-transitory computer readable medium having a set of computer
readable instructions that, when executed, cause a computing system to:
receive a request to download the content from a computing
30 system of the radio access network;
46
identify the content to be a re-schedulable content based on
content analysis parameters, wherein the content analysis parameters are
indicative of at least size and type of the content;
assess service timing of the radio access network to be a
congestion timing based on traffic throughput on the radio acces5 s
network;
determine location of the computing system to be in computing
system’s home network;
prompt the computing system to reschedule the download of the
10 content at one of available service timings, based on the assessment of
service timing and the determination of the location;
receive rescheduling details from the computing system to
reschedule the download of the content, wherein the rescheduling details
include a rescheduled service timing, and wherein the rescheduled service
15 timing is from amongst the available service timings;
reschedule the download of the content at the rescheduled service
timing by sending a response to the computing system, wherein the
response comprises a header including a set of tokens for facilitating
rescheduled download of the content, and wherein the set of tokens are
20 unique to the computing system and the content.
21. A non-transitory computer readable medium having a set of computer
readable instructions that, when executed, cause a computing system to:
send, by a computing system, a request to download the content
25 from the radio access network;
receive a prompt to reschedule the download of the content,
wherein the prompt includes options of available service timings to
reschedule the download of the content; and
47
communicate reschedule details to reschedule the download of the
content, wherein the reschedule details include a rescheduled service
timing from amongst the available service timings.

Documents

Application Documents

# Name Date
1 2539-DEL-2015-IntimationOfGrant09-01-2023.pdf 2023-01-09
1 Form 5 [17-08-2015(online)].pdf 2015-08-17
2 Form 3 [17-08-2015(online)].pdf 2015-08-17
2 2539-DEL-2015-PatentCertificate09-01-2023.pdf 2023-01-09
3 Drawing [17-08-2015(online)].pdf 2015-08-17
3 2539-DEL-2015-Written submissions and relevant documents [13-12-2022(online)].pdf 2022-12-13
4 Description(Complete) [17-08-2015(online)].pdf 2015-08-17
4 2539-DEL-2015-FORM-26 [25-11-2022(online)].pdf 2022-11-25
5 2539-del-2015-Form-1-(18-09-2015).pdf 2015-09-18
5 2539-DEL-2015-Correspondence to notify the Controller [08-11-2022(online)].pdf 2022-11-08
6 2539-DEL-2015-US(14)-HearingNotice-(HearingDate-28-11-2022).pdf 2022-10-26
6 2539-del-2015-Correspondence Others-(18-09-2015).pdf 2015-09-18
7 Form 26 [11-04-2017(online)].pdf 2017-04-11
7 2539-DEL-2015-CLAIMS [13-09-2019(online)].pdf 2019-09-13
8 2539-DEL-2015-Power of Attorney-130417.pdf 2017-04-17
8 2539-DEL-2015-DRAWING [13-09-2019(online)].pdf 2019-09-13
9 2539-DEL-2015-FER_SER_REPLY [13-09-2019(online)].pdf 2019-09-13
9 2539-DEL-2015-Correspondence-130417.pdf 2017-04-17
10 2539-DEL-2015-FER.pdf 2018-12-14
10 2539-DEL-2015-FORM 3 [13-09-2019(online)].pdf 2019-09-13
11 2539-DEL-2015-FORM 4(ii) [11-06-2019(online)].pdf 2019-06-11
11 2539-DEL-2015-Information under section 8(2) (MANDATORY) [13-09-2019(online)].pdf 2019-09-13
12 2539-DEL-2015-OTHERS [13-09-2019(online)].pdf 2019-09-13
13 2539-DEL-2015-FORM 4(ii) [11-06-2019(online)].pdf 2019-06-11
13 2539-DEL-2015-Information under section 8(2) (MANDATORY) [13-09-2019(online)].pdf 2019-09-13
14 2539-DEL-2015-FER.pdf 2018-12-14
14 2539-DEL-2015-FORM 3 [13-09-2019(online)].pdf 2019-09-13
15 2539-DEL-2015-Correspondence-130417.pdf 2017-04-17
15 2539-DEL-2015-FER_SER_REPLY [13-09-2019(online)].pdf 2019-09-13
16 2539-DEL-2015-DRAWING [13-09-2019(online)].pdf 2019-09-13
16 2539-DEL-2015-Power of Attorney-130417.pdf 2017-04-17
17 2539-DEL-2015-CLAIMS [13-09-2019(online)].pdf 2019-09-13
17 Form 26 [11-04-2017(online)].pdf 2017-04-11
18 2539-del-2015-Correspondence Others-(18-09-2015).pdf 2015-09-18
18 2539-DEL-2015-US(14)-HearingNotice-(HearingDate-28-11-2022).pdf 2022-10-26
19 2539-DEL-2015-Correspondence to notify the Controller [08-11-2022(online)].pdf 2022-11-08
19 2539-del-2015-Form-1-(18-09-2015).pdf 2015-09-18
20 Description(Complete) [17-08-2015(online)].pdf 2015-08-17
20 2539-DEL-2015-FORM-26 [25-11-2022(online)].pdf 2022-11-25
21 Drawing [17-08-2015(online)].pdf 2015-08-17
21 2539-DEL-2015-Written submissions and relevant documents [13-12-2022(online)].pdf 2022-12-13
22 Form 3 [17-08-2015(online)].pdf 2015-08-17
22 2539-DEL-2015-PatentCertificate09-01-2023.pdf 2023-01-09
23 Form 5 [17-08-2015(online)].pdf 2015-08-17
23 2539-DEL-2015-IntimationOfGrant09-01-2023.pdf 2023-01-09

Search Strategy

1 2539-del-2015_15-10-2018.pdf

ERegister / Renewals

3rd: 17 Mar 2023

From 17/08/2017 - To 17/08/2018

4th: 17 Mar 2023

From 17/08/2018 - To 17/08/2019

5th: 17 Mar 2023

From 17/08/2019 - To 17/08/2020

6th: 17 Mar 2023

From 17/08/2020 - To 17/08/2021

7th: 17 Mar 2023

From 17/08/2021 - To 17/08/2022

8th: 17 Mar 2023

From 17/08/2022 - To 17/08/2023

9th: 17 Mar 2023

From 17/08/2023 - To 17/08/2024

10th: 16 Jul 2024

From 17/08/2024 - To 17/08/2025

11th: 07 Aug 2025

From 17/08/2025 - To 17/08/2026