METHOD AND SYSTEM FOR SHARING SERVICE GUIDE OR SERVICE GUIDE FRAGMENTS IN MOBILE BROADCAST SYSTEM

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates generally to a mobile broadcast system, and in particular, to a method and system for sharing a service guide or service guide fragments in a mobile broadcast system.

2. Description of the Related Art

The mobile communication market constantly faces the need for production of new services through recombination or integration of the existing technologies. Today, due to the development of communication and broadcast technologies, the conventional broadcast system or mobile communication system has reached the phase of providing broadcast services through portable terminals (mobile terminals) such as mobile phone, Personal Digital Assistant (PDA), and the like. Convergence of mobile communication service and Internet protocol (IP) is now the mainstream of the next generation mobile communication technology in harmony between the latent market needs, the increasing user demand for multimedia services, the strategy of the service providers for providing new services like the broadcast service in addition to the existing voice service, and the interests of the Information Technology (IT) companies that are reinforcing their mobile communication business to meet the user demands.

Open Mobile Alliance (OMA), which is a group for studying the standard for interworking between individual mobile solutions, mainly takes is a leader in establishing various application standards for mobile games, Internet services, and the like. In particular, OMA BAC (Brower and Content) BCAST (Mobile Broadcast Sub Working Group), one of the OMA working groups, is studying the technology for providing broadcast services using mobile terminals.

In the mobile broadcast system, a mobile terminal for receiving a broadcast service should receive service guide information including description information of the service itself, charging information for the service, and

information on a reception method of the service. The mobile terminal receives a corresponding service using the service guide information.

Although a description of the existing technology and the present invention will be made herein with reference to the OMA BCAST technology, which is one of the mobile broadcast technology standards, by way of example, this is not intended to limit the present invention.

FIG. 1 illustrates exemplary architecture of a general mobile broadcast system for delivering a service guide to a mobile terminal. Table 1 and Table 2 show interfaces used between logical entities of FIG. 1.

TABLE l

TABLE 2

Referring to FIG. 1, a Content Creation (CC) block 101 is a provider of a broadcast service (hereinafter referred to as "BCAST service"), and the BCAST service can include the conventional audio/video broadcast service, file (music file or data file) download service, and the like. With use of a Service Guide Content Creation Source (SGCCS) block 102, the Content Creation 101 delivers content information, capability information of a mobile terminal, user profile, content time information, etc., needed for the generation of a service guide for the BCAST service, to a Service Guide Application Source (SGAS) block 105 of a BCAST Service Application (BSA) block 104 via an SG-I interface 103, defined in Table 1.

The BCAST Service Application block 104 takes charge of generating

BCAST service data by processing data of BCAST service provided from the Content Creation block 101 into the form suitable for a BCAST network. In

addition, the BCAST Service Application block 104 takes charge of generating standardized metadata necessary for the mobile broadcast guide.

The SGAS block 105 delivers various sources necessary for the generation of a service guide, such as service/content detail information, schedule information, location information, etc., including the information provided from the SGCCS block 102, to a Service Guide Generation (SG-G) block 109 of a

BCAST Service Distribution/Adaptation block 108 via an SG-2 interface 106.

The BCAST Service Distribution/Adaptation (BSD/A) block 108 takes charge of setting up a bearer over which it will transmit the BCAST service data provided from the BCAST Service Application block 104, determining transmission schedules of the BCAST services, and generating mobile broadcast guide information. The BCAST Service Distribution/Adaptation block 108 is connected to a Broadcast Distribution System (BDS) 122, which is a network for transmitting BCAST service data, and an Interaction Network 123 supporting interaction communication.

A service guide generated by the SG-G block 109 is delivered to a Terminal (or mobile terminal) 119 via an SG Distribution (SG-D) block 110 and an SG-5 interface 117. If there is a need for delivering a service guide via the

BDS 122 or the Interaction Network 123 supporting interaction communication, or for matching with a corresponding system or network, the service guide generated by the SG-G block 109 is matched by a SG Adaptation (SG-A) block 111 and then delivered to the SG-D block 110 or delivered to a BDS Service

Distribution block 121 via an SG-Bl interface 116.

