IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`In re application of:
`Jacob W. JORGENSEN
`
`Group Art Unit: 2155
`
`Appl. No. 09/349’482
`
`Examiner: Frantz B. Jean
`
`confim‘at‘o“ N°' 6669
`Filed: July 09, 1999
`
`Atty. Docket No. 36792—162254
`(fomerly A2154”
`
`F :
`or
`
`APPLICATION—AWARE
`QUALITY OF SERVICE (Q08)
`SENSITIVE, MEDIA ACCESS
`CONTROL (MAC) LAYER
`
`CUStomerNo'
`Hill"|||||||l||||l||||l||||||l|||
`26694
`PATENT TRADEMARK OFFICE
`
`Amendment and Reply Under 37 CPR. § 1.111 and 1.121
`
`Honorable Commissioner for Patents
`
`Washington, DC. 20231
`
`Sir:
`
`No extension of time fee or claim fee is believed to be required in connection with this
`
`Amendment. If an extension of time is needed to prevent abandonment of this application, such
`
`extension of time is hereby requested under 37 C.F.R. § 1.136(a).
`
`Please charge any fee
`
`deficiency or credit overpayments to our Deposit Account No. 22-0261, and notify the
`
`undersigned accordingly.
`
`In reply to the Office Action mailed January 2, 2003, Applicant submits the following
`
`Amendment and Remarks:
`
`lnteliectuai Ventures 1 LLC
`
`Exhibit 2015
`
`ERICSSON V. EV I
`
`'IPRZO 1 8410727
`
`

`

`Amendment
`
`In the Claims:
`
`Please amend claims 1-5, 7, 10-17 and 20 as follows:
`
`1.
`
`(Amended)
`
`An application aware, quality of service (QoS) sensitive, media access control
`
`(MAC) layer comprising:
`
`an application-aware resource allocator at the MAC layer, wherein said resource allocator
`
`allocates bandwidth resource to an intemet protocol (IP) flow associated with a software
`
`application of a user based on IP QoS requirements of said software application, wherein said
`
`resource allocator allocates said bandwidth resource in a packet—centric manner that is not
`
`circuit-centric and does not use asynchronous transfer mode (ATM).
`
`2.
`
`(Amended)
`
`The MAC layer according to claim 1, wherein said resource allocation is
`
`based on input from at least one of:
`
`a packet header; and
`
`a software application communication to said MAC layer.
`
`3.
`
`(Amended)
`
`The MAC layer according to claim 2, wherein said software application
`
`communication comprises:
`
`a communication between said software application, running on at least one of a subscriber
`
`workstation and a host workstation, and the MAC layer, running on at least one of a subscriber
`
`CPE station and a wireless base station.
`
`4.
`
`(Amended)
`
`The MAC layer according to claim 2, wherein said bandwidth resource
`
`comprises at least one of wide area network (WAN) wireless bandwidth and local area network
`
`(LAN) wireless bandwidth.
`
`5.
`
`(Amended)
`
`The MAC layer according to claim 1, wherein said resource allocator
`
`schedules said bandwidth resource to allow transmission of one or more packets of said [P flow.
`
`(\J
`
`36792-162254
`
`

`

`7.
`
`(Amended)
`
`The MAC layer according to claim 5, wherein said resource allocator in said
`
`resource allocation takes into account resource requirements of at least one of a source
`
`application and a destination application of said IF flow.
`
`10. (Amended)
`
`The MAC layer according to claim 1, wherein said resource allocator allocates
`
`switching resource to said software application based on an application type.
`
`11. (Amended)
`
`The MAC layer according to claim 10, wherein said application type is
`
`identified based on input from at least one of:
`
`packet header; and
`
`a sofiware application communication to said MAC layer.
`
`12. (Amended)
`
`The MAC layer according to claim 11, wherein said software application
`
`communication comprises:
`
`a communication between said software application, running on at least one of a subscriber
`
`workstation and a host workstation, and said MAC layer, running on at least one of a subsctiber
`
`CPE station and a wireless base station.
`
`13. (Amended)
`
`The MAC layer according to claim 1 1, wherein said software application
`
`communication comprises:
`
`a priority class of said IF flow.
`
`14. (Amended)
`
`The MAC layer according to claim 1, further comprising:
`
`an application identifier that identifies an application type of said software application to said
`
`resource allocator.
`
`15. (Amended)
`
`The MAC layer according to claim 14, wherein said application identifier uses
`
`contents of a packet header to identify a source application of said IF flow.
`
`16. (Amended)
`
`The MAC layer according to claim 14, wherein said application identifier uses
`
`a direct c0nduit of an application layer from a source application to identify said source
`
`36792—162254
`
`

`

`application of said IF flow.
`
`1?. (Amended)
`
`The MAC layer according to claim 1, wherein said application—aware resource
`
`allocator comprises a module operative to recognize an application type of said software
`
`application associated with said [P flow.
`
`20. (Amended)
`
`An application—aware media access control (MAC) layer for optimizing end
`
`user application intemet protocol (1P) quality of service (QoS) to IP flows comprising:
`
`identifying means for identifying an application type of a software application
`
`associated with an IP flow; and
`
`allocating means for allocating resources to said [P flow, responsive to said
`
`identifying means, so as to Optimize end user application I? QoS requirements of said software
`
`application, wherein said resource allocating means allocates resources in a packet—centric
`
`manner that is not circuit—centric and does not use asynchronous trans fer mode (ATM).
`
`36792—162254
`
`

`

`Remarks
`
`Reconsideration of this Application is respectfully requested.
`
`Upon entry of the above amendments, claims 1-20 are pending in the application, with
`
`claims 1 and 20 being the independent claims. Claims 1-5, 7, 10-17 and 20 are amended.
`
`Attached hereto is a marked—up version of the changes made to claims. The attachment is
`
`captioned “Version with markings to show changes made.” It is noted that the claims 2-5, 7 and
`
`10-17 have been amended to correct editorial informalities only and have not been amended to
`
`overcome any objection or rejection.
`
`Based on the following remarks, Applicant respectfully requests that the Examiner
`
`reconsider all outstanding rejections and that they be withdrawn.
`
`Claim Rejections Under 35 U.S.C. § 102(e)
`
`In section 4 of the Office Action, the Examiner rejects claims 1—15 and 17-19 under 35
`
`U.S.C. § 102(6) as being anticipated by US. Patent No. 5,787,080 to Hulyalkar et a1.
`
`("Hulyalkar"). Applicant traverses the rejection for the following five reasons.
`
`1.
`
`Failure to teach or fairly suggest an application—aware resource allocator at the MAC
`
`layer.
`
`It is important to note that claim 1 teaches a MAC layer including a resource allocator at
`
`the MAC layer. Hulyalkar on the other hand maps applications to an ATM circuit at the ATM
`
`layer. Applicant's invention has nothing to do with ATM, as discussed further below.
`
`36792— 162254
`
`

`

`2.
`
`Failure to teach or fairly suggest a packet—centric protocol that is not circuit-centric and
`
`is not ATM.
`
`As amended, claim 1 now even more clearly distinguishes over Hulyalkar. Claim 1
`
`recites, inter alia: a resource allocator that allocates bandwidth resource to an intemet protocol
`
`(IP) flow associated with a software application of a user based on IP QoS requirements of said
`
`software application, wherein said resource allocator allocates bandwidth resource in a packet-
`
`centric manner that is not circuit—centric and does not use A I‘M. A packet-centric protocol that
`
`is not circuit-centric and does not use ATM “does not use dedicated circuits through which to
`
`transfer packets.” Specification, page 57, lines 8—9. In a packet—centric protocol according to the
`
`present invention, when a large file is sent down the protocol stack, “segmentation and
`
`packetization of the data” occurs, and then “a header is placed on the packet for delivery to the
`
`data link.” Page 57, lines 11—12. A circuit-centric network like ATM is different from a packet-
`
`centn'c protocol network, in that the circuit—centric network sets up “virtual circuits between
`
`source and destination nodes... by dedicating the virtual circuit to a specific traffic type.” Page
`
`57, lines 6-7. Unlike the circuit-centric protocol, the packet—centric protocol "does not
`
`specifically route” the packets "across a specific channel.” Page 57‘, lines 14—15. Instead, the
`
`packet-centric protocol places a header on the packet and lets the network deal with routing the
`
`packets. Page 57, lines 15-16. “Therefore, the outbound packets can take various routes to get
`
`from a source to a destination. This means that the packets are in a datagram form and not
`
`sequentially numbered as they are in other protocols.” Page 57, lines 16—18.
`
`Hulyalkar fails to teach or fairly suggest allocating resource in a packet centric manner
`
`which is not circuit centric and does not use A TM.
`
`Instead, Hulyalkar discloses a reservation-
`
`based wireless asynchronows transfer mode (ATM) local area network. See abstract, lines 1-2;
`
`36792— 162254
`
`

`

`column 3, lines 51-53. A control channel or a data channel of the A TM network can be
`
`implemented in a centralized or distributed mode. Column 5, lines 43-46. To ensure that
`
`different ATM services are possible at the moment of transmission, an actual allocation of
`
`bandwidth is requested by each MN requiring ATM service. Column 6, lines 1618. At a base
`
`station 12 in Fig. 3, for example, ATM switching is performed. Using separate MAC and PHY
`
`layers, the base station can handle both wired—A TM trafi‘ic and wireless ATM traflic as shOWn by
`
`a "shaded" application path 50 in Fig. 3 between a wired-A TM terminal 52 and a mobile ATM
`
`terminal 54 in Fig. 3. Column 6, lines 34—42. During a control phase, a certain number of A TM
`
`slots are reserved for a particular user. During the control sequence, multiple users specify and
`
`request a number of ATM slots required for each of their respective use. Column 7, lines 39-46.
`
`As discussed above, Hulyalkar teaches an ATM local area network. Such an ATM wireless local
`
`area network fails to teach or fairly suggest a packet centric protocol which is not circuit centric
`
`and is not A TM.
`
`3.
`
`Failure to teach or fairly suggest a resource allocator that allocates bandwidth resource
`
`based on IP QoS requirements of a software application.
`
`Claim 1 recites a MAC layer comprising a resource allocator that allocates bandwidth
`
`resource to an internet protocol (IP) flow associated with a software application of a user based
`
`on [P QoS requirements of the software application.
`
`The claimed feature is further explained in the specification at, for example, page 38,
`
`lines 5-14.
`
`[F]or the achievement of high QoS as perceived by the end user, it is desirable
`that the IPucentric wireless system be able to manage QoS mechanism parameters
`over a wide range, and in real time. The QoS mechanism must be able to alter
`system behavior to the extent that one or more data flows corresponding to
`
`36792—162254
`
`

`

`specific applications be switched on and off from appropriate end users in a
`transparent manner. This approach is in contrast to other QoS mechanisms that
`seek to achieve high QoS by establishing circuit-centric connections from end to
`end without regard for an underlying application ’s actual QoS requirements. By
`using the present invention, providing a QoS mechanism that is application-
`specific rather than circuit-specific, scarce wireless bandwidth can be conserved
`and dynamically allocated where needed by the QoS mechanisms associated with
`each application type.
`
`Applicant submits that Hulyalkar fails to teach or fairly suggest an allocation of
`
`bandwidth resource based on IP QoS requirements ofa software application. Instead,
`
`Hulyalkar appears to teach an allocation of bandwidth resource based on QoS requirements of an
`
`end user device. Using a control channel, the ATM based system of Hulyalkar is able to allocate
`
`a nominal bandwidth to "every user (i.e., MN or MT)" on a first—come-first—served basis until a
`
`maximum bandwidth allocation for the system is reached. "To ensure that different ATM
`
`services are pOSsible, at the moment of transmission, an actual allocation of bandwidth is
`
`requested by each MN requiring ATM service." Column 6, lines 12-18. During the control
`
`sequence, multiple users (i.e., MNs or MTs in Figs, l(a)-2(b)) specify and request a number of
`
`ATM slots required for each of their respective use. "Once this request is successful, each user
`
`then transmits its designated packets in a specified sequence during the data slots. Column 7,
`
`lines 43—47. Hence, Hulyalkar teaches an allocation of bandwidth resource based on QOS
`
`requirements of an end user device (i.e., MNs or MTs in Figs, l(a)-2(b)). However, Hulyalkar
`
`fails to teach or fairly suggest an allocation ofbandwidth resource based on IP QoS
`
`requirements of a software application. Hulyalkar wrongly presumes that each end-user device
`
`(i.e., MNs or MTs in Figs, l(a)-2(b)) has only one QoS requirement. Hulyalkarfails to
`
`recognize that an end—user device (i.e., MNS or MTS in Figs, l(a)—2(b)) can have various
`
`applications executing on the device, where each application has its own end user QoS
`
`36792—162254
`
`

`

`requirements as understood by Applicant's invention. Suppose, for example, that an end user
`
`device is a computer. Hulyalkar might assume that QoS requirements of the computer type end
`
`user device are those appropriate for non—latency sensitive data, and assuming so would not
`
`optimize end user (208 for a Voice over [P latency sensitive application. Suppose, instead, that
`
`the computer end user device was presumed to be a video teleconferencing computer and that an
`
`occasional frame of video data could be lost without ill effect. With such a setup, when an FTP
`
`file download, instead of video data, was sent over this video—optimized connection, a loss of
`
`vital data could potentially result by assigning a QoS level to at an end user device rather than at
`
`an end user application level.
`
`4.
`
`Failure to teach or fairly suggest an application aware, quality of service (QoS)
`
`sensitive, media access control (MAC) layer comprising an application-aware resource
`
`allocator.
`
`Claim 1 recites an application aware resource allocator. The application awareness
`
`refers to knowledge by the system of the type of data application such as, e.g., a voice over IP
`
`(VolP) type data application, or a video type data application. The application awareness
`
`feature further refers to the aspect of the resource allocator that allows the resource allocator to
`
`be able to take into account, when allocating bandwidth, information about applications at
`
`International Standards Organization’s Open Systems Intemetworking (OSI) application layer 7.
`
`For example, see Fig. 4, reference numbers 425 and 426. Conventional bandwidth allocation had
`
`been conventionally done only below or perhaps at the network layer 3 or transport layer 4 of the
`
`081 model, as will be apparent to those skilled in the art, not at the application layer 7.
`
`However, Appellant’s invention is aware of application layer 7, Le, above layer 4. Examples of
`
`36792— 162254
`
`

`

`application awareness include, e.g., understanding the type of bandwidth needs of an application
`
`associated with a packet of data such as, e.g., small amounts of bandwidth at periodic intervals
`
`for VoIP voice telephony latency and jitter sensitive traffic, large amounts of bandwidth for file
`
`transfers without time delay latency sensitivity, e.g., file transfer protocol (FTP) traffic, small
`
`amounts with no time sensitivity for email, e.g., simple mail transport protocol (SMTP) type
`
`haffic.
`
`In the present invention, scarce wireless bandwidth can be dynamically allocated using
`
`the present invention to provide wireless communication as needed by applications associated
`
`with packets by tailoring allocations to the application needs associated with each application
`
`933. (See specification at, for example, page 38, lines 11-14.) Data traffic, for example, can be
`
`handled based on classes of service. (See specification at, for example, page 31, line 12.) To
`
`differentiate traffic by class, data traffic (or a sequence of data packets associated with a
`
`particular application, function or purpose) is classified into one of several classes ofservice
`
`such as, e.g., latency sensitive VoIP type data, or video type data. (See specification at, for
`
`example, page 31, lines 12-14.) Differentiation is done on the basis of some identifiable
`
`information contained in packet contents such as, e. g., packet headers. (See specification at, for
`
`example, page 31, lines 14—15.) One exemplary method includes analyzing several items in an
`
`IP packet header or payload, which can serve to uniquely identify and associate the packet and
`
`other packets from that packet flow with a particular type ofapplication. (See specification at,
`
`for example, page 31, lines 15-18.) [F header fields include, e-g., source and destination IP
`
`addresses, helpful in providing application aware preferential resource allocation. (See
`
`specification at, for example, page 99, lines 8—10.) Packet header fields, for example, can be
`
`analyzed to determine the type of a source application making a VolP data call associated with
`
`10
`
`36792—162254
`
`

`

`or transmitting the IP packet; the application can be a file transfer FTP download or a VoIP
`
`telephony call, for example. (See specification at, for example, page 117, lines 18—23.) Thus,
`
`scarce wireless bandwidth can be dynamically allocated to where the bandwidth is needed by
`
`recognizing QoS requirements mechanisms associated with each application type. (See
`
`specification at, for example, page 38, lines 12—14.)
`
`Applicant submits that Hulyalkar does not teach or fairly suggest an application aware
`
`resource allocator, according to the present invention.
`
`5.
`
`Failure to teach or fairly suggest analysis ofapplications above layer 4 ofthe OSI
`
`model.
`
`Claims 18 and 19 recite a module operative to recognize an application type by analysis
`
`of applications above layer 4 of the 031 model. Applicant’s invention claims a resource
`
`allocator that is application—aware, i.e., that uses information about an application by looking
`
`above layer 4 of the 081 model, i.e., in a TCP/IP or UDP/IP world, above TCP or UDP,
`
`rCSpectively. See Fig. 14, for example and reference numerals 425 and 426. Further
`
`identification of the application can be performed at layer 3 or layer 4, such as, e.g., information
`
`about an application can be derived by analyzing ports. Further identification can also occur
`
`over layer 4 of the 081 model, up to and including layer 7, the Application layer- See Fig. 4.
`
`Hulyalkar fails to teach or fairly suggest analysis of applications above layer 4 of the
`
`081 model. Hulyalkar appears to disclose multiple layered protocols in Figs. 3-4. However,
`
`Hulyaikar does not appear to schedule or allocate resources as disclosed in Applicant’s
`
`specification by considering information above layer 4 of the OS! model.
`
`11
`
`36792-162254
`
`

`

`For at least the above discussed reasons, Applicant respectfully submits that claims 1 and
`
`18—19 are allowable over Hulyalkar. Claims 2—19 are submitted to be allowable as being
`
`dependent from allowable claim.
`
`Claim Rejections Under 35 U.S.C. § 103(a)
`
`In section 12 of the Office Action, the Examiner incorrectly states that the present
`
`application names joint inventors. The related provisional application to which this application
`
`claims priority did name two inventors; however, the present invention was invented by a single
`
`inventor, Jacob Jorgensen.
`
`It is important to note that the provisional application need not
`
`include any claims. The law of inventorship is clear that inventorship is determined by the
`
`inventor(s) who conceived at least one claim of a patent application. Jacob Jorgensen is the
`
`inventor of all the claims of the present non—provisional patent application.
`
`In section 13 of the Office Action, the Examiner rejects claims 16 and 20 as being
`
`unpatentable over Hulyalkar. Applicant respectfully disagrees with the rejection.
`
`The Examiner concedes that “Hulyalkar fails to disclose an application identifier that
`
`uses a direct conduit to identify a source application of an 1? flow-” Applicant agrees.
`
`The Examiner continues to assert that it “would have been apparent to one skilled in the
`
`art at the time of the invention” to use a direct conduit in order to provide "a more reliable and
`
`accurate identification process.” Applicant strongly disagrees and traverses the rejection. As
`
`conceded in the Office Action, Applicant submits that Hulyalkar does not by itself teach or
`
`suggest an application identifier that uses a direct conduit to identify a source application of an
`
`1? flow. If the Office Action is based on a secondary reference providing such teaching or
`
`12
`
`36792-162254
`
`

`

`suggestion, then Applicant respectfully requests production of the secondary reference for the
`
`record. Also absent a teaching to combine Hulyalkar with the secondary reference, the Examiner
`
`has failed to prove his prima facie case of obviousness. Lacking production of such secondary
`
`reference, it is not obvious to use an application identifier that uses a direct conduit to identify a
`
`source application of an IP flow. Hence, Hulyalkarfails to teach or suggest the claimed
`
`application identifier that uses a direct conduit to identify a source application of an IPflow.
`
`Information Disclosure Statement
`
`An Information Disclosure Statement has been filed on January 2, 2002, which seems to
`
`have crossed in mail with the Office Action issued on the same date. The Office Action does n_ot
`
`indicate that the Information Disclosure Statement has been considered. Applicant respectfully
`
`requests that the Examiner kindly return a copy of the acknowledged IDS after consideration of
`
`the references cited therein.
`
`Conclusion
`
`All of the stated grounds of rejection have been properly traversed, accommodated, or
`
`rendered moot. Applicant therefore respectfully requests that the Examiner reconsider all
`
`presently outstanding rejections and that they be withdrawn. Applicant believes that a full and
`
`complete reply has been made to the outstanding Office Action and, as such, the present
`
`application is in condition for allowance.
`
`if the Examiner believes, for any reason, that personal
`
`communication will expedite prosecution of this application, the Examiner is hereby invited to
`
`telephone the undersigned.
`
`13
`
`36792-162254
`
`

`

`Prompt and favorable consideration of this Amendment and the allowance of claims 1—20
`
`are respectfully requested.
`
`Date: AW“ 2/ 2003
`
`RPAJ'JHK
`::ODMA\.PCDOCS\DC2DOCS l \446530\l
`
`Respectfully submitted,
`
`/9%
`
`Ralph P. Albrecht
`Registration No- 43,466
`Jung (John) Kim
`Registration No. 51,299
`VENABLE
`
`PO. Box 34385
`
`Washington, DC. 20043—9998
`Telephone: (202) 962-4800
`Telefax: (202) 962—8300
`
`14
`
`36792-162254
`
`

`

`VERSION WITH MARKINGS TO SHOW CHANGES MADE
`
`In the Claims:
`
`Please amend claims 1-5, 7, 10-17 and 20 as follows:
`
`(Amended)
`
`An application aware, quality of service (QoS) sensitive, media access control
`
`(MAC) layer comprising:
`
`an application-aware resource allocatoratthe M AC layer, wherein said resource allocator
`
`allocates bandwidth resource toaan internet protocol (IP) flow associated with an s_-_of‘mare
`
`application of a user based on lP QoS reguirements of said software mapplicationa'ype, wherein
`
`said resource allocator allocates said bandwidth resource in a ackct-centric manner that is not
`
`
`circuit-centric and does not use asynchronous transfer mode LAT N1)
`
`2.
`
`(Amended)
`
`
`The MAC layer according to claim 1, wherein said applieatiee—typegsourcc
`
`a packet header; and
`
`an software application communication to said MAC layer.
`
`3.
`
`(Amended)
`
`The MAC layer according to claim 2, wherein said software application
`
`communication comprises:
`
`a communication between said 5_Q_lm areapplication running on at least one of a subscriber
`
`workstation and a host workstation, and the MAC layer, running on at least one of a subscriber
`
`CPE station and a wireless base station.
`
`4.
`
`(Amended)
`
`The MAC layer according to claim 2, wherein said bandwidth resource is
`
`comprises at ieast one ot'widc area network (WAN) wirciess bandwidth and local area network
`
`{LAN} wireless —bandwidth.
`
`5.
`
`(Amended)
`
`The MAC layer according to claim 1, wherein said resource allocator
`
`flow.
`
`15
`
`36792-162254
`
`

`

`7.
`
`(Amended)
`
`The MAC layer according to claim 5, wherein said resource allocator in
`
`scheduling—said resource allocation takes into account resource requirements of at least one of a
`
`source application and a destination "application of ansaid IP flow.
`
`10. (Amended)
`The MAC layer according to claim 1, wherein said resource allocator allocates
`switching resource to arr—said software application based on an application type.
`
`11. (Amended)
`The MAC layer according to claim 10, wherein said application type is
`identified based on input from at least one of:
`packet header; and
`
`an-a software application communication to said MAC layer.
`
`The MAC layer according to claim 11, wherein said software application
`12. (Amended)
`communication comprises:
`
`a communication between ansaid software application, running on at least one of a
`subscriber workstation and a host workstation, and said MAC layer, running on at least one of a
`
`subscriber CPE station and a wireless base station.
`
`The MAC layer according to claim 11, wherein said softwareapplication
`13. (Amended)
`communication comprises:
`
`a priority class of said IF flow.
`
`14. (Amended)
`
`The MAC layer according to claim 1, further comprising:
`
`an application identifier that identifies an application type of said software application. to said
`
`reSOurce allocator.
`
`I
`
`I
`
`I
`
`I
`
`I
`
`I
`
`15. (Amended)
`
`The MAC layer according to claim 14, wherein said application identifier uses
`
`contents of a packet header to identify a source application of anwsaid lP flow.
`
`16. (Amended)
`
`The MAC layer according to claim 14, wherein said application identifier uses
`
`16
`
`36792—162254
`
`

`

`a direct conduit of an application layer from a source application to identify said source
`
`application of an—said IP flow.
`
`17. (Amended)
`
`The MAC layer according to claim 1, wherein said application-aware resource
`
`allocator comprises a module operative to recognize said—jagapplication type of said software
`
`application associated with an—said IP flow.
`
`20. (Amended)
`
`An application-aware media access control (MAC) layer for optimizing end
`
`userguplication intemcuggtocoifl?) quality of service (QoS) -to IP flows comprising:
`
`identifying means for identifying an application type of aera software application
`
`associated with an IP flow; and
`
`allocating means for allocating resources to said [P flow, responsive to said
`
`identifier—identifying means, so as to optimize end user application lP qaal-ityefiservieHQoS)
`
`reguirements ol’said software applicatioanherein said resource allocating means allocates
`
`resources in alpackct—ccntric manner that is not circuit—centric and. does not use asymehronous
`
`tianst‘cr mode ( ATM g.
`
`17
`
`36792—162254
`
`