Abstract

The mobile device includes a client that has a number of modules, and the MMR Gateway and MMR matching unit are implemented as a server that has a number of modules. The implementation of the MMR system as a client and a server is advantageous because the modules may be distributed among the client and the server in a variety of configurations. The present invention includes a capture module, a preprocessing module, a feature extraction module, a retrieval module, a send message module, an action module, a prediction module, a feedback module, a sending module, an MMR database, a streaming module, an e-mail module, a voice recognition system and an audio database. These modules and systems are operational upon the client or the server. In one embodiment, the client includes only the capture module with the remaining modules operational on the server. In a second embodiment, the server includes the action module with the remaining modules operational on the client.

The invention relates to techniques for creating a mixed media document that is formed from at least two media types, and more particularly, to registering an image and other data in a Mixed Media Reality (MMR) system that uses printed media in combination with electronic media to retrieve mixed media documents. Still more particular, the present invention relates to client devices adapted to interact with an MMR system.

2. Background of the Invention

Document printing and copying technology has been used for many years in many contexts. By way of example, printers and copiers are used in commercial office environments, in home environments with personal computers, and in document printing and publishing service environments. However, printing and copying technology has not been thought of previously as a means to bridge the gap between static printed media (i.e., paper documents), and the “virtual world” of interactivity that includes the likes of digital communication, networking, information provision, advertising, entertainment and electronic commerce.

Printed media has been the primary source of communicating information, such as news papers and advertising information, for centuries. The advent and ever-increasing popularity of personal computers and personal electronic devices, such as personal digital assistant (PDA) devices and cellular telephones (e.g., cellular camera phones), over the past few years has expanded the concept of printed media by making it available in an electronically readable and searchable form and by introducing interactive multimedia capabilities, which are unparalleled by traditional printed media.

Unfortunately, a gap exists between the electronic multimedia-based world that is accessible electronically and the physical world of print media. For example, although almost everyone in the developed world has access to printed media and to electronic information on a daily basis, users of printed media and of personal electronic devices do not possess the tools and technology required to form a link between the two (i.e., for facilitating a mixed media document).

Moreover, there are particular advantageous attributes that conventional printed media provides such as tactile feel, no power requirements, and permanency for organization and storage, which are not provided with virtual or digital media. Likewise, there are particular advantageous attributes that conventional digital media provides such as portability (e.g., carried in storage of cell phone or laptop) and ease of transmission (e.g., email).

One particular problem is that a publisher cannot allow access to electronic versions of content using printed versions of the content. For example, for the publisher of a newspaper there is no mechanism that allows its users who receive the printed newspaper on a daily basis to use images of the newspaper to access the same online electronic content as well as augmented content. Moreover, while the publisher typically has the content for the daily newspaper in electronic form prior to printing, there currently does not exist a mechanism to easily migrate that content into an electronic form with augmented content.

A second problem in the prior art is that the image capture devices that are most prevalent and common as part of mobile computing devices (e.g., cell phones) produce low-quality images. In attempting to compare the low-quality images to pristine versions of printed documents, recognition is very difficult if not impossible. Thus there is a need for a method for recognizing low-quality images of printed newspapers.

A third problem in the prior art is that the image recognition process is computationally very expensive and can require seconds if not minutes to accurately recognize the page and location of a pristine document from an input query image. This can especially be a problem with a large data set, for example, millions of pages of documents. Thus, there is a need for mechanisms to improve the speed in which recognition can be performed.

A fourth problem in the prior is that comparing low-quality images to a database of pristine images often produces a number of possible matches. Furthermore, when low-quality images are used as the query image, multiple different recognition algorithms may be required in order to produce any match. Currently the prior art does not have a mechanism to combine the recognition results into a single result that can be presented to the user.

A fifth problem in the prior is that most mobile phones and other portable devices have very limited functional capabilities. Most cell phone are used predominately for voice communication, and some add the capability for data communication (simple email), and to capture images. The cell phone can use the voice, data or in some cases WiFi or 3G for data communication, but are very limited as to the functions other than those described above which are provided by the manufacturer.

For these reasons, a need exists for techniques, methods and systems that enable the use of mixed media reality systems in the area of mass media printed publishing.

SUMMARY OF THE INVENTION

The present invention overcomes the deficiencies of the prior art with an MMR system for use in newspaper publishing. In one embodiment, the MMR system for newspaper publishing comprises a plurality of mobile devices, an MMR gateway and an MMR matching unit. The mobile devices are communicatively coupled to the MMR gateway and MMR matching unit to provide a message, typically including a request or query, and to receive results. The MMR gateway and MMR matching unit perform user authentication and image recognition as well as other operations depending on the configuration. In one embodiment, the mobile device includes a client that has a number of modules, and the MMR Gateway and MMR matching unit are implemented as a server that has a number of modules. The implementation of the MMR system as a client and a server is advantageous because the modules may be distributed among the client and the server in a variety of different configurations. The present invention includes a capture module, a preprocessing module, a feature extraction module, a retrieval module, a send message module, an action module, a prediction module, a feedback module, a sending module, an MMR database, a streaming module, an e-mail module, a voice recognition system and an audio database. These modules and systems are operational upon the client or the server. In one embodiment, the client includes only the capture module with the remaining modules operational on the server. In a second embodiment, the server includes the action module with the remaining modules operational on the client. The present invention includes a variety of other embodiments in which some of the modules are operational on the client while the other modules are operational on the server. Furthermore, in other configurations, the client and server have less than all the modules described above.

In yet another embodiment, the MMR system includes a plurality of mobile devices each having a client and in communication with each other via a peer-to-peer network. The modules are operational on the plurality of mobile devices. For example, a first mobile device includes only capture module and a peer-to-peer communication module; a second mobile device includes a feature extraction module, a retrieval module, an MMR database and a peer-to-peer communication module. A third mobile device includes a dispatcher, a hotspot database and peer-to-peer communication module. In such an embodiment, the first mobile device captures an image and sends it to the second mobile device. The second mobile device receives the image, performs recognition and outputs a document identification and location to the third mobile device. The third mobile device receives the document identification and location, retrieves hotspot data and sends the hotspot data to the first mobile device.

The features and advantages described herein are not all-inclusive and many additional features and advantages will be apparent to one of ordinary skill in the art in view of the figures and description. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and not to limit the scope of the inventive subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention is illustrated by way of example, and not by way of limitation in the figures of the accompanying drawings in which like reference numerals are used to refer to similar elements.

FIG. 1 is a block diagram of a first embodiment of system mixed-media reality retrieval of location and registration of images in accordance with the present invention.

FIG. 2A is a block diagram of a first embodiment of a mobile device, network and MMR gateway configured in accordance with the present invention.

FIG. 2B is a block diagram of a second embodiment of a mobile device, network and MMR gateway configured in accordance with the present invention.

FIGS. 2C-2H are block diagrams of various embodiments of a mobile device plug-in, MMR gateway and MMR matching unit showing various possible configurations in accordance with the present invention.

FIGS. 2I is a block diagram of an embodiment of a mobile device plug-in, MMR gateway and MMR matching unit showing a configuration using email transmissions in accordance with the present invention.

FIG. 3 is a block diagram of an embodiment of an MMR gateway in accordance with the present invention.

FIG. 4A is a block diagram of a first embodiment of a MMR matching unit in accordance with the present invention.

FIG. 4B is a block diagram of a second embodiment of the MMR matching unit in accordance with the present invention.

FIG. 5 is a block diagram of an embodiment of a dispatcher in accordance with the present invention.

FIG. 6A is a block diagram of a first embodiment of an image retrieval unit in accordance with the present invention.

FIG. 6B is a block diagram of a second embodiment of the image retrieval unit in accordance with the present invention.

FIG. 7 is a block diagram of an embodiment of a registration unit in accordance with the present invention.

FIG. 8 is a block diagram of an embodiment of an MMR publisher in accordance with the present invention.

FIG. 9 is a flowchart of an embodiment of a method for retrieving a document and location from an input image in accordance with the present invention.

FIG. 10 is a flowchart of a method for registering an image with the MMR matching unit in accordance with embodiments of the present invention.

FIG. 11 is a flowchart of a method for dynamic load balancing in accordance with an embodiment of the present invention.

FIG. 12 is a flowchart of a method for image-feature-based ordering in accordance with an embodiment of the present invention.

FIG. 13 is a flowchart of a method for generating blurry images and corresponding indices in accordance with an embodiment of the present invention.

FIG. 14 is a flowchart of a method for generating blurry images for training in accordance with an embodiment of the present invention.

FIG. 15A is a flowchart of a first embodiment of a method for initializing and generating classifiers for blurry images in accordance with the present invention.

FIG. 15B is a flowchart of a first embodiment of a method for initializing and generating classifiers for blurry images in accordance with the present invention.

FIG. 16 is a flowchart of an embodiment of a method for finding a classifier that recognizes the most images in accordance with the present invention.

FIG. 17 is a flowchart of an embodiment of a method for modifying and testing a classifier against unrecognized images in accordance with the present invention.

FIG. 18 is a block diagram of an embodiment of a quality predictor in accordance with the present invention.

FIG. 19 is a block diagram of an embodiment of a vector calculator in accordance with the present invention.

FIG. 20 is a process diagram of a method for generating robustness features in accordance with the present invention.

FIG. 21 is a process diagram of a method for generating a recognizability (quality prediction) score in accordance with the present invention.

FIG. 22 is a flowchart of a first embodiment of a method for combining a plurality of results using a predictor in accordance with the present invention.

FIG. 23 is a flowchart of a second embodiment of the method for combining a plurality of results using the predictor in accordance with the present invention.

FIG. 24 is a flowchart of an embodiment of a method for combining a plurality of results in accordance with the present invention.

FIG. 25 is a flow diagram of an embodiment of a method for processing information including both audio and image or video data from a mobile device in accordance with the present invention.

FIG. 26 is a block diagram of a second embodiment of a system for image recognition and retrieval in accordance with the present invention.

FIG. 27 is a block diagram of a third embodiment of a system for image recognition and retrieval in accordance with the present invention.

FIG. 28 is a block diagram of a fourth embodiment of a system for image recognition and retrieval in accordance with the present invention.

FIG. 29 is a block diagram of a fifth embodiment of a system for image recognition and retrieval in accordance with the present invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

An architecture for a mixed media reality (MMR) system 100 capable of receiving the query images and returning document pages and location as well as receiving images, hot spots and other data and adding such information to the MMR system is described. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the invention. It will be apparent, however, to one skilled in the art that the invention can be practiced without these specific details. In other instances, structures and devices are shown in block diagram form in order to avoid obscuring the invention. For example, the present invention is described in one embodiment below with reference to use with a conventional mass media publisher, in particular a newspaper publisher. However, the present invention applies to any type of computing system and data processing in which multiple types of media including electronic media and print media are used.

Reference in the specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the invention. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment. In particular the present invention is described below in the context of two distinct architectures and some of the components are operable in both architectures while others are not.

Some portions of the detailed descriptions that follow are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers or the like.

It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing” or “computing” or “calculating” or “determining” or “displaying” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

The present invention also relates to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions, each coupled to a computer system bus.

Finally, the algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatuses to perform the required method steps. The required structure for a variety of these systems will appear from the description below. In addition, the present invention is described without reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the invention as described herein.

System Overview

FIG. 1 shows an embodiment of a MMR system 100 in accordance with the present invention. The MMR system 100 comprises a plurality of mobile devices 102a-102n, an MMR gateway 104, an MMR matching unit 106, an MMR publisher 108 and a computer 110. The present invention provides an MMR system 100 for use in newspaper publishing. The MMR system 100 for newspaper publishing is particularly advantageous because provides an automatic mechanism for a newspaper publisher to register images and content with the MMR system 100. The MMR system 100 for newspaper publishing is also advantageous because it has a unique architecture adapted to respond to image queries formed of image portions or pages of a printed newspaper.

The mobile devices 102a-102n are communicatively coupled by signal lines 132a-132n, respectively, to the MMR gateway 104 to send a “retrieval request.” A retrieval request includes one or more of “image queries,” other contextual information and metadata. In one embodiment, an image query is an image in any format, or one or more features of an image. Example of image queries include still images, video frames and sequences of video frames. The mobile devices 102a-102n are mobile phones including a camera to capture images. It should be understood that the MMR system 100 will be utilized by hundreds or even thousands of users that receive a traditional publication such as a daily newspaper. Thus, even though only two mobile devices 102a, 102n are shown, those skilled in the art will appreciate that the MMR gateway 104 may be simultaneously coupled to, receive and respond to retrieval requests from numerous mobile devices 102a-102n. Alternate embodiments for the mobile devices 102a-102n are described in more detail below with reference to FIGS. 2A and 2B.

As noted above, the MMR gateway 104 is able to couple to hundreds if not millions of mobile computing devices 102a-102n and service their retrieval requests. The MMR gateway 104 is also communicatively coupled to the computer 110 by signal line 130 for administration and maintenance of the MMR gateway 104 and running business applications. In one embodiment, the MMR gateway 104 creates and presents a web portal for access by the computer 110 to run business applications as well as access logs of use of the MMR system 100. The computer 110 can be any conventional computing device such as a personal computer. The main function of the MMR gateway 104 is processing retrieval requests from the mobile devices 102a-102n and returning recognition results back to the mobile devices 102a-102n. In one embodiment, the recognition results include one or more of a Boolean value (true/false) and if true, a page ID and a location on the page. In other embodiments, the recognition results also include one or more from the group of actions, a message acknowledging that the recognition was successful (or not) and consequences of that decision, such as the sending of an email message, a document, actions defined within a portable document file, addresses such as URLs, binary data such as video, information capable of being rendered on the mobile device 102, menus with additional actions, raster images, image features, etc. The MMR gateway 104 processes received retrieval requests by performing user authentication, accounting, analytics and other communication. The MMR gateway 104 also generates an image query and recognition parameters from the retrieval request, and passes them on to the MMR matching unit 106 via signal line 134. Embodiments and operation of the MMR gateway 104 are described in greater detail below with reference to FIG. 3.

The MMR matching unit 106 receives the image query from the MMR gateway 104 on signal line 134 and sends it to one or more of recognition units to identify a result including a document, the page and the location on the page corresponding to the image query, referred to generally throughout this application as the “retrieval process.” The result is returned from the MMR matching unit 106 to the MMR gateway 104 on signal line 134. In addition to the result, the MMR matching unit 106 may also return other related information such as hotspot data. The MMR matching unit 106 also includes components for receiving new content and updating and reorganizing index tables used in the retrieval process. The process of adding new content to the MMR matching unit 106 is referred to generally throughout this application as the “registration process.” In one embodiment, the MMR matching unit 106 is coupled to the output of the MMR publisher 108 via signal lines 138 and 140 to provide new content used to update index tables of the MMR matching unit 106. In alternate embodiment, the MMR publisher 108 is coupled to the MMR gateway 104 by signal line 138 and the MMR gateway 104 is in turn coupled by signal line 136 to the MMR matching unit 106. In this alternate environment, MMR gateway 104 extracts augmented data such as hotspot information, stores it and passes the images, page references and other information to the MMR matching unit 106 for updating of the index tables. Various embodiments of the MMR matching unit 106 and its components are described in more detail below with reference to FIG. 4A-7.

The MMR publisher 108 includes a conventional publishing system used to generate newspapers or other types of periodicals. In one embodiment, the MMR publisher 108 also includes components for generating additional information needed to register images of printed documents with the MMR system 100. The information provided by the MMR publisher 108 to the MMR matching unit 106 includes an image file, bounding box data, hotspot data, and a unique page identification number. In the symbols of embodiment, this is a document in portable document format by Adobe Corp. of San Jose Calif. and bounding box information. An embodiment for the MMR publisher 108 is described in more detail below with reference to FIG. 8.

Mobile Device 102

Referring now to FIGS. 2A and 2B, the first and second embodiment for the mobile device 102 will be described.

