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 .
Response to Arguments
Applicant's arguments filed May 1, 2026 have been fully considered but they are not persuasive.
With regard to claim 1, Applicant submits that A177 does not teach “abstract delivery type” including “an attribute of a required type.” Remarks, pp. 5-6.
In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
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 (“A177”), and So et al. (US 2019/0281339).
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 (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.”).
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, and wherein, based on the required type, the delivery type should be supported by a DVB client ([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).” [0054], “In a broadcasting system such as ATSC 3.0 or DVB, service list information (e.g., ESG) is extracted from the lower PHY/MAC layer.”).
Taking the teachings together, 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, 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.
Applicant additionally submits that A177 does not teach “the service list entry points further include an element of a delivery type.” Remarks, p. 6.
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 (“A177”), and So et al. (US 2019/0281339).
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 by receiving service list entry information (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.
Applicant submits that So does not teach “the service list entry points include an abstract delivery type including an attribute of a required type,” as recited in claim 1. Remarks, p. 6.
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 (“A177”), and So et al. (US 2019/0281339).
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 (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.”),
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 by receiving service list entry information (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”). A177 additionally teaches a DVB-I client (pp. 14-15). A177 additionally teaches true or false values for parameters (pp. 37, 43).
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, and wherein, based on the required type, the delivery type should be supported by a DVB client ([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).” [0054], “In a broadcasting system such as ATSC 3.0 or DVB, service list information (e.g., ESG) is extracted from the lower PHY/MAC layer.”).
Taking the teachings together, 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, 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. Furthermore, considering So’s teaching with the combination, in particular, Hwang’s teaching of a usage of true or false values for parameters (Col. 46, lines 19-23) and A177’s teaching of a DVB-I client (pp. 14-15), 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, based on a true value of the required type, the delivery type should be supported by a DVB-I client. The modification would serve to facilitate management and distribution of service list information to devices.
Applicant additionally submits that So does not teach “the service list entry points further include an element of a delivery type” representing “which of the delivery methods are required in order to offer an acceptable experience by a service list provider.” Remarks, pp. 6-7.
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 (“A177”), and So et al. (US 2019/0281339).
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 (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.”).
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 by receiving service list entry information (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”). A177 additionally teaches a DVB-I client (pp. 14-15). A177 additionally teaches true or false values for parameters (pp. 37, 43).
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, and wherein, based on the required type, the delivery type should be supported by a DVB client ([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).” [0054], “In a broadcasting system such as ATSC 3.0 or DVB, service list information (e.g., ESG) is extracted from the lower PHY/MAC layer.”).
Taking the teachings together, 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, 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. Furthermore, considering So’s teaching with the combination, in particular, Hwang’s teaching of a usage of true or false values for parameters (Col. 46, lines 19-23) and A177’s teaching of a DVB-I client (pp. 14-15), 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, based on a true value of the required type, the delivery type should be supported by a DVB-I client. The modification would serve to facilitate management and distribution of service list information to devices.
Applicant also submits that So does not disclose the claimed “the delivery type includes at least one of a DASH deliver, a terrestrial delivery type, a cable deliver type, a satellite deliver type, a multicast TS deliver type.” Remarks, p. 7.
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 (“A177”), and So et al. (US 2019/0281339).
Hwang teaches wherein a delivery type includes at least one of a DASH deliver (Col. 4, line 63 to col. 5, line 3, “service data may be processed into DASH segments and transmitted using real time object delivery over unidirectional transport (ROUTE), based on MPEG DASH.”), a terrestrial delivery type (Col. 4, lines 20-34, “The present invention provides apparatuses and methods for transmitting and receiving broadcast signals for future broadcast services. Future broadcast services according to an embodiment of the present invention include a terrestrial broadcast service, a mobile broadcast service, an ultra high definition television (UHDTV) service, etc.”), a cable deliver type, a satellite deliver type, or a multicast TS deliver type.
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 by receiving service list entry information (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”). A177 additionally teaches a DVB-I client (pp. 14-15). A177 additionally teaches true or false values for parameters (pp. 37, 43).
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, and wherein, based on the required type, the delivery type should be supported by a DVB client ([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).” [0054], “In a broadcasting system such as ATSC 3.0 or DVB, service list information (e.g., ESG) is extracted from the lower PHY/MAC layer.”).
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, 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. Furthermore, considering So’s teaching with the combination, in particular, Hwang’s teaching of a usage of true or false values for parameters (Col. 46, lines 19-23) and A177’s teaching of a DVB-I client (pp. 14-15), 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, based on a true value of the required type, the delivery type should be supported by a DVB-I client. The modification would serve to facilitate management and distribution of service list information to devices.
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.”),
wherein a delivery type includes at least one of
a DASH deliver (Col. 4, line 63 to col. 5, line 3, “service data may be processed into DASH segments and transmitted using real time object delivery over unidirectional transport (ROUTE), based on MPEG DASH.”),
a terrestrial delivery type (Col. 4, lines 20-34, “The present invention provides apparatuses and methods for transmitting and receiving broadcast signals for future broadcast services. Future broadcast services according to an embodiment of the present invention include a terrestrial broadcast service, a mobile broadcast service, an ultra high definition television (UHDTV) service, etc.”),
a cable deliver type,
a satellite deliver type, or
a multicast TS deliver type.
Hwang additionally teaches the usage of true or false values for parameters (Col. 46, lines 19-23, “In some embodiments, HDRTypeTransitionFlag, HDRSDRTransitionFlag, and SDRHDRTransitionFlag may not be simultaneously true. For example, if the HDRSDRTransitionFlag value is true, the HDRTypeTransitionFlag, SDRHDRTransitionFlag value may be false.”).
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 by receiving service list entry information. 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. Hwang also does not expressly teach wherein, based on a true value of the required type, the delivery type should be supported by a DVB-I client, or wherein, based on a false value of the required type, the deliver type is not essential by the DVB-I client.
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 by receiving service list entry information (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”). A177 additionally teaches a DVB-I client (pp. 14-15). A177 additionally teaches true or false values for parameters (pp. 37, 43).
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. The combination also does not expressly teach wherein, based on a true value of the required type, the delivery type should be supported by a DVB-I client, or wherein, based on a false value of the required type, the deliver type is not essential by the DVB-I client.
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, and wherein, based on the required type, the delivery type should be supported by a DVB client ([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).” [0054], “In a broadcasting system such as ATSC 3.0 or DVB, service list information (e.g., ESG) is extracted from the lower PHY/MAC layer.”).
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, 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. Furthermore, considering So’s teaching with the combination, in particular, Hwang’s teaching of a usage of true or false values for parameters (Col. 46, lines 19-23) and A177’s teaching of a DVB-I client (pp. 14-15), 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, based on a true value of the required type, the delivery type should be supported by a DVB-I client. 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.
Claim(s) 8 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over a combination of Hwang, A177, So, and Okazaki (US 2011/0276996).
Regarding claim 8, the combination teaches the limitations specified above; however, the combination does not expressly teach wherein the at least one processor is further configured by display information indicating that a service in a second service list related to the service list entry information is not available by a hybrid service.
Okazaki teaches display information indicating that a service is not available ([0049], “The control portion 13 is formed to control the display portion 14 to display a determination result display screen 14a (see FIG. 3) listing the three services A to C so that the user can visually identify whether or not the same have been determined as available, thereby posting the service (service A, for example) determined as available and the services (services B and C, for example) determined as unavailable to the user so that he/she can visually recognize the services determined as available and unavailable respectively. More specifically, the control portion 13 controls the display portion 14 to display the determination result display screen 14a relatively brightly displaying the service A (DLNA) while relatively darkly displaying the service B (radio distribution) and the service C (video distribution) as shown in FIG. 3, when determining that the service A (DLNA) as available while determining the service B (radio distribution) and the service C (video distribution) as unavailable. In this case, the user can visually recognize that the relatively brightly displayed service A (DLNA) is available and the relatively darkly displayed services B and C (radio distribution and video distribution) are unavailable by observing the determination result display screen 14a (see FIG. 3). The control portion 13 is formed to control the display portion 14 to display the determination result display screen 14a in a prescribed region (lower right portion of the display portion 14 in FIG. 3) thereof, as shown in FIG. 3.”).
In view of Okazaki’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 at least one processor is further configured by display information indicating that a service in a second service list related to the service list entry information is not available by a hybrid service. The modification would serve to aid users in determining the availability of services. The modification would thereby enhance the user experience.
Regarding claim 15, the combination teaches the limitations specified above; however, the combination does not expressly teach displaying information indicating that a service in a first service list related to the service list entry information is available by a hybrid service.
Okazaki teaches display information indicating that a service is available ([0049], “The control portion 13 is formed to control the display portion 14 to display a determination result display screen 14a (see FIG. 3) listing the three services A to C so that the user can visually identify whether or not the same have been determined as available, thereby posting the service (service A, for example) determined as available and the services (services B and C, for example) determined as unavailable to the user so that he/she can visually recognize the services determined as available and unavailable respectively. More specifically, the control portion 13 controls the display portion 14 to display the determination result display screen 14a relatively brightly displaying the service A (DLNA) while relatively darkly displaying the service B (radio distribution) and the service C (video distribution) as shown in FIG. 3, when determining that the service A (DLNA) as available while determining the service B (radio distribution) and the service C (video distribution) as unavailable. In this case, the user can visually recognize that the relatively brightly displayed service A (DLNA) is available and the relatively darkly displayed services B and C (radio distribution and video distribution) are unavailable by observing the determination result display screen 14a (see FIG. 3). The control portion 13 is formed to control the display portion 14 to display the determination result display screen 14a in a prescribed region (lower right portion of the display portion 14 in FIG. 3) thereof, as shown in FIG. 3.”).
In view of Okazaki’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 to include displaying information indicating that a service in a first service list related to the service list entry information is available by a hybrid service. The modification would serve to aid users in determining the availability of services. The modification would thereby enhance the user experience.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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
Prosecution Insights