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 .
Allowable Subject Matter
Claims 3, 8, 10 and 22 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.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim(s) 19 is rejected under 35 USC 101 since the claims are directed to non-statutory subject matter. Claim(s) 19 recite a non-transient computer readable medium which appears to cover both transitory and non-transitory embodiments because a “non-transient medium” may be a “steady-state signal” that is not eligible. The United States Patent and Trademark Office (USPTO) is required to give claims their broadest reasonable interpretation consistent with the specification during proceedings before the USPTO. See In re Zletz, 893 F.2d 319 (Fed. Cir. 1989) (during patent examination the pending claims must be interpreted as broadly as their terms reasonably allow). The broadest reasonable interpretation of a claim drawn to a computer readable medium (also called machine readable medium and other such variations) typically covers forms of non-transitory tangible media and transitory propagating signals per se in view of the ordinary and customary meaning of computer readable media, particularly when the specification is silent. See MPEP 2111.01. When the broadest reasonable interpretation of a claim covers a signal per se, the claim must be rejected under 35 U.S.C. § 101 as covering non-statutory subject matter. See In re Nuijten, 500 F.3d 1346, 1356-57 (Fed. Cir. 2007) (transitory embodiments are not directed to statutory subject matter) and Interim Examination Instructions for Evaluating Subject Matter Eligibility Under 35 U.S.C. § 101, Aug. 24, 2009; p. 2. To overcome this rejection, applicant is encouraged to amend claim with substance equivalent to “A non-transitory computer-readable storage medium, storing computer programs, wherein when the computer programs are executed by a processor ....”
Claim 20 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because product claim “A computer program product, comprising computer programs carried on a non-transient computer-readable medium, wherein the computer programs comprise program codes for executing the video stream acquisition method of claim 1” comprises only computer programs and claimed product does not comprise non-transient computer-readable medium and therefore claimed product is software per se. To overcome this rejection, applicant is encouraged to amend claim with substance equivalent to “A computer program product, comprising a non-transitory computer-readable medium storing a computer program executed by a processor, wherein ....”
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.
Claims 1-2, 4-7, 9, 11 and 18-21 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Publication No. 2020/0322646 to Xie et al. (“Xie”) in view of U.S. Patent No. 2006/0253609 to Andreev et al. (“Andreev”).
As to claim 1, Xie discloses a video stream acquisition method, applied to a user terminal (Xie: fig 1-6), comprising:
sending a stream pulling information acquisition request to a media server, to make the media server determine an IP address of a target intranet edge server based on a target exit IP address in the stream pulling information acquisition request (Xie: fig 1-6, [0006-121]: fig 4 ... when a user wants to watch a live video, the user may trigger, through user operations, a viewer terminal (user terminal) to send an acquisition request for the corresponding live video stream (sending a stream pulling information acquisition request to a media server ...) [0094] ... the stream-pulling query request of target live stream video may include video stream information of the target live video stream (based on ... in the stream pulling information acquisition request) ... CCL server (media server) determines a network communication address (IP address/ domain name) of a target stream-pulling edge node (... determines an IP address of a target intranet edge server ...) corresponding to the area to which the viewer terminal belongs as the acquisition address (...based on a target exit IP address in the stream pulling information acquisition request ...) [0098] ),
perform a domain name generation based on a preset domain name generation method and according to the IP address of the target intranet edge server (Xie: fig 1-6, [0006-121]: fig 4 ... DNS system may receive the acquisition request and convert the target domain name of the acquisition request to a network communication address (perform a domain name generation ...) ... return the converted acquisition request to viewer terminal [0094] ... If the number of stream-pulling requests of the target live video stream is greater than the preset threshold (... based on a preset domain name generation method ...), it may indicate that the target live video stream is a hot stream, and the viewer terminal may pull the target live video stream from the nearest stream-pulling edge node (perform a domain name generation based on a preset domain name generation method ...) ... accordingly, the CCL server may determine the network communication address of the target stream-pulling edge node corresponding to the area to which the viewer terminal belongs as the acquisition address (... and according to the IP address of the target intranet edge server) [0100]), and
determine target stream pulling information based on a generated domain name (Xie: fig 1-6, [0006-121]: in one implementation after a target static parent node receives the stream-pulling request of the target live video stream sent by the target stream-pulling edge node ... may determine at least one dynamic parent node according to the preset algorithm and the video stream information of the target live video stream (see with [0094;100] above - determine target stream pulling information based on a generated domain name) [0091]);
acquiring the target stream pulling information, performing a domain name resolution on the target stream pulling information based on a preset domain name resolution method (Xie: fig 1-6, [0006-121]: ... under another stream-pulling mechanism, the static parent node may preferentially pull the live video stream from a determined first dynamic parent node (acquiring the target stream pulling information ... based on a preset domain name resolution method) and when the network quality between the static parent node and the first dynamic parent node is lower than a certain level, the static parent node then pulls the live video stream from a second dynamic parent node (... performing a domain name resolution on the target stream pulling information based on a preset domain name resolution method) [0091]).
Xie did not explicitly disclose obtaining the IP address of the target intranet edge server (emphasis added).
Andreev discloses obtaining the IP address of the target intranet edge server (emphasis added) (Andreev: fig 1-5, [0004-33]: ... client computer 202 is coupled to a first internal router 302a which is coupled to a geographically distributed enterprise network 304 ... coupled to the internet 310 is a first edge caching server 312a (target intranet edge server) which is topologically near client computer 202 and second edge caching server 312b topologically near internal DNS caching server 306 [0027-28] ... client computer browser 254 sends a domain name resolution request to the local operating system resolver service (Step 1) ... authoritative DNS 316 returns the IP address for the edge caching server (first edge caching server 312a) (obtaining the IP address of the target intranet edge server) that is closest to client computer 202 [0031]).
Xie and Andreev are analogous art because they are from the same field of endeavor with respect to edge servers.
Before the effective filing date, for AIA , it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by Andreev into the method by Xie. The suggestion/motivation would have been to allow a client computer to retrieve a subset of content served by a web server from a topologically closest edge caching server (Andreev: [0002]).
Xie and Andreev further disclose based on the IP address of the target intranet edge server, sending a target stream pulling request to the target intranet edge server (Xie: fig 1-6, [0006-121]: fig 4 ... accordingly, the CCL server may determine the network communication address of the target stream-pulling edge node corresponding to the area to which the viewer terminal belongs as the acquisition address (based on the IP address of the target edge server, sending a target stream pulling request to the target edge server) [0100];
Andreev: fig 1-5, [0004-33]: ... client computer browser 254 sends a domain name resolution request to the local operating system resolver service (Step 1) ... authoritative DNS 316 returns the IP address for the edge caching server (first edge caching server 312a) (based on the IP address of the target intranet edge server ...) that is closest to client computer 202 and FSFS substitutes the IP address in the DNS response for the IP address characters in the file system response to the browser 254 (... sending a target stream pulling request to the target intranet edge server) through the OS resolver service steps 6-8 [0031]), and
acquiring a target video stream returned by the target intranet edge server based on the target stream pulling request (Andreev: fig 1-5, [0004-33]; claim 2: sending a request to the edge caching server for the content; and receiving the content at the client computer (see with [0031] above - acquiring a target video stream returned by the target intranet edge server based on the target stream pulling request).
Same motivation applies as mentioned above to make the proposed modification.
As to claim 2, Xie and Andreev disclose receiving the target stream pulling information sent by the media server (Xie: fig 1-6, [0006-121]: fig 4 ... DNS system may receive the acquisition request and convert the target domain name of the acquisition request to a network communication address ... return the converted acquisition request to viewer terminal (receiving the target stream pulling information sent by the media server) [0094]).
As to claim 4, Xie and Andreev disclose sending the target stream pulling information to a domain name resolution server, to make the domain name resolution server perform the domain name resolution on the target stream pulling information based on the preset domain name resolution method, and obtain the IP address of the target intranet edge server (Andreev: fig 1-5, [0004-33]: ... client computer browser 254 sends a domain name resolution request to the local operating system resolver service (Step 1) ... authoritative DNS 316 returns the IP address for the edge caching server (first edge caching server 312a) (sending the target stream pulling information to a domain name resolution server, to make the domain name resolution server perform the domain name resolution on the target stream pulling information ..) that is closest to client computer 202 (... based on the preset domain name resolution method) and FSFS substitutes the IP address in the DNS response for the IP address characters in the file system response to the browser 254 (... and obtain the IP address of the target intranet edge server) through the OS resolver service (steps 6-8) [0031]),
wherein the domain name resolution server is a domain name resolution server in an intranet or a domain name resolution server in an outer net (Andreev: fig 1-5, [0004-33]: see fig 3 authoritative DNS 316 appears in outer net ); and
receiving the IP address of the target intranet edge server returned by the domain name resolution server (Andreev: fig 1-5, [0004-33]: ... client computer browser 254 sends a domain name resolution request to the local operating system resolver service (Step 1) ... authoritative DNS 316 returns the IP address for the edge caching server (first edge caching server 312a) that is closest to client computer 202 [0031]).
For motivation, see rejection of claim 1.
As to claim 5, see similar rejection to claim 1 where the method is taught by the method.
As to claim 5, Xie and Andreev further disclose extracting target intranet edge server address information that has a preset domain name format from the target stream pulling information and resolving the target intranet edge server address information into an IP address format, and obtaining the IP address of the target intranet edge server (Andreev: fig 1-5, [0004-33]: All WWW-based systems are capable of using a Domain Name Server (DNS) and when searching for a website, a user will typically type into her browser a Uniform Resource Locator (URL) (preset domain name format), which is a global address for a resource on the web (extracting target intranet edge server address information that has a preset domain name format from the target stream pulling information ...) ... to locate a website, the URL must be translated into an IP address (... resolving the target intranet edge server address information into an IP address format, and obtaining the IP address of the target intranet edge server) and this is performed by a DNS (domain name server) [0005]).
For motivation, see rejection of claim 1.
As to claim 6, see similar rejection to claim 1, where the method is taught by the method.
As to claim 6, Xie and Andreev further disclose determining an IP address of a target intranet edge server based on a target exit IP address in the stream pulling information acquisition request (Xie: fig 1-6, [0006-121]: ... algorithm for determining the dynamic parent node may be uniformly configured in advance in all the nodes of the CDN cluster (edge servers) by the technical staff of the live streaming acceleration system, and the algorithm may be a hash algorithm and the above determining process may be performed by hashing the video-playing address of the live video stream (... based on a target exit IP address in the stream pulling information acquisition request) to obtain network communication addresses of two dynamic parent nodes with a sequential order, and the first dynamic parent node may be selected (determining an IP address of a target intranet edge server [0089]).
For motivation, see rejection of claim 1.
As to claim 7, see similar rejection to claim 2.
As to claim 9, see similar rejection to claim 5.
As to claim 9, Xie and Andreev further disclose adding a converted target intranet edge server address information into a stream pulling address, and determining the target stream pulling information (Andreev: fig 1-5, [0004-33]: ... client computer browser 254 sends a domain name resolution request to the local operating system resolver service (Step 1) ... authoritative DNS 316 returns the IP address for the edge caching server (first edge caching server 312a) (see with [0005] - adding a converted target intranet edge server address information into a stream pulling address) that is closest to client computer 202 (... based on the preset domain name resolution method) and FSFS substitutes the IP address in the DNS response for the IP address characters in the file system response to the browser 254 (... and determining the target stream pulling information) through the OS resolver service (steps 6-8) [0031]).
For motivation, see rejection of claim 1.
As to claim 11, see similar rejection to claims 1 and 6, where the method is taught by the methods.
As to claims 18-20, see similar rejection to claim 1 where the device, medium and product, respectively, is/are taught by the method.
As to claim 21, see similar rejection to claim 5.
Claims 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Publication No. 2020/0322646 to Xie et al. (“Xie”) in view of U.S. Patent No. 2006/0253609 to Andreev et al. (“Andreev”) and further in view of U.S. Patent No. 2016/0182582 to Wagenaar et al. (“Wagenaar”).
As to claim 12, Xie and Andreev disclose the method of claim 11.
For motivation, see rejection of claim 1.
Xie did not explicitly disclose based on the target video stream identification in the target stream pulling request, determining the target video stream from a cached video stream that is cached in advance.
Wagenaar discloses based on the target video stream identification in the target stream pulling request, determining the target video stream from a cached video stream that is cached in advance (Wagenaar: fig 1-5, [0006-39]: ... to fulfill a request, an edge node 120 determines where to find a source of media, in this case, the origin 110 from which to pull media content in step B (based on the target video stream ... in the target stream pulling request) and origin 110 returns a fragment or current chunk of media and a link header identifying chunks of media that the edge node 120 may fetch (based on the target video stream identification in the target stream pulling request ...), pre-fetching next chunks of media (... determining the target video stream from a cached video stream that is cached in advance) [0030] ... link header 200 includes one or more links 210 where the edge node 120 can retrieve a current chunk of media and includes at least one link 220 for a next chunk of media (see with [0030] above - based on the target video stream identification in the target stream pulling request, determining the target video stream from a cached video stream that is cached in advance) [0031]).
Xie, Andreev and Wagenaar are analogous art because they are from the same field of endeavor with respect to caching.
Before the effective filing date, for AIA , it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by Wagenaar into the method by Xie and Andreev. The suggestion/motivation would have been to provide an origin-edge architecture to mitigate and substantially remove latency due to cache misses (Wagenaar: [0006]).
As to claim 13, see similar rejection to claim 12, where the method is taught by the method.
As to claim 13, Xie, Andreev and Wagenaar further disclose based on the target video stream identification in the target stream pulling request, detecting whether the target video stream exists in a cached video stream that has been cached currently (Wagenaar: fig 1-5, [0006-39]: ... to fulfill a request, an edge node 120 determines where to find a source of media, in this case, the origin 110 from which to pull media content in step B (based on the target video stream ... in the target stream pulling request) and origin 110 returns a fragment or current chunk of media and a link header identifying chunks of media that the edge node 120 may fetch (based on the target video stream identification in the target stream pulling request ...), pre-fetching next chunks of media [0030] ... fig 1-3 ... edge node 120 at step D requests a fragment previously identified in link header 200 (see with [0030] above - based on the target video stream identification in the target stream pulling request) and, notably, step D for pre-fetching the next chunk of media occurs whilst the edge node 120 is delivering the current media chunk to viewer 130 and step D occurs, not for a current request of media content but in anticipation of a request for the next chunk of media ... the method of pre-fetch is implemented in one of two ways which are selectively configurable and edge node can selectively determine which one of the ways to pre-fetch depending on a user request, user demand context or responsive to content delivery rules (... detecting whether the target video stream exists in a cached video stream that has been cached currently) [0035-36]);
in response to the target video stream existing in the cached video stream that has been cached currently, determining the cached video stream as the target video stream (Wagenaar: fig 1-5, [0006-39]: ... when a request comes into an edge node, it first checks the cache to see if the content is present and a cache key is the entire URL including query check cache keys ( e.g., like in a browser) and if the content is in cache and the cache entry has not expired, then the content is served directly from the edge server (in response to the target video stream existing in the cached video stream that has been cached currently, determining the cached video stream as the target video stream) [0029]); and
in response to the target video stream being absent from the cached video stream that has been cached currently, pulling the target video stream from an extranet edge server based on an outer net stream pulling address in the target stream pulling request, and caching the pulled target video stream (Wagenaar: fig 1-5, [0006-39]: ... when a request comes into an edge node, it first checks the cache to see if the content is present and a cache key is the entire URL including query check cache keys ( e.g., like in a browser) (based on an outer net stream pulling address in the target stream pulling request) ... if however the content is not in the cache or the cache entry has expired (in response to the target video stream being absent from the cached video stream that has been cached currently ...), then the edge node 120 makes a request to the origin 110 to retrieve the information and origin 110 is the source of content and is capable of serving all of the content that is available on the CDN (... pulling the target video stream from an extranet edge server based on an outer net stream pulling address in the target stream pulling request ...) and when the edge server receives the response from the origin server, it stores the content in cache (... and caching the pulled target video stream) based on the HTTP headers of the response [0029]).
For motivation, see rejection of claim 12.
Conclusion
The following prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
A) US 2014/0317671 Hu
Embodiments of the present invention disclose a method includes: sending, by a terminal device, video server name information in video request information to a local domain name server; receiving, by the terminal device, address information of a buffer sent by the local domain name server, and sending the video request information to the buffer according to the address information of the buffer; detecting whether a video resource corresponding to video identification information in the video request information exists in the buffer; and if the video resource corresponding to the video identification information exists in the buffer, sending, by the buffer, the video resource to the terminal device. The present invention is applicable to transmission of a network video resource.
B) US 2022/0141500 – Du
A method for co-hosting in live streaming includes sending, in response to receiving a co-hosting request from a live streaming account, the co-hosting request to a target user account for co-hosting; and sending, in response to receiving co-hosting grant information from the target user account, a first live data stream and a second live data stream to a viewer account. The first live data stream corresponds to the target user account, the second live data stream corresponds to the live streaming account. The second live data stream is pushed by the live streaming account using a target live streaming tool, and the target live streaming tool is configured to push the second live data stream for the live streaming account and pull the first live data stream for the live streaming account.
C) US 20250193466 – Zheng
Disclosed are a video stream data acquisition method and apparatus. An implementation of the method includes: determining, in response to receiving a stream pulling data packet from a target terminal, whether a machine room identifier of a communication machine room that receives the stream pulling data packet is the same as a target machine room identifier included in the stream pulling data packet, where the stream pulling data packet is generated during the target terminal's playing of a video stream, and the target machine room identifier is a machine room identifier of a communication machine room that receives a first stream pulling data packet first generated when the target terminal is playing the video stream; if not, forwarding the stream pulling data packet to a target communication machine room corresponding to the target machine room identifier; and acquiring video stream data through the target communication machine room.
D) US 20260005997 – Liu
Embodiments of the present disclosure provide a data processing method, an electronic device, and a non-transitory storage medium. The method includes: acquiring, when at least one target node cluster corresponding to a multimedia data stream acquisition request is found based on a pre-created mapping relationship, target stream pulling information of a current node cluster corresponding to the multimedia data stream acquisition request; and determining, when the target stream pulling information meets a preset condition, a target server address corresponding to the multimedia data stream acquisition request based on node information of nodes in the at least one target node cluster and the current node cluster so that a multimedia server provides a target service corresponding to the multimedia data stream acquisition request based on the target server address.
E) US 20250202996 - Guo
Disclosed in the present disclosure are a CDN network request scheduling method, an electronic device, and a storage medium. The method includes: obtaining an original network request generated by the client for a target service; obtaining a first domain name rewriting rule corresponding to the target attribution information, and rewriting the original domain name by using the first domain name rewriting rule, to obtain a first domain name; updating the original domain name in the original network request by using the first domain name, to obtain a target network request; and sending the target network request to a target CDN server corresponding to the target CDN service provider identifier, so that the target CDN server obtains a target scheduling path corresponding to the target equipment room identifier, and forwards the target network request to a target equipment room according to the target scheduling path.
F) US 20250385847 – Wang
The present disclosure provides a method of traffic scheduling implementation, including: receiving a domain name resolution request sent by a first business application on a first terminal device, and performing domain name resolution on the domain name resolution request to determine a to-be-resolved domain name; if the to-be-resolved domain name is a target domain name, determining, from a preset network segment, a first virtual network address corresponding to the to-be-resolved domain name, and using the first virtual network address as a first traffic destination address corresponding to the to-be-resolved domain name, where the preset network segment includes a plurality of virtual network addresses; and sending the first traffic destination address to the first business application on the first terminal device, to cause the first business application to perform data transmission based on the first traffic destination address.
G) US 20250220076 – Yu
A method for processing a domain name resolution request is provided. The method includes: obtaining first request information of a first domain name resolution request sent by a target client, wherein the first request information comprises a domain name to be resolved carried in the first domain name resolution request, and client information of the target client; obtaining a first information set from a second server, in response to determining that first target node information corresponding to the first request information is not stored in the first server based on the domain name to be resolved and the client information, wherein the first information set is a collection of first candidate node information corresponding to the first request information; taking at least one first candidate node information in the first information set as the first target node information, and sending the first target node information to the target client.
H) US 20240275787 – Han
The disclosure provides a method, an apparatus, a computer device and storage medium for application access control. The method includes: receiving, by an IAM system, a first access request for accessing a target application managed by the IAM system; and rewriting, by the IAM system, the first access request to obtain a second access request comprising proxy domain name information; obtaining, by a proxy server, the second access request, and parsing the proxy domain name information to determine the domain name information of the target application; based on the need for login authentication information, obtaining login account information and obtaining login authentication information input by the user; and sending a login request to an application server corresponding to the target application.
I) US 20240314103 – Gupta
Methods, systems, and devices in which a computer networking device may compare the destination address of the a name resolution request with a stored list of addresses. If the destination address does not match any of the addresses from the stored list, the computer networking device may perform one or more actions, such as sending a notification, redirecting the name resolution request to one of the servers in the list, or generating a new name resolution request. For example, a method may include receiving network traffic from a client device including a first name resolution request; comparing a first destination address from the first name resolution request with a list of addresses indicating servers to which the client device is to communicate name resolution requests; and detecting that the first destination address does not match any of the addresses from the list of addresses.
J) US20170163706 – Liu
Disclosed are a method, an electronic device and a system for controlling a pull stream. The method includes: receiving a user request forwarded by a content delivery network (CDN) server, wherein the user request is used for requesting to watch a live video; detecting whether a stream state of the live video at a source server is on live, wherein the stream state is a stream state of a live video of the user request; instructing the source server to pull a video stream of the live video to a third-party server if the stream state at the source server is not on live; receiving a stream state returned by the source server, wherein the stream state returned by the source server is on live; and sending a back-to-source path of the video stream to the CDN server so that the CDN server sends the back-to-source path to a client.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JUNE SISON whose telephone number is (571)270-5693. The examiner can normally be reached 9:00 am - 5:00 pm.
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, Emmanuel Moise can be reached at 571-272-3865. 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.
/JUNE SISON/Primary Examiner, Art Unit 2455