FIG. 2A shows a first embodiment of the coupling 132 between the mobile device 102 and the MMR gateway 104. In this embodiment, the mobile device 102 is any mobile phone (or other portable computing device with communication capability) that includes a camera. For example, the mobile device 102 may be a smart phone such as the Blackberry® manufactured and sold by Research In Motion. The mobile device 102 is adapted for wireless communication with the network 202 by a communication channel 230. The network 202 is a conventional type such as a cellular network maintained by wireless carrier and may include a server. In this embodiment, the mobile device 102 captures an image and sends the image to the network 202 over communications channel 230 such as by using a multimedia messaging service (MMS). The network 202 can also use the communication channel 230 to return results such as using MMS or using a short message service (SMS). As illustrated, the network 202 is in turn coupled to the MMR gateway 104 by signal lines 232. Signal lines 232 represent a channel for sending MMS or SMS messages as well as a channel for receiving hypertext transfer protocol (HTTP) requests and sending HTTP responses. Those skilled in the art will recognize that this is just one example of the coupling between the mobile device 102 and the MMR gateway 104. In an alternate embodiment for example, Bluetooth®, WiFi or any other wireless communication protocol may be used as part of communication coupling between the mobile device 102 and the MMR gateway 104. The mobile device 102 and the MMR gateway 104 could be coupled in any other ways understood by those skilled in the art (e.g., direct data connection, SMS, WAP, email) so long as the mobile device 102 is able to transmit images to the MMR gateway 104 and the MMR gateway 104 is able to respond by sending document identification, page number and location information.

Referring now to FIG. 2B, a second embodiment of the mobile device 102 is shown. In this second embodiment, the mobile device 102 is a smart phone such as the iPhone™ manufactured and sold by Apple Computer Inc. of Cupertino Calif. The second embodiment has a number of components similar to those of the first embodiment, and therefore, like reference numbers are used to reference like components with the same or similar functionality. Notable differences between the first embodiment and the second embodiment include a quality predictor plug-in 204 that is installed on the mobile device 102, and a Web server 206 coupled by signal line 234 to the network 202. The quality predictor plug-in 204 analyzes the images captured by the mobile device 102. The quality predictor plug-in 204 provides additional information produced by its analysis and includes that information as part of the retrieval request sent to the MMR gateway 104 to improve the accuracy of recognition. In an alternate embodiment, the output of the quality predictor plug-in 204 is used to select which images are transmitted from the mobile device 102 to the MMR gateway 104. For example, only those images that have a predicted quality above a predetermined threshold (e.g., images capable of being recognized) are transmitted from the mobile device 102 to the MMR gateway 104. Since transmission of images requires significant bandwidth and the communication channel 230 between the mobile device 102 and the network 202 may have limited bandwidth, using the quality predictor plug-in 204 to select which images to transmit is particularly advantageous. The second embodiment shown in FIG. 2B also illustrates how the results returned from the MMR gateway 104 or other information provided by the quality predictor plug-in 204 can be used by the mobile device 102 to access hotspot or augmented information available on a web server 206. In such a case, the results from the MMR gateway 104 or output of the quality predictor plug-in 204 would include information that can be used to access Web server 206 such as with a conventional HTTP request and using web access capabilities of the mobile device 102.

It should be noted that regardless of whether the first embodiment or the second embodiment of the mobile device 102 is used, the mobile device 102 generates the retrieval request that includes: a query image, a user or device ID, a command and other contact information such as device type, software, plug-ins, location (for example if the mobile device includes a GPS capability), device and status information (e.g., device model, macro lens on/off status, autofocus on/off, vibration on/off, tilt angle, etc), context-related information (weather at the phone's location, time, date, applications currently running on the phone), user-related information (e.g., id number, preferences, user subscriptions, user groups and social structures, action and action-related meta data such as email actions and emails waiting to be sent), etc.

Referring now to FIGS. 2C-2H, various embodiments are shown of a plug-in (client 250) for the mobile device 102, the MMR gateway 104 and MMR matching unit 106 represented generally as including a server 252 that has various possible configurations in accordance with the present invention. More particularly, FIGS. 2C-2H illustrate how the components of the plug-in or client 250 can have varying levels of functionality and the server 252 can also have varying levels of functionality that parallel or match with the functionality of the client 250. In the various embodiments of FIGS. 2C-2H, either the client 250 or the server 252 includes: an MMR database 254; a capture module 260 for capturing an image or video; a preprocessing module 262 for processing the image before feature extraction for improved recognition such as quality prediction; a feature extraction module 264 for extracting image features; a retrieval module 266 for using features to retrieve information from the MMR database 254; a send message module 268 for sending messages from the server 252 to the client 250; an action module 270 for performing an action; a preprocessing and prediction module 272 for processing the image prior to feature extraction; a feedback module 274 for presenting information to the user and receiving input; a sending module 276 for sending information from the client 250 to the server 252; and a streaming module 278 for streaming video from the client 250 to the server 252.

FIG. 2C illustrates one embodiment for the client 250 and the server 252 in which the client 250 sends an image or video and/or metadata to the server 252 for processing. In this embodiment, the client 250 includes the capture module 260. The server 252 includes: the MMR database 254, the preprocessing module 262, the feature extraction module 264, the retrieval module 266, the send message module 268 and the action module 270. In one embodiment, the client 250 uses the native applications of the mobile device 102 to capture an image, and generate and send a message, such as in a multimedia messaging service (MMS) format, that includes a query image. Such an embodiment is particularly advantageous because no additional software needs to be loaded to the mobile device 102. Further, the message includes additional information such as: 1) email addresses, user ids, and preferences; 2) GPS information, device settings (i.e. macro on/off), etc.; 3) metadata about the query images such as its location and document name; and 4) information about the action to be taken on the recognition result, such as ‘send email’ or ‘add to MySpace’, etc. Those skilled in the art will recognize that the message need not include all of the information identified above, but includes as much information as necessary to interact with the server 252 according to the action being performed. The client 250 sends the message including an image or video and/or metadata to the server 252. The server 252 parses the message received to obtain the image and additional information sent by the client 250. In one embodiment, the additional information and the image are used by the preprocessing module 262, the feature extraction module 264, and the retrieval module 266 to recognize the image and identify a corresponding electronic document in the MMR database 254. These operations are described in more detail below with reference to FIGS. 4-7. The recognition results, if any and additional information are then used by the server 252 to perform an action. Example actions include sending an email to some address other than the phone, logging the sender's identity, image and recognition result, and sending information about the retrieval request and response to an accounting system. In some embodiments, the action(s) that the server 252 performs includes sending a return confirmation message to the client 250 that includes: 1) Identified document(s), pages, and locations; 2) A thumbnail of the identified document; 3) Identified document itself, 4) A video overview of identified document; 5) A message about the performed actions, e.g. ‘sent e-mail to xxx@yy.com’; 6) If the image is not retrieved, further instructions about taking the image, such as: a) Image was too blurry, please select macro mode, hold camera still and try again; b) Document was too far from the camera and try again; or c) Image was too dark/there are shadows, and try again.

FIG. 2D illustrates another embodiment for the client 250 and the server 252 in which the client 250 captures an image or video, runs quality prediction, and sends an image or video and/or metadata to the server 252 for processing. In this embodiment, the client 250 includes: the capture module 260, the preprocessing and prediction module 272, the feedback module 274 and the sending module 276. The server 252 includes: the MMR database 254, the preprocessing module 262, the feature extraction module 264, the retrieval module 266, the send message module 268 and the action module 270. It should be noted that in this embodiment the image sent to the server 252 may be different than the captured image. For example, the image may be digitally enhanced, sharpened, or may be just binary data.

FIG. 2E illustrates another embodiment for the client 250 and the server 252 in which the client 250 captures an image or video, performs feature extraction and sends image features to the server 252 for processing. In this embodiment, the client 250 includes: the capture module 260, the feature extraction module 264, the preprocessing and prediction module 272, the feedback module 274 and the sending module 276. The server 252 includes: the MMR database 254, the retrieval module 266, the send message module 268 and the action module 270. It should be noted that in this embodiment feature extraction may include preprocessing. After features are extracted, the preprocessing and prediction module 272 may run on these features and if the quality of the features is not satisfactory, the user may be asked to capture another image.

FIG. 2F illustrates another embodiment for the client 250 and the server 252 in which the entire retrieval process is performed at the client 250. In this embodiment, the client 250 includes: the capture module 260, the feature extraction module 264, the preprocessing and prediction module 272, the feedback module 274 and the sending module 276, the MMR database 254, and the retrieval module 266. The server 252 need only have the action module 270. In a modification to this embodiment, the entire retrieval for one recognition algorithm is run on the client 250 of the mobile device 102, and if the query fails, the captured image is sent to the server 252 as described above with reference to FIG. 2C to that the server 252 process the captured image with more complex retrieval algorithms.

FIG. 2G illustrates another embodiment for the client 250 and the server 252 in which the client 250 streams video to the server 252. In this embodiment, the client 250 includes the capture module 260 and a streaming module 278. The server 252 includes the MMR database 254, the preprocessing module 262, the feature extraction module 264, the retrieval module 266, the send message module 268 and the action module 270. Although not shown, the client 250 can run a predictor on the captured video stream and provide user feedback on where to point the camera or how to capture better video for retrieval. In a modification of this embodiment, the server 252 streams back information related to the captured video and the client 250 can overlay that information on a video preview screen.

FIG. 2H illustrates another embodiment for the client 250 and the server 252 in which the client 250 runs a recognizer and the server 252 streams MMR database information to a local database operable with the client 250 based upon a first recognition result. This embodiment is similar to that described above with reference to FIG. 2F. For example, the entire retrieval process for one recognition algorithm is run at the client 250. If the recognition algorithm fails, the query is handed to the server 252 for running more complex retrieval algorithm. In this embodiment, the client 250 includes: the capture module 260, the feature extraction module 264, the preprocessing and prediction module 272, the feedback module 274, the sending module 276, the MMR database 254 (a local version), and the retrieval module 266. The server 252 includes another retrieval module 266, the action module 270 and the MMR database 254 (a complete and more complex version). In one embodiment, if the query image cannot be recognized with the local MMR database 254, the client 250 sends an image for retrieval to the server 252 and that initiates an update of the local MMR database 254. Alternatively, the client 250 may contain an updated version of a database for one recognizer, but if the query image cannot be retrieved from the local MMR database 254, then a database for another retrieval algorithm may be streamed to the local MMR database 254.

Referring now to FIG. 21, another embodiment for the client 250 and the server 252 is illustrated. In FIG. 2I, the client 250 and the server 252 communicate with each other using MMS, SMS or email messages. The client 250 captures an image or video, preprocesses the captured image or video by running quality prediction, and sends one or more MMS, SMS or email messages including an image or video and/or metadata to the server 252 for processing. In one embodiment, the client 250 is software for performing these operations and generating the MMS, SMS or email message(s). In this embodiment, the client 250 includes: the capture module 260, the preprocessing and prediction module 272, and an email module 280. The capture module 260 is client software that performs camera image capture. The preprocessing and prediction module 272 processes the image produced by the capture module 260 as has been described above for other embodiments. For example, the preprocessing and prediction module 272 performs some preprocessing such as image binarization or feature extraction. This information can be included in the message instead of the image (e.g., binary data is converted into text data using a coding scheme such as base64 and sent as an SMS message). The email module 280 is client software that generates the MMS, SMS or email message(s) to be sent to the server 252 for recognition. In one embodiment, the MMS or email message(s) includes rich text, video, image, and audio in an Open Mobile Alliance (OMA) format. In another embodiment, the email module 280 generates and sends feature vectors encoded in one or more MMS or SMS messages as text or binary data. If sending binary data is not supported, it is sent as a media file (for example binary file with JPEG extension). In yet another embodiment, the email module 280 creates a standard compliant media file with binary data encoded in it (in metadata field or as pixels). The server 252 includes: the MMR database 254, the preprocessing module 262, the feature extraction module 264, the retrieval module 266, the send message module 268 and the action module 270. It should be noted that in this embodiment the image sent to the server 252 may be different than the captured image. For example, the image sent may be digitally enhanced, sharpened, or may be just binary data. The server 252 also includes a voice recognition system 290 and an audio database 292 for use in performing recognition on audio content included in SMS, MMS or email message sent by the client 250 the server 252. The use of the voice recognition system 290 and the audio database 292 are described in more detail below with reference to FIG. 25.

MMR Gateway 104

Referring now to FIG. 3, one embodiment of the MMR gateway 104 is shown. This embodiment of the MMR gateway 104 comprises a server 302, a Web server 304, a data store 306, a portal module 308, a log 310, one or more applications 312, an authentication module 314, an accounting module 316, a mail module 318 and an analytics module 320.

As noted above, one of the primary functions of the MMR gateway 104 is to communicate with many mobile devices 102 to receive retrieval requests and send responses including a status indicator (true=recognized/false=not recognized), a page identification number, a location on the page and other information such as hotspot data. A single MMR gateway 104 can respond to hundreds or millions of retrieval requests. For convenience and ease of understanding only a single MMR gateway 104 is shown in FIGS. 1 and 3, however, those skilled in the art will recognize that in other embodiments any number of MMR gateways 104 may be utilized to service the needs of a multitude of mobile devices 102. More particularly, the server 302 of the MMR gateway 104 is coupled to signal lines 132a-132n for communication with various mobile devices 102. The server 302 receives retrieval requests from the mobile devices 102 via signal lines 132a-132n and sends responses back to the mobile devices 102 using the same signal lines 132a-132n. In one embodiment, the retrieval request includes: a command, a user identification number, an image and other context information. For example, other context information may include: device information such as the make, model or manufacture of the mobile device 102; location information such as provided by a GPS system that is part of the mobile device or by triangulation; environmental information such as time of day, temperature, weather conditions, lighting, shadows, object information; and placement information such as distance, location, tilt and jitter.

The server 302 is also coupled to signal line 130 for communication with the computer 110. Again, for convenience and ease of understanding only a single computer 110 and signal line 130 are shown in FIGS. 1 and 3, but any number of computing devices may be adapted for communication with the server 302. The server 302 facilitates communication between the computer 110 and the portal module 308, the log module 310 and the applications 312. The server 302 is coupled to the portal module 308, the log module 310 and the applications 312 by signal line 330. As will be described in more detail below, the modules cooperate with the server 302 to present a web portal that provides a user experience for exchanging information. The Web portal 308 can also be used for system monitoring, maintenance and administration.

The server 302 processes the retrieval request and generates an image query and recognition parameters that are sent via signal line 134 to the MMR matching unit 106 for recognition. The server 302 also receives recognition responses from the MMR matching unit 106 via signal line 134. The server 302 also processes the retrieval request and sends information via signal line 330 to the other components of the MMR gateway 104 as will be described below. The server 302 is also adapted for communication with the MMR publisher 108 by signal line 138 and the MMR matching unit 106 via signal line 136. The signal line 138 provides a path for the MMR publisher 108 to send Web content for hotspots to the Web server 304 and to provide other information to the server 302. In one embodiment, the server 302 receives information from the MMR publisher 108 and sends that information via signal line 136 for registration with the MMR matching unit 106.

The web server 304 is a conventional type and is responsible for accepting requests from clients and sending responses along with data contents, such as web pages, documents and linked objects (images, etc.) The Web server 304 is coupled to data store 306 such as a conventional database. The Web server 304 is adapted for communication via signal line 234 to receive HTTP requests from any communication device across a network such as the Internet. The Web server 304 is also coupled to signal line 138 as described above to receive Web content associated with hotspots for storage in the data store 306 and then for later retrieval and transmission in response to HTTP requests. Those skilled in the art will understand that inclusion of the Web server 304 and data store 306 as part of the MMR gateway 104 is merely one embodiment and that the Web server 304 and the data store 306 may be operational in any number of alternate locations or configuration so long as the Web server 304 is accessible to mobile devices 102 and computers 110 via the Internet.

In one embodiment, the portal module 308 is software or routines operational on the server 302 for creation and presentation of the Web portal. The portal module 308 is coupled to signal line 330 for communication with the server 302. In one embodiment, the web portal provides an access point for functionality including administration and maintenance of other components of the MMR gateway 104. In another embodiment, the web portal provides an area where users can share experiences related to MMR documents. In yet another embodiment, the web portal is an area where users can access business applications and the log 310 of usage.

The log 310 is a memory or storage area for storing a list of the retrieval requests received by the server 302 from mobile devices 102 and all corresponding responses sent by the server 302 to the mobile devices. In another embodiment, the log 310 also stores a list of the image queries generated and sent to the MMR matching unit 106 and the recognition responses received from the MMR matching unit 106. The log 310 is coupled to signal line 330 for access by the server 302.

