WO2010134127A1 - Plate-forme de publicité en ligne sur internet et processus s'exécutant sur ladite plate-forme - Google Patents

Plate-forme de publicité en ligne sur internet et processus s'exécutant sur ladite plate-forme Download PDF

Info

Publication number
WO2010134127A1
WO2010134127A1 PCT/JP2009/002211 JP2009002211W WO2010134127A1 WO 2010134127 A1 WO2010134127 A1 WO 2010134127A1 JP 2009002211 W JP2009002211 W JP 2009002211W WO 2010134127 A1 WO2010134127 A1 WO 2010134127A1
Authority
WO
WIPO (PCT)
Prior art keywords
field
key
serving
social
database
Prior art date
Application number
PCT/JP2009/002211
Other languages
English (en)
Inventor
Terry Hardin
Greg Ellis
Noboru Takeda
Original Assignee
Aspa-Japan Co., Ltd.
Koyama, Hiroko
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Aspa-Japan Co., Ltd., Koyama, Hiroko filed Critical Aspa-Japan Co., Ltd.
Priority to PCT/JP2009/002211 priority Critical patent/WO2010134127A1/fr
Publication of WO2010134127A1 publication Critical patent/WO2010134127A1/fr

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising

Definitions

  • the present invention relates to internet-based online advertising platform and processes running on said platform.
  • AdSense allows content owners to place advertising on websites or blogs to receive compensation for advertising revenues generated by web visitors.
  • AdSense is very popular because anyone with published content can generate revenue by placing advertising on his or her website or blog and receive virtual revenues for integrating the advertising alongside user generated content.
  • AdSense works by sensing key words within the page content and displaying relevant ads. Users register for AdSense in a simple process and then receive a special Publisher-ID Key - a unique number - which is used in the URL to identify the individual to credit when serving up ads.
  • AdSense is typical of most online Web 1.0 advertising platforms and is able to deliver HTML Text, Rich Internet and even Streaming Video ads. Despite the tremendous success of AdSense and other such platforms, these Web 1.0 advertising platforms present many technical problems, challenges and shortcomings in the Web 2.0.
  • the first technical problem is that so-called social 'Widgets' or 'Applications' can now be added alongside content on websites, blogs and within social networking sites.
  • widget application
  • the OpenSocial Container (10) would be a Web ap- plication service provider, such as blogger.com.
  • the Web Page Owner (20) would be the individual user who owns the blog and publishes the User Generated Content (30). Because blogger.com integrates AdSense, in figure 1 both the blog owner (20) and blogger.com (10) derive revenue from advertisements (40).
  • FIG. 2 depicts an advertisement (90) displayed within a social application (80), embedded alongside user generated content (70) into a blog owner's blog (60).
  • Many social applications utilize AdSense as a means for monetization.
  • neither the blog owner (60) nor blogger.com (50) would derive any revenues from the advertisement, mitigating any financial incentive to install such a social application (80).
  • the advertising displayed within the context of the social application (80) would compete with any other advertising published on the page, either within another social application or otherwise embedded within the blog.
  • AdSense and other advertising platforms do allow primitive revenue sharing between service providers and publishers, these limits create barriers in a Web 2.0.
  • Object 100 represents a Social Container, such as Blogger.com.
  • the authors (170,180,190) wish to share revenues generated by the advertisement (150) for visitors to the blog.
  • existing ad platforms do not provide this functionality. Therefore, developers have resorted to creating intermediate "plugins" to address the problem.
  • plugin (160) for WordPress which allows a blog owner (110) to define multiple publishers. With each individual request to load or refresh the webpage, the plugin (160) chooses a single author's ID key to use for said request. The plugin (160) then cycles to the next author, in series, on each subsequent request.
  • the limitation with this solution is that it does not allow for more complex scenarios, such as when distributions are not equal between authors or distributing advertising revenues between multiple content publishers, containers and application developers.
  • OpenSocial standard Another technical problem within the industry prevents the full adoption of the OpenSocial standard, hampering advertising efforts and limiting overall advertising revenues for social containers and advertising opportunities for advertisers.
  • the OpenSocial standard only specifies certain fields as mandatory, with a majority of the fields being optional.
  • implementing the full standard could dramatically increase advertising opportunities and revenues because advertisers are willing to pay a premium for socially targeted content.
  • the present invention includes the following:
  • a web server for receiving HTTP requests and returning responses in one or more forms including XHTML, XML, JSON, RSS or ATOM,
  • a Media server for storing and serving advertising media through HTTP and mobile device connections and serving advertisement media in a plurality of formats including but not limited to HTML, DHTML, Rich Internet Applications and Streaming Audio or Video,
  • a Database system consisting of a plurality of database structures for storing platform configuration information
  • ⁇ 3 ⁇ A process for distributing payments to social containers for queries to the container's social graph to third-party advertising providers that is included in the process of claim 2, wherein the process involves debiting virtual currency from an application or advertising provider and debiting moneys into the social container's account based upon the number of parameterized queries replied to.
  • ⁇ 4 ⁇ A process for collecting and aggregating analytics useful in analyzing advertising campaign success that is included in the process of claim 2.
  • ⁇ 5 ⁇ A process for measuring social influence of users within asocial network that is included in the process of claim 2, wherein users represent any number of distinct entities including individuals, organizations and applications.
  • ⁇ 6 ⁇ A database system that is included in the internet-based online advertising platform of claim 1, which comprises at least four database sub-systems including the following (a) to (d):
  • a Platform Database sub-system for storing general platform configuration information including but not limited to lookup tables, logged ad events, ad types, a master category list, demographic targeting field list, and platform users,
  • An Advertising database sub-system for storing information relative to advertisers, campaigns, advertisements, ad targeting configurations, and registered advertising user agents,
  • An Application database sub-system for storing information relative to applications, containers, container application categories, application rankings, registered application developer user-agents, and developer rankings
  • a Container database sub-system for storing information relative to containers, container categories, available demographics, payment zones, and registered container user- agents.
  • a method of claim for configuring Social Containers that is included in the method of claim 7, which comprises the following (a) to (c):
  • a method for configuring social applications that is included in the method of claim 7, which comprises the following (a) and (b):
  • a method for configuring advertising to be served to social network users that is included in the method of claim 7, which comprises the following (a) to (c):
  • ⁇ 12 ⁇ A process for determining which advertisements to serve up advertisements.
  • ⁇ 13 ⁇ A process of distributing virtual micro-payments among one or a plurality of entities with an algorithm that is included in the method of claim 7, which further comprises the following (a) to (c):
  • a plurality of URLs further comprising the following (i) to (iii):
  • Feeds wherein said feeds consists of JSON, XML, XHTML, WML , RSS or
  • a Platform Database sub-system that is included in the database system of claim 6, which comprises the following (a) to (e):
  • AdEvents table to store advertising events such as clicks, views, purchases, recommendations and other activities further comprising the following (i) to (vi): (i) A clustered, unique-id, primary-key field, AdEventID for uniquely identifying each row in the database, wherein the value presented is globally unique across all id fields in all databases within the system,
  • a TimeStamp field for tracking the date and time of the advertising event
  • a ContainerID field serving as a foreign-key
  • a ViewerUserID field serving as a foreign-key to refer to said UserID field of the undermentioned b.(i)
  • An OwnerUserID field serving as a foreign-key to refer to said UserID field of the undermentioned b.(i)
  • a Platform Users table further comprising the following (i) to (vii):
  • a clustered, unique-id, primary-key field for uniquely identifying each row in the database wherein the clustered index comprises the following two fields, Demo- graphicID field and VersionSpec Field, (ii) A Path field, and (iii) An Optional field,
  • AdTypes table further comprising the following (i) and (ii):
  • a Description field for maintaining a description for each AdType includes but are not limited Click, View, Purchase, Referral and Lead, representing the type of action for which to generate revenue incomes for a specific advertisement, and
  • a Categories table to hold an aggregated list of application categories submitted by containers for classifying applications at registration time, further comprising the following (i) to (iii):
  • An Advertiser field serving as a foreign-key to refer to said AdvertiserID field of the aforementioned (a),(i), and
  • AdDemographicTargets table further comprising the following (i) to (vi):
  • An AdvertisementID field serving as a foreign-key to refer to said AdvertisementID field of the aforementioned (b),(i),
  • An AdApplicationTargets table further comprising the following (i) and (ii): (i) A clustered, unique-id, primary-key field for uniquely identifying each row in the database, wherein the clustered index further comprises the following (1) and (2):
  • An AdvertisementID field serving as a foreign-key to refer to said Adver- tisementID field of the aforementioned (b),(i), and
  • AdCategoriesTargets table further comprising the following (i) and (ii):
  • An AdvertisementID field serving as a foreign-key to refer to said AdvertisementID field of the aforementioned (b),(i), and
  • a clustered, unique-id, primary-key field for uniquely identifying each row in the database wherein the clustered index further comprises the following (1) to (3): (1) An ApplicationID field, serving as a foreign-key to refer to said ApplicationID field of the aforementioned (a) (i), (2) An ContainerID field, serving as a foreign-key, and
  • a Container table further comprising the following (i) to (v):
  • a Zones table further comprising the following (i) to (v):
  • ZoneID for uniquely identifying each row in the database, wherein the value presented is globally unique across all id fields in all databases within the system
  • a ContainerDemographics table further comprising the following (i) to (vi):
  • a ContainerID field serving as a foreign-key to refer to said ContainerID field of the aforementioned (a) (i),
  • An ContainerID field serving as a foreign-key to refer to said ContainerID field of the aforementioned (a) (i), and
  • a ContainerCategories table further comprising the following (i) to (iv):
  • An ContainerID field serving as a foreign-key to refer to said ContainerID field of the aforementioned (a) (i), and
  • a ZoneApplicationUsers table further comprising the following (i) to (iii):
  • ZoneID field serving as a foreign-key to refer to said ZoneID field of the aforementioned (b) (i), and
  • FIG. 2 depicts an advertisement displayed within a social application.
  • FIG. 3 is a schematic drawing of the prior art.
  • FIG. 4 depicts sharing virtual micro-payments between multiple authors of a blog.
  • FIG. 5 depicts the collaborate monetization of a social application.
  • FIG. 6 depicts the operation of the advertising platform of the present invention.
  • FIG. 7 illustrates the sequence necessary to serve up advertisements.
  • FIG. 8- A illustrates a method of calculating revenue distributions for shared monetization.
  • FIG. 8-B illustrates a method of calculating revenue distributions for shared monetization.
  • FIG. 9- A depicts the database structure of the present invention.
  • FIG. 9-B depicts the entity relationship diagram for the present invention.
  • FIG. 9-C depicts the entity relationship diagram for the present invention.
  • FIG. 9-D depicts the entity relationship diagram for the present invention.
  • FIG. 9-E depicts the entity relationship diagram for the present invention.
  • FIG. 10-A depicts the detailed overview of the various use-cases of the present invention.
  • FIG. 10-B represents the Proposed form for the present invention.
  • FIG. 10-C depicts the Advertiser Manager form for the present invention.
  • FIG. 10-D depicts the Manage Advertisement form for the present invention.
  • FIG. 10-E depicts the Manage Advertiser Agent form for the present invention.
  • FIG. H-A illustrates the use-cases diagram of the present invention.
  • FIG. H-B depicts the Manage Container form for the present invention.
  • FIG. 11-C depicts the simple dialogue form for the present invention.
  • FIG. 11-D depicts the simple dialogue form for the present invention.
  • FIG. 12-A illustrates the use-cases diagram of the present invention.
  • FIG. 12-B depicts the Register / Manage Application form for the present invention.
  • FIG. 12-C represents the form used to invite / edit zone users for the present invention.
  • FIG. 13-A depicts the standard approach to monetizing social applications.
  • FIG. 13-B is a schematic drawing of the present invention.
  • FIG. 13-C illustrates the industry-centric role of the patented advertising platform.
  • FIG. 14-A depicts the traditional approach to providing analytics.
  • FIG. 14-B illustrates the enhanced Web 2.0 analytics functionality of the present invention.
  • FIG. 14-C illustrates another distinguishing characteristic of the present invention.
  • FIG. 15-A illustrates a very simple social network.
  • FIG. 15-B illustrates the social network for the present invention.
  • FIG. 15-C depicts unidirectional non-friendship social transactions for the present invention.
  • FIG. 16-A illustrates a simplified social network with social transactions.
  • FIG. 16-B represents a table summarizing the eigenseparation calculations.
  • FIG. 16-C represents a table containing the measures of centrality.
  • Fig. 16-D represents a table representing the eigenfeedback values.
  • Fig. 16-E represents a table representing the average influence eigenvalue.
  • FIG. 17 illustrates the functioning social influence engine for the present invention.
  • the present invention addresses these problems by implementing a method to enable sophisticated collaborative monetization across many partners including social containers, users and application developers. Using these methods, revenues can be shared between any number of entities, including Social Graph Providers, Widget Application Developers, Design Artists and Content Owners / Publishers.
  • the present invention also enables social containers to derive revenues by charging for queries to the social graph, all while securing the social graph from unauthorized access by social applications.
  • FIG 4 in contrast to figure 3, in regard to sharing revenues between multiple authors of a blog (210).
  • Each of the three authors (280, 290, and 300) contributes individual content (220, 230, and 240) to the same blog.
  • Item 200 represents the Social Container, such as Blogger.com, or any other Social container.
  • a plugin (160) cycles through the three authors (170,180,190) with each request.
  • each request is serviced by a collaborative monetization API (260), which creates a collaborative transaction (270), paying a percentage of advertising revenues to all three authors (280,290, 300) on every request.
  • the plugin (160) rotates through the three authors as in figure 3, the plugin (160) distributes to equal amounts to each of the three authors (170,180,190), in turn for each request.
  • the distributed transaction (270) is able to distribute any percentage to each of the three authors (280,290,300), so long as the total of all distributions in the transaction total to one-hundred percent (100%) of the total ad revenue generated by the advertisement (250).
  • FIG. 5 depicts the collaborate monetization of a social application (360), allowing sophisticated revenue sharing between the social container (400), two application developers (410,420) and three authors (430,440,450).
  • the advertisement (370) is presented within the context of a social application (360), which was developed by a team of two developers (410,420).
  • Three authors (430,440,450) publish user generated content (330,340,350) for the blog webpage (320).
  • the social container (310) hosts the blog webpage (320), and therefore receives a share of the revenues (400).
  • the advertisement API (380) spawns a collaborative transaction (390) to distribute revenues between all parties (400 - 450).
  • Figure 6 depicts the operation of said advertising platform (1090) relative to the Internet (1050), social end-user devices (1010, 1020, 1030) and a social container's Web-client (1060) and REST-server (1170) interfaces.
  • Users connect to the Internet through any number of devices, including but not limited to a personal computer (1010), smart phone (1000) or laptop (1020), all of which are capable of using via HTTP, FTP, SMTP or POP3.
  • users may connect to the Internet using a standard cellular telephone (1030) using WAP, connected through a cellular tower (1040).
  • Advertisements (1080) can appear within the social application (1070) or within the social container (1060), such as MySpace, Linkedln or Blogger.com, as examples.
  • the advertisements are embedded within the client webpage and served up by the Advertising Platform System's (1090) Web Server (1110).
  • the Advertising Platform System consists of a number of subsystems, including, but not limited to an FTP Server (1100), a Mobile Information Server (1120), an eMail Server (1130), a Media Server (1140), an Application Server (1150) and a Database Server (1160).
  • the Advertising Platform System (1090) determines which advertisements to serve from the Database Server (1160) when the Application Server (1150) first references the unique user ID-Key contained in the request to the Web Server (1110).
  • the application server then makes a secure OAuth request to the social container's REST Web Server (1170) to query the social graph (1190) field values for the user via the social container's API (1180). These values are then compared against the list of advertisements stored in the database server (1160) and the best advertisements are returned by the Web Server (1110) to the social container's webpage (1060).
  • Figure 7 Ad Serving Sequence Diagram>
  • Figure 7 illustrates the sequence necessary to serve up advertisements.
  • the social application (1300) makes a call to the Advertising Platform's API (1310) using the getAdvertisements REST procedure call (1340).
  • the request contains the necessary metadata to identify the user, social container, application and other necessary information provided by the social container.
  • the ad API then calls the social container (1320) via secure OAuth REST request (1350) to query the necessary social fields for the user.
  • the advertisement API makes subsequent calls to the database (1330) to retrieve a list of relevant ads (1360) and advertiser bidding data (1370).
  • the advertising API then processes the data to select the best ads to serve (1380) and then formats the ads for presentation (1390).
  • the ad API queues the ad event (1400) so that the payment subsystem (see figures 8A and 8B) can calculate revenue distributions.
  • the Advertisement API returns the formatted advertisements (1410) to the social application and logs the ad event (1420) to the database for reporting.
  • Figures 8A and 8B illustrate two different methods of calculating revenue distributions for shared monetization. Both methods would satisfy the criteria necessary to monetize advertisements according to figure 5C, wherein, advertising revenues are distributed between a social container (400), two application developers (410,420) and three blog authors (430,440,450).
  • Figure 8B would be sufficient to support most advertising within contemporary social environments.
  • Figure 8A demonstrates a more flexible solution, which allows a social container to support distributions within any number of payments zones, with each zone supporting multiple pay entities for revenue sharing distributions.
  • Figure 8B only supports three specific zones: container, application and owner, while allowing for distributions among any number of entities within each zone.
  • the initialization sub-process (2000 - 2070 and 2300 - 2370) begins by pulling a message from the ad activity queue (2000 and 2300). Note that the component could either poll the queue or receive notification of new queued items. The component then loads the appropriate metadata including the advertisement and container (2010 and 2310), zone (2020 and 2320), and application (2030, 2330) - in the case of 8B, there are only three predetermined zones, while case 8A would have a variable number of zones depending upon configuration. The ideal system would utilize cache (2040 and 2340) to speed up the process and improve processing performance.
  • the initialization process After determining the revenue amount for the advertisement (2050 and 2350), the initialization process then creates a transaction (2060 and 2360).
  • the transaction is important in the finalization sub- process (2160 - 2200 and 2530 - 2570) so that the sub-process can commit the transaction (2170 and 2540) if all credits and debits succeeded, or rollback the transaction (2180 and 2550) in the case of a failure. If a transaction fails and the component issues a rollback, the ad activity item is put back onto a queue for further processing (2190 and 2560).
  • the revenue distribution method depicted in 8A consists of two nested loops.
  • the outer-loop beginning at 2080 and looping at 2150
  • the nested inner-loop iterates through each user-entity (2110) configured within the zone in scope, calculating the entity's percentage amount (2120) of the revenues and then crediting the entity's account (2130).
  • the total of all entity percentages within a zone must equal 100% when configuring zone distribution entities in the user interface.
  • the difference in method 8B is that the configuration only calls for a predetermined number of 'zones', as opposed to allowing for any number of zones.
  • container (2380 - 2410)
  • application (2430 - 2460)
  • owner (2480 - 2510)
  • the application is able to distribute to multiple entities within each of the predefined zones, which no other system currently does.
  • This example is presented merely to demonstrate the two different types of logic that one might use to approach the problem.
  • Naturally 8A is far more flexible from a logical standpoint, but requires a much more sophisticated database and a more complex User Interface to support the additional functionality.
  • Method 8B is less flexible, but utilizes a simpler database and a much simpler user interface that could be more easily standardized across containers (for example, if establishing a specific industry standard).
  • 8A could be better utilized to define not only one industry standard, but several standards, each adjusted to specific targeted niche markets within any industry. Nevertheless, both approaches are illustrated for the purpose of completeness.
  • Figures 9A - 9E depicts the database structures necessary to provide functionality for the advertising platform under consideration.
  • Figure 9A illustrates a database consisting of four logical divisions including the Platform (3000), Advertiser (3060), Application (3110) and Container (3170) structures.
  • the four logical divisions each consist of several subdivisions, which roughly correspond to a table in a relational or object-oriented database.
  • the Platform division contains five logical subdivisions (3010 - 3050) that hold information pertaining to the overall platform such as user (3050), event logging (3010) and other master list and lookup tables (3020, 3030 and 3040).
  • the Advertiser division's four subdivisions store data relative to the advertiser (3070), registered user agents (3100), advertisements (3080) and demographic targeting information (3090).
  • the Application subdivision stores information about applications (3120) and developers (3150), such as rankings (3140, 3160) and registered categories within installed containers (3130).
  • the Container division contains information about each social container (3180), application categories (3190) offered by the container, available social demographic fields (3200), payment zone configurations (3210) and user agents (3220).
  • Figure 9B is an entity relationship diagram for the tables (3300 - 3340) that correspond to each of the five subdivisions of the Platform division.
  • the AdEvents table (3300) stores information for advertisement impressions, clicks, referrals and leads, along with identifying information to identify the application, container ad viewer and page owner.
  • the PlatformUsers (3310) holds information about the users of the platform, which can also associate as registered agents with applications, containers and advertisers.
  • OSDemographicFields (3320) stores the version specific list of fields available for demographic targeting such as age, gender, and other social container profile information available.
  • AdTypes (3330) describe is a master lookup table referenced by AdEvents (3300) and Advertisements table (fig 9C 3420). Possible values for AdTypes include impressions, click, referral and lead.
  • Categories (3340) refer to the possible categories in which an application may list within the various social containers. For example, applications might list in categories such as Health and Beauty, Games, Educational or Politics.
  • FIG 9C is the entity relationship diagram for the Advertiser subdivision.
  • the Advertiser table (3400) stores the information about the advertisers.
  • the Adver- tiserUserAgents table (3410) provides for the functionality of registering user agents to help manage a portfolio of advertisements. An advertiser must have at least one registered agent.
  • the Advertisements table (3420) stores all the necessary information about an advertisement.
  • the Ad Target Tables (3430 - 3460) provide storage for targeting information relative to demographics (3430), applications (3440), categories (3450) and/or containers (3460).
  • Figure 9D is an entity relationship diagram for the Container division.
  • the Container table (3500) stores the information about the social container itself.
  • the ContainerDe- mographics table (3510) allows the container to define which demographics are available for advertisement targeting and the ContainerCategories table (3530) holds a list of application categories supported by the container.
  • the Zones table (3550) stores the information about each zone established within a social container. For example, the zones established in figure 5 would include Container (400), Application Developers (410, 420) and Owner (430, 440, 450).
  • the ZoneApplicationUsers table (3540) holds references to the users accounts associated with each application zone configured in the container.
  • Figure 9E is the entity relationship diagram for the Application division.
  • the Application table (3600) stores the information about the various applications registered in the platform. Applications are then associated with various categories within containers through the ApplicationCategories table (3610). Users are associated as developers of an application through the ApplicationDevelopers table (3630), which allows these users to access reports and manage application settings within the platform. Finally, platform also provides for both application and developer rankings through the ApplicationRankings (3620) and DeveloperRankings (3640) tables, respectively. [0037] ⁇ Figures 1OA - 1OE: Advertiser Use-Case and UI Diagrams>
  • Figures 1OA - 1OE provide a detailed overview of the various use-cases (figure 10A) and necessary user interface elements (figures 1OB - 10E) available to Advertiser Users (4000).
  • the Register Advertiser use-case (4010) allows a user to register as an advertiser, which further allows the user to manage advertiser properties (4020).
  • the Manage Ad Agents use-case (4030) allows the advertiser to assign other users to help manage a portfolio of advertisements. Given sufficient rights, the advertiser can also manage funds (4040).
  • Managing Advertisements provides the functionality necessary to set advertisement targets for demographics (4060), containers (4070), and categories (4080), as well as to manage advertisement properties (4090), such as the type of advertisement, maximum bids and media source-files, for instance.
  • Figure 1OB represents a proposed form (4200) with elements necessary for a registered user to sign up as an advertiser.
  • the screen displays text boxes for input of an advertiser name (4210) and primary email address (4220).
  • the email address corresponds to the registered user's platform email address.
  • the form also provides mutually exclusive radio buttons for the user to indicate if the advertiser account is a business (4230) or a personal (4240) account.
  • the save and verify button (4250) first saves the information input into the form, then initiates the process to verify the new account sending a validation email or secure, and finally closes the form.
  • Figure 1OC depicts the Advertiser Manager Form (4300), which is the main form for managing advertiser properties, account type, advertiser agents and advertisements.
  • the radio buttons Verified (4310) and Unverified (4320) are not user-configurable and show the current status of the advertiser account. Users can only manage properties and lists after verifying the account.
  • Mutually exclusive radio buttons Business Account (4340) and Personal Account (4350) allow the advertiser to configure the account type, respectively.
  • the form also provides two text boxes, Advertiser Name (4360) and Primary Email Address (4370), are used to configure the name and primary email for the account.
  • the form provides two scrollable table lists for navigating and selecting Advertiser Agents (4380) and Advertisements (4390).
  • buttons to the right of each table list allow the user to Edit (4400, 4430), Create (4410, 4440) and Delete (4420, 4450) selected records, respective of the associated list.
  • the Done button (4460) saves the configuration changes and closes the form.
  • the command button to Manage Funds (4330) opens another dialog screen used to allow the user to add funds to the account.
  • the Manage Advertisement Form (4500) depicted in figure 1OD provides the controls necessary to manage all the properties and targeting information for an advertisement.
  • the first control (4510) residing in the upper-left of the form, is simply a label to display the name for this advertisement.
  • the form also contains six list-boxes (4520 - 4570), which are used to select and unselect targeting criteria.
  • the list boxes on the left display the options from which to select for the available Containers (4520), Categories (4530) and Applications (4540).
  • the list boxes on the right display the criteria selected for Containers (4530), Categories (4560) and Applications (4570).
  • the button controls between the two sets of list boxes (4580) allow the user to move selected items back and forth between the available lists (4520 - 4540) and the selection lists (4550 - 4570).
  • Controls 4560 - 4640 are used to target a list of demographics.
  • the OS Profile Field drop-down combo-box (4590) lists all of the available OpenSocial Fields available within the selected containers (4550), keeping in mind that most social containers do NOT implement the complete OpenSocial standard.
  • the user can choose a logical operator (4600) to use as a comparator against the defined variables in the First (4610) and Second (4620) values text boxes. Note that the second value will not always be necessary, such as when using equality operators (e.g. equals, less than, etc.). The second value will, however, be useful for defining values for the between operator, such as when defining a range of dates or integer values (e.g. birth dates, number of children, etc.).
  • the Add to List button (4630) allows the user to add configured values to the list table (4640), which displays the currently configured OpenSocial Field Target values.
  • the final section of the form consists of three separate controls (4650 - 4670) for configuring advertisement spend information.
  • the Max Daily Spend textbox (4650) allows the user to configure the maximum amount to spend per day for this advertisement.
  • the Add Type combo-box control (4660) allows the user to configure the type of ad event that triggers payment for the ad this advertisement: per impression, click, referral or lead.
  • the Max Bid text box (4670) determines how much each ad event pays.
  • the Done button (4680) saves the configuration information and closes the form.
  • Figure 1OE Depicts the Manage Advertiser Agent form (4800), which allows the advertiser user to manage advertiser agents assigned to help manage the portfolio of advertisements.
  • the mutually exclusive radio buttons display if the registered agent is Verified (4810) or Unverified (4820).
  • the textbox (4830) is used to configure the primary email address for the advertiser agent.
  • Two list boxes (4840, 4860) allow the user to select from a list of access rights to grant to the new advertiser agent.
  • the left list box (4840) displays the list of access rights available, and the list box on the right displays which access rights have been assigned to the advertiser agent.
  • the control buttons in the middle (4850) provide the controls necessary to move items between the two lists. Buttons 4870 and 4880 allow the user to save or cancel, respectively, and close the screen.
  • Figures 1 IA- 1 ID Container Use-Case and UI Diagrams>
  • Figure HA Container Use-Case>
  • Figures 1 IA - 1 ID illustrate the use-cases and user interface elements necessary for managing Container information.
  • Figure 1 IA is a use-case diagram depicting the minimum functionality for a Container user, including the functionality to managing Zones (5010) and revenue sharing percentages for each zone (5020), as well as to set the appropriate Application Categories (5060) for the container.
  • Figure 1 IB depicts the Manage Container Form (5100).
  • the Container Name textbox (5110) sets the user- friendly name used to reference the container.
  • the Manifest URL textbox (5120) provides for an optional URL path pointing to a manifest file that allows the container to manage most of the container's properties by publishing a unique XML file to the website, as opposed to having to update data via the user interface.
  • the Environment Name textbox (5130) is used to set the name of the environment sent by the container when making requests for advertisements.
  • the form also provides two table lists for managing Zones (5140) and Categories (5150).
  • the command buttons (5160 - 5210) to the right of the list tables provide functionality to Edit (5160, 5190), Create (5170, 5200) and Delete (5180, 5210) selected items from respective table lists.
  • the Done button (5220) saves the configuration changes and closes the form.
  • Figures 11C and 1 ID are simple dialogues forms that allow configuration of specific Zone (5300) and Category (5400) records, respectively.
  • the Zone dialog form provides controls to configure the Zone Name (5310) and the Revenue % (5320), as well as a Done command button (5330) to save changes and close the form.
  • the Manage Application Form (5400) presents a textbox for configuring the Category Name (5410), a Status drop-down combo box (5420) for selecting the status of the category and a Done button (5430) to save settings and close the form.
  • Figures 12A - 12C are the use-case and user interface diagrams.
  • Figure 12A represents the use-cases available to the Application User (6000).
  • Application users can both Register Applications (6010) within installed Containers (6030), manage Application Properties (6020) and register Developers (6040), including setting up the revenue sharing percentage (6050) for each of the associated application developers.
  • Figure 12B is the Register / Manage Application form (6100), which is used to configure application settings or create a new application.
  • the first textbox (6110) references the Application Name.
  • the second textbox (6120) points to the gadget Manifest URL - the xml file that holds the source-code for the social application.
  • the form also contains four list-boxes (6130 - 6160), which are used to select and unselect the installed containers and categories criteria.
  • the list boxes on the left display the options from which to select for the available Containers (6130), and Applications (6140).
  • the list boxes on the right display the criteria selected for Containers (6150) and Categories (6160).
  • the button controls between the two sets of list boxes (6170) allow the user to move selected items back and forth between the available lists (6130, 6140) and the selection lists (6150, 6160).
  • the categories list boxes are dynamically bound to the categories list boxes.
  • the Orkut container is highlighted as selected (6180), which limits the items listed in the Available Categories (6140) and Assigned Categories (6160) list boxes.
  • a list table (6190) of Application developers assigned to the receive ad revenues in relation to the application.
  • To the right of the Application Developers list table are the command buttons to Edit (6200), Invite (6210) or Delete (6220) selected developers. Clicking on the Invite or Edit buttons both open a similar dialog box (figure 12C) the only difference being that the Edit dialog is populated with data relating to the selected developer, while the invite dialog is empty and ready to accept new data for the invitee.
  • the Done command button (6230) saves all configuration changes and closes the form.
  • Figure 12C represents the form (6300) used to invite / edit zone users.
  • the form contains two text boxes used to configure the email address (6310) for the invitee, as well as the revenue share percentage (6320) for this user in this zone.
  • the Done command button (6330) saves the configuration information, closes the form and sends out a verification/confirmation email.
  • Figure 13A depicts the standard approach to monetizing social applications.
  • a user (6400) is running a social application (6410), which displays one or more advertisements (6420).
  • the advertisement runs within the context of the social application and makes API calls back to the social graph provider (6430), accessing user social data from the social graph database (6440).
  • the API then makes a call back to the advertiser provider (6450), matching social data up with the advertisements stored within the advertising database (6460).
  • This scenario presents two problems for the social graph provider.
  • Figure 13B depicts a better approach to the problem, allowing social graph providers to improve security, capitalize on more advertising opportunities, and monetize queries to the social graph
  • the advertising platform keeps track of the number of queries to the social graph and charges the advertiser for the quantity of access. For instance, one social graph provider may decide to charge $1 USD or 100 Yen to for every 1000 queries, while another social graph provider decides to charge double that amount.
  • the user (6500) connects to a social application (6510), which displays an advertisement (6520).
  • This solution offers an intermediate social advertising platform (6530), between the advertiser provider (6560) and the social graph provider (6580).
  • the platform helps improve performance by allowing the advertising provider to synchronize the advertising database on the advertiser side (6570) with the advertising database on the platform side (6540). Furthermore, the platform also allows the social graph provider to synchronize between the social graph database on the social graph provider side (6590) and on the advertising platform side (6550). In this scenario, applications that display advertisements merely make an API call to the social advertising platform, which is able to then select the appropriate advertisement according to data stored internally, without having to make external calls to the advertising provider or social graph provider.
  • FIG. 13C illustrates the industry-centric role of the patented advertising platform.
  • social advertising platform (6600) provides the functionality and storage necessary to support many advertiser providers and social graph providers.
  • the social advertising platform allows advertiser A (6680), advertiser B (6670) and advertiser C (6660), are able to update individual and separate instances of their own respective database instances (6610, 6620, and 6630) respectively. This is the same for the social graph providers.
  • the advertising platform allows social graph provider A (6700), social graph provider B (6710), and social graph provider C (6720) to maintain individual and separate databases within the platform (6640, 6650 and 6660), respectively.
  • Figure 14A illustrates the traditional approach to providing analytics.
  • a user (6800) connects to an application via a standard web browser (6810).
  • the application provider (6880) embeds a so-called web-beacon into the application (6820).
  • Common web beacons include embedding a JavaScript file (6830), or a web graphic image (6840) such as a png, jpeg or gif file.
  • a JavaScript file would be included in the HTML head section, and image files are usually only a single pixel in size, so as to minimize interference with rendering in the application content area (6850).
  • the embedded object (6830 or 6840) forces the browser to issue a request, via the Internet (6860), to the analytics provider's server system (6870).
  • the URL pointing to the beacon resource can also include additional parameters passed for additional user-defined tracking codes and references, enhancing final reporting.
  • the analytics provider only has access to information included in the HTTP request header, including browser encoding, language and user-agent.
  • the request also includes the IP address, which allows the analytics provider to derive geographic and ISP metrics.
  • an embedded JavaScript file also allows the analytics provider to use JavaScript functions to keep track of timings, such as the amount of time spent on a page.
  • using cookies the tracking system would be able to track user behavior across many affiliate sites.
  • the request does not include any specific user-identifying information.
  • FIG 14B illustrates the enhanced Web 2.0 analytics functionality provided by the patented social advertising platform (6970). Similar to the traditional approach, the user (6900) connects to a social application (6920) within a web browser (6910). As with the traditional approach, the application provider (7010) embeds a beacon JavaScript file (6930) or graphic image (6940) within the application, allowing the analytics provider the same information available to standard Web 1.0 analytics.
  • the social advertising platform (6970) includes databases for the advertising database, analytics database and social graph database, it becomes possible to aggregate data with regard to social information, such as age, gender, friends and favorites, as examples. Also, because OpenSocial implements the same API across many websites and social networks, it becomes possible to track user statistics, in aggregate, across all compliant providers.
  • Figure 14C illustrates another distinguishing characteristic of the patented social advertising platform.
  • analytics are of interest not only to application developers (7110), advertisers (7120), and content publishers (7130), but also to end-users (7100).
  • all users, including developers, advertisers, publishers and end-users connect via the Internet (7140) to the social advertising platform (7150). This provides all users with access to the same aggregated data relative to the advertisements database (7160), the analytics database metrics (7170) and social graph data (7180).
  • Measuring social influence is of significant value to the online advertising industry. Accurately estimating and measuring social influence offers value to advertisers, who would prefer to target individuals with higher social influence within a social network.
  • One way to measure social influence is simply to count all the connections with a node within a social network.
  • Figure 15A illustrates a very simple social network.
  • user Ul (7500) has five friends: friend Fl (7510), friend F2 (7520), friend F3(7530), friend F4 (7540) and friend F5 (7550). With a simple connectivity count, user Ul would have a score of 5.
  • FIG. 16C illustrates such a complex network.
  • user Ul (8100) is connected to three friends: friend F-I (8110) friend F-2 (8120) and F- 3 (8130).
  • friend F-I 8100
  • friend F-2 8120
  • F- 3 8130
  • each of these friends have friendship connections with FoF-4 - FoF12 (8140, 8150, 8160, 8170, 8180, 8190, 8200, 8210, and 8220, respectively).
  • Figure 16A illustrates a simplified social network with social transactions. Based upon the social network topology depicted in 16 A, the process involves calculating eigenvalues for separation, centrality, and feedback. These eigenvalues are then averaged together using any number of averaging techniques, one preferred method of which is then presented.
  • user U 1(8500) is at the center of a social network, having two friends F-I (8510) and F-2 (8530), through bidirectional friend connections (8515 and 8513) represented as solid lines with arrows on both ends.
  • User Ul is also connected to three friends-of-friends FoF-3 (8540), FoF-4 (8550) and FoF-5 (8560) through bidirectional second-degree friend connections 8545, 8555 and 8565, also represented as solid lines with arrows on both ends.
  • Social transactions that do not have a ranking are valued as a value of one of a total of one possible ranking.
  • OpenSocial gadgets are able to send a so-called activity message through the API from one user to another. Sending such an activity or responding to an activity would represent an unranked social transaction, receiving a value of one out of a total of one possible ranking value (8620).
  • user U2 is not directly contained in the social network of friend connections, but is considered due to social transactions 8580 and 8590, which take place between U1 ⁇ U2 and U1 ⁇ U2, respectively.
  • D e measures the separation effect for any node (u ; ) within a social graph. Note that S d (i,j) equals zero if nodes i,j are not connected. Otherwise, S d (i,j) equals the inverse of the degrees of separation of the shortest path between the two nodes i,j within the social graph.
  • ⁇ is a function of the entire graph and not any particular node within the social graph, where ⁇ is calculated using the Power Method or any other common principal eigenvalue algorithm, of which there are many.
  • Figure 16B represents a table summarizing the eigenseparation calculations for all the various nodes within the network, as specifically relates to the bidirectional friend connections between nodes.
  • the columns are: row is a row number for reference, user represents user (u ; ) in the equation, friend represents user (u,), the connection path is the path of connection between users (Ui j ), cj is the number of connections for user (u,), deg represents the degrees of separation between users (Ui j ), wr is the weight to be applied to the ranking as a result of the degrees of separation, nr represents the normalized rank for each connection attributed to user (u ; ) and rank is the final rank for each user (u ; ). Note that user U2 is zero for all nodes because the user is not connected to any nodes in the network as a friend.
  • Formula 2 Eigencentrality [0067]
  • U 6 measures the centrality for any node (u ; ) within a social graph.
  • Centrality is important in estimating the probability that an advertisement is likely to pass through a specific node within the social network. Consequently, it is assumed that nodes with higher centrality are more likely to receive information virally propagating through the network. Note that P d (i,j) equals zero if nodes i,j are not connected. Otherwise, P d (i,j) equals the total count of all paths between the two nodes i,j within the social graph, divided by the degrees of separation between the two nodes.
  • ⁇ is a function of the entire graph and not any particular node within the social graph.
  • Figure 16C represents a table containing the measures of centrality for each connection and node within the social network depicted in Figure 16 A.
  • the column headings are: row is a row number for easy reference, user is user (u ; ), friend is user (u,- ), path is the path of connection between users (Ui 0 ), pr is the weight to be applied to the ranking as a result of the degrees of separation and number of connections on each node along the path, Ir represents the normalized rank for each connection attributed to user (Ui) with respect to the total number of connections in the network, and ecRank is the final rank for each user (u ; ). Note that user U2 is zero for all nodes because the user is not connected to any nodes in the network as a friend.
  • F e measures the feedback effect for any node (u ; ) within a social graph, based upon feedback received relative to a node.
  • J?/ ( * ⁇ 7j ) equals the total feedback, given as a ratio of total possible feedback given to i fromy Rf ⁇ * ⁇ 7j ) .
  • the ranking scale is given from 1 through 5 and there are three rankings from / to / Rf ( i» j,),
  • Figure 16D is a table representing the eigenfeedback values F 6 (U 1 ) for every node u ; in the social graph depicted in figure 16 A.
  • the column row is a row-number included for easy reference, target and origin refer to i and j from the term ( l «i J, txRef is the social transaction reference from figure 16D, rv is the ranking value assigned to the social transaction, wr is the weighted rank for each social transaction and efRank is the eigenfeedback ranking F 6 (U 1 ) as derived from formula 3.
  • Formulas 4 Averaging Eigen influence Values
  • Formula 4 represents one possible way to average the resulting eigenvalues.
  • Other possible variants for evaluating the interaction between the eigenvalues include: 1) de- mographically weighted measures, and 2) limiting the set of nodes evaluated according to key/value pairs contained within the user's social profile.
  • Figure 16E is a table representing the average influence eigenvalue I 6 (U 1 ) for every node depicted in Figure 16A, taking into account all three eigenvalues D 6 (U 1 ), F 6 (U 1 ) and U 6 (U 1 ) for each node, as taken from figures 16B, 16C and 16D, respectively.
  • Figure 17 A illustrates the functioning social influence engine hosted within the advertising platform.
  • the user (9000) connects to a social network via a web browser (9010).
  • a social application (9020) runs within the browser, providing interactive functionality within the application content area (9040). Examples of interactions include sending messages, replying to friends messages, or recommending or ranking other users in the network, applications or interesting URLs, as examples.
  • the social application Through the social application, the user is able to connect through the Internet (9050) to friends and other users in the social network (9090).
  • the social application is able to send information to the patented social advertising platform (9060) through the internet in any number of formats including, but not limited to RSS, ATOM, JSON and XML.
  • Messages can be pulled from passive sources on a scheduled, polled basis, or pushed from applications on a transactional basis. Incoming messages are placed into a queue (9070) for parallel processing and aggregation, combining data from the analytics database (9090) and the social graph database (9080).
  • Reference Signs List [0074] 200, 310, 400 Social Container
  • 3000 Platform 3300 AdEvents table, 3400 Advertiser table, 3500 Container table, 3600 Application table