A BCAST Subscription Management (BSM) block 113 manages subscription information and service provisioning information for receipt of the BCAST service, and device information for a mobile terminal receiving the BCAST service. A Service Guide Subscription Source (SGSS) block 114 of the BCAST Subscription Management block 113 delivers sources, such as a subscription/provisioning related source, purchase information, promotional information, etc., needed for the generating of a service guide, to the SG-G block 109 for generating a service guide, via an SG-4 interface 115.

The BDS Service Distribution block 121 takes charge of distributing all received BCAST services through a broadcast channel or an interaction channel, and is an entity, the presence of which depends on a type of the BDS 122. The

BDS 122 is a network for transmitting the BCAST service, and can be a broadcast network for, for example, Digital Video Broadcasting - Handheld (DVB-H),

3GPP Multimedia Broadcast and Multicast Services (MBMS), and 3GPP2

Broadcast and Multicast Services (BCMCS). The Interaction Network 123 transmits the BCAST service on a point-to-point basis, or interactively exchanges control information and additional information related to the receipt of the BCAST service, and can be, for example, the existing cellular network.

The Terminal 119 is an apparatus capable of receiving the BCAST service, and has a function capable of connecting with the cellular network according to terminal capability. The Terminal 119, including a Service Guide Client (SG-C) 120, receives a service guide transmitted via the SG-5 interface 117, or receives a service guide transmitted via an SG-6 interface 118, and performs an appropriate operation for the BCAST service reception.

Table 3 to Table 5 give a brief description of major logical entities of FIG. 1 in the OMA BCAST service standard.

In the mobile broadcast system, the SG-G 109 receives information required to generate a service guide, provided from the CC 101, the BSA 104 and the BSM 113. With use of the provided information, the SG-G 109 generates a final service guide based on the data model described in FIG. 1.

SUMMARY OF THE INVENTION

Although information on the service guide is a response to a request for service guide-related information, sent from the mobile terminal to the BSM 113, the BSA 104 needs final information on the service guide generated in the same way by the BSM 113 and the BSA 104, as basic information for generation of charging information for the service. For this, there is a need for a method in which the BSD/A 108 can provide a service guide generated therein to the BSM 113 and the BSA 104, or the BSM 113 or the BSA 104 can send a request for

service guide information to the BSD/A 108 when necessary, and receive the corresponding information therefrom. In addition, in a service provisioning process, if the BSM 113 needs to provide service guide fragments for associated purchase information upon receipt of a request for price information from the mobile terminal, the BSM 113 should be able to directly transmit the corresponding information to the mobile terminal, or receive the corresponding information from the BSD/A 108 and transmit the received information to the mobile terminal.

An aspect of the present invention is to address at least the problems and/or disadvantages set forth above and to provide at least the advantages described below. Accordingly, an aspect of the present invention is to provide a service guide or service guide fragment sharing method and system for providing a service guide generated between network entities for a mobile broadcast service in a network, and providing information on a requested service guide, in a service guide that provides schedule information for service/content, access method information, price information, and purchase method information to the mobile terminal in a mobile broadcast system.

Another aspect of the present invention is to provide a service guide or service guide fragment sharing method and system for providing price information or its associated service guide information to a mobile terminal according to a sharing method between entities for a service guide in response to a price request for a purchase item from the mobile terminal.

According to one aspect of the present invention, there is provided a method for sharing a service guide or a service guide fragment in a mobile broadcast system supporting a mobile broadcast service. The method includes a Broadcast Service Provisioning Client Function (BSP-C) sending a request for the service guide or service guide fragment to a Broadcast Service Provisioning Management Function (BSP-M); and the BSP-M transmitting the service guide or service guide fragment to the BSP-C the BSP-M it has the service guide or service guide fragment.

According to another aspect of the present invention, there is provided a

system for sharing a service guide or a service guide fragment in a mobile broadcast system supporting a mobile broadcast service. The system includes a Broadcast Service Provisioning Client Function (BSP-C) for sending a request for the service guide or service guide fragment to a Broadcast Service Provisioning Management Function (BSP-M); and the BSP-M for transmitting the service guide or service guide fragment to the BSP-C if the BSP-M has the service guide or service guide fragment.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and other objects, features and advantages of the present invention will become more apparent from the following detailed description when taken in conjunction with the accompanying drawings in which:

FIG. 1 is a diagram illustrating an exemplary architecture of a general mobile broadcast system for delivering a service guide to a mobile terminal;

FIG. 2 is a diagram illustrating a data model for a service guide in OMA BCAST to which the present invention is applicable;

FIG. 3 is a diagram illustrating an interface and a protocol stack for transmitting a service guide in OMA BCAST according to the present invention; FIG. 4 is a signaling diagram illustrating a process of transmitting a service guide fragment in OMA BCAST according to the present invention;

FIG. 5 is a signaling diagram illustrating a process of requesting and transmitting a service guide fragment in OMA BCAST according to the present invention; FIG. 6 is a diagram illustrating a mechanism for Service Provisioning in

OMA BCAST to which the present invention is applicable;

FIG. 7 is a diagram illustrating a protocol stack used for transmitting service provisioning information in OMA BCAST according to the present invention; FIG. 8 is a signaling diagram for servicing provisioning in OMA BCAST according to the present invention;

FIG. 9 is a signaling diagram illustrating a process of delivering information in a BSM in response to a price request from a Terminal according to the present invention; and FIG. 10 is a signaling diagram illustrating a process of providing

informant delivered from a BSD/A to a Terminal by a BSM in response to a price request from the Terminal according to the present invention.

Throughout the drawings, the same drawing reference numerals will be understood to refer to the same elements, features and structures.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Preferred embodiments of the present invention will now be described in detail with reference to the annexed drawings. In the following description, a detailed description of known functions and configurations incorporated herein has been omitted for clarity and conciseness.

For convenience, a description of the present invention will be made herein using the names of the entities defined in the 3 ^rd Generation Partnership

Project (3 GPP), which is the asynchronous mobile communication standard, or defined in the BCAST of Open Mobile Alliance (OMA), which is a standard group for the application of a mobile terminal. However, the stated standards and entity names thereof are not intended to limit the scope of the present invention, and the present invention can be applied to any system having similar technical structures.

FIG. 2 is a diagram illustrating a format of a service guide used for receiving a broadcast service in a mobile broadcast system to which the present invention is applicable. FIG. 2 illustrates a data model of a service guide proposed for providing a broadcast service to a mobile terminal in the OMA BAC BCAST. One service guide includes fragments having their own usages, and the fragments are divided into 4 groups according to its usage.

Referring to FIG. 2, the service guide includes an Administrative Group

200 for providing upper configuration information of the entire service guide, a Provisioning Group 210 for providing subscription and purchase information of the service, a Core Group 220 for providing core information of the service guide, such as service/content and service schedule, and an Access Group 230 for providing access information for accessing the service/content. In FIG. 2, a solid

line connected between fragments illustrates a cross reference between the fragments.

The Administrative Group 200, a group for providing basic information needed by a Terminal to receive the service guide, includes a Service Guide

Delivery Descriptor (SGDD) 201. The Service Guide Delivery Descriptor 201 provides information on a delivery session where a Service Guide Delivery Unit

(SGDU) (not shown) containing fragments, which are unit elements constituting the service guide, is located, and provides an Entry Point used for receiving Grouping information for SGDU and a Notification message.

The Provisioning Group 210 is a group for providing charging information for service reception. The Provisioning Group 210 includes a Purchase Item fragment 21I ₅ a Purchase Data fragment 212, and a Purchase Channel fragment 213. The Purchase Item fragment 211 provides bundles of service, content and time to help the user subscribe to or purchase the corresponding purchase item. The Purchase Data fragment 212 includes detailed purchase and subscription information such as price information and promotion information for services or service bundles. The Purchase Channel fragment 213 provides access information for subscription or purchase.

The Core Group 220 is a group for providing information on the service itself. The Core Group 220 includes a Service fragment 221, a Schedule fragment 222, and a Content fragment 223. The Service fragment 221 is an upper aggregate of contents included in a broadcast service, as a core of the entire service guide, and provides service content, genre, service location information. The Schedule fragment 222 provides time information of the contents included in the service, such as Streaming, Downloading, etc. The Content fragment 223 provides detailed description, target user group, service area, and genre information for the broadcast content.

The Access Group 230 includes an Access fragment 231 and a Session

Description fragment 232. The Access fragment 231 provides access-related information to allow the user to access the service, and also provides delivery method and session information for the corresponding access session. The