The one or more business applications 312 are software and routines for providing functionality related to the processing of MMR documents. In one embodiment the one or more business applications 312 are executable on the server 302. The business applications 312 can be any one of a variety of types of business applications adapted to utilize information related to the processing of retrieval quests and delivery of recognition responses such as but not limited to accounting, groupware, customer relationship management, human resources, outsourcing, loan origination, customer care, service relationships, etc.

The authentication module 314 is software and routines for maintaining a list of authorized users and granting access to the MMR system 110. In one embodiment, the authentication module 314 maintains a list of user IDs and passwords corresponding to individuals who have created an account in the system 100, and therefore, are authorized to use MMR gateway 104 and the MMR matching unit 106 to process retrieval requests. The authentication module 314 is communicatively coupled by signal line 330 to the server 302. But as the server 302 receives retrieval requests they can be processed and compared against information in the authentication module 314 before generating and sending the corresponding image query on signal line 134. In one embodiment, the authentication module 314 also generates messages for the server 302 to return to the mobile device 102 instances when the mobile device is not authorized, the mobile device has not established an account, or the account for the mobile device 102 is locked such as due to abuse or lack of payment.

The accounting module 316 is software and routines for performing accounting related to user accounts and use of the MMR system 100. In one embodiment, the retrieval services are provided under a variety of different economic models such as but not limited to use of the MMR system 100 under a subscription model, a charge per retrieval request model or various other pricing models. In one embodiment, the MMR system 100 provides a variety of different pricing models and is similar to those currently offered for cell phones and data networks. The accounting module 316 is coupled to the server 302 by signal line 330 to receive an indication of any retrieval request received by the server 302. In one embodiment, the accounting module 316 maintains a record of transactions (retrieval request/recognition responses) processed by the server 302 for each mobile device 102. Although not shown, the accounting module 316 can be coupled to a traditional billing system for the generation of an electronic or paper bill.

The mail module 318 is software and routines for generating e-mail and other types of communication. The mail module 318 is coupled by signal at 330 to the server 302. In one embodiment, the mobile device 102 can issue retrieval requests that include a command to deliver a document or a portion of a document or other information via e-mail, facsimile or other traditional electronic communication means. The mail module 318 is adapted to generate and send such information from the MMR gateway 104 to an addressee as prescribed by the user. In one embodiment, each user profile has associated addressees which are potential recipients of information retrieved.

The analytics module 320 is software and routines for measuring the behavior of users of the MMR system 100. The analytics module 320 is also software and routines for measuring the effectiveness and accuracy of feature extractors and recognition performed by the MMR matching unit 106. The analytics module 320 measures use of the MMR system 100 including which images are most frequently included as part of retrieval requests, which hotspot data is most often accessed, the order in which images are retrieved, the first image in the retrieval process, and other key performance indicators used to improve the MMR experience and/or a marketing campaign's audience response. In one embodiment, the analytics module 320 measures metrics of the MMR system 100 and analyzes the metrics used to measure the effectiveness of hotspots and hotspot data. The analytics module 320 is coupled to the server 302, the authentication module 314 and the accounting module 316 by signal line 330. The analytics module 320 is also coupled by the server 302 to signal line 134 and thus can access the components of the MMR matching unit 106 to retrieve recognition parameters, images features, quality recognition scores and any other information generated or used by the MMR matching unit 106. The analytics module 320 can also perform a variety of data retrieval and segmentation based upon parameters or criteria of users, mobile devices 102, page IDs, locations, etc.

In one embodiment, the MMR gateway 104 also includes a hotspot database 404. The hotspot database 404 is shown in FIG. 3 with dashed lines to reflect that inclusion in the MMR gateway 104 is an alternate embodiment. The hotspot database 404 is coupled by signal line 436 to receive the recognition responses via line 134. The hotspot database 404 uses these recognition responses to query the database and output via line 432 the hotspot content corresponding to the recognition responses. This hotspot content is sent to the server 302 so that it can be included with the recognition responses and sent to the requesting mobile device 102.

MMR Matching Unit 106

Referring now to FIGS. 4A and 4B, two embodiments for the MMR matching unit 106 will be described. The basic function of the MMR matching unit 106 is to receive an image query, send the image query for recognition, perform recognition on the images in the image query, retrieve hotspot information, combine the recognition result with hotspot information and send it back to the MMR gateway 104.

FIG. 4A illustrates a first embodiment of the MMR matching unit 106. The first embodiment of the MMR matching unit 106 comprises a dispatcher 402, a hotspot database 404, an acquisition unit 406, an image registration unit 408 and a dynamic load balancer 418. The acquisition unit 406 further comprises a plurality of the recognition units 410a-410n and a plurality of index tables 412a-412n. The image registration unit 408 further comprises an indexing unit 414 and a master index table 416.

The dispatcher 402 is coupled to signal line 134 for receiving an image query from and sending recognition results to the MMR gateway 104. The dispatcher 402 is responsible for assigning and sending an image query to respective recognition units 410a-410n. In one embodiment, the dispatcher 402 receives an image query, generates a recognition unit identification number and sends the recognition unit identification number and the image query to the acquisition unit 406 for further processing. The dispatcher 402 is coupled to signal line 430 to send the recognition unit identification number and the image query to the recognition units 410a-410n. The dispatcher 402 also receives the recognition results from the acquisition unit 406 via signal line 430. One embodiment for the dispatcher 402 will be described in more detail below with reference to FIG. 5.

An alternate embodiment for the hotspot database 404 has been described above with reference to FIG. 3 where the hotspot database is part of the MMR gateway 104. However, the preferred embodiment for the hotspot database 404 is part of the MMR matching unit 106 as shown in FIG. 4A. Regardless of the embodiment, the hotspot database 404 has a similar functionality. The hotspot database 404 is used to store hotspot information. Once an image query has been recognized and recognition results are produced, these recognition results are used as part of a query of the hotspot database 404 to retrieve hotspot information associated with the recognition results. The retrieved hotspot information is then output on signal line 134 to the MMR gateway 104 for packaging and delivery to the mobile device 102. As shown in FIG. 4A, the hotspot database 404 is coupled to the dispatcher 402 by signal line 436 to receive queries including recognition results. The hotspot database 404 is also coupled by signal line 432 and signal line 134 to the MMR gateway 104 for delivery of query results. The hotspot database 404 is also coupled to signal line 136 to receive new hotspot information for storage from the MMR publisher 108.

The acquisition unit 406 comprises the plurality of the recognition units 410a-410n and a plurality of index tables 412a-412n. Each of the recognition units 410a-410n has and is coupled to a corresponding index table 412a-412n. In one embodiment, each recognition unit 410/index table 412 pair is on the same server. The dispatcher 402 sends the image query to one or more recognition units 410a-410n. In one embodiment that includes redundancy, the image query is sent from the dispatcher 402 to a plurality of recognition units 410 for recognition and retrieval and the index tables 412a-n index the same data. In the serial embodiment, the image query is sent from the dispatcher 402 to a first recognition unit 410a. If recognition is not successful on the first recognition unit 410a, the image query is passed on to a second recognition unit 410b, and so on. In yet another embodiment, the dispatcher 402 performs some preliminary analysis of the image query and then selects a recognition unit 410a-410n best adapted and most likely to be successful at recognizing the image query. Those skilled in the art will understand that there are a variety of configurations for the plurality of recognition units 410a-410n and the plurality of index tables 412a-412n. Example embodiments for the acquisition unit 406 will be described in more detail below with reference to FIGS. 6A and 6B. It should be understood that the index tables 412a-412n can be updated at various times as depicted by the dashed lines 434 from the master index table 416.

The image registration unit 408 comprises the indexing unit 414 and the master index table 416. The image registration unit 408 has an input coupled to signal on 136 to receive updated information from the MMR publisher 108 and an input coupled to signal line 438 to receive updated information from the dynamic load balancer 418. The image registration unit 408 is responsible for maintaining the master index table 416 and migrating all or portions of the master index table 416 to the index tables 412a-412n (slave tables) of the acquisition unit 406. In one embodiment, the indexing unit 414 receives images, unique page IDs and other information; and converts it into index table information that is stored in the master index table. The indexing unit 414 also cooperates with the MMR publisher 108 to maintain a unique page identification numbering system that is consistent across image pages generated by the MMR publisher 108, the image pages stored in the master index table 416 and the page numbers used in referencing data in the hotspot database 404.

One embodiment for the image registration unit 408 is shown and described in more detail below with reference to FIG. 7.

The dynamic load balancer 418 has an input coupled to signal line 430 to receive the query image from the dispatcher 402 and the corresponding recognition results from the acquisition unit 406. The output of the dynamic load balancer 418 is coupled by signal line 438 to an input of the image registration unit 408. The dynamic load balancer 418 provides input to the image registration unit 408 that is used to dynamically adjust the index tables 412a-412n of the acquisition unit 406. In particular, the dynamic load balancer 418 monitors and evaluates the image queries that are sent from the dispatcher 402 to the acquisition unit 406 for a given period of time. Based on the usage, the dynamic load balancer 418 provides input to adjust the index tables 412a-412n. For example, the dynamic load balancer 418 may measure the image queries for a day. Based on the measured usage for that day, the index tables are modified and configured in the acquisition unit 406 to match the usage measured by the dynamic load balancer 418. The dynamic load balancer 418 implements the method described below with reference to FIG. 11.

FIG. 4B illustrates a second embodiment of the MMR matching unit 106. In the second embodiment, many of the components of the MMR matching unit 106 have the same or a similar function to corresponding elements of the first embodiment. Thus, like reference numbers have been used to refer to like components with the same or similar functionality. The second embodiment of the MMR matching unit 106 includes the dispatcher 402, the hotspot database 404, and the dynamic load balancer 418 similar to the first embodiment of the MMR matching unit 106. However, the acquisition unit 406 and the image registration unit 408 are different than that described above with reference to FIG. 4A. In particular, the acquisition unit 406 and the image registration unit 408 utilize a shared SQL database for the index tables and the master table. More specifically, there is the master index table 416 and a mirrored database 418 that includes the local index tables 412a-n. Moreover, a conventional functionality of SQL database replication is used to generate the mirror images of the master index table 416 stored in the index tables 412a-n for use in recognition. The image registration unit 408 is configured so that when new images are added to the master index table 416 they are immediately available to all the recognition units 410. This is done by mirroring the master index table 416 across all the local index tables 412a-n using large RAM (not shown) and database mirroring technology.

Dispatcher 402

Referring now to FIG. 5, an embodiment of the dispatcher 402 shown. The dispatcher 402 comprises a quality predictor 502, an image feature order unit 504 and a distributor 506. The quality predictor 502, the image feature order unit 504 and the distributor 506 are coupled to signal line 532 to receive image queries from the MMR gateway 104. The distributor 506 is also coupled to receive the output of the quality predictor 502 and the image feature order unit 504. The distributor 506 includes a FIFO queue 508 and a controller 510. The distributor 506 generates an output on signal line 534 that includes the image query and a recognition unit identification number (RUID). Those skilled in the art will understand that in other embodiments the image query may be directed to any particular recognition unit using a variety of means other than the RUID. As image queries are received on the signal line 532, the distributor 506 receives the image queries and places them in the order in which they are received into the FIFO queue 508. The controller 510 receives a recognizability score for each image query from the quality predictor 502 and also receives an ordering signal from the image feature order unit 504. Using this information from the quality predictor 502 and the image feature order unit 504, the controller 510 selects image queries from the FIFO queue 508, assigns them to particular recognition units 410 and sends the image query to the assigned recognition unit 410 for processing. The controller 510 maintains a list of image queries assigned to each recognition unit 410 and the expected time to completion for each image (as predicted by the image feature order unit 504). The total expected time to empty the queue for each recognition unit 410 is the sum of the expected times for the images assigned to it. The controller 510 can execute several queue management strategies. In a simple assignment strategy, image queries are removed from the FIFO queue 508 in the order they arrived and assigned to the first available recognition unit 410. In a balanced response strategy, the total expected response time to each query is maintained at a uniform level and query images are removed from the FIFO queue 508 in the order they arrived, and assigned to the FIFO queue 508 for a recognition unit so that its total expected response time is as close as possible to the other recognition units. In an easy-first strategy, images are removed from the FIFO queue 508 in an order determined by their expected completion times—images with the smallest expected completion times are assigned to the first available recognition unit. In this way, users are rewarded with faster response time when they submit an image that's easy to recognize. This could incentivize users to carefully select the images they submit. Other queue management strategies are possible. The dispatcher 402 also receives the recognition results from the recognition units 410 on signal line 530. The recognition results include a Boolean value (true/false) and if true, a page ID and a location on the page. In one embodiment, the dispatcher 402 merely receives and retransmits the data to the MMR gateway 104.

The quality predictor 502 receives image queries and generates a recognizability score used by the dispatcher 402 to route the image query to one of the plurality of recognition units 410. In one embodiment, the quality predictor 502 also receives as inputs context information and device parameters. The operation of the quality predictor 502 is described in more detail below with reference to FIGS. 18-21. In one embodiment, the recognizability score includes information specifying the type of recognition algorithm most likely to produce a valid recognition result.

The image feature order unit 504 receives image queries and outputs an ordering signal. The image feature order unit 504 analyzes an input image query and predicts the time required to recognize an image by analyzing the image features it contains. The difference between the actual recognition time and the predicted time is used to adjust future predictions thereby improving accuracy. In the simplest of embodiments, simple images with few features are assigned to lightly loaded recognition units 410 so that they will be recognized quickly and the user will see the answer immediately. In one embodiment, the features used by the image order feature unit 504 to predict the time are different than the features used by recognition units 410 for actual recognition. For example, the number of corners detected in an image is used to predict the time required to analyze the image. The feature set used for prediction need only be correlated with the actual recognition time. In one embodiment, several different features sets are used and the correlations to recognition time measured over some period. Eventually, the feature set that is the best predictor and lowest cost (most efficient) would be determined and the other feature sets could be discarded. The operation of the image feature order unit 504 is described in more detail below and can be better understood with reference to FIG. 12.

Acquisition Unit 406

Referring now to FIGS. 6A and 6B, embodiments of the acquisition unit 406 will be described.

As shown in FIG. 6A, the recognition unit 410/index table 412 pairs are grouped according to the content that in the index tables 412. In particular, the first group 602 of recognition units 410a-d and index tables 412a-d is used to index the pages of a publication such as a newspaper for a current day. For example, four of the eight recognition units 410 are used to index content from the current day's newspaper because most of the retrieval requests are likely to be related to the newspaper that was published in the last 24 hours. A second group 614 of recognition units 410e-g and corresponding index tables 412e-g are used to store pages of the newspaper from recent past days, for example the past week. A third group 606 of recognition unit 410h and index table 412h is used to store pages of the newspaper from older past days, for example for the past year. This allows the organizational structure of the acquisition unit 406 to be optimized to match the profile of retrieval requests received. Moreover, the operation of the acquisition unit 406 can be modified such that a given image query is first sent to the first group 612 for recognition, and if the first group 612 is unable to recognize the image query, it is sent to the second group 614 for recognition and so on.

It should be noted that the use of four recognition units 410 and index tables 412 as the first group 612 is merely be by way example and used demonstrate a relative proportion as compared with the number of recognition units 410 and index tables 412 in the second group 614 and the third group 616. The number of recognition units 410 and index tables 412 in any particular group 612, 614 and 616 may be scaled the modified based on the total number of recognition units 410 and index tables 412. Furthermore, the number of recognition units 410 and index tables 412 in any particular group 612, 614 and 616 may be adapted so that it matches the profile of all users sending retrieval request to the acquisition unit 406 for a given publication.

FIG. 6B illustrates a second embodiment for the acquisition unit 406 where the recognition units 410 and index tables 412 are partitioned based upon the type of recognition algorithm they implement. In the second embodiment, the recognition units 410 are also coupled such that the failure of a particular recognition unit to generate a registration result causes the input image query to be sent to another recognition unit for processing. Furthermore, in the second embodiment, the index tables 412 include feature sets that are varied according to different device and environmental factors of image capture devices (e.g., blur).

