Field of the Invention

The present invention relates to a system and method for improving telecommunications network performance and efficiency when providing 3-D services over the air.

Background of the Invention

As new generations of telecommunication technology are developed, greater data transmission speeds become possible. When data demand relates to general browsing, streaming services and even video conferencing, especially over a cellular network using 4G and 5G technology, then there is usually little need for buffering and throttling of bandwidth allowance to take place even in relatively crowded cells.

However, when much higher bandwidth services requiring a real-time response, such as extended reality, XR, services are encountered then even under optimum conditions, network contention, latency and bandwidth requirements may put a strain on the network and reduce the usability and enjoyability of such services. This can also have an effect on other subscriber devices at the same cell site, especially under high data demand.

Therefore, there is required a method and system that overcomes these problems.

Summary of the Invention

A device, such as a VR or XR headset, for example, can be used to provide a three-dimensional (3D) experience to a user. Data for such an experience can originate or be processed at a remote site, such as a server or platform. The device and server communicate over a network, such as a telecommunications network. The device can make requests for data either directly over the air to a cell site or using a mobile device, such as a smartphone, as an intermediary. The request includes data describing the device, e.g., as a header or metadata of the request. These data may include device type, processor, component type (e.g., screen type, resolution, etc.), operating system, firmware version, memory size and other technical information. Such information may be inferred from identifiers, the properties of the request, information included in previous or recent requests from the same device or supplied explicitly.

A system (or a component of the system) monitors requests and/or responses to requests being made over the telecommunications (e.g., cellular) or another network. When the system detects a request and/or responses to requests for 3D digital data then the request and/or response is intercepted and receives additional processing. The technical properties of the requesting device are determined. This information may be determined from the request or from elsewhere. If it is determined that the device cannot render or process the requested 3D data at the full quality (e.g., resolution, frame rate, etc.) of the data that is being requested (or in the native form of the 3D data), then additional processing is carried out. The requested 3D data may also or instead be processed to optimise or speed up the processing of requests through the network (e.g., to lower data volumes passing through the RAN of a cellular network). For example, the 3D data that has been requested may be at (or is natively in) a format beyond the rendering capability of the requesting device. For example, the requested 3D data may take the form of 4k resolution, but the requesting device may only be able to render 1080p resolution. Therefore, additional processing is applied to the 3D data before it is provided in response to the request over the telecommunications network. However, if the 3D data does not require processing or manipulation then the 3D data is transmitted directly and unprocessed by the component. Therefore, the resources of the telecommunications (or other) network are not used to send larger data sets or data streams when the end-user device cannot render the received data without any down sampling or downscaling process and/or if the network operator decides to make a data optimisation decision. Instead, smaller data sets or streams are sent to the requesting device at or close to the size and quality required to make full use of its rendering ability. Therefore, system and communication resources are saved without degrading performance or user enjoyment. This is because the requesting device wouldn’t be able to make use of the full scale or quality stream and so sending it over the network would be a waste of system resources.

Against this background and in accordance with a first aspect there is provided a method for processing 3D digital data, the method comprising the steps of: receiving a request for digital data, wherein the digital data is 3D digital data and further wherein the request is received from a requesting device and the request is transmitted over a telecommunications network; determining (e.g., from the received request or from another source of information) one or more technical properties of the requesting device; determining from the one or more technical properties of the requesting device if the requested 3D digital data requires data manipulation, wherein the determination is based on rendering requirements of the 3D digital data and the one or more technical properties of the requesting device; and if data manipulation is required then: applying one or more data manipulations to the requested 3-D digital data; and transmitting the manipulated 3D digital data to the requesting device over a telecommunications network.

Therefore, system and communication resources can be saved or limited without degrading user experience. The telecommunications network may be a cellular network but may also be Wi-Fi or a fixed line broadband network, for example. The determination regarding whether data manipulation of the 3D digital data is required may also be based on the properties of the 3D digital data being requested, e.g., the 3D digital data (and its attributes or properties) contained within a response to the request. This may be in combination to the determined one or more technical properties of the requesting device, i.e., whether the requesting device is capable of rendering or presenting the 3D digital data (having particular technical properties), without carrying out its own data manipulation (e.g., downsampling, compression, etc.) Advantageously, the data manipulations (if required) are carried out before the 3D digital data are sent over the telecommunications network to the requesting device in response to the request.

