Abstract:
A computer-implementable method includes providing a web-based primary graphical user interface (GUI) within which a user can post a job listing, the primary GUI operable to include multiple web-based secondary GUIs associated with respective job-listing posting services.

Description:
PRIORITY CLAIM  
       [0001]     The present application claims priority from U.S. Provisional Application No. 60/820,583 filed Jul. 27, 2006, which is herein incorporated by reference as if fully set forth herein. 
     
    
     FIELD OF THE INVENTION  
       [0002]     Embodiments of the invention relate generally to computer services and, more particularly, to web-based job and other classified ad posting services.  
       BACKGROUND OF THE INVENTION  
       [0003]     In computerized job-posting endeavors, an entity wishing to list a job on multiple services must inconveniently visit and use a respective different website for each such service.  
       SUMMARY OF THE INVENTION  
       [0004]     In an embodiment of the invention, a computer-implementable method includes providing a web-based primary graphical user interface (GUI) within which a user can post a job listing, the primary GUI operable to include multiple web-based secondary GUIs associated with respective job-listing posting services.  
     
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT  
       [0005]     Jobster&#39;s time saving Direct Post enables you to post your jobs to, for example, Craigslist*, GoogleBase, and/or America&#39;s Job Bank in one easy step. Using this single-click feature, you can now manage multiple site postings and/or responses from within the Jobster service.  
         [0006]     Publish your hiring needs instantly to multiple sites  
         [0007]     Save time. As shown in  FIG. 1 , there&#39;s no need to set up and manage multiple posting accounts.  
         [0008]     Manage incoming responses in a single place  
         [0009]     As shown in  FIG. 2 , Jobster captures inquiries and delivers them to your prospect management list.  
         [0010]     Measure your results in real-time  
         [0011]     As shown in  FIG. 3 , report on the source effectiveness of your postings, and see how each channel compares. Give your team visibility to make better recruiting decisions.  
         [0012]      FIG. 4  illustrates and architecture Overview of DirectPost and Targeting  
         [0013]     What is Targeting? 
         [0014]     For GB customers, offer short-term results from Jobster 
        Advertise jobs to active and/or passive jobseekers     Target ads to specific audiences to result in high ROI even without referrals     Jobster&#39;s advantages are:     Recruiter audience generates fresh, high quality jobs for placement     Specialization in job postings: Simplify &amp; automate online advertising; normalize pricing models        
 
         [0020]     Support of full Jobster product is available to recruiters and/or jobseekers  
         [0021]     Targeting Project Phases 
        Phase  1 : Automated Job Distribution (R 11 )        
 
         [0023]     Distribute to free job boards for active job seekers  
         [0024]     Build foundation infrastructure &amp; app integration  
         [0025]     Craigslist free cities, Google Base, America&#39;s Job Bank, sponsored jobs on Jobster  
         [0026]     No transactional charges  
         [0027]     Simplified UI for GB customers 
        Phase  2 : Targeted Ads (R 12 )        
 
         [0029]     Active and/or Passive jobseekers with targeted placement  
         [0030]     Paid venues: Paid CL, Google AdWords, AdBrite, Federated Media, Facebook  
         [0031]     Feedback mechanism for what ads &amp; targeting is effective 
        Phase  3 : Targeting Distribution Networks (R 13 ++)        
 
         [0033]     Refinement of pricing model  
         [0034]     Targeting Terminology  
         [0035]     Destination: place to post targeted ads  
         [0036]     Examples: Craigslist, Google Base  
         [0037]     Distribution: targeted posting, mapping job opportunity to a destination  
         [0038]     A new type of channel  
         [0039]     Example: single job posting on Craigslist  
         [0040]     Spackler: plug-in module that does the work of creating distributions on destinations.  
         [0041]     Plaster &amp; Drywall: Frameworks that contain spacklers  
         [0042]     R 11  Scenarios 
        P 1 : New GB account        
 
         [0044]     Jobster needs to offer short term value to the GB customer by generating prospects quickly and without significant up-front time investment. 
        Login to account. Simplified UI leads directly to job−&gt;post workflow     Create a job     Post job     Prospects arrive from posting, Recruiter manages prospects     P 1 : Existing SA customer        
 
         [0050]     Targeting is new way to source, relieves complexity and tedium of manually posting jobs 
        Login, notice new capability for targeting     Jobs can be managed and/or filtered based on posting status     Use sources page to determine effectiveness of different channels     P 2 : Manage targeting        
 
         [0055]     Job is posted, but may need finer grained control over posting 
        Post a job with targeting     Receive a flood of low-quality resumes from Craigslist posting as compared to Google Base. Recruiter edits options for job and takes down Craigslist posting.        
 
         [0058]     R 11  Job Distribution Features 
        Lobster app integration        
 
         [0060]     Targeting action on jobs  
         [0061]     Customize targeting  
         [0062]     Filter by targeting in job list  
         [0063]     Sources page integration &amp; reports 
        Simplified landing pages—integrate with referral wizard work     Tracking of unique information for Distributions     Impression tracking     Spacklers:        
 
         [0068]     Craigslist, Google Base, AJB 
        Simplified overall UI for GB customers        
 
         [0070]     Architectural Guiding Principles 
        Extensible framework for new Destinations        
 
         [0072]     Backend: Common framework for scheduling &amp; management  
         [0073]     Frontend: Dynamically compose the UI list of Destinations &amp; Destination-specific preview &amp; options UI 
        New Destination Deployment: Use code &amp; full build        
 
         [0075]     New Destinations can arrive maximum 1-2 per month  
         [0076]     Adding Destination entirely through configuration may not be feasible due to heterogeneity of Destinations 
        Spackler Updating        
 
         [0078]     Some Spacklers can be fragile due to forms &amp; email scraping, e.g. Craigslist  
         [0079]     May need support for rev&#39;ing to work around minor breaks  
         [0080]     Separate Spacklers from full lobster application to support separate deployment  
         [0081]     Spackler Functionality 
        Frontend        
 
         [0083]     Validation, e.g. known editorial guidelines, free vs. paid cities  
         [0084]     UI rendering for preview  
         [0085]     UI representation of options that the recruiter can specify 
        Backend        
 
         [0087]     Formatting Opportunities into whatever format and/or schema a Destination may require  
         [0088]     Namespace translation, e.g. available cities, job categories  
         [0089]     Posting protocol, e.g. custom web service APIs, scheduled FTP file uploads, web form scraping and/or automation, email scraping  
         [0090]     Maintenance of postings: updates, deletes  
         [0091]     Reporting of failures  
         [0092]     Flag needed spackler updates  
         [0093]     Plaster &amp; Drywall 
        Plaster—frontend framework        
 
         [0095]     Scale like Lobster: Deployed as separate process on lobster front-end machines  
         [0096]     Communicate through db, server side includes, and possibly web service interface 
        Drywall        
 
         [0098]     Support scale-out—its own cloud of machines  
         [0099]     Use ‘greedy’ scheduling model 
        Drywall pool machine polls for available Distribution or email to process     Grabs &amp; marks distribution as being processed        
 
         [0102]     Quartz scheduling framework used when needed by a particular spackler, e.g. Google Base  
         [0103]     Database Extensions 
        Distributions table: extends channel        
 
         [0105]     distribution_id  
         [0106]     who created  
         [0107]     when created  
         [0108]     opportunity_id  
         [0109]     impressions  
         [0110]     distribution type−&gt;what type of spackler  
         [0111]     distribution_config−&gt;blob  
         [0112]     status−&gt;used by Drywall to handle scheduling 
        Distribution_config: spackler-specific prop bag, provide resistance to db schema changes for minor spackler rev     Status: Pending|Spackling|Finished, etc     Impressions may be tracked in aggregated form     Spackler-specific tables may be added on spackler-by-spackler basis        
 
         [0117]     Craiglist Spackler Process Details 
        Select correct city URL     Automate 6 webforms to post     Wait for confirmation email to unique email address     Scrape CL&#39;s confirmation URL from email     Automate CL confirmation form     Return to confirmation form for deletion     We can build a “fake” CL proxy for testing        
 
         [0125]     Google Base Spackler Details 
        Google Base has manual posting or bulk upload     Bulk upload     Annotated RSS 1.0, 2.0 or Atom file     Custom field values for Google Base categories     Uploaded through FTP     Google blocks uploads more or less than once every few hours        
 
         [0132]     Targeting Plug-in Architecture for Spacklers  
         [0133]     Overview  
         [0134]     In the targeting framework, Spacklers can be distributed and/or installed using a plug-in mechanism. This document describes thoughts around how these plug-ins can work, including run-time discovery, versioning, packaging, and the interfaces that can be exposed.  
         [0135]     Related Links  
         [0136]     Several existing Java plugin mechanisms were investigated as part of this process. Below are links to some of these efforts. 
        Eclipse Plug-in Architecture     Java Module System     Replaceable Components and the Service Provider Interface     JAR Service Provider Mechanism     ServiceRegistry (javadoc)        
 
         [0142]     Options  
         [0143]     The R 13  launch of the targeting framework established following options for Spackler plugins: 
        The plugin may be deployable as a JAR     The Spackler implementation(s) provided by this plugin may be discoverable at runtime by targeting host environment without additional configuration     The plugin may provide versioning and/or vendor information to the host environment     The plugin may expose a factory for creating Spackler instances that extend the Spackler base class        
 
         [0148]     Additionally, while plugins may eventually be buildable and/or packaged externally from the actual lobster project itself, this wasn&#39;t a requirement of the R 13  launch.  
         [0149]     SPI and ImagelO  
         [0150]     Ultimately, the plugin mechanism provided by Java&#39;s own JAR Service Provider mechanism (SPI) was deemed optionally advantageous as a basis for Spackler plugins. Service provider classes may be detected at run time by means of meta-information in the JAR files containing them. It had the added optional advantage of being readily available (it ships standard with J2SE) and sufficiently documented. Finally, J2SE provides the ImageIO registry , an easily emulated, full fledged example of this plugin mechanism in action. As such, the targeting plugin framework for Spacklers follows the ImageIO SPI model closely.  
         [0151]     While the targeting framework may not use the IIORegistry directly, it may use the ServiceRegistry class as a base class for its own TargetingRegistry. While ServiceRegistry is part of the javax.imageio package, it is applicable as a generic registry for service provider instances.  
         [0152]     SpacklerSpi  
         [0153]     In the SPI model, service provider classes are intended to be lightweight and quick to load. Implementations of these interfaces may avoid complex dependencies on other classes and/or on native code. Among their functions is to serve as a factory for the more heavyweight service instances.  
         [0154]     SpacklerSpi is the service provider interface for Spacklers. The SpacklerSpi instance for a plugin provides additional information, such as the spackler name, version, and/or vendor data. But among its functions is to contruct Spackler instances as necessary, via its createSpacklerInstance method. The SpacklerSpi is solely responsible for creating and/or initializing Spackler instances, but the Spackler&#39;s lifecycle is managed by the calling code.  
         [0155]     The SpacklerSpi instances themselves are not created in a vaccuum. When used by the Jobster Employer Application, they may be managed by the RegisterSpacklerManager class, which can initialize newly-created SpacklerSpi instances using the Spring application context .  
         [0156]     XmlApplicationContextSpacklerSpi  
         [0157]     For Spacklers that may have greater creation and/or initialization requirements, the XmlApplicationContextSpacklerSpi provides more advanced spackler creation functionality. Subclasses of this SPI can define their own Spring application context using Spring 2.0&#39;s XML syntax. This context can be made a child context of the client&#39;s own application context, making all Spring-managed application services (such as the data source, transaction manager, and/or scheduler) available to this spackler&#39;s context. By default, this SPI can define its context using the file “spackler.xml”. When requested, this SPI can create Spackler instances by retrieving the bean named “spackler” from its application context.  
         [0158]      FIGS. 5-12  illustrate DirectPost UI Screenshots and Specifications  
         [0159]     While a preferred embodiment of the invention has been illustrated and described, as noted above, many changes can be made without departing from the spirit and scope of the invention. Accordingly, the scope of the invention is not limited by the disclosure of the preferred embodiment. Instead, the invention should be determined entirely by reference to the claims that follow.