The second embodiment of the acquisition unit 406 includes a plurality of recognition units 410a-410e, a plurality of the index tables 412a-412e and a result combiner 610. In this embodiment, the recognition units 410a-410e each utilizes a different type of recognition algorithm. For example, recognition units 410a, 410b and 410c use an invisible junction algorithm; recognition unit 410d uses a brick wall coding algorithm; and recognition unit 410e uses a path coding algorithm for recognition and retrieval of page numbers and locations. Recognition units 410a, 410d and 410e each have an input coupled signal line 430 by signal line 630 for receiving the image query. The recognition results from each of the plurality of recognition units 410a-410e are sent via signal lines 636, 638, 640, 642 and 644 to the result combiner 610. The output of the result combiner 610 is coupled to signal line 430.

In one embodiment, the recognition units 410a, 410b and 410c cooperate together with index tables 1, 2 and 3, 412a-412c each storing image features corresponding to the same pages but with differing levels of blur caused by device and environmental factors. For example, index table 1412a may store image features for pristine images of pages such as from a PDF document, while index table 2412b stores images of the same pages but with a first level of blur and index table 3412c stores images of the same pages but with the second level of blur. In one embodiment, the index tables 1, 2 and 3, 412a-412c are quantization trees. The first recognition unit 410a receives the image query via signal line 630. The first recognition unit 410a comprises an invisible junction feature extractor 602 and a retriever 604a. The invisible junction feature extractor 602 receives the image query, extracts the invisible junction features and provides them to the retriever 604a. The retriever 604a uses the extracted invisible junction features and compares them to the index table 1412a. If the retriever 604a identifies a match, the retriever 604a sends the recognition results via signal line 636 to the result combiner 610. If however, the retriever 604a was unable to identify a match or identifies a match with low confidence, the retriever 604a sends the extracted invisible junction features to the retriever 604b of the second recognition unit 410b via signal line 632. It should be noted that since the invisible junction features have already been extracted, the second recognition unit 410b does not require an invisible junction feature extractor 602. The second recognition unit 410b performs retrieval functions similar to the first recognition unit 410a, but cooperates with index table 2412b that has invisible junction features for slightly blurry images. If the retriever 604b identifies a match, the retriever 604b sends the recognition results via signal line 638 to the result combiner 610. If the retriever 604b of the second recognition unit 410b is unable to identify a match or identifies a match with low confidence, the retriever 604b sends the extracted invisible junction features to the retriever 604c of the third recognition unit 410c via signal line 634. The retriever 604c then performs a similar retrieval function but on index table 3412c. Those skilled in the art will understand that while one pristine set of images and two levels of blur are provided, this is only by way of example and that any number of additional levels of blur from 0 to n may be used.

The recognition units 410d and 410e operate in parallel with the other recognition units 410a-c. The fourth recognition unit 410d comprises a brick wall coding feature extractor 606 and a retriever 604d. The brick wall coding feature extractor 606 receives the image query and bounding boxes, parses the bounding boxes and generates brick wall coding features. These brick wall coding features are provided to the retriever 604d and the retriever 604d compares them to the features stored in index table 4412d. In one embodiment, index table 4412d is a hash table. The retriever 604d identifies any matching pages and returns the recognition results to the result combiner 610 via signal line 642. The fifth recognition unit 410e operates in a similar manner but for path coding. The fifth recognition unit 410e comprises a path coding feature extractor 608 and a retriever 604e. The path coding feature extractor 608 receives the image query and bounding boxes, parses the image and generates path coding features that are provided to the retriever 604e and the retriever 604e compares them to features stored in the index table 5412e. In one embodiment, the index table 5412e is a SQL database of character strings. The retriever 604e identifies any matching strings and returns the recognition results to the result combiner 610 via signal line 644.

The result combiner 610 receives recognition results from the plurality of recognition units 410a-e and produces one or a small list of matching results. In one embodiment, each of the recognition results includes an associated confidence factor. In another embodiment, context information such as date, time, location, personal profile or retrieval history are provided to the result combiner 610. These confidence factors along with other information are used by the result combiner 610 to select the recognition results most likely to match the input image query. The result combiner 610 implements the functionality described below with reference to the methods of FIG. 22-24.

Image Registration Unit 408

FIG. 7 shows an embodiment of the image registration unit 408. The image registration unit 408 comprises a blurry generator 702, a plurality of invisible junction feature extractors 704a-c, a plurality of invisible junction index table updaters 706a-c, a brick wall coding feature extractor 708, a brick wall coding index table updater 710, a path coding feature extractor 712, a path coding index table updater 714 and a plurality of master index tables 416a-e. The image registration unit 408 also includes other control logic (not shown) that controls the updating of the working index tables 412 from the master index table 416. The image registration unit 408 can update the index tables 412 of the acquisition unit 406 in a variety of different ways based on various criteria such performing updates on a periodic basis, performing updates when new content is added, performing updates based on usage, performing updates for storage efficiency, etc.

The blurry generator 702 has an input coupled in signal line 730 to receive an image and a page identification number. The blurry generator 702 has a plurality of outputs and each output is coupled by signal lines 732, 734 and 736 to invisible junction feature extractors 704a-c, respectively. The blurry generator 702 passes a pristine image and the page identification number to the output and signal line 732. The blurry generator 702 then generates an image with a first level of blurriness and outputs it and the page identification number on signal line 734 to invisible junction feature extractor 704b, and another image with a second level of blurriness and outputs it and page identification number on signal line 736 to invisible junction feature extractor 704c. The blurry generator 702 implements functionality described below with reference to FIGS. 13 and 14.

The invisible junction feature extractors 704 receive the image and page ID, extract the invisible junction features from the image and send them along with the page ID to a respective invisible junction index table updater 706. The outputs of the plurality of invisible junction feature extractors 704a-c are coupled to input of the plurality of invisible junction index table updaters 706a-c. For example, the output of invisible junction feature extractor 704a is coupled to an input of invisible junction index table updater 706a. The remaining invisible junction feature extractors 704b-c are similarly coupled to respective invisible junction index table updaters 706b-c. The invisible junction index table updaters 706 are responsible for formatting the extracted features and storing them in a corresponding master index table 416. While the master index table 416 is shown as five separate master index tables 416a-e, those skilled in the art will recognize that all the master index tables could be combined into a single master index table or into a few master index tables. Once the invisible junction index table updaters 706 have stored the extracted features in the index table 416, they issue a confirmation signal that is sent via signal lines 740 and 136 back to the MMR publisher 108.

The brick wall coding feature extractor 708 and the path coding feature extractor 712 operate in a similar fashion and are coupled to signal line 738 to receive the image, a page identification number and bounding box information. The brick wall coding feature extractor 708 extracts information from the input needed to update its associated index table 416d. The brick wall coding index table updater 710 receives the extracted information from the brick wall coding feature extractor 708 and stores it in the index table 416d. The path coding feature extractor 712 and the path coding index table updater 714 operate in a like manner but for path coding. The path coding feature extractor 712 also receives the image, a page number and bounding box information via signal line 738. The path coding feature extractor 712 extracts path coding information and passes it to the path coding index table updater 714. The path coding index table updater 714 stores the information in index table 5416e. The architecture of the registration unit 408 is particularly advantageous because it provides an environment in which the MMR publisher 108 can automatically update the index tables simply by providing images and page numbers to the image registration unit 408 and the index tables are updated automatically. MMR Publisher 108

An embodiment of the MMR publisher 108 is shown in FIG. 8. The MMR publisher 108 comprises conventional publishing software 802, a pre-press software plug-in for registration and annotation 804 and a hotspot creator 806. The MMR publisher 108 is coupled to signal line 138 to connect with the image registration unit 408 and the hotspot database 404 (such as via the server 302).

The conventional publishing software 802 is software for creating digital content including text, graphics and pictures. Examples of the conventional publishing software used in the production and distribution of newspapers include Adobe Acrobat manufactured and sold by Adobe Inc. of San Jose, Calif. or QuarkXPress manufactured and sold by Quark, Inc. in Denver, Colo. The conventional publishing software 802 may be other types of proprietary software owned by large publishing companies.

The pre-press plug-in for registration and annotation 804 is software and routines for interfacing with the conventional publishing software 802 and generating additional information used by the image registration unit 408 so that the content can be automatically uploaded to the acquisition unit 406. For example, the prepress plug-in for registration and annotation communicates and interfaces with the image registration unit 408 to maintain a unique page identification numbering system that is consistent across image pages generated by the conventional publishing software 802, the image pages stored in the master index table 416 and the page numbers used in referencing data in the hotspot database 404. The prepress plug-in for registration 804 also generates bounding boxes for image pages generated by the conventional publishing software 802; the bounding boxes are subsequently used by the image registration unit 408 for certain types of encoding. The pre-press plug-in for registration and annotation 804 also analyzes the images provided by the conventional publishing software 802 and ensures that the files are of a type usable by the feature extractors 704, 708712.

The hotspot creator 806 is an authoring tool for creating hotspots. Hotspots identify the (x,y) coordinates of polygons on a document image and links to electronic data such as URL's that are associated with each polygon. In one embodiment, hotspots are annotations in Acrobat PDF files that include the (x,y) coordinates of polygons on a document and links to electronic data such as URL's. The hotspot creator 806 can be used to create a hotspot (a “hotspot” is a polygon on an image), associate the hotspot with a particular page in a document, and a particular location on the page, associate zero or more links with each hotspot, and generate and send the hotspot files to the server 302 for storage in the hotspot database 404. A hotspot file lists each hotspot, the coordinates of its polygon, and any links associated with it. The hotspot file can be saved as a separate file or equivalently the same data can be embedded in the document source file. The hotspot creator 806 can be a stand-alone software application that reads a source document such as Word, PDF, or an image format such as tiff, and provides a user interface that lets the user draw polygons on the document, add links to each of the hotspots, and save the hotspot files. The hotspot creator 806 can also be packaged as a plug-in for existing document authoring applications such as Word, Acrobat, Quark Express, etc. and can be designed so that the user can define polygons on the document, add links, and save the hotspot files (or, equivalently the source file with the hotspot data embedded in it). The hotspot creator 806 can also be packaged as a software application that extracts links from existing documents and saves them in the hotspot file. For example, annotations in PDF files that include polygon coordinates and links to electronic data can be removed from the PDF and saved separately in a hotspot file.

Methods

FIG. 9 is a flowchart of a general method for generating and sending a retrieval request and processing the retrieval request with an MMR system 100. The method begins with the mobile device 102 capturing 902 an image. A retrieval request that includes the image, a user identifier, and other context information is generated by the mobile device 102 and sent 904 to the MMR gateway 104. The MMR gateway 104 processes 906 the retrieval request by extracting the user identifier from the retrieval request and verifying that it is associated with a valid user. The MMR gateway 104 also performs other processing such as recording the retrieval request in the log 310, performing any necessary accounting associated with the retrieval request and analyzing any MMR analytics metrics. Next, the MMR gateway 104 generates 908 an image query and sends it to the dispatcher 402. The dispatcher 402 performs load-balancing and sends the image query to the acquisition unit 406. In one embodiment, the dispatcher 402 specifies the particular recognition unit 410 of the acquisition unit 406 that should process the image query. Then the acquisition unit 406 performs 912 image recognition to produce recognition results. The recognition results are returned 914 to the dispatcher 402 and in turn the MMR gateway 104. The recognition results are also used to retrieve 916 hotspot data corresponding to the page and location identified in the recognition results. Finally, the hotspot data and the recognition results are sent 918 from the MMR gateway 104 to the mobile device 102.

Referring now to FIG. 10, a method for registration of images will be described. The method begins by generating 1002 images by using conventional publishing software 802. The images are then augmented 1004 with bounding boxes, hotspot data and page identification numbers using the prepress plug-in for registration and annotation 804. The augmented images are then sent 1006 to the MMR gateway 104. The MMR gateway 104 extracts the hotspot data and adds it to the hotspot database 404. The MMR gateway 104 then sends 1008 the image, page number and bounding boxes to the image registration unit 408. In an alternate embodiment as depicted in FIG. 10 by the dashed line, the augmented images can be sent to the image registration unit 408 without going through the MMR gateway 104. The indexing unit 414 and then performs 1010 feature extraction on the images. Depending on the embodiment, feature extraction may be performed for a single recognition algorithm, multiple different recognition algorithms or the same recognition algorithm on different data sets. The features extracted from step 1010 are then used to update 1012 the master index table(s) 416a-e. Finally, the changes that were applied to the master index table(s) 416a-e are migrated 1014 to working index tables 412a-n of the acquisition unit 406. This method is particularly advantageous because images need only be provided to the image registration unit 408 and the image registration unit 408 automatically updates the master index table 416, and automatically migrates the changes to the working index tables 412 of the acquisition unit 406.

Referring now to FIG. 11, a method for dynamic load balancing will be described. This method relates generally to the operations performed by the dynamic load balancer 418 of FIG. 4A. The method begins by monitoring 1102 image queries and recognition results transferred between the dispatcher 402 and the acquisition unit 406 on signal line 430. The dynamic load balancer 418 monitors the image queries and corresponding recognition results for some pre-defined period such as a day. In particular, the actual distribution of images successfully found and in which index tables 412a-n they were found is monitored. The dynamic load balancer 418 generates 1104 load balancing control signals specifying a configuration for the working index tables 412a-n of the acquisition unit 406. For example, based on usage measured by the dynamic load balancer 418 for the prior day, expected usage can be predicted and the working index tables 412a-n of the acquisition unit 406 loaded with content appropriately. For example, n index tables are loaded with the newspaper content for the current day while m index tables are loaded with the newspaper content of past days. Thus there are a total of n+m servers. Based on past history, the present invention makes it expects n/(n+m) queries will be for the newspaper of the current day. The indexing unit 414 of the image registration unit 408 then receives new images for the current day's newspaper. Based upon the generated load balancing signals generated in step 1104, some (e.g., n) of the working index tables 412a-n are loaded with the new images while the existing information in the working index tables 412a-n are reconfigured such that they can be stored in the remaining (e.g., m=all working index tables−n) working index tables 412a-n that are not utilized to store the new images.

In one embodiment, operation of the acquisition unit 406 is modified or optimized to match the configuration of the working index tables 412a-n. In particular, the acquisition unit 406 upon receiving an image query, first attempts to recognize 1108 the image query with recognition units 410 and index tables 412 configured with the images of the current day's newspaper. Next, the method determines 1110 whether recognition was successful. If so the method returns 1118 the result and a method is complete. If not, the method attempts to recognize 1112 the image query with recognition units 410 and index tables 412 configured with images of past days newspapers. Again the method determines 1114 whether recognition was successful. If so, the method returns 1118 the result and the method is complete. If not, the method returns 1116 a signal indicating that recognition was unsuccessful and the method is complete. While the load balancing method was described above with reference to use of a periodic division of the data for a newspaper, those skilled in the art will understand that the load-balancing method may be applied for dividing the data based on any other usage criteria and that the image data may be any type of images other than newspapers.

Referring now to FIG. 12, one embodiment of a method for performing image feature-based ordering will be described. This functionality of this method is generally implemented by the image feature order unit 504 of the dispatcher 402. The method begins by receiving 1202 an image query. Next, the image feature order unit 504 of the dispatcher 402 analyzes 1204 the image features in the image query. It should be noted that the image features used in the analysis of step 1204 need not be the same image features used by the recognition units 410. It is only necessary to correlate the image features to recognition. In yet another embodiment, several different feature sets are used and correlations are measured over time. Eventually, the feature set that provides the best predictor and has the lowest computational cost is determined and the other feature sets are discarded. The image feature order unit 504 measures 1206 the time required to recognize the image features and thereby generates a predicted time. Next, the method creates 1208 correlations between features and predicted times. Next, the method measures 1210 the time actually required by the acquisition unit 406 to recognize the image query. This time required by the acquisition unit 406 is referred to as an actual time. Then the image feature order unit 504 adjusts 1212 the correlations generated in step 1208 by the actual time. The adjusted correlations are then used 1214 to reorder and assign image queries to recognition units. For example, simple images with few features are assigned to lightly loaded servers (recognition units 410 and index table 412 pairs) so that they will be recognized quickly and the user will receive the answer quickly. While the method shown in FIG. 12 illustrates the process for an image or a small set of images, those skilled in the art will recognize that once many images have been processed with the above method, a number of correlations will be created and the image feature order unit 504 essentially learns the distribution of image features against processing time and then the controller 501 of the distributor 506 can use the distribution to load balance and redirect image queries with particular image features accordingly. After the correlations are adjusted 1212, the new image-based feature ordering measurements can be used immediately in the previously described queue management strategies. The simple assignment strategy would simply use the new predictions. The balanced response strategy would re-balance the queues of requests pending for each recognition unit and optionally move requests between queues to maintain a uniform expected response for each recognition unit 410. The easy first strategy would simply use the new predictions when it inspected the incoming FIFO queue 508.

