Patent ID: 12251783

DETAILED DESCRIPTION

The present invention will now be described in more detail with reference to exemplary embodiments as shown in the accompanying drawings. While the present invention is described herein with reference to the exemplary embodiments, it should be understood that the present invention is not limited to such exemplary embodiments. Those possessing ordinary skill in the art and having access to the teachings herein will recognize additional implementations, modifications, and embodiments, as well as other applications for use of the invention, which are fully contemplated herein as within the scope of the present invention as disclosed and claimed herein, and with respect to which the present invention could be of significant utility.

The present invention provides a low-cost, counter-mounted box replacement key ordering device, that uses a smart device, such as a smartphone, all-in-one computer, or tablet (e.g., a device that comprises a touchscreen interface and camera), a minimal clamp to hold a key blade from a master key in the box in front of the smart device's camera, and a low cost light source to capture an image of the master key to be used for providing a replacement key, which may be referred to as a key copy or cut key, to a customer or user operating the replacement key ordering device. In some embodiments, the light source may not be used and a printed grid positioned adjacent to the key may be used to provide scale and/or perspective for a captured image.

With reference toFIGS.1and2, perspective views of an apparatus for obtaining a captured image of a master key according to the system and application of the present invention are provided. The apparatus, replacement key ordering device100, which may be referred to herein and in the figures as a remote order key system, retail order kiosk system, or Retail Optical Key Scanning (“ROKS”) box100or as the ROKS device100, comprises a housing102in which a smart device200is disposed at the front. The touch-screen or display210of the smart device200, which is a tablet, smart phone, or other device capable of displaying information, receiving user inputs, communicating over a network, and capturing images, is accessible at the front of the housing102. A key port or slot320is at the top160of the housing and provides for a key to be inserted into the clamp assembly300for holding the key blade of a master key to be imaged for copying. A removable side panel110is removably secured, such as by magnets, clips, or other suitable fasteners, in an opening104in one side of the housing102.

The clamp assembly300is disposed at the top160of the housing102and in the interior space190of the housing102, wherein the key channel330is correspondingly positioned with the key port or slot320such that the key blade of a master key to be imaged for copying may be inserted through the key port or slot320into the key channel330of the clamp assembly300. The key channel330of the clamp assembly300aligns and positions the key blade of the master key such that an imaging device, such as a camera, of the smart device200may capture an image of the key blade. The imaging device may be an integral feature of the smart device200or may be a separate device operatively connected to communicate an image to the smart device200. The key channel330may comprise a retaining mechanism such as a set of tabs, spring retention posts, springs, or elastic positioning members such as silicone protrusions to position and align a key blade within the key channel330.

The body220of the smart device200is retained in the interior space190of the housing102by a set of retaining members170such that the display210of the smart device200is viewable and accessible via an opening at the front of the housing102. A set of magnetic retainers130and140, disposed on and secured to respective brackets132and142, are used to releasably and magnetically secure the side panel110in place. A set of vents122and an access port120may be positioned at the back of the housing102to provide for a charging, power, and/or data cable to reach the smart device200and to provide for the exhaust of heat generated by the smart device200from the interior190of the housing102. A set of one or more illumination devices150may be used to illuminate the key blade in the key channel330of the clamping assembly300for image capture by the smart device200. Alternatively, a light source on the smart device200, such as a flash, flashlight, or other rear light source, may be used. Additionally, alternatively or in addition to the illumination devices150a keyed scale or other indicators or markings310may be placed on the clamping assembly300adjacent to the key channel330to provide for determining the positioning, scale, angle, size, and other attributes of the key blade of the master key and may be included in an image presented via display210to the user to assist in proper alignment and position of the key blade for imaging.

The remote access device100serves as a key ordering portal or device and provides for a sales model that may be referred to as “hub and spoke”. The “spoke” is, for example, an auto parts store, auto repair shop, or tire shop that is frequented by car owner customers, e.g., in connection with repair services for the customer's car. The “hub” is, for example, a large retail parts store or distribution center with a more extensive inventory for serving a plurality of “spoke” stores located within a few miles of it. This model typically involves the hub or spoke having drivers regularly receiving or delivering parts from the hub to the spoke.

