U.S. patent application number 15/343007 was filed with the patent office on 2017-05-04 for automated geo-target and geo-hazard notifications for drilling systems.
This patent application is currently assigned to Ubiterra Corporation. The applicant listed for this patent is Ubiterra Corporation. Invention is credited to Peter W. Flanagan.
Application Number | 20170122095 15/343007 |
Document ID | / |
Family ID | 58635381 |
Filed Date | 2017-05-04 |
United States Patent
Application |
20170122095 |
Kind Code |
A1 |
Flanagan; Peter W. |
May 4, 2017 |
AUTOMATED GEO-TARGET AND GEO-HAZARD NOTIFICATIONS FOR DRILLING
SYSTEMS
Abstract
A drilling management system can monitor the traversed path of a
drill bit throughout active drilling at a drilling site and notify
appropriate team members regarding a current status of the active
drilling in real-time. For example, the drilling management system
can notify team members when predetermined milestones have been
met, when the drill bit is drifting off course from a target
wellbore trajectory from a target horizon or target zone, or when
the drill bit is in danger of running into a geo-hazard, such as a
pre-existing wellbore, unpierced fault plane, lease boundary, etc.
The drilling management system can maintain a depth model of the
drilling site that identifies the target wellbore trajectory, a
target zone based on one or more horizons from the depth model, and
coordinates of known geo-hazards at the drilling sites. The
drilling management system can also maintain a set of rules for
each of the drilling sites that indicates when team members should
be notified.
Inventors: |
Flanagan; Peter W.; (Denver,
CO) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Ubiterra Corporation |
Denver |
CO |
US |
|
|
Assignee: |
Ubiterra Corporation
Denver
CO
|
Family ID: |
58635381 |
Appl. No.: |
15/343007 |
Filed: |
November 3, 2016 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
62250256 |
Nov 3, 2015 |
|
|
|
62376256 |
Aug 17, 2016 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
E21B 47/09 20130101;
E21B 47/024 20130101; E21B 44/00 20130101; E21B 47/04 20130101;
E21B 2200/22 20200501 |
International
Class: |
E21B 47/024 20060101
E21B047/024; E21B 47/09 20060101 E21B047/09 |
Claims
1. A method comprising: receiving, by a drilling management device,
a first drilling data stream, the first drilling data stream
including coordinate data describing a traversed path of a drill
bit while drilling a well at a first drilling site; determining,
based on the coordinate data and a depth model of the first
drilling site, that a first rule has been triggered, wherein the
depth model of the first drilling site identifies a feature
associated with the first rule; and transmitting a notification to
a first user that the first rule has been triggered.
2. The method of claim 1, wherein determining that the first rule
has been triggered comprises: determining, based on the coordinate
data, a current location of the drill bit; determining a distance
between the current location of the drill bit and the feature; and
determining that the distance between the current location of the
drill bit and the feature meets a threshold distance defined by the
first rule.
3. The method of claim 1 wherein the feature is a least one of a
target wellbore and a target horizon.
4. The method of claim 3, wherein determining that the first rule
has been triggered comprises: determining, based on the coordinate
data, a current vector direction of the drill bit; determining, an
angle deviation between the current vector direction of the drill
bit and the target wellbore defined by the depth model; and
determining that the angle deviation between the current vector
direction of the drill bit and the target wellbore meets a
threshold angle deviation dictated by the first rule.
5. The method of claim 1, wherein the feature is a preexisting
wellbore, and determining that the first rule has been triggered
comprises: determining, based on the coordinate data, a current
location of the drill; determining, a distance between the current
location of the drill and the preexisting wellbore defined by the
depth model; and determining that the distance between the current
location of the drill and the preexisting wellbore meets a
threshold distance dictated by the first rule.
6. The method of claim 1, wherein the feature is an unpierced fault
plane, and determining that the first rule has been triggered
comprises: determining, based on the coordinate data, a current
location of the drill; determining, a distance between the current
location of the drill to the unpierced fault plane defined by the
depth model; and determining that the distance between the current
location of the drill and the unpierced fault plane meets a
threshold distance dictated by the first rule.
7. The method of claim 1, wherein the feature is a lease boundary,
and determining that the first rule has been triggered comprises:
determining, based on the coordinate data, a current location of
the drill; determining, a distance between the current location of
the drill to the lease boundary defined by the depth model; and
determining that the distance between the current location of the
drill and the lease boundary meets or is less than a minimum
threshold distance dictated by the first rule.
8. The method of claim 1, wherein determining that the first rule
has been triggered comprises: determining, based on the traversed
path of the drill, that a drilling milestone has been met.
9. The method of claim 1 wherein the coordinate data includes an X
axis value, a Y axis value and a Z axis value of the drill, the Z
axis value indicating a depth of the drill.
10. The method of claim 1, wherein the feature is a target zone
based on a first horizon and a second horizon in the depth model,
and determining that the first rule has been triggered comprises:
determining, based on the coordinate data, a current location of
the drill bit; determining, a distance between the current location
of the drill bit to the first horizon or the second horizon; and
determining that the distance between the current location of the
drill and the first horizon or the second horizon meets a threshold
distance dictated by the first rule.
11. The method of claim 1, wherein the feature is a target horizon
and the method further comprising generating a target zone defining
at least one surface a distance from the target horizon, and
determining that the first rule has been triggered comprises:
determining, based on the coordinate data, a current location of
the drill; determining, a distance between the current location of
the drill to the at least one surface; and determining that the
distance between the current location of the drill and the at least
one surface meets at least a first threshold distance dictated by
the first rule.
12. A drilling management system comprising: one or more computer
processors; and memory storing instructions that, when executed by
the one or more computer processors, cause the one or more
processors to: determine, based on coordinate data from a first
drilling data stream describing a traversed path of a drill bit
while drilling a well at a first drilling site and a depth model of
the first drilling site, that a first rule has been triggered,
wherein the depth model of the first drilling site identifies a
feature; transmit a notification to a device associated with a
first user that the first rule has been triggered.
13. The drilling management system of claim 12, wherein the feature
is a target wellbore trajectory, and wherein to determine that the
first rule has been triggered comprises: determine, based on the
coordinate data, a current location of the drill bit; determine a
distance between the current location of the drill bit and the
target wellbore trajectory; and determine that the distance between
the current location of the drill bit and the target wellbore
trajectory meets at least a first threshold distance dictated by
the first rule.
14. The drilling management system of claim 12, wherein the feature
is a target wellbore trajectory, and to determine that the first
rule has been triggered comprises: determine, based on the
coordinate data, a current vector direction of the drill bit;
determine, an angle deviation between the current vector direction
of the drill bit and the target wellbore trajectory defined by the
depth model; and determine that the angle deviation between the
current vector direction of the drill bit and the target wellbore
trajectory meets or exceeds a threshold angle deviation dictated by
the first rule.
15. The drilling management system of claim 12, wherein the feature
is a preexisting wellbore, and to determine that the first rule has
been triggered comprises: determine, based on the coordinate data,
a current location of the drill; determine, a distance between the
current location of the drill and the preexisting wellbore defined
by the depth model; and determine that the distance between the
current location of the drill and the preexisting wellbore meets or
is less than a minimum threshold distance dictated by the first
rule.
16. The drilling management system of claim 12 wherein the feature
is an unpierced fault plane, and to determine that the first rule
has been triggered comprises: determine, based on the coordinate
data, a current location of the drill; determine, a distance
between the current location of the drill to the unpierced fault
plane defined by the depth model; and determine that the distance
between the current location of the drill and the unpierced fault
plane meets a threshold distance dictated by the first rule.
17. The drilling management system of claim 12, wherein the feature
is a lease boundary, and to determine that the first rule has been
triggered comprises: determine, based on the coordinate data, a
current location of the drill; determine, a distance between the
current location of the drill to the lease boundary defined by the
depth model; and determine that the distance between the current
location of the drill and the lease boundary meets or is less than
a minimum threshold distance dictated by the first rule.
18. The drilling management system of claim 12, wherein to
determine that the first rule has been triggered comprises:
determine, based on the traversed path of the drill, that a
drilling milestone has been met.
19. The drilling management system of claim 12, wherein the
coordinate data includes an X axis value, a Y axis value and a Z
axis value of the drill, the Z axis value indicating a depth of the
drill.
20. The drilling management system of claim 12, wherein the feature
is a target zone with a first horizon and a second horizon, and to
determine that the first rule has been triggered comprises:
determine, based on the coordinate data, a current location of the
drill; determine, a distance between the current location of the
drill to the first horizon or the second horizon; and determine
that the distance between the current location of the drill and the
first horizon or the second horizon meets a threshold distance
dictated by the first rule.
21. The drilling management system of claim 12, wherein the feature
is a target horizon and the one or more processors further generate
a target zone defining at least one surface a distance from the
target horizon, and to determine that the first rule has been
triggered comprises: determine, based on the coordinate data, a
current location of the drill; determine, a distance between the
current location of the drill to the at least one surface; and
determine that the distance between the current location of the
drill and the at least one surface meets at least a first threshold
distance dictated by the first rule.
22. The drilling management system of claim 12, wherein the feature
is at least of a target horizon or a target wellbore, and
determining that the first rule has been triggered comprises:
determining, based on the coordinate data, a current location of
the drill; determining, a distance between the current location of
the drill to the target wellbore or the target horizon; and
determining that the distance between the current location of the
drill and the target wellbore or the target horizon meets a
threshold distance dictated by the first rule.
23. A non-transitory computer-readable medium storing instructions
that, when executed by a computing device, cause the computing
device to: receive a first drilling data stream, the first drilling
data stream including coordinate data describing a traversed path
of a drill bit while drilling a well at a first drilling site;
determine, based on the coordinate data and a depth model of the
first drilling site, that a first rule has been triggered, wherein
the depth model of the first drilling site identifies a feature;
identify at least a first user that should be identified when the
first rule has been triggered; and transmit a notification to the
first user that the first rule has been triggered.
24. The non-transitory computer-readable medium of claim 23,
wherein the feature is a target wellbore and, determining that the
first rule has been triggered comprises: determine, based on the
coordinate data, a current location of the drill bit; determine a
distance between the current location of the drill bit and the
target wellbore; and determine that the distance between the
current location of the drill bit and the target wellbore meets a
threshold distance dictated by the first rule.
25. The non-transitory computer-readable medium of claim 23,
wherein the feature is a target wellbore trajectory, and to
determine that the first rule has been triggered comprises:
determine, based on the coordinate data, a current vector direction
of the drill bit; determine, an angle deviation between the current
vector direction of the drill bit and the target wellbore
trajectory defined by the depth model; and determine that the angle
deviation between the current vector direction of the drill bit and
the target wellbore trajectory meets or exceeds a threshold angle
deviation dictated by the first rule.
26. The non-transitory computer-readable medium of claim 23, where
the feature is a preexisting wellbore, and wherein determining that
the first rule has been triggered comprises: determine, based on
the coordinate data, a current location of the drill; determine, a
distance between the current location of the drill and the
preexisting wellbore defined by the depth model; and determine that
the distance between the current location of the drill and the
preexisting wellbore meets or is less than a minimum threshold
distance dictated by the first rule.
27. The non-transitory computer-readable medium of claim 23,
wherein the feature is an unpierced fault plane, and determining
that the first rule has been triggered comprises: determine, based
on the coordinate data, a current location of the drill; determine,
a distance between the current location of the drill to the
unpierced fault plane defined by the depth model; and determine
that the distance between the current location of the drill and the
unpierced fault plane meets or is a threshold distance dictated by
the first rule.
28. The non-transitory computer-readable medium of claim 23,
wherein the feature is a lease boundary, and determining that the
first rule has been triggered comprises: determine, based on the
coordinate data, a current location of the drill; determine, a
distance between the current location of the drill to the lease
boundary defined by the depth model; and determine that the
distance between the current location of the drill and the lease
boundary meets a threshold distance dictated by the first rule.
29. The non-transitory computer-readable medium of claim 23,
wherein determining that the first rule has been triggered
comprises: determine, based on the traversed path of the drill,
that a drilling milestone has been met.
30. The non-transitory computer-readable medium of claim 23,
wherein the coordinate data includes an X axis value, a Y axis
value and a Z axis value of the drill, the Z axis value indicating
a depth of the drill.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] The present application claims priority under 35 U.S.C.
.sctn.119(e) to provisional application No. 62/250,256 titled
"Shared Visualization with Automated Depth Model Based
Notifications for Drilling Systems Utilizing 3D Seismic Data,"
filed on Nov. 3, 2015, and claims priority under 35 U.S.C.
.sctn.119(e) to provisional application No. 62/376,256 titled
"Automated Geo-Target and Geo-Hazard Notifications for Drilling
Systems," filed on Aug. 17, 2016, which are hereby incorporated by
reference herein.
TECHNICAL FIELD
[0002] The present technology pertains to drilling systems, and
more specifically pertains to automated geo-target and geo-hazard
notifications for drilling systems.
BACKGROUND
[0003] An oil company asset team must work to together to ensure
the efficient drilling and completion of an oil and gas well.
During the years 2005 through 2016, the drilling of horizontal
wells in shale formations became a very important new regime of
operations for the oil industry. This new regime requires a
"factory floor" mindset whereby activities become repetitive and
must be repeatable in order to ensure optimal outcomes from an
economic perspective.
[0004] In order to drill a successful horizontal well, a
cross-functional team (a.k.a. "asset team") comprised of engineers,
geoscientists, regulatory, financial specialists, managers, and
third party service providers, such as the drilling contractor and
mud-logger, must work together. The asset team must collaborate to
plan the well, execute the drilling plan, avoid geo-hazards, and
stay on an optimal drilling track and on the drilling plan. This is
challenging since the drilling target geologic horizon will
typically be 2 miles underground and located in a remote field
area.
[0005] An increasingly important tool for improving the success of
these horizontal shale drilling projects is 3-dimensional seismic
data (3D seismic). Many oil and gas companies will acquire a 3D
seismic survey that is an image of the subsurface region within
which they intend to drill. This seismic survey will be calibrated
to existing well control and converted into depth (meaning the
z-axis of the seismic volume will readout in depth below the
surface). The target horizon (and potentially additional reference
horizons) along which the horizontal well will be drilled is
identified within the seismic volume, along with potential hazards,
which primarily will be geologic faults that intersect the target
horizon, but which will also include preexisting wellbores within
the vicinity. In addition, mineral lease ownership information
could be included in the depth model. Also, the depth model
typically includes a planned drilling wellbore trajectory. This
information is collectively referred to as the "Depth Model."
[0006] As the drilling of the well proceeds, the location of the
drill bit using measurement while drilling (MWD) information can be
transmitted on a periodic (15 minute or other interval), real-time
basis to the oil company. Not uncommonly, an asset team member
(typically a geoscientist) will be assigned to manually update a
set of project information on an at least a once daily basis and
generate a report--the project contains the seismic volume, the
depth model including geo-hazards, and the path of the well being
drilled. This report is then distributed manually to the other
asset team members to help the asset team work together.
Regardless, the process is labor intensive, not typically
real-time, the information is difficult to distribute and
coordinate particularly from remote locations where team members
are remote from the drilling operations, among numerous other
challenges and deficiencies.
SUMMARY
[0007] Additional features and advantages of the disclosure will be
set forth in the description which follows, and in part will be
obvious from the description, or can be learned by practice of the
herein disclosed principles. The features and advantages of the
disclosure can be realized and obtained by means of the instruments
and combinations particularly pointed out in the appended claims.
These and other features of the disclosure will become more fully
apparent from the following description and appended claims, or can
be learned by the practice of the principles set forth herein.
[0008] Disclosed are systems, methods, and non-transitory
computer-readable storage media for automated geo-target and
geo-hazard notifications for drilling systems. A drilling
management system can monitor the traversed path of a drill bit
throughout active drilling at a drilling site and notify
appropriate team members regarding a current status of the active
drilling in real-time. For example, the drilling management system
can notify team members when predetermined milestones have been
met, when the drill bit is drifting off course from a target
wellbore trajectory or target horizon, or deviating from a zone
when the drill bit is in danger of running into a geo-hazard, such
as a pre-existing wellbore, unpierced fault plane, lease boundary,
etc. The drilling management system can maintain a depth model of
the drilling site that identifies the target wellbore trajectory
and coordinates of known geo-hazards at the drilling sites. The
drilling management system can also maintain a set of rules for
each of the drilling sites that indicates when team members should
be notified.
[0009] While an active drilling is in progress at a drilling site,
the drilling management system can receive a drilling data stream
from the drilling site that includes coordinate data describing a
traversed path of a drill bit. The drilling management system can
determine, based on the coordinate data and the depth model of the
drilling site, whether a rule has been triggered indicating that
one or more team members should be notified regarding the status of
the active drilling. In response to determining that the rule has
been triggered, the drilling management system can identify a set
of team members that should be notified, and transmit a
notification to the team members that the rule has been
triggered.
BRIEF DESCRIPTION OF THE DRAWINGS
[0010] The above-recited and other advantages and features of the
disclosure will become apparent by reference to specific
embodiments thereof which are illustrated in the appended drawings.
Understanding that these drawings depict only exemplary embodiments
of the disclosure and are not therefore to be considered to be
limiting of its scope, the principles herein are described and
explained with additional specificity and detail through the use of
the accompanying drawings in which:
[0011] FIG. 1 illustrates an exemplary system for automated
geo-target and geo-hazard notifications for drilling systems;
[0012] FIG. 2 illustrates an exemplary system embodiment of a
drilling management system;
[0013] FIG. 3 illustrates an example method of automated geo-target
and geo-hazard notifications for drilling systems; and
[0014] FIGS. 4A-4D illustrate exemplary visualizations of an active
drill; and
[0015] FIGS. 5A and 5B illustrate exemplary possible system
embodiments.
DESCRIPTION
[0016] Various embodiments of the disclosure are discussed in
detail below. While specific implementations are discussed, it
should be understood that this is done for illustration purposes
only. A person skilled in the relevant art will recognize that
other components and configurations may be used without parting
from the spirit and scope of the disclosure.
[0017] The disclosed technology addresses the need in the art for
automated geo-target and geo-hazard notifications for drilling
systems. A drilling management system can monitor the traversed
path of a drill bit throughout active drilling at a drilling site
and notify appropriate team members regarding a status of active
drilling, and the current status may be configured to be monitored
in real-time. As used herein, the term real-time recognizes that
there are various steps and operations that occur prior to the
system receiving information about the location of the drill bit
and progression of the wellbore, and the system may be configured
to monitor the system based on the most current drill bit
information and may be configured to provide notifications on some
schedule. For example, some time may pass between transmission of
drill bit information from the well to the system and hence the
term real-time recognizes some time may pass between when the drill
bit reaches some location and when the system obtains the
information as to the current location of the drill bit, and hence
the term real-time captures near real-time values (e.g., while
drilling and within 10 minutes of the drill bit reaching some point
in the drilling operation). With respect to notification, for
example, the drilling management system can notify team members
when predetermined milestones have been met, when the drill bit is
drifting off course from a target wellbore trajectory and/or target
horizon, or when the drill bit is in danger of running into a
geo-hazard, such as a pre-existing wellbore, unpierced fault plane,
lease boundary, etc. The drilling management system can maintain a
depth model of the drilling site that identifies the target
wellbore trajectory and coordinates of known geo-hazards at the
drilling sites. The drilling management system can also maintain a
set of rules for each of the drilling sites that indicate when team
members should be notified. The information may be processed and
notifications transmitted in real-time.
[0018] While an active drill is in progress at a drilling site, the
drilling management system can receive a drilling data stream
(e.g., a stream of data generated from MWD data captured from an
MWD tool) from the drilling site that includes coordinate data
describing a traversed path of a drill bit. The drilling management
system can determine, based on the coordinate data and the depth
model of the drilling site, whether a rule has been triggered
indicating that one or more team members should be notified
regarding the status of the active drill. In response to
determining that the rule has been triggered, the drilling
management system can identify a set of team members that should be
notified, and transmit a notification to the team members that the
rule has been triggered.
[0019] FIG. 1 illustrates an exemplary system for automated
geo-target and geo-hazard notifications for drilling systems. As
illustrated, multiple computing devices can be connected to a
communication network 104 and be configured to communicate with
each other through use of the communication network 104. The
communication network 104 can be any type of network, including a
local area network ("LAN"), such as an intranet, a wide area
network ("WAN"), such as the Internet, or any combination thereof.
Further, the communication network 104 can be a public network, a
private network, or a combination thereof. The communication
network 104 can also be implemented using any number of
communication links associated with one or more service providers,
including one or more wired communication links, one or more
wireless communication links, or any combination thereof, and may
support the transmission of data formatted using any number of
protocols, as well as different protocols as data traverses the
various paths between devices.
[0020] A computing device, which may be involved in obtaining and
transmitting drilling information, the drilling management system,
and the client devices, can be any type of general computing device
capable of network communication with other computing devices. For
example, a computing device can be a personal computing device such
as a desktop or workstation, a business server, or a portable
computing device, such as a laptop, smart phone, or a tablet PC. A
computing device can include some or all of the features,
components, and peripherals of computing device 500 of FIGS. 5A and
5B.
[0021] To facilitate communication with other computing devices, a
computing device can also include a communication interface
configured to receive a communication, such as a request, data,
etc., from another computing device in network communication with
the computing device and pass the communication along to an
appropriate module running on the computing device. The
communication interface can also be configured to send a
communication to another computing device in network communication
with the computing device.
[0022] As shown, the overall system 100 includes a drilling
management system 102, drilling sites 106.sub.1, 106.sub.2, . . . ,
106.sub.n (collectively "106"), and more particularly computing
devices at the sites, and client devices 108.sub.1, 108.sub.2, . .
. , 108.sub.n (collectively "108"). The drilling management system
102 can be comprised of one or more computing devices configured to
monitor the traversed path of a drill bit throughout active
drilling at any drilling sites 106, through receiving drilling
information, and communicate with various client devices 108 to
notify associated team members regarding the status of active
drilling at the drilling sites 106 in real-time.
[0023] The drilling sites 106 can be physical drilling sites
equipped with drilling machinery, and accompanying sensors and
computing devices, such as an MWD component associated with a drill
bit, configured to gather drilling data describing the status of an
active drilling operation at a drilling site 106. For example, the
drilling data, in the form of MWD data, may be delivered in the
form of sets of Azimuth (inclination from North), Inclination (dip
in degrees), and MD (measured length along wellbore). The data may
be converted to X, Y, Z axis values using any industry standard
conversion. The conversion may occur prior to the drilling data
being transmitted (e.g., the drilling stream) to the drilling
management system. Hence, the drilling data can include coordinate
data, such as an X axis value, Y axis value and Z axis value,
describing the location of a drill bit as the drill traverses
through the ground during the active drill. Systems at the drilling
sites 106 can gather and transmit this drilling data to drilling
management system 102 as part of a drilling data stream. For
example, drilling sites 106 can gather and transmit drilling data
to drilling management system 102 every 10 seconds, 30 second, 1
minute, 5 minutes, etc. In one specific example, MWD drill bit
positional data is collected by an MWD tool associated with the
drill string and typically positioned behind the drill bit. As
introduced above, the MWD tool measures azimuth, inclination, and
length along the well drilling string in real-time. The tool
transmits the data to the surface using "mud pulses"--digital
pulses sent through drilling fluid, in the wellbore, to the surface
where the pulses are encoded with positional data as well as other
information. A transducer at the surface converts these pulses back
into digital information on a network on the drilling rig. The MWD
data may be then be translated to X,Y,Z values at a local computing
device and transmitted, such as form a private web server at the
drilling site, to the drilling management system using the WITSML
protocol.
[0024] In addition to coordinate data describing the location of a
drill bit, drilling data can also include additional data
describing an active drill. For example, the drilling data can
include identifying data, such as a unique identifier identifying
the originating drilling site 106, identifiers of equipment used
for drilling, such as the drill bit, sensors, computing devices,
etc. The drilling data can also include time stamp values
indicating the time at which coordinate values for an active drill
were recorded. Drilling data can also include other sensor readings
or data gathered during the active drill, such as sensor readings
describing traversed soil densities, drill bit pressures, drill bit
performance, etc. The drilling data may also include logging while
drilling (LWD) data including gamma ray log information. The log
records the intensity of naturally occurring gamma radiation from
rock.
[0025] The drilling management system 102 can receive drilling data
streams from one or more of the drilling sites 106 and analyze the
drilling data to determine whether team members associated with the
active drill should be notified regarding the status of the active
drill. For example, the drilling management system 102 can notify
team members when predetermined milestones have been met, when the
drill bit is drifting off course from a target wellbore trajectory
or when the drill bit is in danger of running into a geo-hazard,
such as a pre-existing wellbore, unpierced fault plane, lease
boundary, etc.
[0026] To accomplish this, the drilling management system 102 can
access a depth model for the area being drilled at each drilling
site 106. The depth model may identify the target wellbore
trajectory for the drilling site 106, coordinates of known
geo-hazards, target horizons, and other features. Generally
speaking, the depth model is derived from the seismic data for the
area to be drilled at the drilling site. Typically, seismic
interpretation programs are used to digitize X, Y, Z coordinate
data for a set of seismic data. The digitized coordinates may
further represent and constitute 3D dimensional surfaces associated
with the seismic data. Likewise, features identified within the
seismic data may be digitized into unique three dimensional
surfaces to form part of the depth model. For example, geologic
faults, hazards, target horizons or boundaries and the like may be
digitized into three dimensional surfaces representative of the
respective features.
[0027] Each data type (the seismic data and the derived horizon and
fault surfaces) and the well data (the MWD and LWD information) has
its own elevation datum). To align the various data sets used for
comparison purposes and to trigger notifications, and the like, the
elevation datum may be reconciled if necessary. For example, if the
seismic data used to generate the seismic cube has a datum
elevation of 5200 ft above sea level, and the drilling data has a
datum elevation of 5250 feet above sea level, the depths between
the two sets of data can be reconciled by adding 50 ft to the
seismic data. The depth model may be based on seismic data for the
area being drilled, and may be arranged in a cube with x (e.g.,
inline), y (e.g., crossline) and/or z (e.g., time or depth) aspects
of the cube.
[0028] The drilling management system 102 can also maintain a set
of rules for each drilling site 106 that indicates when team
members for the drilling site 106 should be notified regarding the
status of the active drill. For example, the rules can identify
milestones that, when met, should be reported to specified team
members. As another example, the rules can identify threshold
distances from the target wellbore trajectory, the target horizons,
and/or geo-hazards that, when met or exceeded, are reported to a
specified team member or members. The drilling management system
102 can use the drilling data received from a drilling site 106,
along with the corresponding depth model and set of rules, to
determine when a rule has been triggered and team members should be
notified regarding the status of the active drilling operation.
[0029] The drilling management system 102 can notify team members
via client devices 108. Client devices 108 can be any type of
computing devices, such as a smart phones, laptop computers,
desktop computers, tablets, etc. Drilling management system 102 can
maintain records of client devices 108 associated with team
members, including contact information to reach team members via
one or more of client devices 108. In response to determining that
a team member should be notified, drilling management system 102
can identify the team members contact information and transmit a
notification to the user, which can be received by the user at one
or more of client devices 108. For example, drilling management
system 102 can transmit the notification as an e-mail, text
message, phone call, instant message, etc.
[0030] Drilling management system 102 can also provide team members
with a visualization of an active drill. For example, drilling
management system 102 may use techniques such as those described in
U.S. Pat. No. 9,182,913 titled "Apparatus, System an Method for the
Efficient Storage and Retrieval of 3-Dimesionally Organized Data in
Cloud Based Computing Architectures," which is hereby incorporated
by reference, to among other things, store, access, and view 3D
seismic data and depth models within a cloud architecture utilizing
a web browser or other client side application. The method
disclosed in the '913 patent also provides for the efficient access
to the depth model over network connections.
[0031] Team members can use client devices 108 to communicate with
drilling management system 102 to request a visualization of an
active drill. In response, drilling management system 102 can
transmit visualization data to the team member's client device 108.
The visualization data can be rendered by client device 108, for
example in a web browser or other client-side application, to
present the user with a visualization of an active drill. This can
include a 2 or 3 dimensional rendering of the drilling site
including a visual representation of the traversed path of the
drill bit, the target wellbore trajectory, target horizon, and
geo-hazard, such as a pre-existing wellbores, unpierced fault
planes, lease boundaries, etc.
[0032] FIG. 2 illustrates an exemplary system embodiment of a
drilling management system 102. FIG. 2 is described in view of the
system and components described in FIG. 1. As shown, the drilling
management system 102 includes a data stream receiving module 202,
a rule analysis module 204, a notification module 206, a data
visualization module 208, a data stream storage 210, a depth model
storage 212 and a rules storage 214. The various modules may
involve a processor (or processors) and computer executable
instructions to receive the data stream, apply one or more rules to
the data stream, and provide notifications as needed. The storage
may be provided by one or more tangible readable media, provided as
a database or databases, where data from the data stream is stored,
the depth model is stored, and rules are stored.
[0033] The data stream receiving module 202 receives drilling data
streams from one or more drilling sites 106. A drilling data stream
can include drilling data describing an active drill. In one
possible example, the data stream is accessed from a server or
other computing device at the respective well and may be formatted
according to the Wellsite Information Transfer Standard Markup
Language (WITSML) standard. The data stream may be received at the
drilling management system and/or the data stream storage over the
network 104. The data stream receiving module 202 can receive and
store the received drilling data in the data stream storage 210.
The data stream storage 210 can include a data stream index for one
or more of the drilling sites 106. The drilling index can be a data
index, data file, database, data table, etc., that includes a
listing of drilling data received from a particular drilling site
106. For example, a drilling index can include a listing of
coordinate data describing the location of a drill bit at the
drilling site 106, as well as time stamp data, identifying data,
etc. As a drilling operation procedure, the data stream will
provide updated data as to the progress of the drilling operation
and the current location of the drill bit. Accordingly, the
drilling index for a drilling site 106 can include data documenting
the traversed path of the drill bit at the drilling site 106, as
well as other sensor data and metadata describing drilling at the
drilling site 106.
[0034] Each drilling index can be associated with a unique
identifier identifying the corresponding originating drilling site
106. The data stream receiving module 202 can identify the unique
identifier included in a received drilling data stream to identify
the corresponding drilling index in data stream storage 210 and
record the received drilling data in the identified drilling
index.
[0035] The rule analysis module 204 is configured to analyze
received drilling data to determine whether to notify team members
regarding the status of an active drill. For example, the rule
analysis module 204 can utilize the drilling data along with a
depth model and a set of rules corresponding to a drilling site 106
to determine whether a rule has been triggered and team members
should be notified.
[0036] The depth model storage 212 can store depth models for
drilling sites 106 and rule storage 214 can store sets of rules for
the drilling sites 106--with rules being unique and/or common to
each drilling site. Each depth model and set of rules can be
associated with a unique identifier for its corresponding drilling
site 106. The rule analysis module 204 utilizes the unique
identifier for a drilling site 106 to gather the corresponding
drilling index, depth model and set of rules from data stream
storage 210, depth model storage 212 and rule storage 214,
respectively.
[0037] The rule analysis module 204 can then use the gathered data
to determine whether a rule has been triggered. Moreover, the rule
analysis module 204 can determine whether a rule has been triggered
according to a predetermined temporal schedule, such as every 5
seconds, 10 seconds, 1 minute, etc. The rule analysis module 204
can also determine whether a rule has been triggered as updated
coordinate data (e.g., relative drill bit location data) is
received from a drilling site 106 as part of a drilling data
stream.
[0038] The set of rules for a drilling site 106 can include any
number or type of rules and/or conditions for notifying team
members. For example, a set of rules may include a simple temporal
milestone rule dictating that team members be notified of the
status of an active drill at specified time intervals, such as
every 30 seconds, 1 minute, 5 minutes, etc., or according to a
specified time schedule. In one example, a user interface may be
accessed through a client device 108, where the user interface
provides access to a set of preconfigured rules. The user interface
may include fields to activate any given rule as well as to set
variables for any given rule. The update time, for example, may be
a rule variable set through the user interface. The rule analysis
module 204 can monitor elapsed time during an active drill for each
specified temporal milestone.
[0039] As another example, a set of rules can include a distance
based milestone rule dictating that team members be notified as the
drill bit reaches predetermined distance intervals (a variable
settable through the user interface), such as every 10 feet, 20
feet, 100 feet etc., or according to a specified distance schedule.
The rule analysis module 204 can utilize the location data stored
in the drilling index to determine the current location of a drill
bit as well as the distance traversed by the drill bit during the
active drill and determine whether the rule has been triggered.
[0040] As another example, a set of rules can include a trajectory
deviation rule dictating that team members be notified when the
current location of the drill bit deviates beyond a predetermined
threshold distance from the target wellbore trajectory and/or the
target horizon for the drill bit. Rule analysis module 204 can
utilize the location data stored in the drilling index to determine
the current location of a drill bit and utilize the depth model to
determine the target wellbore trajectory and/or the target horizon.
Rule analysis module 204 can then determine the distance between
the current location of the drill bit and the target wellbore
trajectory and/or target horizon and compare the distance to a
threshold distance to determine whether the rule has been
triggered.
[0041] With respect to comparing the actual drill bit location to
the drilling plan, a distance is computed between a point in
three-dimensional space (the X, Y, Z coordinate for the current
location of the drill bit) and the drilling plan, which may be
represented by a polyline in three dimensional space (series of
points through the 3D space of the depth model). The distance may
be resolved into a z-component and an xy-component, which may be
defined in the depth model or separate therefrom. In that regard,
the system can determine the location of the drill bit relative to
plan and provide any suitable notification--e.g., "at 5:30 p.m.,
the drill bit is 15 feet above the drilling plan, and 10 feet North
of the drilling plan".
[0042] As another example, a set of rules can include a trajectory
deviation rule dictating that team members be notified when an
angle of the drill bit relative to the target horizon exceeds a
threshold angle deviation from the target horizon. Rule analysis
module 204 can utilize the location data stored in the drilling
index to determine a direction (e.g., vector direction) of the
drill bit and use the target horizon from the depth model. Rule
analysis module 204 can then determine an angle deviation of the
drill bit from the target horizon and compare the angle deviation
to the threshold angle deviation to determine whether the rule has
been triggered.
[0043] As another example, a set of rules can include a minimum
distance rule to a geo-hazard, such as a pre-existing wellbore,
unpierced fault plane or lease boundary. Rule analysis module 204
can utilize the location data stored in the drilling index to
determine the current location of a drill bit and utilize the depth
model to determine the location of a geo-hazard. Rule analysis
module 204 can then determine the distance between the current
location of the drill bit and the geo-hazard and compare the
distance to a threshold distance to determine whether the rule has
been triggered. In this example, the computed X, Y, Z position of
the drill bit (current and the previous values, which trace out the
actual wellbore path) are compared to the location of a fault
surface. The fault surface is stored as a triangulated surface in
the same X, Y, Z coordinate system as the coordinates of the path
of the drill bit. Computational geometry is used to compute the
distance between a point in 3D space (e.g., the most recent
position of the drill bit) and a surface in 3D space along a
direction vector (the direction that the drill bit is heading). The
distance is expressed in standard distance units (meters). So, if a
threshold distance has been set for proximity to fault surfaces
(such as 50 meters, which may be a variable), when that distance is
less than or equal to 50, a notification is generated.
[0044] With respect to the intersection of the drill bit with a
geohazard of some sort, the planned wellbore (a polyline in 3D
space) indicates approximately where the wellbore is going to be,
and the actual wellbore indicates the real-time (near real-time
position) of the drill bit and where the drill bit has been. The
path of the drill bit and the current location of the drill, which
collectively represents the wellbore, may be represented as a
three-dimensional polyline starting at the surface where drilling
commences and extending to a point represented by the current
location of the drill bit. In one example, any fault surface that
intersects the planned wellbore may be considered a "geohazard".
For any such fault surface, the system can compute the distance to
the geohazard by computing the distance from the current drill bit
position to the intersection of the planned wellbore with that
fault surface. Furthermore, the system can estimate the time of the
intersection occurring by dividing the distance by the current rate
of penetration of the drilling (expressed by convention as Feet or
Meters per Hour), which may be received by the system with the
drilling information provided by the MWD system.
[0045] Rule analysis module 204 can determined the distance between
the current location of the drill bit and another location based on
geographic coordinates associated with the two points, such as an X
coordinate value, Y coordinate value and Z coordinate value
assigned to drill bit and the other point. In instances where an
object is associated with multiple geographic coordinates, such as
a target wellbore trajectory, lease boundary, pre-existing
wellbore, etc., rule analysis module 204 can determine the shortest
distance between the current location of the drill bit and the
other location.
[0046] In another example, the rule analysis module may compare the
current drill bit position to a target horizon or target horizons.
The rule analysis module may also compare the drill bit to a range
of distances from a target horizon, or may generate a virtual
horizon and compare the location of the drill bit to the virtual
horizon. In one example, the depth model may include at least one
target horizon. The target horizon, may be a surface comprised of
X, Y and Z coordinate data. The target horizon may be associated
with the top surface, bottom surface or some other surface
associated with a formation identified in the seismic data cube
from which the depth model is based. For example, a shale bearing
formation may be identified in a seismic data set, and a target
horizon may be generated and stored for a surface representing the
top surface of the formation.
[0047] Continuing with the example of a shale formation and a
horizon defining a surface in the depth model for the top of the
formation, during drilling, it may be desired to drill a horizontal
well within some distance from the top of the formation. Hence, a
rule may be created to compare the current drill bit position with
a target horizon, and generate some form of notification when the
drill bit deviates some distance, defined in the rule, from the top
of the formation (the target horizon).
[0048] In another example, it is possible to define a second
horizon, such as related to the bottom of the shale formation, and
define a rule that provides a notification when the drill bit comes
within some target distance of either the top or the bottom of the
formation. Hence, assuming the drilling plan is intended to
maintain the wellbore within the formation (between the upper and
lower surface), the rule will be triggered if the drill comes
within some distance of either the top or bottom surface. Hence,
the system may generate rules based on some relationship between
the drill bit and/or path of drilling, and a zone. The zone may be
considered a region within a 3D dimensional volume, based on
(computed from) one or more horizons (actual or virtual) in or
associated with the depth model. Target zones have areal extent (as
horizons do), but also have thickness. When a horizontal well is
drilled, the drilling team will attempt to define a wellbore path
that having penetrated down to a target zone, which will often be a
thickness of a formation, stays within the target zone for the
lateral portion of that wellbore path. The system provides a
mechanism to define a rule associated with the target zone and
provide notifications based on the progress of drilling within the
defined zone.
[0049] Thus, the system, through the rule module or otherwise, may
also be used, such as through the user interface, to generate and
base a rule based on the notion of a target zone. The target zone,
generally speaking, is a bounded zone within which it is desired to
maintain the drill bit. In one example, the target zone may
reference a target horizon and some distance or distances from the
target horizon, in the way introduced above. One simple example of
a target zone would be a target horizon and the target horizon plus
or minus some amount. Referring again to the notion of a shale
formation, a target horizon may be defined for a top surface of the
shale formation, and a drilling plan may be target a zone
immediately below the top surface of the horizon and within the
shale formation. Hence, the target zone may be bounded by the
target horizon and 20 feet below the target horizon, representing a
target zone of the upper 20 feet of the shale formation. In another
example, a target zone may be both above and below a target
horizon. A rule may be established to generate a notification when
the drill bit comes within some distance of either the top or
bottom of the defined zone. Similarly, a rule may be established
when a vector computation of the wellbore progress indicates that
the drill bit is deviating upwardly or downwardly within the zone
in a way that would cause the wellbore to leave the target
zone.
[0050] In another example, when there are adjacent formations, it
is possible to create a virtual horizon representing some
relationship between target horizons associated with each
formation. For example, if there is an upper and a lower shale
formation, that are stacked and adjacent one another, with each
formation defined by a target horizon for the upper surface of the
respective horizons, a virtual horizon might reference a
relationship between the target horizon of each formation and a
range of distances (above and below) the virtual horizon. In this
way, a target zone based on the virtual horizon may be defined.
[0051] In yet another example, the system (e.g., the rule module)
may generate a virtual horizon. In one example, the virtual horizon
may be a surface defined as some set distance from another surface,
such as a virtual horizon defined relative to a target horizon in
the depth model. The rule may both generate the virtual horizon,
and be defined to generate a notification based on the distance of
the drill bit from the virtual horizon. In this example, the target
horizon is a surface within the depth model, where the surface is
based on some corresponding feature in the related seismic data,
and the virtual surface is a surface that is generated based on
some mathematical relationship to the target horizon. A virtual
surface may be useful, for example, when the resolution of the
seismic data is insufficient to identify sub features within a
formation, but it is believed, based on perhaps other information,
that it is useful to target or avoid the sub feature and a virtual
surface is generated for the sub feature, and the rule then based
on the sub feature.
[0052] The target zone region may be further refined by analysis of
the 3D seismic data sample values that fall within the target zone.
An analysis may determine that some sub-regions within the target
zone should be high-graded, and some sub-regions should be avoided.
For example, one computation of the seismic sample values yields
numeric values (a so-called "seismic attribute values") that are
indicative of rock stiffness, which gives an indication of how well
the rock in a sub-region will respond the hydraulic fracturing
process. Now that seismic attribute values can be portioned into
ranges. For example, if all of the values are normalized into a
range of 0 to 100, and the range 0-30 is classified as undesirable,
and the range 70 to 100 is classified as very desirable, and the
pixel values of the seismic attribute values are colored as Red as
undesirable, and Green as desirable, and Transparent for anything
else, now a seismic cross-section through the target zone will
reveal red areas to be avoided and green areas to be high-graded.
The boundaries of these sub-regions can be detected and converted
into closed surfaces, and rules based on such surfaces, that are in
the same X,Y,Z coordinates as our depth model of the target zone or
other features, and as such, can be added to and be considered as
part of the definition of the target zone or otherwise be defined
as a feature from which the drill bit location and trajectory of
the well bore may be compared, and rules generated to trigger
notifications based on the relationship of the drill or well bore
to such features.
[0053] The notification module 206 is configured to notify team
members when a rule has been triggered. Rule analysis module 204
can provide to the notification module 206, when a rule has been
triggered, the data identifying the triggered rule. In one example,
the user interface may include a function for team member contact
information is entered. The contact information may include a phone
number for an SMS message, an email address, or other information
for the form of communication. The team members and contact
information may be linked to the drilling site, and whenever a rule
is triggered for the drilling site, the team receives a message
over the form (or forms) of communication entered in the site.
[0054] In response to receiving a notification from the rule
analysis module 204 that a rule has been triggered, notification
module 206 can identify a set of team members that should be
notified. In some embodiments, each rule can identify the
corresponding team members that should be notified when the rule
has been triggered as well as include contact information for the
identified team members, preferred contact method for the team
members and/or data that should be provided to the team members.
Notification module 206 can use the data in the triggered rule to
generate and transmit notification messages to the team members.
For example, notification module 204 can transmit the notification
messages as text messages, instant messages, e-mails, etc.
[0055] Data visualization module 208 can be configured to provide
team members with a visualization of an active drill. The
visualization of the active drill can be a 2 or 3 dimensional
rendering of the active drill at a drill site 106, including a
visual representation of the traversed path of the drill bit, the
target wellbore trajectory, target horizon, and geo-hazard, such as
a pre-existing wellbores, unpierced fault planes, lease boundaries,
etc.
[0056] Data visualization module 208 can receive data visualization
requests from client devices 108 for a visualization of an active
drill. A data visualization request can include data identifying a
drilling site 106, such as the unique identifier for the drilling
site 106. Data visualization module 208 can use the unique
identifier included in the visualization request to identify and
gather the corresponding drilling index in data stream storage 210
and depth module in depth model storage 212. Data visualization
module 208 can use the gathered data to generate visualization data
that can be rendered by client devices 108 to present the
visualization of the active drill. Data visualization module 208
can provide the generated visualization data to the requesting
client device 108, where it can be rendered for the team member.
Data visualization module 208 can continue to provide updated
visualization data to client device 108 to update the visualization
of the active drill, thereby allowing the team member to view
progress of the active drill in real-time.
[0057] FIG. 3 illustrates an example method 300 of automated
geo-target and geo-hazard notifications for drilling systems. It
should be understood that there can be additional, fewer, or
alternative steps performed in similar or alternative orders, or in
parallel, within the scope of the various embodiments unless
otherwise stated.
[0058] At step 302, a drilling management system can receive a
first drilling data stream. The first drilling data stream can
include coordinate data describing a traversed path of a drill
while drilling a well at a first drilling site. For example, the
coordinate data can include an X axis value, a Y axis value and a Z
axis value of the drill. The Z axis value can indicate a depth of
the drill.
[0059] At step 304, the drilling management system can determine,
based on the coordinate data and a depth model of the first
drilling site, that a first rule has been triggered. The depth
model of the first drilling site can identify a target wellbore
trajectory for the drill at the first drilling site. For example,
the drilling management system can determine, based on the
coordinate data, a current location of the drill and a distance
between the current location of the drill and the target wellbore
trajectory. The drilling management system can then determine that
the distance between the current location and the target wellbore
trajectory meets or exceeds a threshold distance dictated by the
first rule.
[0060] At step 306, the drilling management system can identify at
least a first user that should be identified when the first rule
has been triggered. For example, the first rule can include data
identifying the at least a first user that should be identified
when the first rule has been triggered.
[0061] At step 308, the drilling management system can transmit a
notification to the first user that the first rule has been
triggered.
[0062] FIGS. 4A-4D illustrate exemplary visualizations of an active
drill along with various possible information used by the rule
module to generate a notification. The visualization of the active
drilling operation depicted in FIG. 4A presents a 3 dimensional
representation of a drill site 400 (e.g., 3D seismic volume)
including a target horizon 402 and seismic cross-section 404. The
intersection of the target horizon and the seismic cross-section
represents a target wellbore trajectory 406 of the drill bit. The
current location of the drill bit 408 (as obtained from the drill
stream data) as well as the traversed path 410 of the drill bit
(e.g., wellbore path) is presented relative to the 3d seismic
volume, thereby allowing a team member to visually determine
whether the drill bit is remaining on the target wellbore
trajectory.
[0063] FIG. 4B shows another visualization of an active drill. As
show by the drill bit path 410, the drill bit 408 has drifted away
from the target wellbore trajectory 406. In this example, a target
zone is also shown, which is bounded by the target horizon and
defined, within a rule, as a distance d above the target horizon
and a distance d' below the target horizon. In this example,
besides deviation from the well bore trajectory, a rule may also be
triggered when the drill comes within some distance of the upper or
lower surface of the zone or other relationship to the zone is
defined. As mentioned above, the system may provide the
visualization through a web browser. Within the browser, an alert
(a form of notification) may be posted and a visual cue 412
provided in the viewable seismic cube. For example, a deviation
alert in the form of a text box may pop up in the browser window,
and a color coded portion of the actual drill path relative to the
target trajectory highlighted in some form such as a different
color relative to the non-deviated portion of the drill path.
[0064] FIG. 4C shows another visualization of an active drill. As
shown, the location of a pre-existing wellbore 414 is presented in
addition to the traversed path 410 of the drill bit 408 and the
target wellbore trajectory 406. Additionally, a minimum threshold
distance that the drill must maintain from the pre-existing
wellbore is represented as a cylinder 416 surrounding the
pre-existing wellbore. The cylinder may be represented in the depth
model as a three dimensional surface derived from a radius, of
whatever distance needed, around the preexisting wellbore. For
example, a cylindrical x, y, z surface may be generated around the
wellbore based on a 50 foot radius. Hence, an alert will be
triggered when the current drill bit position intersects any data
point of the cylinder defined by the 50 foot radius (e.g., the
drill bit gets within 50 feet of a preexisting wellbore). A team
member can view this visualization and easily determine that the
drill bit has drifted away from the target wellbore trajectory and
is approaching the minimum threshold distance from the pre-existing
wellbore.
[0065] FIG. 4D shows another visualization of an active drill. As
shown, the location of a geologic fault surface 418 is show in
relation to the traversed path 410 of the drill bit. A team member
can view this visualization and easily determine that the drill bit
is nearing the geographical fault surface, and a rule may trigger
an alert or other notification where the drill bit 408 reaches some
distance from the fault. In this example, the geo-hazard 418 may
also be color coded for easy differentiation relative to other
features.
[0066] FIG. 5A, and FIG. 5B illustrate exemplary possible system
embodiments. The more appropriate embodiment will be apparent to
those of ordinary skill in the art when practicing the present
technology. Persons of ordinary skill in the art will also readily
appreciate that other system embodiments are possible.
[0067] FIG. 5A illustrates a system bus computing system
architecture 500 wherein the components of the system are in
electrical communication with each other using a bus 505. Exemplary
system 500 includes a processing unit (CPU or processor) 510 and a
system bus 505 that couples various system components including the
system memory 515, such as read only memory (ROM) 520 and random
access memory (RAM) 525, to the processor 510. The system 500 can
include a cache of high-speed memory connected directly with, in
close proximity to, or integrated as part of the processor 510. The
system 500 can copy data from the memory 515 and/or the storage
device 530 to the cache 512 for quick access by the processor 510.
In this way, the cache can provide a performance boost that avoids
processor 510 delays while waiting for data. These and other
modules can control or be configured to control the processor 510
to perform various actions. Other system memory 515 may be
available for use as well. The memory 515 can include multiple
different types of memory with different performance
characteristics. The processor 510 can include any general purpose
processor and a hardware module or software module, such as module
1 532, module 2 534, and module 3 536 stored in storage device 530,
configured to control the processor 510 as well as a
special-purpose processor where software instructions are
incorporated into the actual processor design. The processor 510
may essentially be a completely self-contained computing system,
containing multiple cores or processors, a bus, memory controller,
cache, etc. A multi-core processor may be symmetric or
asymmetric.
[0068] To enable user interaction with the computing device 500, an
input device 545 can represent any number of input mechanisms, such
as a microphone for speech, a touch-sensitive screen for gesture or
graphical input, keyboard, mouse, motion input, speech and so
forth. An output device 535 can also be one or more of a number of
output mechanisms known to those of skill in the art. In some
instances, multimodal systems can enable a user to provide multiple
types of input to communicate with the computing device 500. The
communications interface 540 can generally govern and manage the
user input and system output. There is no restriction on operating
on any particular hardware arrangement and therefore the basic
features here may easily be substituted for improved hardware or
firmware arrangements as they are developed.
[0069] Storage device 530 is a non-volatile memory and can be a
hard disk or other types of computer readable media which can store
data that are accessible by a computer, such as magnetic cassettes,
flash memory cards, solid state memory devices, digital versatile
disks, cartridges, random access memories (RAMs) 525, read only
memory (ROM) 520, and hybrids thereof.
[0070] The storage device 530 can include software modules 532,
534, 536 for controlling the processor 510. Other hardware or
software modules are contemplated. The storage device 530 can be
connected to the system bus 505. In one aspect, a hardware module
that performs a particular function can include the software
component stored in a computer-readable medium in connection with
the necessary hardware components, such as the processor 510, bus
505, display 535, and so forth, to carry out the function.
[0071] FIG. 5B illustrates a computer system 550 having a chipset
architecture that can be used in executing the described method and
generating and displaying a graphical user interface (GUI).
Computer system 550 is an example of computer hardware, software,
and firmware that can be used to implement the disclosed
technology. System 550 can include a processor 555, representative
of any number of physically and/or logically distinct resources
capable of executing software, firmware, and hardware configured to
perform identified computations. Processor 555 can communicate with
a chipset 560 that can control input to and output from processor
555. In this example, chipset 560 outputs information to output
565, such as a display, and can read and write information to
storage device 570, which can include magnetic media, and solid
state media, for example. Chipset 560 can also read data from and
write data to RAM 575. A bridge 580 for interfacing with a variety
of user interface components 585 can be provided for interfacing
with chipset 560. Such user interface components 585 can include a
keyboard, a microphone, touch detection and processing circuitry, a
pointing device, such as a mouse, and so on. In general, inputs to
system 550 can come from any of a variety of sources, machine
generated and/or human generated.
[0072] Chipset 560 can also interface with one or more
communication interfaces 590 that can have different physical
interfaces. Such communication interfaces can include interfaces
for wired and wireless local area networks, for broadband wireless
networks, as well as personal area networks. Some applications of
the methods for generating, displaying, and using the GUI disclosed
herein can include receiving ordered datasets over the physical
interface or be generated by the machine itself by processor 555
analyzing data stored in storage 570 or 575. Further, the machine
can receive inputs from a user via user interface components 585
and execute appropriate functions, such as browsing functions by
interpreting these inputs using processor 555.
[0073] It can be appreciated that exemplary systems 500 and 550 can
have more than one processor 510 or be part of a group or cluster
of computing devices networked together to provide greater
processing capability.
[0074] For clarity of explanation, in some instances the present
technology may be presented as including individual functional
blocks including functional blocks comprising devices, device
components, steps or routines in a method embodied in software, or
combinations of hardware and software.
[0075] In some embodiments the computer-readable storage devices,
mediums, and memories can include a cable or wireless signal
containing a bit stream and the like. However, when mentioned,
non-transitory computer-readable storage media expressly exclude
media such as energy, carrier signals, electromagnetic waves, and
signals per se.
[0076] Methods according to the above-described examples can be
implemented using computer-executable instructions that are stored
or otherwise available from computer readable media. Such
instructions can comprise, for example, instructions and data which
cause or otherwise configure a general purpose computer, special
purpose computer, or special purpose processing device to perform a
certain function or group of functions. Portions of computer
resources used can be accessible over a network. The computer
executable instructions may be, for example, binaries, intermediate
format instructions such as assembly language, firmware, or source
code. Examples of computer-readable media that may be used to store
instructions, information used, and/or information created during
methods according to described examples include magnetic or optical
disks, flash memory, USB devices provided with non-volatile memory,
networked storage devices, and so on.
[0077] Devices implementing methods according to these disclosures
can comprise hardware, firmware and/or software, and can take any
of a variety of form factors. Typical examples of such form factors
include laptops, smart phones, small form factor personal
computers, personal digital assistants, and so on. Functionality
described herein also can be embodied in peripherals or add-in
cards. Such functionality can also be implemented on a circuit
board among different chips or different processes executing in a
single device, by way of further example.
[0078] The instructions, media for conveying such instructions,
computing resources for executing them, and other structures for
supporting such computing resources are means for providing the
functions described in these disclosures.
[0079] Although a variety of examples and other information was
used to explain aspects within the scope of the appended claims, no
limitation of the claims should be implied based on particular
features or arrangements in such examples, as one of ordinary skill
would be able to use these examples to derive a wide variety of
implementations. Further and although some subject matter may have
been described in language specific to examples of structural
features and/or method steps, it is to be understood that the
subject matter defined in the appended claims is not necessarily
limited to these described features or acts. For example, such
functionality can be distributed differently or performed in
components other than those identified herein. Rather, the
described features and steps are disclosed as examples of
components of systems and methods within the scope of the appended
claims.
* * * * *