Blurry Images

Referring now to FIGS. 13-17, a method for automatically adapting the MMR system 100 for the characteristics of the image capture devices will be described. Recognition systems are often trained on pristine images of the objects they should recognize. However, handheld image capture devices and the environment in which they are used produce images that are much different. FIGS. 13-17 describe a method for automatically adapting the MMR system 100, originally designed for pristine object images, to images produced by a variety of capture devices as they are commonly used. Basically, the method trains N instances of a recognition algorithm on N different sets of data. The N data sets are chosen based on the ability of the recognition units they produce to successfully recognize a device training (DT) image set that represents the images a that device will produce when used in practice. Then, a query image is recognized with each instance until one of them produces a decision. These adaptations greatly enhance the recognition accuracy of MMR system 100. While the present invention will now be described in the context of adapting the MMR system 100 for blur, blur is only one characteristic that is used by way of example to illustrate the principles of the present invention. Any characteristic of the image capture device could alternatively be modeled to simulate actual variations in that characteristic, a data set created and the system 100 adapted to recognize images with such variations in a characteristic.

FIG. 13 shows one embodiment for a general method of adapting the MMR system 100 for blur introduced by the mobile device 102. The process begins with device training 1302 and data capture. One embodiment for device training is described in more detail below with reference to FIG. 14. Once a set of training data has been created, the method performs initialization 1304 and creates classifiers. Embodiments for initialization and classifier creation 1304 are described below with reference to FIGS. 15A and 15B. Once a set of classifiers has been created, the method identifies 1306 the classifier that recognizes the greatest number of images correctly. In one embodiment this is accomplished by performing a greedy search as described below with reference to FIG. 16. Then the identified classifier is hypothesized 1308 and tested. In other words, the classifier is modified in an attempt to increase the number of images it can recognize and those modifications are validated. One embodiment for this testing is described below with reference to FIG. 17. Finally, the method updates 1310 the index tables 412 and recognition units 410 based on the classifier(s) that has been hypothesized and tested. In another embodiment, the method of FIG. 13 is combined with a method for monitoring the performance of the recognition algorithm as it runs and determines whether a new instance of the recognition algorithm should be added or whether a current instance should be replaced by performing the method of FIG. 13.

Referring now to FIG. 14, one embodiment of a method for creating a set of training data will be described. In general, creating a set of training data requires generation of a data set that spans the range of placement characteristics and environmental factors with respect to objects. The method collects a device training (DT) data set for the range of placement characteristics and environmental factors with respect to the objects. Each image with the measurement for each placement characteristic and environmental factor and added to the set.

The method begins by determining 1402 an image capture device, an object set (O), an environmental characteristic set (E) and a device placement characteristic set (P). The present invention assumes that the following have been identified: a given capture device, a representative set of objects (paper documents in the case of invisible junctions), a set of environmental factors (e.g., lighting, shadows, object deformation, temperature, etc.), and a set of placement characteristics (e.g., distance, rotation, tilt, jitter, etc.). For example, the given capture device may be a commercially available cell phone that includes a camera such as the iPhone from Apple Computer, Inc. or the Blackberry from Research In Motion. The object set can be paper newspaper pages with different X-Y locations on each page. The environmental characteristics and corresponding values such as light=florescent, sunlight, etc.; shadow=soft, sharp, etc. The placement characteristics can include values such as distance=1″, 2″, . . . ″; tilt=0 degrees, 5 degrees, 7 degrees; . . . .

Next, the method retrieves 1404 an object (o) from the object set (O); retrieves 1406 an environmental characteristic (e) from the environmental characteristic set (E); retrieves 1408 a device placement characteristic (p) from the device placement characteristic set (P). Then the method captures 1410 images of the object (o) in the environmental characteristic (e) for each value of the device placement characteristic (p). The images are tagged 1412 with their values of o, e and p. The tagged images are then stored 1414 in the data set (DT). The method then proceeds to step 1416 determine whether there are any more environmental characteristics in the environmental characteristic set (E). If so, the method returns to step 1406 to retrieve another environmental characteristic and then it captures, tags and stores images with that environmental characteristic in the data set until all the environmental characteristics in the data set have been processed. On the other hand, if there are no more environmental characteristics in step 1416, the method proceeds to step 1418 to determine whether there are any more objects (o) in the object set (O). If so, the method returns to step 1404 to retrieve another object and proceeds to repeat steps 1406 to 1416 for the retrieved object. If not the method is complete and ends having created and stored a data set with all possible combinations of objects, environmental characteristics and device placement characteristics. Those skilled in the art will recognize that this process can be automated to automatically perform the steps of FIG. 14 whenever a new device is added or detected.

Referring now to FIG. 15A, a generalized version of a method for initialization 1302 and generation of the classifier is shown. The method begins by defining 1502 a range and sampling interval for the noise factors (e.g., focus blur, motion blur, dynamic range, etc.). This method generates 1504 a classifier at each point in a multidimensional space. Each classifier is then applied 1506 to the data set (DT). Finally, a performance of the classifier on the data set is recorded 1508.

Referring now to FIG. 15B another embodiment of the method for initialization 1302 and generation of classifiers is shown. The method FIG. 15B provides an example of classifier generation where the noise is Gaussian blur σ, x motion blur and y motion blur. The method begins by defining 1520 the range and sampling interval for the Gaussian blur σ, x motion blur and y motion blur. For example, the Gaussian blur σ equals s0 to sg by interval si; the motion blur in the x direction, dx, equals dx0 to dxx by interval dxi; and the motion blur in the y direction, dy, equals dy0 to dyy by interval dyi. Next the method applies 1522 the Gaussian blur σ, x motion blur and y motion blur to a pristine image set (P) to produce image set P′. For example, for each pristine object image p in the pristine image set P, this step applies Gaussian blur σ, s0 to sg for each interval si, x motion blur dx0 to dxx for each interval dxi and y motion blur dy0 to dyy by interval dyi, and adds the resulting images to image set P′. Next, the method generates 1524 a classifier from P′. For example, the method generates a classifier C for sigma, dx, dy for a point in a multidimensional space. The method then applies the classifier C sigma, dx, dy to recognize 1526 the images in training set DT. The method records 1528 the classifier performance including the number of images recognized, the identity of the images and an average confidence score, for example the average number of inliers for invisible junctions. Then the classifier C is added to a classifier results set (CR). Next, the method determines 1530 whether the classifier is the best performing and if so identifies 1530 the classifier as such (best classifier=(sigma, dx, dy)). For example, the classifier is the best performing if it has the highest number of images recognized and the highest average confidence score among all the classifiers tested up to this point. The method next determines 1532 whether there are any additional classifiers. In other words, the method determines whether there are any points in the multi-dimensional space of possible values for Gaussian blur, x motion blur and y motion blur for which a classifier has not been generated. If so, the method returns to step 1522 and generates a classifier for one of those points and repeats steps 1524 to step 1532. On the other hand, if there are no additional classifiers to be generated the method is complete and ends.

Referring now to FIG. 16 a method for finding a classifier that recognizes the greatest number of images will be described. Basically, the method finds the classifiers that recognize the most “unrecognized” images, adds it to the solution set, and considers those images “recognized.” This process is repeated until either N classifiers are determined or the number of newly “recognized” images is less than a threshold.

The method begins by setting 1602 the minimum number of classifiers N required and setting all the device training images as “unrecognized.” Next, the method retrieves 1604 a classifier from the classifier set CR. Then the method determines 1606 the images from the device training set that are recognized by the classifier and an average confidence score for the recognized images. A classifier recognition score is then determined using the number of new images recognized and average confidences scores for those new images. If the classifier recognition score is the highest, then a maximum score is set 1608 to this classifier's score, a best classifier is set to have the values of sigma, dx and dy of this classifier, and the solution set is defined as including the images recognized by this classifier. Next, the method determines 1610 whether there are more classifiers in the classifier set CR. If so, the method returns to step 1604 and proceeds to repeat steps 1606 and 1608. If not, the method determines 1612 whether this new “best” classifier significantly improves the expected performance of current solution. It does this by determining whether the number of newly recognized images is less than a threshold or the total number of recognized images is equal to the device training set. If either condition is true, the method is complete. Otherwise, the method proceeds to step 1614 and increments a variable CF representing the number of classifiers found by one. The method adds the new “best” classifier to classifier set CS, adds the new images recognized by the classifier to the solution set and resets the maximum score to zero. Then the method removes 1618 the “best” classifier from the classifier set CR. Finally, the method determines whether the number of classifiers found is greater than or equal to N, the number of classifiers desired for a working classifier set. If not, then method returns to step 1604 to repeat the process for the classifier set CR from which the best classifier has just been removed. If so, the method is complete and ends.