Session Description fragment 232 can be included in the Access fragment 231, and can provide location information in a Uniform Resource Identifier (URI) format, so the Terminal can detect the corresponding Session Description information. In addition, the Session Description fragment 232 provides address information and codec information for the multimedia content existing in the corresponding session.

The service guide information can further include a Preview data fragment 241 and an Interactivity Data fragment 251 for providing previews and icons for the service/content, in addition to the above 4 groups. In this way, the unit elements constituting the service guide are referred to as 'fragments.'

The service guide of FIG. 2 is generated in the SG-G 109 of FIG. 1, and information (hereinafter provisioning information) of the Provisioning Group 210 is provided from the SGSS 114 of FIG. 1. Detailed information on the service guide can be defined through various elements and attributes for providing detailed contents and values based on the upper data model of FIG. 2. For convenience, although the detailed elements and attributes for each of the fragments of the service guide are not included herein, the detailed elements and attributes do not limit the present invention, and the present invention can be applied to all elements and attributes defined by the need for service guide provisioning for the mobile broadcast service.

FIG. 3 illustrates a protocol stack for transmitting the service guide data through the service guide structure and interface. FIG. 3 illustrates a protocol stack for delivering a service guide via an SG Interface 305 between an SG

Component A 303 and an SG Component B 304. Data is delivered through Hyper

Text Transfer Protocol (HTTP) based on Transfer Control Protocol/Internet

Protocol (TCP/IP), and provided through HTTP REQUEST and HTTP POST methods defined by HTTP. The SG Interface 305 can be the SG-2 106 and the

SG-4 115 defined in FIG. 1. In addition, the same can be applied to the SG-6 118, which is an interface between the SG-C 120 in the Terminal 119 and the SG-D

110 in the BSD/A 108. In FIG. 3, if the SG Interface 305 is an SG-2 306, the SG

Component A 303 is the SG-G 109 and the SG Component B 304 is the SGAS 105, and this can be inverted according to its application. If the SG Interface 305

is the SG-4 115, the SG Component A 303 is SG-G 109 and the SG Component B 304 is SGSS 114, and this can also be inverted according to its application. The protocol stack of HTTP/TCP/IP can be used even for data transmission via the SG-6 118.

Before a description of the present invention is given, a description will now be made of a message scheme table used in the present invention. In Table 6, Name indicates names of elements and attributes constituting the corresponding message. Type indicates a type (Element or Attribute) of the corresponding name. The elements have values El, E2, E3 and E4, wherein El indicates an upper element for the entire message, E2 indicates a sub-element of El, E3 indicates a sub-element of E2, and E4 indicates a sub-element of E3. An attribute is denoted by A, and A indicates an attribute of the corresponding element. For example, A under El indicates an attribute of El. Category is used for determining whether the corresponding element or attribute is mandatory or optional, and has an M value for the mandatory element or attribute, and an O value for the optional element or attribute. Cardinality indicates relationship between elements, and has values 0, 0..1, 1, 0..n, l..n. Herein, 0 means an optional relationship, 1 means mandatory relationship, and n means that a plurality of values can be used. For example, 0..n means that the corresponding message may have no element, or n elements. Description indicates meaning of the corresponding element or attribute, and Data Type indicates a data type for the corresponding element or attribute.

TABLE 6

FIG. 4 is a signaling diagram illustrating a process of transmitting a service guide fragment between the SG Component A 303 and the SG Component B 304 via the SG Interface 305 described in FIG. 3.In FIG. 4, the SG Component A 303 is the SG-G 109, and the SG Component B 304 is the SGAS 105 or the SGSS 114. In step 401, after completing generation of a service guide or service guide fragments, the SG Component A 303 delivers the corresponding

data to the SG Component B 304 through an HTTP POST message. In step 402, the SG Component B 304 responds to the receipt. The message of step 401 is shown in Table 7 A and Table 7B, and the message of step 402 is shown in Table 8.

TABLE 7A

TABLE 7B

TABLE 8

Name Typ Categoi Cardinal Description Data

