Jump to Content
Daniel V. Klein

Daniel V. Klein

Daniel Klein is a Software and Site Reliability Engineer in Google's Pittsburgh office, where he alternately breaks things or fixes them for a living. His non-Google persona is also quite interesting.
Authored Publications
Google Publications
Other Publications
Sort By
  • Title
  • Title, desc
  • Year
  • Year, desc
    Virtual Door Knock
    Dean Jackson
    Defensive Publications Series, Technical Disclosure Commons (2015)
    Preview
    Event Relevant Reminders
    Dean Jackson
    Defensive Publications Series, Technical Disclosure Commons (2015)
    Preview
    Modified Alerts for Off Hour Calendar Events
    Dean Jackson
    Defensive Publications Series, Technical Disclosure Commons (2015)
    Preview abstract A modified alert triggering system modifies alerts associated with calendar events. The system identifies a user’s normal calendar hours. Further, the system determines that a calendar event is scheduled outside of user’s normal calendar hours. Based on determining that the calendar event is scheduled outside of user’s normal calendar hours, the system modifies an alert for the calendar event. For example, the modified alert can be louder than a normal alert, the modified alert can be a different alert tone than the normal alert tone, etc. The system then triggers the modified alert for the calendar event. View details
    Associating Locations with Healthcare Events
    Dean Jackson
    Defensive Publications Series, Technical Disclosure Commons (2015)
    Preview abstract The disclosed subject matter relates to computer implemented methods for associating locations with healthcare events. In one aspect, a method includes receiving location data from a location-aware client device. The location data includes latitude and longitude information. The method further includes determining, based on the received location data, a routine travel pattern of a user associated with the location-aware client device. The method further includes detecting an anomaly in the routine travel pattern. The method further includes detecting a healthcare event. The healthcare event can be a visit to a healthcare facility and/or a healthcare transaction. The method further includes correlating the anomaly in the routine travel pattern of the user with the healthcare event. The method further includes associating one or more healthcare event locations to the healthcare event based on the correlation. View details
    Filtering Media Posts
    Dean Jackson
    Defensive Publications Series, Technical Disclosure Commons (2015)
    Preview abstract A social media filtering system filters social media posts based on criteria specified by a user. The system receives a request from a user to hide social media posts associated with a specified criteria. The specified criteria can be location criteria, event criteria, person criteria, and/or time criteria. Further, the system identifies a set of social media posts on a social media website. Then, the system determines social media posts from the set of social media posts that meet the specified criteria. The system further modifies the set of social media posts by removing or otherwise hiding the social media posts that meet the specified criteria. The system presents the modified set of social media posts to the user. View details
    Temporal/Spatial Calendar Events and Triggers
    Dean Jackson
    Defensive Publications Series, Technical Disclosure Commons (2015)
    Preview abstract Spatial and/or temporal triggers may be established so that when actuated, one or more notifications such as reminders may be provided to one or more users. These triggers may be established manually, e.g., by a user operating a user interface, automatically, e.g., by scraping calendar and/or email data to ascertain and/or predict various aspects of upcoming appointments such as start times, duration, date, location, and so forth, or a combination of the two. Spatial triggers may be actuated based on a determination that a user is, or will be, at a particular location. Temporal triggers may be actuated at particular points in time, e.g., at the scheduled time of an event or at some predetermined time interval before or after the event. Using one or more triggers, it is possible to provide notifications to a user at some predetermined time interval prior to a scheduled event, so that the user has sufficient time to make appropriate arrangements, such as buying tickets, making a reservation, scheduling a rendezvous with a friend, and so forth. A calendar system may also be interfaced with to manually or automatically establish triggers. View details
    Preview abstract Updating production software is a process that may require dozens, if not hundreds, of steps. These include creating and testing the new code, building new binaries and packages, associating the packages with a versioned release, updating the jobs in production datacenters, possibly modifying database schemata, and testing and verifying the results. There are boxes to check and approvals to seek, and the more automated the process, the easier it becomes. When releases can be made faster, it is possible to release more often, and organizationally, one becomes less afraid to “release early, release often”. This is the fundamental driving force behind the work described in this paper – making rollouts as easy and as automated as possible, so that when a “green” condition (defined below) is detected, we can more quickly perform a new rollout. Humans may still be needed somewhere in the loop, but we strive to reduce the purely mechanical toil they need to perform. This paper describes how we, as Site Reliability Engineers working on several different Ads and Commerce services at Google, do this, and shares information on how to enable other organizations to do the same. We define Push On Green and describe the development and deployment of best practices that serve as a foundation for this kind of undertaking. Using a “sample service” at Google as an example, we look at the historical development of the mechanization of the rollout process, and discuss the steps taken to further automate it. We then examine the steps remaining, both near and long-term, as we continue to gain experience and advance the process towards full automation. We conclude with a set of concrete recommendations for other groups wishing to implement a Push On Green system that keeps production systems not only up-and-running, but also updated with as little engineer-involvement and user-visible downtime as possible. View details
    Context Sensitive Paste
    Dean Jackson
    Prior Art Database, IP.COM LLC (2014)
    Preview abstract A paste system can be used to generate hypertext based on determining context of a paste command. The paste system receives a selection of certain text in a document. The paste system then receives a paste command from a user of the paste system. The paste command can include data temporarily stored in memory, e.g., stored in a clipboard. The data can be stored as a result of a past copy command from the user. For example, the data can be a URL of a website. The paste system analyzes the data and determines if the data includes a URL. The system does this by, e.g., recognizing if the data includes “http” and/or “www”. If the system recognizes the data as URL, then the system generates hypertext from a combination of the selection of the text and the data. The user can then click on the generated hypertext and the hypertext system will automatically direct the user to the website identified by the URL. View details
    Crowd-Sourced Call Identification and Suppression
    Dean K. Jackson
    Federal Trade Commission Robocall Challenge (2013)
    Preview abstract We recommend the creation of a system that allows users to report, to an online database system, the originating telephone number of unwanted solicitations, advertisements or robotically placed calls (henceforth called 'spammers'). We also recommend that users' telephones or external hardware may automatically query the database about the telephone number of an incoming call (before the call is answered, or even before the telephone rings) to determine if the caller has been flagged as a spammer by other users, and optionally block the call or otherwise handle it differently from a non-spam call. The recommended system thereby would provide a means whereby users can make reports of spam calls as well as ask if others have reported a caller as a spammer. While the first few people called would get spammed, after a sufficient number of reports are made, further calls would be blocked. The recommended system would work on most types of telephonic platforms - smartphones, some feature phones, POTS lines, VoIP, PBX, and telephony providers - through the use of software and optional inline hardware. In addition to crowd-sourced blacklisting, we also recommend a means to whitelist specific numbers so that, for example, emergency calls will always go through. View details
    Image Processing and Searching
    Dean Jackson
    Defensive Publication Series, Technical Disclosure Commons (2015)
    Carnegie Mellon's CyDAT: Harnessing a Wide Array of Telemetry Data to Enhance Distributed System Diagnostics
    Chas DiFatta
    Mark Poepping
    WASL (2008)
    Perfect Data in an Imperfect World
    USENIX Annual Technical Conference (2007)
    A Forensic Analysis of a Distributed Two-Stage Web-Based Spam Attack (Awarded Honorable Mention!)
    LISA (2006), pp. 31-40
    Flying Linux
    LISA (2004)
    The Constitutional & Financial Argument Against Spam
    LISA (2002)
    Perl/Scripting Gurus
    Mark-Jason Dominus
    LISA (2002)
    150/5,000 Years of (E-)Commerce: History Repeats Itself Again
    LISA (2001)
    Defending Against the Wily Surfer-Web-based Attacks and Defenses
    Workshop on Intrusion Detection and Network Monitoring (1999), pp. 81-92
    Improving system security via proactive password checking
    Matt Bishop
    Computers & Security, vol. 14 (1995), pp. 233-249
    Abstractions for Software Architecture and Tools to Support Them
    Mary Shaw
    Robert DeLine
    Theodore L. Ross
    David M. Young
    Gregory Zelesnik
    IEEE Trans. Software Eng., vol. 21 (1995), pp. 314-335