The present invention is directed to a connector for joining fluid flow passegeways in a fluid handling system. The connector may be manually manipulated, without using any tools, to quickly and easily couple or decouple the mating connector components. Those components include a plug having a cylindrical plug wall and a radially extending flange, and a mating socket having a cylindrical socket wall and a pair of diametrically opposed retainers. The retainers each comprise an axially extending flexible lever spaced from the socket wall. The lever is joined to the socket wall at a base or proximal end and has a latch at its free or distal end. The lever is also joined to the socket wall by a fulcrum wall or living hinge positioned intermediate the ends of the lever. A split lock ring is disposed between the socket wall and each retainer and is movable from a position adjacent the base of each retainer to a position remote from the base of each retainer. The latch at the free end of each retainer is engageable with the plug flange to prevent disengagement of the plug and socket when the levers are in their free, unstressed state. However, the levers may be manually deflected or depressed at a flexing portion thereof when the lock ring is positioned adjacent the retainer bases to disengage each latch from the plug flange and thereby permit axial decoupling of the plug and socket.

The present invention relates to fluid handling systems and, more particularly, to so-called xe2x80x9cquick couplingxe2x80x9d connectors which are manually manipulated to effect connection or disconnection.
Fluid handling systems, particularly those using flexible tubing or hose in sizes {fraction (3/4 )} inch to 1 {fraction (1/2 )} inch I.D., typically include joints made with barbed connectors and hose secured with mechanical clamps such as worm type or deformable metal bands. These type of joints present problems for manufacturers who must maintain efficient, high volume production at the least cost, such as in the marine, appliance and specialized vehicle markets, including mobile washers and sprayers, as well as agricultural fertilizing and irrigation, to name a few. These joints can also be very difficult to service in the field if the joint is difficult to access with the necessary tool to remove the mechanical clamp.
For example, many recreational fishing boat manufacturers feature livewell/baitwell systems in their upper and mid-level boats. These systems typically use barbed fittings to connect hoses with various components, such as pumps, valves, aerator heads, thru-hull fittings, drain fittings, overflow fittings and the like. There may be two dozen or more hose connections in a single boat. Production line installation of these systems is time consuming, as each hose connection requires a clamp, typically a stainless steel worm type, which must be carefully positioned and properly tightened to assure a leak-tight joint. These clamps can be difficult to install in tight quarters, often typical of boat bilge areas, where much of the livewell system is located. Boat manufacturers leak test the system after installation and are often confronted with leaks at the hose connections. However, once installed, these systems are often covered by gas tanks and decking making access for service difficult, particularly if a tool, such as a screwdriver, must be used to remove the mechanical clamp. To partially solve this problem, many boat manufacturers have added the step of coating the barbed connector with silicone sealant before assembling the hose, in an effort to minimize the occurence of leaking hose joints. The silicone sealant, applied using a caulking gun type applicator, is sometimes used in excess which can restrict or completely block the opening in the hose or connector, a problem often not found until the boat is in service. Thus, boat manufacturers have had a long felt need for a system which would allow fast, reliable hose connections to be made on the production line and which would, in turn, reduce the number and duration of field repairs.
One of the important requirements for an improved hose connection system is that it must function with the standard hose that is currently used by boat manufacturers to plumb their livewell and bilge pump systems. This hose, which is widely available from a number of producers, is manufactured by co-extruding flexible PVC with a helical coil of rigid plastic integral within the hose wall. The resulting hose can accommodate a small radius bend without collapsing, yet is pliable so it can be easily routed around obstacles. The problem with this hose is that its outer wall is not smooth. The integral helical coil creates an outer surface unsuitable for sealing using an o-ring.
Another important requirement for an improved hose connection system is that it must be adaptable to existing barbed type fittings because not all system components may be readily changed. System components may be sourced from several manufacturers, so a new standard is not readily implementable.
Any improved hose connection system must not be so bulky as to cause interference with adjacent structure.
An improved hose connection system must be simple and inexpensive, and therefore practical for use on all system joints.
A review of available prior art quick coupling systems shows that none is suitable to meet these requirements. There is nothing that would allow existing barbed fittings to be quickly adapted to serve as quick coupling fittings and eliminate mechanical clamps. Also, there are no quick couplings that are both functional and simple enough to produce at a cost low enough to be widely used in volume production applications, such as those described above.
One available quick coupling is the push-to-connect type where a socket and retaining collet are incorporated onto the fluid system component to which the hose is to be attached. The hose is simply pushed into the socket to form a leak-tight, positively retained connection. Invariably, this type of quick coupling uses an o-ring seal between the inside wall of an outer sleeve and the outside wall surface of the tube. A reliable seal requires a tube with a smooth outer wall. In addition, the tubing must be sufficiently stiff to maintain contact with the o-ring without collapsing or distorting under the o-ring compression loading or under the tube stresses created if the tubing is bent abruptly at the connector exit plane. For reasons cited above, standard marine hose does not have either the smooth wall or the stiffness characteristics which would allow push-to-connect type of quick couplings to be used satisfactorily. In addition, push-to-connect quick couplings would be too expensive to incorporate on all of the different types of fluid system fittings and components used, and no fitting exists which would readily convert a barbed connector to a quick coupling fitting.
Other types of prior art quick couplings typically use a male insert portion which includes an o-ring seal member and a female socket portion which includes a smooth bore into which the male portion is inserted, creating a leak-tight seal. A locking and quick release latch system is generally incorporated into the female socket portion. These are the basic components of the subject quick coupling system also, but the special needs of the markets addressed, require novel features not heretofore available.
The present invention is directed to a connector for joining fluid flow passegeways in a fluid handling system. The connector may be manually manipulated, without using any tools, to quickly and easily couple or decouple the mating connector components. Those components include a plug having a cylindrical plug wall and a radially extending flange, and a mating socket having a cylindrical socket wall and a pair of diametrically opposed retainers. The retainers each comprise an axially extending flexible lever spaced from the socket wall. The lever is joined to the socket wall at a base or proximal end and has a latch at its free or distal end. The lever is also joined to the socket wall by a fulcrum wall or living hinge positioned intermediate the ends of the lever. A split lock ring is disposed between the socket wall and each retainer and is movable from a position adjacent the base of each retainer to a position remote from the base of each retainer. The latch at the free end of each retainer is engageable with the plug flange to prevent disengagement of the plug and socket when the levers are in their free, unstressed state. However, the levers may be manually deflected or depressed at a flexing portion thereof when the lock ring is positioned adjacent the retainer bases to disengage each latch from the plug flange and thereby permit axial decoupling of the plug and socket.
The present invention is also directed to a kit of fluid flow components for a marine fluid handling system that permits the efficacious production assembly and field maintenance of such systems. The kit includes segments of hose of the type previously described, one or more quick coupling connectors, and adaptors used to convert barbed marine fittings into a connector plug or change the barbed connector size to accommodate larger hose sizes.
It is therefore an object of the present invention to provide a quick coupling fluid handling connector that is manually manipulated, very cost effective to produce and install, and which occupies a minimal size envelope relative to the hoses and fittings used with the connector.
It is also an object of the invention to provide a locking element with the connector having a positive tactile feature to facilitate locking and unlocking of the connector when positioned out of sight.
Still another object of the invention is the provision of a kit of fluid handling components that permit the simple and cost effective assembly and maintenance of marine fluid handling systems.


A roof component adapted to be secured to a vehicle body which includes a pair of roof rails secured to a roof module such that the roof component forms a single piece component. The roof module, in one embodiment, includes a openings for receiving therethrough each outermost end of each roof rail. The outermost ends are secured to separate body pillars of the vehicle body. The roof rail is secured by welding, adhesives or by threaded fasteners to the roof module. The roof component thus forms a modular component of the vehicle and eliminates the need for attaching the roof rail components in a subsequent manufacturing step after the assembly of the vehicle is completed.