Referring now to FIG. 17 a method for hypothesizing and testing will be described. Once the best classifiers have been determined, the present invention intends to improve recognition by modifying the classifiers. The method begins by determining 1702 the unrecognized images in the device training set. For example, this can be done by removing all the images recognized in the method of FIG. 16 from device training set (unrecognized images=DT−GS), where GS=the Solution Set found in FIG. 16. The method retrieves 1704 a selected unrecognized image. Next, the method finds 1706 the closest pair of recognized images that match different classifiers where distance is determined by comparing placement characteristics and environmental factors. In one embodiment, this step is performed by finding pair of images (i1, i2) in GS such that: a) i1 and i2 are recognized by different classifiers; b) distance(u,i1) is smallest over all images in GS; c) distance(u,i2) is second smallest over all images in GS subject to condition 1; and d) the distance between the two images is determined by comparing the object, environmental conditions, and placement characteristics for each one. In the simplest case, all objects and environmental conditions are considered to be the same and the distance is determined by the L2 norm on the placement characteristics, normalized for each dimension. Then the method generates 1708 a new classifier from noise characteristics that are half way between those of each member of the pair, and grades the new classifier. In one embodiment, the method generates the new classifier based on the pair of images i1 and i2. For example, the method starts with sigma=(sigma of i1+sigma of i2)/2; dx=(dx of i1+dx of i2)/2; dy=(dy of i1+dy of i2)/2. Then for each pristine object image p in training set P Gaussian blur sigma, motion blurs dx and dy are applied to p and the result added to P′. Then a modified classifier C sigma, dx, dy (P′) is generated. Next the modified classifier C sigma, dx, dy(P′) is used to recognize the unrecognized images (DT-GS) and the method records the number of images recognized, identity of images, and average confidence score (avg. # inliers for IJ). The new classifier is added 1710 to a set of new classifiers. Next, the method determines 1712 whether there are more unrecognized images. If so, the method returns to 1704 to retrieve another unrecognized image and then repeat steps 1706, 1708, 1710 and 1712 for that unrecognized image. Next, the method determines 1714 whether the classifier recognition score is above a threshold. If so, the method either adds 1716 the classifier to the solution set (if the solution set size is less than N) or adds it to the multidimensional space; and the method is complete. If not, the method continues subdividing 1718 the noise factor space until the difference is below threshold, and then returns to step 1704 to generate a new classifier.

Referring now to FIGS. 18-21, an embodiment of the quality predictor 502 and its operation will be described in more detail. The quality predictor 502 produces a recognizability score (aka Quality Predictor) that can be used for predicting whether or not an image is a good candidate for a particular available image/recognition algorithm. An image may not be recognizable based on many reasons, such as motion blur, focus blur, poor lighting, and lack of sufficient content. The goal of computing a recognizability score is to label the recognizable images as “poor quality,” and label recognizable images as “good quality.” Besides this binary classification, the present invention also outputs a “recognizability score” where images are assigned a score based on the probability of their recognition.

The quality predictor 502 will now be described with reference to an embodiment in which the quality predictor 502 is part of the dispatcher 402 as has been described above and is depicted in FIG. 5. In this embodiment, the quality predictor 502 provides a recognizability score as input to the distributor 506 that decides which recognition unit 410 (and thus which recognition algorithm to run). However, those skilled in the art will realize that there are numerous system configurations in which the quality predictor 502 and the recognizability score are useful and advantageous. In a second embodiment, the quality predictor 502 is run on a capture device (mobile device 102 phone, digital camera, computer 110) to determine if the quality of the captured image is sufficient to be recognized by one of recognition units 410 of the MMR matching unit 106. If the quality of the captured image is sufficient, it is sent to the MMR matching unit 106, if not, the user is simply asked to capture another image. Alternatively, the captured image and the quality predictor score are shown to the user and he/she decides whether it should be submitted to the MMR matching unit 106. In a third embodiment, the quality predictor 502 is part of the result combiner 610 where there are multiple recognition units 410 and the recognizability score determines how the recognition results are evaluated. In a fourth embodiment, the quality predictor 502 is part of the indexing unit 414 and computation of a recognizability score precedes the indexing process, and the score is used in deciding which indexer/indexers need to be used for indexing the input document page. For example, if the recognizability score is low for the image to be indexed using the BWC algorithm, then the image may be indexed using only the IJ algorithm. Further, the same quality predictor can be used for both indexing and recognition. In a fifth embodiment, the quality predictor 502 is used before the “image capture” process on a mobile device 102. The recognizability score is computed prior to capturing the image and device captures an image only if the recognizability score is higher than a threshold. The quality predictor 502 can be embedded in a camera chip and can be used to control the camera's hardware or software. For example, camera aperture, exposure time, flash, macro mode, stabilization, etc. can be turned on based on the recognition units 410 requirements and the captured image. For example, BWC can recognize blurry text images and capturing blurry images can be achieved by vibrating the camera phone.

As shown in FIG. 18, one embodiment of the quality predictor 502 comprises recognition algorithm parameters 1802, a vector calculator 1804, a score generator 1806 and a scoring module 1808. The quality predictor 502 has inputs coupled to signal line 532 to receive an image query, context and metadata, and device parameters. The image query may be video frames, a single frame or image features. The context and metadata includes time, date, location, environmental conditions, etc. The device parameters include brand, type, macro block on/off, gyro or accelerometer reading, aperture, time, exposure, flash, etc. Additionally, the quality predictor 502 uses certain parameters of the recognition algorithm parameters 1802. These parameters of the recognition algorithm parameters 1802 can be provided to the quality predictor 502 from the acquisition unit 406 or the image registration unit 408. The vector calculator 1804 computes quality feature vectors from the image to measure its content and distortion, such as its blurriness, existence and amount of recognizable features, its luminosity, etc. The vector calculator 1804 computes any number of quality feature vectors from one to n. One embodiment of the vector calculator 1804 is described below with reference to FIG. 19. In some cases, the vector calculator 1804 requires knowledge of the recognition algorithm(s) to be used, and the vector calculator 1804 is coupled by signal line 1820 to the recognition algorithm parameters 1802. For example, if an Invisible Junctions algorithm is employed, the vector calculator 1804 computes how many junction points present in the image as a measure of its recognizability. All or some of these computed features are then input to score generator 1806 via signal line 1824. The score generator 1806 is also coupled by signal line 1822 to receive recognition parameters for the recognition algorithm parameters 1802. The output of the score generator 1806 is provided to the scoring module 1808. The scoring module 1808 generates a recognition score using the recognition scores provided by the score generator 1806 and applies weights to those scores. In one embodiment, the result is a single recognizability score. In another embodiment, the result is a plurality of recognizability scores ranked from highest to lowest.

Referring now to FIG. 19, an embodiment of the vector calculator 1804 in accordance with the present invention is shown. The vector calculator 1804 comprises a blur feature module 1902, a content amount feature module 1904, a luminosity feature module 1906, a bleed through feature module 1908, a coding artifacts feature module 1910, a perspective distortion feature module 1912, a camera noise feature module 1914, a text quality feature module 1916, an object detection feature module 1918, a recognition algorithm feature module 1920 and a robustness feature module 1922. Those skilled in the art will realize that the vector calculator 1804 they include various other feature modules and the embodiment of FIG. 19 is only one example. Other embodiments may have more or fewer modules than those depicted in FIG. 19. The vector calculator 1804 has inputs for receiving the image query, the context and metadata, device parameters, and parameters of the recognition algorithm. In one embodiment, these inputs are coupled to the modules 1902, 1904, 1926, 1908, 1910, 1912, 1914, 1916, 1918, 1920 and 1922 of the vector calculator 1804.

The blur feature module 1902 is software and routines for determining a quality feature based on an amount of blur in a captured image. In one embodiment, motion blur features are computed in one or more of the following ways:

Gradient Based Features. The gradient of the input image is computed (for example with a [−1 0 1] kernel), in both horizontal and vertical dimensions. The magnitudes of gradient values are used to form two n-bin histograms (for example n=3), one for vertical and one for horizontal direction, yielding a 2n dimensional feature vector. The gradient of the input image is computed with 2D kernels and histograms is computed for n gradient directions (for example in n=8 direction). The histogram can be computed for the whole image or the image can be divided into overlapping or non overlapping regions and an n-bin histogram can be computed for each region. For example, if the image is divided into K×L non-overlapping rectangle regions, the resulting feature vector will be size of K×L×n.

Edge detection. Edge detection such as described in “A Computational Approach To Edge Detection,” Canny, J., IEEE Trans. Pattern Analysis and Machine Intelligence, 8:679-714, 1986, edge direction and edge amount histograms can be employed in a similar way to compute blur features.

Motion Estimation Based Features. If the input is video frames, the motion between two frames can be estimated with one of the motion estimation algorithms know in the art such as “A Novel Four-Step Search Algorithm For Fast Block Motion Estimation,” and displacement in horizontal direction (dx), displacement in horizontal direction (dy), and the time of displacement (dt) yields to a feature vector [dx, dy, dt].

Frequency Domain Analysis Based Features. The focus blur of the image can be treated as a spatially-invariant low-pass spatial filter, and the frequency cutoff of this filter is inversely proportional to the size of the blur. If the image contains sharp and high-contrast edges then the image will have significant high-frequency content. The blur feature module 1902 takes 2D Discrete Fourier Transforms (DFT) of the image. As with almost all natural images, spectral magnitude decreases rapidly with increasing frequency. To compute the cutoff, the average spectral magnitude at each frequency (in all directions) is computed. In other words, the average magnitude along concentric ellipses, centered at the DC (0 frequency) term is computed. Once we have this average radial magnitude graph, we want to pick out the cutoff. Specifically, this is the first point at which the spectrum flattens into the noise floor. One way of selecting this cutoff is to low-pass filter the graph (to remove spikiness), scale the graph to a fixed height, and then look for the first point below a certain graph value at which the graph reaches a (fixed) very flat slope. Another way is to look for points in the graph with the greatest curvature (change in angle) over a fixed distance. Once these cutoffs are determined, they are converted into an actual scale. This is most easily done by taking a calibration shot of a text block and computing its cutoff, and then having a function return the ratio of your calibrated cutoff to each new, sampled cutoff. As blur features, we can employ cut off frequency Y and some other features we can compute from the frequency domain analysis, such as Eigen vectors Ei and spread S of the spectrum.

The content amount feature module 1904 is software and routines for determining a quality feature based on the amount of content in the image. In one embodiment, the amount of content features are computed in one or more of the following ways:

Connected component features. Image is binarized for example using a technique described in “Survey Over Image Thresholding Techniques And Quantitative Performance Evaluation,” and connected components are computed such as using a technique described in “A Simple And Efficient Connected Components Labeling Algorithm,”. Then content amount feature module 1904 computes a number of features from connected components, such as histogram (H=[h1 . . . hn]) of, average (A) of, and variance (σ) of connected components such as sizes, widths and heights, number of pixels, aspect ratios, spread, Eigen vectors, number of holes, compactness, etc.

Edge features. Corners such as using “Optimal Corner Detector,” and edges computed in an image and their detection and strength is used to form corner and edge histograms.

Entropy. Entropies of the connected components (Ecc), binarized pixels (Eb), or graylevel/color pixels (Eg/Ec) in the image are an indication of how much information present in the image. Image can also be segmented into overlapping or non overlapping segments and entropies for each of these segments are computed and used to form entropy feature vectors. A low pass filtering or median filtering step may also be used on the image before computing entropy to remove the camera noise.

Frequency Domain Features. Frequency domain analysis, for example transform functions such as 2D fast Fourier transform (FFT) or Discrete Cosine Transforms (DCT) can be applied to the image (the whole image, or overlapping or non overlapping segments). Once frequency domain representation is obtained, this can be represented with histograms.

Compressed Image Size. If two images are compressed with the same compression algorithm, such as JPEG, with same parameters, such as same quantization factor, most of the time the image with higher frequency content results in a compressed image with higher file size. If the file size S is too high, this may be an indication of speckle noise in the image which makes it harder to recognize the image. If the file size if too low then this may be an indication of lack of significant content in the image.

The luminosity feature module 1906 is software and routines for determining a quality feature based on luminosity features. In one embodiment, the luminosity features are computed in one or more of the following ways:

Histogram features. Patterns in the grayscale histogram or color histogram are good indicators of how the image is illuminated. For example, if an image has mostly dark pixels and not any bright pixels that has a value larger than 50 (where pixel values vary from 0 to 255), then the image is likely to yield a lower recognizability score. Besides forming feature vectors from histograms or features extracted from histograms (such as number of peaks), Fisher discriminant analysis can be performed both on luminance and saturation values of the pixels. Discriminant analysis on luminance samples results in 2 classes with the mean values ml1 and ml2 and interclass variances vl1 and vl2. The degree of separation ml1−ml2, the summation of interclass variation vl1+vl2, and/or their ratios, r=ml1−ml2/vl1+vl2 can be used to form a feature vector.

Contrast. Contrast of the image can be computed in a number of efficient ways, for example: Contrast=average of X % lightest pixels/average of Y % darkest pixels.

Shadow. In one method, a shadow mask can be computed from the image such as described in “Image Difference Threshold Strategies And Shadow Detection,”, and luminosity feature module 1906 uses features extracted from shadow histogram. In another method, luminosity feature module 1906 divides the image into overlapping or non overlapping segments, measure histogram in these segments regions, perform histogram equalization and detect if the histograms are similar. The similarity score can be employed as one of the features.

The bleed through feature module 1908 is software and routines for determining a quality feature based on the bleed through feature. If the captured image is an image of a paper document, and it contains some content from a page that is not in the view (i.e. content printed on the other side of the page), then this would degrade the recognition performance. The content from the other page is referred to here as the bleed through features. Bleed through features can be detected using techniques such as described in “Restoring Ink Bleed-Through Degraded Document Images Using a Recursive Unsupervised Classification Technique,” P. Rosen, et al. Proceedings of the 6th British Machine Vision Conference, 1995.

The coding artifacts feature module 1910 is software and routines for determining a quality feature based on coding artifacts. Coding and compression artifacts may degrade the recognizability of images. Methods such as described in “Detection Of Blocking Artifacts Of Compressed Still Images,” Triantafyllidis et al, can be used to form feature vectors from the amount and probability of coding artifacts' presence in the image.

The perspective distortion feature module 1912 is software and routines for determining a quality feature based on perspective distortion. Severe perspective distortion can affect recognizability of the image. There are many methods for detecting and correcting perspective distortion. Correction may be a part of recognition strategy, but detection of such distortions is useful in identifying if an image is recognizable. Perspective distortion can be measured by many methods such as the relative positions of lines and edges in the image, or using the method described in “Perspective Correction Methods For Camera Based Document Analysis, by Jagannathan et al, Proc. First Int. Workshop on Camera-based Document Analysis and Recognition, 2005. Features representing the amount or a histogram of perspective distortion can be used in computing a recognizability score.

The camera noise feature module 1914 is software and routines for determining a quality feature based on camera noise. If the camera charge-coupled device (CCD) size is too small, or there is not enough light in the environment, the captured image or video frame may contain noise, such as speckle noise. There are several ways to measure such noise. One method used by the camera noise feature module 1914 is to apply speckle noise reduction with median filtering, take the difference between noise in the reduced image and the original image, and compute some features based on the difference image. For example, the percentage of pixels that is larger than a threshold.

The text quality feature module 1916 is software and routines for determining a quality feature based on the text in images. The text can be measured as text box features, optical character recognition (OCR) features or text line features.

Text box features. Text boxes can be detected in an image such as using a method described in “Text Detection from Natural Scene Images: Towards A System For Visually Impaired Persons,” N. Ezaki et al. Proc. of 17th Int. Conf. on Pattern Recognition (ICPR 2004), IEEE Computer Society, 2004, pp. 683-686, vol. II, 23-26 August, Cambridge, UK, and a text quality feature module 1916 computes a number of features from text box detection such as: Histogram of text box heights; histogram of text box width/height ratios (nubs); and histogram of text box densities, etc. Histogram of text boxes that are considered good for recognition (good height). For example, text boxes that have less than 1/10th of the height of the image and more than 1/50th height of the image.

OCR features. Images can be OCR'ed (Optical Character Recognition) and the confidence scores of OCR can be used to form feature vectors.

Text line features. In one embodiment, the text quality feature module 1916 computes text line features by computing line spacing histograms. These features maybe useful especially if the text is blurry and gradient based methods do not provide much information. First graphs from the vertical intensity values (only one pixel wide) are computed, and then the local minimums in each graph are found. Then, the distances between local minimums are computed. These distances correspond roughly the distance between lines. Finally, a histogram is formed with these distances. Histograms of non-document images and document images that contain little text are easily distinguishable since they either have many peaks and the histogram is more uniformly distributed. They also have low peak values. Features extracted from these histograms, such as the number of peaks, N, the height of peaks, Pi, are used to form text line feature vectors.

The object detection feature module 1918 is software and routines for determining a quality feature based on the image object. Presence of some objects or shapes such as lines, tables, bulleted items, lists, faces, and buildings affect recognizability depending on the image recognition algorithm. For example, if the image contains mostly tables, the IJ algorithm may not work very well. If the image contains many lines, the BWC algorithm may not work well. In one embodiment, the object detection feature module 1918 can use any one of the following techniques to detect objects in an image: “Use Of The Hough Transformation To Detect Lines And Curves In Pictures,” R. Duda and P. Hart, Communications of the ACM, Vol. 15, pp 11-15, 1972; “A Survey Of Table Recognition,” by R Zanibbi, D Blostein, J R Cordy, International Journal on Document Analysis and Recognition, 2004; or “Face Detection: A Survey,” by E Hjelmas, BK Low, Computer Vision and Image Understanding, 2001 as techniques for object detection in images. The probability of an image containing certain objects, [P(O1), . . . , P(Oi)], is a feature vector computed by the object detection feature module 1918.

The recognition algorithm feature module 1920 is software and routines for determining a quality feature based on the differences in recognition algorithms. Entire or part of the feature extraction process (that is part of image recognition algorithm) can be run on the image for measuring its recognizability. For example, if there are not many recognition algorithm specific features extracted, the image can be assigned a low recognizability score. For example, the feature extraction process can be different for each recognition algorithm (such as IJ, BWC, or PC) or share some common components (such as bounding box extraction component in BWC and Syntext coding). For IJ, features extracted from properties of the IJ skeleton, such as the number of junction points, number of regions (holes), histogram of size of regions, and distributions of the regions in the image. In addition, after feature vectors of gradient directions are formed in each junction point, the variations in these feature vectors can be used as a measure of content recognizability. For SIFT, features extracted from detected locations of SIFT features (e.g. via corner detector), as well as SIFT features themselves can be employed as a recognizability measure. For BWC and Syntext, besides word bounding box-based features (mentioned in the “Text Quality Features” section), a full feature vector may be computed. Features such as the number of recognition-specific feature vectors and their spatial distribution can be used as a measure of recognizability. Also, the uniqueness of each feature vector for each recognition algorithm can be measured and used as a measure. For example, in BWC a feature vector of [3 22 22] is very common and a feature vector of [10 67 897] is very unique. TF-IDF (term frequency-inverse document frequency) can be applied to measure the uniqueness of feature vectors. The recognition algorithm feature module 1920 uses any one or combinations of these to produce a feature vector.

The robustness feature module 1922 is software and routines for determining a quality feature based on robustness. The extracted features from an image are robust if they are stable and unaffected by camera distortion from placement, environment and device changes. An input image can be further processed to determine if the extracted features are stable and robust against various camera distortions. For example, for IJ an image can be blurred, tilted, warped (or some other noise simulation can be applied) and the skeleton, feature locations, and feature vectors can be computed again. Then the distance between the feature locations of the input image and those of a distorted image is measured with techniques such as the Hausdorff distance, and the distance between the feature vectors can be measured with techniques such as the Euclidian distance. If a combination (such as a weighted sum or multiplication) of these distances is small, then the image is robust to various camera effects and therefore it has a positive effect on the recognizability score. The distance measures and how these are combined would depend on the recognition algorithm.

Referring now also to FIG. 20, a process diagram of a method for generating robustness features such as implemented by the robustness feature module 1922 is shown. The method begins by receiving 2002 an input image. The input image is then processed to extract recognition features 2008 and processed to apply different levels of distortion 2004, 2006. In extracting the recognition features 2008, a set of recognition parameters 2020 such as may be retrieved from the image registration unit 408 or the acquisition unit 406 are used. The recognition parameters 2020 are also provided for the extraction of other features 2010, 2012, computing distances 2014, 2016 and computing the robustness vector 2018. The extracted image features 2008 are provided to model the computed distances between feature locations 2014. Similarly, the received input image 2002 has a first distortion applied 2004, then recognition features are extracted 2010 from the distorted image and the recognition features are provided for the computation of distances between feature locations 2014. This process of receiving the image 2002, applying distortion 2006, extracting features and providing the features is preferably performed for a number of different types of distortion. All the extracted features are then provided to compute 2014 distances between feature locations to produce feature vectors. Then the method computes 2016 the distance between feature vectors. Finally the feature robustness vector 2018 is computed from the distance between the feature vectors.

FIG. 21 is a process diagram of a method for generating a recognizability score in accordance with the present invention. As discussed above, the process begins by capturing 2102 an image or video frame. The captured image can be temporarily stored in an image buffer 2104 or provided directly and immediately for computation 2106 of quality vectors. Some images/video frames can be buffered to be used in quality feature vector computation. As described above for the vector calculator 1804, there are a variety of different features that can be used in calculating the recognizability of the image. Any combination of these features or measurements can be used in predicting recognizability (e.g., generating the recognizability score) of an image using a particular set of recognition algorithms. Each of the modules of the vector calculator 1804 produces feature vectors that represent these measurements. Next, the method normalizes 2108 the feature vectors received from the vector calculator 1804. The normalized vectors are then provided to a module for classifying and computing the recognizability score. The vectors are processed by the classification and scoring module 2110. In one embodiment, the classification and scoring module 2110 is pre-trained with positive and negative image samples and includes a feedback loop 2116 from the recognition unit 410 to adjust the classification parameters. In one embodiment, classification and scoring module 2110 is based on algorithms such as neural networks, naive based classifiers, Bayesian based classifiers, or support vector machine (SVM) based classifiers. These classifiers also output a score, either a probability score or margin of error. In one embodiment, the score is output and used by other components such as the distributor 506 of the dispatcher 402 in determining which recognition unit 410 should be selected to perform 2114 recognition on an input image. In a second embodiment, a threshold is applied 2118 to the score output by the classification of scoring module 2110 and whether a score is above or below the threshold is translated into a Boolean value that can again be used by other components such as distributor 506 of the dispatcher 402 in determining which recognition unit 410 to use for processing.

In another application, such as when the quality predictor 502 is operational as part of a client on the mobile device 102, the score or the score translated into a threshold value can be used to determine whether the received image is of sufficient quality to transmit the captured image from the mobile device 102 on for further processing. In one embodiment, if the recognition score is below a threshold, the recognition score is displayed 2112 to the user along with a request for confirmation that retrieval should be performed on the captured image having the displayed recognition score. In another embodiment, a message is displayed to the user indicating the recognition score and that the score is below a level at which the image can be recognized and therefore the image will not be sent to the MMR Gateway 104. Additionally, the message displayed could request that the user capture another image.

In yet another embodiment, classification (and adjusting classification parameters) is done separately for each algorithm. If quality predictor 502 is used in the dispatcher 402 or prior to indexing, the recognition algorithm that results in the highest recognizability score is selected first in the dispatcher 402 or as indexing algorithm, then the second highest is selected and so on. If quality predictor 502 is used prior to performing retrieval, then the recognizability scores for each algorithm (Rn) can be combined in a weighed (wn) sum: Score=w1R1+ . . . +wNRN. Weights can be computed based on retrieval time and retrieval accuracy. Weights can also be re-computed on the fly using the retrieval results.

Result Combiner 610

Referring now to FIGS. 22-24 various embodiments of methods for combining results of image-based text retrieval from different image retrieval algorithms is described. FIG. 22 illustrates a first embodiment of a method for combining recognition results using a quality predictor or a recognizability score. FIG. 23 illustrates a second embodiment of a method for combining recognition results using a quality predictor. FIG. 24 illustrates a method for combining a plurality of recognition results (without prediction) in accordance with the present invention.

Referring now to FIG. 22, the first embodiment of a method for combining recognition results using a quality predictor is shown. More particularly, FIG. 22 illustrates processes performed by the result combiner 610 and the recognition unit 410. The processes above the dashed lines are performed by the recognition unit 410 while the processes below the dashed line are performed by the result combiner 610. Given an input image or images (I) and several image recognition algorithms, A1 . . . AN, the output of each recognition algorithm is a list of recognition results={R1,n, . . . , Rk,n} (for example top K matched document, page, and location on the page) and confidence values associated with each of these results={C1,n, . . . , Ck,n}, therefore: [{right arrow over (C)}n,{right arrow over (R)}n]=An(I). In addition, prediction algorithms, P1 . . . PN (that compute recognizability given an Algorithm An), compute a recognizability score based on an input image or images (I), and recognition algorithms, Sn=Pn(I, An). The method of the first embodiment determines a result R (that contains information about matched document, such as document id, page, and location on the page) or an ordered result list using the following method.

The process begins by retrieving 2202 images. The retrieved images are used to perform recognition/retrieval 2204, 2206 using a plurality of indices 1 to n. In one embodiment, each recognition algorithm An is run to obtain result and confidence vectors for the input image, [{right arrow over (C)}n,{right arrow over (R)}n]=An(I). Next, the result combiner 610 computes 2208, 2210 a recognizability score using a plurality of indices 1 to n. The prediction algorithm is run to obtain a recognizability score for each input image and each algorithm, Sn=Pn(I, An). These two confidence scores are used to compute 2212, 2214 a new confidence score {right arrow over (Cn′)}. For example, a new confidence score {right arrow over (Cn′)} is computed based on {right arrow over (C)}n and Sn, {right arrow over (Cn′)}=f({right arrow over (C)}n1, Sn) for each algorithm An. Finally, the top results based on the new confidence scores are selected 2216 and output. In one embodiment, this is performed by merging and sorting {right arrow over (R)}1, . . . , {right arrow over (R)}N, based on their corresponding confidence values {right arrow over (C1′)}, . . . , {right arrow over (CN′)}, resulting {right arrow over (R)}s. Then the method outputs the top L results of {right arrow over (R)}s. L can be any integer greater that one.

Referring now to FIG. 23, the second embodiment of a method for combining recognition results using a quality predictor is shown. Unlike the first embodiment, different steps of the method of FIG. 23 are performed by components of the MMR matching unit 106. The method begins by receiving 2302 images. These images are then used compute 2304, 2306 recognizability scores for a plurality of indexes one to n. In other words, the prediction algorithm is run to obtain a recognizability score for each input image and each algorithm, Sn=Pn(I, An). Next, the method determines 2308, 2310 whether the corresponding recognizability score is greater than a predefined threshold. If not, the received images are dismissed and no additional computations are performed. On the other hand, if the recognizability score is greater than the predefined threshold, the method continues to perform recognition/retrieval 2312, 2314 using indexes one to n. For example, each recognition algorithm An is run to obtain result and confidence vectors for the input image, [{right arrow over (C)}n,{right arrow over (R)}n]=An(I). Then a new confidence score is generated 2316, 2318 for each index one to n. The new confidence score {right arrow over (Cn′)} is computed based on {right arrow over (C)}n and Sn, {right arrow over (Cn′)}=f({right arrow over (C)}n, Sn). Finally, the top results are selected 2320 and output. In one embodiment, {right arrow over (R)}1, . . . , {right arrow over (R)}n are merged and sorted based on their corresponding confidence values {right arrow over (C1′)}, . . . , {right arrow over (Cn′)}, resulting in {right arrow over (R)}s, and then the top L results of are output.

In an alternate embodiment, the processes described above with reference to FIGS. 22 and 23 are modified slightly as follows. The recognition results, confidence scores and modify or new confidence scores are produced in a similar manner. Specifically, the prediction algorithm is run to obtain recognizability score for input image and each algorithm, Sn=Pn(I, An). The recognition algorithm An is run to obtain result and confidence vectors for the input image, [{right arrow over (C)}n,{right arrow over (R)}n]=An(I), only if the corresponding prediction score Sn is higher than a threshold. (We assume that {right arrow over (R)}n is sorted based on the confidence scores, therefore R1,n is the best guess for the matching result. Note that some algorithms may not output any result because of their internal threshold). However, rather than just merging and sorting the top recognition results as in the method described above, this alternate embodiment uses the top results from each algorithm (R1,1, . . . , R1,N) for voting for the best result. The votes can be counted based on document id, (docid+pageid), or (docid+pageid+patch location). Patch locations (x,y) do not exactly need to be the same, a proximity measure can be used for giving votes to each document patch location. The method then output the result that receives the most votes.

Furthermore, if there is a tie between results, one of the following methods can be used to output a result: a) Sum the confidence values C1,n of the tied groups of results and output the result corresponding to the highest confidence summation; b) Compute modified confidence scores C1,n′=f(C1,n, Sn). Sum the modified confidence values C1,n′ of the tied groups of results and output the result corresponding to the highest confidence summation; c) Sum the prediction score Sn of the tied groups of results and output the result corresponding to the highest prediction score summation; d) Output the result R1,n of the algorithm that produced the highest confidence score C1,n or the highest modified confidence score C1,n′; e) Output the result R1,n of the algorithm that produced the highest prediction score Sn; or f) Pre-determine the order of algorithms to output (based on their previously measured accuracy). For example, first IJ, then snake coding, etc.

