WO2013191770A1 - Envoi et réception de métadonnées contenant des références à des supports numériques ou des biens de consommation entre abonnés appelants - Google Patents

Envoi et réception de métadonnées contenant des références à des supports numériques ou des biens de consommation entre abonnés appelants Download PDF

Info

Publication number: WO2013191770A1
Authority: WO; WIPO (PCT)
Prior art keywords: message; owner; aqu; mobile device; messages
Prior art date: 2012-06-22
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.): Ceased

Application number

PCT/US2013/031798

Other languages

English (en)

Inventor

Martin GINDI

Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)

TRIBECA MOBILE INNOVATIONS Inc

Original Assignee

TRIBECA MOBILE INNOVATIONS Inc

Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)

2012-06-22

Filing date

2013-03-14

Publication date

2013-12-27

2013-03-14 Application filed by TRIBECA MOBILE INNOVATIONS Inc filed Critical TRIBECA MOBILE INNOVATIONS Inc

2013-12-27 Publication of WO2013191770A1 publication Critical patent/WO2013191770A1/fr

2014-12-22 Anticipated expiration legal-status Critical

Status Ceased legal-status Critical Current

Classifications

- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/22—Arrangements for supervision, monitoring or testing
- H04M3/2227—Quality of service monitoring
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/42—Systems providing special services or facilities to subscribers
- H04M3/42017—Customized ring-back tones

Definitions