Abstract

La présente invention concerne une plate-forme de publicité en ligne sur Internet qui comporte (a) un serveur Internet pour recevoir des requêtes HTTP et renvoyer des réponses, (b) un serveur FTP pour télécharger en vrac des réglages de configuration, (c) un serveur de courriel, (d) un serveur d'informations mobile, (e) un serveur multimédia, (f) un serveur d'application pour exécuter des processus d'arrière-plan, (g) un système de base de données consistant en une pluralité de structures de base de données pour stocker des informations de configuration de plate-forme, (h) un moyen pour permettre une monétisation et une distribution collectives de revenus publicitaires, (i) un moyen pour permettre une monétisation d'interrogation de graphe social, (j) un moyen pour fournir des analytiques de Web 1.0 et Web 2.0, (k) une interface de programmation d'application (API) JavaScript côté client et (l) une pluralité d'API pour permettre un accès côté serveur aux systèmes sous-jacents de la plate-forme.
PCT/JP2009/002211 2009-05-19 2009-05-19 Plate-forme de publicité en ligne sur internet et processus s'exécutant sur ladite plate-forme WO2010134127A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2009/002211 WO2010134127A1 (fr) 2009-05-19 2009-05-19 Plate-forme de publicité en ligne sur internet et processus s'exécutant sur ladite plate-forme

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2009/002211 WO2010134127A1 (fr) 2009-05-19 2009-05-19 Plate-forme de publicité en ligne sur internet et processus s'exécutant sur ladite plate-forme