This application claims priority from German Application No. 100 51 512.6 filed Oct. 17, 2000 which is incorporated by reference herein.
The invention relates to a vehicle roof for passenger cars, station wagons, and similar motor vehicles.
In the automotive industry, the conventional design of motor vehicles is being changed more and more by the use of modules. Thus, car doors, instrument panels, and even lift gates are being produced with a modular design.
It is the objective of the invention to create another modular vehicle component that simplifies the manufacture of a motor vehicle.
To solve the above-described objective in accordance with the present invention, a vehicle roof for passenger cars, station wagons, and similar motor vehicles is proposed, which is comprised of a prefabricated roof module having at least a roof outer panel and a roof liner with roof rails arranged thereon.
The particular advantage of the present invention is the ability to incorporate the roof rails into a modular vehicle roof component.
With the modular roof of the present invention, the roof rails are preferably fastened on the roof module via a fastening system comprised of gluing, soldering, welding, screwing, or riveting. This has the advantage of eliminating the expense associated with designs for balancing tolerances between a roof panel and a recess within the vehicle roof.
As a particular advantage, it can moreover be provided that the roof rails on the side wall sections of the roof module extend in an approximately parallel alignment to each other above the roof outer panel and travel through openings in the roof module with lengthened end sections that form an angle or that are bent. The end sections of the roof rails can each be fastened to front body pillars, such as A-pillars, and rear body pillars, such as D-pillars. The lengthened end sections of the roof rails can each be fastened to the body pillars by an adhesive, solder, weld, screw, or similar connection. A particular advantage of this is that each roof rail in its entirety becomes a supporting part (i.e., structural part) of a motor vehicle, which reinforces the vehicle structure from the A-pillar to the C-pillar or D-pillar for example. The forces operating on the roof rail in operation are thereby passed directly into the vehicle frame and no longer across the roof into the side panels and into the vehicle frame as with present day roof rails. Extra and expensive reinforcements in the roof frame, as required in present day vehicles, can be partially or even completely eliminated. Another advantage is that the roof rails can better cope with the forces occurring in an accident involving rollover, so that their effect has a character similar to that of a roll bar. In regard to design, the roof rails can be provided with a surface finish on the visible portions (i.e., outside the vehicle structure) and function in the same character as conventional roof rails.
Another embodiment of the invention provides a roof module wherein the roof rails each comprise at least one center post arranged thereon. Additional reinforcements can be provided on each roof rail underneath the center posts, the reinforcements then being fastened to the roof frame or to the B-pillars or C-pillars of a motor vehicle body. This results in additional stiffening of the body and even more effectively transmits forces acting on the roof rails into the vehicle body.


A system is described in which call processing considers unique information about the call to better serve the caller and/or to enable the called party to more efficiently handle the call. In one embodiment, the unique information considered by the call processor is information indicator digits, which may indicate to the called party whether to accept the call before the voice portion of the call is initiated.