Figure 1 is a system diagram of hardware and databases to send and receive object related messages between two mobile handsets
Figures 2(1 ), 2(2), and 2A are views of data tables used in the disclosure. Illustrative data is shown along with the tables and columns.
Figures 3(1 ), 3(2), 3A(1 ), and 3A(2) are flow diagrams showing the main steps sending a message with a possible action/response of any type between two handsets.
Figures 4(1 ) and 4(2) show a time-line communication flow of the shown in Figures 3 and 3A for a message from an acquaintance (AQU) to an owner about rating an object owned by or associated with the owner.
Figures 4A(1 ) and 4A(2) show a time-line communication flow of the embodiment shown in Figures 3 and 3A for a message from the AQU to the owner about recommending a new object to replace the object owned by the owner.
Figures 4B(1 ) and 4B(2) show a time-line communication flow of the embodiment shown in Figures 3 and 3A for a message from the AQU to the owner sending a gift of a new object to replace the object owned by the owner.
Figures 4C(1 ) and 4C(2) show a time-line communication flow of the embodiment shown in Figures 3 and 3A for a message from the AQU to the owner that sends a gift of a new object unrelated to any object owned by the owner, and shows the object catalog access when the catalog is located on a carrier.
Figures 4D(1 ) and 4D(2) show a time-line communication flow of the embodiment shown in Figures 3 and 3A for a general textual message from the AQU to the owner about an object owned by the owner.
Figures 4E(1 ) and 4E(2) show a time-line communication flow of the embodiment shown in Figures 3 and 3A for a share message from the Owner to the AQU about an object owned by the owner.
Figures 5, 5A, and 5B show general forms of messages.
300, 400, 600, 700, 800, 810, 820 and 830 show generic messages and objects.
500, 520, 530, 540, 560 and 570 show specific returns related to various processes.
Figures 6(1 ) and 6(2) show an illustrative example of the use of this disclosure with the system shown in PCT patent application no.
Figures 7, 7A, 7B and 7C show screen shots of illustrative examples of an embodiment of this current disclosure.
Figure 8 is a high-level block diagram showing an example architecture of a mobile device.
Figure 9 is a front view of a mobile device suitable for processing. DETAILED DESCRIPTION
a general system will first be described to send any of these messages back and forth between Owner and AQU and to maintain the state of the message. (e.g. the recommendation was accepted).
This software/apparatus on the AQU side invokes a 'Has App' service to determine that the owner side does or does not have the application needed to receive the various messages. If the owner side does not have the application, the 'has app service' sends the owner handset a text message or other communication advising them to download the application so that they can see what the AQU side sent. If the owner is not capable of running this app, messages may be seen by the owner on a website.
Figure 1 shows the hardware components that make up the system described in this disclosure.
Figure 1 also references database tables. The relevant fields for these database tables needed to implement this disclosure.
Main path of communication The software/apparatus on the Acquaintance phone (“Aqu") (1 ) wishes to communicate about an object to the phone of the object's Owner (3).
Phone (1 ) sends a message to the messaging server 40 via internet 10.
Messaging server 40 houses processes 200 to 280, accepting parameters via API calls and returning values in the forms shown in 5, 5a and 5b.
Server 40 stores the message and waits for phone 3 to pick up the message.
Phone 3 will pick up these messages through a poll in a number of scenarios described below.
server 40 may send a notification to phone 3 via a notification service 50. This will cause phone 3 to immediately poll server 40 for messages. Response messages from phone 3 flow in a similar manner in the opposite direction. (Phone 3 to server, phone 1 poll or notification)
Has app service The disclosure requires that the AQU phone have the application needed to send messages about owned objects, but it is possible that the communication is initiated by AQU without the Owner phone having the app.
a 'has app' service 80 is used to determine if the app exists on the owner phone. This service is described in inventor's U.S. Provisional Patent Application No. 61 /663,479 filed June 22, 2012, and concurrently filed application, entitled, "METHOD FOR EXCHANGING FILES OR MESSAGES WHEN ONLY ONE SIDE OF A CALL HAS AN APPLICABLE SOFTWARE APPLICATION," inventor: Martin Gindi, attorney docket no. 82227.8003. US01 , filed , which is incorporated herein by reference in its entirety.
service 80 may send a text message or other communication to the owner phone (not covered in this disclosure). Whether the app exists on the owner phone or not the current system queues the messages on server 40 for pickup by the owner. If the Owner phone eventually downloads the app, that app will pick it up through polls when it is run. Alternately if Phone B is incapable of downloading the app (or the user decides not to get the app) the messages can be retrieved on the website 95.
Metadata authorities In supporting the owned objects in this disclosure, metadata related to the owned object may be needed from time to time. Additionally, new objects, such as recommendations and gifts may be needed.
the Catalog authority 90 and Collection authorities 96 provide object reference services and catalog search services. These authorities may be found locally or on a remote server. The remote server may be part of a cloud computing system. These authorities may require certain permissions to access them. These permissions may be granted by the Owner or through a third party. Permissions may be of varying levels where the owner or third party may grant access to the complete Catalog authority or a portion of it.
the Catalog Authority 90 is concerned with the metadata for single objects while the collection authority 96 is concerned with collection of objects (e.g., playlists or libraries containing a subset of the collection of objects).
authorities 90 and 96 provide RBT track # to metadata services and lists of RBTs owned by a specific customer, respectively. These metadata authorities are accessed from the messaging server 40. This access may be through internet 10, or direct. The direct connection is shown in figure 1 . Metadata Authorities provide APIs to server 40. These APIs are specific to the actual authority; there is a minimal set of semantics to be supported for the authority to work with this disclosure. Additionally these authorities may provide indirect (pass through) APIs to a payment service 92.
the minimal set of APIs needed for a Catalog authority include: 1 ) Object reference number to metadata. This API takes an object # used throughout this disclosure along with an optional phone number to request the metadata for this one object. 2) Catalog access: Abstract 'browsing' of the full catalog. Takes various search strings in, such as 'Rock' or 'the Beatles' and returns lists of objects. Each of these objects has metadata and an object # that can later be used to uniquely identify a particular object from the returned list. 3) pass through to payment service. Server 40 may request payment services for the catalog, e.g. buy a track. This is done by passing the API call through the catalog authority 90 to payment service 92.
the minimal set of APIs needed for a Collection Authority include: 1 ) Phone number based collections. This API provides collections based on a particular phone number. E.g. the RBT record for this owner. 2) Non-phone number based collections. This API provides collection based on abstract search values such as 'global play list' that are not related to a particular phone number 3) pass through to payment service. Server 40 may request payment services for the catalog, e.g. buy a collection. This is done by passing the API call through the collection authority 96 to payment service 92.
Payments The current disclosure includes a method for effecting payments in a gift or recommendation transaction. Payment may be effected on a third party payment platform (60) or to the owner of the catalog or collection billing mechanism, 92 through Catalog Authority 90 or Collection Authority 96.
System 60 is usually a credit card billing platform or a facility such as PayPal.
Payment system 92 may use credit cards, or if it has an arrangement (or is) the carrier, it may do direct to phone billing.
the system supports escrowed payments and chargebacks for gifts as well as direct charge payments. Charge and charge-back requests are sent from server 40 to third party payment platform 60 or from server 40 through Catalog Authority 90 or collection authority 96 to the payment service 92.
This disclosure supports access to many different Payment services each with its own unique syntax for an API request and response. There are however, certain broad requirements of supported API type that each connected service may provide.
the APIs specifically provided are dependent on business rules. These include: 1 ) immediate payment. Payment is charged immediately for the single object or collection being purchased. 2) Payment authorization. Payment is reserved for a single object or collection being purchased. The authorization is formalized at a later date and it may expire (or be canceled). 3) Payment reconciliation. Charge a previously authorized payment. 4) Cancel authorization. Cancel a previously authorized payment 5) refund. Return payment that had been completely charged.
Third party messaging server user The system supports a server calling the APIs available on messaging server 40.
This Third party messaging server user 70 may take the roll of the Owner phone (3) or AQU phone (1 ), that is it may send and receive messages.
An illustrative example of this is when server 70 is an advertisement server.
An AQU phone may send messages to the advertisement server, interacting with an advertisement RBT.
the server 70 may share lists of full tracks with an AQU.
Server 70 is connected to the internet. It may also receive notifications to pick up messages from server 40 via notification service 50.
the phone to carrier service 65 provides the phone carrier associated with a phone number to messaging server 40. This is used to determine which carrier is associated with a phone number which in turn is used to determine a catalog (90) or collection authority (96).
the system supports and will be adapted to specific APIs required by the phone to carrier service used.
the API will take as include a phone number and return a carrier name that can be used as an index into table 180 (column 185).
server 40 supports the service described in this disclosure. Certain tables are also shown for illustrative semantic purposes connected to catalog authority 90 or collection authority 96.
Object catalog (42 and 91 , table schema 100) is a local Catalog Authority. It stores cached values using the ordinal scheme in the authority table 180 as well as a local store of catalogs loaded in various methods. Authority entries in table 180 point to this table with a value of 'local-catalog' in column 183 and an authority # from column 181 . The value in 181 is then used as a search key for column 102, authority #. In this way, table 100 supports many catalog authorities in this table.
OBJ # (101 ) is a unique value for this catalog entry within the authority # column 102. It is used in conjunction with 102 to access this table. (And possibly in conjunction with the owner phone, (104)
Authority # (102) is an authority # referenced by table 180. Rows within this table that have the same authority # belong to one authority.
Metadata (103) is an abstract field that contains the metadata associated with this object. Metadata type is different for each type of object stored here. Often it is the same data cached here after an access to a remote catalog authority 90.
Owner phone (104) is an optional field to allow this row to be associated with a single owner represented by his or her phone number.
Abstract Match Values (105) are fields specific to the type of object that can be used to select a subset of object. This contains descriptions such as 'pop music' or 'on sale'.
FIG. 1 Illustrative examples in figure 2 for table 100 include:
OBJ # 100 the metadata for object 100 within the domain of authority #20004 (which in table 180 is the Verizon full track authority stored locally in this table 100. Track #100 is 'Love shack' and it is classified as 'pop music'
OBJ # 101 the metadata for object 101 is another track within the domain of authority #20004 (which in table 180 is the Verizon full track authority stored locally in this table 100. Track #101 is 'imagine' and it is classified as 'on sale'
Message state object (44, schema 120) records one instance of a message exchange about an object between two handsets. It is a stateful object. E.g. when AQU recommends a new RBT to replace the current RBT owned by Owner a record is created. As the owner accepts or rejects the recommendation, this record changes from 'recommended' to 'recommendation accepted'. A new message state object is created when a message between these two phones about this object of this type of message (rating/recommend/gift) does not exist. In this way, as an example, only one rating from one acquaintance for an object owned by owner may exist (as can only one recommendation).
Msg# (121 ) is a unique identifier for this message and is used to refer later to this message object.
Owner (122) and AQU (123) Phone are unique ownership keys used for accessing this object. On many handsets this is the telephone number of the phone. On other phones it is other unique numbers or strings such at email addresses. See the description on phone numbers below. Messages start out going from AQU to Owner but responses later can flow in the opposite direction. In various circumstances the Owner, AQU or both phone fields are used a key to access records.
Message type (124) may be a recommendation, rating, gift (object related), gift (not-object related) or a general message about an object or a share of objects.
OBJ# (125), OBJ class (128) and OBJ # Authority/type (129) constitute the object reference each of these fields along with access to this message state object is described below.
Mgs info (126) is an abstract field that is relevant to a message type. As an example it contains the new RBT recommended to replace the current RBT, or it may contain the rating. We will expand on the values in this field when we describe the flow of each message type
State (127) is a unique state for this message related to the message type. e.g. 'recommendation accepted' is a valid state of a recommendation. We will expand on the values in this field when we describe the flow of each message type.
Metadata cache (130) is an alternate means of caching metadata associated with this message.
a value of 'msg cache' in the object class e.g. 128 or 164 indicates that metadata for a message or collection is stored here.
Illustrative examples in figure 2 for table 120 include: we also include illustrative examples of the related sub-messages in table 140 here for completeness.
the recommendation to replace track 1000 is for object 1050 from authority 20000 (in the MSG Info field 126).
the sender can display this as a 'you sent xyz recommendation to 212 5551212 on Apr 7).
the next two sub-messages with MSG# 2000 are for the recommendation being accepted, the third message shows the 'recommend accpt' from 212-555-1212 to 212 444-1212.
THe fourth shows the ACK accept back to 212-555-121 2 that would show as 'you accepted' on their handset.
MSG # (column 121 ) 2001 : is a share of an owner's (212 555 1212) list of ringtones with 212 444 1212).
the Ringtones, (the ringtone itself and the title) were sent along with the share and are stored in the message and collection tables so that 212 444 1212 may pick up the message. If 212 444 1212 wishes to rate, recommend, gift or comment on this he or she may refer "my RTs" a reference value supplied by 212 555 121 when the share was sent and is stored in column 125.
the obj class (128) is 'included collection' to indicate that the collection was sent with the message, the type (129) agreed to by both parties is 'RT List'.
the list with its metadata is stored in the metadata cache 130.
the structure of this collection is stored in tables 160 and 170.
the structure is needed in addition to 130 so that individual items in the collection may be communicated about.
the title of the track is stored in the metadata column 172.
the individual members of this collection are in the first two entries of 160 with the same collection#(161 ), Type(162) and phone number(167) as the header, the two members of the collection have OBJ# (163) 1 and 2 respectively.
Column 164 indicates 'MSG Cache' to indicate that the metadata for these individual objects in the collection can be found in table 120, column 130.
the OBJ#, Authority or type column is 2001 , the message # in where this data may be found in table 120.
MSG # (column 121 ) 2002 shows a cached catalog item for a rating.
OBJ 102 for this new message (column 125) is actually contained in table 100 under this owner phone (212 666 1212), so the use of ordinal 1 from authority table 180 of authority 20000 would return a value and would not proceed to ordinal 2.
the rating for this OBJ #102 from 212 666 1212 is saved in the MSG info column 126. He rated it a '5' and said 'Perfect' (in the associated sub messages for MSG #2002, column 146.
the metadata for this profile is stored on a collection server at a carrier that services RBT profile requests.
'Global collection' in column 2003 indicates that the authority 20002 (129) should be contacted for metadata.
Table 180 for entry 20002 indicates that Verizon 2' (183) should be contacted with the API request (184) 'RBT- User-Profile'.
the associated submessages show 'My RBTs' was sent as the share comment (146).
the collection structure is stored in 160 and 170 after its first retrieval from the server, and the metadata is stored in the message itself, column 130.
the collection is called 'maryt's RBTs' in column 172.
RBT profile numbers 8005 and 8006 in column 163.
Columns 164 and 165 indicate where the metadata for each of these tracks can be found.
Sub-Message queue (45, schema 140) can be viewed as an extension of the message state object table (120) it records all state transitions along with text (146) that can be sent back and forth during the state transition of a message state object. Every exchange produces two entries in the table (144) one that is the forward direction of the message itself and one for an acknowledgement back to the originator. In this way a recommendation from AQU to owner would result in 'AQU sent you a recommendation' message on the Owner phone and a 'You send recommendation to Owner' on the AQU phone.
Sub-Message type (141 ) is a specific communication about this msg type, e.g. 'recommendation accepted'. It is calculated by each specific message type flow from the message type (124) and either the initial AQU->Owner action (200), or a later action by owner (260). The specific values for 141 are described in the sections devoted to each message type below. Unless stated otherwise it is the same value as 'state', column 127 in table 120.
ACK or Msg indicates if this is the message itself 'Msg' or the acknowledgement back to the originator (ACK)
Msg # (145) refers back to the message state object in table 120 and is the same value as the MSG # field (121 ) in that table.
Words (146) are the text words sent from AQU or Owner. For a rating it could be a comment on the RBT from AQU to owner. And later it can be a comment on the rating from the owner to AQU. In the Msg/ACK pair of entries saved for one exchange, the same text words are repeated in each of the two entries.
Date (147) is a timestamp for insertion of the record into the table.
Sent (148) indicates if the message has been successfully sent (picked up) by the destination.
Message disallowed (46, schema 150) is a so called 'spurned lover' block. An entry in this table disallows any message from 'from phone' to 'to phone'. If there is an entry in this table for a pair of phones and from phone attempts to send a message to phone it will be blocked.
Figure 2a shows an illustrative example of a block. Should phone 212 222 1212 try to send a message using this system to 212 555 1212 it would be blocked.
Collection headers (47 and 97, schema 170). Stores the metadata associated with a collection of objects.
Message state object table 120 contains a collection reference that matches the collection reference in this table. This table has corresponding objects in the collection members table 160. Those are the actual objects that are part of this collection.
Collection OBJ# (171 ) contains a unique Object number within the domain of authority or type column 174 and owner's phone 173 (i.e. Collection OBJ# 171 need not be unique within 170, however it may be unique within all other entries in table 170 that have a particular value for 174 and owner's phone 173)
Collection Authority or type (174) specifies a domain for the collection object 171 . If the value is an authority it may be equal to a value in table 180. If the value is a type it is unique to the owner's phone (i.e. the owner's phone species this value).
Metadata (172) contains the metadata for this collection. I.e. the description of the collection itself. Note this is an abstract field and may contain various values such as artist name etc.
the metadata itself contains a 'type', (e.g. RBT list).
Owner's phone (173) the phone number of the owner of this collection.
Columns 171 , 174 and 173 collectively are the collection reference and may match the collection references in table message state object table 120 and the collection members table 160
Collection members (48 and 98, schema 160). Stores the members of a collection referred to by the collection header table 170.
the collection reference; columns 161 (Collection OBJ #), 162 (Collection Authority or Type) and 166 (Owner's phone) may match the collection reference in the collection header table 170. All items with the same collection reference in this table belong to one collection.
Columns 163 (OBJ #), 164 (object Class) and 165 (Object Authority or Type) contain the object reference for this member of the collection. Together with column 166 (the owner's phone) this is the unique identifier that the AQU and Owner phone's use to identify an object.
Object references are covered in detail below in 'owned objects and their metadata'. They refer to an object either in a catalog authority or on the owner's phone.
Authority (49, Schema 180) the authority table defines a domain of global objects and where it is stored. This table is used to access Catalog Authority 90, Collection Authorities 96 as well as local variations of these two in tables 42, 47 and 48. Each entry in the Authority table may be a unique. This unique value then forms part of an object or collection reference. Object and collection references are described in detail below.
Authority (181 ) is a value in this table that may be a number of strings. It specifies the domain to which an OBJ# or Collection # belongs. If there is only a primary metadata source this value is unique. If the 'alternate ordinal system' below is used all records for the multiple data sources may be the same, however they may be unique within the set of other authorities.
Type (182) is a value agreed upon by AQU and Owner to specify the type of Object supported by this authority (e.g. RBT, Ringtone, or 'user's RBT Profile'). It is unique within the domain of the catalog name (unique within a particular value of column 183)
Catalog/Collection Name is a name for this catalog or collection, e.g. Verizon, Amazon.com.
Server (183) is the address of the remote Catalog or Collection authority. This may contain the special values of 'local Catalog' or 'local collection' in which case access is made to tables 100, 160 and 170.
API Command (184) is an abstract field that defines a set of access parameters for various API calls to a remote catalog or collection authority. (E.g. retrieve metadata via these parameters or retrieve the user's RBT profile (collection) in this way). API's expected of authorities are described below.
Figure 2 shows illustrative examples of rows in table 180.
Authority # (181 ) 20002 shows a remote collection authority to access the metadata for a user's RBT profile. That profile would contain the collection of RBTs on this line.
the type (182) is 'RBT-user' and the authority name (185) is 'Verizon'.
Server (183) 'Verizon-2' is accessed and the abstract command sent asks for 'RBT-User-Profile'.
Authority # (181 ) 20003 shows a commercially available, via API, full track catalog authority. In this illustrative example it is 'Amazon.com'.
the type (182) is 'full track' and the authority name (185) is 'Amazon.com'.
Server (183) 'Amazon-1 ' is accessed and the abstract command (184) allows for a set of 'full catalog' queries.
the type (182) is 'full track' and the authority name (185) is 'Verizon'.
the current disclosure concerns the exchange of messages about an object owned by the user of the 'owner phone'.
the object itself consists of this actual object along with descriptive metadata or pointers to metadata.
An owned object may be 1 ) a reference to an object in a globally available catalog, 2) a reference to an object on or related to the owner's phone, 3) a collection of objects that could consist of an arbitrary collection of catalog and phone local objects.
each reference starts out by indicating which of these three object reference classes should be used.
800, 810, 820 and 830 show the format of each type of reference.
Process (200) shows the message being sent from the AQU about an object owned by owner to the owner.
(245) shows the retrieval of messages between the AQU and Owner by the AQU.
230 shows the retrieval of messages between the AQU and Owner by the owner.
240 shows the retrieval of messages when the owner accesses the object.
250 retrieval of all messages to a particular phone that also includes the acknowledgement of messages sent.
260 shows the action and/or action message sent by the owner as a reply to the original message by AQU.
(270) shows the access when the owner access all of the objects they own.
(280) shows the access to retrieve an object catalog.
(290) shows accesses to the system from a website when one party in the call does not have an associated software/apparatus.
Objects often have metadata associated with it.
a track name, an album image, or indeed, the object being referenced can contain the actual object. (E.g. the photo being shared).
the current disclosure describes various methods to obtain this metadata if it is needed.
Metadata may be stored at the time that a message is created via process 200. Metadata may be retrieved through any process 230 through 270 if the receiver requests metadata and it was either stored during a 200 or is accessible through a global catalog as described below. Additionally, retrievals through the global catalog may be cached for later use.
Metadata is stored either within a message in table 120, column 130, or in a table in Object catalog 100 that is either local to server 40, or is available via API from a catalog authority 90.
Authority table 180 defines the method of access to this catalog authority.
the user would supply an object# that is relevant to the authority along with either an authority code (defined below) matching column 181 or a catalog name/type pair matching columns 185 and 182 respectively.
the catalog name may be derived from 'phone number to carrier service' 65.
column 185 would be a carrier name and would match the value returned from 65.
the server, column 183 may be an actual server address or it may indicate that the local table 100 on server 40 be used.
an access to the local table 100 uses the passed object # and the retrieved authority from column 181 to search for an object matching columns 101 and 102 respectively. This action retrieves the metadata in column 103.
the owner's phone may also be used as a key to accessing this table.
optional column 104 may also match the owner phone.
server column 183 is a remote server
the metadata is available through API at a remote catalog authority.
the API should support, at a minimum, the functionality described herein.
the API commands are stored in abstract form in column 184. Except for 'authority code' (column 102), the same values used to access the local table 100 are passed to the API. Metadata for the requested object is returned from the remote Catalog Authority.
This disclosure also supports alternate locations to access and resolve metadata should a primary metadata source not contain the requested information.
the 'ordinal' column 186 is used.
This ordinal system may be used for a caching scheme, data retrieved (or inserted offline) from a remote catalog authority may be stored in table 100.
a cache check may be made by having ordinal 1 pointing to table 100 and ordinal 2 pointing to the same metadata on a remote authority. If data is cached in 100 it is returned first. If it is not, it retrieves it from the remote authority of ordinal 2. The retrieval using ordinal 2 may then, if business rules allow, store this value in table 100. The next access then would retrieve the cached value from table 100. Additionally the table may be populated by some offline process not covered in this disclosure.
the global catalog may also be accessed through process 280 to retrieve various lists of objects that contain metadata.
Table 100s that reside on remote catalog authority 90s may take abstract match values 105 to retrieve lists of objects that are of interest. If table 100 resides on sever 40, abstract match values may be used along with a filter on authority column 102 and, by use of a join with table 180 on the authority code, may be used to filter via catalog name (column 185) and object type (e.g. RBT) column 182.
the owner's phone # may also be used to match optional column 104. That would provide a way of storing catalogs relevant to a particular customer (phone # owner). b) Owned object references
Object reference form A phone's owner may own an instance of an object from a catalog that is globally known. In this instance globally means that both the AQU and Owner can access this catalog if needed.
RBT Ringback tone
the AQU phone may comment on the owner's choice of let it be' by passing '9992' as the owned object reference.
any reference to a global catalog value is in the form of 800: 801 , object reference class value is set to 'global catalog', 802, Object # is a number or string that is a unique identifier of the requested object within the domain supported by the catalog authority.
the Object # relevance field, 803 may be either an object authority number 804 that is the same as a value in authority table 180 or it may be catalog name/type pair in fields 805 and 806.
Catalog Name is a string that matches some catalog authority (e.g. Amazon.com or Verizon) and type is one of the types objects for which messages may be exchanged (e.g. RBT, Ringtone, Photos etc.).
Processes 230, 240, 245 and 260 the processes that retrieve messages based on phone numbers and references to specific objects are passed these same references to global catalog objects as was used to store the message about the object in the form of 800.
the two phone numbers, the OBJ# 802, the OBJ class 801 (which is set to global catalog objects and either the Authority # 804 or catalog name (catalog)/object type #805 and 806 are used to retrieve the message.
catalog name (catalog)/object type values been passed, they are normalized with table 180 to an Authority #.
Authority #, OBJ # and phone numbers are used to access all messages related to this object.
Process 270 the 'owned object' query, operates in two separate modes: 'return all objects for which there are messages' and 'collection of objects' mode.
the 'collection of objects' mode is more relevantly understood in the context of 'collection lists' below.
the list of messages for a 'return all objects that have messages' is passed just the 'owner phone' (i.e. it does not use object passing form 800).
Process 270 starts off by returning all messages in message table 120 that match 'owner phone' (column 122). This list may contain messages of all Object Classes. Depending on business rules and the class of their object references, these returned messages may further collect their metadata.
Metadata The global catalog class of objects supports a number of variations. Business rules allow for any of or none of the variations to be used to store or obtain metadata related to a particular exchange. These business rules my effect the actual embodiment of these processes (i.e. only one variation is available in the software/apparatus) or they may be embodied as request values within the values passed to the processes (e.g. ⁇ don't need metadata for this call) [00118] There are two broad variations, first, 'no metadata' is needed when messages are accessed and second, if metadata is needed it may be returned from the global catalog authority (local or remote) or it may be retrieved from within the stored message.
Metadata is needed on a returned message, once the message has been retrieved from table 120, processes 230 through 270 checks to see if metadata is stored in column 130. If it is, that data is returned as the metadata for the object associated with this message. If metadata is not stored there, columns 125, 128 and 129, the Object # and its class/authority, and possibly the owner's phone 122, are used to retrieve the needed metadata from the local or remote Catalog Authority as described above with the general discussion on metadata.
Metadata may be stored in table 120 column 130 in one of two variations. Business rules and possibly run-time flags determine which of any of these storage methods are employed.
process 200 when process 200 is used to initiate a message about object exchange, metadata may be included in the values passed to process 200 and it is then stored in 120.
the metadata needed for processes 230 thorough 270 is cached in message table 120 when it is retrieved from the local or global catalog authority.
process 200 while it does not return metadata, may be instructed to retrieve metadata and cache it. ii) Owned Object references object local to the phone
Object reference form A phone's owner may own an object on this phone. As illustrative examples, a ringtone, a full track, a photo or video taken. This disclosure allows these objects to be shared (and/or a metadata description of these objects to be shared) and then allow an acquaintance send messages related to this object.
the defining characteristic of these types of objects is that they are not at least easily referred to in a shared global catalog as above.
a photo taken on a phone would not be available (unless uploaded to a sharing site in which case that would be considered a global catalog authority) in a global catalog
the song 'let it be' may be stored on this phone and in-fact be available as a global catalog, however, in some circumstances only the track's title and artist are stored and any reference to where the song was purchased is lost.
a common global catalog is not known for certain so it is now considered an object local to this phone.
'OBJ #' some sort of unique identifier represented by 'OBJ #' be used when the AQU (and later the Owner) refer to messages about this object.
any reference to a local object is in the form of 810: 81 1 , object reference class value is set to 'local object', 812, Object # is a number or string that is a unique identifier of the requested object within the domain of the included object type. 813 is this object type. It is an arbitrary value agreed to by both sides of a message exchange.
Process 270 behaves the same as described above with 'global authority' values.
Metadata The nature of local objects requires that any metadata be provided, if it is provided at all, by the local phone, as there is no central, global authority to supply this data. There are a number of variations to this metadata. Business rules allow for any of or none of the variations to be used to store or obtain metadata related to a particular exchange. These business rules my effect the actual embodiment of these processes (i.e. only one variation is available in the software/apparatus) or they may be embodied as request values within the values passed to the processes (e.g. ⁇ don't need metadata for this call)
Metadata may be stored in table 120 column 130. Business rules and possibly run-time flags determine if the data is stored, when process 200 is used to initiate a message about object exchange, metadata may be included in the values passed to process 200 and it is then stored in 120 iii) Collections of objects
Object reference form The current disclosure supports a collection of objects. Messages may be sent referring to the collection as a whole, or messages may be sent that refer to individual objects within the collection. Objects within the collection may be global catalog objects, local objects, or indeed, other catalogs. These collections may exist on the owner phone or at some central collection authority
the collection itself has a collection reference.
This collection reference may be to a list accessible through a 'collection authority' or it may be a list local to the owner's phone. In this way a collection is equivalent to both a 'global catalog' and 'object local to a phone' above. For a collection both of these have distinct collection references.
a collection authority 96 exists to provide information for a collection. This authority takes possibly some collection reference and/or possibly the owner's phone number to provide the actual members of a collection. As an illustrative example, the authority may be the owner's carrier RBT record server. This RBT would use the phone number as the only search criteria to return the complete collections of RBTs that this user owns.
Input form 820 is used to refer to a collection on a collection authority: 821 , object reference class value is set to 'collection authority', 802, Object # is a number or string that is a unique identifier of the requested object within the domain supported by the collection authority.
the Object # relevance field, 823 may be either an object authority number 824 that is the same as a value in authority table 180 or it may be catalog name/type pair in fields 825 and 826.
Collection Name is a string that matches some catalog authority (e.g. Amazon.com or Verizon) and type is one of the types objects for which messages may be exchanged (e.g. 'RBT profile' or 'drop box photo folder'.).
the reference to a local collection is similar to a 'local object' reference above except that it may contain the actual collection.
Form 830 is used for a local catalog reference: 831 , object reference class value is set to 'local collection, 832, Object # is a number or string that is a unique identifier of the collection within the domain of the included object type. 833 is this object type. It is an arbitrary value agreed to by both sides of a message exchange.
834 is the collection itself and is a container type 700 object that has the metadata for the collection itself, e.g. its name, along with a set of objects 900 (without messages 300, i.e. just object info fields 400).
[00142] Store/retrieval of messages about these objects.
the current disclosure allows for messages to be sent referencing the whole collection (e.g. ⁇ like your playlist') or messages about individual objects within the collection. Messages sent for the whole collection use the collection reference. Messages sent for individual objects use the individual object's reference. If the user retrieves messages with the collection reference they would see the messages about the collection and messages related to any constituent objects. They may also retrieve the individual object messages using the object reference. (This would only give messages related to the individual object and not the collection as a whole. This requires server 40, the location where messages are stored to keep a copy of the collection structure as part of message storage.
the retriever may only have the collection reference and the only way he can retrieve the individual messages is through reference to the collection, (e.g. a message is sent about one object in the collection using the object reference, the receiver would reference the collection, the only way to now retrieve this message is to know that the object is part of a collection)
both catalog authority and local collection messages store the message exactly as described above with global catalog and local references for storing in table 120 with the collection references stored in that table.
the additional step of storing the collection is needed in both cases.
the collection is stored in tables local to server 40.
the container header is stored in table 170.
the container metadata, retrieved from the collection authority or in field 834 is stored in 172.
the collection object # is stored in 171 and the collection authority or the local type is store in 174.
the owner phone is stored in 173.
all constituent objects are stored in 160.
Columns 161 and 162 are the same values stored in 171 and 174 respectively.
Column 162 is the OBJ # of the constituent object and 163 is the Catalog authority or local type stored of the OBJ #.
One record is made for each constituent object.
Process 230, 240, 245 and 260 as used to access individual objects from the collection work exactly in the manner as described above for global catalog and local phone message access.
the messages associated with the overall collection use these same techniques. After the messages for the collection are retrieved, these processes iterate over all messages in the collection to see if messages exist for the members of the collection: the collection #, collection authority and owner phone are used with a join operation between tables 170 and 160 to extract all the objects within this collection, obtaining a list of object #s and authority /types from column 162 and 164. Each of the items in this list then accesses the message table 120 as described for global authority or local objects, collecting all messages associated with any object in the collection that have messages (some or none of the objects in the collection may have any messages)
Process 270 has two distinct modes: in one mode, the system returns all objects for this owner phone that have messages, in the other, the user provides a collection and wishes to get all messages associated with the collection
process 270 is passed a collection in the form of 900 without any message 300 values (i.e. just a list of objects).
Metadata There are two parts to metadata within a collection. First, there is the metadata for the collection itself, second each constituent object within the collection has metadata.
the metadata for constituent objects is exactly as described above with metadata for global catalog objects and local objects. As described there the metadata may or may not be required or stored.
Sub-Message 600 Single sub-message 600 is a composite of one sub- message from table 140 and one associated message state object in 120. Access to these two records start with either: 1 ) a search of the sub-message table 140 using various search criteria. This first returns a sub-message. Msg #, from the retrieved column 145 is then used to search column 121 of table 120 to obtain a message state object 2) a search on table 120 using owned OBJ (125), AQU phone (123) and/or Owner Phone (122) obtains a message state object. . Msg #, from the retrieved column 121 is then used to search column 145 of table 140 to obtain a sub-message.
a message queue reference to table (140) and a message state object table (120) we can assemble a general message for 600: 1 ) from/to phone 601 contains the from/to phones in 142 and 143. 2) Sub-Msg type 602 contains sub-msg type 141 , 3) text 603 contains words 146. 4) Date 604 is the date 147. 5) Direction 605 is msg or ACK 144. 6) OBJ reference 606 is the owned object reference of type 800, 810, 820 or 830 as described with object references above.
State 606 is the state of the message exchange 127
Messages about an object 300 may contain all the messages and sub- messages of all message types associated with an owned object.
Form 300 is part of a bigger return value that also contains information about the object (400).
Form 300 contains zero or more ratings (320), gift (330), recommendation (310), general notes (340) and share message (350) messages about this object. It may contain messages involving one pair for AQU and Owner or it may contain a list of messages from many places. As an example it can have all of the individual ratings on an RBT owner's phone for a particular RBT from many AQUs.
a form 300 has zero or more of the following sections depending on whether or not there are any Message About Objects of that type for the associated object. These sections include: recommendations (310), Ratings (320), Gifts (330), general notes (340) and share message (350). Each section may be empty if there are no messages. Conversely if there are any messages of a particular type associated with an object they are grouped into a list of messages here.
[00160] 1 ) from/to phone 312 is collected from table (120) Owner Phone (122) and AQU Phone (123). 2)
the list of sub-messages contains one or more sub-messages 600 associated with the Message About Object message. This is set of messages from the message queue (140) with the same MSG # (145) as that of 121 from the message state object (120). 3) The retrieved MSG # field is collected from column 121
Section 310 of the message about OBJ (300) contains a list of recommendation items 31 1 .
a recommendation item 31 1 contains: 1 ) State 313 comes from state 126, 2)
New OBJ 314 contains an object reference to a new object in the form of 800, 810, 820 or 830 as described above in the Object Reference section. E.g. a new RBT that is recommended as a replacement for this object.
Section 320 of the message about OBJ (300) contains a list of rating items 321 .
a rating item 321 contains: 1 ) State 323 comes from state 126, 2) Rating 324 is obtained from the abstract message into field 126 and is the rating value that AQU rates this owned object e.g. a rating of 4 on a 0 to 5 scale.
Section 330 of the message about OBJ (300) contains a list of gift items 331 to replace this owned object.
a gift item 331 contains: 1 ) State 333 comes from state 126, 2) gift OBJ 334 contains an object reference to a gift object in the form of 800, 810, 820 or 830 as described above in the Object Reference section, e.g. 'here is a new RBT that I've paid for already to replace the RBT you currently play.
Section 340 of the message about OBJ (300) contains simple note message about this owned object. It only contains the three general fields just described.
Section 350 of the message about OBJ (300) contains a share message. It only contains the three general fields just described.
Object info 400 contains an object reference, its metadata, and ownership information. It is used to both send Object information to the procedures 200 through 280 and to pass return values from these procedures. The fields may be populated with the information shown in 400.
An object and its metadata are in 401 and 403.
an owned Object reference of type 800, 810, 820 or 830 is put in 401 and metadata is put into 403 as per the discussion of owned objects and their metadata above. If data is being returned, the metadata in 403 uses the metadata retrieval mechanisms described above.
Field 402 the OBJ type is obtained on a retrieval of the message state object from 120. Column 129, OBJ # Authority or type is used to determine this. If the column indicates 'type' then this type is set in field 402. Otherwise a join operation is performed with table 180 using the authority # in 129 to access that table to retrieve column 182, the type associated with this authority.
the Owner Phone field, 405 is set from the retrieved message state object, 120, column 122.
OBJ and its messages 900 is a composite form that contains an object info form (400) along with all of its associated messages in the form of 300.
the specific return forms 500, 520 and 540 from procedures 200 through 270 contain form 900s. Additionally, the container form 700 contains a list of 900s.
Container for Collection is a list of object info forms 400 and metadata that describes the collection as a whole. It is used to send and receive collections that are included in messages. It is included in the description of form 830, 'collection included'.
Field 701 contains the metadata description of the collection. As an illustrative example: 'Marty's RBTs'. When a form 700 is returned (as opposed to being used as input) field 701 is populated from the collection header table 170, the 'metadata' field 172.
Fields 702 through 703 contain the individual objects of the collection.
a form 700 When a form 700 is returned it is populated with the objects of this collection stored in the Collection Members table 160.
Each individual item retrieved from 160 and stored in 702 through 703 are on the form of a 400. Please see the description of form 400 above for more information.
'Phone Number' has been used throughout this disclosure to mean either a number within the global dialing plan or a private string or binary digits used for addressing.
this number is characterized as a string of digits and certain special characters such as '+', ' * ' or '#' that allow a phone user to place a phone call to another land line or mobile phone throughout the world.
a private string or binary digits it can be, illustratively, any random collection of characters such as an email address or string of hex digits.
This number may also be a special coded address special to a notification system 50.
the phone number supported by this disclosure may be any private string or binary digits agreed to on both the AQU and Owner phones.
An illustrative example is an email address or social network screen name. Sending, routing and pick-up of messages with processes 200 through 280 and the database structure allow for any agreed upon value.
the owner phone number may specify that the owner is a third party advertising server 70. This server may send and pick up messages using processes 200 through 270. This 'phone number' may be a string such as 'Pepsi ad campaign'.
these circumstances include the use of the global dial plan as a mean of identifying the AQU and Owner (e.g. by use of the phone's address book to assign a name to a global dialing plan number). It may also include integration with 'what I heard'.
catalog relevance values in tables 1 10 and 120 in the current disclosure encode a 'type' value which is used as a key to accessing table 160 in the 'what I heard' disclosure.
all 'phone number' values in this disclosure are expanded to include a 'phone number type' (e.g. column 122 and 123 in the current disclosure are expanded to include a 'phone number type' that can be used to match column 163 in the 'what I heard' disclosure')
the process defined in 200 is the start of any message exchange.
AQU sends a message related to an object owned by the owner to the owner.
the initial handle to the object could for instance be the 'What I heard' RBT discovered or the ringtone played on the owner phone when the acquaintance calls or it may be an object previously shared via a 'share' message using 200.
process 200 when process 200 is used to share objects (i.e. send a 'share message' as defined below) the message goes from Owner to AQU instead of AQU to Owner.
step 201 There are 6 values passed in step 201 . Let's call each of these 201 -1 , 201 -2, 201 -3, 201 -4, 201 -5 and 201 -6. Each of are needed to start message processing for process 200.
201 -1 contains the AQU phone. Except in the case of a share message this is the phone number the side initiating the message. For a share message this is the destination of the message.
201 -2 contains the phone number for the Owner phone which is, except for a share message, the destination for these messages. If this is a share message it is the originator of the message
[00191] 201 -3 is an optional text note to be delivered with this phone.
201 -4 is a reference to the object owned by the owner. It is in the form of an object reference to a global catalog, local catalog or collection. The object itself along with its metadata may also be included here. See the section above describing object references and their metadata along with the descriptions above of the format of references for each object class. The system supports a non-object related gift. In this case only 201 -4 would be blank.
[00193] 201 -5 contains the type of message to send: recommendation, rating, gift, share or general message.
201 -6 is message type related data that will be described with each message type below.
the information 201 -1 , 201 -2, 201 -3 201 -4, 201 -5 and 201 -6 are sent via internet 10 to server 40 where it is further processed.
step 202 Upon receiving the message server 40 step 202 is performed. This step uses 201 -1 and 201 -2 to access table 150 with 201 -1 being used as a key for column 151 and 201 -2 used as a key for column 152. If there is a match the message is disallowed and a return value of 'disallowed' is returned to the handset in step 203.
the 'has app' service in step 204 and shown in 80 is used to check if phone 201 -2 has the companion app to ours and is thus capable of receiving the message we are about to send.
the service 80 takes as input the source and destination phone numbers 201 -1 and 201 -2. It also takes a web URL that is used to direct the owner to a website should the owner phone be incapable of installing this app. The service will not be asked to send a queue or send a message payload on our behalf but rather to simply perform the check and calculate actions associated with the has app check (which may result in text or other communications but will not have the actual message (e.g. recommendation) we are sending.)
the web URL contains information to allow the display of a web page with parameters that will allow the owner to retrieve this current messages sent by the AQU from the website.
the URL points to website 95.
This URL contains, 1 ) Object Reference, 2)Owner Phone, 3) AQU phone and 4) whether message was sent to Owner or AQU. Further it may contain the name of the Owner as stored in the address book on the AQU phone. Process 290 below will describe what happens when the owner visits this page and how it accesses the messages.
the has app service 80 will be configured to 1 ) send text messages to Owners phones who's device type can have our app but do not currently have it and can receive text messages, with a pointer to the appropriate app store for that device. 2) Send a text message to Owners phones whose device do not have our app but can receive text message with the web URL above. 3) Send a Facebook, twitter or similar post if the Owner does not support text messages and a Facebook, twitter or similar post address is available in the contact list on the AQU phone. In this case the web URL above is included in the post.
the 'has app' 80 system will set up to indicate that 'notifications' on device types that allow and support notification.
Has app service 80 will return the following to step 204. 1 ) Remote has app already, and if so whether it supports notification. Let us call this return value 80-1 with notification bit 2) does not have app but the service 80 has in some way notified the owner of phone Owner that a message is waiting. Let us call this return value 80- 2. 3) There is no way of getting a message to Owner. Let us call this return value 80- 3.
step 205 if return value was 80-3, process 200 returns 'message not sent' via step 206, otherwise process 200 continues to step 207
Step 207 processes payment now for a gift.
Message type gift to replace object or gift that doesn't replace anything.
the system supports two types of payments. A charge now with a chargeback if the Owner rejects the gift or a payment authorization scheme where the payment organization authorizes payment now but does not actually charge until the payment is put through at a later date. In the latter case, business decisions dictate the action to be taken if the pre-authorization expires. Options include: 1 ) submitting the charge again (and allow for charge failure) or 2) to disallow the gift (i.e. expire the gift itself.
payments are sent to the third party payment service 60 or directly to the catalog or collection's payment service 92 via authorities 90 or 96.
processing Upon payment failure as detected in 208 processing returns to the AQU phone that system payment failed in step 209. Otherwise processing continues to step 210.
Appropriate sales info such as authorization number or potential chargeback codes and account numbers are saved in the abstract message type field (127) in table 120 in this step.
a new row is inserted in to table 120 in step 210 with the following values: 1 ) Msg # (121 ) is inserted as the incremented by one value 121 of the last insert into 120. 2) Owner phone 122 is the passed value 201 -2; 3) AQU Phone 123 is the passed value 201 -3. 4) Msg type 124 is the passed msg type 201 -5. 5) The passed Object reference in 201 -4 is saved in OBJ # (125), OBJ Class (128) and Object Authority or Type (129) as above in the Owned Objects and their metadata section; 6) Msg Info 126 is the abstract data appropriate for this message type as passed in 201 -6.
State 127 is the appropriate initial state for this msg type (or payment status for a gift) and is described below when individual messages are described. If a record exists with the same values for all of the fields Owner Phone (122), AQU Phone (123), msg type (124), Owned Obj # (125), Obj Class (128) and OBJ Authority or type (129) already exists, the record is replaced with this new message using the same message # (121 ). As an illustrative example, this allows the AQU to change his or her recommendation or Rating. In another embodiment, and dependant on business rules, the replacement of the record may result in an 'already exists' error. In any case processing continues at step 213.
From-Phone is set to 201 -2, the Owner phone, 3) To-Phone is set to the Owner Phone passed in 201 -2 if this is not a share message. If this is a share message it is set to 201 -1 , the AQU phone 4) ACK or Msg (144) is set to "Msg". 5) Msg# is the new sequential number returned on the insert in step 210 into 120, column 121 . 6) Words (145) are the words to send to the passed in 201 -3, 7) date (147) is the current timestamp (i.e. right now). 8) Sent bit (148) is set to "no".
Step 214 queues an acknowledgement sub message indicating that the message was sent back to source phone.
a record is inserted into the message queue (140) with the following values: 1 )
Sub-Msg Type (141 ) is the same as calculated in step 213.
From-Phone (142) is set to the Owner Phone passed in 201 - 2 if this is not a share message. If it is a share message it is set to 201 -1 , the AQU phone, 3) To-Phone is set to the AQU Phone passed in 201 -1 if this is not a share message. If it is a share message it is set to 201 -2, the Owner phone. 4) ACK or Msg (144) is set to "Ack".
Msg# is the new sequential number returned on the insert in step 210 into 123, column 121 .
Words (145) are the words to send to the passed in 201 -3, 7) date (147) is the current timestamp (i.e. right now). 8) Sent bit (148) is set to "no".
Step 218 stores the collection structure if a collection had been sent.
the store operation is as per the description of collection structure in the collection description above.
Step 215 the 'notification bit' if it was set on a 'remote has app' return in step 204 is used to determine if the destination should get a notification that there is a message waiting to be picked up and should therefore do an immediate poll. (Or to allow the remote to pick it up on the next poll of the server) (251 or 252). If this is not a share message the destination is the Owner phone. If it is a share, the destination is the AQU phone. Additionally, the Third Party Messaging Server user (70) may request notification to be sent. The notification is sent in step 216. The notification service 50 is called to send the notification. It is up to this service to determine the method of notification.
Step 217 returns success to the caller of process 200. This success is sent to the AQU handset from the server 40 if this had not been a share message. If this had been a share message, step 217 would return OK to the Owner phone.
Process 245 allows the AQU phone to access all messages that were sent to owner about this object such as 'you recommended X instead of Y to owner, on date Z.
the recommendation hasn't been accepted yet by him'.
the result of this process may be a list of one each of each message type, so in addition to the recommendation above you may get 'you rated it a 2 saying 'not very good' on date x, owner responded 'oh you can do better than that'.
Process 245 shows messages originated from Owner to AQU. The only message that fits into this category in this disclosure is a share message.
Step 246 assembles three values on AQU phone 1 and then sends them to the server 40 via internet 10. These values include: 1 ) The AQU phone number, let us call it 245-1 , 2) the Owner phone, let us call it 245-2 and 3) a reference to the owned object, let us call it 245-3. It is in the form of an object reference to a global catalog, local catalog or collection. See the section above describing object references and their metadata along with the descriptions above of the format of references for each object class.
Step 247 retrieves all AQU to owner messages.
AQU phone number 245- 1 , Owner phone number 245-2 and the owned object reference in 245-3 are then used to search for messages as described above in the various owned object Store/Retrieval of messages about these objects sections. These retrievals also return metadata as needed.
This search will then produce up to one each of each Msg type, i.e. a rating, recommendation, gift or general message that includes such message types that AQU sent to Owner (with possible response sub messages in each) about this object.
Step 249 of process 245 then retrieves messages that are unassociated with any object sent by AQU to owner. Illustratively this is the case with a gift message unrelated to an object.
the message or messages thus retrieved (if any) is used to populate 503 in the form of a message about obj 300 (and 600).
the values stored in 300 and 600 are described above.
Step 249a of process 245 then retrieves share message that was sent by the Owner to this AQU. It should be noted that these are messages sent to AQU as opposed to from AQU as is the case for the rest of process 245.
the message or messages thus retrieved (if any) is used to populate 504 in the form of a share message (or messages) 350 (and 600).
the values stored in 350 and 600 are described above.
Step 248 produces an AQU Access Object 500 that consists of Obj and its messages of type 900 as described above.
Constituent field 901 in the form of 400 is filled as described above with the access to the owned obj.
Constituent field 902 is in the form of 300, message about object. It is filled in with the retrieved message types and their associated sub messages of type 600. The form and values in 300, 400 and 600 are described above.
Step 248 of process 245 then returns the values 500 to the handset 1 (Aqu)
Process 230 allows the Owner phone to access all messages (rating, recommendation, gift and general message) that were sent from AQU about this object such as 'Your friend 'aqu' recommended X instead of Y to you, on date Z. You have not as yet accepted his recommendation.
This process 230 also contains all messages from any AQU to the owner about the owned object so that owner can see what all of his friends may have recommended and select from one of them.
This process also contains an aggregate rating which is the simple average of all ratings from all AQU. Also, this process returns gifts from this AQU to owner unassociated to any object.
Step 231 assembles three values on Owner phone 3 and then sends them to the server 40 via internet 10. These values include: 1 ) The AQU phone number, let us call it 230-1 , 2) the Owner phone, let us call it 230-2 and a 3) reference to the owned object, let us call it 230-3. It is in the form of an object reference to a global catalog, local catalog or collection. See the section above describing object references and their metadata along with the descriptions above of the format of references for each object class.
Step 232 retrieves all AQU to owner messages.
AQU phone number 230- 1 , Owner phone number 230-2 and the owned object reference in 230-3 are then used to search for messages as described above in the various owned object Store/Retrieval of messages about these objects sections. These retrievals also return metadata as needed.
This search will then produce up to one each of each Msg type, i.e. a rating, recommendation, gift or general message that includes such message types that AQU sent to Owner (with possible response sub messages in each) about this object.
230-3 is used as a search parameter to the object owner table 43(1 10) with a match on column 1 1 1 to obtain a reference to the owned object.
Constituent field 901 in the form of 400 is filled as described above with the access to the owned obj.
Constituent field 902 is in the form of 300, message about object. It is filled in with the retrieved message types and their associated sub messages of type 600. The form and values in 300, 400 and 600 are described above.
Step 234 aggregates information. In this case it computes the average rating.
Step 235 of process 230 then retrieves messages that are unassociated with any object sent by AQU to owner. Illustratively this is the case with a gift message unrelated to an object.
the message or messages thus retrieved (if any) is used to populate 525 in the form of a message about obj 300 (and 600).
the values stored in 300 and 600 are described above.
Step 236 then returns all the values in 520 to handset 3.
Process 240 allows the Owner phone to access an object he owns. This access returns the information about this object along with all messages about this object from any AQU. For instance he can see all the ratings sent from all AQU's when he is interested in looking at the owned object. This process also contains an aggregate rating which is the simple average of all ratings from all AQU.
Step 241 assembles two values on owner phone 3 and then sends them to the server 40 via internet 10. These values include: 1 ) The Owner phone number, let us call it 240-1 and 2) a reference to the owned object, let us call it 240-2. It is in the form of an object reference to a global catalog, local catalog or collection. See the section above describing object references and their metadata along with the descriptions above of the format of references for each object class.
Step 242 retrieves all messages associated with the object regardless of who sent them.
Owner phone number 240-1 and the owned object reference in 240-2 are then used to search for messages as described above in the various owned object Store/Retrieval of messages about these objects sections. These retrievals also return metadata as needed.
the Object returned (one of them is used since all the retrieved messages are about the same object) is used to populate the Object info field 531 of type 400 as described above with the access to the owned obj.
Field 532 is filled in with all the retrieved message types and their associated sub messages of type 600. The form and values in 300, 400 and 600 are described above.
Step 243 aggregates this data. In this case it computes the average rating.
the individual ratings from each of these messages are added together and then a floating point divide is performed on this sum by the number of message retrieved, producing the simple average of ratings.
This value is then returned in 533 as the average rating of this object by all the friends.
Step 244 of process 240 then returns the values in 520 to handset 3.
Process 250 returns messages to this phone.
This phone can either be AQU or Owner. It retrieves both messages (msg) and acknowledgments (ACK) (which are treated as a message that a phone sends to itself). Thus the user get records of what it sent as well as messages it received.
the app on the phone has the option of retrieving all messages ever sent to this phone or just messages not retrieved since the last execution on process 250 for this phone.
Messages accessed this way include all owned objects referenced by these messages.
the purpose of this process as opposed to 230, 240 and 245 which access messages related to objects are for the user to see all messages even when the object is not being referenced, e.g. with the former accesses you would see a rating from AQU 1 when a call comes in from AQU 1 that would require though that AQU calls again later. The later access would show the rating from AQU 1 even if they never called again.
Process 250 starts with either step 251 or 252.
step 251 the application decides that it would like to see if there are messages. It can do this on a periodic basis such as every 15 minutes, or after an event has occurred, say a phone call has completed.
step 252 a notification sent by step 216 is received through internet 10 and sent to the application. Step 216 may have included an actual message payload 570 and it would be received by step 252 on this phone. If there is a payload, checked for in step 253, process 250 simply returns these values, otherwise step 253 continues at step 254.
Step 254 assembles two values on either phone 1 or phone 3 and then sends them to the server 40 via internet 10. These values include: 1 ) The phone number of this phone, let us call it 250-1 and 2) an indication if it wants all messages or just messages since the last time a poll occurred, let us call this 250-2.
Step 255 retrieves all messages sent to this phone (both MSG and ACKs). This step does a two level search for each message, first it retrieves sub-messages from the message queue, and then it retrieves the associated message state object. In this way each retrieved message has the state, text and all associated data for this message. Step 255 starts with the phone number 250-1 and the 'all messages or just messages since last retrieval bit 250-2 are then used as to search for matches on table (140), the message queue table, columns 143 ('to' phone) and 148 (sent) respectively to access all sub-messages in the message queue sent to this phone.
the second part of step 255 uses the retrieved sub-message field, MSG #(145) to search table (120) column 121 (MSG#).
This retrieval and the message type 124 are then used to assemble a return value 571 which is made up of a list of: 310 (recommendation), 320 (rating), 330(gift), 340 (general note) and 350 (share message) return values.
Each of these messages (310,320,330,340, 350) contains one and only one message 600.
Step 256 retrieves all the owned objects associated with all the messages retrieved in step 255 so that the object referenced in the message is readily available on phone 1 or phone 3.
the list of retrieved messages assembled in step 255 is iteratively scanned to collect a list of unique owned object reference numbers (columns 125(owned OBJ #), 128 (Object class) and 129 (Object # Authority or type)). If metadata is needed the retrieved list of objects is used to access associated metadata as described in General Notes on metadata above. The retrieval is then used to produce one return value of type 400, the object info return value. The fields filled into 400 are described above. The collection of these objects is then used to form list 572.
step 257 we set all the sub-messages thus retrieved to 'read'.
the phone number passed in 250-1 and the sent column 148 with a value of 'not sent' are used again to access the message queue (140) to set the sent column '148' to 'sent.
Step 258 of process 250 then returns the values in 570 to the phone that called this process.
Process 260 allows the Owner to respond in some way to the message about the owned object sent in process 200 from AQU to Owner and retrieved by the owner in one of 230, 240, 250 or 270. These actions range from accepting or rejecting a gift or recommendation or commenting on a rating. All of these actions are then sent back to the owner along with a possible text field.
Step 261 assembles three values on owner phone 3 and then sends them to the server 40 via internet 10.
These values include: 1 ) the reference to the message state object returned as values MSG # in the recommendation, ratings, gift or general message fields 316, 326, 335 and 343 respectively, let's call this value 260-1 , 2) action to take with this message about an owned object, let's call this value 260-2.
the acceptable values of 'action' are dependent on the message types and are described below with the recommendation, ratings, gifts and general messages respectively below, 3) an optional text field that allows the owner to comment on the message is sent in 260-3. 4) If the user wishes to pay for a recommendation along with accepting the recommendation, then payment information is sent in 260-4 (as well as the request to do the payment).
Step 262 performs the charge appropriate action on accepting or rejecting a gift or if requested by the user, the charge for the recommendation as sent in 260-4. (Accepting or rejecting a gift are actions on available on a gift to the owner). The following are the steps taken depending on the business decisions on how to charge the AQU for the gift or recommendation.
step 263. If a charge authorization had been obtained and the authorization has not expired, submit the charge to the payment service 60, or to payment service 92 via Authority 90 or 96 and proceed to step 263 3) if pre-authorization expired attempt to charge again at 60 or 92. Then pass the result of charge to 263.
step 263 If there was a payment failure of a gift as checked in step 263, go to step 264 to return a payment failed message to both handsets (very embarrassing to Aqu). Otherwise proceed to step 265
Step 265 updates the state column 127 of the message state object table (120) as per the message type by using the passed message # 260-1 to update the row who's column 121 matches this passed row. Step 265 also retrieves the row referenced for use in steps 266 and 267.
Step 266 queues the action message itself to go to the AQU phone.
a record is inserted into the message queue (140) with the following values: 1 )
Sub- Msg Type (141 ) is a sub-msg type calculated from msg type 124 and the action (e.g. for an accepted recommendation who's later billing failed a msg type of 'gift bill failed' would be inserted).
2) From Phone (142) is the Owner Phone retrieved from step 265 column 122, 3) To Phone is the AQU Phone retrieved from step 265 column 123. 4) ACK or Msg (144) is set to "Msg”.
Msg# is Msg# retrieved from step 265 column 121 .
Words (145) are the words passed in 260-3; 7) date (147) is the current timestamp (i.e. right now). 8) Sent bit (148) is set to "no".
Step 267 queues an acknowledgement that the message was sent back to Owner.
a record is inserted into the message queue (140) with the following values: 1 )
Sub-Msg Type (141 ) is the same as calculated in step 266. 2) From Phone (142) is the AQU Phone retrieved in step 265 column 123, 3) To Phone is the Owner Phone retrieved in step 265, column 122. 4) ACK or Msg (144) is set to "Ack”. 5) Msg# is set to the Msg# retrieved in step 265, column 121 . 6) Words (145) are the words to send to the passed in 260-3, 7) date (147) is the current timestamp (i.e. right now). 8) Sent bit (148) is set to "no".
Step 268 of process 260 then returns success to handset 3.
Process 270 operates in two distinct modes to return lists of objects. In the first mode it allows the retrieval of a list of objects that have at least one message stored in the system from a previous 200 for a particular owner phone. In the second mode, the user supplies a list of objects (or a single object). In either case, a list of objects is returned along with all messages from any AQU.
Step 271 takes as input either an owner phone (let us call this 270-1 ) or an object reference in the form of an 800, 810, 820, or 830 that contain a single object or a collection of objects for which to query. Let us call this 270-2. 270-1 and 270-2 are mutually exclusive.
Step 272 directs flow depending on whether 270-1 or 270-2 was set. If 270-2, the object reference method is used, processing continues at step 274. Otherwise processing proceeds to step 273 to retrieve a list based on Owner phone.
Step 273 retrieves all the unique objects stored in table 120 for this Owner Phone from any AQU. There may be multiple messages in this table from many AQUs or from one AQU with different messages (i.e. a rating, and a recommendation from the same AQU). Step 273 retrieves all messages with Owner phone, column 122 equal to the passed phone # in 270-1 . It then ensures that there is only one message in this list with a unique object reference. It does so by having only one message with unique values in OBJ# (125), OBJ Class (128) and OBJ# Authority or type (129). As a final part of step 273 the object references only are extracted from these messages to for an object reference list containing only objects that have had at least one message to the Owner.
Step 274 takes either the list of objects (or the single object) passed in 270-2 or the list of objects (or single object) returned by step 273 and collects all messages and sub-messages.
Step 274 iterates through this list of Objects. For each of these objects it retrieves all messages associated with the object regardless of who sent them. It uses the object reference in this iteration to search table 120 for all messages that contain the same object reference, namely it searches columns 125 (OBJ #), 128 (OBJ Class), and 129 (OBJ # Authority or type) for matches to the object being referenced. This produces a list of messages about this object from and AQU. Step 274 saves these lists of messages along with each object.
Step 274 also collects any metadata needed for the objects that are iterated over as per the General Discussion on metadata section above.
a return of form 540 is assembled by step 274. Iterating through the list of objects, the first object is assembled in an Object Item 550. This first item assembles an Object and its messages 900 for this item. The constituent 901 is filled with object reference as per the discussion of object 900 above. It then puts the list of all messages associated with this object it had retrieved into the constituent 902. Likewise step 274 iterates through the list putting the last item 'n' into Object 551 in a similar manner as it did for 550.
Step 274 of process 270 then returns the return value 540 to the owner handset 3.
Process 280 allows the AQU phone (and the Owner phone if needed) to access the whole catalog of objects available as potential owned objects.
Process 280 allows access to the catalog to allow recommendations and gifts to offer up new objects. If AQU and Owner are on different carriers, process 280 allows the AQU to offer recommendations and gifts that will work or can be purchased on Owner's network. As an example, AQU can only recommend RBTs that actually work and are available on the Owner's network.
Step 281 assembles three values on either AQU phone or Owner phone and then sends them to the server 40 via internet 10. These values include: 1 ) Catalog Authority reference. Let us call this 280-1 this abstract passed value may be a) a known Authority reference, (280-1 a) b) Type of object (e.g. RBT or RT) and a catalog name (280-1 b). e.g. 'amazon.com' or 'Verizon', or c) Type of object and phone number (280-1 c) and 2) an abstract search/limiting value, e.g. "Featured list in catalog", "titles of pop-music" or "titles the begin with the letter 'J'". Let us call this 280-2. These parameters are passed and received in step 281 . Optionally, a phone number may be entered (possibly the same as in 280-1 c) that limits the catalog search to objects available to this phone number. Let us call this optional parameter 280-3.
a phone number may be entered (poss
Step 282 starts by resolving the three types of catalog references to a catalog authority.
280-1 a uses a direct authority number.
280-1 b uses type and catalog name to reference columns 182 and 185 respectively from the catalog authority table 180 to get an authority number from column 181 .
280-1 c uses the passed owner phone to access the phone to carrier service 65. This service returns a carrier name. This name and the passed type are then used as in 280-1 b to resolve to an authority number.
Step 282 then uses the catalog authority, the abstract match value 280-2 and the optional phone number filter 280-3 to retrieve values from the catalog authority. More information on this access is described in 'general discussion on metadata' above to retrieve the list requested.
Step 283 assembles a new object list 560 from the retrieved search list.
Each item in the list is in the form of 561 .
Each 561 contains object info reference 563 in the form of object info 400.
Each of these forms 400 may either be: 1 ) of form 800 (catalog reference) if the returned object here is a single object or 2) of form 820 or 830 if it is a collection (820 if the object is to a known collection list, 830 if the objects in the collection are included).
Note, 280 usually return only a type 830.
Step 283 then returns this requested catalog access in the form of 560 to the caller.
the user may then select any object in the table to use for a gift or recommendation in a 200.
This URL contains, 1 ) Object Reference, 2) Owner Phone, 3) AQU phone and 4) whether message was sent to Owner or AQU. Additionally the object reference had to ensure that metadata was available for the object by the user either including it in the original 200 or was available in some Catalog Authority 90.
Step 291 accepts the values passed to the process.
Step 292 directs flow to 293 if the message was 'to the Owner', and to step 295 if it was 'to the AQU' should a share message have been sent.
Step 293 accesses the messaging server 40 with a 'Call Pair to Owner' (230), passing the phone numbers and object reference and asking for the metadata associated with the object.
Step 294 produces the display HTML for the returned object and all its messages. It also provides a HTML menu to allow all acceptable actions to 260, action by owner' to be performed, such as to comment on rating, accept a recommendation or gift'. The website provides actions associated with each of these menu selections to allow 260's to be sent to the messaging server 40. Additionally step 294 may provide access to the appropriate catalog of new objects by providing repeated calls to 280.
Steps 295 and 296 perform these same functions for the AQU, performing a 245, 'Call pair by AQU' instead of a 230 in step 295. It also allows menu access to all functions 200 available to an AQU in step 296 instead of a menu to 260. Steps 295 and 296 would a include 'share' messages that were sent from a phone in addition to messages that the AQU sent. In case of the share the referenced object is the object (or collection of objects) shared.
Step 297 displays this entire HTML on the user's web browser.
the current disclosure allows the AQU to rate the object owned by Owner.
the processes, databases and return values already described are combined to allow the AQU to send the rating, along with a text note to the owner. This rating is then seen by the AQU and Owner whenever the owned object is referenced. Additionally the system shows an average ratings and specific ratings of other Aqu's on the Owner handset. The Owner can also send a comment back to AQU about the rating that was just received.
the initial rating from AQU to Owner and response to the rating can also be seen in a list of messages to and from any handset. In this way each phone doesn't have to access the object to see ratings.
Tables 120 and 140 contain values specific to ratings; 1 ) Msg type column 124 contains the value 'Rating', 2) Msg Info column 126 contains the rating value assigned by AQU to this object. The rating value is an integer or floating point value determined by business rules. The ranges of acceptable values are also set by business rules. 3) State column 127 may be 'Initial rating sent' to indicate that AQU sent a rating to the Owner or 'response received' for the Owner sending a response about the rating'. 4) Sub-msg type column 141 is the same values as 'state' column 127.
the aggregate rating is returned whenever there is a list of ratings messages related to a single object. In all cases it is the numerical average of the set of ratings returned in the set of messages. This value is expressed as a floating point value.
These aggregate values consist of: A) in return value 524 of return list in the 'owner accesses OBJ for this call pair' (520). It is the average of the rating from the specific AQU if there is one (in 521 ) and the list of ratings from every AQU other than this AQU in 523).
Figure 4 shows how all processes in figure 3, database columns in figure 2 and return values in figure 5 are combined to produce the full capabilities of the rating functionality in this disclosure. It shows the communications between 4 points, 1 ) The application on the AQU handset (1001 ), 2) the server 40 (1002), 3) The application on the Owner handset (1003) and the operating system on the owner handset (1004).
Phase 1200 is where the AQU phone rates the object. This phase shows the time-flow communication between the various points from the time that the AQU sends the rating about the object to the time that the rating is stored on server 40 and a possible notification is sent to the Owner phone.
the AQU sends the rating to process 200, Message Aqu->Owner.
value 201 -1 contains the AQU phone
value 201 -2 contains the Owner phone
value 201 -3 has an optional text note
value 201 -4 a reference to the object being rated (and as described with process 200)
201 -6 contains the rating value itself.
Phase 1201 shows the non-object related retrievals of this message on both the Owner and AQU phones. All of the access paths are shown in process 250, the Overall message queue' process.
the poll to get the message continues from the notification if there wasn't a payload (step 252) or by a periodic poll of the server a 251 .
the poll is passed the owner's phone number 250-1 and an indication if all messages or just the messages since last retrieval are needed (250-2)
[00290] 1 108 is the periodic poll by AQU that will pick up the 'you sent the rating' sub-message. It enters process 250 at 251 .
the poll is passed the Aqu's phone number 250-1 and an indication if all messages or just the messages since last retrieval are needed (250-2).
Phase 1202 shows how the owner handset can pick-up the rating sent by the AQU whenever the Owner accesses the call pair for this object
the Owner accesses this call pair with process 230, the 'call pair by owner' process and passes: value 230-1 contains the AQU phone, value 230-2 contains the Owner phone, value 230-3 a reference to the object as described in process 230. 230-3 may be empty indicating that all relevant messages between this call pair will be returned.
1 1 1 server 40 responds with the rating and message if any that the AQU sent about the object. It also returns the rating and messages from all Aqu's on this Object to the Owner along with the average rating. This is returned in a return value of type 520.
Phase 1203 shows how the AQU handset can pick-up the rating it had previously sent to Owner whenever the AQU accesses the call pair for this object.
server 40 responds with the rating and message if any that the AQU had previously sent about the object to the owner. This is returned in a return value of type 500.
Phase 1204 optionally allows the Owner to comment on the rating. This phase shows the time-flow communication between the various points from the time that the Owner sends the comment through to all the ways that this comment may be picked up.
value 260-1 contains a reference to the 'message about object' Msg # returned as described in process 260
value 260-2 contains 'rating comment'
Value 260-3 contains the comment.
1 1 15 1 stores 'response received' as the new state in the message about object reference by msg# 260-1 (step 265) in the state column, 127. 2) Creates a sub- message to AQU that in effect says 'Owner commented on your rating' (step 266). This stored sub-message is of type 'Response sent' and 'Ack or Msg' set to 'Msg' with the comment 260-3 stored with it. 3) Creates a sub-message back to Owner that in effect says 'You just commented to AQU about his rating' (step 267) and the comment 260-3. This stored sub-message is of type 'Response sent' and 'Ack or Msg' set to 'Ack', with the comment 260-3 stored with it.
1 1 16 sends a notification to the OS of the Aqu's handset if that facility has been enabled in the system for the type of device that the AQU has using step 269a then causes notification to continue in step 252.
1 1 17 the poll to get the message continues from the notification if there wasn't a payload (step 252) or by a periodic poll of the server a 251 ). The poll is passed the Aqu's phone number 250-1 and an indication if all messages or just the messages since last retrieval are needed (250-2)
1 1 19 is the periodic poll by Owner that will pick up the 'you commented on a rating' sub-message. It enters process 250 at 251 .
the poll is passed the Owner's phone number 250-1 and an indication if all messages or just the messages since last retrieval are needed (250-2).
value 230-1 contains the AQU phone
value 230-2 contains the Owner phone
value 230-3 a reference to the object as described in process 230.
230-3 may be empty indicating that all relevant messages between this call pair will be returned.
the current disclosure allows the AQU to recommend a new object to replace the current object owned by Owner.
the processes, databases and return values already described are combined to allow the AQU to send this recommended new object along with a text note to the owner.
This recommendation is then seen by the AQU and Owner whenever the owned object is referenced. Additionally the system shows what other Aqu's have recommended on the Owner handset. The Owner can accept or reject the recommendation and send a response text message to the AQU.
the Owner may use the functions in this disclosure to pay for the recommendation.
This function is optional to the flow of a recommendation.
the user may pay for the recommendation directly through other means and simply use this disclosure to record (send a message) that a recommendation was accepted.
Tables 120 and 140 contain values specific to a recommendation; 1 ) Msg type column 124 contains the value 'Recommendation', 2) Msg Info column 126 a pointer to a new recommendation.
This recommendation is an object reference as described in the general object reference above and points to a single global or local object or to a collection of objects. This may have been obtained from a catalog or collection retrieve 280 or by means not covered by this disclosure, as an illustrative example this could be a 'featured' track that the user saw in our app or through an automatically generated suggestion for a track similar to the object being referenced.
state column 127 may be ' Initial recommendation sent' to indicate that AQU sent recommendation to Owner, 'Recommendation Accept' to indicated the recommendation was accepted, 'Recommendation reject' to indicate that the recommendation was rejected, or 'Recommendation comment' for the Owner sending a comment about the recommendation 4).
Sub-msg type column 141 is the same values as 'state' column 127.
action types sent into the action process 260, field 260-2 There are: 1 ) 'reject recommendation', 2) 'accept recommendation', 3) 'comment on recommendation'. Additionally, should the user wish to use this disclosure to pay for a recommendation and the action in 260-2 is 'accept recommendation' field 260-4 would contain payment information as described with process 260.
Figure 4a shows how all processes in figure 3, database columns in figure 2 and return values in figure 5 are combined to produce the full capabilities of the recommendation functionality in this disclosure. It shows the communications between 4 points, 1 ) The application on the AQU handset (2001 ), 2) the server 40 (2002), 3) The application on the Owner handset (2003) and the operating system on the owner handset (2004).
Phase 2201 is where the AQU phone recommends a new object to replace the current object.
This phase shows the time-flow communication between the various points from the time that the AQU looks at the new catalog of objects through to sending the recommendation to the time that the recommendation is stored on server 40 and a possible notification is sent to the Owner phone.
the AQU phone accesses the catalog appropriate to the Owner through process 280.
the following values are passed to obtain the appropriate catalog: 1 ) value 280-1 contains one of three catalog references as described with process 280 above; a)280-1 a is a known authority code, b) 280-1 b is a catalog name and type or c) 280-1 c is a phone number that will be resolved to a carrier's catalog name, and a type. 2) 280-2 contains the abstract/limiting value for the search e.g. 'pop music'. 3) 280-3, an optional phone number that will limit searches to objects relevant to that phone number. Process 280 uses these values to calculate the appropriate catalog of potential new objects to the AQU phone in 2102. 2102 returns a return value 560 containing these new objects to AQU.
the AQU selects an appropriate object (or objects) to replace the current object.
This object may be from the retrieved catalog of it could be from advertisements or from automatic 'songs like this' recommendation engine.
the AQU sends the recommendation to process 200 Message Aqu->Owner.
value 201 -1 contains the AQU phone
value 201 -2 contains the Owner phone
value 201 -3 has an optional text note
value 201 -4 a reference to the object for which the recommendation applies (i.e. 'replace this') (and as described with process 200)
201 -6 contains the new object along with the 'catalog relevance' value returned that was in the object 406 field of this object from process 280.
This stored sub- message is of type 'Recommendation sent' and 'Ack or Msg' set to 'Ack', the text comment 201 -3 is stored with it.
Phase 2202 shows the non-object related retrievals of this message on both the Owner and AQU phones. All of the access paths are shown in process 250, the 'overall message queue' process
the poll to get the message continues from the notification if there wasn't a payload (step 252) or by a periodic poll of the server a 251 ).
the poll is passed the owner's phone number 250-1 and an indication if all messages or just the messages since last retrieval are needed (250-2)
21 10 is the periodic poll by AQU that will pick up the 'you sent the recommendation' sub-message. It enters process 250 at 251 .
the poll is passed the Aqu's phone number 250-1 and an indication if all messages or just the messages since last retrieval are needed (250-2).
21 1 1 continues through process 250 to return a sub-message of value 560 with the 'ack' msg.
Phase 2203 shows how the owner handset can pick-up the recommendation sent by the AQU whenever the Owner accesses the call pair for this object
the Owner accesses this call pair with process 230, the 'call pair by owner' process and passes: value 230-1 contains the AQU phone, value 230-2 contains the Owner phone, value 230-3 a reference to the object as described in process 230. 230-3 may be empty indicating that all relevant messages between this call pair will be returned.
server 40 responds with the recommendation and message if any that the AQU sent about the object. It also returns the recommendations and messages from all Aqu's on this Object to the Owner from all Aqu's. This is returned in a return value of type 520.
Phase 2204 shows how the AQU handset can pick-up the recommendation it had previously sent to Owner whenever the AQU accesses the call pair for this object.
the AQU accesses this call pair with process 245, the 'call pair by Aqu' process and passes: value 245-1 contains the AQU phone, value 245-2 contains the Owner phone, value 245-3 a reference to the object as described in process 245. 245-3 may be empty indicating that all relevant messages between this call pair will be returned.
server 40 responds with the recommendation and message if any that the AQU had previously sent about the object to the owner. This is returned in a return value of type 500.
Phase 2205 allows the Owner to accept, reject or send a comment about the recommendation.
the current disclosure allows the fact that the Owner accepted, rejected or sent a comment to be communicated to AQU.
This phase shows the time- flow communication between the various points from the time that the Owner accepts, rejects or comments through to all the ways that this acceptance, rejection or message may be picked up.
value 260-1 contains a reference to the 'message about object' Msg # returned as described in process 260
value 260-2 contains on of: 1 ) 'reject recommendation', 2) 'accept recommendation', 3) 'comment on recommendation'.
Value 260-3 contains the comment text if any.
21 17 1 stores one of the following as the new state in the message about object reference by msg# 260-1 (step 265) in the state column, 127: , A) 'Recommendation Accept' to indicated the recommendation was accepted, B) 'Recommendation reject' to indicate that the recommendation was rejected, or C) 'Recommendation comment' for the Owner sending a comment about the recommendation. 2) Creates a sub-message to AQU that in effect says that the owner accepted, rejected or commented on your recommendation (step 266). This stored sub-message has the type set to the same value as state 127 with the comment 260-3 stored with it.
21 18 sends a notification to the OS of the Aqu's handset if that facility has been enabled in the system for the type of device that the AQU has using step 269a then causes notification to continue in step 252.
the poll to get the message continues from the notification if there wasn't a payload (step 252) or by a periodic poll of the server a 251 ).
the poll is passed the Aqu's phone number 250-1 and an indication if all messages or just the messages since last retrieval are needed (250-2)
2120 continues through process 250 to return a sub-message of value 560 with the acceptance, rejection or commend from the Owner to the AQU.
2121 is the periodic poll by Owner that will pick up the 'acceptance, rejection or comment' sub-message. It enters process 250 at 251 .
the poll is passed the Owner's phone number 250-1 and an indication if all messages or just the messages since last retrieval are needed (250-2).
value 245-1 contains the AQU phone
value 245-2 contains the Owner phone
value 245-3 a reference to the object as described in process 245. 245-3 may be empty indicating that all relevant messages between this call pair will be returned.
server 40 responds with the recommendation item for this object 31 1 containing two sub-messages in list 315. The first would be the original recommendation 'ack' message and it's comment sent from Aqu->Owner (from 2101 ), the second would contain this acceptance, rejection or comment from the Owner- >AQU (from 21 16). In this way the exchange between Aqu->Owner in both directions is returned along with the recommendation on this object.
31 1 is returned to the AQU handset in a 500 return value [00348]
the Owner again accesses this call pair with process 230, the 'call pair by owner' process and passes: value 230-1 contains the AQU phone, value 230-2 contains the Owner phone, value 230-3 a reference to the object as described in process 230. 230-3 may be empty indicating that all relevant messages between this call pair will be returned.
2126 server 40 responds with the same message as returned from 21 13, however, this time the enclosed 31 1 has two sub-messages in list 315 instead of one. The first would be the original recommendation message and its comment sent from Aqu->Owner (from 2101 ), the second would contain the 'Ack' for the acceptance, rejection or comment from the Owner->AQU (from 21 16). In this way the exchange between Aqu->Owner in both directions is returned along with the recommendation on this object. 31 1 is returned to the Owner handset in a 520 return value (in 522).
the current disclosure allows the AQU to send a gift of a new object to replace the current object owned by Owner. In practice this means browsing a catalog for this new object (or the user could for instance send a featured or system recommended object as a gift).
the processes, databases and return values already described are combined to allow the AQU to send this gift of a new object along with a text note to the owner. These processes allow for the AQU to pay for this new item in a number of business rules based cases.
This gift is then seen by the AQU and Owner whenever the owned object is referenced. Additionally the system shows what other Aqu's have gifted on the Owner handset.
the Owner can accept or reject the gift and send a response text message to the AQU. Should the owner reject the gift, the system allows for various business rules related to crediting the purchase price back to the AQU. Should the gift be accepted, the current system is not involved in the installation of the object on the Owner handset.
FIG. 4b illustrates the gifting of an object from a catalog on server 40.
Figure 4c which shows a gift unrelated to an object illustrates the changed catalog flow if the catalog is on the carrier. That flow could also occur here for an object related gift.
Tables 120 and 140 contain values specific to a gift; 1 ) Msg type column 124 contains the value 'gift', 2) Msg Info column 126 a pointer to a new recommendation. This recommendation is an object reference as described in the general object reference above and points to a single global or local object or to a collection of objects.
state column 127 may be A) ' Initial gift sent' to indicate that AQU sent the gift to the Owner, B) gift 'accepted' to indicate that the gift has been accepted by the Owner and there are no payment issues, C) 'accepted, payment failed' to indicate that the Owner accepted the gift but the payment provided by AQU failed'.
Sub-msg type column 141 may be the same values as the state column 127.
Figure 4b shows how all processes in figure 3, database columns in figure 2 and return values in figure 5 are combined to produce the full capabilities of the gift functionality in this disclosure. It shows the communications between 5 points, 1 ) The application on the AQU handset (3001 ), 2) the server 40 (3002), 3) a payment service 60 (3003) 4) The application on the Owner handset (3004) and the operating system on the owner handset (3005).
Phase 3201 is where the AQU phone sends a gift object to replace the current object. This phase shows the time-flow communication between the various points from the time that the AQU looks at the new catalog of objects through to sending the gift, on to the time that the gift is stored on server 40 and a possible notification is sent to the Owner phone.
the AQU phone accesses the catalog appropriate to the Owner through process 280
value 280-1 contains one of three catalog references as described with process 280 above; a)280-1 a is a known authority code, b) 280-1 b is a catalog name and type or c) 280-1 c is a phone number that will be resolved to a carrier's catalog name, and a type. 2) 280-2 contains the abstract/limiting value for the search e.g. 'pop music'. 3) 280-3, an optional phone number that will limit searches to objects relevant to that phone number.
Process 280 uses these values to calculate the appropriate catalog of potential new objects to the AQU phone in 2102. 2102 returns a return value 560 containing these new objects to AQU.
the AQU selects an appropriate gift object (or objects) to replace the current object.
This object may be from the retrieved catalog of it could be from advertisements or from automatic 'songs like this' recommendation engine.
the AQU sends the gift to process 200 Message Aqu->Owner.
value 201 -1 contains the AQU phone
value 201 -2 contains the Owner phone
value 201 -3 has an optional text note
value 201 -4 a reference to the object for which the gift applies (i.e. 'replace this') (and as described with process 200)
201 -6 contains the gift object along with the 'catalog relevance' value returned in 406 from process 280 for this object.
purchase information is sent by AQU in the form of a credit card or an indication to bill the charge to Aqu's phone bill.
the server 40 attempts to collect payment for the gift using the payment information provided in 3103 and send a payment request to the payment processing service 60.
payments may occur in many forms and under many business rules.
step 3105 the payment processing service sends a 'payment success' or 'payment failure' message back to server 40. If payment fails phase 3201 jumps to 3107 to return failure to the AQU. This results in no 'message about object' record being stored on the server. As a result, step 3108, the sending of a notification to Owner is not performed either.
This stored sub-message is of type 'initial gift sent' and 'Ack or Msg' set to 'Ack'; the text comment 201 -3 is stored with it.
3107 returns success or failure to AQU. Success indicates that both payments succeeded and the gift message has been queued. Success uses step 217. Failure indicates that payment failed and gift message was not queued. Failure uses step 209.
3108 sends a notification to the OS of the Owner's handset if that facility has been enabled in the system for the type of device that the Owner has using step 216.
Phase 3202 shows the non-object related retrievals of this message on both the Owner and AQU phones. All of the access paths are shown in process 250, the 'overall message queue' process
3109 continues the notification sent to the Owner's handset Operating system by passing the notification to the application using step 252. This notification may actually have the sub-message payload. This path is not shown in the time-flow in figure 4.
the poll to get the message continues from the notification if there wasn't a payload (step 252) or by a periodic poll of the server a 251 ).
the poll is passed the owner's phone number 250-1 and an indication if all messages or just the messages since last retrieval are needed (250-2)
31 1 1 continues through process 250 to return a sub-message of value 560 with the Aqu->owner message.
31 12 is the periodic poll by AQU that will pick up the 'you sent the gift sub- message. It enters process 250 at 251 . The poll is passed the Aqu's phone number 250-1 and an indication if all messages or just the messages since last retrieval are needed (250-2).
31 13 continues through process 250 to return a sub-message of value 560 with the 'ack' msg.
Phase 3203 shows how the owner handset can pick-up the gift sent by the AQU whenever the Owner accesses the call pair for this object
the Owner accesses this call pair with process 230, the 'call pair by owner' process and passes: value 230-1 contains the AQU phone, value 230-2 contains the Owner phone, value 230-3 a reference to the object as described in process 230. 230-3 may be empty indicating that all relevant messages between this call pair will be returned.
server 40 responds with the gift and text if any that the AQU sent about the object. It also returns the gifts and messages from all Aqu's on this Object to the Owner from all Aqu's. This is returned in a return value of type 520.
Phase 3204 shows how the AQU handset can pick-up the gift it had previously sent to Owner whenever the AQU accesses the call pair for this object.
the AQU accesses this call pair with process 245, the 'call pair by Aqu' process and passes: value 245-1 contains the AQU phone, value 245-2 contains the Owner phone, value 245-3 a reference to the object as described in process 245. 245-3 may be empty indicating that all relevant messages between this call pair will be returned.
server 40 responds with the gift and text if any that the AQU had previously sent about the object to the owner. This is returned in a return value of type 500.
Phase 3205 allows the Owner to accept, reject or send a comment about the gift. It shows the steps involved for payment related to both an acceptance and rejection. This phase shows the time-flow communication between the various points from the time that the Owner accepts, rejects or comments through to all the ways that this acceptance, rejection or message may be picked up. It also shows the special messages sent where an Owner accepts a gift, but payment fails.
value 260-1 contains a reference to the 'message about object' Msg # returned as described in process 260
value 260-2 contains one of: 1 ) 'reject gift, 2) 'accept gift, 3) 'comment on gift.
Value 260-3 contains the comment.
31 19 the server performs payment details on accept or reject. These steps are described in 262, 263 and 264. 31 19 shows the appropriate action sent from server 40 to payment service 60 to complete (or charge again) the transaction on an accept and to charge-back (or allow to expire) payment on a reject.
31 19A shows the appropriate response to payment or chargeback sent from the payment service 60 to server 40.
3120 1 stores one of the following as the new state in the message about object reference by msg# 260-1 (step 265) in the state column, 127: A) 'gift 'accepted' to indicate that the gift has been accepted by the Owner and there are no payment issues, B) 'accepted, payment failed' to indicate that the Owner accepted the gift but the payment provided by AQU failed'. C) 'Reject, refund OK' to indicate that the Owner rejected the gift and the refund of payment to AQU has succeeded, and D) 'reject, refund failed', to indicate that the Owner rejected the gift and that the payment refund to AQU somehow failed. E) 'Gift comment sent' to indicate that a comment has been sent.
step 266 2) Create a sub-message to AQU that in effect says that the owner accepted, rejected or commented on your gift (step 266).
A) the message type is the same as 127, B) 'Ack or Msg' set to 'Ack', with the comment 260-3 stored with it.
step 269a sends a notification to the OS of the Aqu's handset if that facility has been enabled in the system for the type of device that the AQU has using step 269a then causes notification to continue in step 252.
the poll to get the message continues from the notification if there wasn't a payload (step 252) or by a periodic poll of the server a 251 ).
the poll is passed the Aqu's phone number 250-1 and an indication if all messages or just the messages since last retrieval are needed (250-2)
3124 is the periodic poll by Owner that will pick up the 'acceptance, rejection or comment' sub-message. It enters process 250 at 251 .
the poll is passed the Owner's phone number 250-1 and an indication if all messages or just the messages since last retrieval are needed (250-2).
value 245-1 contains the AQU phone
value 245-2 contains the Owner phone
value 245-3 a reference to the object as described in process 245. 245-3 may be empty indicating that all relevant messages between this call pair will be returned.
server 40 responds with the gift item for this object 331 containing two sub-messages in list 335. The first would be the original gift 'ack' message and it's comment sent from Aqu->Owner (from 2101 ), the second would contain this acceptance, rejection or comment from the Owner->AQU (from 21 16). In this way the exchange between Aqu->Owner in both directions is returned along with the gift on this object.
331 is returned to the AQU handset in a 500 return value [00391]
the Owner again accesses this call pair with process 230, the 'call pair by owner' process and passes: value 230-1 contains the AQU phone, value 230-2 contains the Owner phone, value 230-3 a reference to the object as described in process 230.
230-3 may be empty indicating that all relevant messages between this call pair will be returned.
3129 server 40 responds with the same message as returned from 21 13, however, this time the enclosed 331 has two or three sub-messages in list 335 instead of one. The first would be the original gift message and its comment sent from Aqu->Owner (from 2101 ), the second would contain the 'Ack' for the acceptance, rejection or comment from the Owner->AQU (from 31 18). A third 'msg' would be returned if there had been an 'accept, but payment failed' indicating that that had occurred. In this way the exchange between Aqu->Owner in both directions is returned along with the gift on this object and possible payment failed message. 331 is returned to the Owner handset in a 520 return value (in 522).
Phase 4201 differs from 3201 in that there is no value in 201 -4 pointing the currently owned object. This phase also illustrates the retrieval of the new catalog from the owner's carrier.
Process 280 directs flow to 4102 that sends the catalog request to catalog authority 90 instead of performing a locally on server 40.
4103 returns the catalog from the catalog authority to the server. This catalog is then returned to AQU in step 4101 .
Step 4106 stores a null or some other empty value in the owned object reference columns 125, 128 and 129.
Phase 4202 differs from 3202 in that the sub-messages returned in return value 570 from 41 13 and 41 14 will have a null in their constituent Owned obj' field (606) and will therefore not have any objects in the list of associated objects 572.
Phase 4203 differs from 3203 in that it returns the non-object related gift in the 'message of non-obj related gift' return value 525
Phase 4204 differs from 3204 in that it returns the non-object related gift in the 'message of non-obj related gift' return value 503.
Phase 4205 differs from phase 3205 in the same ways that steps 4202, 4203 and 4204 differed from 3202, 3203 and 3204 respectively. (I.e. in how they have no associated object or return their values in 525 and 503.
the current disclosure allows general text comments about an object to be sent back and forth between AQU and Owner handsets about an object.
the exchange is originated on the AQU handset.
the processes, databases and return values already described are combined to allow the AQU to send a text note about an object. This note is then seen by the AQU and Owner whenever the owned object is referenced.
the Owner can also send a comment back to AQU as a response for this note.
the note and response can also be seen in a list of messages to and from any handset. In this way each phone doesn't have to access the object to see the note.
Tables 120 and 140 contain values specific to a general note; 1 ) Msg type column 124 contains the value 'notes', 2) Msg Info is empty.
State column 127 may be 'Initial note sent' to indicate that the AQU phone sent a note to the other side or 'note response received' for the Owner sending a response '. 4)
Sub-msg type column 141 is the same values as 'state' column 127. 5)
a note has no special return values in 300, 500, 520, 530, and 540,
Figure 4d shows how all processes in figure 3, database columns in figure 2 and return values in figure 5 are combined to produce the full capabilities of the note functionality in this disclosure. It shows the communications between 4 points, 1 ) The application on the AQU handset (5001 ), 2) the server 40 (5002), 3) The application on the Owner handset (5003) and the operating system on the Owner handset (5004).
Phase 5201 is where the AQU phone sends a note about the object. This phase shows the time-flow communication between the various points from the time that the AQU sends the note about the object to the time that the note is stored on server 40 and a possible notification is sent to the Owner phone.
the AQU sends the note to process 200 Message AQU->Owner.
value 201 -1 contains the AQU phone
value 201 -2 contains the Owner phone
value 201 -3 has the text note
value 201 -4 a reference to the object for which this note applies, (the value passed is described with process 200)
201 -6 is blank.
This stored sub-message is of type 'initial note sent' and 'Ack or Msg' set to 'Ack', the text for this note 201 -3 is stored with it. [00416] 5103 returns an OK status back to the AQU using step 217
[00417] 5104 sends a notification to the OS of the Owner's handset if that facility has been enabled in the system for the type of device that the Owner has using step 216.
Phase 5202 shows the non-object related retrievals of this message on both the Owner and AQU phones. All of the access paths are shown in process 250, the 'overall message queue' process
5105 continues the notification sent to the Owner's handset Operating system by passing the notification to the application using step 252. This notification may actually have the sub-message payload. This path is not shown in the time-flow in figure 4.
the poll to get the message continues from the notification if there wasn't a payload (step 252) or by a periodic poll of the server a 251 ).
the poll is passed the owner number 250-1 and an indication if all messages or just the messages since last retrieval are needed (250-2)
5108 is the periodic poll by the AQU phone that will pick up the 'you sent the note' sub-message. It enters process 250 at 251 .
the poll is passed the AQU phone number 250-1 and an indication if all messages or just the messages since last retrieval are needed (250-2).
Phase 5203 shows how the owner handset can pick-up the note sent by the AQU whenever the owner accesses the call pair for this object.
the Owner accesses this call pair with process 230, the 'call pair by owner' process and passes: value 230-1 contains the AQU phone, value 230-2 contains the Owner phone, value 230-3 a reference to the object as described in process 230. 230-3 may be empty indicating that all relevant messages between this call pair will be returned.
value 230-1 contains the AQU phone
value 230-2 contains the Owner phone
value 230-3 a reference to the object as described in process 230.
230-3 may be empty indicating that all relevant messages between this call pair will be returned.
51 1 1 server 40 responds with the note the AQU sent about the object along with all notes sent or received from all AQUs about this object. This is returned in a return value of type 520.
Phase 5204 shows how the AQU handset can pick-up the note it had previously sent to the Owner whenever the AQU accesses the call pair for this object.
the AQU accesses this call pair with process 245, the 'call pair by Aqu' process and passes: value 245-1 contains the AQU phone, value 245-2 contains the Owner phone, value 245-3 a reference to the object as described in process 245. 245-3 may be empty indicating that all relevant messages between this call pair will be returned.
server 40 responds with the note sent to the owner about this object. This is returned in a return value of type 500.
Phase 5205 allows the owner to respond to the note. This phase shows the time-flow communication between the various points from the time that the Owner sends the response through to all the ways that this response may be picked up.
value 260-1 contains a reference to the 'message about object' Msg # returned as described in process 260; value 260-2 is empty. Value 260-3 contains the response.
51 15 1 stores 'note response sent' as the new state in the message about object reference by msg# 260-1 (step 265) in the state column, 127. 2) Creates a sub-message to AQU that in effect says 'Owner responded to your note' (step 266). This stored sub-message is of type 'note response sent" and 'Ack or Msg' set to 'Msg' with the note 260-3 stored with it. 3) Creates a sub-message back to destination that in effect says 'You just sent a response to the destination about his note' (step 267) and the note/share 260-3. This stored sub-message is of type 'note response sent' and 'Ack or Msg' set to 'Ack', with the note 260-3 stored with it.
51 16 sends a notification to the OS of the AQU handset if that facility has been enabled in the system for the type of device that the AQU has using step 269a then causes notification to continue in step 252.
51 17 the poll to get the message continues from the notification if there wasn't a payload (step 252) or by a periodic poll of the server a 251 ). The poll is passed the AQU phone number 250-1 and an indication if all messages or just the messages since last retrieval are needed (250-2)
51 18 continues through process 250 to return a sub-message of value 560 with the response from the Owner to the AQU.
51 19 is the periodic poll by AQU that will pick up the response sub- message. It enters process 250 at 251 .
the poll is passed the AQU phone number 250-1 and an indication if all messages or just the messages since last retrieval are needed (250-2).
value 245-1 contains the AQU phone
value 245-2 contains the Owner phone
value 245-3 a reference to the object as described in process 245. 245-3 may be empty indicating that all relevant messages between this call pair will be returned.
value 230-1 contains the AQU phone
value 230-2 contains the Owner phone
value 230-3 a reference to the object as described in process 230.
230-3 may be empty indicating that all relevant messages between this call pair will be returned.
the current disclosure allows the owner to share owned objects with the AQU. Unlike other messages in this disclosure, this message is originated by the Owner.
the processes, databases and return values already described are combined to allow the Owner to send a share message about an object or collection of objects with the other AQU.
the share is seen on the AQU phone when it references other objects. This is because this is the first time this object is being seen by the AQU and it doesn't have the object reference as yet.
the purpose of this share is to allow the AQU to receive this reference and then to send other messages about this new object. As such there is no direct response to this share message on the AQU phone. Rather the AQU would send a new 200 for this object at a later time.
the share is also when it references this shared object.
the Share can also be seen in a list of messages to and from any handset.
Tables 120 and 140 contain values specific to a share; 1 ) Msg type column 124 contains the value 'share, 2) Msg Info is blank. 3) State column 127 may be 'Initial share sent' to indicate that the Owner phone sent a share to the AQU. 4) Sub-msg type column 141 is the same values as 'state' column 127. 5) the item shared is stored in the Object reference fields 125, 128 and 129.
the shared object can be any of the types of objects (800, 810, 820 or 830), however it should be noted that in many cases, an 830 is used to include the complete item being shared. This results in the shared item being stored on server 40 for pick-up by the Owner.
Figure 4e shows how all processes in figure 3, database columns in figure 2 and return values in figure 5 are combined to produce the full capabilities of the share functionality in this disclosure. It shows the communications between 4 points, 1 ) The application on the Owner handset (9001 ), 2) the server 40 (9002), 3) The application on the AQU handset (9003) and the operating system on the AQU handset (9004).
Phase 9201 is where the Owner phone sends a share about the object. This phase shows the time-flow communication between the various points from the time that the AQU sends the share about the object to the time that the share is stored on server 40 and a possible notification is sent to the AQU phone.
This stored sub-message is of type 'initial share sent' and 'Ack or Msg' set to 'Msg', the text for the note 201 -3 is stored with it.
3) Creates a sub-message back to Owner that in effect says 'You just shared object X with AQU' (step 214).
This stored sub-message is of type 'initial share sent' and 'Ack or Msg' set to 'Ack', the text for this note 201 -3 is stored with it.
9104 sends a notification to the OS of the AQU handset if that facility has been enabled in the system for the type of device that the AQU has using step 216.
Phase 9202 shows the non-object related retrievals of this message on both the Owner and AQU phones. All of the access paths are shown in process 250, the 'overall message queue' process
9105 continues the notification sent to the AQU's handset Operating system by passing the notification to the application using step 252. This notification may actually have the sub-message payload. This path is not shown in the time-flow in figure 4e.
the poll to get the message continues from the notification if there wasn't a payload (step 252) or by a periodic poll of the server a 251 ).
the poll is passed the AQU number 250-1 and an indication if all messages or just the messages since last retrieval are needed (250-2)
9107 continues through process 250 to return a sub-message of value 560 with the Owner->AQU share message.
9108 is the periodic poll by the Owner phone that will pick up the 'you sent the share' sub-message. It enters process 250 at 251 . The poll is passed the Owner phone number 250-1 and an indication if all messages or just the messages since last retrieval are needed (250-2).
Phase 9203 shows how the AQU handset can pick-up the share whenever it access any other object with the same AQU/Owner phone pair. This is needed because other than the overall message queue access (250) there is no way for the AQU to have received the reference to this new shared object.
the AQU accesses this call pair with process 245, the 'call pair by Aqu' process and passes: value 245-1 contains the AQU phone, value 245-2 contains the Owner phone, value 245-3 a reference to the object as described in process 245. 245-3 may be empty indicating that all relevant messages between this call pair will be returned.
server 40 responds as normal with the messages that the AQU sent about this object. This normal info is returned in 501 of return type 500. It also returns all the objects that the Owner shared with AQU in the special 504 of this 500.
Phase 9204 shows the AQU sending a new message 200 about the object that was shared. In this case it rates the object shared in step 9101 .
This phase shows the time-flow communication between the various points from the time that the AQU sends the rating through to the Owner receiving the message and AQU receiving the ACK.
the AQU sends a new rating message about the recently shared object to process 200, the 'AQU->Owner' message process.
value 201 -1 contains the AQU phone
value 201 -2 contains the Owner phone
value 201 -3 has an optional text note
value 201 -4 a reference to the object that was shared in 9101 . (the value passed is described with process 200)
201 -6 contains the rating itself.
91 16 sends a notification to the OS of the Owner handset if that facility has been enabled in the system for the type of device that the source has using step 269a then causes notification to continue in step 252.
the poll to get the message continues from the notification if there wasn't a payload (step 252) or by a periodic poll of the server a 251 ).
the poll is passed the Owner phone number 250-1 and an indication if all messages or just the messages since last retrieval are needed (250-2)
91 19 is the periodic poll by AQU that will pick up the response sub- message. It enters process 250 at 251 .
the poll is passed the AQU phone number 250-1 and an indication if all messages or just the messages since last retrieval are needed (250-2).
9120 continues through process 250 to return a sub-message of value 560 with the 'ack' msg.
Phase 9205 shows the Owner accessing the call pair using the Object reference it used to send the original share in 9101 .
the response will show not only the rating just sent by the AQU, but also the original share (the messages about this object would show, 'you shared', and then 'the AQU rated').
This phase shows the time-flow communication between the various points from the time that the Owner access the call pair for this shared object to the time that the share and rating are returned.
the Owner accesses this call pair with process 230, the 'call pair by owner' process and passes: value 230-1 contains the AQU phone, value 230-2 contains the Owner phone, value 230-3 a reference to the object that was previously shared.
the Object reference is as described in process 230.
91 1 1 server 40 responds with the rating and message if any that the AQU sent about the object in a 320 of form 300. Additionally, since the original share was stored with this same AQU/Owner/Object reference it is returned in field 350 of the same form 300. As with all returns from a 230, it also returns the rating and messages from all Aqu's on this Object to the Owner along with the average rating. These would be messages from other AQUs that the Owner had shared this same object with. This is all returned in a return value of type 520.
Phase 9206 shows how the shared object, now with it's associated rating can be picked up when the owner access all the objects for which they are listed as the owner (i.e. the owner field in 120 is set to this owner phone number) and for which messages have been sent, (this method of selecting objects is one of two modes of process 270 as described above).
This phase shows the time-flow communication between the various points from the time that the Owner requests all objects for it is listed as owner in messages in the system to the time that all these messages are returned.
Ring back tones are short audio clips that an Owner sets to be played to AQU when AQU places a call to Owner. Owner my set this short music clip to be heard by many different Aqus or just this one. This music clip is played by Owner's carrier while AQU waits for Owner to answer the phone. Owner may also set up a number of audio tracks to be played in some sequence. We'll call this a 'jukebox'. Additionally, the RBT may be owned by a third party, such as the carrier itself or an advertising company.
the 'owned object' referred to throughout this disclosure in the case of RBTs is a unique identifier that refers to this RBT on the Owner's carrier. We'll call it the 'unique RBT identifier'
the unique RBT identifier may be incorporated with the Owner's phone unique identifier (e.g. Owner's phone) in some way to produce a globally unique RBT identifier or it may be a unique RBT identifier within the set of RBT identifiers relevant to Owner (e.g. a RBT identifier number starting at '1 ' on every phone, but that is in fact unique since it is still essentially combined with the phone number).
jukeboxes have unique identifier that are used to reference the jukebox; this is referred to as a 'unique RBT jukebox identifier'.
the jukebox itself is a collection unique RBT identifiers.
a user may refer to the RBT jukebox as an owned object or to individual RBTs within the jukebox.
the 'new object' from the catalog that is then passed in a recommendation or a gift is a unique identifier to an RBT relevant to the catalog itself.
the 'catalog relevance' field identifies the set for which catalog relevant unique RBT identifier is valid.
New objects in the catalog may also be jukeboxes; we'll call this the 'catalog relevant unique RBT Jukebox identifier'. It is made up of a collection of 'catalog relevant unique RBT identifier' items.
the AQU phone obtains the initial 'unique RBT identifier' or 'unique RBT jukebox identifier' reference to the RBT or jukebox owned on the owner phone 1 )through the 'what I heard' service or through a 2) share message sent from the owner.
this note may appear on the AQU handset from a notification or poll in the app or an alternate delivery method such as a text message or Facebook posting, additionally should the app not reside yet on AQU phone to receive this note, the 'has app' service will attempt to have AQU download the app.
the owner phone obtains the RBT or jukebox reference from many sources 1 ) 'what I played' such as described in 'what I heard' or through messages, 2) any message from AQU about this object in a rating, recommendation, gift, share or general note. These messages may be delivered through all the same alternate messages above, 3) by calling 230, the owner->AQU access without an object reference to obtain all RBT objects discussed between the parties, 4) by calling process 270 to obtain all RBT objects owned by the owner.
Aqu->owner field 201 -4 would be a 'unique RBT identifier' or 'unique RBT jukebox identifier' relevant to a catalog or collection authority.
the AQU would then supply a rating, recommendation, note or gift value to process 200 and an optional message.
rating value is given.
a recommendation or gift a 'catalog relevant unique RBT identifier' or 'catalog relevant unique RBT Jukebox identifier' is given.
the rating, recommendation, note or gift or gift would be seen by the Owner whenever this RBT or jukebox is accessed through processes 230, 240, 250 and 270.
the AQU would see this rating, recommendation, note, share or gift whenever this RBT or jukebox is referenced through process 245. Both sides would see it on overall message queue accesses 250.
AQU may rate, recommend, send a note or give a gift of a jukebox or a constituent individual RBT. If an individual is rated, recommended, noted, or gifted, it will propagate through the system just like a non-jukebox RBT and loose its relationship in the message exchange to the jukebox.
Metadata for an RBT consists of A) RBT title (in text), B) Author information (text), C) Album information (text and further references to group titles on an album), D) Track image or track image URL, E) RBT information such as expiration date of the RBT on the carrier and original purchase date.
the Abstract Match value column would contain tags relevant to the RBT such as 'Audio', 'user generated', and also may contain standard music tags such as 'Rock' or 'Classical'.
RBT Jukeboxes have a name assigned to the Jukebox as a whole, generally decided by the user (e.g. "My Rock Tracks") or preset by the collection authority (e.g. "B-52 Songs”). Each constituent RBT would consist of object metadata for each track.
type column 129 is set to "RBT or "RBT Collection” as needed.
Ringtones are short audio clips played on the owner phone when some handset calls into the owner phone. These clips can be set to be played as the only RT for all incoming calls, as the RT for this AQU only or as RT for some group of people, i.e. people marked as 'friends'.
An important feature of a RT is that it stored on the Owner handset. On current phones it can be a purchased audio clip, an audio clip that the user edits from another audio clip, or even a clip that the user themselves records. This clip generally doesn't have a global catalog reference number. Also unlike an RBT an RT is generally universal audio file formats such as MP3 and thus not tied to a carrier's catalog.
the Owned Object reference is anything that can uniquely identify this RT on the owner handset and is handset type deponent.
An RT reference may be for example; a numerical value, a Uri, a filename or some combination of the track name, artist name and album name. We will call this the 'unique RT identifier'.
the owner may have shared a list of RTs with the AQU. In this case the reference is to this collection. Let us call it 'unique RT list identifier' these are similar to RBT Jukeboxes
New object references sent in gifts and recommendations may take two forms; A) a raw item, in which case it has the track title, track artist, track name and include the actual recommendation or gift audio clip. Let's call this 'raw new RT reference' or B) as a reference to a global authority or collection authority. Let's call this 'catalog unique RT identifier' (along with possible lists of such RTs.
the Owner my obtain references to these objects through access to the objects stored on the phone or through the various messages and procedures in this disclosure.
New objects are obtained by accessing collection (90) or catalog authorities (96) by using 280 to search the catalog, or they may be obtained by other means including as an illustrative example, a 'featured Ring Tone'.
'Unique RT identifier', 'unique RT list identifier' may be sent as owned object references in ratings, recommendations, and gift and note messages.
'Raw new RT reference', 'catalog unique RT identifier' may be sent as references to new objects in gifts and recommendations.
RTs are similar to RBTs as it pertains to metadata with three exceptions: 1 ) the actual audio clip itself may be stored along with other data in the metadata column 130, 2) type column 129 is set to "RT'Or “RT Collection” as needed 3) a "this is the one played for you” bit indicates that the shared RBT is the one played when you call.
Full tracks are normal audio files that play full songs. Generally these are listened to for enjoyment on an Owner's phone. These full tracks are arranged in 'albums'. Additionally playlist allow for arrangement of single full tracks or albums into a list of full tracks that can be played as a group. Full tracks exist on an owner's phone or even 'in the cloud', which are pointers to full tracks on a third catalog (90) or collection authority (96). New full tracks may be purchased or otherwise obtained from catalogs on a catalog or collection authority These tracks may be 'copy protection free' (which does not imply legal copyright) or 'may be locked to a particular phone using a copy protection scheme.
Copy protected items on an Owner phone may only share title, artist, album (e.g. a playlist could be shared from Owner to AQU that has title, artist, album, an AQU could then rate, recommend, gift or note on this list).
the gift or recommendation can still be a real track that is included in the object or for which a reference to the object in a catalog can be passed
Wallpaper the images shown on a phone's background. Owner may share the wallpaper shown on their phone, and AQU can rate, recommend, gift or note on the wallpaper. AQU can select a gift or recommendation from photos on the AQU phone, from a catalog Authority 90 or collection Authority 96.
the photo itself may be stored as metadata in 130, sent as parameters to processes and be returned in return values of various processes and tables in the system. Generally there are not lists of wallpaper to share.
Owner may share the image shown on their phone, and AQU can rate, recommend, gift or note on the photo.
AQU can select a gift or recommendation from photos on the AQU phone, from a catalog Authority 90 or Collection Authority 96.
the photo itself may be stored as metadata in 130, sent as parameters to processes and be returned in return values of various processes and tables in the system.
Photo galleries Phones often store collections of photos. Owner may share these photos either individually or as albums of photos. And AQU can rate, recommend, gift or note on these images. AQU can select a gift or recommendation from photos on the AQU phone, from a catalog Authority 90 or Collection Authority 96.
the photo itself may be stored as metadata in 130, sent as parameters to processes and be returned in return values of various processes and tables in the system. .
Applications (apps). Software applications such as games, productivity apps etc. may be shared, recommended, rated gifted or noted using this disclosure. Apps can be either free to copy from phone to phone or may be copy protected. If copy protected, Owner may share information such as title and description. If not copy protected they may share the file itself. Gifts and recommendations may be references Catalog (90)or Collection(96) Authorities, or if copy is allowed the actual application file.
the application itself may be stored in the database, sent as parameters to processes and be returned in return values of various processes and tables in the system.
This disclosure may be used to rate, recommend, gift, or send notes about objects that are not stored on the phone. This includes physical goods such as concert tickets or toasters.
Owner may share descriptions of these items, AQU may send gifts not related to any object or it can send gifts or recommendations related to the shared description.
the system would store a pointer to the gift or recommendation that may exist in tables on 40, 90 or 97.
the Owner may supply a physical address as to where to send the gift. (E.g. a US Mail address.
the current disclosure may interact with 'what I heard'.
the 'what I heard' (or played) determination after a phone call completes provides Object reference and metadata that can be used to send and receive messages.
Figure 6 shows a 'what I heard determination' followed by recommendation from the AQU to the Owner that he replace his recommendation. Additionally figure 6 shows how a 'carrier' can consist of various APIs and servers, each providing a different functionality to both of these disclosures.
Phone OS (6001 ) is a mobile phone's operating system that generates a call completion event. The function and setting of the Phone OS is described in 'what I heard'.
6002 is a software/apparatus that embodies the 'what I heard' application as described in 'what I heard' and also embodies API calls through the internet from the mobile phone to the message server 40 in the current application. Illustrative output from this combined software/apparatus is shown in figures 7 and 7a.
6003 is the 'what I heard' server 30 in 'what I heard'. Its function is to take phone numbers and return the RBT that was played or heard (depending on whether on the AQU or Owner side). This return value has metadata including an Object reference of this RBT track.
6004 is the messaging server 40 as described in the current disclosure.
6005 through 6007 are servers and services provided by a carrier, called ' Carrier X' (6008).
6005 is the RBT Authority as described in 'what I heard'. It returns the full RBT record that includes metadata and playing rules of the Owner phone.
the 'what I heard' server 6003 interprets this record to produce a 'what I heard' determination.
6006 is the catalog authority 90 as described in this disclosure. It is highly possible that the RBT Authority 6005 accesses an internal version of the catalog authority as it assembles the full RBT record to be returned to 6003. (This illustrative example assumes that at a minimum, the object references and metadata returned and accessed by both servers are identical.).
6007 is the payment service attached to catalog authority 6006.
the first phone call from AQU to Owner completes in step 6010. Steps 6010 through 6020 are described in 'what I heard'. It starts with a trigger event (202A in 'what I heard') through to a 'what I heard' determination and then, let's say it is shown in a 'pop-up' display of type 217N in 'what I heard').
the Phone OS sends a 'call completion' event via 601 1 to the software/apparatus in 6002. 6002 sends a 'what I heard' API call 6012 to the 'what I heard' server in 6003.
6003 sends a request for the RBT record for the owner phone (the one that just played the RBT for the Owner phone) via 6013 to the RBT Authority in 6005.
the RBT Authority requesting metadata for the tracks in the RBT record from the catalog authority 6006 via 6014.
6015 returns the metadata to the RBT authority 6005.
the RBT Authority 6005 returns the full RBT record to the 'what I heard' server 6003 via 6016.
the 'what I heard server' 6003 processes this RBT record, applying the AQU phone number to this record to determine 'what I heard'. It then returns a 'what I heard' determination complete with Miata Data and an Object Reference relevant to the catalog authority 6006 to the software/apparatus on the mobile phone 6002 via 6017.
the software/apparatus on the mobile phone then requests a 'call pair by AQU' check, process 245 in the current disclosure to retrieve messages previously sent by AQU to Owner about this RBT. It uses the Object reference returned in 6017 when it sends the request to the catalog authority 6006 via 6018. Note since the software/apparatus has all needed metadata from 6017(and the Owner side also has this data), there is no need to send or request metadata via 245. The Catalog authority in 6006 returns that there had not been any pervious messages via 6019.
the return value for 6019 indicates if there are sub- messages, messages from this Owner or any other phone number or message sent acknowledgement to this Owner or any other phone number, waiting to be picked up. (I.e. whether to call 'overall message queue retrieval' 250. since this 6019 indicates there are no messages, 250 is not called here.
Step 6020 displays the 'what I heard' metadata from 6017 along with the fact that no recommendation been sent. The results of this can be seen in the illustrative output of 8000 (top the) and 8001 (top portion). In 8000 note 'you did not recommend' (in both 8000 and 8001 note that there are no messages at the bottom 'messages area' (in 8001 it is the white area below the last blue area). The middle portion of 8000 shows previous calls sent or received by the AQU. [00531] Sometime later, this AQU decides that he or she would like to recommend that the Owner purchase (and play) a different RBT to the one returned in 6017. This is step 6021 .
the AQU starts off browsing the catalog (there could have been featured RBTs or RBTs recommended by the system that this AQU could have chosen from too).
the request to browse that catalog is sent by the software/apparatus 6002 to the catalog authority 6006 via 6023. Note, in reality this browse function would have included many 6023/6024 pairs as the AQU went from genre to genre, artist to artist, album to album etc. in an attempt to choose a new RBT.
the catalog authority returns a list of objects via 6024 to 6002.
the AQU selects one of the items from the list returned in 6024, sending the new (recommended) RBT object reference along with a reference to the original RBT and both the AQU and Owner phones in 6025 to messaging server 6004.
the new RBT object (as well as the original RBT) indicates that the specific catalog authority, the one associated with Carrier X, is the source of the new RBT. (Different for instance from the catalog authority related to AQUs carrier).
6025 is an action by owner, 260, specifying 'recommendation'.
Messaging server 6006 returns that the message was received by sending an 'OK' response in 6026
8002 through 8004 show illustrative examples of the decision by the AQU to send a recommendation to replace the RBT just heard.
AQU would have pressed 'interact with friend 6463150250' in 8001 to access the list of options on interacting with the owner in 8002.
AQU would then have pressed 'recommend new RBT' on 8002 to cause the browse request 6023 to have occurred.
8003 is the result of that browse request and shows a catalog of RBTs on Carrier X's catalog authority 6006.
AQU would have selected as a recommendation, 'Teenage Dream' to replace the current 'Love Shack' to display the confirmation page 8004. Pressing 'OK' on 8004 sends 6025 to the messaging server 6004 for Owner to pick up as the recommendation to replace 'Love Shack'.
the call completion event for the second call is sent to the software/apparatus in 6002 via 6031 .
These new steps access the same Owner RBT record as those previous to determine 'what I played' (on the owner side that plays the RBT for the AQU) rather than 'what I heard'.
This 'what I played' determination with metadata and Object reference is returned in 6037. Note that it is the same track as that returned in the 'what I heard' to the AQU phone.
the software/apparatus in 6002 polls for messages related to this object (the RBT) by sending a 'call pair by owner' query to the messaging server 6004 via 6038. This time, there is a message associated to this object that was sent via 6018, the recommendation from the AQU to replace the track just played by the owner. This is picked up and returned to the software/apparatus, 6002 via 6039.
the 'message waiting bit' in 6039 indicates there are sub-messages and sends out 6040 to retrieve these waiting messages to the messaging server 6004. These messages could have been from any AQU or also have been acknowledgment messages for messages sent by Owner to this AQU or any other AQU. However, in this case it happens to have the same message returned in 6039 that is 'recommendation from AQU received'. This is returned to the software/apparatus 6002 in 6041 .
8005 and 8006 show alternate illustrative examples of 6042.
8005 shows a graphical view of the metadata for this incoming call in the upper portion. It also shows 'they recommended Teenage Dream' here. Additionally, the message received in 6041 is shown at the bottom. This area would have also shown other messages sent to or received from various other phones.
pressing 'interact' on 8005 brings the user to a more detailed page 8006.
the same metadata is shown in a text format. Note here that the messages at the bottom show an 'accept' button next to the message for this recommendation.
the Owner decides to accept the recommendation.
the messaging server 6004 receives this. It sends a purchase request to the catalog authority 6006 via 6045.
the catalog authority 6006 sees the purchase request and forwards it to this carrier X's purchase server in 6007 via 6046.
the purchase server 6007 performs the purchase of this recommended item for this owner and sends an 'OK' response back to the catalog authority 6006 via 6047. 6006 forwards the OK back to the messaging server 6004 via 6048.
6006 sets the state of the original recommend in table 120 to 'accepted' and queues both an 'ACK' message back to Owner and an 'accepted' message back to the AQU. An 'OK' is sent back to the software/apparatus 6002 via 6049.
Pressing the 'accept' button in 8006 shows an illustrative example of accepting a recommendation. Pressing this allows the Owner to both purchase the recommended 'teenage dream' and to indicate to the AQU that his or her recommendation was accepted. Pressing this brings the Owner to 8007 where they can confirm the purchase. Pressing 'Buy' starts a joint purchase and message send operation in 6044.
the AQU may now see that his or her recommendation has been accepted during the third call, 6050.
the AQU again calls the owner, seeing the same 'what I heard' as the first call (6010).
Steps 6051 through 6054 are a condensed version of 6012 through 6017, producing the same 'what I heard', the same metadata and the same Object reference.
a call is made in 6055 to retrieve messages that the AQU had previously sent.
6055 is received by the message server 6004.
6004 returns the same 'recommendation' that was sent originally in 6018; however, the state of the message shows 'recommendation accepted'. It returns it in 6056 to 6002. This return also indicates that there is a waiting sub-message.
6057 retrieves this sub-message.
6046 had queued this recommendation accept message and it returns it in 6058.
6059 displays the metadata for this heard RBT along with the original recommendation and the accept sub-message.
8008 shows an illustrative example of this display. Note the original recommendation in the top box, and, in the white area below, the 'recommendation accept' message
Processes 200 through 280 are supported by the messaging server 40 and are available not only the AQU and Owner phones, but to any server that has internet service. This server is shown as element 70.
phone numbers may be any arbitrary string. In the case of actual phones they are generally 'global phone numbers', however, in the case of use by a server 70 they may be for instance 'Pepsi ad server'. Indeed any agreed upon value may be used as a key to saving and retrieving messages in tables 120 and 140.
Server 70 may originate messages to various phones by calling process 200. Additionally any phone may send a message 200 to a server 70. Server 70 polls for messages using 230, 240, 245 and 250. It may respond to messages using action 260. Additionally, process 200 and 260, when originated from the phone, may send notifications to server 70 informing it that it should pick up messages. These notifications specify to server 70 origination phone number, object reference and whether to user a 230, 245 or 250 to pick up the message. (250 is used if there is no object reference).
varying levels of permissions may be granted by the Owner or a third party to AQU.
Owner may allow complete access to a complete music library through a digital media player or viewer on his mobile device.
the APIs of the digital media player may then interact with the system to allow AQU to take certain actions with the objects to which he has been granted access.
Owner may specify that other parties may only access a portion of his music library.
Owner may give permission only to certain file types, folders, or files.
Owner may signal to other parties that he has granted them access or the other parties may request access to these objects from the Owner.
Owner may grant permission to access objects directly on his phone.
FIG 8 is a high-level block diagram showing an example architecture of a mobile device.
the mobile device includes processor(s) 852 and a memory 854 coupled to an interconnect 856.
the interconnect 856 shown in Figure 8 is an abstraction that represents any one or more separate physical buses, point to point connections, or both, connected by appropriate bridges, adapters, or controllers.
the processor(s) 852 may include central processing units (CPUs) of the mobile device and, thus, control the overall operation of the mobile device by executing software or firmware.
CPUs central processing units
the processor(s) 852 may be, or may include, one or more programmable general-purpose or special-purpose microprocessors, digital signal processors (DSPs), programmable controllers, application specific integrated circuits (ASICs), programmable logic devices (PLDs), or the like, or a combination of such devices.
DSPs digital signal processors
ASICs application specific integrated circuits
PLDs programmable logic devices
the memory 854 represents any form of fixed or removable random access memory (RAM), read-only memory (ROM), flash memory, or the like, or a combination of such devices.
the software or firmware executed by the processor(s) may be stored in a storage area 860 and/or in memory 854, and typically include an operating system 858 as well as one or more applications 868.
Data 870 utilized by the software or operating system is also stored in the storage area or memory.
the storage area 860 may be a flash memory, hard drive, or other mass-storage device.
the mobile device includes an input device 862, which enables a user to control the device.
the input device 862 may include a keyboard, trackpad, touch- sensitive screen, or other standard electronic input device.
the mobile device also includes a display device 864 suitable for displaying a user interface, such as the display.
a wireless communications module 866 provides the mobile device with the ability to communicate with remote devices over a network using a short range or long range wireless protocol.
FIG 9 is a front view of a mobile device 950 suitable for processing.
the mobile device 950 may include a housing 951 , a plurality of push buttons 952, a directional keypad 954 (e.g., a five-way key), a microphone 955, a speaker 956, and a display 960 carried by the housing 951 .
the mobile device 950 may also include other microphones, transceivers, photo sensors, and/or other computing components generally found in PDA phones, cellular phones, smartphones, portable media players, portable gaming devices, portable email devices (e.g., Blackberrys), or other mobile communication devices.
the display 960 includes a liquid-crystal display (LCD), an electronic ink display, and/or other suitable types of display configured to present a user interface.
the mobile device 950 may also include a touch sensing component 959 configured to receive input from a user.
the touch sensing component 959 may include a resistive, capacitive, infrared, surface acoustic wave (SAW), and/or another type of touch screen.
the touch sensing component 959 may be integrated with the display 960 or may be independent from the display 960.
the touch sensing component 959 and the display 960 have generally similar sized access areas. In other embodiments, the touch sensing component 959 and the display 960 may have different sized access areas.
the touch sensing component 959 may have an access area that extends beyond a boundary of the display 960.
the mobile device 950 also includes a 12-key numerical keypad 962 capable of receiving text or numerical input from a user.
the mobile device 950 may include a full QWERTY keyboard for receiving user input.
the mobile device 950 may also provide a software keyboard or keypad on the display 960 to enable a user to provide text or numerical input through the touch-sensing component 959.

Landscapes

Engineering & Computer Science (AREA)
Signal Processing (AREA)
Quality & Reliability (AREA)
Telephonic Communication Services (AREA)
Information Transfer Between Computers (AREA)

PCT/US2013/031798 2012-06-22 2013-03-14 Envoi et réception de métadonnées contenant des références à des supports numériques ou des biens de consommation entre abonnés appelants Ceased WO2013191770A1 (fr)

Applications Claiming Priority (6)

Application Number	Priority Date	Filing Date
US201261663394P	2012-06-22	2012-06-22
US201261663479P	2012-06-22	2012-06-22
US201261663418P	2012-06-22	2012-06-22
US61/663,394		2012-06-22
US61/663,479		2012-06-22
US61/663,418		2012-06-22

Publications (1)

Publication Number	Publication Date
WO2013191770A1 true WO2013191770A1 (fr)	2013-12-27

Family

ID=49769180

Family Applications (2)

Application Number	Title	Priority Date	Filing Date
PCT/US2013/030564 Ceased WO2013191755A1 (fr)	2012-06-19	2013-03-12	Procédé obtenant l'identification d'une tonalité de rappel et d'autres informations de paires d'appels sur des combinés d'appel entrants et sortants
PCT/US2013/031798 Ceased WO2013191770A1 (fr)	2012-06-22	2013-03-14	Envoi et réception de métadonnées contenant des références à des supports numériques ou des biens de consommation entre abonnés appelants

Family Applications Before (1)

Application Number	Title	Priority Date	Filing Date
PCT/US2013/030564 Ceased WO2013191755A1 (fr)	2012-06-19	2013-03-12	Procédé obtenant l'identification d'une tonalité de rappel et d'autres informations de paires d'appels sur des combinés d'appel entrants et sortants

Country Status (1)

Country	Link
WO (2)	WO2013191755A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number	Priority date	Publication date	Assignee	Title
WO2016069951A1 (fr) *	2014-10-30	2016-05-06	Alibaba Group Holding Limited	Procédé et système de mise en cache et de transmission de contenu
US12425461B2 (en)	2023-03-03	2025-09-23	T-Mobile Usa, Inc.	Enabling a first mobile device associated with a wireless telecommunication network to receive assistance from a second mobile device in a shared web page

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number	Priority date	Publication date	Assignee	Title
US10127604B2 (en) *	2014-08-27	2018-11-13	Verizon Patent And Licensing Inc.	Identification and caller options relating to custom ringback audio

Citations (5)

* Cited by examiner, † Cited by third party
Publication number	Priority date	Publication date	Assignee	Title
US20060240851A1 (en) *	2003-03-21	2006-10-26	Vocel, Inc.	Interactive messaging system
KR20070089335A (ko) *	2006-02-28	2007-08-31	이재영	휴대단말기의 사진 공유와 코멘트 추가방법 및 그 장치
KR20070113738A (ko) *	2006-05-26	2007-11-29	엠브릿지 주식회사	국제 문자메시지 서비스 방법
US20080032723A1 (en) *	2005-09-23	2008-02-07	Outland Research, Llc	Social musical media rating system and method for localized establishments
US20100223095A1 (en) *	2009-02-27	2010-09-02	Craig Ranta	Pushed Ringtones Based on Device-Side Content

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number	Priority date	Publication date	Assignee	Title
US7889853B2 (en) *	2004-07-27	2011-02-15	At&T Intellectual Property I, L.P.	Methods, systems, devices, and products for providing ring backs
US7839995B2 (en) *	2005-01-28	2010-11-23	Alcatel-Lucent Usa Inc.	Change to playback characteristic of ringback tone
US7620160B2 (en) *	2005-07-05	2009-11-17	Microsoft Corporation	Announcing presence information during telephone call ringback
CN100486277C (zh) *	2005-11-23	2009-05-06	苏成春	彩景式回铃/来电显示方法
US8315920B2 (en) *	2010-03-09	2012-11-20	At&T Intellectual Property I, L.P.	Method for automating onboarding of user generated ringback tones to sales distribution channel

2013
- 2013-03-12 WO PCT/US2013/030564 patent/WO2013191755A1/fr not_active Ceased
- 2013-03-14 WO PCT/US2013/031798 patent/WO2013191770A1/fr not_active Ceased

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number	Priority date	Publication date	Assignee	Title
US20060240851A1 (en) *	2003-03-21	2006-10-26	Vocel, Inc.	Interactive messaging system
US20080032723A1 (en) *	2005-09-23	2008-02-07	Outland Research, Llc	Social musical media rating system and method for localized establishments
KR20070089335A (ko) *	2006-02-28	2007-08-31	이재영	휴대단말기의 사진 공유와 코멘트 추가방법 및 그 장치
KR20070113738A (ko) *	2006-05-26	2007-11-29	엠브릿지 주식회사	국제 문자메시지 서비스 방법
US20100223095A1 (en) *	2009-02-27	2010-09-02	Craig Ranta	Pushed Ringtones Based on Device-Side Content

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number	Priority date	Publication date	Assignee	Title
WO2016069951A1 (fr) *	2014-10-30	2016-05-06	Alibaba Group Holding Limited	Procédé et système de mise en cache et de transmission de contenu
CN105634981A (zh) *	2014-10-30	2016-06-01	阿里巴巴集团控股有限公司	内容缓存和传输方法及其系统
US12425461B2 (en)	2023-03-03	2025-09-23	T-Mobile Usa, Inc.	Enabling a first mobile device associated with a wireless telecommunication network to receive assistance from a second mobile device in a shared web page

Also Published As

Publication number	Publication date
WO2013191755A1 (fr)	2013-12-27

Publication	Publication Date	Title
EP2444929B1 (fr)	2016-08-31	Equipement portable, réseau social et procédé pour partager des informations
US9002410B2 (en)	2015-04-07	Method and apparatus for creating, using, and disseminating customized audio/video clips
KR101561728B1 (ko)	2015-10-19	파일 전송을 통해 소셜 네트워크를 확립하기 위한 방법 및 장치
US9893908B2 (en)	2018-02-13	System and method to facilitate real-time communications and content sharing among users over a network
US9081827B2 (en)	2015-07-14	Digital file distribution in a social network system
RU2494464C2 (ru)	2013-09-27	Не зависимое от оператора, устройства и платформы агрегирование, межплатформенное преобразование, задействование и распространение каталогов пользовательских действий
EP2158552B1 (fr)	2018-11-07	Agrégation et recherche de données de profil provenant de plusieurs services
US7680699B2 (en)	2010-03-16	Method, system, and medium for sharing digital content and purchasing products at live performances
US20040181540A1 (en)	2004-09-16	System and method for the provision of socially-relevant recommendations
CN101702795A (zh)	2010-05-05	共享权限使能的移动简档的系统和方法
CN102713892B (zh)	2016-09-14	用于全局目录服务的系统和方法
CN101631311A (zh)	2010-01-20	用于共享权限启用的移动简档的简档服务
JP6751474B2 (ja)	2020-09-02	統合識別子及びユーザインタフェースのための端末、サービス方法及び統合識別子管理システム
CN102945239A (zh)	2013-02-27	基于位置的交换所搜索
WO2013191770A1 (fr)	2013-12-27	Envoi et réception de métadonnées contenant des références à des supports numériques ou des biens de consommation entre abonnés appelants
US20120117197A1 (en)	2012-05-10	Content auto-discovery
JP2005158028A (ja)	2005-06-16	プレゼント贈答システム、プレゼント贈答サーバシステム、プレゼント贈答プログラムおよびプレゼント贈答方法
KR101752786B1 (ko)	2017-06-30	친구찾기 방법 및 이를 위한 시스템
JP4396404B2 (ja)	2010-01-13	コンテンツ提供システム、その方法、サーバおよびプログラム
KR100592706B1 (ko)	2006-06-26	Ｗｅｂ 연동된 ａｒｓ 기반의 모바일 음악 컨텐츠제공시스템
EP2199968A1 (fr)	2010-06-23	Service laissant les fournisseurs télécharger vers la base de données des demandes anonymes
NL2009621C2 (en)	2014-04-15	Method and device for retrieving information related to at least one content item selected by a user.
CN102469417A (zh)	2012-05-23	将手机终端本地音乐设置成彩铃的方法和系统
KR20070001348A (ko)	2007-01-04	멀티미디어 데이터의 재판매 방법
JPWO2004086237A1 (ja)	2006-06-29	ホームページ管理システム、およびホームページ管理方法

Legal Events

Date	Code	Title	Description
2014-02-19	121	Ep: the epo has been informed by wipo that ep was designated in this application	Ref document number: 13806759 Country of ref document: EP Kind code of ref document: A1
2014-12-22	NENP	Non-entry into the national phase	Ref country code: DE
2015-08-19	32PN	Ep: public notification in the ep bulletin as address of the adressee cannot be established	Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205N DATED 27/02/2015)
2016-01-06	122	Ep: pct application non-entry in european phase	Ref document number: 13806759 Country of ref document: EP Kind code of ref document: A1