Preferably, the method steps may be carried out by a node within the telecommunications network. Therefore, this improves utilisation of the network. Other networks may be used.

Advantageously, node may be a multi-access edge computing (MEC) node of a 5G telecommunications network. The MEC node provides a convenient location to carry out this functionality. However, other locations may be used. Optionally, the 3D digital data may be extended reality, XR, virtual reality, VR, and/or augmented reality, AR, digital data.

Optionally, the 3D digital data may be a Graphics Language Transmission Format, GLTF, file or data stream. Other data types may be used. The system may determine that 3D data is being requested from the file format or type (e.g., matching one of a list of format or file types), for example.

Optionally, if data manipulation is not required (e.g., because the technical properties of the requesting device are sufficient to handle and/or render the requested digital data) then: transmitting the requested 3D digital data to the requesting device over the telecommunications network (cellular or other) in an original form. Therefore, the method may make a determination either way. For non-3D data the request is not intercepted and passes through the system to be processed as usual. However, if 3D digital data is being requested then the method carries out the further processing steps.

Optionally, the data manipulation may comprise any one or more of: downsampling, compression, and/or decimation. Other manipulations or processing may take place in addition to or instead of these.

Optionally, the one or more technical properties of the requesting device may comprise: properties of a rendering component of the requesting device (e.g., screen or screens), processing power, memory, operating system, and/or firmware version. Other properties may be determined. The data manipulations may relate to any one or more of the determined technical properties or groups of technical properties. A device type identifier may be used, which indirectly indicates the one or more technical properties. A lookup table (against device type or device identifier) may be used, for example. The lookup table may indicate particular technical properties for each device type. However, the request may explicitly contain the technical properties (e.g., screen resolution, maximum frame rate, and/or bitrate).

Optionally, the method may further comprise the step of determining that the requested digital data is 3D digital data, wherein the request for digital data is one request of a plurality of requests including requests for data other than 3D digital data and further wherein if the requested data is not 3D digital data, then transmitting the digital data to the requesting device over the telecommunications network without manipulation. The separate requests may originate from the same device or from different devices.

Optionally, the method may further comprise caching files relating to 3D objects for use in the one or more data manipulations. For example, commonly used 3D objects (or those requested several times) may be cached in memory to save system input/output (i/o) resources.

Optionally, the request for digital data may originate from: 3D goggles, a headset, 3D glasses, or a browser that is configured to render 3D data. Other devices may be used, including smartphones, laptop computers, desktop computers, tablet computers, etc.

Optionally, the request for digital data passes from the 3D goggles, the headset or 3D glasses through user equipment, UE. There may be a local wireless connection (e.g., Bluetooth or Wi-Fi) between the UE and the 3D goggles, the headset or 3D glasses. The requesting device may have its own telecommunications (e.g., cellular) interface (and UICC) or the telecommunications interface of the UE (e.g., smartphone) may be used instead to pass on requests and receive data.

Optionally, the step of determining one or more technical properties of the requesting device may be carried out based on information within the request and/or a response for the 3D digital data. The technical properties of the requesting device (e.g., 3D goggles) may be explicitly included in the request (e.g., the maximum rendering resolution), as information describing the make model, firmware, hardware, etc. of the requesting device, or implicitly as a reference to a device type that can be looked up (e.g., from a database) and has minimum technical properties, for example. Alternatively (or additionally), the one or more technical properties of the requesting device may be determined from the response to the request. For example, such information may be included in a header of the response either explicitly or implicitly.

In accordance with a second aspect, there is provided a telecommunications (e.g., cellular) network comprising means adapted to execute the steps of the method, as described above. In accordance with a further aspect, there is provided a telecommunications (e.g., cellular) network comprising means adapted to execute the steps of the method of: receiving a request for digital data, wherein the digital data is 3D digital data and further wherein the request is received from a requesting device and the request is transmitted over a telecommunications network; determining (e.g., from the received request or from another source of information) one or more technical properties of the requesting device; determining from the one or more technical properties of the requesting device if the requested 3D digital data requires data manipulation, wherein the determination is based on rendering requirements of the 3D digital data and the one or more technical properties of the requesting device; and if data manipulation is required then: applying one or more data manipulations to the requested 3-D digital data; and transmitting the manipulated 3D digital data to the requesting device over the telecommunications network.