For many years the telephone system in general has known certain information about the phone from which a call has been made. For example, the telephone system has known what area code the call was placed from, the long distance carrier of the phone call, and even the approximate geographic location for a non-mobile phone based on the first six digits of the caller's number. This geographic information comes from the Local Exchange Routing Guide of Bell Core (LERG). However, in reality, the extent of information that has been collected to date about a calling party by the telephone system is quite low. For example, consider a home in which two or more people reside. If a call is placed from that home there is no way of knowing, as the call is handled by the telephone system, who is making the call. The only thing the telephone system may know is the approximate geographic location of a non-mobile phone and the calling number. The call may even have been placed by a visitor to the home.
The examples of lack of knowledge about the calling party quickly expand when one considers phone calls originating from institutions (for example, hotels, hospitals, airports, offices, prisons, universities, etc.). Then consider mobile phones, Personal Communication System (PCS) Service, air phones, maritime phones, and cellular phones, and it soon becomes apparent how little information is really known about a calling party. A public phone (such as a pay phone) in a lobby of an institution, provides little if any information about the calling party especially if the calling party is paying cash for the call.
Businesses have attempted to learn more about a calling party by asking questions of the calling party when their call is received. For example, a rental car company receives a call from a person wanting to rent a car. A live attendant for the rental car company will collect information about the call by asking several questions. Consider that the caller is likely to have rented a car previously from the same company. There should be no need to have to re-ask all of the same questions every time the same caller wants to rent a car. The present invention provides a solution to this and related problems of telecommunications.
The telephone system has evolved to include limited standard identification information about the calling phone (calling number and/or ANI) and the phone that was called (dialed number and/or DNIS). This information is primarily obtained from the telephone number from which the phone call was placed and the telephone number that was dialed by the caller. The telephone system has recognized these two numbers as basic information sources (for routing calls and for billing purposes for example) and has developed a system of standards for the data character fields these numbers are to fill.
The following background information will better explain these standards of limited phone identification used today by the current call processing systems, Interactive Voice Response Systems (IVR), and telephone systems of the United States and foreign countries.
Automatic Number Identification (ANI): ANI is a basic element of telephone calls transported throughout the public and private telephone networks. For the North America Numbering Plan (NANP), ANI is currently 10 digits long. ANI is used extensively for call routing, call billing, call tracking, and call identification.
Call routing has been based on ANI: area code routing based on the calling phone number is a common feature found in most long distance telephone networks. Based on the calling party number (ANI), the call can be routed and/or receive special treatment through use of databases, computer processors attached to and/or available to the telephone switches, the phone network, and equipment. Some Interexchange Carriers (IXC's) (such as AT&T, MCI, Sprint, etc.) and Local Exchange Companies (LEC's) (such as Ameritech) provide many enhanced forms of call routing usually based on the first 3 or more ANI digits.
Call routing based on the first 3 ANI digits is usually referred to as Area Code Routing. For example, if the calling number ANI was 614-847-6161, then Area Code Routing would consider the "614" part of the ANI and route the Ohio originated call using the "614" as the broad geographic data element to start the routing routines and calculations, based on the routing rules and other factors (time of day, day of week, percent allocation, etc.).
Call Routing based on more than the first 3 ANI digits allows for more geographic precision. Most ANI's have a geographic relationship. LERG gives the approximate longitude and latitude for the area code/exchange (as well as other data contained in the LERG) represented by the first 6 digits of the ANI. For example, for the calling number 614-847-6161 the "614-847" component has the geographic representation of Ohio and the metropolitan area of North Columbus/Worthington.
Area-Code-Exchange (NPA-NXX): The Area-Code-Exchange (NPA-NXX) routing ability gives even greater routing definition for the calling party (ANI). If a caller to an 800 number with an ANI of "614-847-6161" was in need of being connected to a towing service, then the geographically closest towing service might be identified to handle the towing job (at a shorter travel time and possible lower cost). Call routing can be based on the first 6 ANI digits or more. In fact, call routing can be extended to the first 7, 8, 9, or 10 digits and can even focus on a single calling telephone number. For example, calls originating from "614-847-6161" could be assigned to a specific travel department within a company. The caller with that ANI could be routed by the telephone network to a certain group that always handles that caller when be dials the local, 800, 500, or other number of a travel agency which routes calls using ANI. In this case, a specific ANI or set of ANI's is given a defined routing algorithm, or treatment, when recognized by a controlling network to route the call based on ANI or a group of ANI's.
ANI used as a billing number and geographic representation: ANI (as a term) is used, quite often interchangeably, for both the call originating billing number and/or the line number for the originating end of a call. For a location that has only one telephone line and one number (such as a residence with only one line), ANI usually refers to both the calling line and the billing number.
For a multi-line location (such as a business or residence with 2 or more lines), a PBX (Private Branch Exchange, a location's switch), or Centrex (where the local telephone company's switch or a separate switch acts as a PBX), the billing number or the lead number may be presented by the public telephone network as the ANI for the actual line used to place the call. For example, for a multi-line location such as a business, the public telephone network may present all the out-bound calls with the same ANI as the billing ANI even though multiple lines are in use, each with their own assigned line ANI and most of which are different than the billing ANI. The billing ANI is usually a good geographic representation of the non-mobile caller and usually represents the responsible (billing) party for the call (or one of them). However, in some cases, the billing ANI may not represent the actual ANI (or line number) of the call. In other cases, the billing ANI may not be presented and the line number ANI is presented instead. In any case, the line ANI or billing ANI do not define 100% of the time who is calling or why they are calling.
ANI is not always a good geographic representation: for example, when a call is routed through a private network before it reaches the "Public Telephone Network", the ANI may have no relationship with the physical location or approximate identity of the caller. If the caller at one location calls through a tie line or on a "Private Network" to another location and then access the Public Network from the second location, the call will probably be identified by an ANI based on the point at which the call entered the Public Telephone Network of the second location. For example, if a caller in Columbus, Ohio accesses a switch in New York City through a private network and then accesses dial tone to reach the Public Telephone Network through the New York City switch, the ANI for the call will most likely be a New York City ANI and the bill will be based on the New York City ANI (distance, identification, location, bill to, etc.)
Billing based on ANI: the caller's ANI (billing number and/or line number) is directly used for billing of calls dialed to:
900 access code type calls (e.g., 1-900-WEATHER);
500 access code type calls (e.g., 1-500 personal communications which currently can be billed to the caller);
10XXX access code type calls (e.g., 10288 where the caller dials an access code to reach a carrier and then dials a number);
1+ long distance number type calls per the caller's prescribed carrier; and
411, 1-555-1212 and many other access codes, methods and applications.
The caller's ANI is indirectly (and sometimes directly) used as part of the billing equation for calls where the Dialed Number pays for the call:
collect calls;
1-500 (depending on features);
1-700 (depending on features);
1-800 (e.g., 1-800-SCHERER); and
other access methods, codes and applications where the ANI is used, but the caller is not billed for the call (1-800-COLLECT, 1-800-CALL ATT, etc.).
For 1-800 access code calls, the caller's originating ANI is used to control some of the billing decisions—for example:
Intra-state;
Inter-state;
origination from a different country or island (e.g., calls from Canada);
time zones; and
mileage between calling parties and mileage bands.
1-800 access service was introduced by AT&T around 1967. From that time on, the caller's originating ANI became an integral part of the billing, routing, and call detail. 1-900, 411, and other pay-per-call numbers have also been around for 15 or more years and use the caller's originating ANI for part of the billing and routing equation.
Call tracking: ANI, along with Dialed Number including date and time, may be used as an approximation to track calls. However, if two callers dial from a PBX with a common billing ANI at the same time to the same multi-line location and both callers hang up at the same time, 2 call records will be created that look the same (even though there were 2 calls). Caller ANI, even with Dialed Number, date, time, and duration, do not provide exclusive call tracking, nor specific information about who was calling.
Presentation of network data and/or switch data: most advanced PBX's, ACDs (Automated Call Distributors), network transferring features (such as AT&T's Transfer Connect), PBX call transferring, and other forms of call switching and call transferring—preserve and transfer the caller's ANI (if possible) in the transfer of a call. This is done to preserve this piece of network provided data to the next call location, in an attempt to better serve the caller, and to help identify the caller for billing purposes. ANI preservation and passing has been a feature of Computer-Technology Integration to manage calls.
Caller ID (ANI): one of the most widespread and well-known uses of the caller's ANI is Caller ID (Caller Identification). The concept of Caller ID is to pass on to the recipient of the call the ANI of the caller before the call is answered. ANI has been a key component of ISDN (Integrated Services Digital Network) defined by the CCITT in the 1970's. The caller's ANI has traveled the phone network since the 1970's, if not earlier, in the form of two products:
1) 1-800 Access Type Service; and
2) Integrated Services Digital Network (ISDN Service).
Many companies, businesses, and individuals use ISDN, digital access, and/or Caller ID to get certain data elements of the call—one of which is caller ANI. Despite the benefits of ANI, caller ANI does not define the actual calling person. It does not indicate why the caller is calling.
The ANI of the caller is preserved and passed on as the call passes through the Public Telephone Network (and usually the Private Telephone Network, if possible). For example, the caller ANI may traverse through the LEC, IXC, CAP (Competitive Access Provider), PBX, ACD, Agent and so forth, so the final recipient receives the caller's ANI (i.e., caller ID).
Dialed Number: Dialed Number is the number that the caller dialed. Dialed Number, like ANI, must comply with the North America Numbering Plan (NANP) and the CCITT International Standards if the call is to originate and use the public switched telephone network of the U.S.A., Canada, North American (NANP) and international locations.
Examples are:
847-61617 digit dialing within the Local Access and TransportArea (LATA) where the area code is assumed to bethe same as the local area code (i.e.: 614). Withmultiple area codes for the same LATA coming intoexistence, 7 digit dialing will be phased out in someareas to 10 digit dialing.809-776-8500These are examples of 10 digit dialing geographic614-847-6161numbers. The 809-776 indicates a phone number inSt. Thomas, a U.S. Virgin Island.1-800-356-6161These are all examples of non-geographic routing1-900-932-8437numbers where the carrier and/or telephone network1-500-422-7537that has handled the call checks a database for the1-700-328-5000designated termination and associated routing.911These are examples of local special purpose Dialed411Numbers that again have specific routing and"0"geographic assumptions.011-44International Dialed Numbers that start with011-72international access, country code, and then thenumber (city, line, etc.) in the designated country.
For North America and the countries (including the U.S.A.) which are using the NANP, the public switched telephone network requires the Dialed Number to conform to the NANP. The Dialed Number is passed on to each successive party of the transport of the call (LEC-IXC-LEC-PBX-ACD-etc.) so the call can go through the telephone network ultimately being routed to the intended destination and for call accounting purposes.
Dialed Number and DNIS: the Dialed Number Identification Service (DNIS) is a shortened presentation form representing the Dialed Number. When the incoming call is terminated on digital access (and other forms of special access), the transport provider will usually offer DNIS to help identify what number was dialed for an incoming call, to the target telephone equipment and location. If the Dialed Number was, for example, 1-800-356-6161, then 6161 may be sent with the call presentation to reflect the 10 digit number dialed to give special treatment, routing, and information for the incoming call. The DNIS assigned could be from 1 to 10 digits or more (but usually not more than 10) and does not have to be the same as, or part of, the Dialed Number. In the above example, for the 800 number 1-800-356-6161, the DNIS could be, for example, "100" or "2" or the number itself.
Uses of DNIS: a common use of DNIS, besides representing the Dialed Number, is to aid in routing the calls within the telephone equipment so multiple different Dialed Numbers can share a common access trunk group and a common routing and still receive selective routing and unique audiotext greetings and selective handling. For example, within a business one 1-800 number may route to sales while a different 1-800 number for the same company routes to customer service, but calls to both numbers share the same or parts of the same trunk group to improve network access, switch and telephone equipment utilization.
Geographic Dialed Numbers: for the traditional geographic Dialed Numbers, such as 411, 911, 614-847-6161, the public switched network will attempt to deliver the call to a primary location, and if the local phone company and/or the IXC offers advanced features (Call Forward on Busy, Call Forwarding, Call Forward on Ring No Answer, and other possible static and dynamic delivery options), the call can have special "pre-designated routings" that are mostly static in nature.
Non-geographic Dialed Number: for non-geographic Dialed Numbers, such as 1-800, 1-900, 1-500 (PCS Follow Me), Cellular, and other non-geographic Dialed Numbers, the routing is controlled by the local access provider (LEC) accessing local databases to hand the call to the appropriate IXC (interexchange carrier) for providing inter-LATA (and intra-LATA) services and network routing. It utilizes the traditional public telephone network supplied ANI plus Dialed Number(s) as key data elements.
Network data and/or switch data: in both cases (geographic and non-geographic Dialed Numbers), the telephone network currently uses the public network supplied ANI and/or Dialed Number to determine call routing and special call treatment. Both the ANI and Dialed Numbers are fixed or static in nature, and are located in pre-designated fields of the actual call data. The USA Network and Many International Telephone Networks Support CCS7 Signaling.
Network data and/or switch data flows over a separate signaling network: a CCS7 (Common Channel Signaling 7) network consists of nodes called Signaling Points (SP's). Unique point codes for each network SP serve as the address for message distribution. A typical CCS7 network (as referenced in FIG. 7 herein), has three key nodes:
a Service Switching Point (SSP) capability at a central office provides CCS7 trunk signaling and/or queries a database to determine call routing;
Service Control Point (SCP) houses a database with the routing information used by network SSPs; and
a Signaling Transfer Point (STP) provides routing capabilities for CCS7 messages between CCS7 nodes.
The North American network is based on the basic "Mesh" structure. This structure is sometimes referred to as the "Quad" structure.
The hub of the network is STP pairs. These are two separate STP nodes operating together in a logical arrangement for redundancy.
The Signaling Links can be categorized into several types depending on the functions being performed. However, regardless of the function being performed, all Signaling Links operate in the same manner and have the same technical requirements.
A-Links (Access Links) are used to allow SSPs, SCPs and SPs to connect STP nodes. B-Links (Bridge Links) are used to join mated STP pairs to other mated STP pairs. These Links form the Quad structure, which will provide complete STP redundancy.
C-Links (Cross Links) are used to interconnect two STP nodes, in order to create an STP pair.
D-Links (Diagonal Links) interconnect primary and secondary Signal Transfer Point pairs. They provide communication between pairs and serve as an alternate routing path. A two level hierarchy is an extension of the basic mesh structure.
Some networks, typically those with high levels of sub-network traffic volume, may require another level of STP pairs. This Primary level of the STP architecture would also be a convenient place to bridge signaling boundaries (i.e. from one operating region to another). Most CCS7 nodes will be connected to the network at Secondary level STP pairs, except SCPs may be connected at the Primary level.
D-Links (Diagonal Links) are used to form connections between Secondary level mated STP pairs and Primary level mated STP pairs. This forms a Quad structure as well.
The CCS7, SS7, ISDN networks have predefined fields that contain:
1) The Dialed Number;
2) The Calling Number; and
3) Enhanced Data About the Call.
This network call data travels through the signaling network and represents the call and is presented to the call processor as the IAM (Initial Address Message) that defines the in-bound call to the call processor as part of ISDN, SS7 and CCS7 messages.
Private networks (on-net): "On Net", a Private Virtual Network term, represents a dialing plan that may or may not conform to the public switched network. AT&T in about 1985 introduced its Software Defined Network ("SDN"). MCI offers Virtual Private Network ("VPN") and others offer private dialing plans (e.g., switch to switch) that may not conform to the public network. These private telephone networks are under computer control with access to databases so as to receive calls over dedicated and special access lines or trunks and may use unique "Dialed Numbers" that may look like public Dialed Numbers. The private numbers are translated and routed differently (or can be routed the same) as the public network. For example, dialing 1-614-847-6161 on a private telephone network could ring to a phone in New York City (or anywhere) instead of the expected geographic location of the Columbus area in Ohio.
New network data and/or switch data elements—II digits: Information Indicator Digits, (also referred to as "II digits" "info-indicator digits", info-indicator (II) digits, and/or ANI Information Digit Codes) Bellcore Local Exchange Routing Guide, Dec. 1, 1995, Section 1, Page 168 (1.8 Automatic Number Identification (ANI) Information Digits Codes) are two-digit codes which precede the 7 or 10 digit number of the calling line (ANI) and inform the users of Network Information, the local LEC, Interexchange Carriers and others about the "type of line" that is originating the call, any special characteristics of the billing number (ANI) and/or certain classes of services. The two-digit II digit codes are part of the signaling protocol generated in equal access offices, which represents approximately 99% of all public U.S.A. calls by January 1996 (calls that originate by accessing a local phone company access line such as 1-800 type calls for the U.S.A.) (See FIG. 8). The II digits provided information about the ANI to aid in special routing and billing decisions regarding the ANI for those parties that may handle the call. II digits are designed to help define the "type" of line the ANI represents that is placing the call.
II digits are assigned by the NANP Administrator, at Bell Communications Research, Inc. (Bellcore) based on the telephone industry's needs to classify types of call origination for specific applications and needs. Some of the key II digits codes (00-99) are as follows:
Code 00—Plain Old Telephone Service (POTS)—non-coin service (not a pay phone), no special treatment required, (an unrestricted line).
Code 01—Multiparty Line (more than 2) the ANI does not really reflect the calling party, the party will need to be queried to determine the real calling number (ANI).
Code 02—ANI failure, the calling station has not been identified, the calling party will need to be queried to determine the real calling number (ANI).
Code 06—The call is coming from a multi-station location such as a hotel or motel and the IAM does not include the room number or account number of the caller, just the hotel/motel's ANI.
Code 07—Special Operator Handling Required—Calls from "07" require further operator screening to check to see if the call is allowed.
Code 20—When a call originates from a PBX and the main billing number is being sent as the ANI instead of the individual line number, II digit code 20 is sent with the ANI.
Code 23—Gateway type calls, where the ANI being sent does not represent the real calling line number, such as:                non-equal access end offices        0-800 (data base access)        Type 1 cellular calls (identifies the cellular system—not the caller)        calls from PBX trunks        calls from Centrex tie lines
Code 27—Coin or pay phone.
Code 29—Prison/inmate service—a confinement/detention facility; where calls must be screened for outward calling use and only collect billing is allowed. (ANI of caller can not be billed).
Code 30—Unassigned calling ANI.
Code 31—ANI that has been manually placed in trouble-busy state by Telco personnel.
Code 34—Telephone operator handled call, the call has been handled by an operator prior to reaching the called party. (For example: caller could not get through, required operator assistance).
Code 52—Outwats calls limited to certain zone(s) or band(s) on a special billing arrangement.
Code 60—The call is a TRS call that came from an unrestricted line and the ANI represents the billing line.
Code 61—Cellular/wireless PCS (Type 1)—The ANI represents the system, not the mobile directory (Caller's number) placing the call.
Code 62—Cellular/wireless PCS (Type 2)—The ANI does represent the caller's number (mobile directory number) placing the call, but the ANI does not represent the true geographic location of the caller (the caller is in their home zone (extended)).
Code 63—Cellular/wireless PCS (roaming)—The ANI identifies the mobile directory number (Calling Number) but not the geographic location (since the Caller is roaming).
Code 66—Call originated from a hotel/motel through use of a TRS provider.
Code 67—Call originated through use of a TRS provider and the ANI is restricted (such as a pay phone).
Code 70—ANI is that of a private pay station (coin and/or coinless), for example Public Access Line (PAL), Customer Owned Coin Operated Pay Telephone (COCOT), etc.
Code 93—Call originated (ANI) from a Virtual Network type of service (such as an IXC Calling Card), no real knowledge on the ANI.
As it can readily be seen, the II digits provide a wealth of knowledge about the calling line before, during, and after the call is answered. The II code of "00" represents an unrestricted home or small business (no PBX); while "29" represents a prison/inmate facility; while "27" is a coin/pay phone; etc.
The II digits are presented with the other network data and/or switch data through use of ISDN and/or SS7 signaling and/or can be provided as part of the inband data stream where available.
Database data about ANI, provided by the LERG: "NPA-NXX Type"—LERG reports on how and where the first 6 digits of the 10 digit North American Numbering Plan will be used and how it will be assigned by Bell Core. For example:
614-847-XXXX Represents Plain Old Telephone Service and/or business line with a geographic location of Columbus, Ohio.
614-755-XXXX Represents a pager exchange assigned to the Columbus, Ohio area (ignoring roaming).
614-361-XXXX Represents a cellular phone exchange assigned to the Columbus area (ignoring roaming).
The first 6 digits of the 10 digit NANP is usually referred to as an exchange, of which there are tens of thousands that have been assigned and/or issued by Bellcore as part of the NANP. Each exchange is also assigned a category or "NPA-NXX Type" such that all 10,000 numbers of the exchange have the same type usage.
In the pager example:
614-755-XXXX Represents an exchange or NPA-NXX (614-755) such that all 10,000 numbers having this prefix have been assigned for use as pagers.
The number ranges (614-755-0000 through 614-755-9999) or all 10,000 numbers are reserved for paging. If the exchange 614-755 is checked in the LERG "NXX Type" the value of "02" will be found "fully dedicated to paging".
Some more important examples of the "NXX Type" as defined by the LERG for entire exchanges are:
NXX-Type Code 00—Regular (Plain Old Telephone Service) POTS
NXX-Type Code 01—Mobile (Improved Mobile Telephone Service) IMTS
NXX-Type Code 02—Fully dedicated to paging
NXX-Type Code 04—Fully dedicated to cellular
NXX-Type Code 06—Maritime (Ship to shore, ship to ship)
NXX-Type Code 07—Air to ground
NXX-Type Code 10—Called party pays
NXX-Type Code 14—Special calling cards
NXX-Type Code 16—Originating only (can not receive calls)
NXX-Type Code 64—Personal Communications Services (PCS)
NXX-Type Code 88—Toll station—ring down
Many of the codes not listed above (but all are included in the attached LERG reference) are related to special mobile, paging and cellular and LATA limitations.
Given the first 6 digits of the calling number (ANI), and with the "NPA-NXX Type" classification provided by the LERG reference, the basic phone classification can quickly be determined, for example:
07=Air to ground
00=Plain business/residential
04=Dedicated to cellular
Sometimes the Dialed Number is all that is needed as the unique key to information: in Columbus, Ohio, since about 1985 the city trash collection has divided the city into 5 colors. When you move into a residence in Columbus, Ohio, you learn your trash color. Each trash color has a unique phone number to call to learn when your color's trash will be picked up. Because of snow, cold days (below zero), and holidays, the status of trash pickup changes daily. For a GOLD coded trash customer to find out the current status, they call 614-645-GOLD, and the PINK coded customers call 614-645-PINK, etc. The city of Columbus uses the dialed number to deliver current status of trash pickup, to the 5 subsets of the City's residences. (614-645-RUBY, PINK, GOLD, GRAY, NAVY).
LEC database about ANI on-line (LIDB): all of the local phone companies participate in a U.S.A. and Canadian database called LIDB (Line Information Database). LIDB represents virtually all phones in the U.S.A. and Canada for the reasons listed below. LIDB is really a collection of large LEC's (such as GTE), regional Bell operating companies (such as NYNEX) and a few centralized databases (such as ITN, etc.) who represent large groups of small phone companies. Companies such as Card-Tel provide coordinated access to these sub-sets of LIDB that provide a uniform access method and a uniform response back from the LIDB databases. The maximum response time to a LIDB inquiry is usually less than 1.0 seconds, and this inquiry is based on the "ANI" of the Caller and/or can also be the Dialed Number if the Dialed Number is also a POTS' (Plain Old Telephone Service) number.
A new feature of Caller ID in the December, 1995 time frame is the Caller's name as it would appear on the phone bill. The Caller's name along with the Caller's phone number (calling from number—ANI) is presented to the called number as part of Caller ID. The Caller's name is now available (on a national schedule) as a new feature of LIDB for all POTS lines and other lines (business, hotel, motel, residential, unlisted, pay phone, etc.) for all of the U.S.A. and Canada.
The Caller's name is available, even if the Caller's line (ANI) is unlisted or unpublished through the use of LIDB. Whether the Caller's name can be given out for display on a phone involves intrastate and interstate privacy laws and codes.
In many cases, ANI must be checked to restrict services: the ANI of the Caller also determines the Local Exchange Company (LEC) assigned to the ANI. Currently, exchanges are assigned to a LEC, usually in whole blocks, such that for the 10,000 number exchange 614-847-XXXX, all 10,000 numbers (614-847-0000 to 614-847-9999) are assigned to Ohio Bell of Ameritech for assignment to customers, routing to the end phone and/or device (phone, pager, PCS, etc.) and billing to the customer for usage changes (1+ calling, international calling, 411 calling, 1-900 calling, etc.).
To provide enhanced and/or standard local and long distance phone service, the ANI must be a billable ANI. Some normal ways of checking for a billable ANI are:
1) Based on LIDB, is the ANI valid?
2) Based on LIDB, is the ANI billable for the phone service (for example, will the ANI accept a collect call)? The call processor and/or switch and/or SCP must access several more types of databases:
a) Does the enhanced service provider (IXC) have a billing and collection agreement with this LEC for this ANI? This would come from a database maintained by the enhanced service provider, third party, IXC, etc.
b) Most business, as well as all pay phones have their "ANI" marked as "no collect calls". This is why an operator or an automated collect service (such as 1-800-collect) will tell you that the number you are calling will not accept "collect calls". The collect call service (automated or live operator) will check the actual LEC database (usually through the use of LIDB) and will receive an automated response code back that the "ANI" in question will not accept "collect calls".
c) Has the ANI, LEC calling card, other Bill-to number (credit card), other billing or account number, or grouping of account numbers (household, etc.) exceeded a service provider's velocity threshold for a time period ("X" dollars in "Y" time)?
d) Based on customer preference, prior customer service with a customer, and advanced features with a customer, a customer will not want to pay for this type of service for this time period (for example: no collect calls between midnight and 6:00 A.M.).
e) LIDB may also be used to validate a LEC calling card. LIDB provides on-line access to the calling card a LEC assigns to a POTS number. When you are away from your phone—you can bill calls to your (home) phone through use of your LEC calling card number. One of the means for validating this calling card number is through the on-line use of LIDB. For example: at a pay phone, if you wish to bill a phone call to your LEC calling card, the calling card you would enter at the pay phone would usually be validated through LIDB.
Future use of LIDB—one of the planned possible future uses of LIDB is who is "your local LEC". With the possibility of local number portability, LIDB could be used to determine who the local LEC is, to then determine who to route the call to for the last mile so the phone will ring.
ANI and Dialed Number part of billing: the billing and reporting function of telephone calls (such as MCI's "Friends and Family") revolve around databases, restrictions, rates, and relationships of data ($ dollars spent in a time period such as AT&T's "True Rewards"). Billing databases, usage, access, and restrictions have been part of the phone network since before the AT&T break up in 1984.
Prior Knowledge: prior knowledge is provided by ANI, for example, as it:
                a) Relates to billing and/or usage:                    i) Call velocity—the past number of calls over different periods of time (current day, week, month, 45 days, year, etc.):            ii) Dollars billed and billing velocity—the amount of billing transactions and dollars billed by the biller and/or service provider, bureau over different periods of time to be used to control credit decisions;            iii) Customer service and satisfaction—services the customer will not pay for or has a tendency to refund and/or the party who is assigned the ANI or billing identifier wants blocked.                        b) As it relates to prior calls and/or selections:                    i) Score or level attained in a program, event, promotion, or several programs;            ii) Level of proficiency or approximate knowledge attained based on ANI, Caller Identifier, or real identity (for example—based on Social Security Number).                        c) As a method to control entry into the particular program or restrict entry based on prior usage identity and performance.
