U.S. patent application number 14/800178 was filed with the patent office on 2016-02-11 for delivering files to a mobile device.
The applicant listed for this patent is Penthera Partners, Inc.. Invention is credited to Adam L. Berger, Gary N. Wallace, JR..
Application Number | 20160044086 14/800178 |
Document ID | / |
Family ID | 40851086 |
Filed Date | 2016-02-11 |
United States Patent
Application |
20160044086 |
Kind Code |
A1 |
Wallace, JR.; Gary N. ; et
al. |
February 11, 2016 |
Delivering Files to a Mobile Device
Abstract
Among other things, in controlling a download of one or more
files from a server to a mobile device, account is taken of at
least two of: an urgency of the file, the existence of a
user-indicated preference about the download, a power status of the
mobile device, and a network connectivity status of the mobile
device.
Inventors: |
Wallace, JR.; Gary N.;
(Butler, PA) ; Berger; Adam L.; (Pittsburgh,
PA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Penthera Partners, Inc. |
Pittsburgh |
PA |
US |
|
|
Family ID: |
40851086 |
Appl. No.: |
14/800178 |
Filed: |
July 15, 2015 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
13218620 |
Aug 26, 2011 |
9112838 |
|
|
14800178 |
|
|
|
|
12013567 |
Jan 14, 2008 |
8027671 |
|
|
13218620 |
|
|
|
|
Current U.S.
Class: |
709/219 |
Current CPC
Class: |
H04L 67/322 20130101;
Y02D 70/1244 20180101; Y02D 70/142 20180101; Y02D 70/144 20180101;
H04L 67/06 20130101; H04L 67/1095 20130101; H04L 67/306 20130101;
H04W 52/0254 20130101; G06F 16/957 20190101; Y02D 70/1224 20180101;
Y02D 30/70 20200801 |
International
Class: |
H04L 29/08 20060101
H04L029/08; H04W 52/02 20060101 H04W052/02 |
Claims
1. A method comprising: downloading a file over a communication
channel to a mobile device, monitoring an availability of a WiFi
communication facility through which the mobile device can
communicate and a charge state of a battery of the mobile device
relative to a given state, and causing suspension and resumption of
the downloading of the file based on the monitoring, when there is
a degrading or improvement in the availability of the WiFi
communication facility or of the battery charge state relative to
the given state, or both.
2. The method of claim 1 in which the suspension of the download is
based on rules or heuristics.
3. The method of claim 1 in which the resumed download does not
include at least some of the file that was downloaded before the
suspension.
4. The method of claim 3 in which the resumed download does not
include one or more pieces of the file that were downloaded before
the suspension.
5. The method of claim 1 in which the monitoring is done after each
piece of multiple pieces of the file is sent and before download of
a subsequent piece has begun.
6. The method of claim 1 comprising enabling a user of the mobile
device, to which the file would normally be downloaded
automatically based on preferences of the user, to initiate the
downloading by invoking an option on a user interface of the mobile
device.
7. The method of claim 1 comprising at the mobile device, receiving
a sync signal from a server with respect to the file to be
downloaded, and responding to the sync signal by requesting and
accepting a download of the file.
8. The method of claim 1 comprising at the mobile device,
displaying to a user an indication of a time when the download of
the file to the mobile device is expected to occur.
9. The method of claim 1 comprising sending from the mobile device
to the server, a log of downloading activity with respect to the
file.
10. The method of claim 1 comprising enabling a user of the mobile
device to specify one or more types of files that are to be
downloaded to the mobile device, for storage in a server in
association with an identification of the mobile device or the
user.
11. The method of claim 1 comprising downloading files at the
mobile device that have been selected based on stored preferences
of a user of the mobile device and stored information about files
that were previously downloaded to the user's device.
12. The method of claim 1 comprising displaying to a user of the
mobile device a list of files that are in process of being
downloaded to the device from the server, but which have not yet
been completely downloaded to the device.
13. The method of 12 in which the displaying includes showing a
percentage of at least one of the listed files which has been
downloaded.
14. The method of 12 in which the displaying occurs at the mobile
device.
15. The method of 12 in which the displaying occurs on a web
page.
16. A mobile device comprising: a WiFi network interface, a
battery, and an application to cause downloading of a file over a
communication channel to a mobile device, monitoring of an
availability of a WiFi access point through which the mobile device
can communicate and a charge state of a battery of the mobile
device relative to a given state, and causing suspension and
resumption of the downloading of the file based on the monitoring,
when there is a degrading or improvement in the availability of the
WiFi access point or of the charge state relative to the given
state, or both.
Description
CLAIM OF PRIORITY
[0001] This application is a continuation and claims priority under
35 U.S.C. .sctn.120 to U.S. patent application Ser. No. 13/218,620
filed on Aug. 26, 2011, which is a continuation and claims the
benefit of U.S. patent application Ser. No. 12/013,567 filed on
Jan. 14, 2008. The above applications are incorporated here in
their entirety by reference.
BACKGROUND
[0002] This description relates to delivering files to a mobile
device.
[0003] As shown in FIG. 1, consider a client application 60 that
delivers files from a remote server 25 to a mobile device 50. From
time to time, files 10, 20 are created on the remote server.
Shortly after they are created on the remote server, these files
need to be delivered to the mobile device, where they are stored on
the device's persistent storage 65.
[0004] In the email service provided on a RIM Blackberry device,
for example, once the software on the mobile device is set up,
email messages automatically arrive when they are available, with
no user action required.
SUMMARY
[0005] In general, in an aspect, in controlling a download of one
or more files from a server to a mobile device, account is taken of
at least two of: a power status of the mobile device, a network
connectivity status of the mobile device, an urgency of the file,
and the existence of a user-indicated preference about the
download.
[0006] Some implementations include one or more of the following
features. The controlling includes suspending a download of a file
that is occurring when a power level or network connectivity
degrades during the download. The suspending of the download is
based on a set of rules or heuristics. The suspended download is
resumed when the power level or network connectivity improves
during the suspension. The resumed download does not include at
least some of the file or files that were downloaded before the
suspension. The resumed download does not include one or more
pieces of a file that were downloaded before the suspension.
[0007] In general, in an aspect, download of a file from a server
to a mobile device through a network is controlled by breaking the
file into pieces to be sent separately, monitoring conditions of
the mobile device and the network with respect to each piece,
considering suspending download of a subsequent piece if the
conditions deteriorate with respect to a piece.
[0008] Some implementations include one or more of the following
features. The conditions are monitored after each piece is sent and
before download of the subsequent piece has begun. A partial
download of a file is allowed to continue under deteriorated
conditions, if predetermined circumstances exist.
[0009] In general, in an aspect, a user of a mobile device, to
which large files are normally downloaded automatically from a
server based on the user's preferences, can initiate a download by
invoking a `sync now` option on a user interface of the mobile
device.
[0010] In general, in an aspect, at a mobile device, a sync signal
is received from a server with respect to one or more large files
to be downloaded, and to the sync signal is responded to by
requesting and accepting a download of the one or more large
files.
[0011] In general, in an aspect, at a mobile device, an indication
is displayed to a user of the time when a download of one or more
large files to the mobile device is expected to occur.
[0012] In general, in an aspect, an amount of bandwidth used to
download one or more large files to a mobile device is adjusted
based on a time of day when the download is to occur.
[0013] Some implementations include one or more of the following
features. The amount of bandwidth used at a given time of the day
is governed by an amount paid by a user of the mobile device.
[0014] In general, in an aspect, a log of download activity, with
respect to one or more large files that are downloaded to the
mobile device, is sent from a mobile device to a server.
[0015] In general, in an aspect, a user of a mobile device can
specify one or more types of files that are to be downloaded to the
mobile device, and the specification of file types is stored in a
server in association with an identification of the mobile device
or the user.
[0016] In general, in an aspect, at a server, one or more files are
selected to be downloaded to a mobile device based on stored
preferences of a user of the mobile device and stored information
about files that were previously downloaded to the user's
device.
[0017] In general, in an aspect, a list of files that are in
process of being transmitted to a client mobile device, but which
have not yet been completely transmitted to the device, is
displayed to a user of the device
[0018] Implementations may include one or more of the following
features. The displaying includes showing a percentage of at least
one of the listed the files which has been transmitted. The
displaying can occur at the mobile device. The displaying can occur
on a web page.
[0019] These and other features and aspects, and combinations may
also be expressed as methods, apparatus, systems, program products,
databases, means for performing functions, and in other ways.
[0020] Other advantages and features will become apparent from the
following description and from the claims.
DESCRIPTION
[0021] FIGS. 1 and 2 are block diagrams of a system architecture
including a server and a client.
[0022] FIG. 3 is a user-flow diagram of a client application.
[0023] FIG. 4 is a screen shot of a user application.
[0024] FIG. 5 is a menu of the application.
[0025] FIG. 6 is a screen shot of a video file.
[0026] FIG. 7 is a screen shot of a web-based subscription
portal.
[0027] FIG. 8 is a block diagram.
[0028] Some of the files 10, 20 in FIG. 1 are large. For example, a
30-minute audio, a10+ minute video file, and a collection of 100+
web pages may be from 1 MB to 500 MB or larger.
[0029] In the technique described here, the user of the mobile
device never needs to take any explicit action to query for new
files on the server, nor to fetch the files from the server.
Delivery 40 of the new files (for example, over an IP network) can
occur automatically and without explicit user action or knowledge.
There is no need, for example, to press any key on the mobile
device or to attach a cable to the device to cause the file
delivery to occur.
[0030] In contrast, typical files delivered to mobile devices
today, such as email messages, audio files, and individual web
pages, are typically in the 10 KB to 200 KB range each.
[0031] Delivering a file that is tens or hundreds of megabytes to a
mobile device presents challenges that are absent in delivering
smaller files. With large files, a complete download may take tens
of minutes or even hours, depending on the speed of the connection.
During this time, conditions may change. For example, at the start
of the download, the mobile device may be within an area with
excellent wireless network coverage; but as the download
progresses, the network conditions may degrade.
[0032] Also, as the download progresses, the device's battery may
lose its charge to a level at which continuing the file downloading
risks depleting the battery. Generally speaking, small-file
applications (music downloads, email, web browser) are not and need
not be sensitive to these issues. In other words, downloading a
file that is large may entail a time delay that implicates one or
more other factors in the strategy used to determine the manner and
timing of the download.
[0033] In the technique described here, an application 60 manages
the delivery of these large files from the remote server to the
mobile device in a way that is sensitive to the following
considerations:
[0034] Network. The mobile device has one or more network
interfaces 80, e.g., GPRS/EDGE, CDMA/EVDO, WiFi, Bluetooth, or USB
cable tethered to a host computer, each of which can take advantage
of a network resource for connecting to the Internet 40 (or other
communication network). This connection is the "last hop" for data
traveling over the IP network from the server to the device. The
availability of one or more of these network resources will vary
from time to time as, for example, the mobile device moves in and
out of network "hotspots." For example, at one moment, WiFi and
EDGE may be available; a few minutes later, only EDGE may be
available.
[0035] The mobile device's power status 70 varies from time to
time, depending, for example, on whether the device is charging or
how long it has been on battery.
[0036] Timeliness. Certain files 10 are time sensitive and may need
to be delivered right away (e.g., a stock ticker update). Other
files 20 are relatively time insensitive, and a delay of hours in
delivery may be acceptable (e.g., a movie trailer). Each file
stored on the remote server may be annotated with an "urgency"
parameter 30, which may be assigned by a creator of the file
(content) or determined based on some other policy.
[0037] These considerations are sometimes interrelated. For
example, a mobile device attempting to receive data over a
poor-quality network connection can cause a significant drain on
its battery.
[0038] We shall denote by "sync'ing" the process of copying a file
from the remote server to the mobile device.
[0039] We describe a method for sync'ing that is sensitive to the
above considerations. The method takes into account a set of
factors (two or more) in determining a sync'ing policy, by which we
mean whether and how often to sync. In some implementations, there
is a particular algorithm used to take into account these factors
to implement a sync'ing policy.
[0040] As shown in FIG. 2, an example of the technique described
here includes three parts: a client, a server, and a file
repository. The client is a software application 273 that resides
on the mobile device 275. The server 200 is comprised of a set of
software components including a web portal 210, a sync module 220,
a log upload module 230, and a database 240. The file repository
290 includes a file system storing files for subsequent delivery to
devices, and an application that manages the delivery of those
files over an IP network (an example of such an application is the
Apache HTTP server--http://httpd.apache.org/).
[0041] The client may be installed by the device manufacturer (OEM)
before delivery to the retail outlet which sells or delivers the
device (we sometimes refer to the mobile device simply as a device)
to the end-user. Alternatively, the client may be installed by the
end-user after he has acquired the device, by downloading the
software application from the Internet.
[0042] In some implementations, the client behaves as follows:
[0043] Wait for a signal to indicate that sync'ing should occur.
The signal may come from the device itself, from the server 265, or
from the end-user 255. [0044] Select an available IP channel (GPRS,
WiFi, HSDPA, USB port) for the sync'ing. [0045] Connect to the sync
module 220 on the server and transmit a query (that conforms to a
defined sync'ing protocol) for new files 250. [0046] Download new
files 280 from a file repository 290 and treat old files as
expired. [0047] Optionally, report (in conformity with the sync'ing
protocol) behavior and usage 260 back to the server
[0048] The application performs these steps transparently to the
user. That is, the user need not take any action to cause the steps
to be performed and the user need not be made aware of any of the
steps occurring. New files are delivered--hourly, daily,
weekly--directly to the mobile device. No user action is required.
This is similar to the behavior of a home Digital Video Recorder
(DVR).
[0049] Once the files have been downloaded, they can be stored on
the device's file system. For example, on a Windows Mobile device,
the files could be stored in the "My Documents" folder. The user
can access them manually, using existing tools on the mobile device
(e.g., a "File Manager" application on a Windows Mobile
device).
[0050] However, because user-access to a device file system is not
always available (e.g., on many Java-based phones) and because even
when such access is available it is not always intuitive, the
client may include an application (FIGS. 3, 4) that provides a
user-friendly access to a list of downloaded and
currently-available files. The application 400 may enable the user
to view information about the available files (410 and 500. As
shown in FIG. 5, the application display a menu 600 containing an
option 610 to manually force a sync'ing with the server. The
application may also allow the user to view files that are
scheduled for delivery and/or in transit 430, but not yet fully
downloaded. The application may also allow for users to change some
aspects of the behavior of the client application 420, and show
some details about the version and copyright information of the
application 450.
[0051] The delivered files may be of various types. For example,
web pages (e.g., HTML), audio files (e.g., MP3), video files (e.g.,
h.264 or WMV9 or Flash), and so on. The application need not itself
provide rendering/playout/presentation for any or all of these file
types. Instead, the application may interface with existing
applications (web browser, media player, etc.) on the device
through standard application programming interface (API) calls.
Once the user selects a file from the list (or from the native file
browser), the appropriate external application is launched to
render the file (FIG. 6, 700).
[0052] The server's behavior need not be a synchronous step-by-step
process, but rather can be a set of tasks that occur
asynchronously, as the server is contacted by various mobile
devices 275 and web-based terminals 285. The server's behavior in
some implementations includes the following (with reference again
to FIG. 2): [0053] When contacted by a web browser 285 through an
HTTP connection 270, serve up web pages from a portal 210 that
allows end-users to personalize their subscriptions including
specifying the kinds of files they wish to receive (e.g., news
updates, movie trailers, weather reports, etc.). A representative
screen shot of the subscription portal is shown in FIG. 7. The
portal may provide 800 a menu of subscriptions or "channels"
available for selection. The web portal may show 810 the current
subscription policy of the user, e.g., which channels the user has
requested to be delivered to his device. The portal may allow the
user to edit this subscription policy. [0054] Retain persistent
data in a database 240. Among the information in this database are
(a) the subscription policy for each user, and (b) usage
information uploaded from every client device 275. [0055] Deliver
download instructions 265 to a client 275 upon request. These
instructions direct the client to a file repository 290 (which may
be separately located and controlled) where the files are stored
and from which they are served over an IP connection 280. [0056]
Receive uploaded usage data from each mobile device 275 in a module
230 and store it in the database 240.
[0057] When a mobile device 275 queries the sync module 220 about
the presence of new files, the sync module performs a multi-step
process to determine if any such files are present. In some
implementations, that process includes the following: [0058] Check
the user's subscription policy in the database 240, i.e., discover
which kinds of files the user has previously (through the web
portal 210) requested. [0059] Check the database 240 to discover
which file(s) were most recently delivered to the user. [0060]
Check the file repository 290 to see which files have appeared
subsequent to the files most recently delivered to the user. [0061]
Deliver over an IP connection 265 to the mobile device 275 a
manifest of pointers to the newly-arrived files residing on the
file repository 290.
[0062] Sync Protocol
[0063] In some implementations, the sync'ing protocol includes the
following features. [0064] Account for Current Conditions
TABLE-US-00001 [0064] Condition Example Sync? Impossible to sync No
network access No Expensive to sync Poor network access (sync'ing
would No consume a lot of battery charge) Inexpensive to sync High
speed connection (e.g., WiFi) is Yes available Scarce resources
Battery charge is below a certain No threshold Abundant resources
Device is charging or battery is full Yes charged User wants or 1.
File priority is high, or Yes needs the file(s) 2. User explicitly
requests a sync
[0065] Monitor Device Conditions During Sync'ing
[0066] Instead of performing only a one-time check (to decide
whether to sync or not) prior to a download and then downloading
one or more files, the protocol also checks the device's conditions
(power, network) during the download. To accomplish this, in some
examples, the file 900 (in FIG. 8) may be split 910 into pieces
920, 930, 940, and 950 which are sent individually 952, 954, 956,
and 958 The client 960 checks the conditions after every piece is
received and then continues (or not) the download at its
discretion. The constituent pieces of each file are reassembled at
the client as they arrive, or, alternatively, when the final piece
is downloaded. Should conditions deteriorate and force the client
to suspend downloading, the download will resume from the suspended
point (as opposed to from the beginning of the file) when
conditions are suitable.
[0067] The protocol also allows for the client to continue
downloading for some limited period of time even if conditions have
deteriorated.
[0068] Initiating Sync'ing
[0069] The protocol allows for a sync (we sometimes refer to a
sync'ing procedure simply as a sync) to be initiated in several
ways.
[0070] One way is to use a timer on the client; when the timer
expires, the client queries the server for the presence of new
files. In the sample algorithm set forth below, the proposed
counter starts at 300 seconds. To perform the count down, the
client application must be always running on the device. This is
much like a standard mobile application (e.g., a game), which is
either active or closed, and when closed, does not consume any
random-access memory on the device. In these implementation, the
client application must be auto-started when the device is booted,
and it must persist while the device is on. This is analogous to a
home DVR, which is always on.
[0071] A second way to initiate a sync is in response to a user
request. The client application may provide a "Sync Now" button or
link. (FIG. 5) If user selects it, the application may:
[0072] (1) Attempt to perform an immediate sync, regardless of the
conditions.
[0073] (2) Evaluate the `downloadAllFiles` variable in the below
algorithm, based on current conditions. If the variable evaluates
to `true`, then the sync is performed. If not, the cause for
failure may be presented to the user with a prompt, e.g., "The
battery is only 1/3 full. Sync'ing may drain the battery further
and risk draining it altogether. Do you wish to sync anyway?"
[0074] A third way to initiate a sync is from the server. In some
settings, the client may be capable of receiving asynchronous
messages directly from the server. For example, a RIM Blackberry
device provisioned to use a Blackberry Enterprise Server (BES) can
receive signals directly from the server through an MDS component.
Therefore, the client application need not continuously poll the
server for new files, nor remain active. The application can,
instead, be inactive until the server signal arrives and causes the
device to launch the application.
[0075] Algorithm
[0076] The features described above (and other features in various
combinations) can be implemented in a wide variety of algorithms.
Among other things, different algorithms may specify different
techniques for suspending (and subsequently resuming) file
downloads as conditions change. We provide one example of an
algorithm below. We first introduce several terms and parameters
that are relevant to the example.
[0077] Urgency Levels [0078] a. Urgent: File marked as
time-sensitive and should be delivered as soon as possible. [0079]
b. Regular: File is not time-sensitive.
[0080] Battery Consumption Levels [0081] a. Charging: device is
plugged into A/C power. [0082] b. High: Running off battery, which
is at least 7/8 charged. [0083] c. Medium: Running off battery,
which is between 1/2 and 7/8 charged. [0084] d. Low: Running off
battery, which is less than 1/2 charged.
[0085] Network Connectivity Levels [0086] a. Fast: Using WLAN.
[0087] b. Strong: using radio-access network; strong signal. [0088]
c. Medium: using radio-access network; medium signal. [0089] d.
Weak: using radio-access network; poor signal. [0090] e. None: no
network connectivity.
[0091] The example algorithm follows:
TABLE-US-00002 // When idle, wait this much time (in seconds)
between probes for new content #define
TIME_BETWEEN_CHECKS_FOR_NEW_CONTENT 300 // While downloading, wait
this much time (in seconds) between checking on the vital signs
(battery, network) #define TIME_BETWEEN_PROBES_OF_VITALS 120 // If
conditions degrade during a download session, stop after this many
seconds #define MAX_TIME_IN_DEGRADED_STATE 120 last_check =
getTime( ); do forever { // check to see if server has any new
files to download If (getTime( ) - last_check >
TIME_BETWEEN_CHECKS_FOR_NEW_CONTENT) { File_list = check_for_files(
); last check = getTime( ); } If (File_list is empty) continue; //
Nothing to download If (network == "none") continue; // No network
access - can't do anything Boolean downloadAllFiles =
(battery=="charging") || // device is on AC power
((battery=="high") && (network >= "strong")) || //
device nearly charged and connection is strong ((battery=="medium")
&& (network =="fast")); // device only half-charged but
with high-speed connection // lower the bar somewhat for just
downloading urgent files Boolean downloadUrgentFiles =
(downloadAllFiles==false) && (battery=="medium" &&
network >="medium"); // device half-charged, network connection
is so-so if (downloadAllFiles) downloadFiles( ); else if
(downloadUrgentFiles) downloadUrgentFiles( ); } method
downloadFiles( ) { beginBatteryState = getBatteryState( );
beginNetworkState = getNetworkState( ); int
timeSpentInDegradedState = 0; for (file in File_list) { while (not
done) { // download another chunk of this file int startTime =
getTime( ); download_from_file(file); int timeForThisChunk =
getNow( ) - startTime; // Check our vitals. If nothing has changed,
then carry on. If (getNetworkState( ) == beginNetworkState
&& getBatteryState( ) == beginBatteryState) { continue; }
// Warning - vital signs are worse than when we began this download
session // Increment the amount of time we've spent in this
degraded state timeSpentInDegradedNetworkState += timeForThisChunk;
// Have we reached time limit on downloading in degraded state?
if(timeSpentInDegradedNetworkState > MAX_TIME_IN_DEGRADED_STATE)
return; } // if we made it here, we downloaded `file`. Now onto the
next file... } } method downloadUrgentFiles( ) { // not shown
explicitly; slight variation from downloadFiles( ) method, shown
above } method download_from_file(File) { // continue downloading
from `File`. Stop downloading after `TIME_BETWEEN_PROBES_OF_VITALS`
seconds }
[0092] Additional Condition: Time of Day
[0093] Voice and SMS traffic generate more revenue per bit to the
owner of a mobile network than generic data traffic. Therefore,
during daytime hours (e.g., 9 AM-7 PM), when voice and SMS traffic
is high and spare capacity limited, network owners are likely to
discourage network-intensive applications. On the other hand, most
cellular networks are `latent` during off-peak hours such as 9 PM-6
AM. During this time window, mobile network owners are likely to be
more receptive to network-intensive applications.
[0094] In short, bandwidth on a wireless radio-access network
(e.g., EDGE or EVDO) is a commodity whose value to the network
owner varies over time.
[0095] The application can accommodate this constraint by disabling
sync activity altogether during daytime hours when sync'ing
requires mobile network access. The result is that users may only
receive updates during the evening hours.
[0096] Alternatively, the application can throttle its mobile
network bandwidth usage to an acceptable level during the daytime
hours by waiting a specified period of time between downloading
chunks of data. For example, the application can cut by 50% its
bandwidth usage by pausing for `timeForThisChunk` seconds after the
chunk (e.g., a piece of a file) has been downloaded. Similarly, the
application can cut by 67% its bandwidth usage by pausing for twice
this amount of time.
[0097] A network operator can offer a tiered level of service to
its customers, in which those customers who pay for a `premium
service` are permitted higher throughput for during-the-day
downloads over the mobile network. The application used by premium
customers would not be forced to pause (as long, or at all) between
chunk downloads.
[0098] Other implementations are also within the scope of the
following claims.
* * * * *
References