In accordance with a further aspect, there is provided a method for processing 3D digital data, the method comprising the steps of: receiving a request for digital data, wherein the digital data is 3D digital data and further wherein the request is received from a requesting device and the request is transmitted over a telecommunications network (e.g., cellular, Wi-Fi, wired, broadband, etc.); determining from a response to the request if the requested 3D digital data requires data manipulation; and if data manipulation is required then: applying one or more data manipulations to the requested 3-D digital data; and transmitting the manipulated 3D digital data to the requesting device over a telecommunications network. The response may include a payload of the requested 3-D digital data (i.e., in a raw or unmanipulated format). Furthermore, the response may include a header that describes the type and technical properties (e.g., resolution) of the 3-D digital data. The determination whether data manipulation is required on the 3D digital data may be based on the technical properties of the payload or data describing these technical properties or attributes, for example. There may also be provided a system that carries out this method. The method and system may further incorporate any or all of the optional or preferable features described above.

Preferably, the means adapted to execute the steps of the method is a multi-access edge computing, MEC, component. The means adapted to execute the steps may form part of a core network or may be part of a periphery server or component. The MEC component may form part of a 5G network, for example.

Optionally, the request may be received over a 2G, 3G, 4G, 5G or a 6G network.

The methods described above may be implemented as a computer program comprising program instructions to operate a computer. The computer program may be stored on a computer-readable medium.

The computer system may include a processor or processors (e.g., local, virtual or cloud-based) such as a Central Processing Unit (CPU), and/or a single or a collection of Graphics Processing Units (GPUs). The processor may execute logic in the form of a software program. The computer system may include a memory including volatile and nonvolatile storage medium. A computer-readable medium may be included to store the logic or program instructions. The different parts of the system may be connected using a network (e.g. wireless networks and wired networks). The computer system may include one or more interfaces. The computer system may contain a suitable operating system such as UNIX, Windows (RTM) or Linux, for example.

It should be noted that any feature described above may be used with any particular aspect or embodiment of the invention. Brief description of the Figures

The present invention may be put into practice in a number of ways and embodiments will now be described by way of example only and with reference to the accompanying drawings, in which:

FIG. 1 shows a schematic diagram of a system for processing 3D digital data and providing those data to a requesting device; and

FIG. 2 shows a method of processing 3D digital data and providing those data to a requesting device of figure 1 , given by way of example only;

FIG. 3 shows a further method of providing 3D digital data and providing those data to a requesting device of figure 1 , given by way of example only; and

FIG. 4 shows a schematic diagram illustrating a data flow within the system of figure 1.

It should be noted that the figures are illustrated for simplicity and are not necessarily drawn to scale. Like features are provided with the same reference numerals.

Detailed description of the preferred embodiments

Rendering two-dimensional (2D) web content involves transmission of (typically) HTML, CSS and JavaScript, together with binary media for images (PNG, JPG, GIF) and video (MP4, MOV) and audio/video streams from an origin-server (e.g., a website) to a client/browser.

While users have a certain tolerance for 2D web page rendering (i.e., can tolerate a loss of quality, bitrate and resolution, etc.), when lower quality rendering is used for a particular digital service then this provides a less immersive experience, especially within a real-time extended reality (XR) environment, where every millisecond counts in haptic feedback. Three-dimensional (3D) environments involve far more complex data (e.g., including 3D-mesh, texture, normal-map, bump and displacement-map, animation, and interaction data) that involve larger file sizes than 2D environments because more information is being communicated. VR headsets, glasses, and goggles (or similar rendering devices) are generally far lower powered than a typical laptop or PC that hosts a web-browser. Furthermore, they are very likely to be battery powered further limiting their computing power. Any download (e.g., over a telecommunications network such as a cellular network) or computational expense saved by limiting resolution, increasing compression or other quality reduction techniques will generally influence the immersive experience and battery life. However, this can also be of benefit to creators of the digital service (e.g., a game designer), hardware manufacturers of the rendering device and for any network operator (such as a cellular telecommunication network provider) who can reduce the use of network resources when providing or streaming the digital service.

In-headset VR games typically overcome the problem of slower network connections (or the need to download high volumes of data) by bundling and downloading relevant content upfront from an application or play-store. However, artificial reality (AR)- based spatial experiences (overlaying 3D information onto current, real-world experience or video feeds) generally requires an on-demand request/response process because the data cannot be as easily cached or downloaded in advance, especially when the user of the AR service changes physical location.