FIG. 24 illustrates a method for combining a plurality of recognition results (without prediction) in accordance with the present invention. The process begins by retrieving 2402 images. The retrieved images are used to perform recognition/retrieval 2206, 2208 using a plurality of indices 1 to n. In one embodiment, each recognition algorithm An is run to obtain result (if any) and confidence vectors for the input image, [{right arrow over (C)}n,{right arrow over (R)}n]=An(I). (We assume that {right arrow over (R)}n is sorted based on the confidence scores, therefore R1,n is the best guess for the matching result. Note that some algorithms may not output any result because of their internal threshold). Next, a prediction algorithm is run 2404, 2408 to obtain a likelihood score for input image and each algorithm, Sn=Pn(I, An). The likelihood score as receives and uses the date, time location, personal profile, retrieval history and other context and metadata to generate the likelihood score, On. The confidence score and the likelihood score are used to compute 2412, 2414 a modified confidence score. For example, a modified confidence score {right arrow over (Cn′)} is computed based on {right arrow over (Cn′)}=f(On, {right arrow over (C)}n) for each algorithm An. Finally, the top results based on the new confidence scores are selected 2216 and output. In one embodiment, this is performed by merging and sorting {right arrow over (R)}1, . . . , {right arrow over (R)}n based on their corresponding confidence values {right arrow over (C1′)}, . . . , {right arrow over (Cn′)}, resulting {right arrow over (R)}s Then the method outputs top L results of . L can be any integer greater that one. In a second embodiment, the top results from each algorithm are determined by voting. The top Ln results from each algorithm ({R1,1, . . . , RL1,1}, . . . , {R1,N, . . . , RLN,N}) is used to vote (with weights) for the best result. Ln depends on the algorithm. For example IJ may output only one result, i.e. Ln=1, and BWC may output its top 10 results, Ln=10. If Ln is set to 1 for all algorithms, only the top result from each algorithm votes for the result. In one embodiment, the voting weights are based on confidence scores corresponding to each result, 1/(rank in retrieval), or some other measure. The voting scheme and weights can also be trained using a boosting algorithm such as “A Short Introduction To Boosting,” by Freund, Y. and Schapire, R., J. Japanese Society of Artificial Intelligence, v. 14, no. 5, pp. 771-780, 1999. Further, if there is a tie, one of the following methods can be used to output a result: a) Sum the confidence values of the tied groups of results and output the result corresponding to the highest confidence summation; b) Output the result R1,n of the algorithm that produced the highest confidence score; c) Pre-determine the order of algorithms to output (based on their previously measured accuracy). For example, first IJ, then snake coding etc.

In other embodiments, a classifier (such as neural networks, naive based classifiers, Bayesian based classifiers, SVM based classifiers) can be trained with any combination of the confidence scores of retrieved algorithms, retrieval results, recognizability score or likelihood score Sn, and/or any combination of features used for computing recognizability score. At retrieval time, the computed scores and features for the input image/images are input to the trained classifier to obtain the recognition result and a confidence score (which might be based on margin of error, probability of the classification etc).

In addition to the embodiment described above, the location and region of the retrieved page may be reconciled among a plurality of recognition results. Once a document, page, and approximate patch location is identified, the method computes the exact location of the patch. Different algorithms may produce different location results. Algorithms may not produce any “location on the page” information, may produce only x,y coordinates, x,y coordinates and width and height, (x1,y1,x2,y2) coordinates that are not rectangular, or some arbitrarily shaped region defined by a polygon, a closed curve, etc. A final retrieved region or x,y center can be found by assigning priority to algorithms An that is based on their accuracy and output the retrieved region based on this priority. Alternatively, in one embodiment, the method finds the retrieved location (x,y) on the page by averaging the mass centers of the retrieved regions, or an x, y location that minimizes the Hausdorff distance to all the edges of the closed regions. The retrieved region on the page is determined by finding a region defined by a rectangle, a polygon (etc.) that minimizes the total overlap error in the retrieved regions.

Audio Assisted Recognition Or Action

Referring now to FIG. 25 (and FIG. 21), another embodiment 2500 of the present invention in which the recognition process is enhanced with other information captured by the mobile device 102 is shown. FIG. 21 shows a configuration for the mobile device 102 having a client 250 and a server 252 that supports the process depicted in FIG. 25 and described below. While this embodiment of the present invention is discussed primarily in the context of audio data in addition to the image data, those skilled in the art will recognize that the recognition may be enhanced and the actions specified using other inputs such as captured context, user inputs or other metadata.

The mobile device 102 and the client 250 described above with reference to FIG. 21 include the capability to capture a variety of other information (referred to herein as secondary information) in addition to the image or video. For example, the client 250 is capable of capturing audio data. Further the MMS format for messages provides the capability to include audio streams in addition to image data. In this embodiment of the present invention, the mobile device 102 and the client 250 capture the secondary information, include it in the MMS, SMS or email message along with image information whether preprocessed or not. The secondary information is used by the server 252 for various functions such as, but not limited to, improving recognition, determining how to recognize, determining an action or biometric verification.

The accuracy of recognition is improved using the secondary information. For example, if the user speaks some keywords that identify a document or content such as “New York Times, page 5,” or “advertisement about Coca-Cola,” this audio is captured, recognized with speech recognition tools and the audio recognition results are used to improve the image recognition. The user can also read aloud the header of the story in which they are interested, the caption of a figure or at least some keywords about or from the captured image. Again, this information is captured and used as secondary information when performing image recognition. It should be noted that such information not only improves the accuracy of image recognition, it is also used to reduce the recognition time by reducing the data set against which the captured image is compared.

The secondary information is also used to specify how the recognition should be performed. In such an embodiment, the user is provided with the ability to specify how the recognition should be performed. For example, the user may be able to control the type of recognition (BWC, Invisible Junction, etc.) used, the order that recognizers are used, where recognition is performed (client 250 versus server 252), the data set used for recognition, or other parameters of the recognition process. For example, the user may speak an action to be taken with the query image such as “use BWC for recognition” or “use server for recognition.” The audio is captured and included along with the captured image as part of the message sent from the client 250 to the server 252.

The secondary information is also used to specify an action to be taken on the results of image recognition or after recognition. For example, the user says an action to be taken after recognition such as “e-mail this document to me,” “send to Mary for approval,” or “put this advertisement into MySpace webpage.” The audio is captured and included along with the captured image as part of the message sent from the client 250 to the server 252. The server 252 then recognizes the action and performs it on the recognition results.

Finally, in yet another embodiment, the secondary information is also used for biometric verification. The user speaks so that the audio signature can be extracted from the audio stream. The audio stream is captured and included along with the captured image as part of the message sent from the client 250 to the server 252. The server 252 then processes the audio stream for biometric verification to grant or deny access to the MMR database 254 or a hotspot database 404.

Those skilled in the art will realize that the above are only examples of the data that may be included as part of the message sent from the client 250 to the server 252 and that other data other metadata can be inserted via the audio channel for delivery to the server 252. Furthermore, those skilled in the art will realize that other information can be used for a variety of other purposes beyond those described above.

Referring now to FIG. 25, the process for providing audio-assisted recognition or audio-specified action is described. The process begins with a series of capture steps 2502, 2504, 2506 and 2508. The mobile device 102 and the client 250 capture 2502 visual data such as an image or a video. This process has been described above so that description will not be repeated here. However, it should be noted that in at least one embodiment, the capture module 260 of the client 250 cooperates with the mobile device 102 to capture the image.

The mobile device 102 and the client 250 also capture 2504 secondary information. In one embodiment, the capture module 260 of the client device 250 cooperates with the mobile device 102 to capture and record audio data as an audio clip or file. In other embodiments, other secondary information is acquired 2506 by the capture module 260 such as GPS information, location information, user preferences, time, date, key presses from the telephone keypad, or any other information provided by conventional mobile device 102 and stored in a file. In still other embodiments, the capture module 260 obtains 2508 other metadata such as names of applications installed on the mobile device, identification of magazines the user subscribes to, “friends” of the user, social networks the user participates in, and a profile of the user including her age, picture, gender, nationality, etc., and stores it in a file. Next, the e-mail module 280 of the client 250 operating on the mobile device 102 generates an e-mail such as in MMS format; and adds the image data from step 2502 and the secondary information if any from one or more of steps 2504, 2506 and 2508 to the generated MMS message. The e-mail module 280 then sends the generated MMS message to the server 252.

The server 252 decodes 2510 the generated MMS message to produce or extract a metadata portion, an audio portion and a visual portion. In one embodiment, the visual portion is the data captured in steps 2502, the audio portion is the file captured in step 2504 and the metadata portion is the files captured in steps 2506 and 2508. Although not shown in FIG. 25, the step of decoding 2510 is performed by a module operational on the server 252. In an alternate embodiment, the decoding step 2510 is performed by the preprocessing module 262. The audio portion and the metadata portion are sent to the voice recognition system 290 to perform 2512 audio and metadata recognition. The voice recognition system 290 is coupled to the audio database 292 for use in recognition process. The audio portion is used to improve recognition performance. In one embodiment, the voice-recognition 290 performs speech recognition on the audio portion to obtain one or more keywords, K1 . . . Kn. These keywords are then provided by the voice-recognition system 290 to the retrieval module 266 for use in image recognition. The visual portion and the metadata portion are sent to the feature extraction module 262 and/or retrieval module 266 to perform 2514 image recognition. The retrieval module 266 is coupled to the MMR database 254 to perform image recognition. In one embodiment, the retrieval module 266 performs retrieval using one or more MMR algorithms and receives one or more results from these algorithms, R1 . . . , Rm indicating a document or a document patch. As has been detailed above, confidence scores associated with each of these results C1 . . . Cm are also generated. The recognition results can then be improved in a variety of ways using the audio recognition results. For example, in one embodiment, each retrieved MMR document or MMR patch is searched using keywords K1 . . . Kn and the confidence scores are modified by using the search results. For example, the confidence score is incremented by d for each found keyword. In another embodiment, instead of or together with the retrieved document content, metadata about the document (such as document title, author, date, page number, brand name etc) is searched with the keywords and confidence scores are modified using these search results. In still another embodiment, the keywords K1 . . . Kn are used to select an MMR database or part of an MMR database in which to search. For example, if the keywords were “new york times,” then only databases that contain this publication are searched. Regardless of the embodiment, the method then uses the search results to perform 2516 action. In one embodiment as shown in FIG. 21, the action is to generate a response and using the send message module 268 includes a response into an SMS or MMS message and to transmit the message back to the client 250 of the mobile device 102.

