Operations, such as geophysical surveying, drilling, logging, well completion, and production, are typically performed to locate and gather valuable downhole fluids. Surveys are often performed using acquisition methodologies, such as seismic mapping, resistivity mapping, etc. to generate images of underground formations. These formations are often analyzed to determine the presence of subterranean assets, such as valuable fluids or minerals, or to determine if the formations have characteristics suitable for storing fluids. Although the subterranean assets are not limited to hydrocarbons such as oil, throughout this document, the terms “oilfield” and “oilfield operation” may be used interchangeably with the terms “field” and “field operation” to refer to a site where any types of valuable fluids or minerals can be found and the activities required to extract them. The terms may also refer to sites where substances are deposited or stored by injecting them into the surface using boreholes and the operations associated with this process. Further, the term “field operation” refers to a field operation associated with a field, including activities related to field planning, wellbore drilling, wellbore completion, and/or production using the wellbore.
Models of subsurface hydrocarbon reservoirs and oil wells are often used in simulation (e.g., in modeling oil well behavior) to increase yields and to accelerate and/or enhance production from oil wells. Seismic interpretation tools and seismic-to-simulation programs can include numerous functionalities and apply complex techniques across many aspects of modeling and simulating. Such programs typically include a large suite of tools and different programs and are referred to as exploration and production (E&P) tools known to those skilled in the art. Users of such systems may spend many hours per day working with these tools in an effort to optimize geological interpretations and reservoir engineering development scenarios.
Within the E&P knowledge workspace, the end users of the interpretation applications (typically geoscientists) are often the most knowledgeable on the data used within the interpretations. In many cases, they have created or requested the acquisition of the data. Due to data governance and management policies, the end users may not be able to alter information they find or believe to be erroneous—and thus must forward or inform a data manager who is the custodian of the information. It typically requires a lot of effort to follow up with the data manager, and to explain what, where, when, and other key context of the data issue.
In general, in one aspect, the invention relates to a method for operating an exploration and production (E&P) tool in a field having a subterranean formation. The method includes displaying, in a first image generated by a first instantiation of the E&P tool, a plurality of graphical elements corresponding to a plurality of objects in the field, receiving, by the first instantiation of the E&P tool and from a first user, a first annotation comprising a first issue description regarding a first data item of a wellbore in the plurality of objects, tagging the first annotation onto a first graphical element representing the first data item of the wellbore, wherein the first annotation is stored in a repository and accessible by the first instantiation of the E&P tool and a second instantiation of the E&P tool, sending a first notification to a second user regarding the first annotation, and receiving, by a computer processor executing the second instantiation of the E&P tool and from the second user, a first response to the first issue description, wherein the first response is added to the first annotation and stored in the repository, wherein the first response is accessible from the repository by the first user using the first instantiation of the E&P tool.
Other aspects of the invention will be apparent from the following detailed description and appended claims.
The appended drawings illustrate several embodiments of user sourced data issue management and are not to be considered limiting of its scope, for user sourced data issue assignment and reporting may admit to other equally effective embodiments.
FIGS. 3.1-3.7 depict an example for user sourced data issue management in accordance with one or more embodiments.
Aspects of the present disclosure are shown in the above-identified drawings and described below. In the description, like or identical reference numerals are used to identify common or similar elements. The drawings are not necessarily to scale and certain features may be shown exaggerated in scale or in schematic in the interest of clarity and conciseness.
Aspects of the present disclosure include a method, system, and computer readable medium to allow an end user of an E&P tool to tag a data item as having a possible issue, such that other users in a community can share the information. The data item may be a location or other data associated with an object in the field (e.g., a wellbore, hydrocarbon reservoir, formation layer, etc.). In one or more embodiments, an issue description is tagged to the data item as an annotation. Generally, the annotation is a virtual tag assigned to a location or other data, and can include text, links, images, documents, etc. regarding the possible issue concerning the data item. In one or more embodiments, the type of an annotation can be specified by the selection of a graphical icon that gives the other users an understanding of the nature of the annotation, e.g., basic informative, notification, alert, etc. Throughout this disclosure, the term “object” refers to a physical item in the field, the term “data item” refers to data describing one or more attributes of the object, and the term “graphical element” refers to a displayed element in a graphical user interface (GUI) of the E&P tool. In particular, the graphical element may representing one or more object(s), data item(s) associated with the object(s), or annotations(s) tagged to the data item(s). The graphical element may also be a component of the GUI, such as a radio button, textbox, drop-down list, etc. Further, the term “instantiation” refers to an occurrence, session, or a copy of a software application, whether currently executing or not.
The data item and the annotation are part of a larger data set that is stored in a shared repository accessible by a data manager, who would be notified. The notification may be via an email or other interface for the data manager to view the issue description with its context (e.g., location, related data, reporting user information, nature of the error, time of reporting, etc). Multiple issue descriptions reported by multiple users may be organized in a metadata list. This list may be viewable in 2D and/or 3D format for the data manager to quickly determine the nature and validity of reported data issues, such that proper actions are taken to resolve them. Once the data is corrected or the issue closed, the reporting user is notified of the update with the corresponding action noted in the annotation and history of the data item.
As shown in
As shown in
Further as shown in
In one or more embodiments, the surface unit (202) is operatively coupled to the computer (192) and/or a wellsite system (204). In particular, the surface unit (202) is configured to communicate with the computer (192) and/or the data acquisition tool (102) to send commands to the computer (192) and/or the data acquisition tools (102) and to receive data therefrom. For example, the data acquisition tool (102) may be adapted for measuring downhole properties using logging-while-drilling (“LWD”) tools. In one or more embodiments, surface unit (202) may be located at the wellsite system (204) and/or remote locations. The surface unit (202) may be provided with computer facilities for receiving, storing, processing, and/or analyzing data from the computer (192), the data acquisition tool (102), or other part of the field (104). The surface unit (202) may also be provided with or functionally for actuating mechanisms at the field (100). The surface unit (202) may then send command signals to the field (100) in response to data received, for example to control and/or optimize various field operations described above.
In one or more embodiments, the data received by the surface unit (202) represents characteristics of the subterranean formation (104) and may include seismic data and/or information related to porosity, saturation, permeability, natural fractures, stress magnitude and orientations, elastic properties, etc. during a drilling, fracturing, logging, or production operation of the wellbore (103) at the wellsite system (204). For example, data plot (108-1) may be a seismic two-way response time or other types of seismic measurement data. In another example, data plot (108-2) may be a wireline log, which is a measurement of a formation property as a function of depth taken by an electrically powered instrument to infer properties and make decisions about drilling and production operations. The record of the measurements, typically on a long strip of paper, may also be referred to as a log. Measurements obtained by a wireline log may include resistivity measurements obtained by a resistivity measuring tool. In yet another example, the data plot (108-2) may be a plot of a dynamic property, such as the fluid flow rate over time during production operations. Those skilled in the art will appreciate that other data may also be collected, such as, but not limited to, historical data, user inputs, economic information, other measurement data, and other parameters of interest.
In one or more embodiments, the surface unit (202) is communicatively coupled to an exploration and production (E&P) computer system (208). In one or more embodiments, the data received by the surface unit (202) may be sent to the E&P computer system (208) for further analysis. Generally, the E&P computer system (208) is configured to analyze, model, control, optimize, or perform other management tasks of the aforementioned field operations based on the data provided from the surface unit (202). In one or more embodiments, the E&P computer system (208) is provided with functionality for manipulating and analyzing the data, such as performing seismic interpretation or borehole resistivity image log interpretation to identify geological surfaces in the subterranean formation (104) or performing simulation, planning, and optimization of production operations of the wellsite system (204). In one or more embodiments, the result generated by the E&P computer system (208) may be displayed for user viewing using a 2 dimensional (2D) display, 3 dimensional (3D) display, or other suitable displays. Although the surface unit (202) is shown as separate from the E&P computer system (208) in
As shown in
In one or more embodiments, the E&P computer system (208) includes the E&P tool (230) having software instructions stored in a memory and executing on a processor to communicate with the surface unit (202) for receiving data therefrom and to manage (e.g., analyze, model, control, optimize, or perform other management tasks) the aforementioned field operations based on the received data. In one or more embodiments, the received data is stored in the data repository (234) to be processed by the E&P tool (230). One or more field operation management tasks (e.g., analysis task, modeling task, control task, optimization task, etc.) may be performed in an execution pass of the E&P tool (230), referred to as an E&P tool session. During the E&P tool session, the received data is manipulated by the task engine (231) to generate, continuously or intermittently, preliminary results that are rendered and displayed to the user using the data rendering module (226) and a display (e.g., display-1 (233-1), display-2 (233-2), or display-3 (233-3)) assigned to the user, respectively. For example, the E&P tool session may be a seismic interpretation session where the task engine (231) processes the seismic data set and the data rendering module (226) renders interpreted seismic results to be displayed to the user using the display (e.g., display-1 (233-1), display-2 (233-2), or display-3 (233-3)). In one or more embodiments, one or more of the display-1 (233-1), display-2 (233-2), and display-3 (233-3) may be a 2D display, a 3D display, or other suitable display device. In one or more embodiments, each of multiple users may launch a separate instantiation/session (i.e., an occurrence or a copy, whether currently executing or not) of the E&P tool (230) to access shared data set in the data repository (234). For example, the display-1 (233-1), display-2 (233-2), and display-3 (233-3) may be used by three users to separately view results of their E&P tool sessions. As noted above, the term “object” refers to a physical item in the field (e.g., wellbore (103), geological structures (106-1 through 106-4), reservoir, etc. in the field (100) of
The processor and memory of the E&P computer system (208) are not explicitly depicted in
In one or more embodiments, the E&P computer system (208) includes a communication manager (221) that is configured to allow a user of the E&P tool (230) to communicate with another user of the E&P tool (230). In one or more embodiments, the E&P computer system (208) includes an annotation tagging module (224) that is configured to receive an issue description from a first user (referred to as the data reporting user, e.g., a geologist) while the data reporting user is viewing a subterranean formation field data set using a first instantiation of the E&P tool (230) (referred to as the issue reporting instantiation). Specifically, the issue description describes a potential issue concerning a data item in the subterranean formation field data set. In one or more embodiments, the annotation tagging module (224) is instantiated as part of the issue reporting instantiation that receives the issue description. Further, this instantiation of the annotation tagging module (224) combines a configuration parameter (e.g., camera angle of the view in a 3D spatial window when note was captured, colors, zoom level, etc.) of the issue reporting instantiation and the issue description into an annotation, and stores the annotation in the data repository (234). Further, the annotation is tagged onto a graphical element representing the data item and displayed in a first image (referred to as the issue reporting image) generated by the data rendering module (226) (instantiated as part of the issue reporting instantiation). In one or more embodiments, the communication manager (221) (instantiated as part of the issue reporting instantiation) sends a notification to a second user (referred to as a data manager user) regarding the annotation generated/tagged by the data reporting user. For example, the data manager user may have launched or will launch, in response to the notification, a second instantiation of the E&P tool (230) (referred to as the data manager instantiation).
In one or more embodiments, in response to the notification, the data manager instantiation of the E&P tool (230) generates a second image (referred to as the data manager image) as a reproduction of the issue reporting image for displaying to the data manager user. Specifically, the annotation tagging module (224) (instantiated as part of the data manager instantiation) retrieves the annotation from the data repository (234) to extract the issue description associated with the data item and the configuration parameter of the issue reporting instantiation. In one or more embodiments, the data rendering module (226) (instantiated as part of the data manager instantiation) reproduces the issue reporting image based on the configuration parameter of the issue reporting instantiation to generate the data manager image. Accordingly, the data item and the issue description are displayed in the data manager image for analysis by the data manager user. As noted above, the data manager user may be a data manager who analyzes the data item based on the issue description to generate a response to address the reported (potential) issue. In one or more embodiments, the response is added as an update to the annotation stored in the data repository (234) and a notification of the response is sent to the data reporting user.
The data repository (234) (and/or any of the data set, data item, annotation, etc. stored therein) may be a data store such as a database, a file system, one or more data structures (e.g., arrays, link lists, tables, hierarchical data structures, etc.) configured in a memory, an extensible markup language (XML) file, any other suitable medium for storing data, or any suitable combination thereof. The data repository (234) may be a device internal to the E&P computer system (208). Alternatively, the data repository (234) may be an external storage device operatively connected to the E&P computer system (208).
In one or more embodiments, the method depicted in
In one or more embodiments, the data item of an object (e.g., the wellbore) includes one or more of a wireframe representing the object (e.g., the wellbore), a pixel image representing the object (e.g., the wellbore), a test log associated with the object (e.g., the wellbore), and a report file associated with the object (e.g., the wellbore).
Initially, in Element 241, graphical elements are displayed in a first image (referred to as the issue reporting image) generated by a first instantiation of an exploration and production (E&P) tool. The first instantiation is referred to as an issue reporting instantiation. As noted above, models of subsurface structures (e.g., subterranean layers, hydrocarbon reservoirs and oil wells) in a field are often used in simulation to plan field productions and to accelerate and/or enhance production from wells. Seismic interpretation tools and seismic-to-simulation programs are examples of E&P tools. The issue reporting image is a component of a graphical user interface window of the E&P tool used by a first user (referred to as the issue reporting user). For example, the issue reporting user may use the issue reporting instantiation of the E&P tool to perform planning or simulation for an oilfield. In one or more embodiments, the displayed graphical elements correspond to objects (e.g., subterranean layers, hydrocarbon reservoirs and oil wells) in the field. Accordingly, the issue reporting image represents these objects in the field to the issue reporting user during the planning or simulation.
From time to time, the issue reporting user relies on his/her knowledge and experience to spot issues with the data items during the planning or simulation using the E&P tool. In Element 242, an annotation is received by the issue reporting instantiation of the E&P tool and from the issue reporting user. In one or more embodiments, the annotation is regarding an issue of a data item of a wellbore in the aforementioned objects in the field. Specifically, the annotation includes an issue description describing the issue of the data item of the wellbore. Example issue descriptions may relate to an error in the wellbore trajectory in the wireframe or pixel image, an error in the units for the test log that need to be corrected, or a version of the report file that needs to be validated as to whether the report file is up-to-date.
In one or more embodiments, the issue description is received from the issue reporting user via a user issue description window. In particular, the user issue description window is associated with the data item of the wellbore. Specifically, the user issue description window is displayed in response to the issue reporting user clicking on the graphical element. Accordingly, the issue reporting user may type text description of the issue into the user issue description window. In one or more embodiments, the user issue description window is superimposed on the issue reporting image. In one or more embodiments, the user issue description window is displayed separate from (e.g., adjacent to) the issue reporting image.
In one or more embodiments, the annotation further includes a type of the issue description. In other words, issue descriptions may be of different types. One example type of issue description provides information regarding the data item of the object, such as a note regarding a location of the wellbore. Another example type of issue description provides information regarding an action applied to the data item of the object, such as a note regarding a need to update the location of the wellbore. Yet another example type of issue description provides information regarding a problem with the data item of the object, such as a note regarding a suspected error in the location of the wellbore.
In one or more embodiments, the annotation is stored in a repository and accessible by multiple users of the E&P tool. For example, the annotation is accessible from the repository by the issue reporting user using the issue reporting instantiation of the E&P tool and by another user using a data manager instantiation of the E&P tool. In one or more embodiments, the issue reporting instantiation of the E&P tool and the data manager instantiation of the E&P tool execute on separate computer processors. For example, each instantiation of the E&P tool may execute on a different node of a computer network.
In Element 243, the annotation is tagged onto a graphical element representing the data item of the wellbore.
In Element 244, a notification is sent to a second user (referred to as the data manager user) regarding the annotation. In one or more embodiments, the data manager user is assigned as a data manager to maintain integrity of the data items related to the aforementioned objects in the field. Specifically, the data manager user may use the data manager instantiation of the E&P tool to view, address, and resolve reported issues from other users of the E&P tool.
In Element 245, a second image (referred to as the data manager image) is generated, in response to the notification and by the data manager instantiation of the E&P tool, for displaying to the data manager user. In particular, the data manager image is a component of a graphical user interface window of the E&P tool. Specifically, the data manager user uses this graphical user interface window of the E&P tool to view, or otherwise receive notifications of reported issues from other users of the E&P tool. In one or more embodiments, the data item of the wellbore and the issue description are displayed in the data manager image for analysis by the data manager user. For example, the data manager user analyzes the data item of the wellbore and the issue description in his/her assigned role as the data manager. In one or more embodiments, the data manager instantiation of the E&P tool is launched, automatically or manually in response to a computer node of the data manager user receiving the notification. In one or more embodiments, the data manager instantiation of the E&P tool is already executing when the notification is received by the computer node of the data manager user.
In one or more embodiments, the annotation further includes a configuration parameter (e.g., camera angle, colors, zoom level, image layer configuration, etc. of the view in a 3D spatial window when the annotation was captured) for the issue reporting instantiation of the E&P tool. In such embodiments, the data manager image may be generated as a reproduction of the issue reporting image. Said in other words, the data manager user may view objects in the field using the same camera angle, colors, zoom level, image layer configuration, etc. as the issue reporting user when the issue reporting user annotates the object at issue in the field. Specifically, the data manager image is generated based on the configuration parameter included in the annotation to reproduce the issue reporting image. Accordingly, the data manager user may analyze the data item of the wellbore and the issue description by viewing the same image as the issue reporting user who initially generated the annotation regarding the issue of the data item of the wellbore.
As noted above, by viewing the data manager image, the data manager user analyzes the data item of the wellbore and the issue description in his/her assigned role as the data manager. In Element 246, a first response (referred to as the data manager response) to the issue description is received from the data manager user by the data manager instantiation of the E&P tool. For example, the data manger response may include one or more of “I have corrected the trajectory and please review,” “I have checked the units of the log template and it seems to be correct, please check again,” or “I have updated the file in question to Oct. 23, 2011 version, which is the latest version.” Specifically, the data manager response to the issue description is received in response to displaying the data manager image to the data manager user. In one or more embodiments, the data manager response is added to the annotation and stored in the repository. Accordingly, the data manager response is accessible from the repository by multiple users, such as by the issue reporting user using the issue reporting instantiation of the E&P tool.
In Element 247, the issue reporting image and the data manager image are highlighted to indicate status of annotation, notification, and/or response. Specifically, graphical elements representing the annotation, notification, and/or response are highlighted to indicate their status. For example, the annotation, notification, and/or response may be displayed using different color, hatch pattern, line thickness, or other highlight means known to those skilled in the art. In one or more embodiments, the graphical element representing the data item of the wellbore is highlighted in the data manager image to indicate a notification status with respect to the issue description regarding the data item. In one or more embodiments, the data manager image includes multiple (e.g., 10, 20, 100, etc.) notifications from multiple (e.g., 10, 20, 100, etc.) users. In such embodiments, the issue reporting image may not display all graphical elements representing all objects in the field so as not to obscure viewing of the data manager user. For example, the multiple notification status may be displayed as dots over a map of the field, or simply in a list.
In one or more embodiments, in response to the data manager user viewing the notification status, a request is received from the data manager user to display the issue description such that the data manager user may analyze the reported issue. Accordingly, the data manager user may generate the data manager response. In those embodiments where the data manager image includes multiple (e.g., 10, 20, 100, etc.) notification status from multiple (e.g., 10, 20, 100, etc.) users, the data manager user may select one of the multiple notification status to display the details of the issue description and its corresponding object in the field, so as not to obscure viewing of the data manager user. As described above, the data manager user may view the details of the selected issue description and its corresponding object in the field using the same camera angle, colors, zoom level, image layer configuration, etc. as the particular user when the particular user initially generated the selected issue description.
In one or more embodiments, in response to receiving the data manager response, the data item of the wellbore is further highlighted in the data manager image to indicate a response status of the data item of the wellbore with respect to the data manager response.
In one or more embodiments, in response to receiving the data manager response, the graphical element is also highlighted in the issue reporting image and to indicate, to the issue reporting user, the response status of the data item of the wellbore with respect to the data manager response.
In Element 248, a second response (referred to as the issue reporting user response) is received from the issue reporting user and in response to the issue reporting user viewing the response status of the data item of the wellbore. For example, the issue reporting user response may acknowledge the data manager's response to the reported issue, confirm issue resolution by the data manger's response, or indicate that the data manager's response is insufficient to resolve the reported issue. In one or more embodiments, the issue description, the data manager response, and the issue reporting user response are combined into an issue reporting/resolution log that is stored in the repository. Accordingly, the issue reporting/resolution log of the data item of the wellbore is accessible from the repository by multiple users, e.g., by the issue reporting user using the issue reporting instantiation of the E&P tool and by the data manager user using the data manager instantiation of the E&P tool.
In Element 249, a second annotation is received by a third instantiation (e.g., another instantiation separate from the issue reporting instantiation and the data manager instantiation) of the E&P tool and from a third user (e.g., another user separate from the issue reporting user and the data manager user). For example, the second annotation may report another issue regarding the same data item. As described with respect to the annotation, the second annotation may trigger similar activities and interactions between the third user and the data manager. For example, a second notification may be sent to the data manager regarding the second annotation. As described above, the notification and the second notification are among the multiple notifications from multiple users of the E&P tool. In one or more embodiments, the response from the data manager and the resultant issue reporting/resolution log are also stored in the repository to be accessible by these multiple users.
FIGS. 3.1-3.7 depict various screenshots that further illustrate the user sourced data issue management in accordance with one or more embodiments. In one of more embodiments, the example depicted in FIGS. 3.1-3.7 is practiced using the E&P computer system (208) described above.
Once the geologist creates the annotation, a data manager receives a notification of this newly created note flagged as a data error, which is stored in a repository that several users share. The data manager clicks to view the error notification and the underlying note as he receives it. He can choose an option on the note to restore the camera angle, colors, zoom level, etc. of the image displayed in the user window (321) shown in
An example scenario of the interaction between the user reporting the data issue and the data manager responding to the reported issue (i.e., the issue description-1 (352) and the response to issue description-1 (353)) is described below.
A geologist is doing an interpretation and sees that there has to be an error in the well data. He creates a note saying “The Kelly Bushing value at this point is wrong. Please check the well file and correct if necessary.” The “point” mentioned in the note is represented through the point at which the note is added in the user window-1 (321). Said in other words, all the context is given through the spatial representation of the well and the note in user window-1 (321). He tags the note type as “Data error”. There is an underlying setting for all notes tagged as a “Data error” which identifies the person (i.e., a designated data manager for this note type) to whom a notification will appear when a note of this type is created. Different data managers may be designated to receive different types of notifications. The Geologist saves the note which automatically creates and stores a viewing parameter in the note (transparent to the user) which holds:
(i) Camera angle of the view in the spatial window when note was captured (in this case 3D window).
(ii) All objects turned on in the user window-1 (321) when the note was captured, not only the object the note is being added to. In this manner, the full context of the environment (in which the note was captured) is included.
(iii) Colors, zoom level, etc.
Once notified, the data administrator checks the source well file (e.g., a paper document or an electronic file regarding the well) to confirm the value for the Kelly Bushing. He then updates the value for the well as a response, and generates the response to issue description-1 (353). The data manager then opens the note and adds some text saying the error has been fixed and changes the tag from a “Data error” flag to a “Corrected” flag. He then sends the note back to the repository, and the geologist user who created the note gets an update that the error has been fixed. The geologist user can open the note to see the updated content of the note saying error has been corrected. Instead of correcting the error, the data manager can also reply with a question and maintain communication in context of the data objects through the note with the geologist user. As illustrated in
The geologist user is notified of the action taken. If the data is updated, the geologist user has the option to immediately update local data with the corrected data and view it immediately.
Embodiments of user sourced data issue management may be implemented on virtually any type of computer regardless of the platform being used. For instance, as shown in
Further, those skilled in the art will appreciate that one or more elements of the aforementioned computer system (400) may be located at a remote location and connected to the other elements over a network. Further, one or more embodiments may be implemented on a distributed system having a plurality of nodes, where each portion of the implementation may be located on a different node within the distributed system. In one or more embodiments, the node corresponds to a computer system. Alternatively, the node may correspond to a processor with associated physical memory. The node may alternatively correspond to a processor with shared memory and/or resources. Further, software instructions to perform one or more embodiments may be stored on a computer readable medium such as a compact disc (CD), a diskette, a tape, or any other computer readable storage device.
The systems and methods provided relate to the acquisition of hydrocarbons from an oilfield. It will be appreciated that the same systems and methods may be used for performing subsurface operations, such as mining, water retrieval, and acquisition of other underground fluids or other geomaterials from other fields. Further, portions of the systems and methods may be implemented as software, hardware, firmware, or combinations thereof.
While user sourced data issue management has been described with respect to a limited number of embodiments, those skilled in the art, having benefit of this disclosure, will appreciate that other embodiments may be devised which do not depart from the scope of user sourced data issue management as disclosed herein. Accordingly, the scope of user sourced data issue management should be limited only by the attached claims.
This application claims priority under 35 U.S.C. §119(e) to Provisional Patent Application No. 61/667,198, filed Jul. 2, 2012, with attorney docket number IS12.2446, and entitled “USER SOURCED DATA ISSUE ASSIGNMENT AND REPORTING/DATA MANAGEMENT DASHBOARD,” which is incorporated herein by reference in its entirety.
Number | Date | Country | |
---|---|---|---|
61667198 | Jul 2012 | US |