2017-03-28 Assigned to RAKUTEN, INC. reassignment RAKUTEN, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: VERIZON PATENT AND LICENSING INC.
Establishing a conference between a customer at a customer terminal and a live agent at an agent station, by (a) accepting a call request from the customer terminal, (b) requesting that an available live agent take the call request, (c) when a live agent becomes available to take the call request, passing customer information to the agent station associated with the available live agent, and (d) establishing a conference from the agent station associated with the available live agent to the customer terminal. The conference may be an audio-video conference. The audio-video conference may be compliant with the H.323 standard. The call request may generated in response to an event sensed by an API which was previously downloaded to the customer terminal from a web server. The call request may be generated in response to a trigger event. The trigger event may be a customer request for a live agent, adding an item to a virtual shopping cart, adding items having a total purchase prices of more than a predetermined threshold to a virtual shopping cart, removing an item from a virtual shopping cart, dwelling at a certain web page for more than a predetermined length of time, rendering certain content, rendering a certain sequence of content, filling out a form, or issuing a particular command. The customer information may include an Internet protocol address of the customer terminal, a video capability of the customer terminal, and/or a browser type used by the customer terminal.
Benefit is claimed, under 35 U.S.C. § 119(e) (1), to the filing date of provisional patent application serial No. 60/151,793, entitled “Interactive Multimedia System for Use with Kiosks and Internet Based Customers”, filed on Aug. 31, 1999 and listing M. Reza Shafiee and Sankar Subramanian as inventors, for any inventions disclosed in the manner provided by 35 U.S.C. § 112, ¶1. Benefit is also claimed, under 35 U.S.C. § 119(e)(1), to the filing date of provisional patent application Ser. No. 60/172,321, entitled “Home-Based Internet Agent Assistance”, filed on Dec. 17, 1999 and listing M. Reza Shafiee and Sankar Subramanian as inventors, for any inventions disclosed in the manner provided by 35 U.S.C. § 112, ¶1. These provisional applications are expressly incorporated herein by reference.
The present invention concerns methods, apparatus and data structures for providing live agent assistance. More specifically, the present invention concerns methods, apparatus and data structures for invoking and establishing an audio, video, and/or data (e.g., text message) “call” or “conference” between a live agent and a customer in response to some event which may occur while the customer is browsing content on a network, such as the Internet for example.
Below, methods for providing customer service, as well as perceived shortcomings of such methods, are introduced. More specifically, Internet-based customer service and its perceived shortcomings are introduced in § 1.2.1 below. Then, a system in which customers can access live agents from kiosks and its perceived shortcomings are introduced in § 1.2.2. The discussion of these systems in this section is not, and should not be interpreted as, an admission that such systems are prior art.
The Internet has been successfully used to reduce the need for human customer service representative. That is, in many instances, customers can use the Internet to answer questions that they would otherwise present to a human customer service representative (also referred to as a “live agent”). However, the present inventors believe that in many instances, customers still would like to confer with (e.g., talk and/or see) a live agent. For example, a customer's uncertainty may prevent them from consummating an on-line transaction. In such instances, it would be helpful to have a live agent address any concerns the customer has so that the customer will feel comfortable in consummating (or will be able to consummate) the transaction. Although a customer may call a live agent, conferencing over the telephone with a live agent while viewing web pages may be inefficient. Further, in some instances, a single telephone line is used for both Internet access and telephone service. Thus, conferencing over the telephone with a live agent is not possible when viewing web pages under such circumstances. The present inventors also believe that it would be helpful to have a live agent suggest a purchase or a transaction to potential customers. Finally, the present inventors believe that it would be helpful for the live agent to have some customer information up-front, at or shortly after the start of the conference, so the customer does not have to provide the live agent with information already provided over the Internet (for example, via forms) or available from another source. As will be demonstrated in the following, the present invention may be used to achieve these advantages of providing a live agent to assist customers.
Provisional patent application Ser. No. 60/151,793, entitled “Interactive Multimedia System for Use with Kiosks and Internet Based Customers”, and filed on Aug. 31, 1999, discloses a multimedia call center (or “MCC”) in which live agents can assist customer end users at kiosk stations. It is expected that such kiosks will be located in areas open to the public, and preferably areas with high traffic such as airports, malls, grocery stores, train stations, bus terminals, etc. In such a system, a live agent can help a customer or potential customer complete a transaction. However, the present inventors believe that in addition to providing live agents to customers at kiosks, it would be helpful to permit live agents to assist customers at any terminal, such as a home computer connected to the Internet for example.
The MCC described in provisional patent application Ser. No. 60/151,793 can be supplemented so that the same live agents that help customers at kiosks (or, alternatively, other live agents), can assist customers or potential customers in completing a transaction over any terminal (such as a home computer for example) connected with a network (such as the Internet for example). Internet customers are provided with video, audio and/or other data (e.g., text messages) from live agents with which they interact over the Internet. The live agent can lead the customer through various web pages using a web browser (as described in U.S. patent application Ser. No. 09/487,049, entitled METHODS AND APPARATUS FOR PROVIDING AGENT CONTROLLED SYNCHRONIZED BROWSING AT A TERMINAL, by M. Reza Shaffie and Sankar Subramanian, filed Jan. 19, 2000 and incorporated herein by reference), enter information, answer questions and confirm orders. The live agent may receive textual inputs from the customer via the customer's key board, selection inputs from the customer via a pointing device, such as a mouse for example, audio input from the customer via a microphone, and/or video information from the customer via a camera. Even if the customer does not have a microphone or other audio input means at their premises, they can still receive audio information from the live agent. Similarly, even if the customer does not have a video camera or other video input means at their premises, they can still receive video information from the live agent. Accordingly, as used below, a “call” or a “conference” may include two-way audio/video communications, two-way audio, one-way video communications, two-way audio communications, text messaging (e.g., “chat” window) communications, or any combination of audio, video, and/or data (e.g. text messaging) communications.
The present invention may be used to establish a conference between a customer at a customer terminal and a live agent at an agent station, by (a) accepting a call request from the customer terminal, (b) requesting that an available live agent take the call request, (c) when a live agent becomes available to take the call request, passing customer information to the agent station associated with the available live agent, and (d) establishing a conference from the agent station associated with the available live agent to the customer terminal.
The conference may be an audio-video conference. The audio-video conference may be compliant with the H.323 standard.
The call request may generated in response to an event sensed by an API which was previously downloaded to the customer terminal from a web server.
The call request may be generated in response to a trigger event. The trigger event may be a customer request for a live agent, adding an item to a virtual shopping cart, adding items having a total purchase prices of more than a predetermined threshold to a virtual shopping cart, removing an item from a virtual shopping cart, dwelling at a certain web page for more than a predetermined length of time, rendering certain content, rendering a certain sequence of content, filling out a form, or issuing a particular command.
The customer information may include an Internet protocol address of the customer terminal, a video capability of the customer terminal, and/or a browser type used by the customer terminal.
FIG. 1 is a diagram of a system in which the present invention may operate.
FIG. 2 is a block diagram of a device which may be used to effect various aspects of the present invention.
FIG. 3 illustrates components of an exemplary multimedia call center server.
FIG. 4, which includes FIGS. 4A and 4B, is a flow diagram of an exemplary method for effecting a web browsing process which may be performed by a customer terminal in the system of FIG. 1.
FIG. 5 is a flow diagram of an exemplary method for effecting processes which may be performed by a site server in the system of FIG. 1.
FIG. 6 is a flow diagram of an exemplary method for effecting a process for invoking the establishment of a call between a customer at a customer terminal and an agent at an agent station in the system of FIG. 1.
FIG. 7 illustrates an exemplary directory database which contains a list of all stations known to a session manager in the system of FIG. 1.
FIG. 8 illustrates an exemplary skill database which contains a list of all skills of agents known to a session manager in the system of FIG. 1.
FIG. 9 illustrates an exemplary category database which contains a list of all category names known to a session manager in the system of FIG. 1.
FIG. 10 illustrates an exemplary private user group database which contains a list of all private user group names known to a session manager in the system of FIG. 1.
FIG. 11 illustrates an exemplary station table which may be used in the system of FIG. 1.
FIG. 12 illustrates an exemplary active call table which may be used in the system of FIG. 1.
FIG. 13 illustrates an exemplary skill table which may be used in the system of FIG. 1.
FIG. 14 illustrates components of an exemplary web request processor which may be used in the system of FIG. 1.
FIG. 15 is a flow diagram of an exemplary method for effecting a process for setting up a call between a customer at a customer terminal and an agent at an agent station in the system of FIG. 1.
FIG. 16 is a messaging diagram of the establishment of a call between a customer at a customer terminal and an agent at an agent station in the system of FIG. 1.
FIG. 17 is a messaging diagram of the termination of a call between a customer at a customer terminal and an agent at an agent station in the system of FIG. 1.
FIG. 18 is a messaging diagram of the transfer of a call between a customer at a customer terminal and an agent at an agent station, to another agent in the system of FIG. 1.
The present invention involves novel methods and apparatus for providing live agents to assist customers. The following description is presented to enable one skilled in the art to make and use the invention, and is provided in the context of particular applications and their requirements. Various modifications to the disclosed embodiments will be apparent to those skilled in the art, and the general principles set forth below may be applied to other embodiments and applications. Thus, the present invention is not intended to be limited to the embodiments shown and the inventors regard their invention as the disclosed methods, apparatus and any other patentable subject matter to the extent that they are patentable.
In the following, functions which may be performed by the present invention are introduced in § 4.1. Then, structures, processes, methods and data structures which may be used to effect those functions are described in § 4.2. Finally, examples of how an exemplary system of the present invention operates are described in § 4.3.
At a high level, the present invention may function to facilitate a “call” or “conference” between a live agent and a customer via an interface which may be used in conjunction with, or which may be a part of, a web browser. Further, the present invention may function to provide one or more triggers for invoking the establishment of such a call or conference. Other, more specific functions which may be performed by the present invention are introduced below when the various components of system are described.
An overview of a system which may be used to effect various aspects of the present invention is introduced in § 4.2.1 below. Then, various components of the system are described in more detail in §§ 4.2.1.1 through 4.2.1.4 below. Finally, examples which illustrate operations of the exemplary system are provided in § 4.3 below.
FIG. 1 is an exemplary system 100 which may be used to effect the functions introduced above. The system 100 may include one or more customer terminals 110, one or more (web) site servers 120, one or more agent stations 130, one or more kiosks 140 and a multimedia call center server 150. Each of these components may communicate with one another via a network 170, such as the Internet for example. Note, however, that the agent station(s) 130 and the site server(s) 120 may be part of a semi-secure local area network (or “LAN”) 174 separated from the Internet 170 by a first firewall 172. Note further that the multimedia call center server 150 may be part of a secure LAN 178 which is separated from the semi-secure LAN 174 by a second firewall 176. Each component of this exemplary system 100 is described in more detail below.
A customer terminal 110 may function to (i) permit users to browse Internet web (e.g., HTML) pages, (ii) render forms, (iii) accept information entered by a customer, and (iv) facilitate audio and/or video conferencing (or some other type of communications such as text messages for example). Referring to FIG. 2, these functions may be effected by a processor(s) 210, a storage device(s) 230 (such as RAM, ROM, magnetic, optical, and/or magneto-optic disks, and magnetic tape for example), input/output interfaces 220, an input device(s) 250 (such as a keyboard, a keypad, a pointing device, a microphone, and/or a video camera for example), an output device(s) 260 (such as a monitor and/or a speaker(s) for example), and a system bus or network 240. The processor(s) 210, input/output interface(s) 220, and storage device(s) 230 may communicate with one another via the system bus or network 240. Thus, for example, the functions which may be performed by the customer terminal may be effected by a personal computer.
A site server 120 may function to (i) serve requested web pages or other content such as video streams for example, (ii) maintain a history log of, and/or information entered during, a transaction (referred to simply as “transaction information”), and determine when a particular event occurs which may be used as a trigger to invoke an audio and/or video conference (or some other type of communications, such as text messages for example) between a customer at a customer terminal 110 and a live agent at an agent terminal 130. These functions, which may be performed by the site server 120, may be effected by the devices discussed above with reference to FIG. 2. By separating the multimedia site server(s) 120 from the multimedia call center 150, the multimedia call center 150 is isolated from “casual” traffic and is placed on the more secure LAN 178. More specifically, the H.323 compliant audio/video conferencing software introduced below may use dynamic port allocation for the video and audio channels. Many corporations are reluctant to open their networks to this kind of dynamic port allocation and to heavy video traffic. By using the two firewalls 172/176, the secure LAN 178 is kept free from video traffic originating from the multimedia site server 120. Video traffic is permitted on the semi-secure LAN 174.
An agent station 130 may function to (i) support an audio and/or video conference, (ii) support the communications of other types of information (e.g., text messages), (iii) browse web pages, (iv) share applications with another terminal (such as a customer terminal 110 or a kiosk 140 for example), (v) interpret transaction information, and (vi) access and update customer information. These functions, which may be performed by the agent station 130, may be effected by the devices discussed above with reference to FIG. 2.
A kiosk 140 may perform functions similar to those performed by a customer terminal 110. In addition, the kiosk may provide printing, scanning, check printing, card reading, signature capturing, and touch screen interfacing functions. Although the system 100 may include one or more kiosks 140, it does not need to have any kiosks 140 and may function more to serve customers at customer terminals 110.
A multimedia call center server 150 may include an operation and administration system 152, a multimedia session manager 158, a web-request processor 159 and storage devices 154, 156. The operation and administration system 152 may function to (i) monitor the system, (ii) check the status of any entity of the system, (iii) add or change agents, kiosks and services, (iv) generate reports of agents, system usage, etc., and (v) distribute system files to various terminals. The multimedia session manager 158 may function to (i) distribute requests for agents (also referred to simply as “calls”), (ii) set up conferences, (iii) manage communications channels, (iv) download and upload files, (v) manage skill groups and private user groups, (vi) log in and update kiosks or other system terminals, (vii) control the login of agents, (viii) distribute calls to skill groups and agents, (ix) create private user groups (or “PUGs”), and (x) create call usage records. The multimedia session manager 158 may include a call management process 162 for setting up, modifying, and/or terminating calls between an agent at an agent station 130 and a customer at a customer terminal 110 or kiosk 140. The call management process 162 may access and update memory tables 154 in a shared storage device. The multimedia session manager may also include a data support services process 166 which may access and update database files 156, which may include customer information for example, in a database. The web request processor 159 may be used to facilitate the establishment of an audio and/or video conference (or some other type of communications, such as text messages for example) over the network 170. Each of the components of the multimedia call center core system 150 may be hardware, processor(s), storage devices, hardware and/or software interfaces, and/or software programs. For example, the components 152,158,159 of the multimedia call center server 150 may be designed for Sun Sparc-based server class machines running the Solaris 7.0 or higher operating system from Sun Microsystems, Inc. of Mountainview, Calif. These components are designed to be installed on one (1) to three (3) machines, for example, based on the expected load and performance considerations.
Recall that a customer terminal 110 may function to (i) permit users to browse Internet web (e.g., HTML) pages, (ii) render forms, (iii) accept information entered by a customer, and (iv) facilitate audio and/or video conferencing (or some other type of communications such as text messages for example). Recall further that these functions may be effected by the system 200, such as a personal computer for example, illustrated in FIG. 2. More specifically, the functions of permitting users to browse Internet web pages, rendering forms, and accepting information entered by a customer may be effected by browser software (such as Explorer from Microsoft Corporation or Navigator for example), an input/output interface device (such as a modem or a network interface card and router for example) a pointer device (such as a mouse for example), and a display. The function of facilitating some form of conferencing may be effected by conferencing software (such as NetMeeting from Microsoft Corporation for example), an input device (such as a video camera, a microphone, a tablet, a pointer and/or a keyboard for example), an output device (such as a display and/or a speaker(s) for example), and an input/output interface device (such as a modem or a network interface card and a router for example).
FIG. 4 illustrates the arrangement of FIGS. 4A and 4B which are referred to, collectively, as FIG. 4. FIG. 4 is a flow diagram of an exemplary method 110′ which may be used to effect processes of the customer terminal 110. Please note that in the flow diagram of FIG. 4, as well as the other flow diagrams described, the steps do not need to be performed in the sequence shown unless the results of a particular step are needed before another step is performed. At decision branch point 410, it is determined whether or not a synchronized web browsing command is received. For example, an agent at an agent station 130 may control a synchronized web browsing session rendered at a customer terminal 110, via the web site server 120 for example. If it is determined that a synchronized web browsing command is received, a page (or other content or program) from the server with the uniform resource locator (or “URL”) associated with the command is requested as shown in step 415. The method then continues at decision branch point 420. Returning to decision branch point 410, if it is determined that a synchronized web browsing command is not received, the method continues directly to decision branch point 420.
At decision branch point 420, it is determined whether or not a customer requested a resource (e.g., by activating a hypertext link or typing in a URL for example). If so, the resource is requested from the server with the URL associated with the request as shown in step 425. The method then continues at decision branch point 430. Returning to decision branch point 420, if it is determined that a customer did not request a resource, the method continues directly to decision branch point 430.
At decision branch point 430, it is determined whether or not content (such as content requested by the customer or via a synchronized web browsing command for example) has been received. If so, the content is rendered as shown in step 435 and the method continues at decision branch point 440. Returning to decision branch point 430, if it is determined that content is not received, the method continues directly to decision branch point 440.
At decision branch point 440, it is determined whether or not a message regarding a queued call request is received. For example, if the customer is to have a call or conference with a live agent, that customer may receive status messages about when they will be provided with a live agent. These status messages are particularly advantageous if the customer affirmatively or explicitly requests a live agent. If so, as shown in step 445, the message is rendered and the method continues at decision branch point 450. Returning to decision branch point 440, if it is determined that a message regarding a queued call request is not received, the method continues directly to decision branch point 450.
At decision branch point 450, it is determined whether or not a trigger event for invoking the establishment of a call with a live agent has occurred. The trigger event may be, for example, the customer requesting a live agent (e.g., by activating a button, typing or speaking a command, etc.), or the customer taking some other action (e.g., adding an item to a “shopping cart”, adding items having a total purchase price of more than a predetermined threshold to a “shopping cart”, removing an item from a “shopping cart”, dwelling at a certain page for a predetermined length of time, viewing certain content or a certain sequence of content, filling out a form, issuing a particular request or command, etc.). If so, the web request processor 159 is notified, and the method 110′ continues at decision branch point 460 (via Node A 458). Returning to decision branch point 450, if it is determined that a trigger event for invoking the establishment of a call with a live agent has not occurred, then the method 110′ continues directly to decision branch point 460 (via node A 458).
At decision branch point 460, it is determined whether a call has already been requested and a status period has expired. If so, as shown in step 462, the method 110′ may request the status of the call from the web request processor 159 (and a status period timer is reset) and the method 110′ continues to decision branch point 464. Otherwise, if it is determined that a call has not already been requested or a status period has not expired, the method 110′ continues directly to decision branch point 464.
At decision branch point 464, it is determined whether a call has already been requested and then a cancel call has been subsequently requested. If so, the method 110′ requests that the web request processor 159 cancel the call as shown in step 466, and the method 110′ continues to decision branch point 470. Otherwise, the method 110′ continues directly to the decision branch point 470.
At decision branch point 470, it is determined whether or not a “page load” has been received from the web request processor 159 (in response to a trigger event as discussed above with reference to steps 450 and 455). If so, the browser opens a new window as shown in step 471. Most customers will have audio/video conferencing software, such as NetMeeting from Microsoft Corporation of Redmond, Wash. for example, residing on their terminal. If however, the needed software is not available, the user may be prompted to download the software and then continue their browsing session later, or the user may be prompted to place a telephone call to a live agent as shown in steps 472 and 474, before the method 110′ is left via RETURN node 495. If, on the other hand, the needed software is available, it is loaded as shown in steps 472 and 473 and the method 110′ may submit a request to the web request processor 159 to establish a call as shown in step 475. In this letter case, the method 110′ then continues to decision branch point 480.
At decision branch point 480, it is determined whether or not the user has submitted a completed (or at least partially completed) form. If so, the submitted form is forwarded to the URL associated with the form as shown in step 485. The method 110′ the continues at decision branch point 490. Returning to decision branch point 480, if it is determined that a form has not been submitted, the method 110′ continues directly to decision branch point 490.
At decision branch point 490, it is determined whether or not the web browsing method has received a close command. If so, the method 110′ is left via RETURN node 495. Otherwise, steps 410-490 of the method 110′ are repeated.
Having described an exemplary customer terminal 110, an exemplary web site server 120 is now described in § 4.2.1.2 below.
Recall that a site server 120 may function to (i) serve requested web pages or other content such as video streams for example, (ii) maintain a history log of, and/or information entered during, a transaction (referred to simply as “transaction information”), and determine when a particular event occurs which may be used as a trigger to invoke an audio and/or video conference (or some other type of communications, such as text messages for example) between a customer at a customer terminal 110 and a live agent at an agent terminal 130. Recall further that these may be effected by the devices discussed above with reference to FIG. 2.
FIG. 5 is a flow diagram of an exemplary method 122′/124′/126′ which may be used to effect the web site server processes 122/124/126. Please note that in the flow diagram of FIG. 5, as well as the other flow diagrams described, the steps do not need to be performed in the sequence shown unless the results of a step are needed before another step is performed. At decision branch point 510, it is determined whether or not a request for content is received. If so, the requested content is forwarded to the requester as shown in step 512 and a transaction history for that requester is updated as shown in step 514.
One or more of the pages provided by the site server 120 to the customer terminal may include an application program interface (or “API”) for invoking the establishment of a call to a live agent. Using the API, web pages call embedded “talk to agent” buttons or active links. The API may be a URL with active parameters. The method then continues at decision branch point 520. Referring back to decision branch point 510, if a request for content is not received, the method continues directly to decision branch point 520.
At decision branch point 520, it is determined if customer information is received, such as via a completed (or partially completed) and submitted form for example. If so, transaction information is updated as shown in step 525. The method then continues at decision branch point 530. Referring back to decision branch point 520, if customer information is not received, the method continues directly to decision branch point 530.
At decision branch point 530, it is determined whether a trigger event (for invoking the establishment of a conference or call with a live agent) has occurred. The trigger event may be, for example, the customer requesting a live agent (e.g., by activating a button, typing or speaking a command, etc.), or the customer taking some other action (e.g., adding an item to a “shopping cart”, adding items having a total purchase price of more than a predetermined threshold to a “shopping cart”, removing an item from a “shopping cart”, dwelling at a certain page for a predetermined length of time, viewing certain content or a certain sequence of content, filling out a form, issuing a particular request or command, etc.). In any event, if a trigger event occurred, the method 122′/124′/126′ provides a web page with the “invoke call” API introduced above as shown in step 532. Further, an optional step of forwarding transaction information (e.g., to the multimedia session manager 158) may be performed at this time as shown in step 534. In this way, when a live agent becomes available, they will have access to information already known about the customer. The method then branches back to decision branch point 510. Referring back to decision branch point 530, if a trigger event has not occurred, the method continues directly to decision branch point 510.
Having described an exemplary web site server 120, an exemplary multimedia call center server is now described in § 4.2.1.3 below.
The multimedia call center server 150 is largely responsible for managing the system 100. It may function to control the distribution of calls, perform user validation, manage network resources, monitor station clients, and store and/or create call usage records.
When a station (e.g. agent station 130 or a kiosk 140 (and optionally, a customer terminal 110) logs on, it must first register with the multimedia call center server 150. The multimedia call center server 150 accepts TCP/IP based socket connections from both such stations. (See, e.g., FIG. 3.) The station can then register (or login) with the multimedia call center server 150. The multimedia call center server 150 may then create a memory table entry 154 for that station. When that socket connection dies, or is terminated, all table entries 154 associated with it terminate. Upon login, the multimedia call center server 150 may verify that all remote software components are valid. If any of the stations do not have valid software, the multimedia call center server 150 may send the appropriate software files to that station.
When a customer wants to reach an agent, the customer negotiates first with the multimedia session manager 158. The multimedia session manager 158 may attempt to assign a call request to a next available agent. As soon as, a qualified agent becomes available, that agent may be given a call back number (or IP Address) at which the customer can be reached. The multimedia call center server 150 is not necessarily actually involved in establishing the call. Conferencing support processes, such as NetMeeting from Microsoft Corporation for example, in the agent and customer stations may perform this task over the network 170, such as a TCP/IP network. The multimedia call center server 150 may then record information about the nature of the call and may then proceed to monitor network/station status.
When the call with the customer is completed, the multimedia call center server 150 is notified and the agent drops the call. This agent then becomes available to serve another call waiting in a queue.
The multimedia call center server may also facilitate call transfers and multiparty calls.
The multimedia call center server 150 may be designed for use on a UNIX platform. The modules 152, 158 and 159 may use shared memory and semaphores as supported by the operating system. The use of shared memory ensures data stability and ease of recovery. It also allows for data sharing between processes.
The multimedia call center server 150 may include three (3) main components—a session manager 158, an operation and administration system 152 and a web-request processor 159. The session manager is described in more detail in § 4.2.1.3.5 below. The operation and administration system 152 is described in more detail in § 4.2.1.3.4 below. Finally, the web request processor 159 is described in more detail in § 4.2.1.3.6 below. As shown in FIG. 3, the session manager 158, the operation and administration system 152 and the web request processor 159 may communicate with one another via a CDPE (Concurrent Distributed Processing Environment) layer 310. The entire system may sit atop a TCP/IP stack 320.
Recall that user information may be stored, updated, and accessed by the operation and administration system 152. FIGS. 7 through 10 are exemplary data structures of files in the user information database 156. FIG. 7 illustrates a directory database which contains a list of all stations known to the session manager 158. The directory database is described in § 4.2.1.3.2.1 below. FIG. 8 illustrates a skill database which contains a list of all skills of agents known to the session manager 158. The skill database is described in § 4.2.1.3.2.2 below. FIG. 9 illustrates a category database which contains a list of all category names known to the session manager 158. Since the details of the category database are not needed to appreciate the present invention they are not described here. Finally, FIG. 10 illustrates a private user group database which contains a list of all private user group names known to the session manager 158. Since the details of private user group database are not needed to appreciate the present invention, they are not described here.
The field names 710 of the directory database, as well as their size 720 and description 730, are set forth in FIG. 7. Note that each kiosk 140 or agent station 130 has a unique login name 740, an associated password 750, a (via the web request processor 159) unique port identifier 760, and a user name directory listing 770. Also note that the port identification 760 may also be referred to as the “address” of the station. Since the “addresses” of all potential customer terminals 110 cannot be determined ahead of time, they are gathered by the multimedia call center server 150 (via the web request processor 159) at the time a customer desires to access a live agent.
The field names 810 of the skill database, as well as their size 820 and description 830, are set forth in FIG. 8. The skill database stores primary video conferencing protocols 840 and addresses 845, secondary video conferencing protocols 850 and addresses 855, and default video conferencing protocols 860 and addresses 865. Since the video conferencing protocols and addresses of all potential customer terminals 110 cannot be determined ahead of time, they are gathered by the multimedia session manager 150 (via the web request processor 159) at the time a customer desires to access a live agent.
Memory tables are data structures that reside in shared memory 154. They are initialized upon startup of the call management process 162 and are accessible by the call management process 162. Having multiple instances of the call management process 162 permits data sharing. FIG. 11 is a station table 1100, FIG. 12 is an active call table 1200, and FIG. 13 is a skill table 1300. Each is described in more detail below.
A station table 1100 contains information related to a station, such as a kiosk 140 or a agent station 130 for example. The station table 1100 illustrates field names 1110, and their type 1120, size 1130, and description 1140. As shown in FIG. 11, the station table 1100 may include a login name 1152 for the station, an associated password 1154, a unique stations port identifier 1156, a video conferencing protocol type identifier 1162, a video conferencing address 1164, an alternative video conferencing protocol type identifier 1166, an alternative video conferencing address 1168, an internet protocol (or “IP”) address 1170 of the station, an encryption type 1182 employed by the station, and an (public) encryption key 1184 disseminated by the station.
The active call table 1200 contains information related to an established call. Since the active call table 1200 is not particularly relevant to the understanding of the invention, it is not described in further detail. The skill table 1300 contains information related to the known skills. Since the skill table 1300 is not particularly relevant to the understanding of the invention, it is not described in further detail.
The operation and administration system 152 may facilitate all administration-related tasks. These tasks may include generating reports, setting up resources, and managing the database 156. The operation and administration system 152 may communicate with other components of the multimedia call center 150 via the CDPE layer 310.
The multimedia session manager 158 may function to facilitate all session related tasks, namely routing calls, managing resources (e.g., stations) and distributing files. The session manager 158 may communicate with other components via the CDPE layer 310. Having introduced the session manager 158, components which may be included in the session manager are introduced in §§ 4.2.1.3.5.1 and 4.2.1.3.5.2 below.
The call management process 162 may be used for call setup, call modification (e.g., adding parties, transfers, etc.) and call termination. The call management process 162 does not actually place or route a call—rather, it notifies the relevant parties to place a call or to receive a call. The actual call is independent of the multimedia call center server 150. Call setup is initiated by the customer terminal 110 (or at the kiosk 140) and the call is placed from the agent station 130 to the customer terminal 110.
Stations, such as agent stations 130 and kiosks 140 login with the call management process 162 upon startup. More specifically, the station may identify itself and it capabilities using a unique identifier and can send a login name. If the call management process 162 determines that the software residing on a station is out of date, it will notify the data support server process 166 to transfer all necessary files. Station login is described in U.S. patent application Ser. No. 09/487,049, by M. Reza Shafiee and Sankar Subramanian, filed on Jan. 19, 2000 and entitled “METHODS AND APPARATUS FOR PROVIDING AGENT CONTROLLED SYNCHRONIZED BROWSING AT A TERMINAL” (which is incorporated herein by reference). However, unlike a kiosk 140, a customer's home-based terminal (such as a personal computer for example) will obviously not perform the same login steps. Rather, the web call management process 184, described in § 4.2.1.3.6 below, facilitates the establishment of a call between a customer terminal 110 and an agent 130.
The call management process 162 may be an event driven process. A particular message received by a station may cause a sequence of counter events to occur. In addition, an internal time process may run to facilitate the triggering of system events.
FIG. 6 is a high level flow diagram of a portion of an exemplary method 162′ for effecting the multimedia session manager 158. At decision branch point 610, it is determined whether or not an agent has been requested (e.g., whether or not a not yet queued request for an agent has been received). If, not, the method 162′ branches to decision branch point 660,′ (discussed below). If, on the other hand, an agent has been requested, the request is queued as shown in step 620 and acknowledge may be submitted to the requestor (e.g., the web request processor 159) as shown in step 625. The method 162′ then continues to decision branch point 630.
At decision branch point 630, it is determined whether or not there is an agent (e.g., an agent in an appropriate skill group) available to take the request. If not, the method 162′ branches to decision branch point 660, (described below). Otherwise, if an agent is available to take the request, the call request (e.g., along with transaction history information) is forwarded to the available agent as shown in step 645. Further, an updated status is sent (e.g., to the web request processor 159 (which submitted the request)) as shown in step 645. The method then continues to decision branch point 650. At decision branch point 650, it is determined whether or not an acknowledge message has been received from the agent. If not, the method may branch to decision branch point 665. At decision branch point 655, if a time out period has not expired, the method 152′ branches back to decision branch point 650. Otherwise, if the time out period has expired, the method 162′ is left via RETURN node 690. Referring back to decision branch point 650, if an acknowledge is received from the agent, tables (for the agent and, if appropriate, the customer) are updated as shown in step 680 and the method 162′ continues to decision branch point 660.
At decision branch point 660, it is determined whether or not a “wrap-up” status message has been received (e.g., from the agent). If so, the table (e.g., associated with the agent) is updated as shown in step 665 and the method 162′ continues to decision branch point 670. Otherwise, the method 162′ continues directly to decision branch point 670.
At decision branch point 670, it is determined whether or not a transfer request has been received (e.g., from an agent). If so, the call is queued as shown in step 675 and the method 162′ is left via RETURN node 690. Otherwise, the method 162′ proceeds directly to RETURN node 690.
The data support services process 166 may be used to record all session data. It may receive a copy of all messages to and from the call management process 162. The data support services process 166 may record such messages into a circular log file. This log file may be subject to post processing for creating data reports.
FIG. 14 is a block diagram which illustrates an exemplary architecture of a web request processor 159. As discussed above with reference to FIG. 1, the exemplary web request processor 159′ may include a brownie manager 182′ (for effecting a brownie management process 182), a web call manager 184′ (for effecting a web call management process 184) and a script manager 186′ (for effecting a script management process 186). An instance 1402 of each of these processes may be provided for each call (e.g., a per-message process). Each instance 1402 may have one or more common graphical interface (or “CGI”) bins 1404 per message. Basically, CGI bins 1404 facilitate the generation of dynamic web pages. More specifically, with normal hyper text mark-up language (or “HTML”), each hypertext link has an associated uniform resource locator (or “URL”) which corresponds to a file location. These URLs are pre-existing and static. CGI bins 1404 basically call an executable process, the output of which may be an HTML file (i.e., a dynamic page). For example, and as will be described in more detail below, a “call button” may be used to dynamically create a call request, the call request having a browser type, an IP address, and a video capability. Finally, the exemplary web request processor 159′ may include a web server 1412 which may communicate with the web browsing-process 112 at the customer terminal 110.
The brownie management process 182 (or the brownie manager 182′) is described in more detail in § 4.2.1.3.6.1 below. Then, the script management process 186 (or the script manager (186′) is described in more detail in § 4.2.1.3.6.2 below. Finally, the web call management process 184 (or the we call manager 184′) is described in more detail in § 4.2.1.3.6.3 below.
The brownie management process 182 may be used to assign a unique identifier (also referred to as a “brownie”) to each call request. This brownie is then referenced in all the subsequent transactions and pages to identify the call. A brownie is not to be confused with cookies which are set on client browsers. A brownie is not stored on the client browser. Rather, each page sent out by the web request processor 159 has the brownie.
The web call management process 184 may be used to place requests in the CDPE queues. It can also be used to provide status updates to the browsing process 112 at the customer terminal 110 periodically, or in response to an event or a request. The web call management process 184 may also be used to coordinate call transfers and disconnects.
Recall from § 4.2.1 above that the agent stations 130 may function to permit a live agent to assist a customer at a kiosk 140 or at a terminal 110. Recall further that such assistance may take the form of audio, video, and/or data (e.g., text message) communications (as well as synchronized (web) browsing in which the agent station 130 acts as a guide terminal and the kiosk 110 or customer terminal 110 acts as a follower terminal which is disclosed in U.S. patent application Ser. No. 09/487,049.) The agent station 130 may also function to invoke the establishment of a connection between it and another terminal, such as a kiosk 140 or another agent station 130. Further, the agent station 130 may function to encrypt (using a public key for example) communications sent from it. Furthermore, the agent station 130 may function to control access to content, such as web pages for example. An agent station 130 may further function to permit a live agent to control kiosk peripherals, access customer information from a database 156, update customer information, send and receive messages to and from other live agents, transfer customers to another live agent, and access call information. These functions, which may be performed by the agent station 130, may be effected by the devices discussed above with reference to FIG. 2. In an exemplary embodiment, agent stations 130 may include a (web) (e.g., HTML) browser process 134 which is similar to the (web) browser process 112 included in the customer terminals 110, an applications sharing process 136 (e.g., a synchronized (web) browsing process) a transaction history tracking process 138, an audio/video conferencing process 132 and other (e.g., text messages) communications process 133.
In view of the foregoing, a live agent can view scanned identification documents, interpret them, and manually enter name, address and other information obtained from the identification documents into one or more forms, e.g., credit applications, purchase forms, etc. Since communication between the kiosk 110 and the agent stations 130 may be provided over a secure, e.g., encrypted data channel, confidential information may be exchanged without fear of unauthorized interception. Thus, for example, completed application or purchase forms can be transmitted to a kiosk 140, a signature on the form captured, and payment received without security concerns. In addition, a live agent can control the printing of checks, money orders, etc. at the kiosk 140. Thus, for example, if a loan application is approved, the customer can be provided the money in the form of a check issued directly from the kiosk 140. Furthermore, a live agent can fill out service and/or purchase forms based on, e.g., customer information obtained via scanned identification documents, and control the kiosk 140 to print the completed form. A customer's signature on a completed form can be captured using the kiosk's signature capture device and the completed form with signature can be printed at the kiosk 140 as well as the agent station 130. The flat bed scanner can be used to acquire images of driver's licenses, credit cards and other forms of identification.
FIG. 15 is a flow diagram of an exemplary method 132′ which may be used to effect the audio/video conferencing process 132 (and, optionally, the transaction history tracking process 138). At decision branch point 1505, it is determined whether or not a call request has been received, from the multimedia session manager 158 for example. The call request may include information for establishing a call, such as the customer terminal's browser type, IP address, video capabilities, and name. If a call request has not been received, the method 132′ continues to decision branch point 1520 (discussed later). If, on the other hand, a call request has been received, then the agent station 130 establishes a call with the customer terminal associated with the request as shown in step 1510. An audio/video call may be established using means complaint with the H.323 standard, for example, via NetMeeting from Microsoft Corporation. Although not shown in FIG. 15, if the customer terminal 110 has less capabilities, then the other (e.g., text messaging) communications process 133 can be invoked to establish a different type of “call” between the agent station 130 and the customer terminal 110. Next, the method 132′ may send a connect response message to the multimedia session manager 158, as shown in step 1515. The method 132′ then continues to decision branch point 1520.
At decision branch point 1520, it is determined whether or not a call is in progress and a call disconnect is commanded (e.g., by the agent at the agent station 130). If so, the call with the requesting customer terminal is terminated as shown in step 1525. This call termination may be done in accordance with H.323 standards, such as via NetMeeting of Microsoft Corporation for example. Then the method 132′ may send a “wrap up” state indication to the multimedia session manager 158 as shown in step 1530 before the method 132′ continues to decision branch point 1535. Referring back to decision branch point 1520, if a call is not in progress or if a call disconnect is not commanded, then the method 132′ continues directly to decision branch point 1535.
At decision branch point 1535, it is determined whether or not a call is in progress and a call transfer has been commanded (e.g., by an agent at the agent station 130). If not, the method 132′ continues back to decision branch point 1505. If, on the other hand, a call is in progress and a call transfer has been commanded, then the method 132′ submits a transfer request to the multimedia session manager as shown in step 1540. As shown in decision branch point 1545, the method 132′ awaits a transfer response from the multimedia session manager 158. Assuming that a positive response is received (which indicates that the multimedia session manager 158 has gotten another agent to take the call), the method 132′ continues to step 1525, which was already discussed above. Although not shown here, if a time out period expires, or if the multimedia session manager 158 informs the method 132′ that no other agent is available to take the call, the method 132′ may continue back to decision branch point 1505.
Having described exemplary processes, methods, apparatus and data structures for effecting various aspects of the present inventions, examples which illustrate operations of such exemplary embodiments are now presented in § 4.3 below.
Having described the system and its components, an example which illustrates how a audio and/or video conference (or some other type of communication such as text messages) between a customer at a customer terminal and a live agent at an agent station may be invoked, set up, and carried out is provided in § 4.3.1 below with reference to FIG. 16. Then, an example which illustrates how a “call” is disconnected is provided in § 4.3.2 with reference to FIG. 17. Finally, an example which illustrates how a “call” is transferred from one agent to another is provided in § 4.3.3 with reference to FIG. 18.
FIG. 16 is a messaging diagram which illustrates how a conference (or call) can be established between a customer at a terminal 110 and a live agent at a station 130. As shown in FIG. 16, a customer may request, via terminal 110, content (e.g., web pages, HTML text, pictures, audio and/or video streams, etc.) and provide information (e.g., via forms) to a web site server 120. This is depicted by communication 1605. (Recall steps 420 and 425 of FIG. 4.) In response to such requests, the web site server 120 can provide content and forms to the customer's terminal 110. This is depicted by communication 1610. (Recall steps 510 and 512 of FIG. 5) At some point, the web site server 120 may recognize an event which is used as a trigger to establish (or invoke) a conference (or call). The trigger event may be, for example, the customer requesting a particular web page (or pages), or the customer taking some other action (e.g., adding an item to a “shopping cart”, adding items having a total purchase price of more than a predetermined threshold to a “shopping cart”, removing an item from a “shopping cart”, dwelling at a certain page for a predetermined length of time, viewing certain content or a certain sequence of content, filling out a form, issuing a particular request or command, etc.). Such an event is depicted by note 1615. In response to the event, the web site server 120 may provide a page with a “call agent” application program interface (or “API”) to the customer terminal 110, as shown by communication 1620. This API will allow the customer to issue a request for a live agent. For example, the API may include a “call agent” button which may be activated by the user, or may monitor the customer terminal 110 for some other event for invoking the establishment of a call to an agent.
Assuming that an agent call is requested, by means of the API, by the customer terminal 110, such a request is provided to the web request processor 159 as depicted by communication 1625. (Recall steps 450 and 455 of FIG. 4.) The request 1625 may include information regarding the browser being used at the customer terminal 110, the internet protocol (or “IP”) address of the customer terminal 110, a name or identifier associated with the customer terminal 110, and a video capability of (e.g., video protocols supported by) the customer terminal 110. The request 1625 may also include transaction information which may be used by a live agent as will be described below.
In response, the web request processor 159 may forward a page load to the customer's web browser as shown in communication 1630. The page load communication 1630 may include a command to open a new browser window, as well as a command to load conferencing software and video streaming software (such as NetMeeting from Microsoft Corporation of Redmond, Wash. and RealVideo). It is presumed that this software resides on the customer terminal 110. If not, the customer terminal may render a message prompting the user to load the needed software or to make an ordinary telephone call to an agent. Alternatively, assuming that the conferencing software can be loaded in a reasonable amount of time from a remote source, it may be loaded and started from such a remote source. In response to the page load communication 1630, the customer terminal 110 may forward a web call request to the web request processor 159 as shown in communication 1635. This communication 1635 may be automatically generated by the page load 1630, using JAVA script for example. (Recall steps 470, 471, 472, 473 and 475 of FIG. 4.) The web call response communication 1650 from the web request processor 159 to the customer terminal 110 may include an indication that the agent call request has been queued. The customer terminal 110 may render a video stream, for example, download by the site server 120, while it waits for an agent to take its “call”. (See note 1652.) At about the same time, the web request processor 159 may request an agent (agents may be grouped based on their skills) from the multimedia session manager 158 as shown by communication 1640. (Recall step 610 of FIG. 6.) The multimedia session manager 158 may acknowledge this request as shown by communication 1645. Thus, as shown by note 1660, the request is queued until an agent becomes available.
Once an agent becomes available to take a queued call as shown in note 1660, the multimedia session manager 158 may update the status of the call and communicate this new status to the web request processor 159, as shown in communication 1662. In addition, the multimedia session manager 158 may submit the call request to the available agent 130 as shown by communication 1664. (Recall step 640 of FIG. 6.) The communication 1664 may include customer information such as their browser type, their IP address, their name and their video capabilities. Recall that the customer provided the web request processor 159 with this information in the call request communication 1625, and the web request processor 159 may have provided the multimedia session manager 158 with this information in request agent communication 1640.
In response to the call request communication 1664, the available agent station 130 may establish an audio, video, and/or other data (e.g., text message) call with the customer terminal 110. (Recall step 1510 of FIG. 15.) At about this time, the agent station 130 may also provide a call connect response communication 1668 to the multimedia session manager 158. (Recall step 1515 of FIG. 15.) In response, the multimedia session manager 158 may update the tables for both the agent 130 and the customer terminal 110 as indicated by note 1690. (Recall step 680 of FIG. 6.) Also, after the audio, video, and/or data call is established between the agent 130 and the customer terminal 110, the streams of via which may have been provided from the site server 120 may be stopped as shown by note 1692. (Note that the video streams may be provided while the conferencing software is being started and/or as the call is queued while awaiting an available agent.) Further, the web request processor 159 may provide script-based web pages to the customer terminal 110 as shown by communication 1694.
Although not shown in FIG. 16, information regarding the customer or the history of the customer's transaction(s) with the web site server 120 may also be communicated to the agent station 130 so that the agent does not need to request information from the customer that the customer has already provided (e.g., via forms).
In view of the foregoing, web designers can use a small and easy to use API to facilitate the establishment of a call (e.g., a video conference) with a live agent. Such a call may be invoked upon the occurrence of a trigger event.
Having described an example of how a call between a customer and an agent may be established, terminating such a call is described in § 4.3.2 below with reference to FIG. 17 and transferring such a call is described in § 4.3.3 below with reference to FIG. 18.
In addition, in response to the call termination 1710, the customer terminal 110 may request a status from the web request processor 159 as shown in communication 1730. In response, the web request processor 159 provides the status to the customer terminal 110 in communication 1735. In this case, the status will be that the call has been (or is being terminated). As shown in note 1740, the customer terminal 110 may then render a “thank you” page. As described in § 4.3.3 below, if the agent terminated that call pursuant to a call transfer operation, the status provided in communication 1735 will indicate that the call is being transferred to another live agent. In such a case, the customer terminal 110 may be made to wait for the completion of the call transfer.
Having briefly introduced a call transfer operation, an example of the operation of a call transfer is now provided in § 4.3.3. below with reference to FIG. 18.
In addition, in response to the call termination 1825, the customer terminal 110 may request a status from the web request processor 159 as shown in communication 1855. In response, the web request processor 159 provides the status to the customer terminal 110 in communication 1860. In this case, the status will be that the call is being transferred. As shown in note 1865, the customer terminal 110 may then wait for the call to be transferred. Further, as the customer terminal is waiting, it may render a video stream (or slide show, etc.).
As shown in note 1845, the multimedia session manager 158 may queue the call transfer. (Recall steps 670 and 675 of FIG. 6.) The multimedia session manager 158 may submit the call request to the second agent (which may be the next available agent) 130 b as shown by communication 1850. The communication 1850 may include customer information such as their browser type, their IP address, their name and their video capabilities. Recall that the customer provided the web request processor 159 with this information in the call request communication 1625 of FIG. 16, and the web request processor 159 may have provided the multimedia session manager 158 with this information in request agent communication 1640 of FIG. 16.
In view of the foregoing, the present invention permits a customer at almost any terminal (having some video and/or audio conferencing capabilities) to access a live agent via a “call”. The establishment of the call may be handled by means (e.g., 150) remote from a web site server 120—the web site server 120 may employ an API to invoke such means (e.g., 150). The call may be carried over a semi-secure network which is isolated from the means (e.g., 150) by a firewall 176. Basically, the API permits the means (e.g., 150) to gather information it passes onto a next available agent for establishing a “call” from the agent station 130 to the customer terminal 110 without needing any prior knowledge about the customer terminal 110.
The live agent's station 130 can access information about the customer that has already been gathered.
While the customer awaits a live agent, it can receive video streams, slide shows, etc. To entertain or inform them from the site server 120.
d) establishing a conference from the agent station associated with the available live agent to the customer terminal.
2. The method of claim 1 wherein the conference includes at least one of audio, video, and text communications.
3. The method of claim 1 wherein the conference includes at least two of audio, video, and text communications.
4. The method of claim 1 wherein the conference is an audio-video conference.
5. The method of claim 4 wherein the audio-video conference is compliant with the H.323 standard.
wherein the API was previously downloaded to the customer terminal from a web server.
8. The method of claim 1 wherein the customer information includes at least one of (a) an Internet protocol address of the customer terminal; (b) a video capability of the customer terminal; and (c) a browser type used by the customer terminal.
e) when it is determined that a live agent at an agent station becomes available, forwarding a web call request to the agent station.
wherein the agent station can establish a conference with the customer terminal based solely on the information about the customer terminal.
15. The method of claim 13 wherein each of the web conference request and the web call request includes at least one of (a) an Internet protocol address of the customer terminal; (b) a video capability of the customer terminal; and (c) a browser type used by the customer terminal.
ii) queuing the accepted request until a live agent becomes available.
17. The system of claim 16 wherein the multimedia session manager informs the web request processor when an available live agent accepts the queued call.
ii) for providing a “call agent” application program interface to the customer terminal.
g) a second firewall arranged between the semi-secure LAN and the secure LAN.
20. The system of claim 19 wherein the conference between the agent station and the customer terminal takes place via the semi-secure LAN, the first firewall, and the Internet.
21. The system of claim 19 wherein the conference between the agent station and the customer terminal takes place via the Internet.
b) if a trigger event occurs, providing an “invoke call” API to the customer terminal.


