`
`Exhibit 2014, Page 1
`Google Inc. v. Summit 6 LLC
`IPR2015-0806, Summit 6 LLC
`
`
`
`COPYRIGHT
`
`©2000 Internet Pictures Corporation. All rights reserved.
`
`Information in this document is subject to change without notice. The software
`described in this document is furnished under a license agreement or nondisclosure
`agreement. The software may be used or copied only in accordance with the terms of
`those agreements. No part of this publication may be reproduced, stored in a retrieval
`system, or transmitted in any form or any means electronic or mechanical, including
`photocopying and recording for any purpose other than the purchaser’s use without the
`written permission of Internet Pictures Corporation.
`
`Internet Pictures Corporation (iPIX)
`3160 Crow Canyon Road
`Fourth Floor
`San Ramon, CA 94583
`U.S.A.
`
`www.ipix.com
`
`TRADEMARKS
`
`Rimfire and the PIXcast Network are trademarks of Internet Pictures Corporation
`(iPIX) in the United States and in other countries. ActiveX and Internet Explorer are
`trademarks or registered trademarks of Microsoft Corporation. Java and Java script are
`trademarks or registered trademarks of Sun Microsystems. Other brands and their
`products are trademarks or registered trademarks of their respective holders and should
`be noted as such.
`
`RFWP-E1-091801AA-C
`
`Exhibit 2014, Page 2
`Google Inc. v. Summit 6 LLC
`IPR2015-0806, Summit 6 LLC
`
`
`
`Contents
`
`A brief history........................................................................................................... 1
`The “Chain of Pain” 2
`Enter iPIX 2
`What is Rimfire?....................................................................................................... 3
`An out-sourced end-to-end solution that collects, transforms, and deploys millions of
`3
`media objects in just seconds.
`Internationalized 3
`3
`Easily implemented and extensible
`Who are Rimfire customers?.................................................................................... 4
`4
`A few of our stellar customers...
`How does Rimfire work?.......................................................................................... 5
`5
`RSAPI: An extensible middle layer
`5
`Submission Controls
`6
`Behind the scenes
`The Rimfire Client.................................................................................................... 7
`Built-in intelligence to discern the best implementation for the end-user 7
`The full-browse implementation 7
`10
`The minbrowse implementation
`Rimfire Upload Features ........................................................................................ 12
`
`Rimfire
`
`i
`
`Exhibit 2014, Page 3
`Google Inc. v. Summit 6 LLC
`IPR2015-0806, Summit 6 LLC
`
`
`
`Contents
`
`Standard Upload 12
`12
`Bulk Upload
`The Rimfire Server ................................................................................................. 13
`13
`Media transformation
`Media deployment 13
`Rimfire Central: The Server-side Architecture....................................................... 14
`Media server subsystems 14
`Hosting and Mirroring Services ............................................................................. 15
`Rimfire Key Benefits.............................................................................................. 16
`Now its “drag-and-drop simple” to submit images into any Web site 16
`About iPIX.............................................................................................................. 17
`Internet Pictures Corporation 17
`
`ii
`
`Internet Pictures Corporation
`
`Exhibit 2014, Page 4
`Google Inc. v. Summit 6 LLC
`IPR2015-0806, Summit 6 LLC
`
`
`
`A brief history
`
`Rimfire
`
`A BRIEF HISTORY
`
`In 1997, when most digital imaging companies were claw-
`ing for a niche in the dwindling desktop market, iPIX
`noticed a new challenge. On one side were markets with a
`need for vast amounts of digital imaging content. On the
`other side was a diverse base of digital imaging users, i.e.,
`Web businesses and their consumers (end-users) who could
`potentially create and contribute digital imaging content
`over the Internet. It quickly became clear that user-generated
`media represented the next growth phase for the Internet,
`impacting many industries and applications such as:
`
`• Remote capture, submission, transformation and distri-
`bution of dynamic image data for vertical markets such
`as insurance, real estate, construction, and medicine
`Inventory management
`•
`• Business communications via intranets and extranets
`• E-commerce in auctions and classifieds
`• Personal Web page publishing
`• Communication via chat, discussion boards, and instant messaging
`• Affinity groups/family sites/communities
`• Photo sharing sites
`• Reporters, photographers, and editors
`
`The unifying element across all of these industries and applications was the need to col-
`lect media from a diverse user-base. However, the user-base itself posed a problem.
`While a proliferation of digital devices had given an increasing number of Internet users
`the tools to create digital images, most of these users were far from expert in imaging
`
`Internet Pictures Corporation
`
`Rimfire
`
`1
`
`Exhibit 2014, Page 5
`Google Inc. v. Summit 6 LLC
`IPR2015-0806, Summit 6 LLC
`
`
`
`A brief history
`
`The “Chain of Pain”
`
`Enter iPIX
`
`technology. In other words, they were completely unprepared for the sequence of com-
`plex technical tasks involved in posting even a single image to the Web. These tasks
`include:
`
`• Editing the image content
`• Transforming (resizing and/or reformatting) static images for suitable usage on the
`Web
`• Creating dynamic images that allow fluid and energetic user interaction
`• Transferring images to the Web
`• Storing images in an accessible Web location
`• Distributing images to multiple destinations
`• Delivering media according to customer specified delivery requirements
`
`For most users, these tasks constituted a merciless “chain of pain” which merely helped
`them propagate poor quality images in every conceivable format. For businesses strug-
`gling to collect, manage and distribute this morass, the chain was effectively a noose. It
`required additional back-office infrastructure costs to handle user submitted and man-
`aged media. Companies began looking for alternative ways to manage the complexities
`of user content delivery.
`
`Rather than continually add servers, bandwidth, and human resources, more Web busi-
`nesses began outsourcing their image media delivery to Controlled Content Delivery
`(CCD) providers. CCD providers specialize in delivering content to end users more
`quickly and efficiently through business efficient applications, intelligent caching, geo-
`graphically-distributed servers and rerouting over private networks.
`
`Recognizing the need to solve the challenge, iPIX set out to build a reliable technology
`infrastructure that could serve as a platform to automate the submission, transformation
`and management of user-supplied media according to specific delivery requirements.
`This infrastructure would invisibly do the “heavy lifting” involved in submitting, trans-
`forming and distributing digital images between businesses and end-users. It would
`automatically resolve complex technology variables in real-time, thus allowing both
`parties to focus on their objectives rather than on the hard science that made their rela-
`tionship viable. And lastly, this infrastructure would put into place a much needed stan-
`dard for the comprehensive management of digital images over the Internet.
`
`In 1999, the task was completed: iPIX built the first end-to-end imaging solution for
`content capture, transformation and delivery on the Internet and named it RimfireTM. The
`technology was so innovative that in 1999, two patent applications were filed for Rim-
`fire. In 2000, the infrastructure was expanded to include robust components from sev-
`eral merging companies and technologies, resulting in the creation of the PIXcast
`NetworkTM. Rimfire serves as a key component of PIXcast, handling the submission and
`transformation of user-supplied content.
`
`2
`
`Rimfire
`
`Internet Pictures Corporation
`
`Exhibit 2014, Page 6
`Google Inc. v. Summit 6 LLC
`IPR2015-0806, Summit 6 LLC
`
`
`
`What is Rimfire?
`
`WHAT IS RIMFIRE?
`
`A strategic technology of the PIXcast Network, Rimfire is a browser-based dynamic
`imaging solution to acquire, process and distribute images online. Rimfire automatically
`captures, sizes and formats images to customer specifications before uploading to Rim-
`fire servers for additional transformation, storage and distribution. Rimfire also allows
`customers to enhance the presentation of images with graphic layering (adding water-
`marks or banners), thumbnail creation, image editing (on the client), multiple image
`delivery, and interactive PhotoMoviesTM.
`
`An out-sourced end-
`to-end solution that
`collects, transforms,
`and deploys millions
`of media objects in
`just seconds.
`
`Rimfire stores and serves media more efficiently than traditional methods by managing
`the primary challenges not addressed by other CCD providers. Namely:
`
`• Collecting user-supplied media from its creators as painlessly and simply as possible
`• Automatically preparing media for use on the Internet prior to delivery and storage
`
`Rimfire provides an extensible browser-based solution with standard APIs to integrate
`user-supplied media capabilities site-wide. To implement Rimfire is surprisingly easy.
`The customer (or the customer’s Web developer) simply cuts-and-pastes Java Script or
`HTML code snippets provided by iPIX into the appropriate sections of the customer’s
`Web pages. Rimfire’s integration documents guide each step of this straight-forward
`and uncomplicated process. From there, customers need only test the code and function-
`ality, and make slight modifications to adjust the look and feel of the site.
`
`Internationalized
`
`As the world’s first and only dynamic imaging infrastructure, PIXcast with Rimfire
`stands alone in providing a solution for collecting, managing, and delivering user media
`to customers around the globe. To accommodate this global perspective, Rimfire is fully
`internationalized, making the system entirely compatible with double-byte and special
`characters where localization is required.
`
`Easily implemented
`and extensible
`
`Once Rimfire code is integrated into Web applications that support additional media
`types, adding exciting transformations or changing delivery settings can be done on the
`Rimfire server without requiring changes to the Web application. As an out-sourced
`solution, Rimfire gives Web sites and intranets the ability to integrate robust user-media
`without making a major investment in adding servers, bandwidth and the staff required
`to operate effectively. More importantly, businesses can stay focused on their objectives
`rather than on becoming media experts.
`
`In its first full year of operation, over 250 million image views were processed through
`the Rimfire system for e-commerce business customers ranging from online auctions to
`asset management to real estate. This number is currently increasing at a rate of over 3.5
`million each week. All the while, Rimfire and the rest of the PIXcast Network is being
`continually upgraded and enhanced without requiring customers to change their imple-
`mentation.
`
`Internet Pictures Corporation
`
`Rimfire
`
`3
`
`Exhibit 2014, Page 7
`Google Inc. v. Summit 6 LLC
`IPR2015-0806, Summit 6 LLC
`
`
`
`Who are Rimfire customers?
`
`WHO ARE RIMFIRE CUSTOMERS?
`
`Rimfire customers are businesses who typically want to enhance a specific Web site
`with user-supplied images and associate those images with domain-specific information
`stored in a database. (For example, images of real estate associated with listing informa-
`tion stored in an MLS database.) The dynamic imaging objectives that these customers
`generally seek to achieve are:
`
`• To manage mega-volume image submission and processing
`• To allow end-users (either business associates or customers of those associates) to
`select and upload images from remote locations via a Web page in the customer’s
`site
`• To automatically transform the images on the client-side into a size and format suit-
`able for viewing on the Web
`• To provide image-editing capability to the end-user on the client-side
`• To provide back-end server functionality for databasing, image management and
`image hosting
`• To optionally customize the images on-the-fly with banners or watermarks or
`present them as slideshows or dynamic images
`• To allow submitted images to be viewed directly on the customer’s site
`• To implement all of the above quickly and easily
`
`A few of our stellar
`customers...
`
`Rimfire currently provides end-to-end media management for online auctions, chats,
`classifieds, communities, construction, e-commerce, insurance, personalized greetings,
`real estate, and wireless customers. Several of our most prominent customers are:
`
`•
`
`eBay (http://www.ebay.com/), the world’s largest personal trading community™
`pioneered person-to-person online trading. Founded in 1995, eBay has developed an
`efficient and entertaining trading site on the Web that is available 24-hours a day,
`seven days a week. eBay has more than 15 million registered users who add more
`than 550,000 items to the site daily in over 4,200 categories. Rimfire technology
`allows eBay users to instantly upload and display images of their auction items
`directly in the eBay site. It also provides services that allow the users to transform
`images into exciting slideshows that enhance the selling experience. The PIXcast
`Network with Rimfire allowed eBay to completely out source their imaging needs to
`iPIX.
`• MakeOverStudio.com (http://www.makeoverstudio.com), the “place for the ulti-
`mate cyber-makeover” that allows users to try thousands of new looks on their own
`images. Introduced by Makeover Networks Inc. (an application service provider
`syndicating Web-based solutions to marketing partners who serve the $70 billion
`beauty and fashion industries), MakeOver Studio.com uses the PIXcast Network
`with Rimfire technology to provide the complete dynamic imaging infrastructure for
`their product line. As a Rimfire-enabled site, MakeOver Studio.com allows end-
`users to upload their own images to the Makeover site where it becomes available
`for their makeover experience.
`
`4
`
`Rimfire
`
`Internet Pictures Corporation
`
`Exhibit 2014, Page 8
`Google Inc. v. Summit 6 LLC
`IPR2015-0806, Summit 6 LLC
`
`
`
`How does Rimfire work?
`
`• Polaroid Corporation, with annual sales of approximately $2 billion, is the world-
`wide leader in instant imaging. Polaroid supplies instant photographic cameras and
`film, digital imaging hardware, software and media, secure identification systems,
`sunglasses and polarizers to markets worldwide. The PIXcast Network with Rimfire
`provides a media infrastructure for Polaroid’s i-zone.com, a photo-sharing and cre-
`ativity site focusing on teens.
`• Homestore.com® (http://www.homestore.com), has a family of real estate Web
`sites which includes REALTOR.com®, the official Internet site of the National
`Association of REALTORS®, which features approximately 1.36 million existing
`and new home listings and real estate agent and broker services. Rimfire technology
`allows Realtors to quickly and easily submit pictures of properties for sale or lease
`and instantly display them on the site.
`
`HOW DOES RIMFIRE WORK?
`
`The process of enabling a Web site with Rimfire technology begins as a collaborative
`effort between iPIX, the Rimfire customer, and the customer’s designated Web develop-
`ers. iPIX provides the customer with a valid Rimfire account and a Rimfire Submission
`Pack. The Submission Pack contains everything that the developer needs to activate a
`new account and “Rimfire-enable” the site. The most important component of the Rim-
`fire Submission Pack is the Java Script code that constitutes the Rimfire Submission
`Application Programming Interface or RSAPI.
`
`RSAPI: An extensible
`middle layer
`
`RSAPI is a Java Script interface to Rimfire that allows Web site customers to set proper-
`ties and invoke functions to configure how media is pre-processed and submitted. Once
`customers (or their Web developers) add snippets of Java Script Rimfire integration
`code to the their Web pages, Rimfire can begin collecting, transforming and distributing
`user-supplied media. The integration code enables the submitting Web site to communi-
`cate with Rimfire via a direct socket connection or via http tunneling. Because RSAPI is
`not hard-coded on the server, Rimfire remains easily extensible without negatively
`impacting the end-user’s ability to use the Rimfire submission controls.
`
`Submission Controls
`
`Rimfire submission controls are a combination of GUI image well controls and “send”
`components that are instantiated in the customer’s Web page after their values are
`defined in the integration code. These controls are the elements that allow the end-user
`to submit images to the Rimfire Server. They include:
`
`•
`
`Image wells - These controls provide Rimfire’s patent-pending drag-and-drop func-
`tionality for adding images. The user simply drags an image file from a location on
`their local drive to an image well on the customer’s Web submission page. The cus-
`tomer may elect to add one or more image wells to the page.
`
`Internet Pictures Corporation
`
`Rimfire
`
`5
`
`Exhibit 2014, Page 9
`Google Inc. v. Summit 6 LLC
`IPR2015-0806, Summit 6 LLC
`
`
`
`How does Rimfire work?
`
`Behind the scenes
`
`• A submission button - This control is a regular HTML button that calls into RSAPI
`and informs it that there are images in the image wells that are ready to be uploaded
`to the Rimfire Server.
`• An upload handler - This component is the send control that performs the submis-
`sion of images to the Rimfire server when the user clicks the submission button.
`
`In addition to specifying the values for submission controls, customers may also elect to
`set parameters in their integration code that specify custom features such as:
`
`• Graphic layering
`• Dynamic thumbnails
`• Slideshow (an animated effect that cycles a series of images within a display box)
`• PhotoMovies (interactive MacroMedia Flash presentations)
`• Callback functions to perform checks against images (or against data associated with
`the image) at the following points in the submission process:
`- before any images are sent to the Rimfire Server
`- before each image is sent to the Rimfire Server
`- after each image is sent to the Rimfire Server
`- after all images are sent to the Rimfire Server
`Image editing (cropping and rotating) on the Rimfire client
`•
`• Large images
`• Media management
`
`When an end-user submits an image via a Rimfire-enabled Web page, a copy of that
`image (already properly sized and formatted on the client to specific standards set by the
`recipient Web site) is transmitted to the Rimfire Server. The server first validates the
`Rimfire account information for the customer. Once the account is validated, the server
`then applies any instructions for images that the customer has specified in the integra-
`tion code. Depending on the customer’s objectives, these instructions might include
`invoking callback functions or transforming images to adding a banner and/or water-
`mark, creating a slideshow or thumbnails, or creating a PhotoMovie. After the instruc-
`tions have been carried out, the images are saved to our PIXcast Network and
`information associated with the images is stored in an Oracle 8i database on the servers.
`A URL to the location of each image is created and returned to the client via a hidden
`field in the Web application. This hidden field is what allows the end-user to see the
`images on the client’s Web pages.
`
`6
`
`Rimfire
`
`Internet Pictures Corporation
`
`Exhibit 2014, Page 10
`Google Inc. v. Summit 6 LLC
`IPR2015-0806, Summit 6 LLC
`
`
`
`The Rimfire Client
`
`THE RIMFIRE CLIENT
`
`The Rimfire client is a browser-dependent application that determines how image sub-
`mission and client-side image processing is managed on the end-user’s system. Submis-
`sion, as discussed earlier, is the user’s ability to upload images to the Rimfire Server.
`Client-side image processing encompasses any automated image handling specified by
`the customer, such as image resizing, viewing, and the conversion of graphical formats.
`A real benefit of client-side processing is that it frees the server from unnecessary pro-
`cessing overhead and bandwidth expense.
`
`Built-in intelligence
`to discern the best
`implementation for
`the end-user
`
`Functionality of the Rimfire client is ultimately determined by the requirements of the
`end-user’s preferred browser. To accommodate Netscape and Internet Explorer users,
`the Rimfire client has built-in intelligence to transparently identify the browser and then
`provide the appropriate controls on the submission page. In most instances, client-side
`processing is implemented by downloading either an ActiveX control or a Java applet
`(depending on the browser) on the user’s system. This is called the full-browse imple-
`mentation of RSAPI.
`
`The full-browse
`implementation
`
`However, there is a minority of users whose browser and/or operating system (OS) con-
`figurations will not support either the ActiveX control or the Java applet. For these
`users, there is another RSAPI implementation called Minbrowse, which will be dis-
`cussed later in this section.
`
`When an end-user on the Microsoft Windows operating system visits a Rimfire-enabled
`site for the first time, Rimfire downloads either an ActiveX control or a Java Applet
`depending on the user’s browser. These components determine how Rimfire manifests
`submission and image processing for the user:
`
`•
`
`•
`
`•
`
`If the preferred browser is Microsoft’s Internet Explorer version 4.X or greater, the
`user is prompted to download the ActiveX control.1 Eighty-six percent of all Internet
`users fall within this category.
`If the preferred browser is Netscape version 4.08 or greater, the user is prompted to
`download the Java applet2.
`If the preferred browser is AOL version 5.0 or greater, the user is prompted to down-
`load the ActiveX control.
`
`1. The ActiveX control is downloaded and installed once on the user’s system. Thereafter, the user is not
`prompted until a newer version becomes available.
`2. The Java applet does not install on the user’s system. The user is prompted to download the applet for each
`session.
`
`Internet Pictures Corporation
`
`Rimfire
`
`7
`
`Exhibit 2014, Page 11
`Google Inc. v. Summit 6 LLC
`IPR2015-0806, Summit 6 LLC
`
`
`
`The Rimfire Client
`
`The ActiveX control. This control enables the following functionality/features on the
`client:
`
`• Drag-and-drop - The user can add an image to the submission page by simply drag-
`ging an image file from their local system and dropping it into a submission control
`(an image well) on the submission page.
`• Previewable graphic formats - ActiveX allows a broader variety of graphic file for-
`mats (JPEG, BMP and GIF) to be viewable from within submission page prior to
`actual submission to the Rimfire Server.
`• Client-side image editing - The user can crop or rotate previewable images directly
`in the submission page prior to actual submission.
`
`The Java applet. The Java applet enables the following functionality/features on the
`client:
`
`• Browse dialog - The user clicks an image well in the submission page which opens a
`browse dialog from which the user selects and adds an image file. Drag-and-drop
`functionality is not supported.
`• Previewable graphic formats - The Java applet allows JPEG and GIF graphic file
`formats to be viewable from within the submission page.
`• Client-side image editing - The user can crop or rotate previewable images directly
`in the submission page prior to actual submission.
`Notes:
`The currently supported file types are JPG, BMP, GIF, Animated GIF, ZIP, TIF,
`PNG, FPX, PCX, IPX and XML.
`Internet Explorer 2.x, Netscape 2.x, AOL 3.0 and Web TV as browsers are supported
`for viewing of submitted media only.
`
`Figure 1 on page 9 illustrates the Rimfire full-browse workflow.
`
`8
`
`Rimfire
`
`Internet Pictures Corporation
`
`Exhibit 2014, Page 12
`Google Inc. v. Summit 6 LLC
`IPR2015-0806, Summit 6 LLC
`
`
`
`The Rimfire Client
`
`FIGURE 1. Rimfire Full Browse Workflow
`(1) Media is dropped into an image well in the client Web application by the end-user.
`(2) Submitted media is sent via RSAPITP (port 1470) to a Rimfire media server.
`(2.1) If port 1470 is blocked and submission fails, media are sent via HTTP-tunnel
`on port 80 to a Rimfire HTTP server.
`(2.2) The HTTP server re-submits media to a Rimfire media server.
`(3) Received media is checked for processing & delivery profile.
`(3.1) The database is queried for processing and storage information.
`(4) Any processing not performed by client is now performed.
`(5) Processed media are delivered according to the storage profile.
`(5.1) Sent to a storage facility and the client web application is returned a URL to
`the stored media.
`(5.2) Sent to a client server running the Rimfire Client Receiver applet.
`(5.3) Final transaction is recorded in the database.
`
`Internet Pictures Corporation
`
`Rimfire
`
`9
`
`Exhibit 2014, Page 13
`Google Inc. v. Summit 6 LLC
`IPR2015-0806, Summit 6 LLC
`
`
`
`The Rimfire Client
`
`The minbrowse
`implementation
`
`If an end-user’s preferred browser and/or OS configuration does not permit use of the
`ActiveX control or Java applet, the minbrowse implementation of RSAPI is used. The
`major difference between minbrowse and full-browse is that minbrowse does not con-
`duct image processing on the client. Instead, submitted images are sent directly to the
`Rimfire server and all image processing takes place there. Images are not previewable
`prior to sending, but are reflected back from the server after submission. All Macintosh
`systems using Internet Exploter, Netscape and AOL require the minbrowse implementa-
`tion of RSAPI.1
`
`In the minbrowse scenario, the end-user clicks on an empty “image well” in the submis-
`sion page, which calls a separate minbrowse page. The minbrowse page contains a
`browse button and a URL display field. The user clicks the browse button to summon a
`browse dialog, and then browses the file system to the location of the image to be
`uploaded. Upon selection of the image file, the use clicks a submission button. At this
`point, the image is transmitted to the Rimfire Server and the URL for the image is pro-
`vided in the display field simultaneously. Figure 2 on page 11 illustrates the Minbrowse
`workflow.
`
`1. Netscape 6.0 is supported for Minbrowse on Microsoft Windows systems only.
`
`10
`
`Rimfire
`
`Internet Pictures Corporation
`
`Exhibit 2014, Page 14
`Google Inc. v. Summit 6 LLC
`IPR2015-0806, Summit 6 LLC
`
`
`
`The Rimfire Client
`
`FIGURE 2. Rimfire Minbrowse Workflow
`(1) Media is selected by the end-user in the client Web application.
`(2) When submitted, the media is sent via form-post to a Rimfire HTTP server.
`(2.1) The Rimfire HTTP Server re-submits the media to a Rimfire Media server.
`(3) Received media are checked for processing and delivery profile.
`(3.1) The database is queried for processing and storage information.
`(4) Any processing not performed (or performed incorrectly) by the client is now per-
`formed.
`(5) Processed media are delivered according to the storage profile.
`(5.1) Sent to a storage facility and the client web application is returned a URL to
`the stored media.
`(5.2) Sent to a client server running the Rimfire Client Receiver applet.
`(5.3) Final transaction is recorded in the database.
`
`Internet Pictures Corporation
`
`Rimfire
`
`11
`
`Exhibit 2014, Page 15
`Google Inc. v. Summit 6 LLC
`IPR2015-0806, Summit 6 LLC
`
`
`
`Rimfire Upload Features
`
`Standard Upload
`
`Bulk Upload
`
`RIMFIRE UPLOAD FEATURES
`
`Rimfire's standard upload feature is a business-to-consumer solution that allows casual
`contributors (who are typically not digital imaging experts) to upload relatively small
`amounts of media1 in a given session. In this business model, the submission process is
`accomplished in essentially two steps:
`
`1. Contributors are constrained to loading one image at a time into available image
`wells on a submission page (or specifying URLs in display fields on a minbrowse
`page).
`2. Contributors then invoke the submission by clicking a button which uploads all the
`images in that submission to the Rimfire server.
`
`This upload methodology is especially attractive to casual users because of its ease of
`use. However, because of Rimfire’s especially rapid processing speed, a false impres-
`sion may sometimes be created that all of the images in a submission are uploaded
`simultaneously and processed as a group. This is wholly incorrect. It is an important dis-
`tinction to understand that in a standard Rimfire upload operation, images are uploaded
`singly and a separate URL is returned for each uploaded image.
`
`Rimfire's bulk upload feature is a business-to-business solution for customers who need
`to transfer and process vast groups of media2 in an automated fashion. It simplies the
`submission process by allowing media to comes to the client in large batches rather than
`singly as in the standard upload.The bulk upload feature is a system administrator’s tool
`that is optionally available in two implementations:
`
`The first bulk upload option is a Windows console application that uses C++ to transmit
`a directory of media to Rimfire. It facilitates the handling of bulk submissions by writ-
`ing the submission results to an XML file. A "SOURCE" element is inserted into the
`XML document for each image in the submitted directory. Sub-elements detailing the
`success of that submission to Rimfire and the resulting Rimfire response (usually the
`URL of the hosted images) are also inserted. Using any number of XML parsing meth-
`odologies, a Rimfire customer can then reconcile each image in the bulk upload to a
`database.
`
`The second bulk upload option is through Rimfire programming APIs and components.
`Using the faceless Rimfire ActiveX control, developers can create custom solutions that
`integrate image upload with their overall application. This control provides the same
`capabilities as the client-oriented control, but is intended to run as a behind-the-scenes
`integrated software component that handles the application's image transfer tasks. Such
`applications could include desktop applications or server-based Web applications.
`
`1. Usually between 3 and 5 images per submission.
`2. Thousands or tens of thousands of images.
`
`12
`
`Rimfire
`
`Internet Pictures Corporation
`
`Exhibit 2014, Page 16
`Google Inc. v. Summit 6 LLC
`IPR2015-0806, Summit 6 LLC
`
`
`
`The Rimfire Server
`
`THE RIMFIRE SERVER
`
`The Rimfire Server is the central repository for submitted images and their associated
`information (e.g., file names, client info, distribution lists, etc.) It is also the workhorse
`that manages image transformation.
`
`Media transformation While basic transformations to resize images or convert graphic file formats typically
`happen on the client, additional transformations may be applied by the server. These
`transformations may be as simple as creating multiple versions of an image for screen
`display, print, and thumbnails for preview, or as complex as building new types of
`media out of component media parts. For example, a real estate agent can submit a per-
`sonal photo, franchise logo and a marketing caption and the Rimfire server will auto-
`matically merge these elements into each new property listing photo. Rimfire can also
`receive several pictures from a user, and merge them with other media assets (music,
`animation, or captions, for example) to create a rich, interactive PhotoMovie. Rimfire’s
`transformation modules fall into three key categories: translation, manipulation and
`generation.
`
`Translation. Translation modules perform format conversions, such as changing an
`image from TIF to JPG, or a video clip from AVI to Quicktime. Translators can also per-
`form data extraction operations, which may pull metadata from a media and convert it to
`XML for indexing, and database associations.
`
`Manipulation. Manipulation modules perform enhancement, compositing, sizing, and
`analysis operations. An enhancement module may reduce noise, adjust color balance, or
`apply special effects. A compositing module may dynamically merge multiple image
`elements together into a single image as required. Sizing modules can generate multiple
`resolutions of a media object for device-specific display limitations, bandwidth limita-
`tions, preview thumbnails, and high-resolution printing requirements. Analysis opera-
`tions may be used to emphasize or de-emp