Publications (1)

Publication Number Publication Date
WO2010134127A1 true WO2010134127A1 (fr) 2010-11-25

Family

ID=43125828

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2009/002211 WO2010134127A1 (fr) 2009-05-19 2009-05-19 Plate-forme de publicité en ligne sur internet et processus s'exécutant sur ladite plate-forme

Country Status (1)

Country Link
WO (1) WO2010134127A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102708208A (zh) * 2012-05-24 2012-10-03 北京我知科技有限公司 一种收藏微博的方法和微博收藏服务系统
CN102737305A (zh) * 2011-04-06 2012-10-17 朱海彬 一种网络购物付费新方法
WO2017184977A1 (fr) * 2016-04-22 2017-10-26 Butler Solutions, Llc Systèmes et procédés de communication multimodale
CN109863718A (zh) * 2016-08-24 2019-06-07 西门子股份公司 对设备的安全配置

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000008802A2 (fr) * 1998-08-03 2000-02-17 Doubleclick Inc. Reseau de distribution d'annonce publicitaire reciblee
US20020188563A1 (en) * 2001-06-12 2002-12-12 International Business Machines Corporation Personal data recording device, personal data transaction method, personal data transaction system, and program thereof
JP2007018200A (ja) * 2005-07-07 2007-01-25 Flatz:Kk アフィリエイトシステム
US20080097994A1 (en) * 2006-10-23 2008-04-24 Hitachi, Ltd. Method of extracting community and system for the same
JP2008305258A (ja) * 2007-06-08 2008-12-18 Nec Mobiling Ltd ユーザの評価方法、ユーザ評価システム及びプログラム
JP2008304964A (ja) * 2007-06-05 2008-12-18 Hitachi Ltd 広告仲介サーバ、動線情報仲介サーバ及び電子マネー等付与サーバ
JP2009098964A (ja) * 2007-10-17 2009-05-07 Oki Telecommunication Systems Co Ltd ネットワークサービスシステム、サーバ、方法及びプログラム

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000008802A2 (fr) * 1998-08-03 2000-02-17 Doubleclick Inc. Reseau de distribution d'annonce publicitaire reciblee
US20020188563A1 (en) * 2001-06-12 2002-12-12 International Business Machines Corporation Personal data recording device, personal data transaction method, personal data transaction system, and program thereof
JP2007018200A (ja) * 2005-07-07 2007-01-25 Flatz:Kk アフィリエイトシステム
US20080097994A1 (en) * 2006-10-23 2008-04-24 Hitachi, Ltd. Method of extracting community and system for the same
JP2008304964A (ja) * 2007-06-05 2008-12-18 Hitachi Ltd 広告仲介サーバ、動線情報仲介サーバ及び電子マネー等付与サーバ
JP2008305258A (ja) * 2007-06-08 2008-12-18 Nec Mobiling Ltd ユーザの評価方法、ユーザ評価システム及びプログラム
JP2009098964A (ja) * 2007-10-17 2009-05-07 Oki Telecommunication Systems Co Ltd ネットワークサービスシステム、サーバ、方法及びプログラム

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
KEIICHIRO NAGANO: "Google Social Graph API Katsuyoh-Kohza", SOFTWARE DESIGN, no. 214, 18 August 2008 (2008-08-18), pages 116 - 127 *
YOICHIRO TANAKA ET AL.: "Facebook vs. Open Social", WEB+DB PRESS, vol. 44, 25 May 2008 (2008-05-25), pages 116 - 125 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102737305A (zh) * 2011-04-06 2012-10-17 朱海彬 一种网络购物付费新方法
CN102708208A (zh) * 2012-05-24 2012-10-03 北京我知科技有限公司 一种收藏微博的方法和微博收藏服务系统
WO2017184977A1 (fr) * 2016-04-22 2017-10-26 Butler Solutions, Llc Systèmes et procédés de communication multimodale
CN109863718A (zh) * 2016-08-24 2019-06-07 西门子股份公司 对设备的安全配置
CN109863718B (zh) * 2016-08-24 2023-05-26 西门子股份公司 对设备的安全配置