Distributed Retrieval

Referring now to FIG. 26, an embodiment of the present invention for distributed retrieval utilizing the functionality of the present invention distributed over a plurality of mobile devices 102a, 102b and 102c will be described. In particular, FIG. 26 illustrates a server-less configuration for a plurality of mobile devices 102a, 102b and 102c. In this server-less configuration, different mobile devices 102a, 102b and 102c perform different capture and retrieval tasks in a distributed fashion. While FIG. 26 illustrates a distributed architecture having three mobile devices 102a, 102b and 102c, this is only by way of example and those skilled in the art will recognize that any number of mobile devices 102 may be used in a distributed fashion, and the functionality may be distributed amongst those mobile devices in a variety of different ways. Furthermore, those skilled in the art will recognize that while the present invention is described as a plurality of plug-in modules part of the client 250 operable on the mobile device 102, the present invention can be implemented in a variety of other ways such as a mixture of functionality provided by the mobile device 102 and plug-in modules of the client 250.

As shown in FIG. 26, this embodiment includes a plurality of mobile devices 102a, 102b and 102c each having a respective client 250a, 250b and 250c. In one embodiment, the plurality of mobile devices 102a, 102b and 102c are adapted for communication with each other such as via the data communication networks provided by most mobile telephone carriers. In addition, each of the clients 250a, 250b and 250c includes a peer-to-peer communication module 2602, 2604 and 2606 for communicating with the other clients 250a, 250b and 250c. Those skilled in the art will recognize that peer-to-peer communication is only used by way of example for identifying which mobile device 102a, 102b and 102c includes which functionality and information for communicating with the other mobile devices 102a, 102b and 102c, and that in other embodiments, other types of communication mechanisms may be employed such as MMS, SMS, e-mail, infrared, Bluetooth, wireless network, phone network, etc.

In this example embodiment, a first mobile device 102a includes client 250a comprising a capture module 260 and a first peer-to-peer communication module 2602. The first mobile device 102a captures an image for use as part of a query and the capture module 260 generates a message, such as an MMS message, to send to another mobile device 102b, 102c. The client 250a utilizes the first peer-to-peer communication module 2602 to identify the corresponding client 250b to which the MMS message is sent. In one embodiment, the peer-to-peer communication modules 2602, 2604, 2606, identify other clients 250 or peer-to-peer communication modules 2602, 2604, 2606 by exchanging tokens identifying the functionality and database available at each client 250a, 250b and 250c. In another embodiment, information about databases and client functionally is kept in one central database (not shown) accessible by the peer-to-peer communication modules 2602, 2604, 2606. In yet another embodiment, a ad hoc network is created between the clients 250a, 250b and 250c. Such a network is created based upon using physical proximity, word of mouth (direct connection by sending a MMS to a phone number that is running MMR, a social group defined at a server (Facebook, Linked-in, etc), a social group defined at the mobile device, or a contact list on the phone, etc. The first peer-to-peer communication module 2602 then transmits the MMS message to the second peer-to-peer communication module of client 250b.

The second mobile device 102b includes a second client 250b comprising a second peer-to-peer communication module 2604, a feature extraction module 264, a retrieval module 266 and an MMR database 254. Each of these modules 2604, 264, 266 and 254 has a functionality, structure and coupling similar to that described above. It should be noted however, that since the MMR database 254 is operational on the second mobile device 102b with limited computational ability and storage, the MMR database 254 need not be the entire MMR database 254 described above but rather is a smaller version scaled to match the resources available at the second mobile device 102b. The client 250b, in particular the second peer-to-peer communication module 2604, receives the image query from the first mobile device 102a. The second peer-to-peer communication module 2604 provides the image query to the feature extraction module 264 that generates features which are in turn provided to the retrieval module 266. The retrieval module 266 cooperates with the MMR database 254 to perform image retrieval to find a document ID, page and a location (X, Y) on the document. This information is provided to the second peer-to-peer communication module 2604 that uses it to generate a message, for example an SMS message and sends the generated message to the third mobile device 102c.

The third mobile device 102c includes a third client 250c comprising a third peer-to-peer communication module 2606, the dispatcher 402 and a hotspot database 404. The third client 250c uses the document ID to retrieve additional information about the identified document. The third client 250c then sends the retrieved information, for example hotspot data, back to the first mobile device 102a for presentation to the user. More specifically, the third peer-to-peer communication module 2606 receives the document ID and a location from the second mobile device 102b within a SMS message. The third peer-to-peer communication module 2606 extracts the document ID and location, and provides them to the dispatcher 402. The dispatcher 402 uses the document ID and a location as part of a query to the hotspot database 404. This query returns results in the form of hotspot information that is then provided to the third peer-to-peer communication module 2606. The hotspot information is embedded within an SMS or MMS message and sent by the third peer-to-peer communication module 2606 to the first mobile device 102a. It should be noted, however, that since the hotspot database 404 is operational on the third mobile device 102c with limited computational ability and storage, the hotspot database 404 need not be the entire hotspot database 404 described above but rather is a smaller version scaled to match the resources available at the third mobile device 102c.

One real world example use case for the architecture of FIG. 26 is sharing comments about a book between your friends. For example, Mary, Amy and Mark are reading the same book. Mary is wondering what her friends thought about a particular section of the book. She captures an image of that section with her cell phone (the first mobile device 102a) and sends it to Amy. Amy's device (the second mobile device 102b) receives the message and uses her MMR database to retrieve document id and section. However, Amy does not have any comments about this section. Amy's device sends Mark (who is identified as being in the same group of people who is reading the book) an SMS message that contains the document id and the section. Mark's device (the third mobile device 102c) receives this message and finds in Mark's hotspot database an audio clip that was recorded by Mark that includes his comments about the book section. The audio clip is then sent back to Mary as an MMS message.

As was noted above, those skilled in the art will recognize that the configuration shown in FIGS. 26 and described above is only an example of a configuration for distributed retrieval. In other embodiments, any one of the clients 250a, 250b or 250c of the mobile devices 102a, 102b or 102c include a combination of (or a subset of) the MMR database 254, the capture module 260, the preprocessing module 262, the feature extraction module 264, the retrieval module 266, the send message module 268, the action module 270, the preprocessing/prediction module 272, the feedback module 274, the sending module 276, the streaming module 278, the e-mail module 280, the voice recognition system 290 and the audio database 292. Further, there are a variety of other examples, such as but not limited to:

1) an architecture in which the first client 250a sends the query image to multiple clients, any one of which has its own MMR database and returns retrieval results back to the first mobile device 102a or the first client 250a;

2) an architecture in which retrieval and hotspot retrieval take place on the same client device (i.e., the second and third client devices 102b, 102c are the same device)

3) an architecture in which the first client 250a performs feature extraction and sends extracted features to other client devices;

4) an architecture in which overlapping or non overlapping image segments may be send to other devices for computing image features and retrieval; and

5) an architecture in which different client devices may run different retrieval algorithms.

Referring now to FIG. 27, an embodiment of the present invention for distributed retrieval utilizing a plurality of mobile devices 102a, and 102c and the MMR gateway 104 will be described. The configuration shown in FIG. 27 is similar to that of FIG. 26, but the second mobile computing device 102b has been replaced by the MMR Gateway 104 and MMR matching unit 106 including server 252. This embodiment illustrates that the computations may be distributed among a plurality of devices 102a, 104/106, 102c, whether they are mobile devices or not, that are adapted for communication via a peer-to-peer communication modules 2602, 2604 and 2606. In this embodiment, the server 252 includes the second peer-to-peer communication module 2604, the feature extraction module 264, the retrieval module 266 and an MMR database 254. The functionality provided by the server 252 is similar to the second client 250 but operable on server 252 which is a hardware server with increased computing power and storage capability. In a modified version of the embodiment of FIG. 27, the client 250a of the mobile device 102a includes the feature extraction module 264 and performs feature extraction. In such a modification, mobile device 102a sends extracted features rather than the image to the MMR gateway 104.

Referring now to FIG. 28, another embodiment of the present invention for distributed retrieval utilizing a plurality of mobile devices 102a, 102b and 102c is described. The configuration shown in FIG. 28 is similar to that of FIG. 26 in that the mobile devices 102a, 102b and 102c are coupled for communication with each other by peer-to-peer communication modules 2602, 2604 and 2606. However, in this embodiment the first mobile device 102a includes client 250a comprising a capture module 260, the feature extraction module 264, the dispatcher 402, the hotspot database 404 and the first peer-to-peer communication module 2602. These modules 260, 264, 402, 404 and 2602 provide the same functionality as has been described above with reference to FIG. 26, but reside in the first mobile device 102a. In other words, MMR image capture, feature extraction, and hotspot look up are performed at and by the first mobile device 102a. The second mobile device 102b includes a second client 250b comprising the second peer-to-peer communication module 2604, the retrieval module 266 and the MMR database 254. Each of these modules 2604, 266 and 254 has a functionality and structure similar to that described above. It should be noted however, that the MMR database 254 need not be the entire MMR database 254 described above but rather is a smaller version or portion scaled to match the resources available at the second mobile device 102b. The client 250b, in particular the second peer-to-peer communication module 2604, receives the image features from the first mobile device 102a. The retrieval module 266 cooperates with the MMR database 254 to perform image retrieval to find a document ID, page and a location (X, Y) on the document. This information returned to the is provided to the second peer-to-peer communication module 2604 that uses it to generate a message, for example an SMS message and sends the generated message back to the first mobile device 102a. The third mobile device 102c includes the third client 250c comprising the third peer-to-peer communication module 2606, the retrieval module 266 and the MMR database 254. The third mobile device 102c also receives image features from the first mobile device 102a and returns a document ID, page and a location (X, Y) on the document to the first mobile device 102a. In one embodiment, the second mobile device 102c and third mobile device 102c have different portions of the MMR database 254, different algorithms for performing retrieval, index the data differently or a combination of those. The configuration of FIG. 28 provides fault tolerance in the event one of the second mobile device 102c and third mobile device 102c are not accessible, and parallel searching of different sources when the data is bifurcated.

Referring now to FIG. 29, yet another embodiment of the present invention for distributed retrieval utilizing a mobile device 102a, the MMR gateway 104 and MMR matching unit 106 is described. The configuration shown in FIG. 29 includes a first mobile device 102a with the same configuration as in FIG. 28 but without the peer-to-peer communication module 2602. Communication between mobile device 102a and the MMR gateway 104 is a conventional manner such a voice or data channel provide by a wireless carrier. The MMR gateway 104 and MMR matching unit 106 are operable on an hardware server as opposed to a mobile device. In this embodiment, the MMR image capture, feature extraction, and hotspot look up are performed at the first mobile device 102a. The MMR retrieval occurs as the server 252. This configuration is particularly advantageous for accessing a user's own private content, like audio recordings, but where the MMR retrieval is more efficiently and effectively done at the server 252.

The foregoing description of the embodiments of the present invention has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the present invention to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. It is intended that the scope of the present invention be limited not by this detailed description, but rather by the claims of this application. As will be understood by those familiar with the art, the present invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Likewise, the particular naming and division of the modules, routines, features, attributes, methodologies and other aspects are not mandatory or significant, and the mechanisms that implement the present invention or its features may have different names, divisions and/or formats. Furthermore, as will be apparent to one of ordinary skill in the relevant art, the modules, routines, features, attributes, methodologies and other aspects of the present invention can be implemented as software, hardware, firmware or any combination of the three. Also, wherever a component, an example of which is a module, of the present invention is implemented as software, the component can be implemented as a standalone program, as part of a larger program, as a plurality of separate programs, as a statically or dynamically linked library, as a kernel loadable module, as a device driver, and/or in every and any other way known now or in the future to those of ordinary skill in the art of computer programming. Additionally, the present invention is in no way limited to implementation in any specific programming language, or for any specific operating system or environment. Accordingly, the disclosure of the present invention is intended to be illustrative, but not limiting, of the scope of the present invention, which is set forth in the following claims.

Claims (20)

1. A method for generating and processing a retrieval request for a visual recognition system, the method comprising:

capturing an image and generating an image query;

capturing audio data associated with the image;

generating and sending a first message including the image query and the audio data;

performing retrieval of a file using the image query and the audio data;

generating and sending a second message or performing an action based upon the media file.

2. The method of claim 1, further comprising capturing metadata associated with the image.

3. The method of claim 1, further comprising performing command and data recognition on the audio data to produce audio recognition results.

4. The method of claim 3, wherein the audio recognition results are used to improve the accuracy of retrieval.

5. The method of claim 3, wherein the audio recognition results are used to specify how retrieval is performed.

6. The method of claim 3, wherein the audio recognition results are used to specify an action to be taken on retrieval results.

7. The method of claim 3, wherein the audio recognition results are used for biometric verification of a user generating and sending the first message.

8. The method of claim 1,wherein performing retrieval of a file using the image query and the audio data comprises:

performing speech recognition on the audio data to generate a keyword;

performing retrieval using an MMR recognition method to produced recognition results and confidence scores; and

modifying the confidence scores using the keyword.

9. The method of claim 8, further comprising:

capturing metadata associate with the image;

wherein the first message includes the metadata; and

wherein modifying the confidence scores use the metadata.

10. The method of claim 8, further comprising using the keyword to select one of a plurality of databases to use for the step of performing retrieval using MMR recognition.

11. A method for generating and processing a retrieval request in a distributed visual recognition system, the method comprising:

capturing an image and generating an image query using a first mobile device;

generating and sending a first message including the image query using the first mobile device;

receiving the first message using a second mobile device;

performing recognition using the second device; and

generating and sending a second message including a document identification and a location using a second device.

12. The method of claim 11 further comprising:

receiving the second message using a third mobile device; and

performing an action based upon the document identification and the location using the third mobile device.

13. The method of claim 11 wherein the second device is one from the group of a mobile device and a hardware server.

14. The method of claim 12 wherein performing the action includes:

generating and sending a third message by the third mobile device, the message including hotspot data; and

receiving and processing the third message at the first mobile device.

15. The method of claim 11 wherein performing recognition comprises:

removing an image query from the first message;

performing feature extraction on the image query to produce extracted features; and

querying an MMR database using the extracted features to generate recognition results including the document identification and the location.

16. A method for generating and processing a retrieval request for a visual recognition system, the method comprising:

capturing an image and generating an image query;

capturing metadata associated with the image;

generating and sending a first message including the image query and the metadata;

performing retrieval of a file using the image query and the metadata;

generating and sending a second message based upon the media file; and

performing an action based upon the media file.

17. The method of claim 1, wherein capturing an image, capturing metadata and generating and sending a first message are performed by a mobile phone and wherein the first message and the second message have an MMS format.

18. The method of claim 1, wherein the metadata includes one from the group of an email address, a user id, a preference, GPS information, device settings, metadata about a query image, query image location, an audio file, query image document name and information about an action to be taken on the recognition result.

19. The method of claim 1, wherein the action is one from the group of sending a return confirmation message, sending an identified document, sending a page, sending a location, sending a thumbnail of the identified document, sending a video overview of the identified document, a message about an action performed, and instructions about capturing an image.

20. The method of claim 1, wherein performing retrieval, generating and sending the second message and performing the action are performed by a server coupled to a mobile device.

US123401242004-10-012008-12-19Client device for interacting with a mixed media reality recognition system
Active2027-02-17US9020966B2
(en)

Network-linked interactive three-dimensional composition and display of saleable objects in situ in viewer-selected scenes for purposes of object promotion and procurement, and generation of object advertisements