With reference now toFIGS.3-6, provide a series of flowcharts illustrating an exemplary process400for a user presenting a master key for imaging and duplicating and for ordering a duplicate or replacement of a master key according to the present invention are provided.

At step401the customer using the device100at the spoke location encounters the device100displaying a looping splash screen on the display210of the smart device200, shown inFIGS.1-2. At step402the user interacts with the display210to begin entering information, and then in step403the user enters their vehicle data, such as vehicle make, model, and year (“MMY”). At decision404it is determined if more than one compatible key of any type and same key fob button count/configuration exist for the entered vehicle make and model. In the event multiple key blank types are associated with the MMY and other data entered by the user the system may prompt the user with a series of questions to further limit the set of potential key blank matches from the database of stored OEM key types. This process may include presenting via a display a series of prompts, and wherein the series of prompts may include one or more of: iteratively determining through database means a prompt (e.g., “To start the car, do you press a start button?”, “Which stamp do you have on the blade”, “Which key head shape looks like yours?”, “Which blade looks like yours?”, “What's your FCCID?”, “What's your OEM P/N”, “What color is the key head?”, “Look at the rear of the key. Which looks like yours?”) or series of prompts, the answers to which will result in the fewest remaining potential key blank matches.

If there are, at decision405it is determined if the key can be distinguished using a fundamental frequency for the key. If yes, at step406the user is prompted to press a button or key on the remote of the key fob for step407. At step408, the fundamental frequency is determined and sent to the car keys express (“CKE”) server423, which then returns data (e.g., a determined key type based on the fundamental frequency) back to the device100.

If the key cannot be distinguished by fundamental frequency, at decision409it is determined if the key can be distinguished by transponder data. To reduce the possibility of the customer selecting an incompatible key after the customer enters their vehicle data, it is determined by accessing information in a database if multiple keys, key fobs, or remotes with an integrated transponder could be compatible. This is done using an integrated transponder reader. A transponder type (e.g., “Megamos”, “Philips 46”, “HITAG2”, “HITAG-AES”, “DST-80”, etc) is determined and additional transponder data (e.g., the value at page 0x10) are read and uploaded to the server to further filter the results of truly compatible keys/remotes. If this can be determined, in step410an instructional video on how to insert the key plays and in step411the user inserts the key blade into the ROKS device100. In step412a flag is set that the key is inserted and in step413the transponder on the key is read, the transponder type is determined, the transponder data is read by an antenna or communication device in the clamping assembly300or in the smart device200. The data is sent to the car keys express (“CKE”) server423, which then returns data (e.g., a determined key type based on the transponder data) back to the device100.

If the key cannot be determined by the transponder data, at decision414it is determined if the key can be distinguished by the Federal Communications Commission identification (“FCCID”). To further reduce the possibility of the customer selecting an incompatible key, after the customer enters their vehicle data, if through database means it is determined that multiple keys/remotes with an integrated UHF transmitter could be compatible, the user may be prompted to provide the FCCID of the master key. To accomplish this, the user could be provided with a field to manually enter the FCCID or be allowed to capture and confirm a picture of the FCCID on the master key itself. If manually entered into a field or if through openly available OCR algorithms the FCCID is deciphered, the FCCID could be uploaded to the server to further filter the results of truly compatible keys/remotes. In addition, the system may use an OCR process to detect a stamp or other indicia or marking on the key blade or an OEM emblem or symbol.

If a picture is taken or an image is captured, the picture or image may be included with the key order to provide the operator who will be cutting or making the key at a remote location or at the hub with the ability to further manually validate that the ordered key is indeed compatible with the customer's vehicle. In combination with or in lieu of the FCCID information, the user may also be prompted to push a button on the remote as described above. An integrated UHF frequency detector is used to capture and determine the fundamental transmitter frequency. This fundamental frequency could be uploaded to the server to further filter the results of truly compatible keys/remotes.

If this can be determined, at decision415it is determined if the FCCID must be entered or if it can be captured by photo by the smart device200. If it must be entered, at step416the user is prompted to input the FCCID in a text field or similar input in step417. If it can be captured by photo, in step418a video is played showing how to find and capture the FCCID on the key or key fob. In step419the user is prompted to interact with a user interface element on the display210of the smart device200to capture an image of the FCCID. The captured FCCID is processed, such as by optical character recognition (“OCR”) in step420. In decision421it is determined if the captured FCCID is valid. If it is not valid it is stored as an image with the order in step422, and if it is valid the data is sent to the car keys express (“CKE”) server423, which then returns data (e.g., a determined key type based on the FCCID) back to the device100.

