PTO/SBl16 (12-04)
`Approved for use through 07/31/2006. OMB 0651-0032
`U.S. Patent and Trademark Office; U.S. DEPARTMENT OF COMMERCE
`Under the Paperwork Reduction Act of 1995, no persons are required to respond to a collection of information unless it displays a valid OMB control number.
`PROVISIONAL APPLICATION FOR PATENT COVER SHEET
`This is a request for filing a PROVISIONAL APPLICATION FOR PATENT under 37 CFR 1_53(c).
`Express Mail LabelNo.
`lNVENTOR(S)
`Family Name or Sumame
`
`Given Name (first and middle [if any])
`
`Residence
`and either State or Forein Count
`
`Ci
`
`James M.
`Bfian
`
`Dabbs Ill
`Claise
`
`Stockbridge, GA
`Alpharetta, GA
`
`separately numbered sheets attached hereto
`Additional inventors are being named on the
`TITLE OF THE INVENTION (500 characters max):
`
`METHOD AND APPARATUS FOR EFFICIENT AND RELIABLE GROUP ALERTING
`
`' _
`
`,04
`
`60/636'!
`
`Direct all conespondence to:
`
`CORRESPONDENCE ADDRESS
`
`The address corresponding to Customer Number:
`
`001 609
`
`OR
`
`::,i,r;,r,1,£:,a. Name Roylance, Abrams, Berdo & Goodman, L.L.P.
`Address
`1300 19th Street, N.W., Suite 600
`
`.
`
`C°“'“'V u.s.A.
`
`T°'ePh°"° (202)659-9076
`ENCLOSED APPLICATION PARTS (check all that apply)
`
`Fax (202)659-9344
`
`I:I Application Data Sheet. See 37 CFR 1.76
`Specification Number of Pages
`29
`4
`Drawing(s) Number of Sheets
`Application Size Fee: It the specification and drawings exceed 100 sheets of paper, the application size fee due is $250 ($125 for
`small entity) for each additional 50 sheets or fraction thereof. See 35 U.S.C. 41(a)(1)(G) and 37 CFR 1.16(s).
`
`CI CD(s), Number of cos
`CI Other (specify)
`
`METHOD OF PAYMENT OF FILING FEES AND APPLICATION SIZE FEE FOR THIS PROVISIONAL APPLICATION FOR PATENT
`
`CI Applicant claims small entitystatus. See 37 CFR 1.27.
`A check or money order is enclosed to cover the filing fee and application size fee (if applicable).
`I:I Payment by credit card. Form PTO-2038 is attached
`The Director is hereby authorized to charge the filing fee and application size fee (if applicable) or credit any overpayment to Deposit
`Account Number:
`18'2220
`. A duplicative copy of this fonn is enclosed for fee processing.
`The invention was made by an agency of the United States Government or under a contract with an agency of the United States Government.
`- No.
`I: Yes, the name of the U.S. Government agency and the Government contract number are:
`
`TOTAL FEE AMOUNT $)
`$100.00
`
`/
`
`SIGNATURE
`December 16, 2004
`Date
`3‘
`TYPED or PRINTED NAME
`REGISTRATION NO.
`33.952
`if a
`ropriale
`TELEPHONE
`(202) 559'9°75
`Oocfigt Number:
`47726
`USE ONLY FOR FILING A PROVISIONAL APPLICATION FOR PATENT
`This collection of information is required by 37 CFR 1.51. The information is required to obtain or retain a benefit by the public which is to file (and by the USPTO
`to process) an application. Confidentiality is governed by 35 U.S.C. 122 and 37 CFR 1.11 and 1.14. This collection is estimated to take 8 hours to complete.
`including gathering, preparing, and submitting the completed application form to the USPTO. Time will vary depending upon the individual case. Any comments
`on the amount of time you require to complete this fonn andlor suggestions for reducing this burden, should be sent to the Chief Information Officer, US, Patent
`and Trademark Office, U.S. Department of Commerce. PO. Box 1450. Alexandria, VA 22313-1450. DO NOT SEND FEES OR COMPLETED FORMS TO THIS
`ADDRESS. SEND TO: Commissioner for Patents, P.O. Box 1450, Alexandria, VA 22313-1450.
`If you need assistance in completing the form, call 1-800—PTO-9199 and select option 2.
`
`9’
`
`General Electric Co. 1014 - Page 001
`
`

`
`Patent Application
`
`for
`
`METHOD AND APPARATUS FOR EFFICIENT AND RELIABLE GROUP
`
`ALERTING
`
`by
`
`James M. Dabbs HI
`
`and
`
`Brian Claise
`
`Detailed Description of the Preferred Embodiments
`
`[0001] Overview
`
`[0002] A method is described for reliable, wireless group alerting. In this system,
`
`an encrypted message is broadcast to a group address. This message is received by a
`
`number of mobile receivers, each. of which then acknowledges back to the system,
`
`decrypts the message, displays it to the user, and allows the user to respond. The
`
`system comprises a database, switch, a wireless network, and a plurality of intelligent
`
`mobile receivers. It employs centralized management to simplify the role of the
`
`mobile users and administrators, minimizing configuration and operational human
`
`errors that would otherwise result in confusion or lost messages. It also employs novel
`
`mechanisms to compress the responses from the receivers to use minimal airtime. The
`
`system is particularly relevant to public safety and critical infrastructure operators,
`
`where large group dispatches must be delivered quickly and deterrninistically to a
`
`heavily distracted mobile workforce, and their responses must be delivered to the
`
`dispatch center efficiently. As such, this system provides a comprehensive,
`
`meaningful solution to support distracted users with simple, resilient group
`
`messaging.
`
`General Electric Co. 1014 - Page 002
`
`

`
`[0003]
`
`System Description
`
`[0004] With reference to Fig. 1, a central switching system (‘Switch’) connects to
`
`a Wireless Network and communicates with a number of subscriber devices
`
`(‘Receivers’) such as pagers, cell phones, or wireless personal data assistants. Each
`
`Receiver contains one identifying Primary Address and multiple Group Addresses,
`
`and is capable of receiving broadcast alert messages directed to any of its addresses.
`
`The Switch contains a Receiver Database describing receivers, their group
`
`membership, and connects to a Wireless Network, such as a PCS network employing
`
`cell broadcast, a paging network, or a broadcast-capable data network employing
`
`group addressing.
`
`[0005] With reference to Fig. 2, the Receiver Database comprises an independent
`
`table of Receivers and an independent table of Groups. Each Receiver row contains an
`
`identifying personal address, as well as other information specific to a single device
`
`and its Wireless Network architecture. Each Group row contains an identifying group
`
`address, an encryption key, and a symbolic name. A dependent table, Membership,
`
`provides the many-to-marry relationship between Receiver and Group rows. Each
`
`Membership row assigns one receiver to one group. Membership rows contain
`
`GroupAddress and Persona1Address columns, identifying a Group and Receiver row,
`respectively. Each Membership row also contains a ReceiverGroupNumber column, a
`
`small mnemonic value that uniquely identifies the Group from other Groups
`
`programmed into the same Receiver, and CC (‘carbon copy’) flag to define specific
`
`behavioral aspects of the Receiver. Receivers do not respond to messages received by
`
`group addresses if their CC flag is set, while they can respond to messages received
`
`by group addresses with if their CC flag is clear. This mechanism allows users to
`
`monitor alerts to specific groups, without expectation by the source of the alerts for a
`
`response.
`
`[0006] As administrative changes occur to the Receiver Database, configuration
`transactions areexecuted over the air with individual Receivers to synchronize their
`
`configuration memory with the Receiver Database. The system therefore maintains an
`
`up-to-date image in each the configuration memory of each Receiver, including a list
`
`General Electric Co. 1014 - Page 003
`
`

`
`_3_
`
`of Group addresses, their ReceiverGroupNumber values, their symbolic names,
`
`encryption keys, and CC flags.
`
`[0007] A ‘Client’ (e.g., a computer—aided dispatch center, a human user, or other
`
`network client) uses this system to broadcast alert messages to groups of Receivers.
`
`To do so, the client composes a message, including display content and a list of
`
`response strings. The Client then connects to the Switch and requests transmission of
`
`the message to a particular group name. Depending on architecture of the Wireless
`
`Network, either the Client or the Wireless Network assigns an identifying field to the
`
`message such that user responses can be associated with the correct message.
`
`[0008] Upon receipt of the message, the Switch responds to the Client with
`
`detailed information on the group such as a list or a count of group members. It then
`encrypts the Group Message, assigns a cyclical message sequence number, and
`
`transmits the message to the Group Address.
`
`[0009] Upon receiving the Group Message, the Receivers decrypt the message
`
`and display the content, group name, and multiple choice options to the user. Each
`Receiver with a CC flag of falseltransmits one or more acknowledgement codes
`
`through the Network back to the Switch, specifying message received, message read
`
`notifications, and enumerated multiple-choice responses. The datagrarn carrying the
`
`acknowledgement code also includes the personal address of the receiver, the
`
`ReceiverGroupNumber of the group address, and the message sequence number of the
`
`message, which together efficiently and uniquely identify the specific group message
`
`at the specific Receiver.
`
`[0010]
`
`Each receiver provides a configuration display for the user. This display
`
`allows the user to specify, by group name, how notification should occur for messages
`
`received by each group address. Similarly, the Switch provides an administrative
`
`human interface that allows a system administrator to set up and maintain the
`
`Receivers belonging to each Group.
`
`[001 1] An Exemplary Computer Aided Dispatch (CAD) System
`
`[0012]
`
`The foregoing system description discusses the high-level organization and
`
`data flow of a group messaging system that can use any of a variety of network types.
`
`General Electric Co. 1014 - Page 004
`
`

`
`With reference to Figs. 3, 4 and 5, the following is a description of an exemplary type
`
`of network, that is, a ReFLEX “two-way” paging network that incorporates the new
`
`group messaging layer of the present invention. Fig. 3 is a Sparkgap campus server or
`
`network controller which is configured to implement group messaging in accordance
`
`with the present invention. Fig. 4 illustrates the use of a Sparkgap network controller
`
`in a system configuration similar to Fig. 1. Fig. 5 illustrates another exemplary
`
`system configuration.
`
`[0013]
`
`The Sparkgap network controller in Fig. 3 provides private two-way
`
`paging, mobile data, and wireless email over inexpensive channel pairs in the 800/900 ‘
`
`ESMR band. Coverage can be configured for a single building, multiple counties, or
`
`state-wide service, supporting small user devices such as pagers and personal data
`
`assistants (PDAs) with Motorola’s proprietary ReFLEX protocol. Since the Sparkgap
`
`server provides encrypted acknowledgement paging, responders reply immediately to
`
`CAD events and other messages directly from their pagers, and AES encryption
`
`protects all transmissions. Since the Sparkgap server supports mobile applications,
`
`law enforcement officers can use PDAs to connect wirelessly with municipal, state,
`
`and federal databases to run license checks, warrants, and other mobile applications.
`
`Further, the Sparkgap server is useful for automatic vehicle location. Small,
`
`inexpensive GPS sending units can monitor vehicles and heavy equipment, sending
`
`real-time location and status information on a 24/7 basis. The Sparkgap server can
`
`also support wireless e-mail. Users can send and receive secure, wireless email using
`
`pagers and PDAs.
`
`[0014]
`
`The Sparkgap server can support one base station or hundreds of base
`
`stations, each consisting of a standard 900MHz paging transmitter and ReFLEX base
`
`receiver. A single station covers a 7—20 mile radius, and a network can coordinate
`
`multiple stations using simulcast or cellular arrangements to optimize coverage and
`
`capacity. A single channel pair can serve thousands of users, and multiple channels
`
`can be aggregated for additional capacity. Even under worst—case peak conditions,
`
`ReFLEX uses centralized arbitration to prevent contention and channel overloading.
`
`General Electric Co. 1014 - Page 005
`
`

`
`-5-
`
`[0015]
`
`The Sparkgap server maintains a full packet data layer on top of the
`
`toughest and most reliable communication technology available, that is, paging, and it
`
`leverages this foundation into a balanced set of features, coverage, and capacity. The
`
`Sparkgap server connects directly to computer-aided dispatch (CAD) systems,
`
`provides low latency messaging with virtually unbreakable security, and operates with
`
`the lowest cost-per-user and cost-per-coverage-area of any wireless data solution
`
`available. For additional resilience, redundant hot standby units maintain network
`
`operation even under catastrophic circumstances, keeping first responders connected
`
`when they’re needed most.
`
`[0016] As stated previously, Sparkgap is a ReFLEX network solution designed to
`
`control one or more base stations and provide two-way paging and mobile data
`
`coverage over an arbitrary geographical area. While this solution is similar in some
`
`ways to traditional one-way paging, two-way paging also differs significantly fi'0m its
`
`one-way counterpart. Two-way pagers acknowledge and reply to messages they
`
`receive, and they can originate their own messages. These additional capabilities
`
`outperform traditional paging input protocols (e.g., SNPP, TAP and TNPP). In
`
`addition, while suitable second generation paging protocols exist (e.g., SMTP, SMPP,
`
`and WCTP), these newer protocols add significant complexity and introduce latency
`
`unsuitable for public safety and similar communications applications.
`
`[0017]
`
`In accordance with an aspect of the present invention, a Sparkgap Dispatch
`
`Protocol (SDP) is provided as a streamlined means for a computer aided dispatch
`
`(CAD) system to communicate with two-way pagers on a Sparkgap ReFLEX
`
`network. It is to be understood, however, that the group messaging of the present
`
`invention can be implemented using other types of protocols and network devices.
`
`The SDP of the present invention is a transactional, TCP/IP protocol where the CAD
`
`system is the client and the Sparkgap is the server. It features synchronous, client-
`
`initiated request/response transactions as well as asynchronous server-driven events,
`
`minimizing latency and complexity and delivering a rational solution to the public
`
`safety space.
`
`General Electric Co. 1014 - Page 006
`
`

`
`-5-
`
`[0018] With further reference to Fig. 4, when employing SDP, the CAD system
`
`client connects to the Sparkgap server using TCP/IP on port 55000. The CAD system
`
`initiates transactions with the Sparkgap using a synchronous request/response model,
`
`that is, — the CAD system sends the Sparkgap a request, the Sparkgap takes an action,
`
`and then the Sparkgap sends the CAD system a response. Additionally, in order to
`
`minimize latency in delivering responses from the pagers, the Sparkgap server also
`
`sends asynchronous event notifications to the CAD system regarding message
`
`progress and responses from individual pagers.
`
`[0019]
`
`The SDP will now be described in further detail. A description of protocol
`
`data units, transactions and events follows.
`
`[0020]
`[0021]
`
`1. SDP Protocol Data Units
`SDP requests, responses, and events are implemented as atomic protocol
`
`data units (PDUs) transmitted by the client and server using the TCP/IP network.
`
`PDUs are serialized, and preferably always transmitted contiguously in their entirety.
`
`In other words, a node must never ‘interrupt’ a partially transmitted PDU to begin
`
`another PDU. A PDU is encoded using ASCII plain text, and consists of an
`
`identifying header followed by a collection of name/value attributes enclosed, as
`
`shown below, in curly brackets (braces).
`
`[0022]
`
`1.1 Syntax
`
`[0023] All PDUs are encoded using ASCII plain text according to the following
`
`specification:
`
`[0024] Client-to-server transmission syntax:
`
`[0025]
`
`“request” <request-number> <request—type> “{“ <attribute-list> “}“
`
`[0026]
`
`Server-to-client transmission syntax:
`
`[0027]
`
`“event” <event-type> “{“ <attribute—list> “}“
`
`[0028]
`
`“response” <request-number> “{“ attribute-list “}“
`
`[0029] where,
`
`<request-number>
`<request—type>
`<event-type>
`
`: := <integer>
`::= token
`:
`: token
`
`General Electric Co. 1014 - Page 007
`
`

`
`-7-
`
`<attribute—list>
`<attribute>
`<attribute—name>
`
`<attribute-va1ue>
`<integer>
`<string>
`
`: <attribute> [<attribute-listI
`:
`: := attribute-name ““ attribute-value “;“
`:
`: token
`
`2 := <integer> <string>
`: := Base] 0 Integer Expression
`2
`: string enclosed in double quotes
`
`[0030] An example PDU exchange is illustrated in the following table:
`
`Sparkgap to CAD
`
`CAD to Sparkgap
`request 5066 SendMessage
`
`{ C
`
`adEventID=”#CTYFO41820772”;
`MessagelD=”2004”;
`Destination1D=Fire 1 ;
`Display=”Ca1ling All Cars”;
`A1ertResponse=O;
`ReadResponse=1;
`MCR=”On My Way”;
`MCR=”Busy”;
`MCR=”On Scene”;
`
`Response 5066
`
`{ R
`
`esu1tCode=O;
`ResultText=”Message Queued”;
`} ;
`Event PagerResponse
`
`{ T
`
`imestamp=”O7082004130553EST”;
`Message1D=”2004”;
`CadEventID=”#CTYFO4l820772”;
`PagerlD=”22903 0O20”;
`PagerName=”Doe, John”;
`MessageRead=1 ;
`}.
`
`[0031]
`
`1.2 Attribute Value Types
`
`[0032]
`
`SDP supports two attribute types, with string or integer values. Integer
`
`values are simply unsigned integers with no more than 32 significant bits, described
`
`General Electric Co. 1014 - Page 008
`
`

`
`_g_
`
`using base-10 notation. Strings are simply printable ASCII strings contained in double
`
`quotes, and supporting the following escape sequences:
`
`\n
`
`\r
`
`\\
`\###
`
`New Line
`
`Carriage Return
`Double Quote
`Backslash
`An octal value
`
`[0033]
`
`1.3 The Timestarnp Attribute
`
`[0034] All events contain a timestamp attribute marking the creation of the event.
`
`A timestamp value contains a string in a specific format:
`
`I\/[l\/IDDYYYYI-II-INIMSST
`
`Where
`
`MM is the 2-digit month (1-12)
`DD
`is the 2—digit day of the month (1-31)
`YYYY is the 4—digit year
`HH
`is the 2 digit hour (O-23)
`MM is the 2 digit minute (0-59)
`SS
`is the 2 digit second (0-59)
`T
`is the 1-4 character time zone abbreviation
`
`[0035]
`
`1.4 Attribute Order
`
`[0036]
`
`In some cases, attribute order is significant. For purposes of this document,
`
`receiving nodes are expected to read and decode attributes from first to last in the
`
`PDU.
`
`[0037]
`
`2. Transactions
`
`[0038] A transaction is exchanged on the network as a request from the client,
`
`some action by the server, and a response from the server. SDP includes three
`
`transactions:
`
`Login
`SendMessage
`QueryMessage
`
`General Electric Co. 1014 - Page 009
`
`

`
`[0039]
`
`2.1 Login
`
`[0040]
`
`The Login transaction simple establishes the identity of the CAD client for
`
`purposes of reconnection. Should a TCP/IP connection be broken, the Sparkgap will
`
`queue events awaiting a reconnection.
`
`[0041]
`
`2.1.1 Request
`
`[0042]
`
`The request PDU contains the following attributes:
`
`[0043] User (string, mandatory): This value contains the name or identity of the
`
`CAD system, which much match an entry in the Sparkgap CAD account database.
`
`[0044]
`
`Password (string, optional): This value contains the access password for
`
`the CAD system. If the CAD account is set up without a password, then this attribute
`
`is not required.
`
`[0045] Version (integer, mandatory): This value specifies the protocol version that
`
`the CAD system is requesting for this session. The version is conveyed as the major
`
`number multiplied by 100 and added to the minor number. For this document, this
`
`attribute value is 100.
`
`[0046]
`
`2.1.2 Response
`
`[0047]
`
`The response PDU contains the following attributes:
`
`[0048] ResultCode (integer, mandatory): This value contains the result code of the
`
`transaction.
`
`[0049]
`
`Resu1tText (string, optional): This value contains a human readable
`
`message string describing the result of the transaction.
`
`[0050] Version (integer, mandatory): This value specifies the protocol Version
`
`that the Sparkgap is supporting for this session. The version is conveyed as the major
`
`number multiplied by 100 and added to the minor number. For this document, this
`
`attribute value is 100.
`
`[0051]
`
`System (string, optional): This value contains an identifying description of
`
`the Sparkgap system.
`
`[0052]
`
`2.1.3 Example
`
`General Electric Co. 1014 - Page 010
`
`

`
`-10-
`
`[0053]
`
`This example illustrates a CAD system logging into a Sparkgap as user
`
`“ECD9 1 l,” requesting version 1.0 of the protocol. The Sparkgap grants the login and
`
`acknowledges version 1.0 support.
`
`Sarkga to CAD
`
`Response 5066
`
`{ R
`
`esultCode=O;
`Version—‘—-100;
`Resu1tText=”Connection
`
`Complete”;
`System=”Sparkgap ESN
`04000022”;
`} ;
`
`{ U
`
`ser”ECD91l”;
`Password=”GHTy778”;
`Version=l00;
`}
`
`[0054]
`
`2.2 SendMessage
`
`[0055]
`
`The SendMessage transaction queues a message for delivery for one or
`
`more pager recipients. The transaction only queues the message for processing. As the
`
`message is processed and responses are received, a sequence of events will convey the
`
`results back to the CAD system.
`
`[0056]
`
`2.2.1 Request
`
`[0057]
`
`The request PDU contains the following attributes
`
`[0058] MessagelD (string, mandatory): This value uniquely identifies the message
`
`from the client (CAD) perspective. An identical MessagelD attribute will be included
`
`in all subsequent events related to this message.
`
`[0059]
`
`CadEventlD (string, optional): This value uniquely identifies the
`
`precipitating CAD event. If present, an identical CadEventlD attribute will be
`
`included in all subsequent events related to this message.
`
`General Electric Co. 1014 - Page 011
`
`

`
`-11-
`
`[0060] DestinationlD (string, mandatory): This value specifies the target audience
`
`for the message. The DestinationlD must match the name of a group or individual
`
`user in the Sparkgap database. The PDU may contain multiple Destination1D
`
`attributes, in which case the message will be directed to an aggregated group
`
`representing the net total of all recipients.
`
`[0061] GroupDetail (integer, optional): This value conveys the client’s desire to
`
`receive detailed information about group recipients in the transaction response. If this
`
`field is present and set to a non-zero value, then the response will include a Pagerfl)
`
`and PagerName attribute for each constituent number of the group. If the
`
`GroupDetail attribute is not present or set to zero, then this information will not be
`
`included in the response.
`[0062] Display (string, mandatory): This value contains the actual display
`
`message to be read by message recipients. Multiple Display attributes will be
`
`contained in the order they appear into a single unbroken message.
`
`[0063] AlertResponse (integer, mandatory): If present and set to a non-zero value,
`
`this value instructs the Sparkgap system to notify the CAD client as pagers receive the
`
`message alert their users.
`
`[0064] ReadResponse (integer, optional): If present and set to a non-zero value,
`
`this value instructs the Sparkgap system to notify the CAD client as users display the
`
`message on their pager.
`
`[0065] MCR (string, optional): If present, MCR attributes specify “multiple-
`
`choice responses” to be presented to the user as reply options. Multiple MCR
`
`attributes may be included in the request. The first MCR encountered is number 0, the
`
`second is number 1, and so on. As users reply to the message, the Sparkgap system
`
`will relay appropriate PagerReply events to the CAD client.
`
`[0066]
`
`2.2.2 Response
`
`[0067]
`
`The response PDU contains the following attributes:
`
`[0068]
`
`Resu1tCode (Integer, mandatory): This value contains the result code of
`
`the transaction.
`
`General Electric Co. 1014 - Page 012
`
`

`
`-12-
`
`[0069]
`
`Resu1tText (suing, optional): This value contains a human readable
`
`message string describing the result of the transaction.
`
`[0070] GroupSize: This value specifies the total number or recipient members in
`
`the group.
`
`[0071]
`
`PagerID (Suing, mandatory): This value contains the identification of one
`
`pager in the aggregate destination group. The presence of this atuibute signifies that a
`
`corresponding PagerName attribute will follow. Together, these two fields are
`
`duplicated for each member of the total pager destination group.
`
`[0072]
`
`PagerName (string, optional): The value contains the name of the pager
`
`user corresponding to the last PagerID value.
`
`[0073]
`
`2.2.3
`
`Example
`
`[0074]
`
`This example illustrates a CAD system sending the message “Calling all
`
`cars” to two dispatch groups, Firel and Fire34. The CAD.system requests notification
`
`from each pager when the users read the messages, but not when the pagers alert. The
`
`request includes a CadEvent[D and a MessageID so that the CAD system can
`
`properly categorize forthcoming events related to this message. Sparkgap queues the
`
`message and returns a SllCCCSSfl.1l result code in the response.
`
`CAP to Sparkgap
`
`Sparkgap to CAD
`
`request 5066 sendmessage
`
`{ C
`
`adEventlD=”#CTYFO4 1 820772”;
`MessageID=”2004”;
`DestinationID”Fire1”;
`DestinationlD=”Fire34”;
`GroupDetail=l
`Display=”Ca1ling All Cars”;
`AlertResponse=0;
`ReadResponse=l;
`MCR”On My Way”;
`MCR”Busy”;
`MCR”Already On Scene”;
`
`Response 5066
`{
`
`General Electric Co. 1014 - Page 013
`
`

`
`-13-
`
`Resultcode=O;
`ResultText=”Message Queued”;
`GroupSize=892
`} ;
`
`[0075]
`
`2.3 QueryMessage
`
`[0076]
`
`The CAD client initiates a QueryMessage transaction to discover present
`
`status of a previously sent message. The transaction response provides details about
`
`the message status as well as the status of all message recipients.
`
`[0077]
`
`2.3.1 Request
`
`[0078] MessageID (string, mandatory): This value identifies the message to be
`
`queried. It must match the Message1D attribute of the SendMessage request that
`
`created the message.
`
`[0079]
`
`2.3.2 Response
`
`[0080]
`
`The response includes a message status, and a number of member status
`
`values in the form of an attribute group, PagerID, PagerName, Pagerstatus. These
`
`three attributes may appear multiple times in the response to convey the status of
`
`multiple pagers in the message’s aggregate destination group.
`
`[0081] ResultCode (integer, mandatory): This value contains the result code of the
`
`transaction. If this value is not zero, then the Messagestatus, Pager]D, PagerName,
`
`and PagerStatus fields will not be present.
`
`[0082] ResultText (string, optional): This value contains a human readable
`
`message string describing the result of the transaction.
`
`[0083] MessageStatus (integer, mandatory): This value contains the present status
`
`of the message, as described in the table below.
`
`[0084]
`
`PagerID (string, mandatory): This value contains the identification of one
`
`pager in the aggregate destination group. The presence of this attribute implies that a
`
`corresponding PagerName attribute may follow, and that a Pagerstatus attribute will
`
`follow. Together, these two or three fields are duplicated for each member of the
`
`pager group total pager destination group.
`
`General Electric Co. 1014 - Page 014
`
`

`
`-14-
`
`[0085]
`
`PagerNa1ne (string, optional): This value contains the name of the pager
`
`user corresponding to the last PagerID value.
`
`[0086]
`
`Pagerstatus (string, mandatory): This value contains the status of the pager
`
`user corresponding to the most recent PagerID value in the PDU. PagerStatus values
`
`are enumerated in the table below.
`
`[0087]
`
`Pagerstatus and MessageStatus value enumerations are described below:
`
`PagerStatus Values
`
`Value
`“Pending”
`“Sent”
`
`Description
`The message is pending for transmission.
`The message has been sent to the device but not yet acknowledged in
`any way.
`
`The message has been successfully received by the device.
`“Received”
`The message has been read by the user.
`“Read”
`“Answered” The user has answered the message.
`
`MessageStatus Values
`
`Meaning
`“Pending”
`“Sent”
`“Closed”
`
`Description
`The message is pending for transmission.
`The message has been transmitted and is open for replies.
`The message is closed.
`
`[0088]
`
`2.3.3 Example
`
`[0089]
`
`This example illustrates a CAD system, querying for the message 2004.
`
`The Sparkgap returns a MessageStatus of 1 to indicate that the message has been sent,
`
`and it returns individual deliver status codes on the four members of the group.
`
`CAD to Sparkgap
`request 5067 sendmessage
`
`Sparkgap to CAD
`
`{ M
`
`}
`
`essageID=”2004”;
`
`Response 5067
`{
`Result=0;
`MessageStatus=”Sent”;
`PagerID=”229030020”;
`
`General Electric Co. 1014 - Page 015
`
`

`
`-15-
`
`PagerName=”Doe, John”;
`PagerStatus=”Read”;
`Pager]D=”229030109”;
`PagerName=”Doe, Jane;
`PagerStatus=”Sent”;
`PagerID=”22903 0O43”
`PagerName=”Orwell, George”;
`PagerStatus=”Read”;
`PagerlD=”229030025”;
`PagerName=”Miller, Hark”;
`PagerStatus=”Answered”;
`}.
`
`[0090]
`
`3
`
`"Events
`
`[0091]
`
`SDP allows the Sparkgap server to send asynchronous events to the CAD
`
`client to notify it of message activity on the network. SDP includes two events:
`
`PagerReply
`MessageComplete
`
`[0092]
`
`3.1 PagerRep1y
`
`[0093]
`
`This event infonns the CAD system that a recipient pager has responded in
`
`some way to a message. The event contains the following attributes
`
`[0094]
`
`Timestamp (string, mandatory): This value specifies the time that the
`
`Sparkgap received the information from the pager.
`
`[0095] MessagelD (string, mandatory): This value identifies the message,
`
`matching the MessagelD attribute value of the SendMessage request that created the
`
`message.
`
`[0096]
`
`CadEventID (string, mandatory): This field is only present if a
`
`CadEventlD attribute existed in the SendMessage request that created the message. If
`
`it is present, it matches the value in the SendMessage request.
`
`[0097]
`
`PagerID (string, mandatory):This value contains the identification of the
`
`pager issuing the reply.
`
`General Electric Co. 1014 - Page 016
`
`

`
`-15-
`
`[0098]
`
`PagerName (string, optional): This value contains a descriptive name of
`
`the pager user.
`
`[0099] UserAlerted (integer, optional): If this attribute is present and its value is
`
`non—zero, it means that the message was successfully received by the pager and the
`
`user was alerted.
`
`[00100] MessageRead (integer, optional): If this attribute is present, it means that
`
`the user displayed the message on the pager.
`
`[00101] McrValue (integer, optional): If this attribute is present, the user selected a
`
`multiple-choice reply value indicated by the value.
`
`[00102] McrText (string, optional): If this attribute is present, it contains the actual
`
`text of the selected multiple-choice reply.
`
`[00103] MessageText (string, optional): If this attribute is present, it contains a
`
`manually typed response from the pager.
`
`[00104] The PDU will not aggregate events; it will contain either UserAlerted,
`
`MessageRead, McrValue (and McrText), or MessageText. It will not contain a
`
`combination of these fields. Each distinct pager response will arrive in its own event
`
`PDU with its own timestamp value.
`
`[00105] In the following example, Pager 229030020 (John Doe) has responded to
`
`message 2004 with multiple-choice response number 2.
`
`Event PagerResponse
`
`{ T
`
`irnestamp=”O7082004l 3
`O5 5 3EST”;
`MessagelD=”200-4”;
`CadEventID=’ ’#CTyFD4l
`820772”;
`PagerID=”2290_3 0020”;
`PagerName=”Doe, John”;
`UserAlerted=l ;
`MessageRead=l ;
`McrValue=2;
`McrText=”Already On
`Scene”;
`
`General Electric Co. 1014 - Page 017
`
`

`
`I
`
`I};
`
`[00106] 3.2 MessageComp1ete
`
`[00107] This event informs the CAD system that a message has transitioned to the
`
`closed state. The message record will remain in memory for some time, but the
`
`system will no longer accept pager responses for it. This event contains the following
`attributes:
`
`[00108] Timestamp (string, mandatory): This value specifies the time that the
`
`Sparkgap closed the message.
`
`[00109] Message1D (string, mandatory): This value identifies the message,
`
`matching the Message1D attribute of the SendMessage request that created the
`
`message.
`
`[001 10] CadEvent1D (string, mandatory): This value is only present if a
`
`CadEventID attribute existed in the original SendMessage request that created the
`
`message, and if it is present, it matches the value in the SendMessage request.
`
`[001 1 1]
`
`In this example, Sparkgap announces that Message 2004 is closed:
`
`VI arkga (0 CAD
`Event MessageComp1ete
`
`{ T
`
`imestamp=”07082004l3
`O553E5T”;
`MessageID=”2004”;
`CadEvent]D=”#CTYFO4
`
`1320772”;
`},
`
`CAD t0 Sarkga
`
`[001 12] Result Codes
`
`[001 13] SDP supports the following result codes:
`
`0
`
`Transaction Completed Successfully
`
`1000
`1001
`
`Badly formed PDU
`Unknown recognized Request
`
`General Electric Co. 1014 - Page 018
`
`

`
`2000
`
`Invalid User/Password
`
`3000 Message Queue Full - Try Again Later
`3001
`Unknown MessageID
`3002
`Unknown DestinationID
`
`3003 Missing Required Attribute
`
`[001 14] A Dispatch/Response Layer will now be described which is a layer above
`
`the ReFLEX Air Protocol to support group messaging in accordance with the present
`
`invention. The SDP and DRL are analogized as book ends in that they operate on
`either side of the ReFLEX network.
`
`[001 15]
`
`1.
`
`Introduction
`
`[001 16] The Dispatch/Response Layer (DRL) provides efficient and high-
`
`performance group and personal messaging over ReFLEX. DRL uses binary IS
`
`vecto