Ever since mobile browsers, i.e., those operating on user equipment (UE) such as smartphones, have adopted native HTTP capability, an Optimiser Service Node (OSN) in a mobile network may act as a "Web Accelerator", providing:

Caching common web page data for faster retrieval, as the request does not need to go back to an origin server;

Non-lossy white-space removal of text-based page description languages (HTML, CSS, JavaScript);

Image and video compression of JPEG/GIF/PNG/MP4/MOV as appropriate to the receiving device (e.g., down-scaling to fit the screen resolution);

HTTP aggregation using mime-multipart, to provide a single HTTP response containing multiple page components (e.g., HTML and its referenced CSS, JavaScript and images); and

HTTP compression to gzip (or other similar compression algorithm) an overall response for browsers that advertise their support of this (i.e., decompressing the content in the client before rendering). However, as mobile bandwidth has increased, the cost/benefit of the Web Accelerator has decreased.

The system and method described in this disclosure provides a different type of performance enhancer specifically focused on 3D digital data provision and for XR data services, in particular. This facilitates the provision of more complex 3D data services, with reduced time-tolerance (i.e., lower latency) that provide immersive real-time XR service and other 3D digital data to relatively low processing power XR devices. Such a system may be described as a 3D optimiser node within a telecommunications network in the form of an XR or 3D data accelerator.

Figure 1 shows a schematic diagram of a system 5 for processing 3D digital data and providing those processed data to a requesting device 10. In this example implementation, the requesting device is a 3D headset, although any requesting device capable of accepting 3D digital data may be used.

In the example shown in Figure 1 , the requesting device 10 is in wireless communication with a smartphone 20 or other user equipment. The smartphone 20 has a data connection (e.g., cellular) with a base station 30, which is in communication with a core network 40. The core network 40 includes one or more separate servers. One of the servers 50 can carry out the various processing steps used to process and provide 3D digital data to the requesting device 10. In this example implementation, the processing server 50 is a multi-access edge computing (MEC) component. However, any suitable processer either within the core network 40 or outside of the core network may be used to carry out these processing steps.

In this example implementation, the smartphone 20 is used as an intermediary between the requesting device 10 and the base station 30. This is because the smartphone 20 has a UICC or SIM capable of receiving data services from the telecommunications network (e.g., 4G or 5G). However, in other example implementations, the requesting device 10 may be in direct communication with the base station 30 as it may also contain a UICC or SIM and therefore for a subscriber unit or user equipment (UE).

In any case, the requesting device 10 makes a particular request for 3D digital data and in response, receives such 3D digital data. The request may be a single request or one of a stream of requests. Each request may include other information (e.g., local video data that can be enhanced using an external data service). The 3D digital data may originate from within the telecommunications network or be provided by an external service provider (not shown in this figure). Whilst some data services may not be real-time (e.g., movie and game streaming services), other 3D digital services may require low latency and real-time processing. Such real-time services may include extended reality (XR), augmented reality (AR), or virtual reality (VR) services. For example, a video stream may be generated by a camera in the headset, transmitted over the telecommunications network (together with the request) to an XR service, which augments the video with 3D digital data that this sent back to the headset in response to the request. This allows relatively low powered (CPU) devices to provide a higher quality XR service. Such services can require significant bandwidth and have particularly low latency requirements in order to provide an acceptable user experience.

Furthermore, the 3D digital data services may need to provide a quality and resolution of data suitable for the highest performance devices that may request those data. For example, 4K or 8K equipped displays and computers may be able to take advantage of such high-quality media. Therefore, the XR (or other) 3D data service may perform at the maximum required data and quality settings regardless of the requesting device. Whilst devices such as VR goggles and other headsets may have the advantage of providing an immersive experience, they may lack resolution and processing power. Nevertheless, they may receive the same high quality data stream that they cannot fully take advantage of and may even need to down-sample or otherwise reduce the quality of the incoming received 3D digital data. Nevertheless, the network has had to expend significant resources in providing such 3D digital data services to the virtual reality headset.

