Patent Abstract:
Video clips are stored and converted on a website into different formats which are compatible with different cellular phones. The source for the video can be sources such as DVDs, other cellular phones, or broadcast television. The system can automatically store profiles from multiple different phones and automatically carry out a conversion based on information stored in the profile.

Full Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application claims priority to U.S. Provisional Application 60/844,207, filed Sep. 12, 2006. The disclosure of the prior application is considered part of (and is incorporated by reference in) the disclosure of this application. 
    
    
     BACKGROUND 
     Data compression allows storing more data in a smaller space, and later reconstructing the original data. The use of data compression may allow improved use of limited bandwidth over channels such as cellular networks. 
     It is important that many different clients be able to decompress video which has been compressed using various techniques. Accordingly, the decompression process typically is kept simple to avoid the requirement of special hardware to decompress. However, the compression process can be extremely complicated, since specialized hardware can be used for the compression. 
     SUMMARY 
     The present application teaches a compression process intended to be used on a cellular phone over a cellular network. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1A  illustrates the host login screen; 
         FIG. 1B  illustrates a selection menu; 
         FIG. 2  illustrates an exemplary screen; 
         FIG. 3  illustrates how a cable television feed can be selected; 
         FIG. 4  illustrates a flowchart of the operation of customer interaction; and 
         FIG. 5  illustrates a hardware diagram. 
     
    
    
     DETAILED DESCRIPTION 
     The general structure and techniques, and more specific embodiments which can be used to effect different ways of carrying out the more general goals, are described herein. 
     The present application operates by allowing users to connect to a host website using their cellular phone. While attached to the host website, the users can view motion pictures of streaming video on the display of the cellular phone. In an embodiment, the cellular phone has a special adapter that is externally attached to the data port of the cellular phone. This special adapter uses very large scale integration “VLSI” chips to carry out decompression of the received information. 
     An embodiment uses extremely aggressive motion estimation algorithms for the compression and decompression, in order to attempt to obtain a ratio as high as 1000:1 compression ratio. The wavelet transform decomposes the image into different resolutions (or scales). One usually refers to these as averages and details. However, there are different levels of detail resolution and one of the parameters that we can select is the number of levels we decompose the image. One usually refers to the details to describe “the finest scale”, hierarchically down to the “coarsest” scale. In order to reconstruct the image it is necessary to transmit information about not only the magnitude of the wavelet transform coefficients, but also the position of the significant transform coefficient. This means that for each wavelet coefficient, we need to provide three numbers; magnitude plus the location in x and y. One of the challenges for transmitting wavelet transformed data efficiently is to use redundancy in the location description such that not each individual position has to be transmitted independently. A challenge in streaming media is to transmit the most significant pieces of information first. By doing this, all is not lost even if the bitstream is interrupted pre-maturely. This also provides an easy way to adjust the protocol for different bit budgets. This is referred to as progressive transmission, and may also be used in this system. 
     Since the decoder is a single purpose device, separate from the phone, it can be of any level of complexity. 
     In an embodiment, a cellular phone display may have the ability to view images that have many different forms, for example, 245×320 pixels. Such a phone requires 76,800 pixels per frame. If the streaming video is sent at a refresh rate of 24 frames per second, this means that about 442 million pixels of streaming data is necessary. Taking the Verizon™ network of CDMA networks as an example, which has a baud rate of 400,000 bits per second, this would require about 18½ minutes. At a compression rate of 250:1, this could be accomplished in about 4½ seconds and would require much less bandwidth and memory storage. 
     In addition, the module may store a number of images, which can be displayed as part of the displayed video. In addition, the module stores compression and decompression algorithms that allow more efficient transferring of large images over the network. 
     An operating system can also be downloaded to the attachment module. 
       FIG. 1A  indicates the host login screen, that requires the user to connect.  FIG. 1  shows entering (or otherwise obtaining) a user&#39;s mobile telephone number, and, their cellular provider  105 , and type of phone  110 . This information may also be automatically detected. 
     Other information about the phone and/or its connection may also be obtained, for example, whether the phone has GPRS. 
     Once connected, the user is provided with a selection menu shown in  FIG. 1B . This requires selecting both the input source from the selection menu: High definition TV, DVD, cellular, PDA and other. The output destination can also be selected from high definition TV, DVD, cellular, and other. Once selected, the website will carry out a conversion operation. 
       FIG. 2  illustrates an exemplary screen. This shows the owners personal information  200  including name, cellular phone number, and the like. A ‘ CREATE NEW VIDEOS ’ menu  205  is also shown. The ‘ CREATE NEW VIDEOS ’ selects an import path from which the videos can be created. Once created, the videos are resident on the website, shown by the section  210 , which also shows how many video clips the user has, and allows sending them to the cellular phone, viewing or deleting. A preview screening  220  can also be provided. 
     In operation, the user can select a video from any desired source to be sent to the website, converted, and eventually sent to the telephone. For example,  FIG. 3  illustrates how a cable television feed can be selected, received by the website at  305 , converted by the VLSI board into a motion compensated and aggressively compressed video image, and then sent over the cellular carrier  322  to the cellular phone  325 . This architecture allows any feed—such as from a cable television—to be selected by a user on a website, aggressively compressed, and sent to the mobile phone for later usage. 
     According to one aspect, much of the compression is done in VLSI circuitry, thereby enabling more aggressive compression of that information. 
       FIG. 4  illustrates a flowchart of the operation of customer interaction. At  400 , the user logs on to a website, and identifies the preferences at  405 , using for example the screens shown in  FIGS. 1A and 1B . The user can change preferences at  410 , which preferences are then stored in the user database at  415 . Alternatively, the user can choose to upload or download video clips at  420 . If the download is selected, flow passes to  425 , where the user selects a video, and selects download to cellular at  430 . The user profile is then used to determine the number of pixels at  435 . An aggressive data compression  440  is carried out, which passes control to the download process  460 . 
     If the user selects uploading clips, the user then selects a source at  450 , which may be, for example, a DVD at  455 . Alternatively, the source may be cable television, or any other source. Uploading begins at  456 , followed by a data compression stage at  457  where the data is aggressively compressed. Flow then passes to the upload/download process which allows the data to be downloaded. 
       FIG. 5  illustrates a hardware diagram which shows the phone  500  and the attachment module  510  attached thereto. In the embodiment, the attachment module is connected by a hook and eye part  509  such as Velcro™ to the side of the phone. The attachment module has a cable  511  which is attached to a USB or other format data port  512 . The VLSI module has a processor  520 , a logical gate array  521  of flash memory storage  522 , and a cellular phone interface  525 . The logical gate array  521  may either be a programmable logic array that is reconfigurable according to downloaded instructions, or may be dedicated logic gates. Because dedicated hardware can be used to decompress the data, the data may be more aggressively compressed prior to sending to the cellular phone. 
     Although only a few embodiments have been disclosed in detail above, other embodiments are possible and the inventors intend these to be encompassed within this specification. The specification describes specific examples to accomplish a more general goal that may be accomplished in another way. This disclosure is intended to be exemplary, and the claims are intended to cover any modification or alternative which might be predictable to a person having ordinary skill in the art. For example, the external module is optional and others could be used. 
     Also, the inventors intend that only those claims which use the words “means for” are intended to be interpreted under 35 USC 112, sixth paragraph. Moreover, no limitations from the specification are intended to be read into any claims, unless those limitations are expressly included in the claims. The computers described herein may be any kind of computer, either general purpose, or some specific purpose computer such as a workstation. The computer may be an Intel (e.g., Pentium or Core 2 duo) or AMD based computer, running Windows XP or Linux, or may be a Macintosh computer. The computer may also be a handheld computer, such as a PDA, cellphone, or laptop. 
     The programs may be written in C or Python, or Java, Brew or any other programming language. The programs may be resident on a storage medium, e.g., magnetic or optical, e.g. the computer hard drive, a removable disk or media such as a memory stick or SD media, wired or wireless network based or Bluetooth based Network Attached Storage (NAS), or other removable medium. The programs may also be run over a network, for example, with a server or other machine sending signals to the local machine, which allows the local machine to carry out the operations described herein. 
     Where a specific numerical value is mentioned herein, it should be considered that the value may be increased or decreased by 20%, while still staying within the teachings of the present application, unless some different range is specifically mentioned. Where a specified logical sense is used, the opposite logical sense is also intended to be encompassed.

Technology Classification (CPC): 7