When is subsurface drilling a trespass in Pennsylvania?
Unlike other minerals, natural gas is fugitive meaning it moves through the subsurface based on changes in pressure. Pennsylvania’s rule of capture permits a well operator to drain natural gas from a common reservoir under an adjacent property, even absent a mineral lease. In the context of unconventional shale gas wells using hydraulic fracturing, however, the Pennsylvania Superior Court recently decided that fractures crossing boundary lines are an unlawful trespass.
In November of 2015, the Briggs family filed suit against Southwestern Energy Production claiming the operator unlawfully extracted natural gas from beneath their 11 acres. The Briggs argued that, despite the lack of physical intrusion, Southwestern’s forced extraction of natural gas through hydraulic fracturing made it possible to identify which parcel provided the source of recovered gas. Southwestern argued the direction of fractures cannot be controlled and if the company did recover gas from beneath the Briggs’ property, their actions were permitted by the rule of capture.
This April, the Pennsylvania Superior Court issued a decision in the Briggs’ case explaining that engineers design hydraulic fracturing operations by selecting injection pressures and volumes based on site-specific geologic data and can estimate the length fractures will extend from the well. Further, “[u]nlike oil and gas originating in a common reservoir, natural gas, when trapped in a shale formation, is non-migratory in nature… Shale gas does not merely ‘escape’ to adjoining land absent the application of external force.” Briggs v. Southwestern Energy Prod. Co., 184 A.3d 153 (Pa. Super. Ct. 2018).
The Court found that in light of the differences between hydraulic fracturing and conventional gas drilling, hydraulic fracturing “may constitute an actionable trespass where subsurface fractures, fracturing fluid and proppant cross boundary lines and extend into the subsurface estate of an adjoining property for which the operator does not have a mineral lease...” Briggs, 184 A.3d at 163-164.
The Court sent the case back to the trial court for the Briggs to develop evidence of fractures crossing boundary lines and damages. In early July, however, Southwestern petitioned the Pennsylvania Supreme Court arguing the decision departs from the time-honored rule of capture and threatens to disrupt the industry. To date, the PA Supreme Court has not decided whether to hear the appeal.
For more information about how your rights and property may be impacted by natural gas extraction, contact attorney Ryan Hamilton at (412) 904-2774.
The Ohio Fifth District Court of Appeals issued a ruling on August 13, 2018 that could provide some protections for lessors that have leases with clauses that contain limitations on pooling or units.
The case, American Energy – Utica, LLC et al. v. Ronald Fuller, involved a lease that had included a handwritten clause that read “UNITIZATION BY WRITTEN AGREEMENT ONLY!” The lease was originally signed in 1981 by the landowners and D.B. Shaffer & Associates, Inc., and the rights of the lessee were assigned to EnerVest in 2009, and then to American-Energy-Utica (“AEU”) in 2013. AEU then requested that the landowners agree to amend the lease in order to allow unitization of the leasehold, but the parties could not reach an agreement. Rather than continue to negotiate, AEU filed an application with the Ohio Division of Oil and Gas pursuant to Ohio’s mandatory unitization statute, Ohio Revised Code Section 1509.28, in order to force the landowners’ property into the proposed unit, against the landowner’s will and in direct conflict the lease itself.
On this particular issue, the Court held that using the mandatory unitization law at Section 1509.28 to circumvent the clear language in the lease violated the Section 28, Article II of the Ohio Constitution because it was “used to retroactively impair the obligation of the contract.” The Court also found that this constituted a breach of the lease and remanded to the trial court with instructions to determine the remedy. While the ultimate remedy remains to be seen, the constitutional finding by the Court is important because it suggests that the unitization statute can’t be used to force lands subject to leases with similar unitization restrictions into units.
For context, a “pool” is defined as an underground reservoir containing a common accumulation of oil or gas, or both. A “unit” is simply a formal designation of contiguous land outlining the boundaries of development of a pool of oil and/or gas resources. With the recent development of technologies to horizontally drill and fracture deep shale formations in order to extract oil and gas resources, the concept of a “pool” in which to develop a unit has broadened greatly to include large geological formations of shale in an area. However, in 1965, when Ohio’s mandatory pooling and unitization statutes were enacted, a “pool” of oil or gas was more limited to a relatively free flowing reservoir in a geological formation. The drafters of the statutory sections outlining “mandatory pooling” and “mandatory unitization” could not have contemplated “pools” from which to form units would grow to the many hundreds of acres that we see today in the Utica and Marcellus shale development.
If you are a fan of private property rights, you might find forced pooling troubling, but you will almost certainly find forced unitization far more nefarious in the context of today’s shale gas development. Unitization in principle is closely related to mandatory pooling, because it compels non-consenting landowners to include their land in a unit for ultimate oil and gas development. However, where mandatory pooling is only allowed to the extent necessary to meet minimum spacing requirements, forced unitization can capture vast amounts of land, up to hundreds of acres in size. The requirements under the forced unitization statutory section are that the applicant have 65% of the proposed unit through consent or ownership, and be “reasonably necessary to increase substantially the ultimate recovery of oil and gas, and the value of the estimated additional recovery of oil and gas exceeds the estimated additional cost” of the unit. In other words, the Ohio statute may allow private oil and gas companies to take of up to 35% of property within a proposed unit (which the companies come up with) as long as they can show it would be profitable. Since units for shale gas development can be upwards of 1,000 acres or more in size, this statute as its applied today can allow hundreds of acres at a time to be forced into development without agreement or consent of Ohio property owners.
Saving discussion on the constitutionality of the general application of Ohio’s forced unitization law to current shale gas development for another day, The Fifth District Court of Appeals’ ruling in Fuller appears to offer protections to landowners who have contracted limits on unitization from Ohio’s intrusive forced unitization law. Even landowners that are open to negotiating a lease often tell us that they feel like they can’t negotiate on equal footing with an a oil and gas company when company representatives threaten or initiate forced unitization proceedings if their standard lease terms aren’t met. Some older oil and gas leases contain size limits on units to 40 acres or less, and horizontal drilling in the Utica shale in Ohio often requires units of far greater than 40 acres, so the Fifth District’s decision could give landowners with such lease restrictions a lot of leverage in negotiations when approached to amend their lease.
Property rights issues, and oil and gas rights issues in particular, are often complex, and it is always advisable to speak to an experienced attorney about your rights when approached to sign or amend an oil and gas lease.
 Am. Energy - Utica, LLC v. Fuller, 5th Dist. Guernsey No. 17 CA 000028, 2018-Ohio-3250, ¶ 7.
 Am. Energy - Utica, LLC v. Fuller, 5th Dist. Guernsey No. 17 CA 000028, 2018-Ohio-3250, ¶ 40.