The present invention brings certain telephone network data and/or switch data into the field of call processing in unique ways to provide a new call processing system and reveals several methods of using such data to better serve callers and to provide entities who rely on callers for business a better means in which to handle those callers. The present invention recognizes deficiencies in the use of calling/billing line number (ANI) to identify a caller and/or call. The use of calling/billing line number does not indicate the actual identity of the caller. Furthermore, the Dialed Number does not always indicate the specific purpose of the call and the best way to always answer the call. ANI and Dialed Number when used for call processing purposes, can provide misleading information.
The present invention is a new, unique, and much needed call processing system that provides substantial benefits over the traditional use of limited network data and/or switch data, such as Calling number (caller ID and/or ANI), Dialed Number (and/or DNIS), and Equipment type (touch tone, rotary, data). The known, limited network information can lead to less than accurate call limitation, statistical analysis and unique caller input format selection. As stated above, known use of telephone network data and/or switch data is very imprecise as to whom is calling. To limit the callers or select caller input templates and caller data request selections based on ANI, Dialed Number and/or equipment type will not give proper representation to businesses, schools, PBX's, and/or hotels with thousands of rooms, or cellular/PCS type 1, for example, where all 10,000 ANI's are the same and represent the system not the mobile ANI. For example, a TV ad offering a free breakfast for Father on Father's Day, shown in Orlando, Fla. would draw hundreds or even thousands of calls from the same small group of ANIs, in this case hotels. The call processor, using known methods, would be able to gather little valuable information based on ANI in this case.
Businesses, hotels, pay phones, PBX's, college phone systems, and other large gateways must be recognized and taken into account in any statistical analysis using ANI and Dialed Number as call limiters and call input selections. Fortunately, using call enhanced network data and/or switch data such as described herein, will change the caller input data selection and improve the call prompting and call handling by the call processing system and, in many cases eliminate or enhance the value of ANI.
Enhanced Data Available as Part of the Call Processing of the Present Invention
II Digitsinfo indicator digits - indicate phone type (pay phone,residence, business, prison, etc.NPA-NXXLERG Exchange Assignment - use classification forthe entire exchange (such as air to ground phones)LIBDLine Information Data Base (ANI for all NANP)caller's nameline restrictionline servicechange of ownershipPrivatebusiness vs. residenceDatabasestreet addressZIP codeSocial Security Number if residenceChange ofindicates the historical ANI data is no longerOwnershiprelevant due to change in ownershipLine Statusbased on the in-bound and out-bound linesavailable, the call handling logic will change.Call Controlbased on the resources available to the callprocessor.
A preferred embodiment of the present invention is useful in a multi-line, multi-protocol, multi-format, multi-input template call processing system. It utilizes the following:
a) Public and Private Phone Network supplied data and/or switched supplied data
b) Caller inputted data without prompting;
c) Caller prompted by the call processor to input data (information)—as the data may be needed one or multiple times which consist of multiple data items using multiple input formats and templates tailored based on stored data, network call information and data inputted;
d) Caller responding to the call processor requests, and inputting data as needed via touch tone, pulse dial, voice recognition, word spotting and/or voice prints, and electronic data in conjunction with voice (for example, data over voice, ADSI, etc.);
e) Proper call routing, as required, after the reason for the call and/or identity of the caller has been sufficiently determined;
f) Proper call identification as the call is passed on to the next call handling location—whether live and/or automated;
g) Access to stored data to control, identify, modify, route, rate, tax, compare and process the current call;
h) Updating stored data to currently (real time) and historically track what transpired, to provide information to other locations who may be still processing the current call, to provide future treatment of the same caller(s) or new caller(s) to the same Dialed Number and/or other Dialed Numbers, to aid and provide telephone related services, customer services, information to customers, to respond to customer queries and the sale and use of products and services, and other services and products and to aid and develop billing and reporting data;
i) To record words, inputs, opinions, feelings, desires, knowledge, experience, and other data from individual callers and/or a selection of callers that are processed as part of the call, once and multiple times, during and/or after the call, that could affect the next caller to same Dialed Number or a set of related Dialed Numbers and/or other Dialed Numbers, after all the calls over a period of time, (such as a statistical analysis), and on a rolling basis with each sub-set of callers to select a further set.
The present invention uses twelve (12) relatively new technologies and concepts individually and in combination with existing technologies to provide enhanced call processing. The twelve (12) new technologies for use in call processing environments, of the present invention, are:
1) II digits—info indicator digits that are now part of the SS7 (Signaling System 7) and/or ISDN (Integrated Services Digital Network) that provides ANI definition and restriction information for each phone call (see Bellcore documentation for II digits, SS7, and ISDN documentation) and define phone type—business, residence, pay phone, institution, local only, etc. for each call.
2) NPA-NXX type (reference LERG, the first 6 digits of all North American Numbering Plan (NANP)) defines ANI digits into a fixed classification (pagers, cellular phone, air to ground, POTS, etc.).
3) ADSI—Analog Display Serial Interface phones—and other data with voice over the same call (voice/data modems, ISDN, BRI, etc.) where data and voice coexist at the same time, or different times, over the same voice path of the call: this allows the call processor to create displays and soft key(s) on the caller's terminal (PC, ADSI phone, Kiosk, etc.) and to accept voice, soft keys (keys defined for just that display), data input-keyed data, screen touch data input, touch tone and voice recognition and voice print inputs; all intermixed at the caller's and call processor's discretion.
4) Line Information Data Base (LIDB): the local phone company's customer data base is on line and available for real time access (USA and Canada) to determine                a) Is the ANI valid (turned on);        b) Validate the LEC calling card PIN; and        c) Restricted ANI services (no collect call, for example).
5) Caller's Name—As an implementation of caller D, the billing name is available for the USA and Canada on a real time basis. This is a new special feature accessed through LIDB in the January, 1996 time frame.
6) Access to information, public and private databases that are keyed by a code contained in the call data (e.g.—ANI): one existing database has the phone type for example business versus residential for 85-90% of all phones in the USA and Canada, both listed and unlisted, with Zip code and street address, again on-line and indexed by ANI for 85-90% of the USA and Canada.
7) Access to information that is keyed to a unique number or reference that is not a part of ANI—such as Frequent Flyer Number, account number, customer specific keyed such as a ticket number, Social Security Number, credit card number, sweepstakes number, or other unique key for the service, product or event.
8) Biller's databases by ANI and/or NPA-NXX; whether the call can be billed by one or more billers.
9) Prior knowledge by ANI and/or other unique identifier such as credit card number as it:                a) Relates to billing and/or usage:                    i) Call velocity—the past number of calls over different periods of time (current day, week, month, 45 days, year, etc.);            ii) Dollars billed and billing velocity—the amount of billing transactions and dollars billed by the biller and/or service provider bureau over different periods of time to be used to control credit decisions;            iii) Customer service and satisfaction—services the customer will not pay for or has a tendency to refund and/or the party who is assigned the ANI or billing identifier wants blocked;                        b) As it relates to prior calls and/or selections:                    i) Score or level attained in a program, event, promotion, or several programs;            ii) Level of proficiency or approximate knowledge attained based on ANI, Caller Identifier, or real identity (for example—based on Social Security Number).                        c) As a method to control entry into the particular program or restrict entry based on prior usage identity and performance.
10) Change of ownership and/or status—using the ANI "Bill To" name (caller ID name): if not available then accessing other commercial Bill To" name and address databases or other information other than LIDB to use as the equivalent to caller's name and storing the "Caller ID" name for reference.
a) The system can be checked based on a date and/or "last called" usage and/or other frequency triggers to see if the "Bill To" or other stored data as required has changed for a given ANI. If the "Bill To" (or other data) has changed (through LIDB, presentation of the call, etc.), clearing out, resetting and/or modifying prior stored data to a history file (if so elected to save) and resetting or modifying the current stored data to reflect the new "Bill To" (or other data).
11) User-to-user data passed through the IAM (Initial Address Message) of the incoming call: "User-to-user" data is a field in the IAM (up to 255 characters long) that can pass additional data about the call with the presentation of the call.
12) "Line Status" and/or "Call Control" of the Call Processor: in-bound to and out-bound from "line Status" of the call processor is a major element in determining the actions of the call processor. As the in-bound lines to the call process reach 100% utilization (i.e. 190 lines in use of 200 available (95%) utilization), the call processor may start refusing, rejecting, and/or shedding in-bound calls based on priority. The same is true with out-bound lines from the call processor to other devices such as lines to a conference bridge, ACD, live agents, text to speech or other custom platforms, On Net-to-On Net, another switch or network. Based on the almost full status (up to 90+%) or full or even over-full; the call processor is holding callers in queue in excess of the capacity of the next destination of the call; the call processor may start to reject, refuse or shed in-bound calls based on the anticipated destination of the calls. Give the in-bound line status and/or out-bound line status of the call processor plus network data about pending calls, the call processor will use the "Line Status" and/or "Call Control" to change the acceptance and processing of calls.
The following three Bellcore documents are hereby incorporated by reference herein:
a. Local Exchange Routing Guide, general information, Section 1, pages 168-173, Dec. 1, 1995;
b. V&H Coordinates Data, Data Set/File Specifications, pages 1-5, Jan. 15, 1996, with Appendix A-1, pages 1-6, Jan. 15, 1996; and
c. Generic Requirements For Call Control Using ISDNUP, GR-317-CORE, Issue 1, February, 1994, Appendix A: SS7 Messages and Appendix B: SS7 Parameters.

