DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on January 7, 2026 has been entered.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1, 5-6, 9, and 13-14 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1 and 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over a combination of Hwang et al. (US 10171849), Digital Video Broadcasting (DVB). (2019). Digital Video Broadcasting (DVB); Service Discovery and Programme Metadata for DVB-I Services (DVB Document A177). dvb.org/wp-content/uploads/2019/12/a177_dvb-i_specification.pdf (hereinafter referred to as “A177”), and So et al. (US 2019/0281339).
Regarding claim 1, Hwang teaches a device for processing media data, comprising:
a memory; and at least one processor connected to the memory (Col. 65, lines 6-18), the at least one processor configured to:
transmit a query for an internet-based broadcast service discovery (Col. 27, lines 23-26, “An HTTP client may request a necessary MPD and/or a segment from an HTTP server. In addition, the HTTP client may deliver the MPD and/or the segment acquired from the server to the MPD parser or the segment parser.”);
receive service in response to the query (Col. 28, lines 12-14, “The HTTP access client may request specific information from the HTTP server and process a response to the request.”); and
wherein a service list includes an abstract type including an attribute of a required type for representing that a type is required to be supported by the device in order to offer an acceptable experience by a service list provider (Col. 62, lines 3-18, “In a method of transmitting a broadcast signal according to another embodiment of the present invention, a service list table or USBD may further include capability information. This may refer to various capability information items included in the aforementioned SLT and USBD. The capability information may describe at least one or more capabilities required to meaningfully present a broadcast service.”).
Hwang does not expressly teach that the transmitting includes transmitting a query to a service list registry for an internet-based broadcast service discovery, and the receiving includes receiving service list entry points in response to the query. Hwang also does not expressly teach discovering a service based on the service list entry points. While Hwang teaches wherein a service list includes an abstract type including an attribute of a required type for representing that a type is required to be supported by the device in order to offer an acceptable experience by a service list provider, Hwang does not expressly teach wherein the service list entry points includes an abstract delivery type including an attribute of a required type for representing that a delivery type is required to be supported by the device. Hwang also does not expressly teach wherein the service list entry points further include an element of a delivery type for representing delivery methods used to deliver services in a service list and which of the delivery methods are required in order to offer an acceptable experience by the service list provider.
A177 teaches transmitting a query to a service list registry for an internet-based broadcast service discovery, receiving service list entry points in response to the query, and discovering a service based on the service list entry points (p. 18, “A DVB-I Service List Registry is an HTTP endpoint available at a known URL that, if queried, can return a list of Service List Entry Points. The DVB-I Service List Providers who wish to enable the Service List Registry discovery mechanism for their own Service Lists may register their Service List Entry Points in the Service List Registry using the M2 interface in clause 4.1. … The Service List Registry shall be able to respond to queries issued by DVB-I clients. … Query response shall be in the form of an XML document according to the schema defined in clause 5.3, including the list of Service List Entry Points matching the query parameters (carrying the URL of the associated DVB-I Service Lists).”). A177 additionally teaches an element of a delivery type for representing delivery methods used to deliver services (p. 94, i.e., “DeliveryMode”).
In view of A177’s teaching, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the Hwang such that the transmitting includes transmitting a query to a service list registry for an internet-based broadcast service discovery, that the receiving includes receiving service list entry points in response to the query, discovering a service based on the service list entry points, wherein the service list entry points include the abstract delivery type, and wherein the service list entry points further include an element of a delivery type for representing delivery methods used to deliver services in a service list. The modification would serve to facilitate access to content delivery sources.
While the combination teaches wherein a service list includes an abstract type including an attribute of a required type for representing that a type is required to be supported by the device in order to offer an acceptable experience by a service list provider (Hwang: Col. 62, lines 3-18), the combination does not expressly teach wherein the service list entry points includes an abstract delivery type including an attribute of a required type for representing that a delivery type is required to be supported by the device. Hwang also does not expressly teach wherein the service list entry points further include an element of a delivery type for representing which of the delivery methods are required in order to offer an acceptable experience by the service list provider.
So teaches:
an attribute of a required type for representing that a delivery type is required to be supported by a device; and an element of a delivery type for representing delivery methods used to deliver services and which of the delivery methods are required ([0068], “The delivery channel type information, deliveryChannelType, provides the required channel type of MMT packages to be included in the MMT service list transmitted to the MMT receiving entity. The required channel type is a channel type which transmission channels should be in order to consume the MMT packages included in the MMT service list which the MMT sending entity will transmit to the MMT receiving entity. That is, if the MMT service list storage server receives a request using a query string, the MMT service list storage server generates an MMT service list by merging lists of MMT packages consumable only with an indicated channel type (i.e., a delivery channel type deliveryChannelType), and replies to the MMT receiving entity with the MMT service list. If the MMT receiving entity wants a channel list consumable with a specific channel type on the basis of available channels, the MMT receiving entity may request the channel list by using a query string (particularly, the delivery channel type element, deliveryChannelType, included in the query string).”).
In view of So’s teaching, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination wherein the service list entry points includes an abstract delivery type including an attribute of a required type for representing that a delivery type is required to be supported by the device, and wherein the service list entry points further include an element of a delivery type for representing which of the delivery methods are required in order to offer an acceptable experience by the service list provider. The modification would serve to facilitate management and distribution of service list information to devices.
The grounds of rejection under 35 USC §103 with respect to claim 1 is similarly applied to claim 9.
Regarding claims 5 and 13, the combination teaches the limitations specified above; however, the combination as presently combined does not expressly teach wherein service list entry information received by the at least one processor comprises one or more pieces of service list information, wherein the one or more pieces of service list information comprise required information and availability information related to delivery types.
So teaches wherein service list entry information received by at least one processor comprises one or more pieces of service list information, wherein the one or more pieces of service list information comprise required information and availability information related to the delivery types (So: [0069], “The MMT receiving entity may specifically request an MMT service list having only a specific channel type, channelType, by an HTTP GET request. Herein, the MMT service list request message may include service_URI and a query string. Service_URI is the URI of an MMT service list storage server that provides the MMT service list, and may be identical to the descriptorURL. The query string may include delivery channel type information, deliveryChannelType. The delivery channel type information, deliveryChannelType, provides the required channel type of MMT packages to be included in the MMT service list transmitted to the MMT receiving entity. The required channel type is a channel type which transmission channels should be in order to consume the MMT packages included in the MMT service list which the MMT sending entity will transmit to the MMT receiving entity. That is, if the MMT service list storage server receives a request using a query string, the MMT service list storage server generates an MMT service list by merging lists of MMT packages consumable only with an indicated channel type (i.e., a delivery channel type deliveryChannelType), and replies to the MMT receiving entity with the MMT service list.”)
In view of So’s teaching, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the combination wherein service list entry information received by the at least one processor comprises one or more pieces of service list information, wherein the one or more pieces of service list information comprise required information and availability information related to delivery types. The modification would serve to further aid in the distribution of service list information to devices.
Regarding claims 6 and 14, the combination further teaches further teaches wherein the one or more pieces of service list information comprise at least one of
required information related to a DASH delivery type and availability information related to the DASH delivery type,
required information related to a terrestrial delivery type and availability information related to the terrestrial delivery type, or
required information related to a communication network delivery type (So: [0069], “The MMT receiving entity may specifically request an MMT service list having only a specific channel type, channelType, by an HTTP GET request. Herein, the MMT service list request message may include service_URI and a query string. Service_URI is the URI of an MMT service list storage server that provides the MMT service list, and may be identical to the descriptorURL. The query string may include delivery channel type information, deliveryChannelType. The delivery channel type information, deliveryChannelType, provides the required channel type of MMT packages to be included in the MMT service list transmitted to the MMT receiving entity. The required channel type is a channel type which transmission channels should be in order to consume the MMT packages included in the MMT service list which the MMT sending entity will transmit to the MMT receiving entity. That is, if the MMT service list storage server receives a request using a query string, the MMT service list storage server generates an MMT service list by merging lists of MMT packages consumable only with an indicated channel type (i.e., a delivery channel type deliveryChannelType), and replies to the MMT receiving entity with the MMT service list.”),
wherein the service list entry points received by the device are filtered by a server based on a delivery type for the device (So: [0069], “That is, if the MMT service list storage server receives a request using a query string, the MMT service list storage server generates an MMT service list by merging lists of MMT packages consumable only with an indicated channel type (i.e., a delivery channel type deliveryChannelType), and replies to the MMT receiving entity with the MMT service list.” A177, p. 18.).
Allowable Subject Matter
Claims 7-8 and 15 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL R TELAN whose telephone number is (571)270-5940. The examiner can normally be reached 9:30AM-6:00PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Nasser Goodarzi can be reached at (571) 272-4195. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MICHAEL R TELAN/ Primary Examiner, Art Unit 2426