The process continues at A inFIG.4. In step424the user or customer is shown images of possible keys/remote that are compatible with their vehicle, then chooses key/remote to order by selecting the on-screen option for the desired key in step425. However, in some circumstance a customer may select the wrong key when ordering even though they have the master key in their hand and are presented with detailed images of the key being ordered, this possibility is mitigated using the determination processes described above.

If it is determined in decision426that the key is not inserted, at step427a video is played illustrating how to insert the key into the device100and in step428the user inserts the key. In step429, if the key is inserted the smart device200in step430captures an image of the key blade when the user interacts with a user interface element such as a button in step429. In decision431if the photo is acceptable the process proceeds to step433and if not in step432the user is prompted to adjust the key positioning and/or camera focus and the process returns to step429. In step433the user is prompted to submit the order by interacting with a user interface element and then in step434removes the master key from the device100. The process continues at B inFIG.5.

In step435the checkout process for the order is completed by inputting or determining store information, user name, email and phone number in addition to other information. In step436the smart device200displays an item number for an employee at the spoke location where the device100is located to use in completing obtaining payment for and finalizing the order. A store representative may be prompted for a password or other means of authorizing the process to proceed. In step437the order is placed through the commercial system at the spoke location business through their normal ordering and point-of-sale (“POS”) software and systems. In step438an order number, which may be a unique identifier, is generated. The spoke employee then, in step439, enters the order number into the device100. The order with order number is then sent to the key-cutting hub location in step440.

Prior to or contemporaneous with the order number and order being sent to the key cutting hub in step440, in step441an ordered part number of the master key to be used in creating the replacement or cut key, the photo or image of the key blade and/or FCCID, transponder or fundamental frequency information, and other vehicle information are transmitted to a server such as a car keys express (“CKE”) or iKEYLESS system. On the server side in step442, through database means, this received order information is associated with the “CKE ID” corresponding to the combination of the vehicle information and ordered key part number. The CKE ID is a collection of records that associates a minimum of the key blade type (e.g., generic blank Ilco part number), depth and spacing data (DSD) for the cutting of the key, and key series. Key data is verified in step444and this information is then transmitted to the key cutting hub in step445where an employee at the hub receives an email with order and key code data.

Using the tablet's front camera, the user also captures image of and uploads to server a picture of the full key showing shape, size, and button configuration. This aids in validation at iKEYLESS (server side) and/or at the hub that the ordered key is indeed compatible with the customer's vehicle. Customers may be provided with the ability to upgrade (e.g., they have a transponder key and separate remote and would like to buy a head key) or downgrade (e.g., the customer has a smartkey and wants a transponder key) the ordered key type, and the image of the master key will allow the operator at iKEYLESS and/or the hub to verify that the ordered key has the same blade type, key series, and will successfully pair with the customer's entered vehicle.

At the remote server one or more automatically executed algorithms or computer image processing techniques alone or in combination with operator processing and verification are used to process the image or images to decipher bitting information.

Processing of the image of the master key to be copied comprises the first step of detecting the outline of the key in a 2-D space, broken up into best-fit line segments, then evaluating those segments according to a set of known key blank physical properties and applicable tolerances in order to auto-correct (e.g., deskew, stretch/compress), auto-rotate, auto-align, and auto-scale the key image to either the tip or shoulder. The properties considered in this evaluation may include security type (e.g., edge-cut or high security), double or single sided, parallel and orthogonal surface locations, blade width, blade tip to shoulder distance, blade tip to first bit distance, blade shoulder to first bit distance, flat widths, cut angles, alignment surfaces (i.e., tip or shoulder), and MMY (in consideration of key wear likelihood and tendency).

The second step of determining the grid extents is then performed. Parallel lines, one for the top and one for the bottom, are assigned. Next, at a right angle to the top and bottom lines, tip and shoulder (if applicable to the key blank) lines are assigned.

