U.S. patent application number 17/713124 was filed with the patent office on 2022-07-14 for managed network content monitoring and filtering system and method.
The applicant listed for this patent is Securly, Inc.. Invention is credited to Tigran GEVORGYAN, David HINKLE, Vamsee KRISHNA, Vinay MAHADIK, Amar PATEKAR.
Application Number | 20220224696 17/713124 |
Document ID | / |
Family ID | 1000006242100 |
Filed Date | 2022-07-14 |
United States Patent
Application |
20220224696 |
Kind Code |
A1 |
HINKLE; David ; et
al. |
July 14, 2022 |
MANAGED NETWORK CONTENT MONITORING AND FILTERING SYSTEM AND
METHOD
Abstract
A system and method for content request monitoring and filtering
for a plurality of managed devices in a managed network uses a
smart PAC file that is uniquely associated with a particular user
using a particular managed device and a DNS look up to perform both
the logging/monitoring of the content request and the filtering
without a hardware appliance or partial proxying.
Inventors: |
HINKLE; David; (San Jose,
CA) ; KRISHNA; Vamsee; (San Jose, CA) ;
GEVORGYAN; Tigran; (San Jose, CA) ; PATEKAR;
Amar; (San Jose, CA) ; MAHADIK; Vinay; (San
Jose, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Securly, Inc. |
San Jose |
CA |
US |
|
|
Family ID: |
1000006242100 |
Appl. No.: |
17/713124 |
Filed: |
April 4, 2022 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
16836839 |
Mar 31, 2020 |
11329993 |
|
|
17713124 |
|
|
|
|
16414728 |
May 16, 2019 |
11265332 |
|
|
16836839 |
|
|
|
|
62672964 |
May 17, 2018 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04L 63/0245 20130101;
H04L 51/212 20220501; H04L 67/535 20220501; G06F 16/9566 20190101;
H04L 43/00 20130101; G06F 16/955 20190101; G06F 9/547 20130101;
H04L 63/10 20130101; H04L 45/745 20130101; H04L 63/0263 20130101;
H04L 63/108 20130101; H04L 67/56 20220501; H04L 67/562 20220501;
H04L 63/0281 20130101; G06F 16/27 20190101; G06F 21/6218 20130101;
H04L 63/00 20130101; H04L 61/4511 20220501; H04L 67/02 20130101;
H04L 63/0236 20130101; H04L 63/20 20130101; H04L 67/133 20220501;
H04L 63/0227 20130101 |
International
Class: |
H04L 9/40 20060101
H04L009/40; H04L 43/00 20060101 H04L043/00; H04L 67/562 20060101
H04L067/562; G06F 9/54 20060101 G06F009/54; G06F 16/955 20060101
G06F016/955; H04L 61/4511 20060101 H04L061/4511; H04L 67/50
20060101 H04L067/50; H04L 67/02 20060101 H04L067/02; G06F 21/62
20060101 G06F021/62; H04L 67/56 20060101 H04L067/56; H04L 67/133
20060101 H04L067/133; G06F 16/27 20060101 G06F016/27; H04L 45/745
20060101 H04L045/745; H04L 51/00 20060101 H04L051/00 |
Claims
1. A method, comprising: by a computer with a processor and a
memory, receiving a request for a proxy-auto config (PAC) file from
a browser of a managed device that has not accessed an Internet
within a preset amount of time; sending, by the computer, to the
requesting browser, a PAC with a Javascript code for access
permissions and an identifier for each managed device and
corresponding unique user; correlating by the computer, the
identifier with a filtering policy for the unique user; sending by
the computer, the identifier to a DNS server which can execute the
correlated filtering policy; utilizing by the computer, remote
procedure calls (RPCs) to monitoring content and filtering
information among PAC, web server and DNS server.
2. The method of claim 1 wherein the request from the browser of
the managed device that has not accessed the Internet within a
preset amount of time is by a GET command.
3. The method of claim 1 wherein the PAC with the Javascript code
also contains content monitoring code.
4. The method of claim 1 wherein the PAC with the Javascript code
also contains filtering code.
5. The method of claim 1 wherein the identifier is a tracking
number.
6. The method of claim 1 wherein the unique identifier is a DID
file.
7. The method of claim 1 wherein the RPC calls have a format of
arguments.endpoint.cluster.v1api.securly.com.
8. The method of claim 1 wherein the RPC call has an endpoint
called on a particular cluster with a series of arguments to return
a value.
9. The method of claim 1 further comprising, PAC navigation logging
provided by the RPC call regarding what hosts and URL the user is
visiting.
Description
PRIORITY CLAIMS/RELATED APPLICATIONS
[0001] This application is a continuation of U.S. patent
application Ser. No. 16/836,839 filed Mar. 31, 2020 which in turn
is a divisional of and claims priority to U.S. patent application
Ser. No. 16/414,728 filed May 16, 2019 which claims the benefit
under 35 USC 119(e) and priority under 35 USC 120 to U.S.
Provisional Patent Application Ser. No. 62/672,964 filed May 17,
2018 and are entitled "Managed Network Content Monitoring And
Filtering System And Method," the entirety of which is incorporated
herein by reference.
FIELD
[0002] The disclosure relates generally to a system and method for
monitoring and filtering internet content for a managed
network.
BACKGROUND
[0003] The idea of monitoring and filtering content and web
browsing for a managed device is well known. In a first
conventional system, an in-line hardware appliance is inserted into
the path between the managed network and the Internet to monitor
and filter content requests. These in-line hardware appliances
require a piece of relatively expensive hardware installed at any
ports to the Internet and are difficult to manage by an IT person
of the managed network. Other known systems implement a domain name
service (DNS) or proxy approach that logs the content request sites
and takes filtering actions and is typically implemented in
software or the cloud. This proxy type approach requires a huge
bandwidth cost if the proxy is proxying all content requests. Some
proxy systems use a selective proxying approach in which the proxy
chooses which content request will be proxied. However, the
selective proxying approach cannot keep up with content development
making the selective proxying approach less secure. For example,
the selective proxy may have a list of sites that are monitored,
but will not be able to log access to a newly created site until
the list of monitored sites are updated in the selective proxy.
Other known systems use a piece of software installed on each
managed device to monitor and filter content. However, to make a
commercially viable product, the developer must develop a version
of the software for each different managed device and each
different operating system which is difficult.
[0004] Some known systems use a proxy auto-config (PAC) file that
defines how a web browser of each managed device can automatically
choose the appropriate proxy server (access method) for fetching a
given uniform resource locator (URL). The PAC file contains a
Javascript function "FindProxyForURL(url, host)". This function
returns a string with one or more access method specifications.
These specifications cause the user agent to use a particular proxy
server or to connect directly. Like the selective proxying above,
this method has the same problem that the proxying is behind the
content development resulting in reduced security for the managed
network.
[0005] All of the above technical problems with existing monitoring
and filtering systems result in a need for a monitoring and
filtering system that overcomes these limitations and problems with
the conventional systems and it is to this end that the disclosure
is directed.
BRIEF DESCRIPTION OF THE DRAWINGS
[0006] FIG. 1 illustrates an example of a system for monitoring and
filtering content for one or more managed devices of a managed
network;
[0007] FIG. 2 illustrates the system for monitoring and filtering
content of FIG. 1 and its method for associating a customer
identifier with a universally unique identifier;
[0008] FIG. 3 illustrates the system for monitoring and filtering
content of FIG. 1 and its method for monitoring and filtering a
content request from a managed device;
[0009] FIGS. 4A and 4B illustrate a data flow for an exemplary
implementation of the method for content request monitoring and
filtering;
[0010] FIG. 5 illustrates a data flow for another exemplary
implementation of the method for content request monitoring and
filtering; and
[0011] FIG. 6 illustrates an example of a smart proxy auto config
file that may be used by the system.
[0012] Detailed Description of One or More Embodiments
[0013] The disclosure is particularly applicable to
monitoring/logging and filtering content from content requests for
a plurality of managed devices connected to an entity managed
network and it is in this context that the disclosure will be
described. For purposes of illustration, an example use case is
described in which the entity is a school district and the managed
devices are used by teachers and students, each of whose content is
monitored and filtered differently due in part to a proxy
auto-config (PAC) file that is unique for each user as described
below. It will be appreciated, however, that the system and method
has greater utility since it may be used to monitor and filter
content for any entity managed network and may also be implemented
in different manners than the examples described below and shown in
the attached figures.
[0014] A system and method for monitoring and filtering content
from the Internet based on content requests for a plurality of
managed devices that connect to an entity managed network may
utilize a smart PAC file, a universally unique identifier (UUID)
assigned to each user of each managed device, a domain name service
(DNS) lookup to monitor the content request and decide whether the
particular request is permitted so that each managed device can
then enforce the content filtering decision. The system and method,
as described below in more detail, implement a content filtering
process that is unconventional, not routine and not well
understood. Specifically, since known content filtering system use
the techniques described in the background and have been doing so
for a long time, the unique combination of processes is
unconventional as compared to the known content filtering system,
is not routine nor well understood. Furthermore, the disclosed
system uses a novel arrangement and location of the elements of the
system including the smart PAC file at the web server and the
generation of the UUID for each user of the managed device that is
returned with the smart PAC file, the synchronization of the UUID
to a remote DNS server, the remote DNS server logging/monitoring
the content request based on the content request and the UUID of
the user making the content request (without proxying all content
requests like conventional systems) and the managed device remote
from the DNS server and web server enforcing the web content policy
for the particular managed device.
[0015] The system and method described below further provides a
technical solution to the technical problems of the known
monitoring and filtering content systems. For example, the
disclosed system does not require an expensive hardware appliance
at each port or the complicated management required for hardware
appliances while still providing the content request
monitoring/logging and filtering and the ability to monitor all
sites visited as described below. Similarly, the disclosed system
does not require proxying each content request that is bandwidth
intensive and slow and does not use selective proxying that is less
secure. Similarly, the disclosed system does not require installing
software on each monitored device or operating system.
[0016] FIG. 1 illustrates an example of a system 100 for monitoring
and filtering content for one or more managed devices 102 of an
entity managed network that is shown below the dotted line in FIG.
1 for content requested from the Internet shown above the dotted
line. The system 100 for monitoring and filtering content, like
other known systems, acts as a gatekeeper that prevents a user who
is using a managed device 102 from accessing certain content or
types of content from other networks or the Internet. The system
100, however, accomplishes this goal using a novel arrangement of
components and processes that overcomes the problems and
limitations of the known systems described above.
[0017] The system 100 may include the one or more managed devices
102 each of which is being used by a user employed or associated
with the entity, such as teachers, administrators and students at a
school district, to access content on an external network or the
Internet. The system 100 may be used with any managed device 102
that has a processor, memory and a display in which the processor
of the managed device executes a well-known browser application or
other application to access content external to the entity managed
network (known as external content hereinafter). For example, the
managed devices 102 may include a terminal device, a tablet
computer, a smartphone device 102A, such as an Apple.RTM.
iPhone.RTM. or Android.RTM. operating system based device, a laptop
computer 102B, . . . , and a desktop computer 102N. While each
managed device 102 is conventional and routine since each is
commercially available, the content monitoring and filtering
processes achieved using those managed devices is not conventional,
well-understood or routine as described below in more detail.
[0018] The system 100 may also include a web server 104, a DNS
server 106 and a smart PAC file 108 hosted at the web server 104
that collectively provide the content request monitoring and
filtering processes. The web server and the DNS server are each
conventional and well known pieces of computer hardware, but each
have a plurality of lines of computer code executed by a processor
of each server that implement the unconventional content request
filtering processes described below. Thus, the system uses these
well-known computer elements in a novel way and configuration due
to the plurality of instructions that perform processes that
overcome the limitations and problems with the conventional
monitoring and filtering content systems.
[0019] The operation of the system will now be described. It should
be understood that although the operation is being described as
actions being performed by the elements shown in FIG. 1, the
content monitoring and filtering method and its processes may be
performed using other elements and the method is not limited to the
elements shown in FIG. 1 performing the method processes.
[0020] In operation, a network management administrator first
configures all devices in the managed network to use a PAC file
location (108) hosted on the web server location (104). When a user
first submits a content request for content (whether external to
the entity managed network or stored within the entity managed
network), the browser application of the managed device 102 may
issue a GET PAC request 120 to the web server 104 to retrieve a PAC
file 108 that contains the method for content specifications for
filtering content as described above. In this system, the web
server 104 may return a smart PAC file unique to each user 122
wherein that smart PAC file may include a universally unique
identifier (UUID) for each user (such as
johnsmith@exampleschool.org in an example in which a school
district is using the monitoring and filtering system, and usually
tracked via web-authentication & cookies by a web server such
as 104) that is generated by the web server 104 and returned to the
managed device 102 with or as part of the PAC file 108 that is
unique for the user. This process may be implemented using remote
procedure calls (RPCs) and further details of this process is
described below. Thus, in the example in FIG. 1, each managed
device 102A-102N receives a unique PAC and the UUID that associates
the user with the particular PAC file. Each unique PAC file has the
specifications (the policy) that control the content filtering for
each user. As part of the above process, the association of the
particular PAC with a particular user (and unique ID or tracking
number) may be synchronized from a database 200 of the web server
104 onto a database 202 of the domain name service (DNS) server 106
of the web filtering company as shown in FIG. 2. This
synchronization allows the domain name service (DNS) server 106 of
the web filtering company to perform the DNS lookup for each user
and monitor/track and make filtering decisions about the content
requests for each user and providing a technical solution.
[0021] When a user of the managed device makes a content request,
the content request includes the request for the content (including
the host and uniform resource location (URL)) and the UUID. The
content request is communicated from the browser to a DNS server
300 of the entity for the managed network and may be passed onto a
root DNS server since the content request includes a link to the
web filtering company. The content request may then be communicated
(322) onto the web filtering company DNS server 106 using RPCs as
shown in FIG. 3 as described below in more detail. The web
filtering DNS server, through a DNS look-up, may monitor/track the
content request and may determine a filtering decision for the
particular content request from the particular user based on the
UUID as described below in more detail. The web filtering DNS
server may also include a process in which a decision is made, for
each content request, to either perform the DNS lookup for
filtering or use the PAC file and perform typical proxying of the
content request that are described below in more detail. The DNS
server 106 may communicate the content request decision (324) back
to the local DNS server 300. The content request decision may then
be communicated back (326) to the managed device 102B and the
browser of the managed device 102B enforces the content request
decision as shown in FIG. 3.
[0022] FIGS. 4A and 4B illustrate a data flow for an exemplary
implementation of the method for content request monitoring and
filtering for each content request made by a user using a managed
device in the entity managed network. The data flow shown in FIGS.
4A and 4B show the process for monitoring and filtering for a
managed device and user that needs to obtain the PAC file and the
UUID/DID/tracking number since the particular user and managed
device is new to the network, has had its cache of cookies with the
tracking number flushed or deleted or has not recently accessed
Internet content. The entities that are part of the data flow
include a browser, PAC logic that may be a part of any browser
application, the DNS server 106 and a cluster of web servers
(useast-www.securly.com for example) operated by the web filtering
company. In the example in FIGS. 4A and 4B, a user is seeking to
access content from www.evite. corn (a well-known electronic
invitation site), but the process in FIGS. 4A and 4B may be used to
monitor and filter access to any type of content and is clearly not
limited to accessing any particular type of content.
[0023] The data flow may include a process 400 of requesting and
receiving the PAC file, a proxy decision process 402 and a
brokering process 404. During the process 400, the PAC logic of a
browser of a managed device that has not accessed the Internet
recently or, is a new managed device on the network, etc. will
request a proxy auto-config (PAC) file using a GET command (such as
GET/smart.pac?fid- . . . &cluster-useast as shown in FIGS. 4A
and 4B) which is a standard process that a browser application
performs for a managed device that does not already have a PAC
file. However, unlike the typical and conventional PAC file that
has methods for access permissions, the smart PAC file has the
Javascript code for access permissions (and other code for the
content monitoring and filtering an example of which is shown in
FIG. 6) and an identifier (or a tracking number) for each managed
device and user that is universally unique. In the example in FIGS.
4A and 4B, the cluster useast returns the smart PAC file that
include the identifier "123" (called DID in the example--that
translates to a user such as johnsmith@exampleschool.org tracked by
the web server 104) that universally uniquely identifies the
managed device and the user presently using the managed device. In
the implementation shown in FIGS. 4A and 4B, a Set-Cookie DID--123
may be used to assign the DID to the managed device and the user
presently using the managed device. The tracking number associated
with the PAC file that uniquely identifies each managed device and
user of the managed device is also associated with a filtering
policy for the user and then other systems, like the DNS server
106, receives the tracking number and can execute the appropriate
filtering based on the associated policy.
[0024] The data flow now proceeds to the proxy decision process
402. During this process 402 and the brokering process 404 shown in
FIGS. 4A and 4B, remote procedure calls (RPCs) may be used to
communicate and transfer information between different systems
including the PAC, the DNS server, the web server, etc. for
monitoring and filtering. While it is known and routine to use an
RPC call for spam filtering techniques, it is unconventional, not
routine and not well understood to use RPC calls for content
monitoring and filtering for data communicating (including the host
and URL of the content request and the DID/tracking number) between
the system elements including the smart PAC 108, the web server 104
and the DNS server 106 of the system. The RPC calls may have the
format of: arguments.endpoint.cluster.vlapi.securly.com which is a
unique and unconventional API interface standard for communicating
with the content monitoring and filtering system over the DNS
protocol. Each RPC call may have endpoint called on a particular
cluster with a series of arguments and return a value. In one
example used in FIGS. 4A and 4B, the cluster may be useast and
useast.v1api.securly.com is the DNS subdomain used for web content
monitoring and filtering. In the above format, the endpoint is a
name of an API call such as log, prx or mip, arguments may be a
series of text strings separated by period and the return value may
be, for example, an IP address (integers), although other return
values are possible. In one implementation, a return value, for a
prx RPC, of XXX.0.0.2 indicates that a proxy will be used for the
particular content request and a return value of XXX.0.0.1
indicates that the DNS lookup process (shown in more detail in FIG.
5) may be performed where XXX is a three digit number.
[0025] In the proxy decision process 402, an RPC call is initiated
by the PAC logic in the browser from the PAC to the filtering DNS
server 106. For example, for a content request to www.evite.com,
the RPC call may be www.evite.com/welcome.123.prx.vlapi.securly.com
where "prx" is the particular RPC call, "123" is the tracking
number that associates the PAC file with the particular managed
device and user who made the content request. This RPC call
provides an unconventional mechanism for the web content monitoring
and filtering system to communicate data from the smart PAC to the
DNS server 106. In more detail, the RPC call provides PAC
navigation logging in that the PAC can transmit information about
what hosts and URL the user is visiting ("www.evite.com" being the
host and "www.evite.com/welcome" being the URL) and it's PAC
identity (the tracking number or DID). The PAC navigation logging
allows the DNS server 106 to receive policy information for the
particular user and the particular managed device to apply to the
hosts/URL's in the content request and take action to log
information about the user's activity whether or not the user's
content request is proxied as described below. This unconventional
technique in the content filtering industry allows the system to
log information about the user and his/her content requests while
avoiding incurring the expense of proxying the user which is the
major competitive advantage.
[0026] In the proxy decision process 402 in FIGS. 4A and 4B, the
tracking number of the PAC (123 in this example) is not yet known
to the DNS server 106 since the synchronization of the PAC and
tracking number association with the DNS server 106 has not
occurred. Thus, since the content request has a tracking number
that is unknown, the DNS look up process (based on the RPC) returns
127.0.0.2 indicating that the PAC is unknown (since the DNS server
106 does not have the association of the provided tracking number
to any PAC assigned to a particular user and managed device) and to
use proxying using the PAC file of the particular user and managed
device. The PAC logic receives the response from the DNS server 106
and sends a command to perform proxying for the particular content
request.
[0027] During the brokering process 404, the tracking number for
the particular PAC file assigned to the particular user using the
particular managed device may be synchronized to the DNS server 106
so that the DNS server 106 recognizes the particular PAC file and
can perform the DNS lookup to monitor and filter the content
request of the particular user using the particular managed device.
In the example in FIGS. 4A and 4B, since the DID/tracking number
associated with the particular PAC file is missing (since the PAC
file was only recently assigned the 123 tracking number), the
brokering process uses a sync RPC (communicating data from the
cluster/DNS server to the browser/smart PAC) with a token (for
example
http://token.sync.pacprc.useast.vlapi.securly.com/smart.pac?parpr-
c=svnc&argument=TOKEN& redirect=NEXTURL as shown in FIG. 4)
wherein the token is a restore token and the NEXTURL is a URL to
redirect back when the brokering is completed. Note this is another
example of an unconventional use of a RPC to perform data
communications during content monitoring and filtering. In more
detail, when the PAC detects the RPC call, the PAC generates a RES
DNS RPS call (as shown in FIGS. 4A and 4B) to fix the current
DID/tracking number to the TOKEN and synchronize the information
about the PAC file and the DID to the DNS server 106. In the
brokering process, the browser follows the redirect and asks the
PAC for a proxy decision and the PAC logic sees the special host
name (vlapi.securely.com) and generates an API call over DNS lookup
(for example, did.token.res.v1api.securely.com to the DNS server
106) that returns 127.0.0.1 and restores the DID to the cookie (and
binds the DID to the token in the database of the DNS server 106)
when that association is lost. This is again another example of the
unconventional use of an RPC call for content monitoring and
filtering. Once the DID to the TOKEN is fixed, the PAC is informed
of this and then instructs the browser not to use the proxy and
instead use the DNS lookup, such as
token.res.useast.v1api.securely.com that is sent to the DNS server
106 that returns decision (allow, deny or partial proxying of the
content request). A PHP script in the browser then loads the DID
looking up the token in the database (redis in one implementation)
and fixes the cookie such as by using GET/smart.pac? . . . HOST.
token.res.useast.v1api.securely.com that is sent to the cluster.
The cluster sends back a confirmation message that the cookie and
DID association is completed.
[0028] FIG. 5 illustrates a data flow for another exemplary
implementation of the method for content request monitoring and
filtering for direct access when the DID of the PAC file for the
particular user and particular managed device is known to the DNS
server 106 so that a DNS lookup may be used to perform the
monitoring and filtering. In this data flow, a user may request
data from www.evite.com through the browser and the PAC logic may
lookup "securlydns.securly.com" that returns an indication that the
user/managed device is not on the managed network at the time of
the content request (for example, the managed device is not in
school when the system is being used to managed a school network)
and the PAC logic generates a DNS lookup (for example,
www.evite.com.123.prx.vlapi.securely.com) using a RPC call to the
DNS server 106. The DNS server 106 logs the content request
(device=123 and site is www.evite.com) into a log file (to perform
the monitoring/logging aspect of the system without proxying) and
the DNS server returns a filtering decision to allow the content
request and instructs the PAC file to go direct and the browser
then directly accesses the requested content. In this way, the site
visited and the user visiting the site, are both logged by the DNS
server 106, without the need for any appliance, proxying or
software installed on the operating system or device--purely using
the PAC file and DNS service of the web-filter company.
[0029] The DNS lookup described above incorporates a bypass feature
that allows the inventive DNS lookup to disable the PAC file 108
entirely in certain situations. In particular, the system may
determine if the content request originates from the managed
network or originates from elsewhere (for example child with
managed device at home and not on school network in the example of
a school district managed network) and adjust the method of
filtering while still monitoring/logging the content request.
Specifically, if the request originates from a server in the
managed network served directly by the web filtering company's DNS
service 104, the DNS server 104 is able to detect the direct access
based on the source (e.g. via a source IP address lookup) and use
an RPC response that requests the PAC file 108 to shut itself down.
In this case then the normal DNS lookup monitoring and filtering
process is used without any additional involvement of the PAC file
108. However, if the content request is made with the PAC file (not
DNS directly since the managed device made the request from a
different network), the DNS server 104 is able to detect that the
request came via the DNS Root Servers and hierarchical DNS
propagation, and request the PAC file to stay active and not shut
itself down. In this case then, the PAC file 108 is used in
determining filtering although the logging is still performed as is
shown in FIG. 5.
[0030] The above monitoring and filtering for a content request
also has a process to handle when a user logs out from a managed
device. In particular, when a user logs out of a managed device,
the web server 104 shown in FIG. 1 sends an RPC to the PAC file
that flushes the cache and logs thus invalidates the cache and logs
to the PAC. Thus process also flushes the tracking number/DID
association with the user identifier and the token discussed above.
When another user or the same user (a "new user" for purposes of
the monitoring and filtering) log onto the managed device, the
system performs the process of FIGS. 4A and 4B to associate the PAC
file of the "new" user with a tracking number and performs the
brokering. In this manner, the content monitoring and filtering
system handles when a user logs out of a managed device and
prevents, for example, a teacher's content profile that is more
liberal than student's content profile, from being used by a
student who subsequently logs into the managed device. The above
process also handles a situation of a shared managed device wherein
the different users may have a different content filtering profile
since the logging out of each user nullifies the content policy of
that user. The above process also handles the situation in which a
nefarious user is trying to circumvent the content filtering system
by deleting the cookies stored in the browser of the managed device
since the deletion of the cookies causes the process of FIGS. 4A
and 4B to be executed as if the user is logging into the managed
device for the first time.
[0031] The PAC file for a user and managed device and its
association to the tracking number may also be used for internal IP
address fusing/tracking. In particular, different PAC's on the same
client 1P can be fused together for the purpose of applying policy
data using their "Internal IP" that is the private IP the device is
registered under on the entity managed network that is normally
invisible to cloud providers. This IP address tracking/fusing
allows the above described system to execute on content policy
using that internal IP like a physical appliance is able to do, but
without the limitations and drawbacks of the physical appliance. In
more detail, the PAC file may be tracked for an app executing on
the managed device. Although the app has no login that would
normally allow the content monitoring and filtering, the user still
logs into the browser so that the system can monitor and filter
content for the apps as described above.
[0032] In addition to the monitoring and filtering activities
described above carried out using the smart PAC file and the
universally unique identifier for the user and managed device, the
smart PAC file and the system may also be used to provide a pause
feature and/or a time scheduling feature. The pause feature may
enable the internet (access to a network outside of the entity
network) to be remotely paused and then resumed for any particular
managed device at any particular time. The pause feature may be
implemented by the web server sending a pause instruction to the
smart PAC of a particular managed device or one or more managed
devices. The instruction may be send using an RPC as described
above. In one implementation, the pause instruction may result in
access being denied to all outside resources. At the end of the
pausing of the Internet (whenever that may be), the web server may
send a normal operation (or stop pause) command using the same
processes described above and the filtering policy associated with
the universally unique identifier for the managed device will be
used again to monitor and filter the content.
[0033] The time scheduling feature may allow for time scheduled
monitoring and filtering of content for all web sites (or a
particular web site) for a managed device instead of the static
monitoring and filtering that operates at all times. For example, a
time schedule may be created for a managed device being used by a
particular user, such as a student, and a user of the system, such
as a parent or the school or whomever has authority to set
permissions for the user of the managed device. That user can
create or change the allow/deny monitoring and filtering rules
(that are part of the monitoring and filtering process) based on a
time schedule for the managed device so that the monitoring and
filtering may be performed on a time schedule. The system may allow
the user to change/create the monitoring and filtering rules on the
fly. For example, for a student at a school, the monitoring and
filtering rules may be different at different times of the day,
such as homework time in which access may be denied to all
non-educational sites, bed time in which all access is denied and a
fun/gaming time when the student is allowed to access certain
sites. This time schedule feature can be implemented similar to the
pause feature and the web server may communicate instructions about
the time schedule and the monitoring and filtering rules during
each time period to the smart PAC that can implement those
changes.
[0034] The foregoing description, for purpose of explanation, has
been described with reference to specific embodiments. However, the
illustrative discussions above are not intended to be exhaustive or
to limit the disclosure to the precise forms disclosed. Many
modifications and variations are possible in view of the above
teachings. The embodiments were chosen and described in order to
best explain the principles of the disclosure and its practical
applications, to thereby enable others skilled in the art to best
utilize the disclosure and various embodiments with various
modifications as are suited to the particular use contemplated.
[0035] The system and method disclosed herein may be implemented
via one or more components, systems, servers, appliances, other
subcomponents, or distributed between such elements. When
implemented as a system, such systems may include an/or involve,
inter alia, components such as software modules, general-purpose
CPU, RAM, etc. found in general-purpose computers. In
implementations where the innovations reside on a server, such a
server may include or involve components such as CPU, RAM, etc.,
such as those found in general-purpose computers.
[0036] Additionally, the system and method herein may be achieved
via implementations with disparate or entirely different software,
hardware and/or firmware components, beyond that set forth above.
With regard to such other components (e.g., software, processing
components, etc.) and/or computer-readable media associated with or
embodying the present inventions, for example, aspects of the
innovations herein may be implemented consistent with numerous
general purpose or special purpose computing systems or
configurations. Various exemplary computing systems, environments,
and/or configurations that may be suitable for use with the
innovations herein may include, but are not limited to: software or
other components within or embodied on personal computers, servers
or server computing devices such as routing/connectivity
components, hand-held or laptop devices, multiprocessor systems,
microprocessor-based systems, set top boxes, consumer electronic
devices, network PCs, other existing computer platforms,
distributed computing environments that include one or more of the
above systems or devices, etc.
[0037] In some instances, aspects of the system and method may be
achieved via or performed by logic and/or logic instructions
including program modules, executed in association with such
components or circuitry, for example. In general, program modules
may include routines, programs, objects, components, data
structures, etc. that perform particular tasks or implement
particular instructions herein. The inventions may also be
practiced in the context of distributed software, computer, or
circuit settings where circuitry is connected via communication
buses, circuitry or links. In distributed settings,
control/instructions may occur from both local and remote computer
storage media including memory storage devices.
[0038] The software, circuitry and components herein may also
include and/or utilize one or more type of computer readable media.
Computer readable media can be any available media that is resident
on, associable with, or can be accessed by such circuits and/or
computing components. By way of example, and not limitation,
computer readable media may comprise computer storage media and
communication media. Computer storage media includes volatile and
nonvolatile, removable and non-removable media implemented in any
method or technology for storage of information such as computer
readable instructions, data structures, program modules or other
data. Computer storage media includes, but is not limited to, RAM,
ROM, EEPROM, flash memory or other memory technology, CD-ROM,
digital versatile disks (DVD) or other optical storage, magnetic
tape, magnetic disk storage or other magnetic storage devices, or
any other medium which can be used to store the desired information
and can accessed by computing component Communication media may
comprise computer readable instructions, data structures, program
modules and/or other components. Further, communication media may
include wired media such as a wired network or direct-wired
connection, however no media of any such type herein includes
transitory media. Combinations of the any of the above are also
included within the scope of computer readable media.
[0039] In the present description, the terms component, module,
device, etc. may refer to any type of logical or functional
software elements, circuits, blocks and/or processes that may be
implemented in a variety of ways. For example, the functions of
various circuits and/or blocks can be combined with one another
into any other number of modules. Each module may even be
implemented as a software program stored on a tangible memory
(e.g., random access memory, read only memory, CD-ROM memory, hard
disk drive, etc.) to be read by a central processing unit to
implement the functions of the innovations herein. Or, the modules
can comprise programming instructions transmitted to a general
purpose computer or to processing/graphics hardware via a
transmission carrier wave. Also, the modules can be implemented as
hardware logic circuitry implementing the functions encompassed by
the innovations herein. Finally, the modules can be implemented
using special purpose instructions (SIMD instructions), field
programmable logic arrays or any mix thereof which provides the
desired level performance and cost.
[0040] As disclosed herein, features consistent with the disclosure
may be implemented via computer-hardware, software and/or firmware.
For example, the systems and methods disclosed herein may be
embodied in various forms including, for example, a data processor,
such as a computer that also includes a database, digital
electronic circuitry, firmware, software, or in combinations of
them. Further, while some of the disclosed implementations describe
specific hardware components, systems and methods consistent with
the innovations herein may be implemented with any combination of
hardware, software and/or firmware. Moreover, the above-noted
features and other aspects and principles of the innovations herein
may be implemented in various environments. Such environments and
related applications may be specially constructed for performing
the various routines, processes and/or operations according to the
invention or they may include a general-purpose computer or
computing platform selectively activated or reconfigured by code to
provide the necessary functionality. The processes disclosed herein
are not inherently related to any particular computer, network,
architecture, environment, or other apparatus, and may be
implemented by a suitable combination of hardware, software, and/or
firmware. For example, various general-purpose machines may be used
with programs written in accordance with teachings of the
invention, or it may be more convenient to construct a specialized
apparatus or system to perform the required methods and
techniques.
[0041] Aspects of the method and system described herein, such as
the logic, may also be implemented as functionality programmed into
any of a variety of circuitry, including programmable logic devices
("PLDs"), such as field programmable gate arrays ("FPGAs"),
programmable array logic ("PAL") devices, electrically programmable
logic and memory devices and standard cell-based devices, as well
as application specific integrated circuits. Some other
possibilities for implementing aspects include: memory devices,
microcontrollers with memory (such as EEPROM), embedded
microprocessors, firmware, software, etc. Furthermore, aspects may
be embodied in microprocessors having software-based circuit
emulation, discrete logic (sequential and combinatorial), custom
devices, fuzzy (neural) logic, quantum devices, and hybrids of any
of the above device types. The underlying device technologies may
be provided in a variety of component types, e.g., metal-oxide
semiconductor field-effect transistor ("MOSFET") technologies like
complementary metal-oxide semiconductor ("CMOS"), bipolar
technologies like emitter-coupled logic ("ECL"), polymer
technologies (e.g., silicon-conjugated polymer and metal-conjugated
polymer-metal structures), mixed analog and digital, and so on.
[0042] It should also be noted that the various logic and/or
functions disclosed herein may be enabled using any number of
combinations of hardware, firmware, and/or as data and/or
instructions embodied in various machine-readable or
computer-readable media, in terms of their behavioral, register
transfer, logic component, and/or other characteristics.
Computer-readable media in which such formatted data and/or
instructions may be embodied include, but are not limited to,
non-volatile storage media in various forms (e.g., optical,
magnetic or semiconductor storage media) though again does not
include transitory media. Unless the context clearly requires
otherwise, throughout the description, the words "comprise,"
"comprising," and the like are to be construed in an inclusive
sense as opposed to an exclusive or exhaustive sense; that is to
say, in a sense of "including, but not limited to." Words using the
singular or plural number also include the plural or singular
number respectively. Additionally, the words "herein," "hereunder,"
"above," "below," and words of similar import refer to this
application as a whole and not to any particular portions of this
application. When the word "or" is used in reference to a list of
two or more items, that word covers all of the following
interpretations of the word: any of the items in the list, all of
the items in the list and any combination of the items in the
list.
[0043] Although certain presently preferred implementations of the
invention have been specifically described herein, it will be
apparent to those skilled in the art to which the invention
pertains that variations and modifications of the various
implementations shown and described herein may be made without
departing from the spirit and scope of the invention. Accordingly,
it is intended that the invention be limited only to the extent
required by the applicable rules of law.
[0044] While the foregoing has been with reference to a particular
embodiment of the disclosure, it will be appreciated by those
skilled in the art that changes in this embodiment may be made
without departing from the principles and spirit of the disclosure,
the scope of which is defined by the appended claims.
* * * * *
References