Facilitating a request for oilfield services. At least some of the illustrative embodiments are systems including a data store to receive a services request from a services requestor through a data transfer protocol interface and update an entry in the data store to indicate one or more parameters associated with the services request. The system also includes a monitor tool and a configuration file creator. The monitor tool detects an update to the data store and, if an update is detected, verifies the correctness of the services request that corresponds to the detected update. The configuration file creator detects an update to the data store and, if an update is detected, identifies an affected receiving system, determines a configuration file format for the affected receiving system, and generates a configuration file for the services request having the determined format for the affected receiving system.
|
8. A method, comprising:
receiving a request for services for a wellsite system through a data transfer protocol interface;
updating an entry in a data store to indicate one or more parameters associated with the services request;
detecting an update to the data store that corresponds to the request for services and, based on detecting the update, verifying the correctness of the request based on the services requested for the particular wellsite system;
when the verification of the correctness of the request fails, generating a notification indicating that the services request contains an error; and
when the verification of the correctness of the request is successful, generating a configuration file including a formatted request for each of the services according to a configuration file format associated with a receiving system of a vendor that provides that service.
12. A method, comprising:
receiving a request for services for a wellsite system through a data transfer protocol interface;
updating an entry in a data store to indicate one or more parameters associated with the services request;
detecting an update to the data store that corresponds to the request for services and, based on detecting the update, verifying the correctness of the request based on the services requested for the particular wellsite system;
upon successfully verifying the correctness of the request, identifying an affected receiving system of a vendor that provides one or more of the requested services;
determining a configuration file format for the affected receiving system; and
generating a configuration file including a formatted request for each of the one or more requested services provided by the vendor, in accordance with the configuration file format determined for the vendor's affected receiving system.
16. A computer system, comprising:
a processor; and
a memory coupled to the processor;
wherein the memory stores a program that, when executed by the processor, causes the processor to:
detect an update to an entry of a data store that corresponds to a request for services for a wellsite system, and, based on detecting the update, verify the correctness of the request based on the services requested for the particular wellsite system;
upon successful verification of the correctness of the request, identify an affected receiving system of a vendor that provides one or more of the requested services, wherein the detected update in the data store indicates one or more parameters associated with a services request;
determine a configuration file format for the affected receiving system; and
generate a configuration file including a formatted request for each of the one or more requested services provided by the vendor, in accordance with the configuration file format determined for the vendor's affected receiving system.
1. A system, comprising:
a data store to receive a request for services for a wellsite system from a services requestor through a data transfer protocol interface and update an entry in the data store to indicate one or more parameters associated with the services request;
a monitor tool to detect an update to the data store that corresponds to the request for services and, if an update is detected, to verify the correctness of the request based on the services requested for the particular wellsite system; and
a configuration file creator to detect an update to the data store that corresponds to the request for services and, if an update is detected, to identify an affected receiving system of a vendor that provides one or more of the services requested for the wellsite system, determine a configuration file format for the vendor's affected receiving system, and generate a configuration file including a formatted request for each of the one or more requested services provided by the vendor, in accordance with the configuration file format determined for the vendor's affected receiving system.
2. The system of
3. The system of
4. The system of
5. The system of
6. The system of
7. The system of
9. The method of
10. The method of
11. The method of
13. The method of
14. The method of
15. The method of
17. The computer system of
18. The computer system of
19. The computer system of
|
None.
Oilfield equipment or services may need to be ordered for use at a hydrocarbon wellsite during various stages of hydrocarbon operations such as drilling, completion, production and the like. In such a situation, an order is placed with a vendor, for example, by a phone call to the vendor or by emailing a spreadsheet to the vendor. The vendor then manually enters the order in the receiving system for processing.
However, the above procedure for ordering services and processing orders for services is prone to errors. For example, the requestor may order a component or tool that is incompatible with other components or tools currently being used at the rig site (e.g., incorrect dimensions, incorrect tool for a particular task). In such a case, no reliable safeguard exists to correct the erroneous order prior to sending the order to a vendor or receiver. As another example, the requestor may send a component order to a receiver that is incapable of processing or filling at least a portion of the order (e.g., certain components have been ordered from a receiver that does not or cannot provide those components). In such a case, a delay may result before the requestor is made aware of the erroneous order and can reorder the components from the proper receiver. As yet another example, the receiver may require that orders be formatted in a specific way or that certain information be provided by the requestor for certain components. The requestor may mistakenly use the wrong format or not include all the required information regarding a particular component, further causing confusion and delays. In the above situations, various mistakes may not be discovered until after the receiver has supplied the requestor with the ordered services, resulting in increased costs and long delays to various operations as the order is corrected.
For a detailed description of exemplary embodiments, reference will now be made to the accompanying drawings in which:
Certain terms are used throughout the following description and claims to refer to particular components. As one skilled in the art will appreciate, different companies may refer to a component by different names. This document does not intend to distinguish between components that differ in name but not function.
In the following discussion and in the claims, the terms “including” and “comprising” are used in an open-ended fashion, and thus should be interpreted to mean “including, but not limited to . . . .” Also, the term “couple” or “couples” is intended to mean either an indirect or direct connection. Thus, if a first device couples to a second device, that connection may be through a direct connection or through an indirect connection via other devices and connections.
As used herein, the terms “services” or “oilfield services” shall mean parts, services, or other purchasable items, particularly for use in oilfield operations such as drilling, completion, and production.
As used herein, the terms “requestor” or “requesting system” shall mean a party that requests oilfield services.
As used herein, the term “receiver” or “receiving system” shall mean a party that receives a request for oilfield services, regardless of whether that party actually processes and fills the request or passes the request onto a third party for processing and filling.
As used herein, the term “wellsite system” shall mean equipment installed or in use at a hydrocarbon wellsite, regardless of what stage of hydrocarbon extraction the equipment is used for. For example, drilling equipment, completion equipment, and production equipment are all part of the wellsite system.
The following discussion is directed to various embodiments of the invention. Although one or more of these embodiments may be preferred, the embodiments disclosed should not be interpreted, or otherwise used, as limiting the scope of the disclosure, including the claims. In addition, one skilled in the art will understand that the following description has broad application, and the discussion of any embodiment is meant only to be exemplary of that embodiment, and not intended to intimate that the scope of the disclosure, including the claims, is limited to that embodiment.
The various embodiments are directed to systems and related methods to facilitate a request for oilfield services using a data transfer protocol. More particularly, various embodiments are directed to receiving a services request from a services requestor that is transmitted using a data transfer protocol, such as the wellsite information transfer standard markup language (WITSML), which is a standard for transmitting technical data between organizations in the petroleum industry. The request is received at a data transfer protocol interface that passes the request to a data store, such as a database server, where the request is subsequently stored (e.g., as a new or updated database entry).
In some embodiments, a monitor tool monitors the data store for updates to existing entries and/or the addition of new entries, both of which may correspond to a request for services received from a services requestor. The monitor tool may review a new request for correctness using business rules that correspond to the particular data type of the request. For example, requests may enter the data store from different external systems, each of which may have a set data protocol. The monitor tool reviews the requests as they enter the data store to ensure that the requests conform to the data protocol of the associated external system. The monitor tool may then transform the request into a native format that a configuration file creator understands. This transformation may act as an audit for both the correctness and validity of the request, which is then processed and stored in the data store. Thus, regardless of the data format of requests when received, requests may be stored in the data store in a similar manner.
The monitor tool may also monitor the wellsite system to ensure that the new request corresponds to services that would actually be needed given the various components in use at the wellsite system. For example, the monitor tool compares units of measurement, sizes of components and the like to those which are in use at the wellsite system. In the event that the monitor tool determines that the new request is incorrect (e.g., for the reasons given above), the monitor tool generates a notification to the requestor that informs the requestor that one or more aspects of the request need to be corrected. The notification may be generated via, for example, a Short Message Service (SMS) text message, an e-mail, a voice mail or the like. The monitor tool may also generate an invoice for the requested services (or, alternately, cause an invoicing system to generate an invoice for the requested services) if the correctness of the new request is verified.
In accordance with various embodiments, a configuration file creator also monitors the data store for updates to existing entries and/or the addition of new entries, both of which may correspond to a request for services received from a requestor. Based on identifying a new request for services, the configuration file creator generates a configuration file for an appropriate vendor receiving system. Many receiving systems (e.g., oilfield service providers) may be associated with a single wellsite system, and thus the configuration file creator determines the appropriate receiving system(s) for a given new request. In some cases, configuration files for multiple receiving systems may be generated based on a single new request. The configuration file creator formats each configuration file to correspond to a format desired by the receiving system for that configuration file. For example, the configuration file creator maintains a lookup table that specifies a request format for each particular receiving system. Such a lookup table may be created or updated when new receiving systems are added. The configuration file creator may optionally review the configuration prior to being transmitted to the receiving system. In some embodiments, when the receiving system accesses the configuration file, the associated order is entered into an order processing system of the receiving system.
Additionally, as explained above, requests are stored in the data store in a similar manner regardless of the initial data format of the request, which enables the configuration file creator to create configuration files in the same manner regardless of the data format of the request. This allows for data aggregation to occur for all request formats, such that the data store is the main receiver of all requests, which simplifies processing these requests. The storage of data in the data store in an aggregated format allows for the system to become a request aggregator and receive data in many formats. This process is enabled by the monitor tool understand many different data formats and how to transform these formats into an aggregated format in which the data can be stored
Thus, in accordance with various embodiments, once a request for oilfield services is generated at a wellsite, the process of transmitting the request to the appropriate receiving service(s) is automated and the communication between a requestor and a receiver is simplified. Additionally, each request may be efficiently checked for correctness, which reduces expenditures and delays resulting from an incorrect service order.
Turning now to
The services requestor 102 may comprise a web browser, application, applet, mobile phone application or the like that a hydrocarbon wellsite operator (i.e., the requestor) accesses to request oilfield services. For example, the requestor may sign in to an application that allows them to fill in a form requesting various services. In some embodiments, the application form may limit the requestor to only services that are currently available from vendor receiving systems 112 that are coupled to the system 100. However, as will be explained in more detail below, additional vendor receiving systems 112 may be coupled to the system 100 as needed. Thus, if a particular requested service is unavailable, the requestor is made aware of a need to add additional vendor receiving systems 112 so that the requestor's request may be fulfilled.
The data transfer protocol interface 104 serves as a communication interface between the services requestor 102 and the data store 106. For example, data such as a services request may be transferred over the data transfer protocol interface 104 using WITSML, hypertext markup language (HTML), extensible markup language (XML) or the like. Further, various transfer protocols such as hypertext transfer protocol (HTTP) may be employed by the data transfer protocol interface 104. One skilled in the art appreciates that the above interfaces are exemplary, and any communication interface that enables the transmission of a request for oilfield services is within the scope of the present disclosure.
The data store 106 may comprise a database server, or other data storage device, that allows data received through the data transfer protocol interface 104 to be stored for monitoring, access or retrieval. The data store 106 may include a number of entries that correspond to requests for oilfield services received through the data transfer protocol interface 104. In some cases, when a new request is received through the data transfer protocol interface 104, a new entry is generated in the data store 106 that corresponds to the new request. In other cases, an entry in the data store 106 is updated (e.g., various fields of the entry may be altered based on data of the new request or a particular field may be altered to indicate that the entry corresponds to a new request) to contain data that corresponds to the new request.
In addition to containing entries corresponding to requests for oilfield services, the data store 106 may also store audit logs that track various activities/events such that, if necessary, a detailed description of events may be recovered. For example, the audit logs may include information such as where the request originated from, the initial data format of the request, where the original data file of the request is stored, when the request was received, whether notifications were sent as a result of receiving the request, whether a configuration file was created, what data was in the configuration file, or whether the configuration file was sent to an external system. Various events may be marked with a time and date stamp and a user ID may be captured when a receiving system accesses a configuration file or when a requesting system generates a request. User IDs may also be captured if an update is made to the data store along with the data changes that were made. User IDs may include a system ID or an individual's user ID who is logged onto the system 100 and invoking a change. In accordance with various embodiments, the audit logs facilitate subsequent forensic analysis, if necessary, to rebuild the process of events that led to an incident. For example, it may be possible to show how a request was created, where the request originated from, and how the request was subsequently handled.
The monitor tool 108 monitors the data store 106 (e.g., through periodic or continuous queries) to detect updates to existing entries or the addition of new entries, both of which may correspond to a request for services generated by the services requestor 102. When the monitor tool 108 detects a change to the data store 106 that corresponds with a new request for services, the monitor tool 108 reviews the new request for correctness using business rules that correspond to the particular data type of the request. For example, a new request may be received from the services requestor 102 in the data format that the services requestor 102 uses (e.g., a request for drilling services using a requestor's XML format). The request is then stored in the data store 106, which causes the monitor tool 108 to examine the request and transform the request into a native format, such that the request can be stored and understood by, for example, the configuration file creator 110. This transformation of the request from an external system format to a native request format enables all requests to be acted on in a similar manner. In some embodiments, the monitor tool 108 also monitors the wellsite system (not shown) to ensure that new requests are for services that would actually be needed considering the various components in use at the wellsite system. For example, in some embodiments, the monitor tool 108 compares units of measurement, sizes of components and the like to those which are in use at the wellsite system for correctness. If a requested component is incompatible with various components in use at the wellsite system, the new request may be erroneous.
In the event that the monitor tool 108 determines that the new request is incorrect or erroneous (e.g., for the reasons given above), the monitor tool 108 generates a notification to the services requestor 102 that informs the requestor 102 that one or more aspects of the request need to be corrected. The notification may be generated via, for example, a Short Message Service (SMS) text message, an e-mail, a voice mail or the like. In some cases, the monitor tool 108 also forwards the notification to the receiving system 112 or generates a different notification for the receiving system 112. If the monitor tool 108 verifies the correctness of the new request, the monitor tool 108 may also generate an invoice for the requested services (or, alternately, cause an invoicing system (not shown) to generate an invoice for the requested services).
Similar to the monitor tool 108, the configuration file creator 110 monitors the data store 106 (e.g., through periodic or continuous queries) to detect updates to existing entries or the addition of new entries, both of which may correspond to a request for services generated by the services requestor 102. When the configuration file creator 110 detects a change to the data store 106 that corresponds with a new request for services, the configuration file creator 110 determines whether the vendor receiving system 112 is affected by the new request. For example, if the request is for services that the receiving system 112 does not provide, then the receiving system 112 is not affected by the new request. On the other hand, if the request is for services that the receiving system 112 provides, then the receiving system 112 is affected by the new request. In some embodiments, multiple receiving systems are coupled to the system 100, and thus the configuration file creator 110, and a particular request may affect more than one receiving system.
If the configuration file creator 110 determines that the receiving system 112 is affected by the new request, the configuration file creator 110 determines a configuration file format for the receiving system (e.g., by accessing a look up table containing a preferred configuration file format for each receiving system coupled to the configuration file creator 110). The configuration file format specifies a request format that the receiving system 112 will be capable of processing as an order. The configuration file creator 110 formats the new request into an appropriate configuration file for the receiving system 112. In some cases, the receiving system 112 accesses the configuration file creator 110 (e.g., periodically or continuously) to retrieve the configuration file, while in other embodiments, the configuration file creator 110 transmits the configuration file to the receiving system. In some embodiments, the receiving system 112 retrieves or receives the configuration file only after being authenticated, for example by logging into a web application and/or presenting appropriate credentials to the configuration file creator 110. After receiving the configuration file, the receiving system 112 processes the order.
When the configuration file creator 110 determines the receiving systems affected by the new request 202, the configuration file creator 110 determines the appropriate configuration file format for each affected receiving system 112a, 112b. For example, the configuration file creator 110 accesses a configuration file format lookup table 111b that specifies the preferred configuration file format for each receiving system 112a, 112b. The configuration file creator 110 then creates an appropriately formatted configuration file 204a, 204b for each receiving system 112a, 112b. In this case, the configuration file 204a is formatted for the receiving system 112a and contains formatted requests for services A, B and D (i.e., the services provided by the receiving system 112a). Similarly, the configuration file 204b is formatted for the receiving system 112b and contains formatted requests for services C and E (i.e., the services provided by the receiving system 112b). In some embodiments, the receiving systems 112a, 112b access the configuration files 204a, 204b by logging into an application (e.g., a webpage provided through a standard web browser) and providing credentials to authenticate the identity of the receiving system 112a, 112b to prevent unauthorized access to the system 100. Subsequently, the receiving system 112a, 112b retrieving its associated configuration file 204a, 204b causes the request associated with the configuration file 204a, 204b to be processed by the receiving system 112a, 112b (e.g., is automatically entered into the order processing system of the receiving system 112a, 112b). The receiving system 112a, 112b may continually or periodically check the configuration file creator 110 for newly-generated configuration files for that receiving system.
Referring to
The method 300 continues in block 306 with verifying the correctness of the services request that corresponds to the detected update. In some embodiments, this step is carried out in response to detecting the update to the data store 106 (e.g., by the monitor tool 108). As explained above, the monitor tool 108 may detect that a new request has been added to the data store 106 by periodically or continually querying the data store 106. The monitor tool 108 may verify the correctness of the services request by using business rules that correspond to the particular data type of the request. For example, the services request is transformed from the data format that the services requestor 102 uses (e.g., a request for drilling services using a requestor's XML format) into a native format. This validates the request since, to correctly carry out the transformation, the data format of the original services request must be correct. Transforming the services request into the native format enables the request to be stored and understood by, for example, the data store 106 and the configuration file creator 110. In some embodiments, the monitor tool 108 monitors the wellsite system and verifies the correctness of the services request by comparing the requested services with the various components in use at the wellsite system. For example, the services request may be further validated by, for example, determining whether a proposed depth in is less than a proposed depth out, determining whether there are mnemonics for every curve request, determining whether there are one or more tools with each tool services request, determining whether each tool has an outer diameter associated with it, and the like. This validation helps to ensure that the services request is correct for the wellsite system. Certain requested services may be incompatible with the components or tools currently being used at the rig site (e.g., incorrect dimensions, incorrect tool for a particular task), and thus the services request may be at least partially erroneous. If the services request is verified, the request may be stored to the data store 106 in the native format.
If the correctness of the services request is not verified (block 308), the method 300 continues in block 310 with generating a notification indicating that the services request contains one or more errors. The monitor tool 108 that attempted to verify correctness may also generate the notification. The notification may be transmitted to the services requestor, potential receiving systems, or both. The monitor tool 108 may generate the notification via, for example, a Short Message Service (SMS) text message, an e-mail, a voice mail or the like.
If the correctness of the services request is verified (block 308), the method 300 continues in block 312 with generating an invoice for the services request. The monitor tool 108 that verified the services request may also generate the invoice or, alternately, the monitor tool 108 may cause an invoicing system to generate the invoice for the services request.
Turning now to
As explained above, the configuration file creator 110 may detect that a new request has been added to the data store 106 by periodically or continually querying the data store 106. The configuration file creator 110 identifies the affected receiving system by, for example, accessing a vendor reference table (such as vendor reference table 111a of
When an affected receiving system has been identified, the method 350 continues in block 358 with determining a configuration file format for the affected receiving system. The configuration file creator 110 determines a configuration file format by, for example, accessing a configuration file format lookup table (such as configuration file format lookup table 111b of
The method 350 then continues in block 362 with enabling the affected receiving system to access the configuration file. In some embodiments, the affected receiving system accesses the configuration file creator 110 (e.g., periodically or continuously) to retrieve the configuration file, while in other embodiments, the configuration file creator 110 transmits the configuration file to the receiving system. Credentials may be passed between the affected receiving system and the configuration file creator 110 to authenticate the retrieval or access of the configuration file for the affected receiving system.
The methods 300, 350 contain steps that may be performed in an order other than that which is shown in
The main memory 412 couples to the host bridge 414 through a memory bus 418. Thus, the host bridge 414 comprises a memory control unit that controls transactions to the main memory 412 by asserting control signals for memory accesses. In other embodiments, the main processor 410 directly implements a memory control unit, and the main memory 412 may couple directly to the main processor 410. The main memory 412 functions as the working memory for the main processor 410 and comprises a memory device or array of memory devices in which programs, instructions and data are stored. The main memory 412 may comprise any suitable type of memory such as dynamic random access memory (DRAM) or any of the various types of DRAM devices such as synchronous DRAM (SDRAM), extended data output DRAM (EDODRAM), or Rambus DRAM (RDRAM). The main memory 412 is an example of a non-transitory computer-readable medium storing programs and instructions, and other examples are disk drives and flash memory devices.
The illustrative computer system 400 also comprises a second bridge 428 that bridges the primary expansion bus 426 to various secondary expansion buses, such as a low pin count (LPC) bus 430 and peripheral components interconnect (PCI) bus 432. Various other secondary expansion buses may be supported by the bridge device 428. In accordance with some embodiments, the bridge device 428 comprises an Input/Output Controller Hub (ICH) manufactured by Intel Corporation, and thus the primary expansion bus 426 comprises a Hub-link bus, which is a proprietary bus of the Intel Corporation. However, computer system 400 is not limited to any particular chip set manufacturer, and thus bridge devices and expansion bus protocols from other manufacturers may be equivalently used.
Firmware hub 436 couples to the bridge device 428 by way of the LPC bus 430. The firmware hub 436 comprises read-only memory (ROM) which contains software programs executable by the main processor 410. The software programs comprise programs executed during and just after power on self tests (POST) procedures as well as memory reference code. The POST procedures and memory reference code perform various functions within the computer system before control of the computer system is turned over to the operating system.
The computer system 400 further comprises a network interface card (NIC) 438 illustratively coupled to the PCI bus 432. The NIC 438 acts as to couple the computer system 400 to a communication network, such the Internet.
Still referring to
The computer system 400 further comprises a graphics processing unit (GPU) 450 coupled to the host bridge 414 by way of bus 452, such as a PCI Express (PCI-E) bus or Advanced Graphics Processing (AGP) bus. Other bus systems, including after-developed bus systems, may be equivalently used. Moreover, the graphics processing unit 450 may alternatively couple to the primary expansion bus 426, or one of the secondary expansion buses (e.g., PCI bus 432). The graphics processing unit 450 couples to a display device 454 which may comprise any suitable electronic display device upon which any image or text can be displayed. The graphics processing unit 450 comprises an onboard processor 456, as well as onboard memory 458. The processor 456 may thus perform graphics processing, as commanded by the main processor 410. Moreover, the memory 458 may be significant, on the order of several hundred megabytes or more. Thus, once commanded by the main processor 410, the graphics processing unit 450 may perform significant calculations regarding graphics to be displayed on the display device, and ultimately display such graphics, without further input or assistance of the main processor 410.
It is noted that while theoretically possible to perform some of the above-described data aggregation, monitoring, processing, verification and the like by a human using only pencil and paper, the time measurements for human-based performance of such tasks may range from man-days to man-years, if not more. Thus, this paragraph shall serve as support for any claim limitation now existing, or later added, setting forth that the period of time to perform any task described herein less than the time required to perform the task by hand, less than half the time to perform the task by hand, and less than one quarter of the time to perform the task by hand, where “by hand” shall refer to performing the work using exclusively pencil and paper.
From the description provided herein, those skilled in the art are readily able to combine software created as described with appropriate general-purpose or special-purpose computer hardware to create a computer system and/or computer sub-components in accordance with the various embodiments, to create a computer system and/or computer sub-components for carrying out the methods of the various embodiments, and/or to create a non-transitory computer-readable storage medium (i.e., other than an signal traveling along a conductor or carrier wave) for storing a software program to implement the method aspects of the various embodiments.
The above discussion is meant to be illustrative of the principles and various embodiments of the present invention. Numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.
Tait, Colin A., Schave, Robert A.
Patent | Priority | Assignee | Title |
11363101, | Mar 08 2018 | Landmark Graphics Corporation | Using existing servers in a wellbore environment as data sources for streaming servers |
Patent | Priority | Assignee | Title |
6519568, | Jun 15 1999 | Schlumberger Technology Corporation | System and method for electronic data delivery |
6826492, | Apr 23 2001 | BANK OF AMERICA, N A , AS ADMINISTRATIVE AGENT | Method of managing a well file record at a well site |
20020065736, | |||
20020162010, | |||
20030074401, | |||
20040078281, | |||
20050049885, | |||
20080228503, | |||
20100042449, | |||
20110153726, | |||
JP2007226721, |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
Dec 20 2011 | Landmark Graphics Corporation | (assignment on the face of the patent) | / | |||
Jan 07 2013 | TAIT, COLIN A | Landmark Graphics Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 029574 | /0639 | |
Jan 07 2013 | SCHAVE, ROBERT A | Landmark Graphics Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 029574 | /0639 |
Date | Maintenance Fee Events |
Sep 04 2019 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
Jan 29 2024 | REM: Maintenance Fee Reminder Mailed. |
Jul 15 2024 | EXP: Patent Expired for Failure to Pay Maintenance Fees. |
Date | Maintenance Schedule |
Jun 07 2019 | 4 years fee payment window open |
Dec 07 2019 | 6 months grace period start (w surcharge) |
Jun 07 2020 | patent expiry (for year 4) |
Jun 07 2022 | 2 years to revive unintentionally abandoned end. (for year 4) |
Jun 07 2023 | 8 years fee payment window open |
Dec 07 2023 | 6 months grace period start (w surcharge) |
Jun 07 2024 | patent expiry (for year 8) |
Jun 07 2026 | 2 years to revive unintentionally abandoned end. (for year 8) |
Jun 07 2027 | 12 years fee payment window open |
Dec 07 2027 | 6 months grace period start (w surcharge) |
Jun 07 2028 | patent expiry (for year 12) |
Jun 07 2030 | 2 years to revive unintentionally abandoned end. (for year 12) |