The third step comprises overlaying a “grid” of the key blank's known depth and spacing data (DSD) onto the key image, where edge detection is then used to assign a bit position and bit number, along with a confidence value. The confidence may be a function of one or more of the following: known tolerances, thicknesses of detected shadows at each suspected bit position location; degree of agreement between opposite sides (in the case of a 2-sided symmetrical keyway); blade profile differences that can contribute to predictable differences in light and shadow thicknesses; bit error at each bit position using the absolute value of the error between the measured cut depth and the depth assigned to the detected bit value; and the sum of this same error across all bits.

Next, at each bit position, the bit number with the highest confidence value is output. This is the First Pass Bitting Output. The fourth step executes a pseudo closed-loop bitting determination or validation algorithm, which is iterative in nature and is critical in the evaluation and adjustment of the bitting output of each “pass” or processing step to ultimately arrive at a final bitting output with the highest confidence value. This algorithm consists of referencing known validation data against each “pass” of the validation algorithm and updating the confidence value at each bit position. For greater quality control, when the final bitting output is determined, to help minimize incorrect key bitting determination and unhappy customers, if the confidence value is below a predetermined threshold, an expert operator is flagged to manually check and/or adjust the deciphered key characteristics.

The primary validation data used is a lookup table of all valid bitting permutations, or “key codes” for the known key series. After each pass of the algorithm, a confidence value is calculated based on the bit error at each bit position between the absolute value of the difference between the measured cut depth at that bit position and the cut depth associated to the bit value at that same position of the potential matching key code. For any pass of the algorithm, a falsely deciphered key code match is inherently unlikely as the number of key codes in any particular key series is a small subset of all possible permutations that can be generated from the full space of bitting. For example, key series “40000-49999” used on TOYOTA 5-cut high security keys has 10,000 key codes, out of 59,049 (10 bit positions, 3 depths) possible permutations. So, in this example, the probability of wrongly deciphering a series of key cuts as any key code is about 17%. The probability of a false match is further decreased by applying the previously described predetermined confidence value limit to every potential match and selecting the potential match with the highest confidence value.

To aid the automatic algorithm and/or operator in reducing the number of passes of the algorithm (i.e., reducing the number of possible matching key codes), a key code/bitting search algorithm utilizes search criteria which may comprise one or more of the following: the number of bits; the maximum bit value allowed at the first bit position; the minimum and maximum bits values; the maximum adjacent bit variation (MACS); the minimum number of different bit values; the minimum difference between the highest bit value and lowest bit value; the maximum number of repeated adjacent bit values; the maximum number of times any bit value may appear; the likelihood that any two or more bit positions are the same bit values; and the possible range of values at any particular bit position. Given the low probability of a false match to a valid key code within a known key series and again using the key series “40000-49999” as an example, the key code/bitting search algorithm can reduce the list of potential matches from 10,000 to 3 with only a few of the search criteria being applied. At that point, the match with the highest calculated confidence value is selected.

When manual checking and adjustment occurs, over time, the algorithm logs its iterative failures and final successes to provide for experts to adjust the automatic algorithms, increasing the final pass bitting output accuracy.

Once the key code is determined, it is stored to memory. Then, the ordered key information along with the key code, bitting, image of the master key and not of the key blade itself, vehicle information, part number of ordered key, and order number are sent to hub for cutting. If this information matches from the spoke and from the server (iKEYLESS system), at decision446the process proceeds.

In step447an operator at the “hub” retrieves a key blank matching the ordered key from inventory, which may be part of or integrated with a key duplication machine, and compares the picture of the master key key blade with the ordered key selected from inventory to verify compatibility. In step448, the operator cuts the key to code. In step499the hub location dispatches a delivery driver to provide the key to the “spoke”.

If it is determined at decision450that the ordered key requires a pairing process, at decision451it is determined if the included transponder is cloneable. If a cloneable transponder does not exist within the ordered key, the driver OR spoke employee pairs the key to the customer's vehicle at step452using either vehicle specific On-Board Programming procedures or a separate programming tool. If the transponder is cloneable, it may be cloned using an integrated or attached key cloning device in step453. In step454it is determined if the new key starts the vehicle and operates the door locks. If the key passes or does not require programming it is delivered to the customer with their vehicle in step455, if it does not, the programming step is reattempted.

