0% found this document useful (0 votes)
61 views28 pages

Us 9413715

This patent application describes a URI service system that performs the following: 1) It receives and stores different types of payloads of data. 2) It generates a unique URL associated with each stored payload. 3) It provides the unique URLs for exposure to mobile devices through machine-scannable codes like QR codes. 4) When it receives requests for the unique URLs, it processes the current request and retrieves the associated payload.

Uploaded by

Jagriti Arora
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
61 views28 pages

Us 9413715

This patent application describes a URI service system that performs the following: 1) It receives and stores different types of payloads of data. 2) It generates a unique URL associated with each stored payload. 3) It provides the unique URLs for exposure to mobile devices through machine-scannable codes like QR codes. 4) When it receives requests for the unique URLs, it processes the current request and retrieves the associated payload.

Uploaded by

Jagriti Arora
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

US0094.

13715B2

(12) United States Patent (10) Patent No.: US 9.413,715 B2


Chor (45) Date of Patent: Aug. 9, 2016

(54) URI SERVICE SYSTEMAND METHOD (58) Field of Classification Search


CPC. G06F 17/30879; G06Q30/02; H04L 67/02
(71) Applicant: YAHOO! INC., Sunnyvale, CA (US) USPC .................................. 709/225, 238 240, 245
See application file for complete search history.
72). Inventor
(72) I tor: Jesse Unor,
Chor, Bell
Sellevue, WACUS
(US) (56) References Cited
(73) Assignee: Yahoo! Inc., Sunnyvale, CA (US) U.S. PATENT DOCUMENTS
(*) Notice: Subject to any disclaimer, the term of this 7,490,134 B2 * 2/2009 Ono ................... GO6K 7/10722
patent is extended or adjusted under 35 235,437
2006/0243807 A1* 11/2006 Tien .................... GO6F 9/45512
U.S.C. 154(b) by 0 days. 235,462.15
2008/O149701 A1* 6/2008 Lane ..................... GO6F 19,323
(21) Appl. No.: 14/695,444 ag 235,375
2009, O108057 A1* 4, 2009 Mu ................... HO4M 1/72561
(22) Filed: Apr. 24, 2015 235,375
2011/0035262 A1 2/2011 Meriaz. ................... G06Q 10/10
O O TO5, 14.1
(65) Prior Publication Data 2011/0264992 A1* 10, 2011 Vishria ............. GO6F 17,30887
US 2015/0229603 A1 Aug. 13, 2015 715,208
2011/0279851 A1* 1 1/2011 Berger ................... G06Q 10/00
358,115
2011/0283196 A1* 1 1/2011 Berger .............. GO6F 17,30879
Related U.S. Application Data 715.738
2011/0289434 A1* 11/2011 Kieft................. GO6F 17,30887
(60) Continuation of application No. 13/943.311, filed on 715,760
Jul. 16, 2013, now Pat. No. 9,065,797, which is a 2012/0055984 A1* 3, 2012 Van
division of application No. 12/908.547, filed on Oct. Megchelen ....... G06F 1972
20, 2010, now Pat. No. 8,583,795, which is a
continuation-in-part of application No. 12/852,730, OTHER PUBLICATIONS
filed on Aug. 9, 2010, now Pat. No. 8,438,245. QRStuff, [Link] website by Wayback machine, Mar. 16, 2010, 2
ck
(51) Int. Cl. pageS.
G06F 15/16 (2006.01) * cited by examiner
G06F 5/73 (2006.01)
H04L 29/2 (2006.01) Primary Examiner — Hieu Hoang
G06F 7/30 (2006.01) (74) Attorney, Agent, or Firm — James J. DeCarlo:
H04L 29/08 (2006.01) Greenberg Traurig, LLP
G06K L/2 (2006.01) (57) ABSTRACT
(52) is: C. H04L 61/2007 (2013.01); G06F 17/30879 A URI-redirection via machine-scannable-code system and
(2013.01). Gook tip (2013 ontout 6702 method are provided herein.
(2013.01) 20 Claims, 15 Drawing Sheets

5 N
DETIKPLURALITY OFPAYLOAD ^505
TPES -

Banpur DEEPEs/50
CREATEDEVICEAPAAD
MAPPINGS
(SEEFIG.E)

OSTANDATAYLOAD

STOREDATAPAYLDAO

GENERATEUNIUEURLASSOCATED -.
ITH STREPLOAD × 525

PRIDEUNDUEURLFOR
EXPOSURETOMOBILEDEVICES ^
YMACHINE-SCANNABLEEDE
(SEEFIG.)

HILERECEINGREUESTSFOR
UNIQUEURL --

ROCESSCURRENTRELEST
(SEEFIG.E} --

YE /535
CREATEDEVICEAAAYLDAO
MAPPINGS -EDD
(SEEFIGS) XD

WHILE RECEIVING REQUESTS FOR


UNIQUEURL --
A-5

C mi / SSS
U.S. Patent Aug. 9, 2016 Sheet 1 of 15 US 9.413,715 B2

IIS DATABASE

MOLEDEVICE
R&

RENDERINGELENT
(TYPEA)

Fil
U.S. Patent Aug. 9, 2016 Sheet 2 of 15 US 9.413,715 B2

COMPUTER-READABLE
MEDIUM

MEMORY

OPERATING SYSTEM

REMOTEUR-SERVICE ROUTINE (SEEFIG.5)

WEB-APPLICATION INTERFACE ROUTINE(S)

DYNAMIC MACHINE-SCANNABLE-CODE GENERATION ROUTINE (SEE FIE. 14)

UR-REDIRECTION ROUTINE (SEE FIG. (5)


U.S. Patent Aug. 9, 2016 Sheet 3 of 15 US 9.413,715 B2

330
\ NETWORK
INTERFACE

F
- 340

3ID

/345

COMPUTER-READABLE
MEDIUM

MEMORY
/350

NON-WEB-BROWSERAPPLICATION

MACHINE-SCANNING ROUTINE(S)

URL-HANDLING ROUTINE(S)

NDN-URLURI HANDLING ROUTINE(S)


U.S. Patent Aug. 9, 2016 Sheet 4 of 15 US 9.413,715 B2

AO
URISERVICE
SERVER
an MOBILEDEVICE

| ENDENBELLIND
MACHINE-SCANNABECODE
ENDED UNIQUE
45°N
“ENSINE OBLIE R
EC

LERY UNIQUE URL)


DATAPAYLOAD

DETERMINEDEVICETYPE
KH
A.O. NH
GENERATEUR FORDEVICETYPE
ATAPAYLOAD
UR DATAPAYLOAD)

NYOKEAPPLICATIONTO
HANDLEDATAPAYLOAD
U.S. Patent Aug. 9, 2016 Sheet 5 Of 15 US 9.413,715 B2

SD N.
BTAN PLURALITY OF PAYLOAD /.505
TYPES ---

DETAINPLURALITY OF DEVICETYPES/ 5ID


CREATE DEVICE/PAYLOAD -
MAPPINGS / GOD
(SEE FIG.E)

ETANDATAPAYLOAD /55

STORE DATAPAYLOAD / 520

GENERATE UNIQUE URL ASSOCIATED


WITH STOREDPAYLOAD
/ 525

PROVIDENUERLFDR
EXPOSURETDMDELE DEVICES /7DO
WAMACHINE-SCANNABLE CODE | 1
(SEE FIG.7)

WHILE RECEIVINGREESTS FOR / 53D


UNEURL

PROCESSCURRENTREUEST /BOD
(SEE FIG.8)

YES Ew MOBILE DEVICETYPE s 535


CREATE DEVICE/PAYLOAD S.
MAPPINGS N
(SEE FIG.E)
WHILE RECEIWNGREESTS FOR
UNUE URL
U.S. Patent Aug. 9, 2016 Sheet 6 of 15 US 9.413,715 B2

FDREACH DATA PAYLOAD TYPE EDS

FDREACHMOBILE-DEVICETYPE BD

CREATE MOBILE-DEVICETYPE/DATA
PAYLOADTYPE MAPPING BS

FDREACHMOBILE-DEVICETYPE 620

FDREACH DATA PAYLOAD TYPE 25

RETURN
U.S. Patent Aug. 9, 2016 Sheet 7 Of 15 US 9.413,715 B2

705 GENERATE MACHINE- YES


SCANNABLE CODE

ENDENERLINT MACHINE
SCANNABLE CODE

PROVIDE MACHINE-SCANNABLE CODE


FOR EXPOSURE

72D

PROVIDE UNIUE URL FOR EXPOSURE

799

272.7
U.S. Patent Aug. 9, 2016 Sheet 8 of 15 US 9.413,715 B2

820

-- GENERATE MAPEDDEVICE-TYPE
825 Yu SPECIFICURINCLUDINGDATA
AYLOAD
DELIVERGENERICURITO INVOKE
Ys. APPLICATION ON REMOTE
DELVERDEVICE-TYPE-SPECIFICUR REUESTING DEVICE
-- TOINVOKENDN-WEB-BROWSER
83D APPLICATION ON REMOTE
RELESTING DEVICE TO HANDLEDATA
PAYLOAD

Fig.8
U.S. Patent Aug. 9, 2016 Sheet 9 Of 15 US 9.413,715 B2