Figure 2 shows a flowchart of an example method 100 for processing such 3D digital data. At step 110 of this method 100, a request for digital data is received from the requesting device 10. This request may take several forms. For example, it may be a particular request for a specified data file or stream. It may also be a request to receive a particular 3D data service, such as an extended reality service. The request may include additional data such as location data of the requesting device 10 or other supplementary information such as those data generated by a local application operating on the requesting device 10 or connective device (e.g., smartphone 20).

The request also includes some data providing information regarding the technical capabilities or properties of the requesting device 10. These data may explicitly describe such technical properties of the requesting device (e.g., processor, processing power, memory, screen resolution, firmware version, and battery level). The request may alternatively or additionally contain one or more identifiers that may be used to infer such technical properties of the requesting device 10. For example, such one or more identifiers may include device type, device identifier, device category or other identifier that may be used or looked up by a receiver of the request to determine the technical capabilities of the requesting device 10.

The request is transmitted over a telecommunications network. In this example, that is a cellular telecommunications network (e.g., 4G or 5G). The request passes through the smartphone 20 to the base station 30 and on to the core network 40. The request is intercepted by the MEC component 50, which can specifically intercept 3D digital data requests. The identification of 3D digital data may be based on request type, file type, originating application, or other technical properties of the request or requesting device 10. From data included within the device, the MEC component 50 determines technical properties of the requesting device at step 120. These technical properties may be inferred or explicitly derived from the request (e.g., within a header or other metadata).

The MEC component 50 determines from the technical properties of the requesting device and the nature of the requested data or data stream (3D data or non-3D data) whether data manipulation is required (step 130). This determination may also be made by the MEC component 50 by intercepting the response, including the requested data. For example, an HTTP request may include a header that states the content type being returned and/or details describing or referencing the type of requesting device, and this information may be used by the MEC component 50 to make the determination regarding data manipulations that may be required. Data manipulations may include small adjustments to the data (e.g., a change of format) or more significant changes. For example, the MEC component 50 may apply lossy or lossless compression to the requested 3D digital data, resolution changes, bitrate reductions (in a case of imaging or video data), or other data manipulations. In general, the data manipulations will reduce the required system resources used to transmit the data through the telecommunications network to the requesting device 10 and may also reduce processing requirements of intermediate components or of the requesting device (e.g., to avoid down-sampling or internal format changes). However, the reductions in size and/or data quality will preferably be limited to those that do not affect the end user experience because the manipulated data will more closely match the technical capabilities, preferably at or just above of the requesting device 10 (e.g., within 10-50% of them) than the originally requested data.

However, any reduction may have an overall benefit.

Those determined data manipulations are applied at step 140 and after such data manipulations or reformatting have been achieved or in the case of a streaming service, simultaneously, the requested data are transmitted to the requesting device at step 150.

Figure 3 shows a flowchart of a further example method 200 used to process 3D digital data and to provide those data to a requesting device 10. Similar steps are provided with the same reference numerals as those described with reference to Figure 2. However, this method 200 includes an explicit step to check whether or not data manipulation is required (step 210). For example, if the requested 3D digital data is in a format, a size, or a resolution (for example) that is suitable and capable being rendered on the requesting device 10 then no data manipulations may be required. Furthermore, it may be that although the requested 3D digital data is in a format that is beyond the technical capabilities of the requesting device 10 the difference is below a particular predetermined threshold (e.g., 10-50%) that a determination is made that any additional processing or necessary processing latency (for the data manipulation) is not justified because the bandwidth or system resource savings are insufficient to justify the additional steps.

In the case that no data manipulations are required then the process moves straight to the transmission stage (step 150). If it is determined that data manipulation is or are required, then these particular data manipulations are determined at step 220. This may involve a full set of data manipulations or the system may determine that only one or more of the available data manipulations should be applied given a particular cost/benefit assessment. The system may have a set of available data manipulations to apply and may determine which subset of the full set of possible manipulations to use. This may depend on the difference in native data quality and technical properties of the requesting device.

The particular determined data manipulations are applied at step 230 and then the manipulated 3D digital data is transmitted to the requesting device at step 150 in a similar way to that described with method 100 described with reference to Figure 2.

Figure 4 shows schematically the operation of the system 5 and includes an illustration of the data flowing between different components of the system 5. The requesting device 10 (also a rendering device) may be but is not limited to a 3-D headset. A proxy engine 320 operates within the MEC component 50 or elsewhere. An origin server 330 may provide the requested 3D digital data (for example a 3D model in some format) in an original or unprocessed form. The origin server 330 may be located with the MEC component 50 or be at a remote location outside of the telecommunications network.

