Bump button
A fixed bump button may: (1) report its identification to a server connected to the internet when the button is bumped by a mobile device; and/or (2) emit a beacon signal identifying the button to a mobile device.
Latest Google Patents:
- Deep reinforcement learning for robotic manipulation
- Energy reduction in always-on intelligent sensing for wearable devices
- Adaptive active noise control system with hearing assistance mechanism
- Camera assembly with concave-shaped front face
- Systems and methods to evaluate client device trust in a distributed computing system
This application is a division of U.S. patent application Ser. No. 12/859,695, “Bump button”, filed on Aug. 19, 2010 which is a continuation-in-part of U.S. patent application Ser. No. 12/699,692, “Bump validation”, filed on Feb. 3, 2010 and incorporated herein by reference.
TECHNICAL FIELDThe disclosure is generally related to the field of information exchange between fixed and mobile electronic devices.
BACKGROUNDRecently a simple and quick way to exchange information between mobile electronic devices was developed. When people meet, they can bump their smart phones together to rapidly exchange business cards, music playlists, digital photos, money, or other information. The act of bumping tells a device to start information transfer.
Bumps between mobile devices occur when two devices at the same place at the same time indicate their intention to establish a connection for transferring information. Principles for determining when two devices are at “the same place at the same time” are described in U.S. patent application Ser. No. 12/699,692, “Bump validation”, filed on 3 Feb. 2010 and incorporated herein by reference.
Bumps may also occur between mobile and fixed devices. If one of the participants in a bump is fixed at a known place, the problem of determining bump location for the fixed device is solved in advance. What are needed, therefore, are fixed bump terminals.
Bumps between electronic devices occur when two devices at the same place at the same time indicate their intention to establish a connection for transferring information. When a mobile device bumps another device that is fixed at a known place, the problem of determining the location of the fixed device is solved in advance.
In
When a mobile device bumps a fixed bump button, a server receives information from both the mobile device and the fixed button. A few examples serve to illustrate how bump information may be used. In a first example, a bump button is located at the cash register of a retail shop such as a coffee shop, clothing store, supermarket, etc. A customer pays for a purchase by bumping his mobile device (e.g. smart phone, personal digital assistant, etc.) against the bump button. When the bump occurs, the mobile device sends position and time estimates, and a bump request to a server, and the fixed button sends its identification to the server. The server sends a message to the mobile device prompting the customer to enter an amount of money to be sent to the retail shop. Thus, the bump button helps the server match the customer and the retail shop and initiate an electronic payment.
In another example, a bump button is located at an information kiosk in a train station. A traveler bumps the button with his mobile device. When the bump occurs, the mobile device sends position and time estimates, and a bump request to a server, and the fixed button sends its identification to the server. The server sends a message to the mobile device that directs the device to display travel information to the traveler. The message might be the uniform resource locator for a train timetable web page, for example. Thus, the bump button helps the server match the traveler with information relevant to the traveler's current position.
In another example, a bump button is located at a fan club booth at a musical concert. When a music fan attending the concert bumps the button with her smart phone or other mobile device, the device sends position and time estimates, and a bump request to a server, and the fixed button sends its identification to the server. The server sends the fan's email address to a band playing in the concert or registers the fan as a “friend” of the band in a social network, as examples. Thus, the bump button helps the server match the fan with the band.
In another example, a person using a computer needs to enter identifying information (e.g. user name, password, personal identification number, encryption key, etc.) to access a web site or other online resource. The web site displays a message: “bump now”. The person bumps his mobile device against any of the keys on the computer's keyboard. The device sends position and time estimates, and a bump request to a server. The web site also reports the bump to the server. The server may then send identifying information to the web site on behalf of the person using the computer thus saving him from a tedious login process.
In another example, a sports fan is using a touch screen input device at stadium to buy beer from a vending machine. The fan bumps his mobile devices against the touch screen to initiate payment (as described above) and also to send an encrypted identification key that identifies him as someone old enough to buy beer. The bump button helps the server match the fan with the beer vendor and allows the vendor to offer additional services to the fan.
Many alternatives devices to the buttons depicted in
In dense user environments a bump button may emit a short-range beacon signal to help a mobile device improve its position estimate. For example, a bump button may emit a coded audio signal. A mobile device may use its microphone to record part of the audio signal. The audio recording may then be interpreted by the mobile device or sent to a server for further processing. A bump button may instead (or also) emit a radio or optical signal as a beacon. Further the beacon may be continuous or may be turned on briefly when a bump occurs. In either case, receipt of a beacon signal by a mobile device during a bump provides another way to validate the bump in the presence of multiple nearby mobile devices.
A bump button may be implemented in many different forms as described above. In one configuration, each of these share basic components as outlined in
In a basic form, a bump button has only one capability: when its sensor is triggered, it sends a message stored in memory to a server via the internet. The memory may be read-only memory as the message need only identify the bump button. The button's fixed location is already known to the server. Thus, a button's processor does not perform any general purpose computer function other than sending the message stored in the read-only memory
If a button also contains a clock, then the server may determine the button's clock offset as described in U.S. patent application Ser. No. 12/699,692, “Bump validation”, filed on 3 Feb. 2010 and incorporated herein by reference. However, time reporting ability is not required in basic bump button implementations. A bump button's optional beacon may emit audio, radio and/or optical signals. The signals may be continuous tones or may contain coded information. Finally, the beacon signals may be emitted continuously or briefly (e.g. a few seconds) when a bump occurs.
In another configuration, a fixed bump button does not include a system for communicating with the internet.
If a bump button constructed according to
A bump button that has no internet communication ability still adds information when a mobile device bumps it. When a mobile device bumps a beacon-only button, the mobile device reports the beacon signal, and thus the button's identity, to a server. The button's fixed location is already known to the server, so the location of the mobile device is known with improved accuracy compared to a case where no button is present.
Fixed bump buttons as described herein facilitate matching mobile device users with specific locations such as retail shops, information kiosks or vending machines. When mobile and fixed devices are matched in a bump, information transfers between the mobile device and a server can carry money, identification or other information. Fixed bump buttons in different forms may include internet connection ability and/or emit beacon signals.
The above description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the disclosure. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the principles defined herein may be applied to other embodiments without departing from the scope of the disclosure. Thus, the disclosure is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims
1. A fixed device comprising:
- an input sensor button configured to receive, from a nearby mobile device, an indication of an intention of the nearby mobile device to establish a connection to transfer information;
- a beacon that, when triggered by the input sensor button, sends a short-range signal to the nearby mobile device, the short-range signal comprising a MAC address and identifying the fixed device,
- wherein the fixed device is incapable of communication via the internet.
2. The device of claim 1 wherein the short-range signal is a coded audio signal.
3. The device of claim 1 wherein the short-range signal is a radio signal.
4. The device of claim 1 wherein the short-range signal is an optical signal.
6366202 | April 2, 2002 | Rosenthal |
6573833 | June 3, 2003 | Rosenthal |
6807564 | October 19, 2004 | Zellner |
6961555 | November 1, 2005 | Philyaw |
6970183 | November 29, 2005 | Monroe |
7191247 | March 13, 2007 | Philyaw |
7427926 | September 23, 2008 | Sinclair |
7542770 | June 2, 2009 | Zegelin |
7719422 | May 18, 2010 | Steinmetz |
7769927 | August 3, 2010 | Dubs |
8391786 | March 5, 2013 | Hodges |
8970480 | March 3, 2015 | Herrod |
9008616 | April 14, 2015 | Wall |
20020155844 | October 24, 2002 | Rankin |
20030167207 | September 4, 2003 | Berardi |
20030171984 | September 11, 2003 | Wodka |
20040088345 | May 6, 2004 | Zellner |
20040150521 | August 5, 2004 | Stilp |
20040192383 | September 30, 2004 | Zacks |
20040203381 | October 14, 2004 | Cahn |
20040203638 | October 14, 2004 | Chan et al. |
20040264404 | December 30, 2004 | Zegelin |
20050140507 | June 30, 2005 | Nam et al. |
20050153707 | July 14, 2005 | Ledyard |
20060125693 | June 15, 2006 | Recker |
20060258289 | November 16, 2006 | Dua |
20060267731 | November 30, 2006 | Chen |
20060290496 | December 28, 2006 | Peeters |
20070136102 | June 14, 2007 | Rodgers |
20070188323 | August 16, 2007 | Sinclair et al. |
20070222618 | September 27, 2007 | Randall et al. |
20080041936 | February 21, 2008 | Vawter |
20080201212 | August 21, 2008 | Hammad et al. |
20090024770 | January 22, 2009 | Dubs et al. |
20090043658 | February 12, 2009 | Webb |
20090068982 | March 12, 2009 | Chen |
20090112630 | April 30, 2009 | Collins, Jr. |
20090153342 | June 18, 2009 | Thorn |
20090192935 | July 30, 2009 | Griffin |
20090201122 | August 13, 2009 | Stobbe |
20090253476 | October 8, 2009 | Pestotnik |
20100023449 | January 28, 2010 | Skowronek |
20100040029 | February 18, 2010 | Doppler |
20100042493 | February 18, 2010 | Nino et al. |
20100075758 | March 25, 2010 | Balosetti |
20100082491 | April 1, 2010 | Rosenblatt |
20100109914 | May 6, 2010 | Tieman et al. |
20100125492 | May 20, 2010 | Lin |
20100174599 | July 8, 2010 | Rosenblatt |
20100257033 | October 7, 2010 | Roberts |
20100295943 | November 25, 2010 | Cha et al. |
20100311385 | December 9, 2010 | Hurwitz |
20110074582 | March 31, 2011 | Alexis |
20110076941 | March 31, 2011 | Taveau |
20110076942 | March 31, 2011 | Taveau |
20110126009 | May 26, 2011 | Camp, Jr. |
20110136468 | June 9, 2011 | McNamara et al. |
20110164509 | July 7, 2011 | Wengrovitz |
20110191438 | August 4, 2011 | Huibers |
20120027196 | February 2, 2012 | Martin |
20130100942 | April 25, 2013 | Rudnick |
- Smart Card Alliance, “Proximity Mobile Payments: Leveraging NFC and the Contactless Financial Payments Infrastructure,” Sep. 2007, Princeton Junction, NJ.
Type: Grant
Filed: Mar 21, 2013
Date of Patent: Feb 23, 2016
Patent Publication Number: 20130217335
Assignee: Google Inc. (Mountain View, CA)
Inventors: Andrew G. Huibers (Los Altos, CA), David F. Lieb (San Francisco, CA), Jacob Mintz (San Francisco, CA)
Primary Examiner: April G Gonzales
Application Number: 13/848,576
International Classification: H04B 7/00 (20060101); H04B 7/26 (20060101); G06Q 20/32 (20120101); G06F 15/16 (20060101); H04B 5/00 (20060101); H04M 1/2745 (20060101); H04M 1/725 (20060101);