 Act and subsequent orders was that they did not require ILECs to collaborate in order to standardize the processes and interfaces new competitors would use in order to access their databases, submit orders and trouble tickets, and generally communicate with their OSSs. As a result, vendors began designing interconnection gateways that could meet the differing interface requirements of various ILECs on the one hand, and easily integrate to order and workflow managers on the other. The interface requirements to link with ILECs electronically are not trivial. They differ not only from ILEC to ILEC, but often from region to region within individual ILECs. "Do-all" interfaces do not exist. In most cases, IICs must communicate with several different interfaces in each region to perform certain functions: one kind of interface for accessing pre-order customer data, another for submitting orders, another for updating directory databases, another for number portability requests, and another for sending trouble tickets. Technologies vary among interfaces as well, including versions of EDI, CMIP, IIOP, HTTP, XML, and various proprietary protocols. Furthermore, the systems behind those interfaces require data to be delivered in diverse formats depending on the make and vintage of the system managing the data. Many of these systems, particularly customer and inventory management systems and databases, were built and installed years ago. They have been modified to support interconnection, but they still often require arcane and proprietary data formatting. Further, though various order forms are somewhat standardized, every ILEC has its own twists in terms of which fields contain what information and how that information is presented. For example, one ILEC could require an address to be listed as "123 South State Street" where another will accept "123 S. State St." Even such trivial variations can cause headaches when implementing interconnection systems and processes. Adding to the complexity, business processes vary from pr