Similar Documents

Publication Publication Date Title
US20210004853A1 (en) Social-referral network methods and apparatus
US11783357B2 (en) Syndicated sharing of promotional information
US20190130457A1 (en) Methods and systems for modeling campaign goal adjustment
JP6170463B2 (ja) ソーシャルネットワークにおける広告のターゲット設定
US9787760B2 (en) Platform for building virtual entities using equity systems
US10110413B2 (en) Communicating information in a social network system about activities from another domain
JP5186569B2 (ja) ソーシャルネットワーキングウェブサイト上の社交的広告および他の情報メッセージ、ならびにその広告モデル
US20120215607A1 (en) Systems and methods for allocating a common resource based on individual user preferences
US20100106598A1 (en) System and Methods for Merging or Injecting Targeting Marketing Offers with a Transaction Display of an Online Portal
US20130339109A1 (en) System and method for providing celebrity endorsed content
JP5498899B2 (ja) 電子ネットワークの消費者集約手続をサポートするためのシステム及び方法
CN112633914A (zh) 向广告主建议用于在线内容项的创意类型的系统和方法
JP2016531347A (ja) モバイル広告
JP2011504260A (ja) ソーシャルネットワーキングウェブサイトにおいて別のドメインでの行動についての情報を通信すること
US20110270670A1 (en) Method and system for facilitating online advertising
WO2010134127A1 (fr) Plate-forme de publicité en ligne sur internet et processus s'exécutant sur ladite plate-forme
US20140032275A1 (en) System and method for improved app distribution
US20210097574A1 (en) Delivering advertisements to mobile applications
JP7144395B2 (ja) 情報処理装置、情報処理方法および情報処理プログラム
US20210182917A1 (en) Method and apparatus for managing broker curated deals in electronic advertising
WO2015048128A1 (fr) Système et procédé de distribution améliorée d'applications

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09844862

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 11-05-12)

122 Ep: pct application non-entry in european phase

Ref document number: 09844862

Country of ref document: EP

Kind code of ref document: A1