FIG. 5 is a signaling diagram illustrating a process of transmitting a service guide fragment between the SG Component A and the SG Component B via the SG Interface described in FIG. 3. In FIG. 5, the SG Component A 303 is the SGAS 105 or the SGSS 114, and the SG Component B 304 is the SG-G 109. In step 501, the SG Component A 303 transmits a service guide or service guide fragments to the SG Component B 304 through an HTTP REQUEST message. If all the generated service guides or service guide fragments are requested, the SG Component A 303 transmits only SGRequestld and EntityAddress, and if fragments related to specific service, content, or Purchaseltem are requested, the SG Component A 303 delivers GlobalServiceld, GlobalContentld, or Purchaseltemld along with a request message. When the corresponding service guide or its fragments are requested, the SG Component B 304 responds to the corresponding request in step 502. If GlobalServiceld, GlobalContentld, or Purchaseltemld is included in the request message, the SG Component B 304 delivers all fragments related to the corresponding content along with a response message. Otherwise, the SG Component B 304 delivers all generated latest service guides or service guide fragments. The message of step 501 is shown in Table 9A and Table 9B, and the message of step 502 is shown in Table 1OA and Table 1OB.

TABLE 9A

Name Typ "ateg ;coi|Cardinal Description Data jty_ Type

TABLE 9B

TABLE 1OA

TABLE 1OB

With reference to FIGs. 6 to 10, a description will now be made of an exemplary method of requesting price information for a specific purchase item in a Terminal according to the present invention.

FIG. 6 is a diagram illustrating a mechanism for Service Provisioning in

OMA BCAST.

A Content Creation 605 is a provider of a broadcast service (BCAST service), and the BCAST service can include the conventional audio/video broadcast service, file (music file or data file) download service, and the like.

A BCAST Service Application 606 takes charge of generating BCAST service data by processing data of the BCAST service provided from the Content Creation 605 into a format appropriate for a BCAST network, and generating standardized metadata necessary for a mobile broadcast guide.

A BCAST Service Distribution/Adaptation 607 takes charge of setting up a bearer over which it will transmit the BCAST service data provided from the BCAST Service Application 606, determining a transmission schedule of the BCAST service, and generating a mobile broadcast guide. The BCAST Service Distribution/Adaptation 607 is connected to a Broadcast Distribution System (BDS) 611 capable of providing broadcast service, and an Interaction Network 610 supporting interaction communication.

A BCAST Subscription Management 608 manages subscription information and service provisioning information for receipt of the BCAST service, and device information for a terminal receiving the BCAST service. In particular, the BCAST Subscription Management 608 includes a Broadcast Service Provisioning Management Function (BSP-M) 601. The BSP-M 601 takes charge of providing subscription and purchase information for the service. The BSP-M 601 manages charging of the user according to the subscription information of the user, provides information thereon, and supports billing for the mobile broadcast service. The BSP-M 601 delivers a report in response to a subscription request and a charging and personal information request from the user, via an SP-7 603 or an SP-8 604.

A BDS Service Distribution 609 takes charge of distributing all received

BCAST services through a broadcast channel or an interaction channel, and is an entity, the presence of which depends on a type of the BDS 611. The BDS 611 is a network for transmitting the BCAST service, and can be a broadcast network for, for example, DVB-H, 3GPP MBMS, and 3GPP2 BCMCS.

The Interaction Network 610 transmits the BCAST service on a point-to- point basis, or interactively exchanges control information and additional information related to the receipt of the BCAST service, and can be, for example, the existing cellular network.

A Terminal 620 is a terminal capable of receiving the BCAST service, and has a function capable of connecting with the cellular network according to terminal capability. The Terminal 620 is assumed to be a terminal capable connecting with the cellular network.

A Broadcast Service Provisioning Client Function (BSP-C) 602 in the Terminal 620 manages reporting on subscription to and use of the BCAST service. The BSP-C 602 can extract provisioning information for subscription and purchase from the service guide, or can filter the information when necessary.

A Service Provisioning (SP) in FIG. 6 manages subscription to the BCAST service and purchase on the subscribed service. In addition, the SP can provide addition information related to the purchase. A description of the SP-7 603 and the SP-8 604 is given in Table 11.

TABLE I l

FIG. 7 illustrates a protocol stack used for requesting or delivering information via an SP-7 interface, which is an interaction channel for interaction communication between a BSP-M and a BSP-C. FIG. 7 shows a protocol stack for transmitting data via an SP-7 interface 705 between the BSP-C 602 and the BSP-M 601. A request or delivery of information is delivered through HTTP in TCP/IP, and an HTTP Request is used therefor. If needed, all other schemes supported by HTTP POST or HTTP can be used.