SID CAPTION
U.S. Patent Aug. 9, 2016 Sheet 10 of 15 US 9.413,715 B2

ELEETEVFORIES ISEP
e. ) ,
EAEK FIRWARD STOP REFRESH
4. S.
HOY E S ARCH FAVORITES
(2.
HISTORY MAI
X
Lis' gesterwisrows inst v6's
ADDRESS
OS \ 1525ATHAVE SEATTLE WASEID %
MAPREVIEW

%%

RCODEKMSTA
(MSSR"HTTP//WWMSKYNETCOM/ NILEURL
REENT-MAPDATASEATHERAVE:

G"
W
to
U.S. Patent Aug. 9, 2016 Sheet 11 of 15 US 9.413,715 B2

ELEEDTVEY FAVORITESOLS HELP

BAEK
. () , (3) E. ?. G
FDRARD STOP REFRESH HOME SEARCH FAVORITES
6%
HISTORY AL
Av 3
SIZE

Is Estells showstainst
R
" TIMEDAC-IFL

RCODE (IME}TAS
%
{MGSRC"HTTP/WMSKYNETCOM/
RGENTRACKET-REDATAHTTP3A%2F%2
FNASOEECOMEFASRFOEDITF.
8%2EHARDENSEELENTARDISB.
MAEEEDUTF8%2SEDSOEZOTHE
EAVEBNEB98ISEFERDESERDIS
%2HNEARERDSEATTLE%2CZEWAGEVIEWARD
MAEEEDRDISS357238SO9702%2SWLOC UNEURL
%3DASEVEDRDOCSKIPYESADEEE
%3DODUITKAAFAPEADHWZEEWSCO-OOOOOOG25A r
WDTH-3SIs HTTP/IMSKYISIRISW
U.S. Patent Aug. 9, 2016 Sheet 12 of 15 US 9.413,715 B2

ELEEDT VEY FAVORITES IDDS EP


(; , ) ()
BACK FORWARD STOP REFRESH
(, S. G.) (3 y y 5
HOME SEARCH ANDRITES HISTORY A. PRINT

IE * ADRESS HTTP/IWYSKYNETCOM/STATIC/MAESTRO
A.
TITLE
r
ZDS MYRIGPARTY
LOCATION
2O
EMAINST. 120 -V
: ".
ORGANIZE
123 JOHNODENAME
RCODE META
(MSSR"HTTP//WWWMSKYNETEIM
REENTYEASTITLEMY BIGPARTVSLOE-123
MANSTEMAHNAODENAMEDESETS
+AEG-PARTYESYEAR20DESMONTHESDAY.
2ESHOUSESMNSOESOFFSE- NILERL
SEYEAR20DEEMONTH/SEDAY-2SEHOUR-7GE
MINDEEDFFSET-
7EALARMSCOOOOOODEWOTHSSIs
125 \lurid
HTTP//WWWMSKYNETCOM/RISWT V
U.S. Patent Aug. 9, 2016 Sheet 13 of 15 US 9.413,715 B2

in E ". DATABASE a
O UR-SERVICE
WEEPUBLISHER SERVER RENDERINCENT MOELEDEVICE
gy, WEBPAGE REQUEST
3D
II. WEBPAGESOURCE (INCLUDING DYNAMIC 2-D EARODE IMAGETAG)
|PREVE AESOURCE
READ-DEARCODEMAEETAS

A.M. EDBOEMELETEEETIES
ENI [Link]
A ENINU
El EEAELNER
gu. NE
GREBEIA
ENCODNENUEUR
15\- 2-DEARCODENAE
RENDER WEBPAGE
SCANRENDERED WEBPAGE
E-DEARCODEMAEE
DECODEUNIQUEUR
1875 UNIQUEURREQUEST II.
A SIANIE
SA ENINI
(39. DESTINATIONURREDIRECT
: A k----------------------- EIALISEE--------L-------------
39 \l Fig.13
U.S. Patent Aug. 9, 2016 Sheet 14 of 15 US 9.413,715 B2

to-N, RECEIVEREQUEST FOR2-D BARCODE


MAGE RESOURCE
-
1405
1420
)
IEENIS 4D
ONDITIONA MULTIPLE ---
SPECIFIERS YES DESTINATIONURSIN - AS
N
ND
STRE CONDITIONAL SPECIFIERS - -1430

IMAGE
USTDMIATION ATTRIBU
1455 - ASSOCATED WITHERDU
DENTIFIER

GENERATE 2-D BARCODEMAEE


1N ENCODED WITHUNUEUR AND
4GD 1 DEPICTINE DETERMINEDIMAGE
CUSTDMIATION ATTRIBUTE

Fig. 74
U.S. Patent Aug. 9, 2016 Sheet 15 Of 15 US 9.413,715 B2

RECEIVEREQUEST FORUNIQUEUR
RESOURCE

REDIRECT REQUEST TO
RASSOCATEDWT
PROYPTRELESTORTOSELECTA CONDITIONALS
5'- "Etna
SES

REDIRECT REQUESTOSELECTED
SAD DESTINAT

S25 STORE ANAVTEDATA

Easy
Fig.15
US 9,413,715 B2
1. 2
UR SERVICE SYSTEMAND METHOD resulting action would typically be to open the URL in a
browser application on the device.
CROSS REFERENCE TO RELATED However, not all actionable text formats are so universally
APPLICATIONS recognizable, and many different mobile device manufactur
ers and/or mobile device operating system providers may
This application is a continuation of and claims priority implement proprietary standards for formatting actionable
from co-pending U.S. patent application Ser. No. 13/943.311, text in two-dimensional barcodes. For example, mobile
filed on Jul. 16, 2013, entitled “URI SERVICE SYSTEM devices provided by NTT DoCoMo, Inc. of Tokyo, Japan may
AND METHOD,” which is a divisional application of U.S. recognize URLs encoded using an alternate format, e.g.
application Ser. No. 12/908,547, filed on Oct. 20, 2010, (now 10 “MEBKM:TITLE:NTT DOCOMO:URL:httpY://int tdoco
U.S. Pat. No. 8,583,795), titled “URI SERVICE SYSTEM [Link]/f/;”. While mobile devices provided by NTT
AND METHOD, which is a continuation in part of U.S. DoCoMo may recognize such a URI, other types of mobile
application Ser. No. 12/852,730, filed on Aug. 9, 2010 (now device may not recognize Such a URI.
U.S. Pat. No. 8,438,245), titled “REMOTE APPLICATION Similarly, differing formal and/or de-facto standards may
INVOCATION SYSTEMAND METHOD, all of which are 15 be used by different types of mobile devices for interpreting
incorporated herein by reference in their entireties, for all encoded contact information, event/appointment informa
purposes. tion, and other types of information. Consequently, it may be
difficult or even impossible in some cases to provide a single
FIELD two-dimensional barcode that will cause a variety of different
types of mobile devices to perform a desired action.
The present disclosure relates to networked computing In addition, different types of mobile devices may imple
services, and more particularly to handling URIs via ment cameras or other scanning components that have differ
machine-scannable codes. ing capture capabilities. While various types of two-dimen
sional barcode may be able to encode several kilobytes (or
BACKGROUND 25 more) of information, not all mobile devices may be able to
properly recognize many densely-packed two-dimensional
The term “mobile tagging refers to the process of provid barcodes. For example, a first mobile device with an auto
ing data to mobile devices, commonly through the use of data focus macro lens may be able to capture and resolve a two
(e.g., a Uniform Resource Locator or “URL) encoded in a dimensional barcode encoded with several kilobytes of data,
two-dimensional barcode. For example, addresses and/or 30 while a second mobile device, with a fixed-focus lens, may
URLs are commonly encoded in two-dimensional barcodes only be able to resolve as little as 200 bytes of data. Conse
(e.g., QR Codes, Data Matrix codes, High Capacity Color quently, even if the first and second devices both supported
Barcodes or “HCCBs, and the like) that are printed in maga the same actionable text format, the second device may still
Zines, on signs, buses, business cards, or other object. Users be incapable of acting on an information-dense two-dimen
with a camera phone equipped with an appropriate reader 35 sional barcode due to hardware limitations of the second
application can scan the image of the two-dimensional bar device's capture components.
code to display text, contact information, connect to a wire
less network, open a webpage in the phone's browser, and/or BRIEF DESCRIPTION OF THE DRAWINGS
perform other operations. For example, the Android operat
ing system for mobile devices (provided by Google Inc. of 40 FIG. 1 illustrates an exemplary remote application invoca
Menlo Park, Calif.) supports the use of QR codes by natively tion system according to one embodiment.
including a barcode scanner application on Some device mod FIG. 2 illustrates several components of an exemplary
els and by including a browser that Supports Uniform URI-service server.
Resource Identifier (“URI) redirection, which allows QR FIG. 3 illustrates several components of an exemplary
Codes to send metadata to existing applications on the device. 45 mobile device.
The Symbian OS (provided by Nokia Corporation of Tem FIG. 4 illustrates an sequence of data communications for
pere, Finland) also includes a barcode scanner that is able to an exemplary remote-application invocation scenario, in
read QR Codes. accordance with one embodiment.
Generally speaking two-dimensional barcodes encode FIG. 5 illustrates a remote-application invocation routine
some sort of actionable text (or other data). For example, text 50 in accordance with one embodiment.
representing contact information, when recognized by a bar FIG. 6 illustrates an exemplary device/payload mapping
code scanner application, could add the contact information Subroutine, in accordance with one embodiment.
to an address book on the device. Similarly, text representing FIG. 7 illustrates an exemplary unique URL exposure sub
an event or appointment, when recognized, could add the routine, in accordance with one embodiment.
event or appointment to a calendar on the device; text repre 55 FIG. 8 illustrates an exemplary unique-URL-request pro
senting geo-location information, when recognized, could cessing Subroutine, in accordance with one embodiment.
open a map application on the device; and so on. FIG. 9 illustrates a SPARQCodeTM two-dimensional bar
However, actionable text, Such as the examples mentioned code, such as may be employed as a machine-Scannable code
above, can only be acted on when the barcode scanner appli in various embodiments in one embodiment.
cation understands the format of the actionable text encoded 60 FIG. 10 illustrates a web application, such as may be pro
in the two-dimensional barcode. Some format standards exist vided by URI-service server in one embodiment, for handling
and are commonly used for encoding actionable text in a a geo-location payload.
two-dimensional barcode. For example, perhaps the most FIG. 11 illustrates a web application, such as may be pro
common actionable text encoded in two-dimensional bar vided by URI-service server, for handling a URL payload.
codes is text that represents a URL, e.g. "[Link] 65 FIG. 12 illustrates a web application, such as may be pro
m”. This string of text would be generally recognized as a vided by URI-service server in one embodiment, for handling
URL by virtually all barcode scanner applications, and the an event or appointment payload.
US 9,413,715 B2
3 4
FIG. 13 illustrates an sequence of data communications for In various embodiments, network 150 may include the
an exemplary dynamic machine-scannable-code generation Internet, a local area network (“LAN), a wide area network
and URI-handling scenario, in accordance with one embodi (“WAN'), a cellular data network, and/or other data network.
ment. In many embodiments, there may be more mobile devices 300
FIG. 14 illustrates a dynamic machine-Scannable-code than are illustrated.
generation routine. Such as may be performed by URI-Service FIG. 2 illustrates several components of an exemplary
server in accordance with one embodiment. URI-service server 200. In some embodiments, URI-service
FIG. 15 illustrates a URI-redirection routine, such as may server 200 may include many more components than those
be performed by URI-service server in accordance with one shown in FIG. 2. However, it is not necessary that all of these
embodiment. 10 generally conventional components be shown in order to
disclose an illustrative embodiment. As shown in FIG. 2,
DESCRIPTION URI-service server 200 includes a network interface 230 for
connecting to the network 150.
The detailed description that follows is represented largely The URI-service server 200 also includes a processing unit
in terms of processes and symbolic representations of opera 15 210, a memory 250, and an optional display 240, all intercon
tions by conventional computer components, including a pro nected along with the network interface 230 via a bus 220.
The memory 250 generally comprises a random access
cessor, memory storage devices for the processor, connected memory (“RAM), a read only memory (“ROM), and a
display devices and input devices. Furthermore, these pro permanent mass storage device. Such as a disk drive. The
cesses and operations may utilize conventional computer memory 250 stores program code for a remote-application
components in a heterogeneous distributed computing envi invocation routine 500 (see FIG. 5, discussed below), one or
ronment, including remote file Servers, computer Servers and more web-application interface routines 260, a dynamic
memory storage devices. Each of these conventional distrib machine-scannable-code generation routine 1400 (see FIG.
uted computing components is accessible by the processor 14, discussed below), and a URI-redirection routine 1500 (see
via a communication network. 25 FIG. 15, discussed below). In addition, the memory 250 also
The phrases “in one embodiment,” “in various embodi stores an operating system 255. These software components
ments.” “in some embodiments.” and the like are used repeat may be loaded from a computer readable storage medium 295
edly. Such phrases do not necessarily refer to the same into memory 250 of the URI-service server 200 using a drive
embodiment. The terms “comprising.” “having and “includ mechanism (not shown) associated with a non-transient com
ing” are synonymous, unless the context dictates otherwise. 30 puter readable storage medium 295, such as a floppy disc,
Reference is now made in detail to the description of the tape, DVD/CD-ROM drive, memory card, or the like. In some
embodiments as illustrated in the drawings. While embodi embodiments, software components may also be loaded via
ments are described in connection with the drawings and the network interface 230, rather than via a computer readable
related descriptions, there is no intent to limit the scope to the storage medium 295.
embodiments disclosed herein. On the contrary, the intent is 35 In some embodiments, URI-service server 200 may further
to cover all alternatives, modifications and equivalents. In comprise a specialized interface (not shown) for communi
alternate embodiments, additional devices, or combinations cating with database 115. Such as a high speed serial bus, or
of illustrated devices, may be added to, or combined, without the like. In some embodiments, URI-service server 200 may
limiting the scope to the embodiments disclosed herein. communicate with database 115 via network interface 230. In
FIG. 1 illustrates an exemplary remote application invoca 40 other embodiments, database 115 may reside in memory 250.
tion system 100 according to one embodiment in which Although an exemplary URI-service server 200 has been
mobile devices 300A-C (see FIG. 3, discussed below), ren described that generally conforms to conventional general
dering client 120, and URI-service server 200 (see FIG. 2, purpose computing devices, an URI-service server 200 may
discussed below) are connected to a network 150. In some be any of a great number of devices capable of communicat
embodiments, rendering client 120 may be associated with 45 ing with the network 150, database 115, and/or clients 300A
and/or visible to one or more of mobile devices 300A-C. In C. for example, a personal computer, a game console, a set
some embodiments, a publisher device 110 is also connected top box, a handheld computer, a cell phone, or any other
to network 150, and URI-service server 200 is in communi suitable device.
cation with database 115 (which may also be connected to FIG. 3 illustrates several components of an exemplary
network 150 in some embodiments). In some embodiments, 50 mobile device 300. In some embodiments, mobile device 300
publisher device 110 may also be in direct communication may include many more components than those shown in
with URI-service server 200. In other embodiments, URI FIG. 3. However, it is not necessary that all of these generally
service server 200 and publisher device 110 may comprise a conventional components be shown in order to disclose an
single device. illustrative embodiment. As shown in FIG. 3, mobile device
In some embodiments, other servers and/or devices (not 55 300 includes a network interface 330 for connecting to the
shown) may also be present. For example, in some embodi network 150.
ments, one or more proxy devices, firewalls, and/or other The mobile device 300 also includes a processing unit 310,
intermediaries (not shown) may exist between URI-service a memory 350, and a display 340, all interconnected along
server 200, some or all of clients 300A-C, and/or rendering with the network interface 330 via a bus 320. The memory
client 120. 60 350 generally comprises a random access memory (“RAM),
In some embodiments, URI-service server 200 may com a read only memory (“ROM), and a permanent mass storage
municate with database 115 via network 150, a storage area device. Such as a disk drive, flash memory, or other persistent
network ("SAN), a high speed serial bus, and/or via other storage technology. The memory 350 stores program code for
Suitable communication technology. In some embodiments, a non-web-browser application 360, as well as one or more
URI-service server 200, publisher device 110, and/or data 65 routines 365, 370, 375 for respectively handling machine
base 115 may comprise one or more replicated and/or distrib Scanning operations (including scanning, decoding, and
uted physical or logical devices. interpreting machine-scannable codes), URL handling opera
US 9,413,715 B2
5 6
tions (e.g., a web browser and routines for invoking the web embodiment, the unique URL may consist of 20 (or even
browser), and non-web-browser URI handling operations fewer) characters. In many embodiments, the unique URL
(e.g., one or more non-web-browser applications and routines may consist of less than about 200 bytes of data, so that when
for invoking the non-web-browser applications). In addition, the unique URL is encoded into a machine-Scannable code
the memory 350 also stores an operating system 355. These (e.g., a two-dimensional barcode), the machine-Scannable
Software components may be loaded from a computer read code will not contain more information than can be reliably
able storage medium 395 into memory 350 of the mobile captured by mobile device types with relatively low-fidelity
device 300 using a drive mechanism (not shown) associated scanner components.
with a non-transient computer readable storage medium 395, In the illustrated embodiment, URI-service server 200
such as a floppy disc, tape, DVD/CD-ROM drive, memory 10 encodes 420 the unique URL into a machine-scannable code
card, or the like. In some embodiments, software components and sends 425 to publisher 110 the machine-scannable code
may also be loaded via the network interface 330, rather than with the encoded unique URL. For example, in one embodi
via a computer readable storage medium 395. ment, URI-service server 200 may encode the unique URL
The mobile device 300 also includes a scanner 345 capable into a two-dimensional barcode and send an image of the
of capturing information encoded in machine-Scannable 15 barcode to publisher 110. In other embodiments, URI-service
codes. For example, in some embodiments, Scanner 345 may server 200 may send the unencoded unique URL directly to
comprise a camera or other optical scanner for capturing publisher 110, in addition to or instead of the machine-scan
optically-encoded machine-scannable codes, such as bar nable code. In some embodiments, publisher 110 may per
codes, two-dimensional barcodes, and the like. In other form the encoding of the unique URL into the machine
embodiments, Scanner 345 may comprise a radio transmitter scannable code. For example, in one embodiment, publisher
and/or receiver for capturing radio-frequency identification 110 may receive the unique URL and encode it into one or
(“RFID) tags and the like. In still other embodiments, scan more RFID rags.
ner 345 may comprise Suitable components for scanning or Publisher 110 manifests 430 the machine-scannable code
reading codes encoded in other machine-Scannable media (encoded with the unique URL) into at least one publication
Although an exemplary mobile device 300 has been 25 401. In some embodiments, publication 401 may comprise
described that generally conforms to conventional general one of a run of printed publications, such as a magazines,
purpose computing devices, an mobile device 300 may be any flyers, brochures, catalogs, books, and the like. In Such
of a great number of devices capable of communicating with embodiments, manifesting the machine-scannable code into
the network 150 and/or URI-service server 200, for example, publication 401 may comprise printing (or causing to be
a personal computer, a game console, a set-top box, a hand 30 printed) an image of the machine-Scannable code on one or
held computer, a cell phone, or any other Suitable device. more pages of the printed publication. In other embodiments,
FIG. 4 illustrates an sequence of data communications for publication 401 may comprise an electronic publication, such
an exemplary remote-application invocation scenario, in as a web page, e-mail message(s), instant message(s), and the
accordance with one embodiment. Publisher 110 has an like. In such other embodiments, manifesting the machine
actionable data payload for exposure, via a machine-scan 35 scannable code into publication 401 may comprise including
nable code, to at least one mobile device 300 from among a an image of the machine-scannable code (or a link to Such an
number of mobile devices (not shown) of differing mobile image) within the content of an electronic document, such as
device types. The actionable payload should invoke a non an HyperText Markup Language (“HTML') document. In
web-browser application on the differing mobile device still other embodiments, publication 401 may comprise an
types, and the differing mobile device types require differing 40 article of manufacture, in which case manifesting the
URI formats to invoke the intended non-web-browser appli machine-scannable code into publication 401 may comprise
cation. affixing an RFID (encoded with the unique URL) to the
For example, in various embodiments, the actionable data article of manufacture.
payload may include information Such as contact information At some point, mobile device 300 encounters publication
(for invoking address book or contact manager applications 45 401 and machine-scans 435 the machine-scannable code
on the differing mobile device types), geo-location informa manifested therein. For example, in some embodiments,
tion (for invoking geo-mapping applications on the differing mobile device 300 may capture a picture of a machine-scan
mobile device types), event information (for invoking calen nable code printed on a page of publication 401 or rendered as
dar or appointment applications on the differing mobile an electronic document on a display of a display device. In
device types), downloadable content information (for invok 50 other embodiments, mobile device 300 may capture data
ing store or e-commerce applications on the differing mobile emanating from an RFID tag affixed to publication 401. As
device types), and the like. In some embodiments, the action discussed above, in some embodiments, the machine-scan
able data payload may include one kilobyte or more of data, nable code may encode only about 20-200 bytes of data, so
but mobile device 300's scanner may not be capable of resolv the machine-Scannable code may be relatively easily scan
ing more than about 200 bytes of data. 55 nable even if mobile device 300 has relatively low-fidelity
Publisher 110 sends actionable data payload 405 to URI scanner components.
service server 200, which generates 410 a unique URL asso Having obtained 440 a representation of the machine-scan
ciated with the data payload. URI-service server 200 stores nable code manifested in publication 401, mobile device 300
415, 417 in database 115 the data payload and the unique decodes 445 the unique URL encoded in the machine-scan
URL associated with the data payload. 60 nable code, and sends 450 a request for the unique URL to
In some embodiments, the actionable data payload may URI-Service server 200.
include one kilobyte or more of data and may thus be too large URI-service server 200 queries 455 database 115 and
to encode into a machine-scannable code than can be reliably retrieves 460 the actionable data payload associated with the
scanned by mobile devices with relatively low-fidelity scan unique URL. URI-service server 200 also determines a
ner components (e.g., cameras with fixed-focus lenses). In 65 device type of mobile device 300. For example, in one
Such embodiments, the unique URL may consist of far less embodiment, the request for the unique URL from mobile
data than the actionable data payload. For example, in one device 300 may include an implicit indication of the client
US 9,413,715 B2
7 8
type (e.g., a client hardware and/or Software type may be device type for handling the different payload types, includ
indicated via an HTTP referrer header or other metadata ing the URL and/or URI formats that are required to invoke
incident to the request). In other embodiments, determining a the non-web-browser applications on each device type.
device type of mobile device 300 may include additional In subroutine block 600 (see FIG. 6, discussed below),
communications (not shown) with mobile device 300. routine 500 creates a set of device-type/payload-type map
Having determined a device type of mobile device 300, pings corresponding to the plurality of different payload
URI-service server 200 generates a URI including the action types and the plurality of different device types. Specifically,
able data payload, the URI being formatted so that mobile FIG. 6 illustrates an exemplary device/payload mapping Sub
device 300 will be able to interpret and act on the data payload routine 600, in accordance with one embodiment. Beginning
by invoking a non-web-browser application. 10
in starting loop block 605, subroutine 600 iterates over each
Because the URI is to invoke a non-web-browser applica data payload type, and beginning in starting loop block 610,
tion, in some embodiments, the URI may not be a URL subroutine 600 iterates over each mobile-device type. In
(URLs being a subset of URIs). However, some device types block 615, subroutine 600 creates a mapping between the
may handle some URLs (as well as non-URL URIs) by non current data payload type and the current mobile-device type.
web-browser applications. For example, iPhone OS/iOS 15
devices (provided by Apple Inc. of Cupertino, Calif.) may For example, in one embodiment, the created mapping may
handle URLs in the form of “[Link] indicate that for the current device/payload combination, a
maps...' by invoking the Maps non-web-browser applica particular URI format should be used, including a particular
tion (if present), while URLs in the form of “[Link] URI scheme and a particular scheme-specific syntax, possi
[Link]/WebObjects . . . . may be handled by the bly including placeholders for various types of scheme-spe
iTunes non-web-browser application. cific data. In ending loop block 620, subroutine 600 iterates
In some embodiments, generating Such a device-type-spe back to block 610 to process the next mobile-device type (if
cific URI includes obtaining and using a device-type/pay any), and ending loop block 625, subroutine 600 iterates back
load-type mapping, as discussed below. In some embodi to block 605 to process the next data payload type (if any).
ments, the generated device-type-specific URI may comprise 25 subroutine 600 ends in block 699, making the created map
one kilobyte or more of data. pings available to the caller.
URI-service server 200 sends 475 the device-type-specific In one embodiment, the created mappings may be com
URI to mobile device 300, which invokes 480 an appropriate prise executable program code for handling a particular type
non-web-browser application to handle the data payload. In of actionable data payload. For example, in one embodiment,
other embodiments, an equivalent result may be obtained by 30 mappings for combinations of geo-location data payload
generating and delivering an alternately-formed device-type types and various mobile-device types may be embodied as in
specific data structure in place of the device-type-specific the following exemplary code snippet:
URI, e.g. device-type-specific Extensible Markup Language
(XML) data, device-type-specific JavaScript Object Nota urlagent = [Link]'HTTP USER AGENT
tion (“JSON”) data, and the like. 35
caption = map [Link] || map [Link] location
FIG. 5 illustrates a remote-application invocation routine case urlagent
500 in accordance with one embodiment. In some embodi when (iPhone webOS)/i
ments, routine 500 may be performed by URI-service server redirect url= [Link]
map [Link] query
200. In block 505, routine 500 obtains information related to redirect url < *(#{caption) unless [Link]?
a plurality of different payload types. For example, in one 40 when f(Android)fi
embodiment, the plurality of different payload types may redirect url = "geo:0.02(q=''<map [Link] query
include payload types such as contact information, map or redirect url < *(#{caption) unless [Link]?
else
geo-location information, event or appointment information, redirect url = map location...generate map url ([Link],
downloadable content information, and the like. The infor caption)
mation related to the plurality of different payload types may 45 end
include information Such as standardized formats (if any) redirect to redirect url
corresponding to the payload types. Such as vCard for contact
information, vCal for event/appointment information, and the Similarly, in one embodiment, mappings for combinations
like. of event or appointment data payload types and various
In block 510, routine 500 obtains information related to a 50 mobile-device types may be embodied as in the following
plurality of different device types. For example, in one exemplary code Snippet:
embodiment, the plurality of different device types may
include device types such as the following:
iPhone OS and/or iOS devices, provided by Apple Inc. of phone type = [Link](
Cupertino, Calif.; 55 [Link]'HTTP USER AGENTI)
Android operating system devices, provided by Google #Parameters for generating ics file
(avcal params = {}
Inc. of Menlo Park, Calif.; case phone type
BlackBerry devices, provided by Research InMotion Lim when MobileType:IPHONE
ited of Waterloo, Ontario; #Invoke native iCalendar on IPhone
webOS devices, provided by Palm, Inc. of Sunnyvale, 60
ics url = url for(:Only path=>true, :Overwrite params =>
{:action=>'generate, format=>ics)
Calif.; redirect to “webcal://#{[Link] with port#Eics url
Symbian OS devices, provided by Nokia Corporation of return
Tempere, Finland; when MobileType:WINDOWS CE
#Create downloadable vics file for Windows Mobile
and the like. redirect to :Overwrite params => {:action=>generate,
In some embodiments, the information related to the plu 65 :format=>'vcs
rality of different device types may also include information return
related to non-web-browser applications that exist on each
US 9,413,715 B2
10
-continued types, the mobile devices having obtained the unique URL by
scanning manifestations of a machine-scannable code to
when MobileType:SYMBIAN which the mobile devices were exposed. For example, in
#Create downloadable vics v1.0 file for Symbian phones various embodiments, the mobile devices may have been
redirect to :overwrite params => {:action=> generate, exposed to printed publications or rendered electronic docu
:format=>'vcs, .mobile=>phone type}
return ments including images of a two-dimensional barcode
end encoded with the unique URL, articles of manufacture with
affixed RFID tags encoded with the unique URL, and the like.
Referring again to FIG.5, in block515, routine 500 obtains In subroutine block 800 (see FIG. 8, discussed below),
an actionable data payload. For example, in one embodiment, 10 routine 500 processes the current request for the unique URL
routine 500 may receive the actionable data payload from a from the current requesting mobile device.
remote publisher device (e.g., publisher 110). In other From time to time, routine 500 may obtain information
embodiments, routine 500 may obtain actionable data pay about a new mobile device type that was not previously
load from database 115 or other local or remote data store. known at the time the unique URL was generated and asso
As discussed above, in various embodiments, the action 15 ciated with the actionable data payload. In decision block
able data payload may include information Such as contact 535, routine 500 determines whether any such new device
information (for invoking address book or contact manager information has been obtained. If not, in block 540 routine
applications on the plurality of different device types), geo 500 iterates back to block 530 to process the next request for
location information (for invoking geo-mapping applications the unique URL (if any). If information about one or more
on the plurality of different device types), event information new mobile devices has been obtained, then in subroutine
(for invoking calendar or appointment applications on the block 600 (see discussion of FIG. 6, above), routine 500
plurality of different device types), downloadable content creates new device/payload mappings for each new combi
information (for invoking store or e-commerce applications nation of mobile device type and payload type, then in block
on the plurality of different device types), and the like. In 540, iterates back to block 530 to process the next request for
Some embodiments, the actionable data payload may include the unique URL (ifany). After all requests for the unique URL
one kilobyte or more of data. 25 have been processed, routine 500 ends in block 599.
In block 520, routine 500 stores the actionable data pay FIG. 8 illustrates an exemplary unique-URL-request pro
load, e.g. in database 115 or other data store. In block 525, cessing subroutine 800, in accordance with one embodiment.
routine 500 generates a unique URL and associates the In block 805, subroutine 800 retrieves (e.g., by querying
unique URL with the stored actionable data payload. In some database 115 according to the unique URL) the actionable
embodiments, the unique URL may consist of between 30
data payload associated with the unique URL. In block 810,
20-200 bytes of data. In other embodiments, the unique URL subroutine 800 determines which of the plurality of different
may be larger or Smaller. payload types corresponds to the actionable data payload
In subroutine block 700 (see FIG. 7, discussed below), associated with the unique URL.
routine 500 provides the unique URL for exposure, via a In block 815, subroutine 800 determines a device type of
machine-scannable code, to a plurality of mobile devices of the mobile device that issued the request currently being
the plurality of different device types. 35 processed. For example, in one embodiment, the request for
FIG. 7 illustrates an exemplary unique URL exposure sub the unique URL from the mobile device may include an
routine 700, in accordance with one embodiment. In decision implicit indication of the client type (e.g., a client hardware
block 705, subroutine 700 determines whether to generate a and/or software type may be indicated via an HTTP referrer
machine-scannable code. In some embodiments, such as header or other metadata incident to the request). In other
those in which the machine-scannable code is a two-dimen 40 embodiments, determining a device type of the requesting
sional barcode, subroutine 700 may encode the unique URL mobile device may include additional communications with
the mobile device.
into the machine-scannable code in block 710 and provide the In decision block 817, Subroutine 800 determines whether
generated machine-Scannable code for exposure to a plurality the determined device type of the requesting mobile device is
of mobile devices in block 715. For example, in one embodi known and a device-type/payload-type mapping exists. If so,
ment, subroutine 700 may encode the unique URL into a 45
in block 820, subroutine 800 obtains the mapping corre
two-dimensional barcode and send an image of the barcode to sponding to the determined device type of the requesting
a remote device (e.g., publisher 110) for printing into printed
publications, embedding into electronic documents, and the mobile device and the determined payload type of the action
like, which publications and/or electronic documents may be able data payload associated with the requested unique URL.
subsequently exposed to a plurality of mobile devices of In block 825, subroutine 800 generates a device-type-spe
differing device types. However, in other embodiments, sub 50 cific URI including the actionable data payload. The URI is
routine 700 may determine not to generate a machine-scan formatted so that the requesting mobile device will be able to
nable code, leaving this task to a remote device (e.g., pub interpret and act on the data payload by invoking a suitable
lisher 110). non-web-browser application.
In decision block 720, Subroutine 700 determines whether In block 830, subroutine 800 delivers the device-type-spe
to provide the unique URL. In some embodiments, such as 55 cific URI to the requesting mobile device, where a URI han
those in which subroutine 700 has generated and provided the dling routine will invoke a non-web-browser application to
machine-scannable code in block 710-715, Subroutine 700 handle the actionable data payload included in the device
may not need to also provide the unique URI. In other type-specific URI. For example, depending on the payload
embodiments, including those in which subroutine 700 deter type, the requesting mobile device may act on the actionable
mined not to generate a machine-scannable code in block 60 data payload by adding (or prompting to add) a contact to a
705, subroutine 700 may in block 725 provide the unique contacts list, adding (or prompting to add) an event or
URL to a remote device (e.g., publisher 110) for encoding appointment to a calendar or event list, opening a mapping
into a machine-Scannable code and Subsequent exposure to a application to a geo-location, downloading (or prompting to
plurality of mobile devices of differing device types. Subrou
tine 700 ends in block 799. download) downloadable content from a store or other con
Referring again to FIG. 5, beginning in starting loop block 65 tent-downloading application, and the like.
530, routine 500 processes an ongoing series of requests for On the other hand, if in decision block 817, Subroutine 800
the unique URL from mobile devices of differing device determines that the determined device type of the requesting
US 9,413,715 B2
11 12
mobile device is not known and/or that a device-type/pay exposure to mobile devices of differing device types, inaccor
load-type mapping does not exist, then in block 835, subrou dance with various embodiments.
tine 800 may generate a generic URI according to the data FIG. 10 illustrates a web application 1000, such as may be
payload type and in block 840, deliver the generic URI to the provided by URI-service server 200, for handling a geo
requesting mobile device. For example, in one embodiment, location payload. A user (e.g. a user of publisher device 110)
forageo-location-type payload, Subroutine 800 may generate provides an address 1005 (or otherwise specifies a geo-loca
an image of a map targeting a particular geo-location and tion) as an actionable payload. In other embodiments, web
application 1000 may allow for entry of additional payload
deliver a URI of the image to the requesting mobile device to data (not shown). Such as captions, map labels, directions, and
be handled by a web browser or other image-handling appli 10
the like. In response to payload input, the web application
cation. For another example, in one embodiment, for an event provider automatically, dynamically generates and provides
or appointment payload, Subroutine 800 may generate a web to the user a unique URL 1025 associated with the payload, a
page including event or appointment details, and deliver the two-dimensional barcode 1020 (including a non-machine
URI of the web page to the requesting mobile device to be readable, payload-type-indicative pictogram 1030), an
handled by a web browser. Similarly, in one embodiment, for 15
embeddable URL 1015 to an image corresponding to two
contact information payload, Subroutine 800 may generate a dimensional barcode 1020, and a preview 1010 of the geo
web page including contact details, and deliver the URI of the location on a map.
web page to the requesting mobile device to be handled by a FIG. 11 illustrates a web application 1100, such as may be
web browser. provided by URI-service server 200, for handling a URL
Subroutine 800 ends in block 899. payload. A user (e.g. a user of publisher device 110) provides
FIG. 9 illustrates a SPARQCodeTM two-dimensional bar a URL 1105 as an actionable payload (on some devices,
code 900, such as may be employed as a machine-scannable notable iOS/iPhone OS devices, certain URLs may be
code in various embodiments. Two-dimensional barcode 900 handled by non-web-browser applications). In other embodi
follows the SPARQCode TM encoding standard, which was ments, web application 1100 may allow for entry of addi
developed by the assignee of the present application. Per the 25
tional payload data (not shown). Such as captions and the like.
SPARQCodeTM encoding standard, barcode 900 includes In response to payload input, the web application provider
several components: automatically, dynamically generates and provides to the user
a source-identifier 920; a unique URL 1125 associated with the payload, a two
a non-machine-readable pictogram 905 indicating a pay dimensional barcode 1120 (including a non-machine-read
load type of the actionable data payload associated with 30
able, payload-type-indicative pictogram 1130), and an
barcode 900; embeddable URL 1115 to an image corresponding to two
a caption 910, providing brief human-readable information dimensional barcode 1120.
about the data payload associated with barcode 900; and FIG. 12 illustrates a web application 1200, such as may be
a QR Code 915 encoded with a unique URL associated provided by URI-service server 200, for handling an event or
with a data payload. 35
appointment payload. A user (e.g. a user of publisher device
QR Code 915 encodes the unique URL as a binary data 120) provides an actionable payload, including a title 1205,
stream according to standards defined by DENSO Corpora location 1210, organizer 1235. In other embodiments, web
tion (of Kariya, Aichi, Japan) in ISO/IEC 18004. However, application 1200 may allow for entry of additional payload
ISO/IEC 18004 lacks an encoding standard for interpreting data (not shown). Such as captions, start and/or stop times,
the data stream on the application layer for decoding various 40
alarms, directions, and the like. In response to payload input,
data payload types, as discussed herein. The SPARQCode TM the web application provider automatically, dynamically gen
encoding standard specifies common formats for the interpre erates and provides to the user a unique URL 1225 associated
tation of different data payload types at the application layer. with the payload, a two-dimensional barcode 1220 (including
In the illustrated embodiment, non-machine-readable pic a non-machine-readable, payload-type-indicative pictogram
togram 905 indicates that the geo-location or map data is the 45 1230), and an embeddable URL 1215 to an image corre
payload type of the actionable data payload associated with sponding to two-dimensional barcode 1220.
the unique URL encoded in QR Code 915. The SPARQ Tables 1-5, below, illustrate unique URLs and device-type
CodeM standard specifies additional pictograms indicating specific URIs for an exemplary geo-location payload type and
various other actionable data payload types, including contact an exemplary event/appointment payload type according to
information, appointment or event information, web address 50
various embodiments.
information, raw data, and the like. For example, in one embodiment, an exemplary geo-loca
FIGS. 10-12 illustrate exemplary interfaces 1000, 1100, tion data payload (here, referring to the Pike Place Market in
1200, such as may be used to obtain actionable data payloads Seattle, Wash.) may be associated with an exemplary unique
(e.g. from publisher 110 to URI-service server 200) and pro URL (e.g., “[Link] which may be
vide machine-Scannable codes and/or unique URLs (e.g. mapped to device-type-specific URIs as set out in Table 1,
from URI-service server 200 to publisher 110) for subsequent below.
TABLE 1

Device type device-type-specific URI


iPhone [Link]
%20USA%28pike--place+market-seattle%29
Android geo:0,0?q=Pike Place Market, Seattle, WA, USA(pike--place+market-seattle)
webOS [Link]
%28pike--place+market--seattle%29
US 9,413,715 B2
13 14
To handle the device-type-specific URIs listed in Table 1, a However, in alternate embodiments, other device types
may not allow for invocation of a local mapping application
requesting device of one of the device types set out in Table 1 on the requesting device. For example, in one embodiment set
would invoke a local mapping application to handle the indi out in Table 2, for certain device types, a device-type-specific
URI may resolve to a dynamically-generated image of a map
cated device-type-specific URI. showing the geo-location specified by the data payload.
TABLE 2
Device type device-type-specific URI
Windows [Link]
Mobile; bin/map [Link]?Zoom=14&maptype=mobile&center=47.6101359,-
Symbian OS; 122.3420567&markers=47.6101359,-
Blackberry 122.3420567,blueg&cap=pike%2Bplace%2Bmarket%2Bseattle&size=350X280

15
For another example, in one embodiment, an exemplary
calendar-event data payload (here, referring to an event cel
ebrating the 58th Birthday of the Barcode) associated with an
exemplary unique URL (e.g., "[Link]
MNN') may be mapped to device-type-specific URIs as set
out in Table 3, below.
TABLE 3
Device type device-type-specific URI
iPhonefiOS webcal://[Link]/vcal/generate?alarm=15&desc=Barcode%27s--58th--

Windows [Link]
Mobile Birthday%21&end=2010-10-07T21%3A30%3A00%2BOO%3A00&

Symbian OS [Link]

title=Birthday

To handle the device-type-specific URIs listed in Table 3, a


40 requesting device of one of the device types set out in Table 3
would make a request to the indicated device-type-specific
URI and invoke a local calendaring application to handle the
resultant iCalendar data (see Table 5, discussed below).
However, in alternate embodiments involving other device
types, a local calendaring application may be invoked indi
45
rectly, such as by emailing iCalendar data to an email address
associated with the requesting device. Consequently, the
device-type-specific URIs set forth in Table 4, below, may
resolve to a web page that prompts for an email address to
which iCalendar data would then be emailed, subsequently
invoking a local calendaring application on the receiving
device.
TABLE 4

Device type device-type-specific URI


Blackberry [Link]
Birthday!&end=2010-10-07T21%3A30%3A00%2BOO%3A00&
from=noreply%[Link]&loc=Seattle%2C+WA&mobile=blackberry&
start=2010-10-07T20%3A30%3A00%2BOO%3A00&title=Birthday&
vcal format=ics
Android [Link]
Birthday!&end=2010-10-07T21%3A30%3A00%2BOO%3A00&
from=noreply%[Link]&loc=Seattle%2C+WA&mobile=andriod&
start=2010-10-07T20%3A30%3A00%2BOO%3A00&title=Birthday&
vcal format=ics
US 9,413,715 B2
15 16
TABLE 4-continued
Device type device-type-specific URI
webOS [Link]
desc=Barcode%27s+58th-- Birthday!&email=yowhan%[Link]&

mobile=palm&start=2010-10-07T20%3A30%3A00%2BOO%3A00&
title=Birthday&vcal format=ics

Table 5 shows various device-type-specific iCalendar pay TABLE 5-continued


loads that may be delivered to requesting devices of various
types according to the device-type-specific URIs set out in Device type device-type-specific iCalendar data
Table 3 and Table 4. The various iCalendar data payloads set 15 CALSCALE:GREGORIAN
out in Table 5 would ultimately be handled by a local calen EGIN:VEVENT
daring application on the requesting device of the indicated TSTART:2010.1007T2O3OOOZ
TEND:2010.1007T213OOOZ
type. TSTAMP:2O100715TO63717Z
RGANIZER:CN=:MAILTO:noreply([Link]
TABLE 5 LASS:PUBLIC
REATED:2O10(O71ST063717Z
Device type device-type-specific iCalendar data UMMARY:Birthday
ESCRIPTION:Barcode's 58th Birthday!
iPhone/iOS: BEGIN:VCALENDAR LAST-MODIFIED:2O10(O71STO63717Z
Android: METHOD:PUBLISH OCATION:Seattle, WA
webOS PRODID:-f/MSKYNET, Inc.//EN EQUENCE:0
VERSION:20 25
RANSP:OPAQUE
X-WR-CALNAME:Birthday ND:VEVENT
CALSCALE:GREGORIAN END:VCALENDAR
EGIN:VEVENT Windows EGIN:VCALENDAR
TSTART:2O101007T2O3OOOZ Mobile ETHOD:PUBLISH
TEND:2010.1007T213OOOZ

RGANIZER:CN=:MAILTO:noreply([Link]
LASS:PUBLIC
REATED:2O1 OO71STOS44082
30
s
PRODID:-f/MSKYNET, Inc.//EN
ERSION:2.O
-WR-CALNAME:Birthday
ALSCALE:GREGORIAN
EGIN:VEVENT
UMMARY:Birthday TSTART:2010.1007T2O3OOOZ
ESCRIPTION:Barcode's 58th Birthday! TEND:2010.1007T213OOOZ
LAST MODIFIED:2O1 OO71STOS44082, 35 TSTAMP:2O100715TO55225Z
OCATION:Seattle, WA RGANIZER:CN=:MAILTO:noreply([Link]
UENCE:O LASS:PUBLIC

s NSP:OPAQUE
N:VALARM
ON:DISPLAY
GGER-PT1SM
D:VALARM
40
REATED:2O100715TO55225Z
UMMARY:Birthday
ESCRIPTION:Barcode's 58th Birthday!
ASTMODIFIED:2O10(O71STOSS225Z
OCATION:Seattle, WA
D:VEVENT EQUENCE:0
D:VCALENDAR RANSP:OPAQUE
Blackberry B GIN:VCALENDAR EGIN:VALARM
C
THOD:REQUEST CTION: DISPLAY
ODID:-f/MSKYNET, Inc.//EN RIGGER-PT1SM
RSION:20 45 END:VALARM
-WR-CALNAME:Birthday END:VEVENT
A. SCALE:GREGORIAN END:VCALENDAR
GIN:VEVENT
START:2O101007T2O3OOOZ
END:2010.1007T213OOOZ
STAMP:2O1 OO71STO628372, 50
Although Tables 3-5 refer to an exemplary event payload
RGANIZER:CN=:MAILTO:noreply([Link] delivered in the iCalendar data format, in other embodiments,
LASS:PUBLIC the methods disclosed herein may be similarly adapted to
REATED:2O1 OO71STO628372
UMMARY:Birthday
other payload data types and data delivery formats.
ESCRIPTION:Barcode's 58th Birthday! FIG. 13 illustrates a sequence of data communications for
ASTMODIFIED:2O1 OO71STO628372, 55 an exemplary dynamic machine-scannable-code generation
OCATION:Seattle, WA and URI-handling scenario, in accordance with one embodi
EQUENCE:0 ment. Rendering client 120 (e.g. a personal computer, or other
RANSP:OPAQUE
EGIN:VALARM computing device capable of rendering a web page) sends a
CTION:DISPLAY web page request 1305 to publisher 110. In response, pub
RIGGER-PT1SM
ND:VALARM
60 lisher 110 sends source 1310 for the requested web page,
ND:VEVENT typically a document including text that has been marked up
ND:VCALENDAR in a markup language Such as HTML, eXtensible Hypertext
Symbian EGIN:VCALENDAR Markup Language (XHTML'), XML, or the like. The
ETHOD:PUBLISH
RODID:-/MSKYNET, Inc.//EN Source document includes a markup tag for including in the
ERSION:1.O 65 rendered web page an image, sourced from URI-Service
X-WR-CALNAME:Birthday server 200, of a machine-scannable code, such as a barcode or
two-dimensional barcode. For example, in one embodiment,
US 9,413,715 B2
17 18
an HTML document may include an<img tag having a “src' 1385 corresponding to the requested unique URI. URI-ser
attribute specifying a dynamic image resource hosted by vice server 200 then responds to the unique-URI-request with
URI-service server 200, e.g. <img src="[Link] a redirect 1390 to the destination URI. Mobile device 300
[Link]/qrgen?qturl&data=http%[Link]/> then sends a request 1395 for the destination URI to publisher
Rendering client 120 parses 1315 the source document and 110 (if the destination URI identifies a resource hosted by
reads the image tag for the machine-Scannable code. When publisher 110) or to another web server hosting the resource
rendering the page, rendering client 120 sends a single identified by the destination URI.
request 1320 to URI-service server 200 for the specified Thus, as illustrated in the scenario described above, any
image resource. For example, in one embodiment, rendering destination URL or other URI (of any length) can be con
client 120 may send a "GET request for the specified image 10
verted to a compact, unique URL (or other URI) encoded into
resource to URI-service server 200 via the Hypertext Transfer a two-dimensional barcode image (or other machine-scan
Protocol (“HTTP"). nable-code image) simply by including an image tag direct
URI-service server 200 parses the request and identifies ing URI-service server 200, via a single resource request, to
1325 a destination URI (which may be a URL) specified by generate a unique URI and encode it into a dynamically
the request. For example, in one embodiment, URI-service 15
server 200 may receive a request including one or more name/ generated machine-scannable-code image.
value pairs, Such aS “qt=url” and/or FIG. 14 illustrates a dynamic machine-Scannable-code
“data=http%3A%2F%[Link]', and the destination generation routine 1400, such as may be performed by URI
URL may be the value specified by a particular name, e.g. service server 200 in accordance with one embodiment. In
“data'. In some embodiments, URI-service server 200 may block 1405, routine 1400 receives a request for a machine
have a publically available application programming inter scannable-code image resource, the request specifying one or
face (API) defining the name/value pair to use to indicate a more destination URIs (or URLs). For example, in one
destination URL. In various embodiments, the request may embodiment, routine 1400 may receive a request including
include additional name/value pairs that may affect various one or more name/value pairs, such as "qt url''.
parameters of the requested machine-scannable-code image. 25 “data1=http%3A%2F%[Link]', and/or “data2=http
URI-service server 200 stores the identified destination URI %3A%2F%[Link]'.
in database 115. In some embodiments, the destination URI In decision block 1410, routine 1400 stores the one or more
may identify a resource hosted by publisher 110. In other received destination URI(s) (e.g., in database 115). In block
embodiments, the destination URI may identify a resource 1415, routine 1400 determines whether more than one desti
hosted by another web server (not shown). 30
nation URI was specified by the request. If not, routine 1400
URI-service server 200 generates 1335 a unique URI proceeds to block 1430 (discussed below). If, however, the
(which may be a URL) corresponding to the identified desti request specified more than one destination URI, then in
nation URI. In some embodiments, if the identified destina decision block 1420, routine 1400 determines whether
tion URI has been previously requested, URI-service server explicit conditional specifiers were provided for the two or
200 may alternatively retrieve a previously generated unique 35
URI from database 115. In other embodiments, URI-service more destination URIs. For example, in some embodiments,
server 200 may generate a new unique URI for some or all the request may include two or more additional name/value
subsequent requests for an identified destination URI. URI pairs specifying conditions associated with the two or more
service server 200 associates 1340 the generated unique URI destination URIs.
(if generated) with the identified destination URI in database 40 For example, in one embodiment, a request may include
115. one destination URI identifying an iPhone version of a par
URI-service server 200 generates 1345 a machine-scan ticular application, and a second destination URI identifying
nable-code image with the unique URI encoded therein. For an Android version of the particular application. In this exem
example, in some embodiments, URI-service server 200 may plary embodiment, the request may further include name/
generate a two-dimensional barcode, Such as those illustrated 45 value pairs such as “device1=iphone' and
in FIGS. 9-12, discussed above. In alternate embodiments, if “device2=android’, which act as conditional specifiers for the
the unique URI has previously been encoded into a machine first and second destination URIs. For example, the condi
scannable-code, URI-service server 200 may retrieve a stored tional specifier “iphone' may indicate that when a machine
copy of the previously generated machine-Scannable-code scannable-code generated in response to the request is
image from database 115. 50 scanned by an iPhone device, the device may be redirected to
URI-Service server 200 delivers 1350 the machine-Scan the first destination URI, whereas if the machine-scannable
nable-code image to rendering client 120, which inserts the code is scanned by an Android device, the device may be
image into the web page it is rendering 1355 and displays the redirected to the second destination URI.
rendered web page on a display associated with the rendering In other embodiments, the request may specify time-based
client 120. 55 conditional specifiers, such as “day1=MTWRF' and
At some point while the machine-scannable-code image is “day2=SS, which may indicate that a first destination URI is
displayed on a display associated with the rendering client associated with weekdays, while a second destination URI is
120, a mobile device 300 scans 1360 the rendered web page associated with weekend days. Similarly, in Some embodi
with a machine-Scannable-code scanner (e.g., a camera com ments, the request may specify location-based conditional
ponent and a barcode- or two-dimensional barcode-reading 60 specifiers, such as “state1=WACA and “state2=OR, ID',
application) to obtain a facsimile of the machine-scannable which may indicate that a first destination URI is associated
code image 1365. Mobile device 300 decodes 1370 the with the states of Washington and California, while a second
unique URI encoded in the machine-scannable-code image destination URI is associated with Oregon and Idaho. Simi
and sends a request 1375 for the unique URI to URI-service larly, in some embodiments, the request may specify loca
Server 200. 65 tion-based conditional specifiers, such as "Zip1=98101 and
URI-service server 200 receives the request and sends a "zip2=98028, which may indicate that a first destination
query 1380 to database 115 to retrieve the destination URI URI is associated with the zip code 98.101, while a second
US 9,413,715 B2
19 20
destination URI is associated with the zip code 98028. In In block 1465, routine 1400 delivers the generated
other embodiments, other types of conditional specifier may machine-scannable-code image to the requestor for rendering
be specified. to a display. Routine 1400 ends in block 1499.
If the request specifies such conditional specifiers, then in FIG. 15 illustrates a URI-redirection routine 1500, such as
block 1425, routine 1400 stores the conditional specifiers may be performed by URI-service server 200 in accordance
(e.g., in database 115) in association with their respective with one embodiment. In block 1505, routine 1500 receives a
destination URIs. request for a resource identified by a previously generated
However, in other embodiments, a distinction between dif unique URI. In some embodiments, the request may be
ferent application platforms may be inherent in the destina received from a mobile device that obtained the unique URI
tion URLs and/or distinctions between multiple destination
10 by optically (or otherwise) scanning a machine-scannable
URIs may be implicitly determinable based on the destination code generated according to FIG. 14, discussed above, and
displayed on a rendering device.
URLs themselves. For example, in one embodiment, a first In block 1510, routine 1500 retrieves the one or more
destination URI may specify a first country-code top-level destination URI(s) (e.g., from database 115) that are associ
domain, while a second destination URI may specify a first 15 ated with the requested unique URI. In decision block 1515,
country-code top-level domain. In such an embodiment, it routine 1500 determines whether more than one destination
may be implicit in the destination URIs that when a machine URI is associated with the requested unique URI. If only one
scannable-code generated in response to the request is destination URI is associated with the requested unique URI,
scanned by a device in the first country, the device may be then in block 1520, routine 1500 redirects the requestor to the
redirected to the first destination URI, but a device in the destination URI. In various embodiments, the redirection
second country may be redirected to the second destination mechanism may include a 3xx HTTP status code or other
URI, and so forth. Similar implicit determinations may be Suitable redirection and/or forwarding scheme.
made for various other types of destination URIs, such as However, if more than one destination URI is associated
destination URIs that identify geographical coordinates or with the requested unique URI, then in decision block 1530,
other location-based information (e.g., country, state, city, 25 routine 1500 determines whether it can obtain one or more
neighborhood, block, and the like). In such embodiments, stored and/or implicit conditional specifiers associated with
devices may be redirected to the destination URI identifying the more than one destination URI. If routine 1500 cannot
the nearest coordinate or location. In such and similar obtain one or more stored and/or implicit conditional speci
embodiments, the request may not include explicit condi fiers, then in block 1535, routine 1500 may prompt the
tional specifiers, in which case, routine 1400 may proceed 30 requestor to select one of the destination URI(s), such as by
from decision block 1420 directly to block 1430. delivering a web page offering the requestor the various des
In decision block 1430, routine 1400 determines whether a tination URI(s) as selectable options. In block 1540, routine
unique URI corresponding to the destination URI (or to the 1500 redirects the requestor to the selected destination URI.
group of destination URIs) already exists. If so, then routine In various embodiments, the redirection mechanism may
1400 proceeds to block 1445. If not, then in block 1435, 35 include a 3XX HTTP status code or other suitable redirection
routine 1400 generates a unique URI corresponding to the and/or forwarding scheme.
destination URI(s) and, in block 1440, associates the gener On the other hand, if routine 1500 can obtain one or more
ated unique URI with the destination URI(s) (e.g., in database stored and/or implicit conditional specifiers, then in block
115). In some embodiments, routine 1400 may omit decision 1545, routine 1500 matches the request for the unique URI to
block 1430, generating a new unique URI for every machine 40 one of the conditional specifiers. For example, in various
scannable-code generated, regardless of whether other previ embodiments, matching the request for the unique URI to one
ously-generated unique URIs are also associated with the of the conditional specifiers may include determining meta
destination URI(s). data associated with the request, such as a requesting device
In block 1445, routine 1400 determines whether the type or Software platform; a physical or logical location asso
request includes a group identifier. For example, in one 45 ciated with the requesting device; a time of day, day of week,
embodiment, the request may include a name/value pair Such month, year or other time-related metadata; and the like. The
as “group=123. If not, then routine 1400 proceeds to block determined metadata may then be compared against the two
1450, discussed below. If the request includes a group iden or more conditional specifiers to find a matching destination
tifier, then in decision block 1455, routine 1400 determines URI. In some embodiments, one of the destination URIs may
whether the group identifier has one or more associated image 50 be associated with a “default” or “fallback’ conditional speci
customization attributes. For example, in various embodi fier, in the event that no other, more specific conditional
ments, a group identifier may be associated with one or more specifier is found to match the request metadata. In block
customized attributes Such as image size, image color, image 1550, routine 1500 redirects the requestor to the matched
caption (or other text string), non-scannable logo, and the destination URI.
like. 55 In block 1525, routine 1500 stores one or more pieces of
If the group identifier has no associated image customiza analytic metadata associated with the just-completed redi
tion attributes, then routine 1400 proceeds to block 1450, rect. For example, in various embodiments, routine 1500 may
discussed below. However, if the group identifier has one or determine and store metadata associated with the request,
more associated image customization attributes, then in block Such as a requesting device type or Software platform; a
1460, routine 1400 generates a machine-scannable-code 60 physical or logical location associated with the requesting
image encoded with the unique URI according to the one or device; a time of day, day of week, month, year or other
more associated image customization attributes. time-related metadata; and the like. In some embodiments,
In block 1450, routine 1400 generates a machine-scan routine 1500 may alternately or additionally classify analytic
nable-code image encoded with the unique URI according to data according to a group identifier associated with the unique
one or more default image attributes (e.g., in a default color, 65 URI (if any).
in a default size, with a default caption, with a default non Routine 1500 ends in block 1599. Subsequently, in some
scannable logo, and the like). embodiments, routine 1500 may provide such analytic data in
US 9,413,715 B2
21 22
the form of a report to a URI-service client on whose behalf 11. The method of claim 8, wherein said image customi
the unique URI redirection may have been provided. Zation attribute comprises at least one of a logo image, a text
Although specific embodiments have been illustrated and String, and an image color.
described herein, it will be appreciated by those of ordinary 12. A non-transitory computer-readable storage medium
skill in the art that alternate and/or equivalent implementa 5 tangibly encoded with computer-executable instructions, that
tions may be substituted for the specific embodiments shown when executed by a processor associated with a computing
and described without departing from the scope of the present device, perform a method comprising:
disclosure. This application is intended to cover any adapta
tions or variations of the embodiments discussed herein. receiving, over a network, a request for a uniform resource
The invention claimed is: 10
identifier (URI) associated with a network resource, said
1. A method comprising: request comprising information associated with a desti
receiving, at a computing device on a network, a request for nation URI for the network resource;
a uniform resource identifier (URI) associated with a parsing the request, said parsing comprising identifying
network resource, said request comprising information the destination URI:
associated with a destination URI for the network determining a unique URI that corresponds to the destina
15
resource:
parsing, via the computing device, the request, said parsing tion URI:
comprising identifying the destination URI: dynamically generating a machine-scannable-code image,
determining, via the computing device, a unique URI that said generating comprising encoding the unique URI
corresponds to the destination URI: into the machine-Scannable-code image; and
dynamically generating, via the computing device, a communicating, over the network, said machine-scan
machine-scannable-code image, said generating com nable-code image to a remote rendering device.
prising encoding the unique URI into the machine-scan 13. The non-transitory computer-readable storage medium
nable-code image; and of claim 12, further comprising:
communicating, via the computing device over the net determining that the unique URI corresponding to the des
work, said machine-scannable-code image to a remote 25 tination URI does not exist; and
rendering device. generating a new unique URI which corresponds to desti
2. The method of claim 1, further comprising: nation URI.
determining that the unique URI corresponding to the des 14. The non-transitory computer-readable storage medium
tination URI does not exist; and of claim 12, further comprising:
generating a new unique URI which corresponds to desti 30 generating a new unique URI for every generated machine
nation URI. Scannable-code image regardless of whether the unique
3. The method of claim 1, further comprising: URI exists; and
generating a new unique URI for every generated machine encoding the new unique URI into the machine-scannable
Scannable-code image regardless of whether the unique code image.
URI exists; and 35 15. The non-transitory computer-readable storage medium
encoding the new unique URI into the machine-scannable of claim 14, further comprising:
code image. associating the new unique URI with the destination URI:
4. The method of claim 3, further comprising: and
associating the new unique URI with the destination URI: storing said associated new unique URI and destination
and 40 URI in a database on the network.
storing said associated new unique URI and destination 16. The non-transitory computer-readable storage medium
URI in a database on the network. of claim 12, wherein said request comprises a single Hyper
5. The method of claim 1, wherein said destination URI text Transfer Protocol (HTTP) “GET request, wherein said
comprises a plurality of URIs. destination URI is associated with an attribute of an element
6. The method of claim 1, wherein said machine-scan 45 from a markup language document hosted by remote server.
nable-code image comprises a barcode. 17. The non-transitory computer-readable storage medium
7. The method of claim 1, wherein said request comprises of claim 12, further comprising:
a single Hypertext Transfer Protocol (HTTP) “GET request, determining an image customization attribute associated
wherein said destination URI is associated with an attribute of with said unique URI, wherein said machine-scannable
an element from a markup language document hosted by 50 code image depicts said image customization attribute.
remote Server. 18. The non-transitory computer-readable storage medium
8. The method of claim 1, further comprising: of claim 17, further comprising:
determining an image customization attribute associated receiving a second request for a resource identified by said
with said unique URI, wherein said machine-scannable unique URI subsequent to said communication of the
code image depicts said image customization attribute. 55 machine-scannable-code image;
9. The method of claim 8, wherein said request indicates a obtaining said destination URI according to said unique
group identifier associating said request with said image cus URI:
tomization attribute. redirecting said second request to said destination URI:
10. The method of claim 8, further comprising: and
receiving a second request for a resource identified by said 60 storing analytic data associated with said second request.
unique URI subsequent to said communication of the 19. A system comprising:
machine-scannable-code image: a processor;
obtaining said destination URI according to said unique a non-transitory computer-readable storage medium for
URI: tangibly storing thereon program logic for execution by
redirecting said second request to said destination URI: 65 the processor, the program logic comprising:
and receiving logic executed by the processor for receiving,
storing analytic data associated with said second request. over a network, a request for a uniform resource iden
US 9,413,715 B2
23 24
tifier (URI) associated with a network resource, said
request comprising information associated with a
destination URI for the network resource:
parsing the request, said parsing comprising identifying
the destination URI: 5
determining a unique URI that corresponds to the desti
nation URI:
dynamically generating a machine-Scannable-code
image, said generating comprising encoding the
unique URI into the machine-scannable-code image: 10
and
communicating, over the network, said machine-scan
nable-code image to a remote rendering device.
20. The system of claim 19, further comprising:
determining logic executed by the processor for determin- 15
ing that the unique URI corresponding to the destination
URI does not exist;
generating logic executed by the processor for generating a
new unique URI which corresponds to destination URI:
encoding logic executed by the processor for encoding the 20
new unique URI into the machine-scannable-code
image; and
storage logic executed by the processor for storing said
associated new unique URI and destination URI in a
database on the network. 25
k k k k k

You might also like