With reference to the process400shown inFIGS.3-6, the remote server at the iKEYLESS system, which may be at the hub that is cutting the key or may be at a separate location, attempts to determine key code from image in an automated fashion and assigns a confidence value of its success in doing so. If the determined confidence level is below a threshold, the order is flagged for manual review. An employee of the second location (iKEYLESS sever system location or hub location) manually determines the correct key code from the captured image. If the image is poor quality and/or the key is significantly worn, the pseudo closed-loop bitting determination/validation algorithm is used to find the most likely match. A manual version of this algorithm is provided to the operators that are decoding keys manually and this greatly increases their chance of success in manual decoding and decreases the time to do so.

With reference now toFIG.7, a system diagram for a system700for creating replacement vehicle keys according to the present invention is provided. The system700includes a remote access device1110, such as a point-of-sale smart device located at a retail store, a central key service1100, and a key cutting and transponder encoding hub facility1150, all of which are adapted to communicate via a communications network1126.

The remote access device1110presents user interfaces and collects user input data associated with a master key including identifying information, image data, key blank selection information, and transaction data, e.g., including a unique order number or identifier, and generates a key order record. The remote access device1110communicates the key order record to the central key service1100and/or the key cutting hub facility1150over communications network1126.

The central key service1100processes the received master key image data and user input data, confirms or corrects the key blank selection, and determines a set of key code data for use in cutting a duplicate key. In determining the key code data, the central key service processes the master key image data in a manner described above to verify key cut depths and determine a set of key bitting data. The set of key code data is confirmed as a “valid” key code by consulting a set of known valid OEM key codes associated with the master key. The key code data represents key bitting information used to cut a duplicate key blade. The central key service1100determines if the master key is a transponder type key and if the key is cloneable and generates a set of programming data upon determining the key is programmable. The central key service1100sends the key blank order record and the key code data as well as any key programming data to the key cutting hub1150via the communications network1126.

The key cutting hub1150receives the key blank order record and the key code data as well as any key programming data from the central key service1100. The key cutting hub may separately receive the key blank order record from the remote access device1110. In an alternative order flow, the remote access device1110may not be configured to communicate directly with the central key service1100and the key cutting hub may receive the key blank order from the remote access device1110and forward that record to the central key service1100. The key cutting hub pulls the selected and confirmed key blank from inventory and places the selected key blank in a key cutting machine for cutting based on the received key code data. In this manner, the key cutting hub cuts a key blank without having a physical master key present and based on key code data. To the extent the duplicate key is cloneable, the key cutting hub programs the duplicate key in a cloning process or otherwise prepares the key for programming if the key is a programmable type. The key cutting hub delivers the cut duplicate key with any appropriate key programming instructions and/or dongle or other device, if necessary, to an identified recipient. For example, delivery may be to a retail store at which the remote access device1110is located. The user may return to the retail store to pick up the duplicate key and pair the key with the target vehicle. Alternatively, the hub or retail store may deliver the duplicate key and programming instructions/equipment directly to the user or other identified recipient based on the key order record, e.g., mail the key to the user's address, and the duplicate key may be paired with the target vehicle independent of the retail store.

Note, the central key service1100and the key cutting hub1150may be co-located and essentially a combined facility.

Now in more detail, the central key service (“CKE”) system1100includes, for example, the iKeyless System1101for storing and processing user-captured images of master keys to be used in creating key blade copies. The system1100comprises an iKeyless or Car Keys Express WebAPI (Web Application Program Interface)1105which may be part of a system environment1104run on network server1102and is the conduit, or interface, through which the remote access device1110and the iKeyless System1101sends and receives information to/from the iKeyless DB1103. The network server1102may be in communication with the iKeyless database1103which stores information used by the iKeyless System1101and may pre-process captured images for use in creating key blade copies. The network server1102may comprise a processor and a non-transitory memory which stores instructions that, when executed by the processor, transform the network server1102into a special purpose computing machine. The iKeyless System1101processes the raw images to identify a set of features associated with a master key in the images. The iKeyless System1101further comprises a key outline module1132, a customer information module1138, a user interface controller1134, an order processing module1140, a key depth and bitting module1136, and a key feature module1144, the features of which are discussed in further detail hereinbelow.