FIG. 8 is a signaling diagram for the case where a BSP-C sends a request for price information to a BSP-M. A user detects service/content/schedule from a service guide received at a Terminal, and determines a purchase item related thereto. In step 801, if no price information for the determined purchase item is included, the BSP-C 602 of the user sends a price request for the corresponding purchase item to the BSP-M 601, and a request message therefor is shown in Table 12A and Table 12B. In step 802, the BSP-M 601 delivers price information to the BSP-C 602 in response to the request. Only the price information can be simply provided, or the associated service guide fragments can be provided together. A response message of step 802 for the case where the BSP-M 601 sends price information in acceptance of the request message is shown in Table 13, and a response message for the case where the BSP-M 601 rejects the request message is shown in Table 14.

TABLE 12A

TABLE 12B

TABLE 13

TABLE 14

FIG. 9 is a signaling diagram illustrating a process of delivering a response message in response to the price request from a BSP-C in the case where a BSM has a service guide or service guide fragments. A request message in step

901 and a response message in step 904 are shown in Table 12A, Table 12B, Table 13, and Table 14 described in FIG. 8.

In step 901, the BSP-C 602 sends a price request for the purchase item to the BSP-M 601. ^" When only the price information Price_info is provided, the BSP-M 601 transmits the corresponding information to the BSP-C 602 in step 904. In the case where there is a need to transmit service guide fragments related to the purchase item to the Terminal, if the BSP-M 601 sends in step 902 an SG Fragment Request to the SGSS 114 in the BSM, the SGSS 114 delivers the associated SF Fragment to the BSP-M 601 in step 903. Then the BSP-M 601 delivers the corresponding fragments along with a response message in step 904.

FIG. 10 is a signaling diagram illustrating a process of sending a request for a corresponding fragment to a BSD/A and providing the corresponding information to a Terminal if a BSM has no information identical to the requested purchase item or has no service guide or service guide fragment in the case where there is a need to deliver an SG fragment in response to a price request.

A request message in step 1001 and a response message in step 1006 are shown in Table 12A, Table 12B, Table 13, and Table 14 described in FIG. 8, and messages of steps 1003 and 1004 are shown in Table 9A, Table 9B, Table 1OA and Table 1OB described in FIG. 6. The BSP-C 602 in the Terminal sends a price request to the BSP-M 601 in step 1001, and the BSP-M 601 sends an SG Fragment Request for the corresponding purchase item to the SGSS 114 in the same BSM in step 1002. If there is no content identical to Purchaseltemld for the requested purchase item or the SGSS does not have the latest service guide or service guide fragments, the SGSS 114 in the BSM sends an SG Fragment Request for the corresponding fragment to the SG-G 109 in step 1003. The SGSS 114 can request all of the generated service guides or service guide fragments. In step 1004, the SG-G 109 delivers the requested SG Fragment to the SGSS 114 in the BSM. The SGSS 114 in the BSM delivers the SG Fragment to the BSP-M 601 in step 1005, and finally provides the SG Fragment to the Terminal in step 1006.

As can be understood from the foregoing description, in order to generate a service guide in the mobile broadcast system, the SG-G receives sources necessary for the generation of the service guide from the CC, the BSA and the BSM. With use of the provided information, the SG-G generates the final service guide based on the data model described in FIG. 2. Although information on the service guide is a response to a request for service guide-related information, sent from the Terminal to the BSM, the BSA needs final information on the service guide generated in the same way by the BSM and the BSA, as basic information for generation of charging information for the service. For this, the BSD/A can provide a service guide generated therein to the BSM and the BSA, or the BSM or the BSA can send a request for service guide information to the BSD/A when • necessary, and receive the corresponding information therefrom.

In addition, in a service provisioning process, if the BSM needs to provide service guide fragments for associated purchase information upon receipt of a request for price information from the Terminal, the BSM can directly transmit the corresponding information to the Terminal, or receive the corresponding information provided from the BSD/A and transmit the received information to the Terminal.

While the invention has been shown and described with reference to a certain preferred embodiment thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the appended claims.