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 .
Claim Rejections - 35 USC §103
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 4-10, 11 and 14-20 are rejected under 35 U.S.C. 103 as being unpatentable over Ante, et al., (hereinafter referred to as “Ante,” US 2021/0016179) in view of Rosenberg (US 2023/0385967).
Regarding claims 1, and substantially similar limitations in claims 11, and 20, Ante discloses a data storage device (see para. [0055]: FIG. 7 is a block diagram illustrating components of a machine 800, according to some example embodiments, configured to read instructions from a machine-readable medium (e.g., a machine-readable storage medium) and perform any one or more of the methodologies discussed herein) comprising:
a non-volatile memory (see para. [0057]: The memory/storage 830 may include a memory, such as a main memory 832, a static memory 834, or other memory, and a storage unit 836, both accessible to the processors 810 such as via the bus 802; see para. [0058] As used herein, “machine-readable medium” means a device able to store instructions and data temporarily or permanently and may include, but is not limited to, random-access memory (RAM), read-only memory (ROM), buffer memory, flash memory, optical media, magnetic media, cache memory, other types of storage (e.g., Erasable Programmable Read-Only Memory (EEPROM)) and/or any suitable combination thereof. The term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) able to store the instructions 816. The term “machine-readable medium” shall also be taken to include any medium, or combination of multiple media, that is capable of storing instructions (e.g., instructions 816) for execution by a machine (e.g., machine 800), such that the instructions, when executed by one or more processors of the machine 800 (e.g., processors 310), cause the machine 800 to perform any one or more of the methodologies described herein. Accordingly, a “machine-readable medium” refers to a single storage apparatus or device, as well as “cloud-based” storage systems or storage networks that include multiple storage apparatus or devices. The term “machine-readable medium” excludes signals per se);
a display unit (see para. [0059]: The output components 852 may include visual components (e.g., a display such as a plasma display panel (PDP), a light emitting diode (LED) display, a liquid crystal display (LCD), a projector, or a cathode ray tube (CRT)), acoustic components (e.g., speakers), haptic components (e.g., a vibratory motor, resistance mechanisms), other signal generators, and so forth); and
control circuitry (see para. [0024]: In accordance with an embodiment, the developer device 102 includes one or more central processing units 103 (CPUs), and graphics processing units 105 (GPUs). The CPU 103 is any type of processor, processor assembly comprising multiple processing elements (not shown), having access to a memory 101 to retrieve instructions stored thereon, and execute such instructions. Upon execution of such instructions, the instructions implement the developer device 102 to perform a series of tasks as described herein. The memory 101 can be any type of memory device, such as random access memory, read only or rewritable memory, internal processor caches, and the like) configured to: receive a write command from a host, wherein data associated with the write command includes one or more game assets relating to a gaming application; determine a first game asset file associated with the data (see para. [0016]: There is described herein an Addressable Asset System which provides efficient runtime loading of digital assets for a game using an address; see para. [0017]: In example embodiments, a method for tracking game asset locations is disclosed. Content is created for an application using a first asset. The first asset includes asset data that describes at least a part of the content associated with the asset. The asset data is placed within one or more files within a location within one or more memories. A catalog associated with the application is created on the server. A catalog entry is created for the first asset. The catalog entry includes at least an address and location data, the address being a unique identifier for the first asset and the location data being a description of the location of the first asset. A request is received from the application for asset data associated with the first asset, the request including the address. The address and the catalog are used to determine the location data associated with the address. The determined location data is used to retrieve the asset data at the determined location. The retrieved asset data is returned to the application);
add one or more addresses associated with the first game asset file and corresponding game asset information to a game asset mapping table configured to map the addresses and corresponding game assets (see para. [0017]: A catalog associated with the application is created on the server. A catalog entry is created for the first asset. The catalog entry includes at least an address and location data, the address being a unique identifier for the first asset and the location data being a description of the location of the first asset);
receive a read command from a host, wherein data associated with the read command relates to one or more game assets (see para. [0034]: In accordance with an embodiment, and in reference to FIG. 5, at operation 500 of the runtime mode 204, the application runs (e.g., is executed) on the user device 162. For example, the application may be executed by a user operating the user device 162 (e.g., in order to play a game via a runtime version of the application 174). In accordance with an embodiment, at operation 502 of the runtime mode 204, the application 174 (while executing) requires an asset from within an asset bundle. The executing application determines the address for the required asset and sends a request that includes the address to the addressable asset module 166. The request includes the address and a request for data associated with the required asset (e.g., asset data within the asset files));
determine, based on the game asset mapping table, a second game asset file associated with one or more addresses associated with the read command (see para. [0034]: The request includes the address and a request for data associated with the required asset (e.g., asset data within the asset files). In accordance with an embodiment, at operation 504 of the runtime mode 204, the addressable asset module 166 communicates over the network 150 with (e.g., sends a request) the content catalog on the content server 140 to determine a current location for the data associated with the address. In accordance with an embodiment, at operation 506 of the runtime mode 204, the addressable asset module 166 asynchronously downloads the required asset data from the current location received from the content catalog); and
provide display control instructions to the display unit, wherein the display control instructions are configured to provide a visual indication (see para. [0025]: The display device 109 is driven or controlled by the one or more GPUs 105 and optionally the CPU 103. The GPU 105 processes aspects of graphical output that assists in speeding up rendering of output through the display device 109).
Per claim 11, Ante discloses a method of providing game asset display control in a data storage device (see para. [0017]: In example embodiments, a method for tracking game asset locations is disclosed. Content is created for an application using a first asset. The first asset includes asset data that describes at least a part of the content associated with the asset. The asset data is placed within one or more files within a location within one or more memories. A catalog associated with the application is created on the server. A catalog entry is created for the first asset. The catalog entry includes at least an address and location data, the address being a unique identifier for the first asset and the location data being a description of the location of the first asset. A request is received from the application for asset data associated with the first asset, the request including the address. The address and the catalog are used to determine the location data associated with the address. The determined location data is used to retrieve the asset data at the determined location. The retrieved asset data is returned to the application).
Ante fails to explicitly disclose one or more logical block addresses (LBAs); determine game progress associated with the second game asset file; and provide a visual indication relating to the game progress. However, Ante teaches one or more addresses (see para. [0031]: At operation 306, the addressable asset module 116 provides an address for the asset and associates the address with a location for the asset data (e.g., a file path name). In accordance with an embodiment, the location includes physical locations such as a content server 140 (e.g., a content delivery network), remote servers and local data storage (e.g., a local hard drive on the developer device 102). The address identifies the asset for efficient retrieval at runtime (e.g., when the game is being played). In accordance with an embodiment, the asset address is initialized to a string value of a file path location of a file containing data for the asset).
Furthermore, specifying that the addresses are logical block addresses, would involve routine skill in the art. It would have been obvious to one of ordinary skill in the art to modify Unity with the addresses for the purpose of providing efficient runtime loading of digital assets for a game using an address. The Addressable Asset System handles asset management for a game and simplifies content creation and deployment. In accordance with an embodiment, during the playing of a game (e.g., execution of game code), the Addressable Asset System allows the game code to simply query an address associated with a digital asset at runtime and receive data which describes the digital asset that resides at the address (see Ante, para. [0016]).
Rosenberg teaches determine game progress associated with the second game asset file (see para. [0063]: In some examples, the digital asset can include a save file that saves progress in a video game at a particular point in the progression (e.g., in the story) of the video game. The save file can be identified as an in-game digital asset, since it is usable in-game. The save file can be identified as a video game digital media asset, since it functions as a representation of a moment of gameplay at which the save file was saved); and provide a visual indication relating to the game progress (see para. [0026]: [0026] In some examples, the asset may be an instance of the video game. In some examples, the asset may be in-game content, such as in-game items, characters, environments (e.g., levels, stages, worlds), objectives, save files, DLC, IAP, or combinations thereof. The asset may be video game digital media asset with media representations of moments of gameplay of a video game, such as video clips, images, and/or audio clips; see para. [0028]: The network environment 100 may include one or more interactive content servers 110 that provide streaming content (e.g., interactive video, podcasts, video game content, etc.), one or more platform servers 120, one or more user devices 130, one or more data structures 140, one or more distributed ledgers 150; see para. [0030]: The platform servers 120 may be responsible for communicating with the different interactive content servers 110, data structures 140, and user devices 130. Such platform servers 120 may be implemented on one or more cloud servers. The interactive content servers 110 may communicate with multiple platform servers 120, though the media interactive content servers 110 may be implemented on one or more platform servers 120. The platform servers 120 may also carry out instructions, for example, receiving a user request from a user to stream streaming media (i.e., video games, activities, video, podcasts, User Generated Content (“UGC”), publisher content, etc.). The platform servers 120 may further carry out instructions, for example, for streaming the streaming media content titles. Such streaming media may have at least one object set associated with at least a portion of the streaming media. Each set of object data may have data about an object (e.g., activity information, zone information, actor information, mechanic information, game media information, etc.) displayed during at least a portion of the streaming media).
Rosenberg is analogous to Ante, as both are drawn to the art of asset management. It would have been obvious to one of ordinary skill in the art to modify Ante with the asset management system of Rosenberg for the of purpose creating, modifying, tracking, authenticating, and/ or transferring usability of digital assets associated with video game(s) in order to expand the capabilities of systems that manage usability of digital assets associated with video games by providing a process through which such systems to transfer usability of such digital assets, for instance by disabling usability of an asset at one user device and enabling usability of the asset at another user device in response to a trigger condition ... The techniques and technologies described herein allow for secure and comprehensive tracking of the history of a digital asset, for instance tracking when, how, and by whom the digital asset was created, used, modified, rented to, rented by, sold to, purchased by, licensed to, licensed by, exchanged to, exchanged by, transferred to, transferred by, and/or other actions (see Rosenberg para. [0027]).
Regarding claim 4, and substantially similar limitations in claim 14, Ante discloses wherein the one or more game assets include one or more of: three-dimensional models, two-dimensional sprites, textures, images, animations, or audio data (see para. [0020]: The terms ‘asset’, ‘game asset’, and ‘digital asset’, used herein are understood to include any data that can be used to describe a game object or can be used to describe an aspect of a game or project. For example, an asset can include data for an image, a 3D model (textures, rigging, and the like), a group of 3D models (e.g., an entire scene), an audio sound, a video, animation, a 3D mesh and the like. The data describing an asset may be stored within a file, or may be contained within a collection of files, or may be compressed and stored in one file (e.g., a compressed file), or may be stored within a memory. The data describing an asset can be used to instantiate one or more game objects within a game at runtime).
Regarding claim 5, and substantially similar limitations in claim 15, Ante fails to explicitly disclose wherein the control circuitry is further configured to determine the game progress associated with the second game asset file in connection with another game asset file. However, Rosenberg teaches wherein the control circuitry is further configured to determine the game progress associated with the second game asset file in connection with another game asset file (see para. [0061]:The digital asset 405 that the token 400 represents can be an instance of a video game. The digital asset 405 that the token 400 represents can be an in-game digital asset, such as an in-game item, and in-game character (which can be referred in-game actor), an in-game costume for an in-game character, an in-game area, a save file for a game, a configuration for a game, a DLC, an IAP, or a combination thereof. An in-game digital asset can be referred to as an in-game object, as in the object of FIGS. 2A-2B. An in-game character can be referred to as an in-game actor, as in the actor 254 of FIG. 2B. An in-game area can be referred to as an in-game zone, as in the zone 252 of FIG. 2B. In some examples, the in-game character can be a player character controlled by a player, a non-player character (NPC) that the player cannot control (but in some cases can interact with), or some combination thereof. In some examples, an in-game costume can include in-game representations of clothing, outfits, armor, suits, hats, helmets, tops, shirts, jackets, bottoms, pants, skirts, gloves, gauntlets, shoes, boots, fins, eyewear, headwear, handwear, legwear, footwear, jewelry, accessories, another article of clothing, or combinations thereof. In some examples, in-game items can include ranged weapons, melee weapons, potions, food, consumables, armors, shields, ammunition, magic abilities, health-restorative items, mana-restorative items, vehicles, power-ups, extra lives, extra continues, items that modify the attributes of other items (e.g., upgrading a bow and arrow to shoot fire arrows), or combinations thereof).
Rosenberg is analogous to Ante, as both are drawn to the art of asset management. It would have been obvious to one of ordinary skill in the art to modify Ante with the asset management system of Rosenberg for the purpose of creating, modifying, tracking, authenticating, and/ or transferring usability of digital assets associated with video game(s) in order to expand the capabilities of systems that manage usability of digital assets associated with video games by providing a process through which such systems to transfer usability of such digital assets, for instance by disabling usability of an asset at one user device and enabling usability of the asset at another user device in response to a trigger condition ... The techniques and technologies described herein allow for secure and comprehensive tracking of the history of a digital asset, for instance tracking when, how, and by whom the digital asset was created, used, modified, rented to, rented by, sold to, purchased by, licensed to, licensed by, exchanged to, exchanged by, transferred to, transferred by, and/or other actions (see Rosenberg para. [0027]).
Regarding claim 7, and substantially similar limitations in claim 16, Ante discloses wherein a game asset is associated with a game asset identifier (see para. [0031]: In accordance with an embodiment and shown in FIG. 3 are operations of the application content creation process 200 from the application development cycle 205. At operation 300, the developer 130 creates content for an application, using one or more assets. As part of the creation process, the developer 130 can import assets for the application, and can create assets for the application. Creating content includes creating game objects (e.g., characters and scenery), game levels and more. At operation 302, the game engine 104 generates a unique identification (or unique ID) for each asset (e.g., including numeric, alpha, alphanumeric or any type of string identification). The unique ID is a permanent unique identifier that identifies one asset. Data that defines an asset is stored in one or more files. At operation 304, using the Addressable Asset System 100, the developer 130 indicates that an asset is to be addressable (e.g., via a graphical user interface generated by the module 116 or via code and an Application Interface (API) provided by the module 116). In accordance with an embodiment, an addressable asset has an associated name (e.g., a string label) for easy identification and referencing of the addressable asset. In some embodiments, a label may be shared by a group of addressable assets. The label for the addressable asset provides a secondary identifier which can be used for runtime loading of a plurality of similar assets. For example, a game may include several types of space hazards and which are labeled ‘spaceHazards’ and which can all be accessed with a single command that uses the label as input (e.g. LoadAll(“spaceHazards”)). At operation 306, the addressable asset module 116 provides an address for the asset and associates the address with a location for the asset data (e.g., a file path name). In accordance with an embodiment, the location includes physical locations such as a content server 140 (e.g., a content delivery network), remote servers and local data storage (e.g., a local hard drive on the developer device 102). The address identifies the asset for efficient retrieval at runtime (e.g., when the game is being played). In accordance with an embodiment, the asset address is initialized to a string value of a file path location of a file containing data for the asset. At operation 308, the addressable asset module 116 tracks a location of the asset data (e.g., by tracking the file or files that contain the data) as the data is moved (e.g., by the developer).
Regarding claim 8, and substantially similar limitations in claim 17, Ante discloses wherein a game asset is associated with a stage of a game (see para. [0031]: In accordance with an embodiment and shown in FIG. 3 are operations of the application content creation process 200 from the application development cycle 205. At operation 300, the developer 130 creates content for an application, using one or more assets. As part of the creation process, the developer 130 can import assets for the application, and can create assets for the application. Creating content includes creating game objects (e.g., characters and scenery), game levels and more.; See para. [0032]: In accordance with an embodiment, the addressable asset module 116 prioritizes a subset of assets to be included in an asset bundle (e.g., including assets for a user interface menu, a game or application tutorial, and first-level game content).
Regarding claim 9, and substantially similar limitations in claim 18, Ante discloses wherein the game asset mapping table is configured to include one or more of: one or more LBAs associated with a game asset, a game asset identifier of the game asset, or one or more physical addresses associated with the one or more LBAs (see para. [0017]: In example embodiments, a method for tracking game asset locations is disclosed. Content is created for an application using a first asset. The first asset includes asset data that describes at least a part of the content associated with the asset. The asset data is placed within one or more files within a location within one or more memories. A catalog associated with the application is created on the server. A catalog entry is created for the first asset. The catalog entry includes at least an address and location data, the address being a unique identifier for the first asset and the location data being a description of the location of the first asset. A request is received from the application for asset data associated with the first asset, the request including the address. The address and the catalog are used to determine the location data associated with the address. The determined location data is used to retrieve the asset data at the determined location. The retrieved asset data is returned to the application.).
Regarding claim 10, and substantially similar limitations in claim 19, Ante discloses wherein the display unit includes one or more light-emitting diodes (LEDs) (see para. [0059]: It will be appreciated that the input/output (I/O) components 850 may include many other components that are not shown in FIG. 1. The input/output (I/O) components 850 are grouped according to functionality merely for simplifying the following discussion and the grouping is in no way limiting. In various example embodiments, the input/output (I/O) components 850 may include output components 852 and input components 854. The output components 852 may include visual components (e.g., a display such as a plasma display panel (PDP), a light emitting diode (LED) display, a liquid crystal display (LCD), a projector, or a cathode ray tube (CRT)), acoustic components (e.g., speakers), haptic components (e.g., a vibratory motor, resistance mechanisms), other signal generators, and so forth).
Ante and Rosenberg fail to explicitly disclose the visual indication is based on one or more of: a color or intensity of the one or more LEDs. However, the Applicant’s use of the visual indication is based on one or more of: a color or intensity of the one or more LEDs is an obvious design choice. Applicant has not disclosed that visual indication is based on one or more of: a color or intensity of the one or more LEDs solves any stated problem or is for any particular purpose. Moreover, it appears that any visual indication protocol using the device of Ante and Rosenberg or the Applicant would perform equally well. Therefore, it would have been prima facie obvious to modify Ante and Rosenberg to obtain the device as specified in claims 10 and 19, because such a modification would have been considered a mere design consideration which fails to patentably distinguish over the prior art of Ante and Rosenberg.
Claims 2, 3, 12, and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Ante and Rosenberg, in view of Nguyen, et al., (hereinafter referred to as “Nguyen,” US 2023/0144263).
Regarding claim 2, and substantially similar limitations in claim 12, Ante fails to explicitly disclose wherein the control circuitry is further configured to parse the data associated with the write command to identify the one or more game assets. However, Nguyen teaches wherein the control circuitry is further configured to parse the data associated with the write command to identify the one or more game assets (see para. [0146]: In a specific implementation, the remote paging file subsystem 1004 is implemented, at least in part, as part of a kernel of the virtualized asset utilization system 1002. The remote paging file subsystem 1004 can intercept requests for portions of virtualized assets and provide the intercepted requests for purposes of remote paging the virtualized assets. For example, the remote paging file subsystem 1004 can intercept a request for a file of a virtualized asset and handle the request. The remote paging file subsystem 1004 can implant a stub in response to intercepting a request to trick the virtual asset utilization system that a portion of a virtualized asset does actually reside at the virtual asset utilization system when it is actually virtualized at the virtual asset utilization system. In various implementations, the remote paging file subsystem 1004 can intercept and provide data for writing to a portion of a virtualized asset and/or a pointer to a location in the virtualized asset where the data should be written. For example, the remote paging file subsystem 1004 can intercept a request to write to a file of a virtualized asset and provide data and a pointer indicating what and where to write in the file).
Nguyen is analogous to Ante and Rosenberg, as all are drawn to the art of asset management. It would have been obvious to one of ordinary skill in the art to modify Ante and Rosenberg with Nguyen for the purpose of virtualizing assets remotely from content clients in order to reduce the amount of memory that content clients need to correctly operate and improve the scalability and processing power of networks having content clients (see Nguyen, para [0002]).
Regarding claim 3, and substantially similar limitations in claim 13, Ante fails to explicitly disclose wherein the control circuitry is further configured to parse the data associated with the write command based on one or more of: a file format, an internal reference in a game asset, or metadata associated with a game asset. However, Nguyen teaches wherein the control circuitry is further configured to parse the data associated with the write command based on one or more of: a file format, an internal reference in a game asset, or metadata associated with a game asset (see para. [0147]: The remote paging file subsystem 1004 shown in FIG. 10 includes an asset request interceptor engine 1006, a stub datastore 1008, a stub implantation engine 1010, and a remote paging engine 1012. The asset request interceptor engine 1006 functions to intercept a request for purposes of remote paging a portion of a virtualized asset. Depending upon implementation-specific or other considerations, the asset request interceptor engine 1006 can intercept a request for a portion of a virtualized asset. Further depending upon implantation-specific or other considerations, the asset request interceptor engine 1006 can intercept a request to exploit a virtualized asset in a specific manner. For example, the asset request interceptor engine 1006 can intercept a request to move a player to a specific position in a game. Depending upon implementation-specific or other considerations, the asset request interceptor engine 1006 can intercept a request of data to write to a portion of a virtualized asset and/or a pointer to a location in the virtualized asset where the data should be written.).
Nguyen is analogous to Ante and Rosenberg, as all are drawn to the art of asset management. It would have been obvious to one of ordinary skill in the art to modify Ante and Rosenberg with Nguyen for the purpose of virtualizing assets remotely from content clients in order to reduce the amount of memory that content clients need to correctly operate and improve the scalability and processing power of networks having content clients (see Nguyen, para [0002]).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Ante and Rosenberg, in view of Kruglick (US 2015/0258437).
Regarding claim 6, Ante fails to explicitly disclose wherein the control circuitry is further configured to compare a game asset identifier of the second game asset file and a game asset identifier of the other game asset file. However, Kruglick teaches wherein the control circuitry is further configured to compare a game asset identifier of the second game asset file and a game asset identifier of the other game asset file (see para. [0036]: Embodiments may score cache performance of the multiple different generated video game missions at least in part by identifying digital assets used by the video game missions, and determining whether the identified digital assets are in a cache. For example, a list of keys may be generated or retrieved to identify digital assets used by a particular generated mission. The list of keys may be compared to a cache table identifying digital assets stored in a cache. A cache score may comprise a cache re-use rate corresponding to a proportion of digital assets for a mission that are already in a cache. Other techniques for generating cache scores may be applied in some embodiments, and may account for factors such as overall size, e.g., in kilobytes (kB) or Megabytes (MB), of combined digital assets for a mission that are already in a cache and/or overall size of combined digital assets for a mission that are not already in a cache).
Kruglick is analogous to Ante and Rosenberg, as all are drawn to the art of asset management. It would have been obvious to one of ordinary skill in the art to modify Ante and Rosenberg with Kruglick for the purpose of improving technologies relating to providing digital assets for video games, whether such games are multiplayer games accessed over networks, or otherwise by caching digital assets since cached digital assets can generally be retrieved more efficiently than digital assets stored elsewhere, such as on disk or in a database, and therefore video game performance may be improved by increasing re-use rates of cached digital assets (see Kruglick, paras. [0005]-[0006]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ROBERT P. BULLINGTON whose telephone number is (313) 446-4841. The examiner can normally be reached on Monday through Friday from 8 A.M. to 4 P.M. If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Peter Vasat, can be reached on (571) 270-7625. The fax phone number for the organization where this application or proceeding is assigned is (571) 273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://portal.uspto.gov/external/portal. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at (866) 217-9197 (toll-free).
/Robert P Bullington, Esq./ Primary Examiner, Art Unit 3715