There may be a plurality of origin servers 330 but only one is shown in this figure.

The flow of information, requests, and responses in figure 4 are referenced by numbered flows 1-7. The request (1 ) for 3D digital data is issued by the requesting device and received by the (e.g., transparent) proxy engine 320 (2). The request is also passed on or made to the origin server 330 (3).

The origin server 330 provides the requested (unprocessed) digital data (4) in the form of an unmodified response 340. A content inspection and optimisation component 350 carries out content inspection steps on data contained within the unmodified response 340. The returned information is examined by the content inspection and optimisation component 350 (content inspection), and the proxy engine 320 decides whether to intervene. If not, then content is returned unmodified as in step (7) without passing through the other steps.

However, when a decision or determination is made that data manipulation is required, based on one or more technical properties of the requesting device 10, then one or more 3D content compression mechanisms 360 or other data manipulations are carried out on the unmodified response 340 (6) to form modified data. This can include appropriate 3D content compression algorithms employed to optimise the 3D data for the requesting rendering device 10 (e.g., content specific compression). The modified data are transmitted to the requesting device 10 (7).

Different data manipulations may be selected and applied to the 3D digital data by the system 5. This may include:

Non-lossy compression of gITF (Graphics Language Transmission Format) from its ASCII form (.gltf, essentially JSON) to its equivalent binary form (.gib). Such processing may provide around 50% compression;

Non-lossy compression of USD (Universal Scene Descriptor) from its ASCII form (.usda) to its equivalent binary form (.usdc); Unpacking a USDZ package file (a non-compressing ZIP), compressing the individual contents (e.g., any USDA files, downscaling textures) and repackaging;

Texture compression (images used to drape over 3D meshes). It may be quite easy to apply an image texture that far exceeds the resolution of the viewing device, causing massive redundancy in the data transferred;

3D-Mesh compression: Compressing a 3D grid and point cloud, which may change the order and quantity of the vertices in the grid. This may provide around 50-64% compression; and

There are other 3D-centric file formats that may be in a text-based design-friendly format for ease of editing. These may be different to an optimised binary transmission/rendering format. Furthermore, these may be optimised/compiled in transit (e.g., OBJ, FBX, WebAssembly/WASM etc.);

Caching gITF, USD and related files for commonly accessed 3D objects. This can be particularly appropriate to MEC processing when the data include a 3D object that is attached to a spatial anchor within its physical serving region (e.g., an AR overlay reconstruction of a ruined castle - that would only be accessed in that physical area/location);

3D experiences in a web-browser are generally achieved through common JavaScript libraries that act as a 3D-viewer. These are downloaded on request and executed within the browser, such as balylon.js and three.js. JavaScript compression and caching of these may be beneficial;

Opportunities for specific-server-side compression for particular VR-headset decoders. For example, if a particular headset type implemented a proprietary compression or streaming codec, then the MEC (or other) node may act as a proxy, performing that compression if was not supported by the origin server.

These may be described as a collection of tools placed in-line with 3D-relevant data traffic, to optimise the XR-experience.

Whilst the system may take the form of a component of the MEC, a further implementation may take the form of a server-side GPU for the client-side XR-device, which may offload computationally-expensive 3D rendering into the network (known as a "split rendering pipeline"). This further allows for lighter, cheaper XR-devices, or higher- end experiences on lower-end devices but with the provided 3D digital data provided at a quality and resolution matched to the rendering device. Optimisations and data manipulations may change over time and may themselves be optimised or evolve as the rendering or requesting devices change and are enhanced.

As will be appreciated by the skilled person, details of the above embodiment may be varied without departing from the scope of the present invention, as defined by the appended claims.

For example, whilst the figures show only a single requesting device, the network may include many devices requesting different 3D digital data. Furthermore, a single MEC or processing component is shown but further processing components may be used within the same telecommunications network to load balance or to intercept different 3D data types.

Many combinations, modifications, or alterations to the features of the above embodiments will be readily apparent to the skilled person and are intended to form part of the invention. Any of the features described specifically relating to one embodiment or example may be used in any other embodiment by making the appropriate changes.