Patent Application
20090319570
A portion of the disclosure of this document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever. The following notice applies to the software, data, and/or screenshots that may be described below and in the drawings that form a part of this document: Copyright©2008, eBay Inc. All Rights Reserved.
Example embodiments relate generally to the technical field of algorithms and programming and, in an example, to the uploading and linking of item images to manage item listings.
Image hashing is mapping an image to a short binary string. An image hash function extracts a fixed-length bit string from a given image. The extracted bit string has been used in various cryptographic applications for use in digital signatures to authenticate a message being sent so that a recipient of the message can verify its source. The image hash function may be used in multimedia applications to index, search and sort images in multimedia databases.
Some embodiments are illustrated by way of example and not limitation in the figures of the accompanying drawings in which:
In some example embodiments, a system and method are illustrated to link item images to item listings. The system and method include receiving an item listing and a tentative image for the item listing from a user device. The system and method include assigning an image identifier to the tentative image received from the user device. The image identifier may be identical or substantially identical for the same or similar images and unique for different images. The system and method include comparing the image identifier with one or more image identifiers for existing images for existing item listings. The system and method further include linking the received item listing to the tentative image according to a result of the comparing.
In some example embodiments, a system and method are illustrated to receive item images for item listings. The system and method include receiving an image identifier associated with an image for an item listing from a user device. The image identifier may be identical or substantially identical for the same or similar images and unique for different images. The system and method include comparing the image identifier received from the user device with one or more image identifiers for existing images for existing item listings. The system and method further include determining whether to receive the image for the item listing from the user device according to a result of the comparing.
In some example embodiments, an image identifier for an item listing may be generated as a function of a hash algorithm. For example, conventional cryptographic hashing algorithms such as message digest 5 (MD5) and secure hash algorithm 1 (SHA-1) may be used to produce the image identifier. These hashing functions may be sensitive to the message (e.g., changing even one bit of the input may change the output). Multimedia data such as digital images, however, may go through various manipulations such as compression, enhancement, cropping, and scaling. An image hash function thus may take into account the changes in a visual domain and produce hash values based on the image's visual appearance. In some example embodiments, therefore, an image hash function may be used to produce the identical or substantially identical hash value with high probability for perceptually identical or similar images, while producing unique or substantially independent hash values for perceptually different images. Such a hash function would be useful in identifying images in databases, in which the image possibly undergoes incidental changes (such as compression and format changes, common signal processing operations, scanning or watermarking). Such a hash function would also be useful in identifying different but substantially similar images for similar items. More detailed information about sharing duplicate images for item listings using image identifiers is given below using
The item listing upload engine 112 may receive an item listing for an item and an image for the item listing from a user (not shown in
The host device 130 may run an item listing management engine 132, a memory unit 136 and a processing unit 134. The item listing management engine 132 may receive the item listing and/or the image for the item listing transferred from any of the user devices 110-1 through 110-N. The memory unit 136 may store the received item listing and/or the received image for the item listing for further processing by the processing unit 134. The item listing management engine 132 may assign an image identifier to the image transferred from the user device 110-1 and compare the image identifier with one or more image identifiers existing in the host device 130. Each of the one or more existing image identifiers may be associated with an existing item image stored in the host device 130. If the comparing is done, the item listing management engine 132 may further link the received item listing to an item image according to a result of the comparing. More detailed explanation about the item listing management engine 132 is given below using
In response to the receipt, the assigning engine 220 may assign an image identifier to each image for the items A 114 and B 116. In some example embodiments, the image identifier may be generated as a function of a hash algorithm, such as MD5 or SHA-1. In some example embodiments, other suitable hash algorithms may be used to generate an image identifier. The image identifier may be a binary value that can be converted to an integer value. For example, a numerical value “545” and “830” may be assigned to the image for the item A 114 and the image for the item B 116, respectively as an image identifier. In some example embodiments, the assigning engine 220 may only generate a distinguishable part of the image identifier. In such a case, the distinguishable part may be combined with one or more other numerical values indicating, for example, a location of storage or category information of a corresponding item to produce a complete image identifier. For example, “160116111548808038”, “1601161116268080” and “1601161117228080” may be produced as image identifiers.
The comparing engine 230 may then refer to the item listing table 250 in the item listing database 140 and identify an image identifier that is identical or substantially identical to the image identifier (e.g., 545) assigned to the image for the item A 114 transferred from the item listing upload engine 112. In some example embodiments, an image identifier may be treated as being substantially identical to another image identifier if the value of the image identifier is within a predefined threshold difference (e.g., 2, 5, 10, 20, 50, 100 or 120, etc.) from a value of the other image identifier. For example, there is no existing image identifier having the value of “545” in the item listing table 250. An existing image identifier 141 having the value of “548” may be, however, recognized as being substantially identical to the image identifier (e.g., “545”) assigned to the image for the item A 114 if a value of “5” is set as the threshold difference.
The linking engine 240 then may discard the image for the item A 114 (e.g., from the memory unit 136) and link the item listing for the item A 113 to an existing image 142 via the existing image identifier 141 (e.g., “548”). In some embodiments, the item listing for the item A 113 may be inserted in the item listing table 250 as one of “item listings” 143 associated with the existing image identifier 141.
The comparing engine 230 may, however, fail to find an existing image identifier that matches (e.g., is identical or substantially identical to) the image identifier (e.g., “830”) for the image for the item B 116. In some example embodiments, the linking engine 240 then may link the item listing for the item B 115 with the image for the item B 116 and store them together into the item listing table 250 as a new row along with the newly assigned image identifier (e.g., “830”). It is noted that the image identifier (e.g., “830”) for the image for the item B 116 may be regarded as substantially identical to an existing image identifier 144 with a value of “722” if a value larger than the difference between “830” and “722” (e.g., “120”) is set as the predefined threshold value. As similarly described above, the linking engine 240 may then discard the image for the item B 116 that may have been temporarily stored in the memory unit 136 and link the item listing for the item B 115 to an existing image 145 via the existing image identifier 144 (e.g., “722”). In some example embodiments, the item listing for the item B 115 may be inserted in the item listing table 250 as one of “item listings” 146 associated with the existing image identifier 144. It is noted that each of the engines described above in
In some example embodiments, an image identifier (e.g., “545”) for an item A 117 may be transferred from the item listing uploading engine 112 to the item listing management engine 132. As described above in
As described above in
When another image identifier (e.g., “830”) for an item B 118 transferred from the item listing uploading engine 112 is received by the receiving engine 210 of the item listing management engine 132, the comparing engine 230 may compare the image identifier (e.g., “830”) for the item B 118 with one or more image identifiers stored in the item listing table 250. This time, however, the comparing engine 230 may fail to find an existing image identifier that matches (e.g., is identical or substantially identical to) the image identifier (e.g., “830”) for the item B 118. The determining engine 260 then may receive the item listing for the item B 115 and the image for the item B 116 from the item listing uploading engine 112. The determining engine 260 may further store them together into the item listing table 250 as a new row along with the newly assigned image identifier (e.g., “830”). As described above in
As similarly described above, in some embodiments, the item listing for the item B 115 may be inserted in the item listing table 250 as one of “item listings” 146 associated with the existing image identifier 144. In some example embodiments, the item listings 113, 115 may be uploaded from the item listing uploading engine 112 to the item listing management engine 132 when their corresponding image identifiers 117, 118 are transferred. In such a case, the uploaded item listings 113, 115 may be temporarily stored in the memory unit 136 for further processing by the processing unit 134. In some example embodiments, the determining engine 260 may be the same linking engine 240 as described above in
The transferring engine 330 may transfer, for example, the image identifier (e.g., “545”) 117 to the host device 130. The host device 130 may then compare the image identifier 117 with one or more existing image identifiers for existing images stored in the host device 130 as described above in
In some example embodiments, the transferring engine 330 may be further configured to send an override notification 360 to the host device 130. The override notification 360 may indicate that the image for the item A 114 will be transferred to the host device 130 regardless of the result of the comparing 352. If the host device 130 reviews and sends an allowance 370 back to the item listing uploading engine 112, the transferring engine 330 may upload the image for the item A 114 to the host device 130 even though the result of the comparing 352 indicates that an matching image identifier exits in the host device 130. In some example embodiments, the transferring engine 330 may send the image for the item A 114 without waiting for the allowance 370 from the host device 130. In some example embodiments, the host device 130 may be one of the other user devices 110-2 through 110-N. It is noted that each of the engines described above in
In some example embodiments, at operation 440, it may be checked whether there is an existing image in the host device 130 that matches the tentative image. This may be done by checking whether there is an image identifier in the host device 130 that matches (e.g., identical or substantially identical to) the image identifier assigned to the tentative image received from the user device (e.g., 110-1). If it is determined that there is no matching image in the host device, at operation 450, the item listing and the tentative image received from the user device (e.g., 110-1) may be linked to each other and stored together in the host device 130 along with the image identifier assigned to the image. If it is determined that the image identifier assigned to the image received from the user device (e.g., 110-1) matches an existing image, at operation 460, the tentative image may be discarded from the host device 130. The item listing received from the user device (e.g., 110-1) then may further be linked to the existing image in the host device 130. In some example embodiments, the item listing and the image for the item listing may be stored in an item listing database (e.g., 140) that may be locally or remotely coupled to the host device 130. In some embodiments, the image identifier may be generated as a function of a hash algorithm, such as MD5 or SHA-1. In some example embodiments, a listing period may be set for the item listing received from the user device (e.g., 110-1). The listing period may be used to mange existing item images as described below in more detail using
In contrast, if it is determined that there is an existing image that matches the image associated with the image identifier received from the user device 110-1, at operation 650, it may be further checked whether an override notification is received from the user device. The override notification may indicate that the image will be transferred from the user device regardless of the result of the comparing at operation 620. If it is determined that there is an override notification received from the user device, then the control goes back to operation 640, where both the item listing and the image for the item listing may be received from the user device. On the contrary, if it is determined that there is no override notification received from the user device, the control goes to operation 660. At operation 660, the item listing may be received from the user device and linked with the existing image that matches the image associated with the image received from the user device. In some example embodiments, the operation 650 may not be employed. In such a case, if is determined that there is an existing image that matches the image associated with the image identifier received from the user device, the control moves from operation 630 to operation 660.
In contrast, if it is determined at operation 750 that there is a matching existing image in the host device, the control moves to operation 770. At operation 770 it may be further checked whether an override notification is sent by the user device. If it is determined that the override notification is sent by the user device, the control goes back to operation 760, where both the item listing and the image for the item listing may be uploaded to the host device. On the contrary, if it is determined at operation 770 that no override notification is sent to the host device, the control moves to operation 780. At operation 780, the item listing may be uploaded to the host device without uploading the image for the item listing. The uploaded item listing may then be linked to the existing image that matches the image associated with the image identifier. In some example embodiments, at operation 770, it may be further checked whether the override notification sent to the host device is allowed by the host device. In such a case, even if an override notification is communicated to the host device, the image for the item listing is not uploaded to the host device if the override notification is not allowed by the host device. Instead, at operation 780, only the item listing may be uploaded to the host device and the uploaded item listing may be linked to the matching existing image. In some example embodiments, the operation 770 may not be employed. In such a case, if is determined that there is a matching existing image identifier in the host device, the control goes from operation 750 to operation 780. Although
Some example embodiments may include the various databases (e.g., item listing database 140) being relational databases or in some example cases On Line Analytic Processing (OLAP)-based databases. In the case of relational databases, various tables (e.g., 250) of data are created and data is inserted into, and/or selected from, these tables using SQL or some other database-query language known in the art. In the case of OLAP databases, one or more multi-dimensional cubes or hypercubes containing multidimensional data from which data is selected or into which data is inserted using MDX may be implemented. In the case of a database using tables and SQL, a database application such as, for example, MYSQL™, SQLSERVER™, Oracle 81™, 10G™, or some other suitable database application may be used to manage the data. Here, the case of a database using cubes and MDX, a database using Multidimensional On Line Analytic Processing (MOLAP), Relational On Line Analytic Processing (ROLAP), Hybrid On Line Analytic Processing (HOLAP), or some other suitable database application may be used to manage the data. These tables, or cubes made up of tables, in the case of, for example, ROLAP, are organized into a RDS or Object Relational Data Schema (ORDS), as is known in the art. These schemas may be normalized using certain normalization algorithms so as to avoid abnormalities such as non-additive joins and other problems. Additionally, these normalization algorithms may include Boyce-Codd Normal Form or some other normalization and/or optimization algorithm known in the art.
In some example embodiments, a method is illustrated as implemented in a distributed or non-distributed software application designed under a three-tier architecture paradigm, whereby the various components of computer code that implement this method may be categorized as belonging to one or more of these three tiers. Some example embodiments may include a first tier as an interface (e.g., an interface tier) that is relatively free from application processing. Further, a second tier may be a logic tier that performs application processing in the form of logical/mathematical manipulations of data inputted through the interface level, and that communicates the results of these logical/mathematical manipulations to the interface tier and/or to a backend or storage tier. These logical/mathematical manipulations may relate to certain business rules or processes that govern the software application as a whole. A third storage tier may be a persistent storage medium or non-persistent storage medium. In some example cases, one or more of these tiers may be collapsed into another, resulting in a two-tier architecture, or even a one-tier architecture. For example, the interface and logic tiers may be consolidated, or the logic and storage tiers may be consolidated, as in the case of a software application with an embedded database. This three-tier architecture may be implemented using one technology, or, as may be discussed below, a variety of technologies. This three-tier architecture, and the technologies through which it is implemented, may be executed on two or more computer systems organized in a server-client, peer-to-peer, or some other suitable configuration. Further, these three tiers may be distributed between more than one computer system as various software components.
Some example embodiments may include the above illustrated tiers and the processes or operations that make them up, as one or more software components. Common to many of these components is the ability to generate, use, and manipulate data. These components, and the functionality associated with each, may be used by client, server, or peer computer systems. These various components may be implemented by a computer system on an as-needed basis. These components may be written in an object-oriented computer language such that a component-oriented or object-oriented programming technique can be implemented using a Visual Component Library (VCL), Component Library for Cross Platform (CLX), JavaBeans (JB), Enterprise JavaBeans (EJB), Component Object Model (COM), Distributed Component Object Model (DCOM), or other suitable technique. These components may be linked to other components via various Application Programming interfaces (APIs), and then compiled into one complete server, client, and/or peer software application. Further, these APIs may be able to communicate through various distributed programming protocols as distributed computing components.
Some example embodiments may include remote procedure calls used to implement one or more of the above-illustrated components across a distributed programming environment as distributed computing components. For example, an interface component (e.g., an interface tier) may reside on a first computer system remotely located from a second computer system containing a logic component (e.g., a logic tier). These first and second computer systems may be configured in a server-client, peer-to-peer, or some other suitable configuration. These various components may be written using the above-illustrated object-oriented programming techniques, and can be written in the same programming language or a different programming language. Various protocols may be implemented to enable these various components to communicate regardless of the programming language used to write these components. For example, a component written in C++ may be able to communicate with another component written in the Java programming language using a distributed computing protocol such as a Common Object Request Broker Architecture (CORBA), a Simple Object Access Protocol (SOAP), or some other suitable protocol. Some example embodiments may include the use of one or more of these protocols with the various protocols outlined in the Open Systems Interconnection (OSI) model, or Transmission Control Protocol/Internet Protocol (TCP/IP) protocol stack model for defining the protocols used by a network to transmit data.
Some example embodiments may use the OSI model or TCP/IP protocol stack model for defining the protocols used by a network to transmit data. In applying these models, a system of data transmission between a server and client or between peer computer systems is illustrated as a series of roughly five layers comprising: an application layer, a transport layer, a network layer, a data link layer, and a physical layer. In the case of software having a three-tier architecture, the various tiers (e.g., the interface, logic, and storage tiers) reside on the application layer of the TCP/IP protocol stack. In an example implementation using the TCP/IP protocol stack model, data from an application residing at the application layer is loaded into the data load field of a TCP segment residing at the transport layer. This TCP segment also contains port information for a recipient software application residing remotely. This TCP segment is loaded into the data load field of an IP datagram residing at the network layer. Next, this IP datagram is loaded into a frame residing at the data link layer. This frame is then encoded at the physical layer, and the data transmitted over a network such as the Internet, a Local Area Network (LAN), a Wide Area Network (WAN), or some other suitable network. In some example cases, “Internet” refers to a network of networks. These networks may use a variety of protocols for the exchange of data, including the aforementioned TCP/IP, and additionally Asynchronous Transfer Mode (ATM), Systems Network Architecture (SNA), or some other suitable protocol. These networks may be organized within a variety of topologies (e.g., a star topology) or structures.
The computer system 900 includes a processor 902 (e.g., a Central Processing Unit (CPU), a Graphics Processing Unit (GPU) or both), a main memory 901, and a static memory 906, which communicate with each other via a bus 908. The computer system 900 may further include a video display 910 (e.g., a Liquid Crystal Display (LCD) or a Cathode Ray Tube (CRT)). The computer system 900 also includes an alpha-numeric input device 917 (e.g., a keyboard), a User Interface (UI) cursor controller device 911 (e.g., a mouse), a drive unit 916, a signal generation device 919 (e.g., a speaker) and a network interface device (e.g., a transmitter) 920.
The drive unit 916 includes a machine-readable medium 922 on which is stored one or more sets of instructions and data structures (e.g., software) 921 embodying or used by any one or more of the methodologies or functions illustrated herein. The software 921 may also reside, completely or at least partially, within the main memory 901 and/or within the processor 902 during execution thereof by the computer system 900, the main memory 901 and the processor 902 also constituting machine-readable medium 922.
The software 921 may further be transmitted or received over a network 926 via the network interface device 920 using any one of a number of well-known transfer protocols (e.g., HTTP, Session Initiation Protocol (SIP)).
The term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “machine-readable medium” shall also be taken to include any medium capable of storing, encoding, or carrying a set of instructions for execution by the machine and that cause the machine to perform any of the one or more of the methodologies illustrated herein. The term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical and magnetic medium, and carrier wave signals.
Some example embodiments may include a system and method to link item images to item listings. The system and method include receiving an item listing and an image for the item listing from a user device. The system and method include assigning an image identifier to the image received from the user device. The image identifier may be identical or substantially identical for the same or similar images and unique for different images. The system and method include comparing the image identifier with one or more existing image identifiers. The system and method further include linking the received item listing to an image according to a result of the comparing.
Some example embodiments may include a system and method to receive item images for item listing. The system and method include receiving an image identifier associated with an image for an item listing from a user device. The image identifier may be identical or substantially identical for the same or similar images and unique for different images. The system and method include comparing the image identifier received from the user device with one or more existing image identifiers. The system and method further include determining whether to receive the image from the user device according to a result of the comparing.
Method examples described herein can be machine or computer-implemented at least in part. Some examples can include a computer-readable medium or machine-readable medium encoded with instructions operable to configure an electronic device to perform methods as described in the above examples. An implementation of such methods can include code, such as microcode, assembly language code, a higher-level language code, or the like. Such code can include computer readable instructions for performing various methods. The code may form portions of computer program products. Further, the code may be tangibly stored on one or more volatile or non-volatile computer-readable media such as during execution or at other times. These computer-readable media may include, but are not limited to, hard disks, removable magnetic disks, removable optical disks (e.g., compact disks and digital video disks), magnetic cassettes, memory cards or sticks, random access memories (RAMs), read only memories (ROMs), and the like.
The above “DETAILED DESCRIPTION” includes references to the accompanying drawings, which form a part of the “DETAILED DESCRIPTION.” The drawings show, by way of illustration, some example embodiments. These embodiments are also referred to herein as “examples.” Such examples can include elements in addition to those shown and described. However, the present inventors also contemplate examples in which only those elements shown and described are provided.
All publications, patents, and patent documents referred to in this document are incorporated by reference herein in their entirety, as though individually incorporated by reference. In the event of inconsistent usages between this document and those documents so incorporated by reference, the usage in the incorporated reference(s) should be considered supplementary to that of this document; for irreconcilable inconsistencies, the usage in this document controls.
In this document, the terms “a” or “an” are used, as is common in patent documents, to include one or more than one, independent of any other instances or usages of “at least one” or “one or more.” In this document, the term “or” is used to refer to a nonexclusive or, such that “A or B” includes “A but not B,” “B but not A,” and “A and B,” unless otherwise indicated. In the appended claims, the terms “including” and “in which” are used as the plain-English equivalents of the respective terms “comprising” and “wherein.” Also, in the following claims, the terms “including” and “comprising” are open-ended, that is, a system, device, article, or process that includes elements in addition to those listed after such a term in a claim are still deemed to fall within the scope of that claim. Moreover, in the following claims, the terms “first,” “second,” and “third,” etc. are used merely as labels, and are not intended to impose numerical requirements on their objects.
The above description is intended to be illustrative, and not restrictive. For example, the above-described examples (or one or more aspects thereof) may be used in combination with each other. Other embodiments can be used, such as by one of ordinary skill in the art upon reviewing the above description. The Abstract is provided to comply with 37 C.F.R. §1.72(b), to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Also, in the above Detailed Description, various features may be grouped together to streamline the disclosure. This should not be interpreted as intending that an unclaimed disclosed feature is essential to any claim. Rather, inventive subject matter may lie in less than all features of a particular disclosed embodiment. Thus, the following claims are hereby incorporated into the Detailed Description with each claim standing on its own as a separate embodiment.