If you look at the law, you’ll see that you have protection. Living and working in coal country and the processes of coal extraction coexist beautifully in the statutes and rulebooks governing the handling of claims of damage from the process of mining. In reality, however, the law pits a landowner against two very powerful and resourceful figures: the coal mining company and the government, to enforce the landowner’s right to a replacement water supply or compensation for damage to buildings and lands that literally fall in to the ground due to subsidence once mining occurs in the area.
The law requires a replacement water supply or compensation for subsidence damage when a landowner complains to the mining company and the state conducts an investigation determining that mining was the presumptive cause or, for properties outside of a certain number of feet diagonally from the extracted coal, was the cause of the water loss or diminished quality or subsidence. If the state makes that finding, then the coal company is allowed time to rebut the presumption or otherwise prove that the cause of subsidence, contamination or diminished quantity of water is something other than mining. Many times, we see the state giving the coal company multiple opportunities to make such a showing.
Then it happens: the state issues an order stating that the coal company was right. We hear the same story from our clients almost every time. The story is that the state first orders the mining company to provide a temporary water supply replacement, which is usually in the form of a water buffalo that has to be filled at least once a week. Then, the state and the company test the water well for quality and quantity. They wait, test again, and may repeat this process as long as they see fit. Then, the company will produce an expert report that always seeks to rebut the presumption that they caused the damage. The state then gives in, sends a letter to the landowner stating that a replacement supply is not warranted, and the water buffalo is removed. Our client then has 30 days to appeal the decision.
Most of our clients start the appeal process headstrong to get their water back and seek justice. Even when we provide pro bono services, our clients are faced with the prospect of having to prove that the coal company’s actions caused the impact to their water or damage to their land and structures. The cost is daunting: around $15,000 at a minimum just for the development of an expert report. The decision our clients eventually have to make: spend money on an uncertain outcome to seek justice OR spend money on a solution to the home or structure damage, such as drilling a new and deeper water well or moving away. It’s an unfair outcome no matter which decision the client makes.
While we have settled many water supply replacement and subsidence cases, we have never won one. For example, after one 5-day hearing, Ohio’s Reclamation Commission, where appeals of the State’s decision on causation must be brought, factually ruled out every single one of the State’s reasons for causation (well maintenance, drought, and other local users), and yet could not reach a quorum on whether the nearby mining caused our clients’ water losses. The procedural result of this non-decision is that the State’s finding is upheld, despite the finding that the basis for their decision is false. These landowners are still without a potable water supply, more than 3 years after mining approached their properties and their wells went dry, and despite having plenty of water for household uses for decades from these same wells. The combination of two well-funded parties in the State and the Mining Company against a landowner, and requiring the landowner to prove exactly what occurred in the underground water source and how its connected to the nearby mining, is a nearly impossibly heavy burden in today’s expensive legal and expert services market. Our clients simply cannot afford to go through hearing. Most of the time, our clients cannot afford an expert witness to opine on the cause of the water loss or structural damage.
We have noticed the difference between legal protection on the face of the law and justice most in these water supply replacement cases among all of our environmental cases. It renders legal rights meaningless when the administrative process is used to bargain those rights away.
To date and without any explanation of its consideration of the Pennsylvania Constitution's Environmental Rights Amendment, the Pennsylvania Environmental Hearing Board has put the burden of proving any objections to environmental permits, such as an inadequately sized geologic barrier between a newly proposed mine and an abandoned mine, on ill-equiped individuals and community organizations. 25 Pa. Code § 1021.122(c). Therefore, the most effective environmental permit challenges in PA are those where unsupported permit conditions are made practical, impactful and reasoned, which should make those conditions better. Defeating a permit is hard under these circumstances.
The process of challenging an environmental permit involves all-out litigation - factual & legal theory development, motions that whittle away at those theories and the parties respective budgets, hiring and working with scientific and engineering experts who can intelligently educate the judge on her expert opinion about the permit and its protectiveness. Then there's a lengthy trial where the administrative law judge sits as judge and jury. It's a three-party trial that typically pits an individual or community against a powerfully-aligned governmental agency and industry. Going to trial does not often yield the exact results sought. It's an expensive, and because of the inexplicable and unjust burden of proof rule, incredibly risky proposition to rely on the Board's hearing process to achieve reasonable results through a hearing on the merits.
Since we are, after all, lawyers as counselors instead of lawyers as monotonous predictors of the outcome of single court or administrative arguments, we can look at the permit challenge process as an opportunity to secure better results than what a full hearing on the merits may be able to achieve if the industrial party and community organization or individual party are willing to discuss settlement. Without fail, what my clients are seeking in this process is to be heard and valued for what they have to add to the decisionmaking process. So, in any process that I engage in for my clients, I seek to fulfill the objective of adding that client's value to the decisionmaking process.
One of the best ways to ensure that your client is valued in environmental decisionmaking is to both maximize their access to information and data AND to give them as much future opportunity to enforce against violations of a permit (or a settlement agreement) in the future. In a hotly contested and well-funded coal mining permit challenge called Mountain Watershed Association v. DEP and LCT Energy Co. (Rustic Ridge Mine No. 1 case) we achieved that twofold objective in a way that should be replicated.
· Barriers: 800 foot barrier increased to 1400 foot horizontal barrier between the Melcroft No. 3 abandoned mine & the new Rustic Ridge No. 1 Mine; a piezometer will be placed in the barrier to detect water level changes that would indicate an illicit discharge to the Melcroft No. 3; and quarterly monitoring and more frequent monitoring the closer the mining comes to the barrier of that piezometer goes to MWA.
· Temperature: relocation of the wastewater outfall to a downstream location just prior to the confluence with Champion Creek.
· Flow: 1500 gpm flow from dewatering of the coal seam reduced to 1,000 gpm to ensure that streambed erosion does not occur.
· Noise & blasting: eliminated fan shaft & return shaft through development of three slopes in the pit; location of variable frequency fan underground during slope development; peak particle velocity limited to 1.0 inch per second; air blast limited to 126 db; seismograph installed at home nearest to mine & readings from the seismograph go to MWA.
· Lighting: dark sky & canopy lighting to be used.
· Information: Discharge Monitoring Reports, pumping rates & six month mining map to be provided to MWA regularly.
This settlement, which likely looks incredibly practical and reasonable, marks the first time in years that my client actually felt heard in the permit appeal process. On many occassions, we reached out to the governmental decisionmakers to try to make the exact points that the settlement agreement ultimately rested upon. The governmental attorney's response to our requests? Either that there's no need to meet or that my client has the ability to comment on the permit in the same way as everyone else. It is more than fair to criticize the PA governmental attorneys' apparent inability to do anything other than work to obstruct individuals and community organization's ability to be heard and valued.
It's not just the governmental attorney at fault. There's absolutely no reason that industries seeking permits cannot start the process of valuing the community in which they seek to operate long before a permit is even in draft form. If lawyers for those industrial users choose to push things through bureaucratic processes without valuing individuals and communities, then they should expect that hearings on the merits will focus on creating value by increased recordkeeping and data development as permit conditions, and by reducing environmental impact through more stringent pollution control requirements subject to citizen enforcement.
The way to engage in these otherwise lopsided hearing processes and ensure that you are meeting your client's objective of being valued in the environmental decisionmaking process is to see the attorney's role - for the industrial client, for the individual or community organization, and even for the government - as a true counselor, which involves much more than simply predicting the outcome of a legal argument. Lawyers as counselors can build value in all parts of the community and build community wealth. Use the settlement between a small watershed association and a coal mine as your guide for the possibilities.
We climbed two major mountains (Bearwallow at the Hatfield McCoy Trail System & Cazy Mountain), got fairly off course a few times, saw a lot of clusters of homes in hollows and churches, met some really nice people...some who had just processed a deer and got us right back on course, and we climbed and climbed and climbed.
At the top of Cazy Mountain towards the end of the day, we found ourselves at a plateau with low vegetation. We were untroubled until we rounded the bend only feet away, opening out into a gorgeous vista full of developed trees, and realized the low growth wasn't tree line but the vestiges of surface mining.
What pieces of community are still standing in the many of the clusters of homes we ran through? Typically, a post office, a dump, small plots with chain link fences, and homes that made the most of it, contrasted by well-maintained churches. In those clusters of homes, we saw so many "Free Will Baptist" churches that we started to wonder about the branding and were concerned that hope lies in things like food, health, the absolutely gorgeous places that we ran through (we all thought national park status was warranted for almost the entirety of our route), and something more than branded faith. We quickly added it to our to-do list to hear from people more familiar with the churches before reaching any judgments.
We spent a good amount of time along creeks and steep hillsides that made us feel like we were in areas where the land was protected and for the people to enjoy. What was incredible is that we didn't see people in those places. The connection between land and people was disjointed and unclear. But the people we met were so wonderful, so helpful and kind, and hunting. So, we're going into day 2 wondering about that connection and seeking clarity. West Virginians live in paradise. It's unclear that paradise is helping them.
Have you ever been faced with a situation in which there was an alleged violation of law regarding air pollution, water pollution, solid waste, infectious waste, hazardous waste, construction and demolition debris, public water supply, or cessation of chemical operations? Or has there ever been a circumstance where you suspected that a company has failed to meet a requirement of a license, permit, variance or plan approval relating to any of the previously listed violations?
If so, then most likely you have called your local or state authorities to report. However, waiting on the agency to respond or to take action, if ever, can be a frustrating process that citizens often have little control over. Well, Ohio law provides a way in which you can ease this frustration. You can file a verified complaint directly to the Ohio EPA. This process provides for formal written and appealable agency response to your complaint. If you file proper a verified complaint to the Ohio EPA, they have a duty to respond and act on this complaint within a period of 180 days. By taking advantage of this unique process, you can better assure answers to the numerous questions or problems you may be facing within your local community or home when an environmental violation occurs.
Ohio’s rules for filing verified complaints can be found under Ohio Revised Code §3745.08. Once an individual demonstrates that they have been adversely affected by an environmental issue, they can file a verified complaint. If the director determines a violation is evident from the verified complaint that you have filed, the director may issue an order to the violator to correct the problem or request that the Attorney General's Office begin legal proceedings.
It is important to note that if for any reason the verified complaint is reviewed and dismissed, the dismissal is considered a final decision of the Director of the Ohio Environmental Protection Agency (EPA). Any action taken by the Director in relationship to a verified complaint is considered appealable to the Ohio Environmental Review Appeals Commission (ERAC). Specifically, if the complainant is adversely affected by the decision, he or she can file a Notice of Appeal with ERAC in order to appeal a final action if the Ohio EPA proceeding or decision was arbitrary, capricious or unlawful.
b. Also, the complainant must describe his or her knowledge of the violation.
i. Standing cannot be based upon something the complainant simply read.
a. The complainant must give as many detailed facts as possible. This is because often times a verified complaint can be dismissed where the Ohio EPA cannot gather sufficient information about the violation. Photographic evidence can be very useful.
3) The complainant must provide a list of the alleged violations citing the specific laws or regulations that were disregarded.
a. It may be helpful to have attorney review your complaint prior to submitting it. This way you can identify as many laws and regulations that were believed to be violated, and the Ohio EPA will have a better idea of what the specific problem is.
4) The complainant must provide verification in the form of a sworn and notarized affidavit by the complainant, or his/her agent or attorney.
a. To notarize prevents fraud and ensures the appropriate people execute documents freely. Institutions rely upon notaries so they may have full faith in important documents. These materials serve as a means of verifying the transaction so others may rely upon it. When you see a notary’s seal on a document, it means a trusted notary public represents that it is authentic and properly executed.
b. The verified complaint must be in writing and include the words “Verified Complaint” at the top.
Be sure to review your verified complaint several times before submitting it! It is imperative to understand that a verified complaint may be of ease and cost efficient, BUT it can be easily dismissed or overlooked if it isn’t executed properly. The Director of the Ohio EPA makes the decision to either dismiss the complaint or take action. A properly executed verified complaint can be a powerful tool for landowners who suspect environmental violations have occurred on their property or in their community.