Call processing system with call screening


Embodiments of the invention provides a method of and apparatus for itemizing web pages for display on a screen in a system comprising a server connected to the internet the server having storage for format data in respect of one or more accessible websites, the method comprising: at a client requesting from the server format data for a requested website; upon receipt of the format data, accessing the website; and when the website has been accessed itemizing locally the website in dependence on the format data.

In embodiments the invention relates to a system and method for itemising web pages for display on a screen such as a television screen or in some cases the screen of a computer monitor.
There is a need to present web pages on displays other than those for which they are primarily created. In other words, although web pages are primarily created for display on the monitor of a PC or other such computer, there are increasingly different ways in which people access web content via the internet. Examples include web Television or "Web TV" and personal digital assistants (PDAs).
Web pages are generally designed for viewing in a personal computer (PC) environment. Normally, in a PC environment, a mouse is used for navigation, the graphics are displayed on a high-resolution screen, and the user sits very close to the display.
However, in view of the increase in video content on websites, many users wish to view some websites on a television (TV) screen. Displaying a web page directly on a TV screen does not give good results because generally in a TV environment there is no mouse for navigation, the user sits further away from the TV as compared to the distance that he would typically sit from a computer monitor, and if the TV is a standard-definition one, only a small portion of the contents of a typical web page can fit on the screen.
It is clear that there is a need for reformatting and filtering web pages to make them more suitable for displaying on a TV screen and also more suitable for easy navigation with a TV remote control instead of a mouse. A number of systems exist for the reformatting of web pages to make them suitable for viewing on a TV screen but they have a number of significant drawbacks.
U.S. Pat. No. 7,143,347 discloses a method and apparatus for reformatting of content for display on interactive television. Requests from a user (client) for web pages go through a proxy server. The proxy server fetches the content (HTML pages, images, etc.) and translates them to "compiled objects" that are suitable for the client set top box (STB). Instead of the actual content data, the compiled objects are sent back to the STB. A special object interpreter in the STB interprets and displays the compiled objects. There is also a caching mechanism to prevent compiling previously compiled websites again.
However, Web content is not presented as part of the native user interface (UI) of the client STB, so it is not easy to navigate. Furthermore, with each request the proxy has to be informed about the STB model to be able to identify the content format it supports, and the proxy must support all variations in the STBs. All of the translation and reformatting is done at the proxy, so the processing requirements of the proxy are high. Last, if the proxy is down, none of the clients can connect to the Internet and are therefore unable to access web page content via their STBs.
U.S. Pat. No. 6,226,642 discloses a method and apparatus by which modification of content of internet web pages is achieved for television display. Again, requests for web pages go through a proxy server. The proxy server fetches the content and modifies the HTML into a format compatible with the display requirements of the client STB. The reformatted HTML is then sent back to the STB. A browser in the STB interprets and displays the reformatted HTML.
There are some significant disadvantages with this system. For example, with each request the proxy has to be informed about the STB model to be able to identify the content format it supports, and the proxy must support all variations in the STBs. All of the translation is done at the proxy, so the processing requirements are high and so if the proxy is down, none of the clients can connect to the Internet.
An example is described in this patent in which the proxy is on the client. However, there are problems with this arrangement too in that the HTML document is still displayed by a web browser on the client STB, and not as an integral part of the native GUI, so navigation is still difficult. Furthermore, since the proxy component resides on the client, ongoing changes in the world-wide web standards cannot be easily addressed. That is, when some web-sites change their contents and use some new HTML features, the client may not be able to display those web-sites until the proxy software on the clients are updated.
It can be seen then that although attempts have been made to address the general problem of reformatting of web pages and web based content for display on a television systems and the like, most of the available prior art makes use of a proxy for translating HTML content into a format that better suits a TV-type display device. With such an approach, the improvements are limited to making the text bigger, fitting the whole page width onto the screen and adjusting the colour of certain items to reduce flickering. The general usability of world-wide web content on a set-top box that has a remote-control for navigation inside the GUI is not improved.
Furthermore, most of the prior art requires a dedicated proxy for performing the translations, and this increases dependency of the whole system on a single server. Moreover, in most of the prior art, the proxy that performs the translations must know the display capabilities of each set-top box client model, and translate web content accordingly. This further increases system complexity.
According to a first aspect of an embodiment of the invention, there is provided a method of itemising web pages for display on a screen in a system comprising a server connected to the internet the server having storage for format data in respect of one or more accessible websites, the method comprising: at a client requesting from the server format data for a requested website; upon receipt of the format data, accessing the website; and when the website has been accessed itemising locally the website in dependence on the format data.
Preferably, web content is presented as part of the native UI of the client STB, so it is easy and intuitive to navigate for a user.
Whereas most of the prior art requires a dedicated proxy for performing the translations, and this increases dependency of the whole system on a single server in the present invention, the "translation" is preferably performed locally to the client in dependence on the format file and so takes advantage of the processing power of the clients.
In an embodiment, the relevant information is extracted from web-pages at the client and displayed as part of a client's native user interface according to instructions received from a central format description server.
Today's STBs are continuously getting more powerful in terms of their processing capabilities. In contrast to most prior art systems that reformat the content on a special dedicated server, the present system reformats the content on the client. Therefore, processing power requirements for the server can be reduced and no special handling is necessary on the server to format content for different models of receivers. Different clients can reformat web pages differently to suit their native UIs, based on a single web-site format description provided by the format server.
The client is able to process the web data locally and uses this information, based on the received format file, to present web-page contents as a list of items that are easy-to-navigate on its native graphic user interface. The use of a format data server also means that plural users can connect to it so that when a website's format changes the modifications to the format file need only be loaded up to the format server and not to each individual user.
According to a second aspect of an embodiment of the invention, there is provided a system for itemising web pages for display, the system comprising: a server for storing format data indicative of the format of one or more websites; and, one or more clients connectable to the server, at least one of the clients being arranged to request format data of one of the websites from the server, wherein upon receipt of the request, the server is arranged to provide to the requesting client the format data indicative of the format of the respective website, the client being arranged locally to access the website and use the format data to itemise content from the website for display.
According to a third aspect of an embodiment of the invention, there is provided a client for connection to the internet for the itemising of web pages for display, the client comprising: a processor arranged, upon activation by a user, to request and to receive from a format server format details in respect of a requested website; and memory for storage of the format details, the client being configured and arranged to access the website and, itemise locally the contents for display in dependence on the format details.
In one embodiment, the client comprises an HTML itemiser for itemising locally the received website. Preferably, the client comprises an XML parser for parsing received XML documents. Primarily the XML parser is for parsing the SFD and SLS files which are XML documents.
In one embodiment the client the HTML itemiser includes a scripting engine for interpreting commands and a regular expression engine for searching for textual patterns within received HTML code of a website. This enables the data from a received website to be easily itemised.
The client can be embodied in any suitable form in which a user is enabled to access internet content and display it on a display such as a television display. Examples include but are not limited to a stand-alone Set Top Box dedicated for viewing web pages on a television, functionality embedded into a digital television receiver Set Top Box, a digital television recorder, a television receiver, and a personal computer.
As is currently the case, clients such as set top boxes for accessing television include native GUIs. Preferably, the client for use with the present system, is configured and arranged to display itemised websites using the native graphic user interface, i.e. the GUI used already to display conventional television images. This is the GUI that is also used to browse program information and configure the client's settings, etc.
Preferably, the client is arranged, prior to requesting the format details, on activation by a user to request from the format server a list of available websites in respect of which format details are stored by the format server.
In an embodiment, there is provided a method of itemising web pages for display on a screen in a system comprising a server connected to the internet the server having a list of websites that it is able to provide to a client and a database for storing for each of the accessible websites a format file indicative of the format of the respective website, the method comprising: at a client requesting from the said server the format file for a requested website; upon receipt of the format file, accessing the website; and when the website has been accessed itemising the website to extract data from the website in dependence on the format file.
In an embodiment, there is provided a client for use in a system according to the second aspect of the invention, the client comprising: a processor arranged, upon activation by a user, to request and to receive from a format server format details for a website the processor being configured, to access the website and display the contents in accordance with the format details obtained.
Referring to FIG. 1, an example is shown of a system for itemising web pages. Typically the system would include a plurality of client set-top boxes (STBs) 200 connected to the internet 130 although, for clarity and simplicity, in the example shown, only a single STB 200 is included.
The system comprises a server 140, referred to hereinafter as a format server, including a Database 150, the server being connected to the internet. A TV-type monitor 270 is provided and is used for displaying the output of the client STB. The client STB may be a stand-alone STB dedicated for viewing web pages on a TV, or its functionality may be embedded into a digital TV receiver STB, a digital TV recorder, a TV receiver, or a personal computer. By way of non-limiting example only, henceforth, the description will be in respect of a stand-alone STB.
Through the internet, all standard websites such as www.youtube.com and www.bbc.co.uk 170 are accessible by the client STB 200.
The client includes a graphic user interface GUI which displays the STB's resident application in addition to displaying content from the internet. As used herein, the term "native GUI" refers to this application user interface that is embedded in the client STB. In the art, the native GUI of a device in a TV environment usually allows the user to perform tasks such as setting the user's preferences, browsing program information, changing the channel, or watching recorded material. The system of FIG. 1 is able to display the contents of a web page as part of the client STB's native GUI, so that online content appears as a natural continuation of the native GUI. One particular advantage of this is that navigation becomes technically simplified and as simple to the user as possible. Indeed, the navigation is no different from the navigation of television channels, to which the user is well used.
Most web pages are cluttered with images, animations, and significant amounts of text. As explained above, this makes them unsuitable for displaying on a TV screen. The system of FIG. 1 is capable of extracting only the relevant information from web pages to make them more suitable for display on a TV screen.
The layout of visual elements on a web page is determined by its HTML code. The system of FIG. 1 utilises the concept of data or a file, referred to hereinafter as an "SFD file" (site description file), which contains details about the format of data inside a website's HTML pages. The format server includes or is associated with a Database 150, in which is stored and maintained a plurality of SFD files 160. Each SFD file contains the description or format data of one specific website. The STB 200 uses these SFD files 160 to itemize HTML pages and present them as part of its native GUI.
The client STB 200 includes a web navigator component 210. In a preferred embodiment, the web navigator includes an XML Parser 220 for reading XML-type documents, and an HTML Itemiser 240 for identifying the details of each "interesting" item on a web-page. The HTML Itemiser may typically consist of a Scripting Engine 250 for interpreting commands in a particular scripting language such as Perl, and a Regular Expression Engine 260 for searching for textual patterns directly inside an HTML page. Sources of such engines are known to those skilled in the art.
Referring to FIG. 1, when the user wishes to browse the internet on the client STB, the STB requests from the format server 140 a list of websites known to it and therefore accessible to the STB using the system. These "websites known to the format server" are the websites for which there exist corresponding SFD files in the Database 150, and the list is carried in a Server List (SLS) document.
By way of example, the SFD files may be composed and maintained by the format server administrator, or they may be uploaded to the format server by individual users of the system. Also, the list of known websites may be categorized and returned in a multi-level fashion. For example, an SLS composed of categories of web servers may be returned first, such as entertainment or sports, and when a sub-category is requested another SLS file containing the actual list of websites in that category may be returned. As a minimum, the items of the returned SLS document must include the website name and the universal resource locator (URL) of the website SFD. Optionally, it may include additional details such as a textual description of the website and the URL of a thumbnail image representing the website.
Thus, the server functions as a portal site which contains a list of websites, such as media content sites, on the internet. It does not simply provide a webpage with links, but rather by providing format data to a client STB it "teaches" an STB how to interpret a webpage and display it in its native GUI. The server is only responsible for directing STBs to where the content is on the internet and the STB then connects directly on the internet to media sites such as www.youtube.com.
When the STB 200 receives a list of known web servers from the format server 140, it presents them to the user in its native GUI. The user then selects a website from among those that are presented, and as a result, the STB 200 requests the SFD file corresponding to the selected website from the format server 140.
In response, the format server 140 sends the requested SFD File from the SFD Database 150 to the STB 200.
The SFD file contains the URL for the "entry point" into the requested web server, and also contains methods for classifying and itemising the web pages on the server. In this context, "classifying" a web page means determining which one of the two possible classes a page belongs to: directory-class pages, or terminal-class pages. Terminal-class pages contain media content such as textual information, video streams, or audio streams. Terminal-type pages do not have any sub-pages. Directory-class pages contain a list of sub-elements. Sub-elements of directory-class pages may be other directory-class pages or terminal-class pages.
Itemising a web page means extracting only the relevant links from the web page and determining the properties of those links such as their name, URL and type. As a result, the STB has a list of "items" representing the links on the web page.
The STB 200 reads the received SFD file, and identifies the URL for the "entry point" page on the website. The STB 200 directly requests this page from the web server 160, and when the page is received, the STB itemises it according to the data in the website's SFD file. The preferred method of displaying the items extracted from a web page's HTML is presenting them to the user as a list. The user is preferably allowed to select an item from the list, and if another directory-type page is selected, the same procedure is repeated to itemise the new page.
If the user selects a terminal-type page, the relevant content on the page is extracted according to the information in the web-site's SFD file and the content displayed as part of the STB's native GUI. For example, if the terminal-page is a textual page containing a news article, only the article is extracted and displayed by the GUI. In another example, where a terminal page contains a link to a streaming video source, provided that a corresponding video decoder is present on the STB, the video is played in accordance with the native GUI.
If a website supports a search mechanism, e.g. www.google.com, the details of this search mechanism are also included in the website's SFD file. When the user enters a keyword that he/she wishes to search at a particular website on the client, the client requests the website's SFD file from the format server. As a minimum, the SFD file contains the search URL, the character-escaping method (i.e. how to convert characters that are not allowed in URLs into characters or strings of characters that are allowed), the HTTP submission method (POST or GET) for the website and the format of the results page. Using this information, the client submits the search string to the website's search engine, and the website in due course returns a page containing the results. The client STB itemises the results based on the information in the SFD file, and presents them to the user via the TV display.
The system also allows the data transmission between the format server and the STB to be reduced if the STB downloads the SFD files periodically, for example once every day. The details of this process will become clear with the description of a preferred embodiment below.
There need be no computer or PC involved other than the inherent processing capability of the STB itself. The user interface of the STB is entirely separate from the server and so all STB models are therefore able to display the acquired video content as part of their native GUIs. The user, when viewing internet based video material on a television connected to the STB, does not have to navigate through cumbersome web pages using a remote control that was never designed for the control of web content. Furthermore, since the video material is not streamed from the server, but rather is still obtained from the websites' own host servers, the format server cost and complexity can be kept to a minimum.
In addition, the format server only sends instructions to clients as to how to interpret other websites and does not send HTML pages with links. Therefore, the server does not even have to be up and running all the time because clients can operate without it so long as they have already received the necessary format data.
FIG. 5 shows a schematic representation of an example of the main menu 1110 of an STB's native GUI. In this preferred example, the STB's native GUI includes a "Websites" button 1130, or something similar. Upon activation by a user, this button opens the "Websites" screen, which is a user's entry point to Web content accessible from the STB. Alternatively, the "Websites" button may exist at a different location in the STB's menu structure, or the STB's remote control may have a dedicated button to the same effect.
By way of example only, consider an embodiment of the system incorporated into a Digital Video Recorder (DVR) STB. A DVR records TV programs in digital format and stores them on a hard-drive, to be viewed later by the user. The native GUI in most DVR products includes a screen where all the recorded material can be viewed by the user. FIG. 6 shows schematic representation of a typical native GUI for listing recorded programs on a DVR. As it is an aim of the present system to present web content as a natural continuation of the native GUI, the "Websites" screen of the preferred embodiment is similar to the screens that are part of the native GUI.
One such embodiment is presented in FIG. 7 where the "look and feel" of the "Websites" page is very similar to that of the native GUI, and particularly to the "Recordings Library" screen shown in FIG. 6.
Referring to FIG. 2, a method for receiving and displaying the contents of a website on a TV screen is now described. By selecting the "Websites" button on the Main Menu, the user requests to enter the "Websites" screen at step 310. In response, at step 320 the STB queries the "index.sls" file from the format server. The URL of the SLS server is preferably put into the STB's persistent memory during production, which, for exemplary purposes only, will be taken to be "http://sfdserver.com". In a preferred embodiment, the format server maintains the SLS and SFD documents in an XML-like format.
An example of the SLS document index.sls is provided in FIG. 3. The SLS document may either contain links to other SLS documents which have further sub-elements, or it may contain links to SFD documents which contain data about the format of one particular website. The example SLS document in FIG. 3 contains two items 2120, 2130 that represent links to other SLS documents, and one item 2140 that represents a direct link to the SFD file for the BBC News website. In a preferred embodiment, as a minimum, the SLS file contains the name and the file link for each item. Other details that may optionally be included for an item in an SLS file include, the item's textual description and a thumbnail icon image for visual representation of the item. The SLS file also contains a header with a version number 2110 that may be used to test the compatibility of a particular client with a particular SLS file received from a format server.
Upon receiving the SLS file, at step 330 in FIG. 2 the STB parses it to extract the details of each item and presents the items as part of the STB's native GUI. The embodiment with the exemplary GUI presented in FIGS. 5 and 6 may display these details as shown in FIG. 7. All the items present in the SLS file are put under the header "Links" 1170 on the screen, and when a particular item is highlighted by the user, the item's details are also displayed. By way of example only, when the highlighted item 1180 in FIG. 7 is "BBC News", the STB will get the item details from entry 2140 in the SLS file in FIG. 3. The corresponding name, description and thumbnail icon are displayed respectively at 1150, 1160 and 1190 on the screen, as shown in FIG. 7.
Referring again to FIG. 2, when the user selects a particular item at step 340, and if the selected item points to a SFD-type item at step 350, this triggers at step 360 a request from the STB to the format server for the SFD file associated with the selected item. For example, when the user selects the "BBC News" item on the GUI in FIG. 7, the corresponding file is identified from the item entry 2140 in the SLS file, which is "bbc.sfd". The STB then requests the "bbc.sfd" file from the format server.
An example of an SFD file that may be returned by the format server is shown in FIG. 4. Like the SLS file in FIG. 3, the SFD file also contains a header 2210 with a version number, for testing the STB's compatibility with it. The SFD file includes the general properties of the website 2220, and the format details 2230, 2240 of each different page type on a website. As a minimum, the general properties 2220 of the website preferably include the URL of the start-page for the website and the format-id of the start-page.
Next, at step 370 the STB extracts the start-page of the selected website from the SFD file, and, at step 380, requests it directly from the website. Thus, there is no direct involvement of the format server in providing the HTML code of the requested website, which is instead received over the internet directly from the appropriate web server. For example, according to the SFD file presented in FIG. 4, the start-page that will be requested is
http://news.bbc.co.uk/1/hi/video_and_audio/default.stm
The SFD file also indicates 2220 that the format-id of the start-page is "top-level-dir". Hence, when the STB receives the HTML for the start-page, the page-format details for "top-level-dir" 2240 are used to itemise the page.
Any web page is categorized into either a directory-class page or a terminal-class page. For each directory-class page and a terminal-class page, there is at least one corresponding page-format entry in the SFD file. The example SFD file in FIG. 4 only provides a single directory-class entry 2230, and a single terminal-class entry 2240, but other websites may well have more.
The number of such entries in a web-site's SFD file is equal to the number of different types of page formats that the client STBs will be allowed to browse. Each page-format entry in the SFD file must have a different ID associated with it. Using the "top-level-dir" page-format details 2240, the STB itemises the received web page by using "finders". A finder may be a regular-expression to be used with a regular expression engine 260 embedded into the STB, or it may be a downloadable script, such as a perl script, that may be run with a scripting engine 250 embedded in the STB. The page-format sections in the SFD file include details about the finders for various item properties.
For directory-class web-pages, the properties that must be "found" for each item are an item's name, the URL of its target page, the class of its target page and the ID of its target page. For terminal-class web-pages, the properties that are preferably "found" for each item are the item's name, the URL of the media content that the web-page includes, and the format of the media content. Other item properties, such as the URL of a thumbnail image or the item description are optional.
Returning to FIG. 2, after step 380, the page-class of the BBC News web page will be identified as "directory" at step 390. Using the finders shown in the page-format section 2230 for "top-level-dir", the STB itemises the returned BBC News web page by extracting the name, description and target-URL of each "interesting" item at steps 400 and 410. The results are then displayed on the screen in a format similar to other screens of the native GUI at step 420. Afterwards, the GUI waits for user input at step 450.
FIG. 8 shows a schematic representation of a "Websites screen". In one particular exemplary embodiment, the list of items 1230 is displayed under the "Link" header 1220, and the details of each item, such as the name 1200, thumbnail-image 1210 and description 1240 are displayed at the top of the screen in accordance with the native GUI of this particular client.
Referring to FIG. 2, when there is any input from the user, step 450 is followed by the test in step 460. If the user wishes to quit the Web-Sites screen, the Web-Sites screen is closed at step 490. Otherwise, step 460 is followed by step 470 and another test is made for whether or not the user wishes to continue with content from the same web-site that the user is currently browsing. If the user wishes to continue with content from another web-site, if it's not already stored at the client the new web-site's SFD file must be obtained from the format server first, so the procedure will be repeated from step 360.
At step 470 of FIG. 2, if the user wishes to continue with content from the same web-site, for example by selecting any of the items shown on the exemplary GUI in FIG. 8, the URL of the selected target item is determined at step 480, and this target-URL is requested directly from a web server at 380, from which point on the same process will be repeated.
Referring to FIG. 4, the page-format section 2230 indicates to the STB that the ID for the target page is "terminal-content". Therefore, when the requested page arrives at step 390 of FIG. 2, execution continues from step 430. At this step, the page-format section 2240 in FIG. 4 corresponding to the ID "terminal-content" is used by the STB to itemise the new page. Since the new page is a terminal page, it does not contain sub-items, but it includes media content, such as textual or audio-visual data. A preferred embodiment displays this media content in accordance with the client's native GUI. For example, a DVR STB that displays recorded video material in full-screen mode, may also display video content coming from a web-server in full-screen mode.
Thus a method, apparatus and system is provided that makes it simpler to navigate through content in web pages on a set-top box connected to a TV screen. In practice the entire system will include a plurality of client set-top box devices connected to the internet, and a format server, also connected to the internet. The format server contains information about how data is laid out on HTML pages making up specific websites. By obtaining the format details of pages on a web-site from the format server, a set-top box "learns" how to "itemise" the individual data and link objects on a web-site's web-pages.
The set-top box processes the web data locally and uses this information to present web-page contents, preferably as a list of items, in a way that is easy-to-navigate on its native GUI. The use of a format data server also means that plural users can connect to it so that when a website's format changes the modifications to the SFD file need only be loaded up to the format server and not to each individual user.
Embodiments of the present invention have been described with particular reference to the examples illustrated. However, it will be appreciated that variations and modifications may be made to the examples described within the scope of the present invention.

Systems and methods for itemising web pages for display on a screen