The iKeyless System1101may be in communication over a network, such as a local area network, wide area network, or the Internet by connection1126with a remote access device1110. The Key Imaging and User Interface remote access device1110is operated by the user1109and may be a stand-alone computing device such as a computing kiosk, computer, or point-of-sale device, which may comprise a smart device or computer such as a tablet or smart phone capable of receiving user input via a touch-screen display and of capturing an image via a rear facing camera. As shown in the embodiment ofFIG.1, the remote access device1110is in the form of POS counter-top unit that includes as a display a tablet or the like device which include processing, memory and storage, user interface, operating system, and networking capabilities. The remote access device1110comprises a processor1120, system memory1112, local storage1122, and an image capture device1124. Programs and software are loaded from the local storage1122into the system memory1112and may comprise an operating system1114, application programs1116, a graphical user interface (“GUI”)1118, and local database1119. An application program1116communicates with the local database1119and provides a graphical user interface1118that comprises a set of user interface elements for interacting with the application program. The WebAPI1105provides a secure encrypted interface, exposed to the web, to/from which the remote access device application can send commands/requests and receive responses. The iKeyless System1101may be a desktop or a mobile application or both.

As a desktop application, the iKeyless System1101may be a software application compatible and compliant with Microsoft Windows operating systems such as Windows 7 and newer, but may also be a web-based software-as-a-service application that is compatible with web-browsers such as Google Chrome, Mozilla Firefox, and Microsoft Edge. The iKeyless System1101provides for the importing, processing, and manipulation of pictures to find key bitting quickly and effectively. The iKeyless System1101also provides for the detection of key bitting for house keys such as Schlage and Kwikset. The iKeyless System1101interfaces with the WebAPI1105to provide for the encrypted exchange of information between the iKeyless System1101and the Web API1105. The iKeyless System1101provides for the input of an order number and a line item number and will retrieve order provided key information (“OPKI”) to start a new order including the cutting and preparation of a replacement key. The iKeyless System1101can use the OPKI, modify the OPKI, and revert back to earlier versions of the OPKI. The OPKI used by the iKeyless System1101may be confined by or associated with a set of read-only key rules. These key rules comprise one or more of a number of bits, datum location (shoulder or tip), distances of datum to each bit, key bit cut depths max and min as measured from a keyway-defined reference, Maximum Adjacent Cut Specs (MACS), permitted or disallowed bit patterns, flat distance, shoulder to tip distance, blade width, and other applicable rules.

For a new job, within the user interface of the iKeyless System1101, the iKeyless System1101implements automatic algorithms with manual overrides which are applied to all photos upon import or upon manual adjustment and which comprise: the automatic detection of key features (e.g., tip, shoulder (if applicable), bottom, top, blade width, shoulder to tip distance); the auto-registration of a key image including the auto-rotation of the key, skew detection and auto-adjustment (detection of non-parallel key features) and auto-correction, stretch/compression detection (using, for example, known rules of shoulder to tip distance and blade width) and auto-correction; automatic detection of cut depths with visual indicators of the nominal cut depths for the detected bitting; zoom and pan option to make close-up, fine adjustments to the above features and registration information, and in the zoom mode, all detected key features and key bit cut depths are shown with visually indicated tolerance limits; automatic detection and highlighting of key features and key bit cut depths that break key rules; and the comparison of key bitting of up to 4 other pictures at once to verify bittings are the same through all photos.

For a reorder job using the iKeyless System1101, all previous job data is retrieved and displayed. By default, all automatic algorithms shall be disabled, but may be enabled by the user. Similar to a new job, manual overrides are provided to the user within the user interface for the manipulation of job data and of the image.

The automatic algorithms used by the iKeyless System1101can, without manual manipulation, extract key cut depths and key bitting data with a high degree of accuracy. Images captured and used for extracting key information including bitting information are saved and stored by the iKeyless System1101. The performance of the iKeyless System1101may be audited, for example, to determine the performance of the automatic detection and auto-registration algorithms. For an audit, after the initial import of key images and application of all automatic algorithms (which are enabled for new job and disabled for a re-order job), all initial job data (e.g., feature locations, registration information, key bitting, cut depths, breaks rules (yes/no) on a feature by feature and bit by bit basis) is saved locally. Then, upon exiting and/or saving the job, all initial and final job data may be exported via the iKeyless WebAPI1105and processed externally to determine accuracy.

As a mobile application, the iKeyless System1101may be a mobile application that is compatible and compliant with at least Apple IOS and/or Android standards. The mobile application version of the iKeyless System1101interfaces with the iKeyless WebAPI1105to allow encrypted exchange of information. The mobile application for the iKeyless System1101provides a user interface for a user to create a new account or log into existing account, access previous orders for review of order progress or to re-order, take pictures of existing key, buy new keys, and buy upgrades to previous or existing key products. A user may order automotive keys or house keys through the mobile application. In addition to the features provided by the desktop application version of the iKeyless System1101, the mobile application, and desktop application, also display slides or video clips showing a user how to take the best pictures of their key for the extraction of key information. This may include showing an example of what a “perfect” picture looks like. When taking an image of a key, camera orientation locked so that tilting mobile device will not auto-flip the screen, tilting the phone too far turns the screen red and prevents the taking of a picture, the flash defaults to being on with an option for it to be disabled, and a generic key silhouette is shown on the screen. After a picture is taken the picture displays an animation which traces the key outline to provide an indication to the user that the application has detected the outline of the key.

After key images have been captured and key information or data has been extracted, the user or customer may select an option to not have their key kept on file, to assign a nickname to key, to add a key purchase to a shopping cart, to remove items from the cart, to checkout, and to continue shopping. The user may also be presented with one or more “upsell” options to provide the user with the option to purchase additional keys and/or services based on what the customer has selected for purchase. For example, the user may be presented with the option to buy an extra remote for a vehicle, or buy an integrated key and remote instead of a separate key and remote. After an order has been entered, clicking on previous non-fulfilled orders allow user to see progress of order. For example, the user may be shown order statuses including: “Expert reviewing”, “Expert cutting”, and “Shipped”.

Processing of the image or images of the master key to be copied comprises evaluating the image according to key bitting rules and determining if the key bittings determined from the image or images is within acceptable tolerances for a particular key type. This will eliminate invalid key bitting information from a damaged or worn master key from which a key blade copy may not be cut. If an invalid bitting is determined from an image of a master key, an outline of the master key as determined by the system may be modified to create the best possible outline. A set of target key features are determined from this best possible outline to be used to create the key blade copy. The target key features comprise at least blade rotation, blade top line, blade bottom line, blade tip endpoint, blade shoulder line, shoulder to tip length, and blade width. This set of target key features is then compared to key bitting rules and tolerances to determine if the modified outline is an acceptable outline conforming to key bitting rules and tolerances from which a key blade copy may be cut. For each key type or model of key in the system, the key bitting rules contain measurements and parameters such as number of bits, shoulder to first bit, bit to bit spacing, bit heights as measured from a key-type-defined reference line, and maximum adjacent cut specs (MACS).

The captured image is analyzed in real-time to ensure the image is of the quality needed for further processing and provides input back to the user. The application may notify the user that the picture of sufficient quality or may inform the user that they need to recapture the image. Image processing algorithms to identify required key cuts includes software and algorithms that validates the captured image of the master key in real time. Additional key alignment algorithms for getting clean edge and surface images are also used. Another algorithm and process are used to identify and fix worn or damaged keys. This algorithm may identify and fix an outline of the master key in the captured image and adjust or geometrically change the outline including by adjusting the cut height to compensate for worn contours. Additional processes may be used to provide for better processing of a captured image, and these processes include limiting or compensating for image parallax, applying digital filters to the captured image, applying color or greyscale modes for higher quality images, applying edge detection and contrast enhancement filters or algorithms, and applying sequential imaging and filtering algorithms.

While the invention has been described by reference to certain preferred embodiments, it should be understood that numerous changes could be made within the spirit and scope of the inventive concept described. Also, the present invention is not to be limited in scope by the specific embodiments described herein. It is fully contemplated that other various embodiments of and modifications to the present invention, in addition to those described herein, will become apparent to those of ordinary skill in the art from the foregoing description and accompanying drawings. Thus, such other embodiments and modifications are intended to fall within the scope of the following appended claims. Further, although the present invention has been described herein in the context of particular embodiments and implementations and applications and in particular environments, those of ordinary skill in the art will appreciate that its usefulness is not limited thereto and that the present invention can be beneficially applied in any number of ways and environments for any number of purposes. Accordingly, the claims set forth below should be construed in view of the full breadth and spirit of the present invention as disclosed herein.